27
REPASO DE CONOCIMIENTOS Arbey Tovar Álvarez. CORPORACIÓN UNIFICADA NACIONAL FACULTAD DE INGENIERÍA SISTEMAS

Repaso de conocimientos

Embed Size (px)

Citation preview

Page 1: Repaso de  conocimientos

REPASO DE CONOCIMIENTOS

Arbey Tovar Álvarez.

CORPORACIÓN UNIFICADA NACIONAL

FACULTAD DE INGENIERÍA SISTEMAS

INGENIERÍA DE SISTEMAS III

BOGOTÁ

2016

Page 2: Repaso de  conocimientos

REPASO DE CONOCIMIENTOS

Arbey Tovar Álvarez.

Trabajo # 1

CATEDRÁTICO:

Néstor Alejandro Pinzón López

CORPORACIÓN UNIFICADA NACIONAL

FACULTAD DE INGENIERÍA SISTEMAS

INGENIERÍA DE SISTEMAS III

BOGOTÁ

2016

Page 3: Repaso de  conocimientos

Resumen

El propósito de este trabajo es realizar un pequeño y rápido recuento sobre algunos conceptos básicos e

importantes en el estudio de la ingeniería del software, nivel 3, para lo cual se citaran los solicitados en

clase, con algunos ejemplos, de este extenso tema.

Page 4: Repaso de  conocimientos

CONTENIDO

INTRODUCCIÓN...........................................................................................................................................5_ ¿Qué son los casos de uso?.........................................................................................................................6

_ ¿Cuáles son sus Elementos?......................................................................................................................7_ ¿Cuáles son sus Relaciones?.....................................................................................................................8

Ciclo de Vida (SDLC).....................................................................................................................................9Actividades del SDLC................................................................................................................................10Comunicación............................................................................................................................................10Recolección de solicitudes.........................................................................................................................11Estudio de viabilidad..................................................................................................................................11Análisis del sistema....................................................................................................................................12Diseño de Software....................................................................................................................................12Codificación...............................................................................................................................................12Pruebas.......................................................................................................................................................13Integración..................................................................................................................................................13Implementación..........................................................................................................................................13Mantenimiento y Funcionamiento.............................................................................................................13Metodologías..............................................................................................................................................14

VENTAJAS DEL USO DE UNA METODOLOGÍA...................................................................................15DEBILIDADES EN EL MODELO...............................................................................................................16

Ventajas......................................................................................................................................................16Inconvenientes............................................................................................................................................17

Fase de iniciación:..................................................................................................................................18Fase de elaboración:...............................................................................................................................18Fase de construcción:.............................................................................................................................18Fase de transición:..................................................................................................................................18

BIBLIOGRAFÍA............................................................................................................................................20

Page 5: Repaso de  conocimientos

INTRODUCCIÓN

El presente trabajo se hace para reforzar conocimientos y tener más clara la terminología necesaria para

obtener una buen desempeño a la hora de empezar a estructurar conceptos, e ideas, pensamiento y

usabilidad del proyecto sistema experto de información para el diagnóstico del estrabismo en niños de 3 a 5

años de edad, un proyecto como este, de tipo educativo o netamente laboral.

Page 6: Repaso de  conocimientos

Basados en estas necesidades en el siguiente texto encontraremos la definición de una serie de preguntas

las cuales son la base para la elaboración como herramientas para adquirir la experticia al momento de

elaborar un buen proyecto.

_ ¿Qué son los casos de uso?

Page 7: Repaso de  conocimientos

Los casos de uso son una técnica para especificar el comportamiento de un sistema: “Un caso de uso es una

secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.” Todo sistema

de software ofrece a su entorno –aquellos que lo usan– una serie de servicios.

Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos

“alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por

otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe

ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio,

podemos decir que está “ejecutando” el caso de uso ingresando pedido.

_ ¿Cuáles son sus Elementos?

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es

importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente

representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor

con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

_ ¿Qué es un caso de uso?

Page 8: Repaso de  conocimientos

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una

petición de un actor o bien desde la invocación desde otro caso de uso.

_ ¿Cuáles son sus Relaciones?

Asociación 

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación

(caso de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación 

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se

instancia (se crea). Dicha relación se denota con una flecha punteada.

Generalización 

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su

estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores).

Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

Uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un

caso de uso y no se desea mantener copiada la descripción de la característica.

Page 9: Repaso de  conocimientos

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en

donde está la duda clásica de usar o heredar.

Ciclo de Vida (SDLC)

El presente es un esquema que como se representa gráficamente un ciclo de vida para un proyecto en

ingeniería de sistemas

El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas), es una secuencia estructurada y bien

definida de las etapas en Ingeniería de software para desarrollar el producto software deseado.

Page 10: Repaso de  conocimientos

Actividades del SDLC

El SDLC aporta una serie de pasos a seguir con la finalidad de diseñar y desarrollar un producto software

de manera eficiente. El borrador del SDLC incluye los pasos que veremos a continuación:

Comunicación

Page 11: Repaso de  conocimientos

Este es el primer paso donde el usuario inicia la petición de un producto software determinado. Contacta al

proveedor de servicios e intenta negociar las condiciones. Presenta su solicitud al proveedor de servicios

aportando la organización por escrito.

Recolección de solicitudes

A partir de este paso y en adelante el equipo de desarrollo software trabaja para tirar adelante el proyecto.

El equipo se reúne con varios depositarios de dominio del problema, e intentan conseguir la máxima

cantidad de información posible sobre lo que requieren. Los requisitos se contemplan y agrupan en

requisitos del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos

se lleva a cabo como se especifica a continuación:

Estudiando el software y el sistema actual u obsoleto,

Entrevistando a usuarios y a desarrolladores de Software,

Consultando la base de datos o

Recogiendo respuestas a través de cuestionarios.

Estudio de viabilidad

Después de la recolección de requisitos, el equipo idea un plan para procesar el software. En esta fase, el

equipo analiza si el software puede hacerse para cubrir todos los requisitos del usuario y si hay alguna

posibilidad de que el software ya no sea necesario. Se investiga si el proyecto es viable a nivel financiero,

práctico, y a nivel tecnológico para que la organización acepte la oferta. Hay varios algoritmos disponibles,

los cuales ayudan a los desarrolladores a concluir si el proyecto software es factible o no.

Page 12: Repaso de  conocimientos

Análisis del sistema

En este paso los desarrolladores trazan su plan e intentan crear el mejor y más conveniente modelo de

software para el proyecto. El análisis del sistema incluye el entendimiento de las limitaciones del producto

Software; el aprendizaje de los problemas relacionados con el sistema; los cambios que se requieren en

sistemas ya existentes con antelación, identificando y dirigiendo el impacto del proyecto a la organización

y al personal, etc. El equipo del proyecto analiza las posibilidades del proyecto y planifica la

temporalización y los recursos correspondientes.

Diseño de Software

El siguiente paso es diseñar el producto software con la ayuda de toda la información recogida sobre

requisitos y análisis. Los inputs (aportaciones) de los usuarios y los resultados de la recogida de

información hecha en la fase anterior serán las aportaciones base de la fase actual. El output (o resultado)

de esta etapa toma la forma de 2 diseños; El diseño lógico y el diseño físico. Los ingenieros crean meta-

data (Metadatos), Diagramas dilógicos, diagramas de flujo de datos, y en algunos casos pseudocódigos.

Codificación

Esta fase también se puede denominar 'fase de programación'. La implementación del diseño de software

empieza con el lenguaje de programación más conveniente, y desarrollando programas ejecutables y sin

errores de manera eficiente.

Page 13: Repaso de  conocimientos

Pruebas

Se estima que el 50% de todos los procesos de desarrollo de software deberían ser evaluados. Los errores

pueden arruinar el software tanto a nivel crítico y hasta el punto de ser eliminado. Las pruebas de Software

se hacen mientras se codifica y suelen hacerlo los desarrolladores y otros expertos evaluadores a varios

niveles. Esto incluye evaluación de módulos, evaluación del programa, evaluación del producto, evaluación

interna y finalmente evaluación con el consumidor final. Encontrar errores y su remedio a tiempo es la

llave para conseguir un software fiable.

Integración

El Software puede necesitar estar integrado con las bibliotecas, Bases de datos o con otro u otros

programas. Esta fase del SDLC se focaliza en la integración del software con las entidades del mundo

exterior.

Implementación

Aquí se instala el software en máquinas de clientes. A veces, el software necesita instalar configuraciones

para el consumidor final con posterioridad. El Software se evalúa por su adaptabilidad y su portabilidad, en

cuanto a las cuestiones relacionadas con la integración y conceptos asociados, se resuelven durante la

implementación.

Mantenimiento y Funcionamiento

Page 14: Repaso de  conocimientos

Esta fase confirma el funcionamiento del software en términos de más eficiencia y menos errores. Si se

requiere, los usuarios se forman, o se les presta documentación sobre como operar y como mantenerlo en

funcionamiento. El software se mantiene de forma temprana actualizando el código en acorde a los

cambios que tienen lugar en entornos del usuario o tecnológicos. Esta fase puede que tenga que encarar

retos originados por virus ocultos o problemas no identificados del mundo real.

Disposición

Con el paso del tiempo, puede que el software falle en su ejecución. Puede que se vuelva totalmente

obsoleto o que necesite actualizaciones. De ahí surge una necesidad urgente de eliminar una parte

importante del sistema. Esta fase incluye archivar datos y componentes software requerido, cierre del

sistema, planificación de la actividad de disposición y terminación de sistema en el momento final del

sistema.

Metodologías

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas

metodológicas que inciden en distintas dimensiones del proceso de desarrollo.

Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea

y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de

software detallado y completo.

Una metodología para el desarrollo de software comprende los procesos a seguir sistemáticamente para

idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que

cumplimos el objetivo por el cual fue creado. DESARROLLO ITERATIVO E INCREMENTAL El

Page 15: Repaso de  conocimientos

desarrollo iterativo e incremental es una parte esencial de RUP, de DSDM, XP y generalmente de los

marcos de trabajo de desarrollo de software ágil.

RAPID APPLICATION DEVELOPMENT (RAD) La metodología de desarrollo rápido de aplicaciones

(RAD) se desarrolló para responder a la necesidad de entregar sistemas muy rápido.

No es apropiado para todos los proyectos.

El alcance, el tamaño y las circunstancias, determina el éxito de un enfoque RAD. 

El método RAD tiene una lista de tareas y una estructura de desglose de trabajo diseñada para la rapidez.

El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE

(Computer Aided Software Enginering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a

englobar también la usabilidad, utilidad y rapidez de ejecución.

VENTAJAS DEL USO DE UNA METODOLOGÍA

 

Desde el punto de vista de gestión:

Facilitar la tarea de planificación

Facilitar la tarea del control y seguimiento de un proyecto.

Mejorar la relación coste/beneficio

Optimizar el uso de recursos disponibles

Facilitar la evaluación de resultados y cumplimiento de los objetivos

Definir el ciclo de vida que más se adecue a las condiciones y características del desarrollo

Facilitar la comunicación efectiva entre usuarios y desarrolladores

Desde el punto de vista de los ingenieros del software:

Ayudar a la comprensión del problema

Page 16: Repaso de  conocimientos

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

Facilitar el mantenimiento del producto final.

Permitir la reutilización de partes del producto.

Desde el punto de vista del cliente o usuario:

Garantía de un determinado nivel de calidad en el producto final

Confianza en los plazos de tiempo fijados en la definición del proyecto.

DEBILIDADES EN EL MODELO

En la retroalimentación hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a

avances extremadamente lentos.

No es una aplicación ideal para desarrollos en los que de antemano se sabe que serán grandes en el

consumo de recursos y largos en el tiempo.

Al requerir constantemente la ayuda de los usuarios finales, se agrega un coste extra a la compañía, pues

mientras estos usuarios evalúan el software dejan de ser directamente productivos para la compañía.

Ventajas 

•Velocidad de desarrollo 

•Calidad: resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes

de mantenimiento bajos. 

•Visibilidad temprana debido al uso de técnicas de prototipo. 

Page 17: Repaso de  conocimientos

•Mayor flexibilidad que otros modelos. 

•Ciclos de desarrollo más cortos.

Inconvenientes 

•Características reducidas. 

•Escalabilidad reducida. 

Más difícil de evaluar el progreso porque no hay hitos clásicos. RATIONAL UNIFIED PROCESS (RUP)

El proceso unificado Rational (RUP) es un marco de trabajo de proceso de desarrollo de software iterativo

creado por Rational Software Corporation, una división de IBM desde 2003. RUP no es un proceso

preceptivo concreto individual, sino un marco de trabajo de proceso adaptable, con la idea de ser adaptado

por las organizaciones de desarrollo y los equipos de proyecto de software que seleccionarán los elementos

del proceso que sean apropiados para sus necesidades. Módulos de RUP se basa en un conjunto de módulos

o elementos de contenido, que describen qué se va a producir, las habilidades necesarias requeridas y la

explicación paso a paso describiendo cómo se consiguen los objetivos de desarrollo. Los módulos

principales, o elementos de contenido, son: Fases del ciclo de vida del proyecto RUP determina que el ciclo

de vida del proyecto consiste en cuatro fases que permiten que el proceso sea presentado a alto nivel de una

forma similar a un estilo en cascada.

Cada fase tiene un objetivo clave y un hito al final que denota que el objetivo se ha logrado. •Roles (quién):

conjunto de habilidades, competencias y responsabilidades relacionadas. 

Productos de trabajo (qué): representa una tarea, incluyendo todos los documentos y modelos producidos

en el proceso. 

Page 18: Repaso de  conocimientos

Tareas (cómo): describe una unidad de trabajo asignada a un rol que proporciona un resultado significante.

Las cuatro fases en las que divide el ciclo de vida del proyecto son:

 Fase de iniciación: se define el alcance del proyecto. 

Fase de elaboración: se analizan las necesidades del negocio en mayor detalle y se define sus principios

arquitectónicos. 

Fase de construcción: se crea el diseño de la aplicación y el código fuente. 

Fase de transición: se entrega el sistema a los usuarios. RUP proporciona un prototipo al final de cada

iteración. 

Dentro de cada iteración, existen seis disciplinas de ingeniería :

Modelaje de negocio

Requisitos 

Análisis y diseño 

Implementación 

Pruebas 

Despliegue Tres disciplinas de soporte.

Gestión de la configuración y del cambio.

Gestión de proyectos. 

Entorno Extreme Programming (XP)

Esta Ultima se considera una de las mejores metodologías de desarrollo por seruna metodología ágil

centrada en potenciar las relaciones interpersonales, que promueve el trabajo en equipo y con aprendizaje

Page 19: Repaso de  conocimientos

de los desarrolladores, se propicia un buen clima de trabajo; se basa en la realimentación continua: cliente-

equipo de desarrollo.

Comunicación fluida entre todos los participantes, Simplicidad en las soluciones implementadas y coraje

para enfrentar los cambios. Elementos de la metodología Las historias de usuario: son la técnica utilizada

para especificar los requisitos del software.