modelos de desarrollo de sistemas

MODELOS DE DESARROLLO DE SISTEMAS

¿ Qué es el proceso de desarrollo de sistemas?

Metodología seguida por una organización para el desarrollo del software

Esta metodología incluye todas las fases del ciclo de vida clásico Este proceso se define de manera general para todas las

aplicaciones de una organización Igualmente se definen tareas especificas a cada aplicación en

particular

2

3

El Proceso de Software “Conjunto estructurado de actividades requeridas para

desarrollar un sistema de software. Especificación. Diseño. Validación. Evolución”.

“Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse”.

“Debe estar explícitamente modelado si va a ser bien administrado”.

4

El Proceso de Software Las instrucciones para desarrollar una aplicación.

Cómo descubrir qué tiene que hacer la aplicación. Cómo decidir cómo va a estar estructurada la aplicación. Cómo asegurarse de que la aplicación funciona y hace lo que tenía que hacer. Cómo ocuparse de que la aplicación se pueda ampliar / migrar / adaptar.

Hay que adaptarlas para cada caso. Conviene que las instrucciones figuren por escrito

DESARROLLO DEL SOFTWARE

5

Modelos del proceso del software• Modelo lineal• Modelo en cascada• Modelo de construcción de prototipos• Modelo de desarrollo rápido de aplicaciones (DRA)• Modelos evolutivos: incremental, espiral, de desarrollo

concurrente• Modelo basado en componentes

6

Modelo lineal

7

Modelo en Cascada

• Desarrollado entre 1960-1980 • Basado en el modelo en cascada de Winston Royce• Se conoce como el ciclo de vida básico • Secuencia de actividades, donde la estrategia

principal es seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos mediante entregas calendarizadas.

8

Modelo en Cascada

9

Definición Análisis

Diseño Desarrollo

Pruebas Mantenim.

Definición de requisitos:• Las restricciones y metas del sistema se definen a partir de la

interacción con el interesado.• Se comprende la naturaleza de la aplicación y el dominio de

información, así como su funcionalidad, rendimiento e interconexión • Se reúnen todos los requisitos que debe cumplir el software

Modelo en Cascada

10

Definición Análisis

Diseño Desarrollo

Pruebas Mantenim.

Se concentra en cuatro características básicas:Estructura de datosArquitectura del softwareRepresentaciones de interfazDetalle procedimental (algoritmo)

Modelo en Cascada

11

Definición Análisis

Diseño Desarrollo

Pruebas Mantenim.

• Se llama también Implementación• Generación de código entendible por la máquina• Actualmente se investiga mucho sobre la manera

de generar código automáticamente

Modelo en Cascada

12

Definición Análisis

Diseño Desarrollo

Pruebas Mantenim.

• Proceso de depuración de programas• Chequear la validez de las sentencias• Pruebas para detectar errores, asegurando que a

partir de los datos de entrada si se genere la salida deseada

Modelo en Cascada

13

Definición Análisis

Diseño Desarrollo

Pruebas Mantenim.

• Corrección de errores no detectados en la etapa de pruebas

• Posibles mejoras funcionales debidas a nuevos requerimientos del cliente

• En esta fase se vuelven a aplicar todas las etapas anteriores sobre el software existente

Modelo en Cascada

14

Definición Análisis

Diseño Desarrollo

Pruebas Mantenim. LIMITACIONES

• En la realidad no estrictamente secuencial (se traslapan las etapas)

• El interesado debería exponer los requisitos en la etapa inicial, pero en realidad él lo hace a través de todo el proceso y esto complica las cosas

• La primera versión del software llega al final del proceso, a veces el afán del cliente hace que la aplicación final no cumpla con los requerimientos

Modelo de Construcción de Prototipos

Comienza con una recolección inicial de requisitos para pasar a un diseño rápido y finalmente a la construcción de un prototipo de la solución.

15

Modelo de Construcción de Prototipos

El desarrollador y el cliente deben ser concientes de que el prototipo se utiliza para precisar los requisitos del software y así evitar inconvenientes como:

• El cliente cree que el prototipo es una primera versión funcional del Sistema.

• El desarrollador construye el prototipo rápidamente y en ocasiones sin hacer uso de la tecnología optima disponible.

16

Modelo de Construcción de Prototipos

17

Modelo de Construcción de Prototipos

18

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

• Basado en el Modelo Lineal Secuencial• Modelo llevado a cabo por varias equipos de trabajo que siguen

las etapas del proceso de manera simultanea.• Modelo aplicable a la construcción de sistemas de información

fácilmente modularizables.• El Modelo DRA necesita clientes y desarrolladores

comprometidos con el proceso.• No es muy útil para aplicaciones que requieren adopción de

nuevas tecnologías porque la curva de aprendizaje puede afectar el cronograma del proyecto.

19

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

20

Modelo de Desarrollo Rápido de Aplicaciones (DRA)1. Modelo de Gestión:- ¿Qué información se genera?, ¿Quién la genera?.- ¿A dónde va la información?.- ¿Quién la procesa?.2. Modelado de Datos: Formalización del conjunto de objetos de datos

(definición de características de los objetos y relaciones entre ellos).3. Modelado de Procesos: Transformación de los objetos de datos para

lograr el flujo de información necesarios para las funciones de gestión.4. Generación de Aplicaciones: Utilización de programas ya existentes como

parte de la nueva solución (Reutilización de código).5. Pruebas y Entrega: Se verifican los componentes nuevos del sistema,

porque los ya existentes ya pasaron por el proceso de validación, lo que reduce el tiempo de pruebas del mismo.

21

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

22

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

23

Modelos evolutivos

• Modelos flexibles que permiten la modificación del sistema durante su proceso de desarrollo.

• Procesos iterativos que permiten a los desarrolladores construir versiones del software cada vez más completas

• Ejemplos:• Modelo Incremental.• Modelo Espiral.• Modelo Espiral WINWIN.• Modelo de Desarrollo Concurrente.

24

Modelo Incremental

• Aplica el enfoque lineal secuencial escalonadamente• Incrementos parciales de la herramienta completa (versiones) • Cada incremento agrega funcionalidad adicional o mejorada

sobre el sistema• Cada etapa debe cumplir con los requisitos de las desarrolladas

30

04

58

2 -

I.S

Univ

ers

idad N

aci

onal de

Colo

mbia

25Incremento 2

Incremento n

... ... ... ...

Análisis Diseño Código Pruebas

Análisis Diseño Código Pruebas

Análisis Diseño Código Pruebas

Modelo Incremental

26

Modelo Incremental• Ventajas:• Los clientes no tienen que esperar hasta que el sistema se entregue

completamente para comenzar a hacer uso de él.• Los clientes pueden usar los incrementos iniciales como prototipo para

precisar los requerimientos posteriores del sistema.• Minimización del riesgo de falla en el proyecto porque los errores se

van corrigiendo progresivamente.• Problemas:• Adaptación de los requisitos del cliente para lograr incrementos

pequeños (no mas de 20.000 líneas de código) que añadan funcionalidad al sistema.

• Nota: Una evolución de este enfoque se conoce como Programación Extrema (XP-Extreme Programming).

27

Modelo Espiral

• Utilización de ciclos en lugar de sucesión de actividades.• Facilita el desarrollo rápido de versiones incrementales de

software.

28

Modelo Espiral

29

Modelo Espiral

30

Modelo Espiral WINWIN

• Hace énfasis en la etapa Comunicación con el Cliente definiendo un conjunto de actividades de negociación que se llevan a cabo al principio de cada ciclo

• El proceso de negociación busca que ambos ganen, tanto cliente como analista:• el cliente obtiene el producto que satisface gran parte de sus

necesidades y • el desarrollador intenta obtener requisitos que le permitan cumplir con

tiempos de entrega realistas

31

Modelo Concurrente

• Provee una meta descripción del proceso de software• Mientras que en el Espiral la principal contribución es que las actividades

del software ocurran repetidamente, en el Concurrente es la capacidad de describir las múltiples actividades del software que ocurren simultáneamente.

• Dado que los requerimientos cambian es muy probable que una vez haya comenzado la fase de diseño, sea necesario incorporar cambios. En estos casos No se debe detener el diseño, sino que se debe continuar “si es posible” al mismo tiempo que se modifican los requerimientos.

• Por lo tanto en este modelo, diversas actividades pueden estar ocurriendo concurrentemente

• Posibilita el conocimiento del verdadero estado del proyecto

32

Modelo basado en componentes

33

Modelo basado en Componentes

• Identificar• componentes• candidatos

• Buscar • componentes• en biblioteca

• Extraer• componentes• disponibles

• Construir• componentes• que falten

• Añadir• componentes• a biblioteca

• Construir• iteración N• del sistema

34

Modelo basado en componentes

35

¿Qué Modelo Utilizar?

36

Un Proyecto...

• Un proyecto es una organización transitoria de individuos dedicados a alcanzar un objetivo especifico dentro de un periodo de tiempo, un presupuesto, y un objetivo técnico.

Por lo Tanto...

Un proyecto: • Tiene un principio y un fin. • Debe de tener un objetivo (debe de ser medible).• Requiere de un líder y de un equipo.

Lo que nos indica que es:• Temporal y Unico, ya que involucra hacer algo que no se ha hecho

antes.

¿Qué Modelo?

• Dado que cada proyecto es único, no existe un modelo que se aplique al 100% a todos los proyectos de una organización.

• Una organización puede contar con uno o más modelos de desarrollo para ser utilizados dependiendo del tipo de proyecto.

• El modelo seleccionado tendrá influencia en el éxito del proyecto y en el tipo de decisiones que se deberán hacer.

¿Cuál Seguir?

Para seleccionar el modelo a adoptar habrá que hacerse una serie de cuestionamientos:

• ¿Qué tantos son los riesgos del proyecto?• ¿Qué tan claros están los requerimientos?• ¿Se conoce bien la tecnología ha utilizar?• ¿Visibilidad que requiere el proyecto?• ¿Qué tanta planeación hacia adelante es requerida?• ¿Qué restricciones se tienen?

Criterios de Exito

• Contar con un modelo debidamente documentado. (entradas, salidas, entregables, aprobaciones)

• Los documentos deben de estar actualizados.

• La gente que participa en el proyecto debe estar capacitada en su uso.

• Se debe de reforzar el uso del modelo mediante auditorias y revisiones.

Criterios de Exito

• La alta gerencia debe soportar la utilización de un modelo.

• Cualquier desviación al modelo debe ser documentada y aprobada.

• Se debe de medir la eficiencia del modelo.

• Retroalimentar y ajustar.