MODELOS DE PROCESO DE SOFTWARE

TEMAS DE UNIDAD IV 4.1.- Modelo de cascada

4.2.- Modelo de espiral

4.3.- Modelo incremental

4.4.- Proceso de desarrollo unificado

4.5.- Proceso software personal

MODELOS DE PROCESO DE SOFTWARE

Por su naturaleza los modelos son simplificados,por lo tanto un modelo de procesos del software esuna abstracción de un proceso real”.

Los modelos genéricos no son descripcionesdefinitivas de procesos de software; sin embargo,son abstracciones útiles que pueden ser utilizadaspara explicar diferentes enfoques del desarrollo desoftware.

4.1. MODELO DE CASCADA El modelo en cascada, alguna vez llamado el ciclo de

vida clásico, sugiere un enfoque sistemático,secuencial hacia el desarrollo del software, que seinicia con la especificación de requerimientos delcliente y que continúa con la planeación, el modelado,la construcción y el despliegue para culminar en elsoporte del software terminado.

Análisis de requisitos: Se analizan las necesidades de los usuariosfinales del software para determinar qué objetivos debe cubrir.

Diseño: Se descompone y organiza el sistema en elementos quepuedan elaborarse por separado, aprovechando las ventajas deldesarrollo en equipo.

Codificación: Aquí se desarrolla el código fuente, haciendo uso deprototipos así como pruebas y ensayos para corregir errores.

Pruebas: Los elementos, ya programados, se ensamblan paracomponer el sistema y se comprueba que funciona correctamenteantes de ser puesto en explotación.

Implantación: El software obtenido se pone en producción.

Mantenimiento: Durante la explotación del sistema softwarepueden surgir cambios.

4.2. MODELO DE ESPIRAL

El modelo en espiral, que Boehm propusooriginalmente, es un modelo de proceso de softwareevolutivo que conjuga la naturaleza iterativa de laconstrucción de prototipos con los aspectos controladosy sistemáticos del modelo en cascada.

Este método está basado en dos importantes principios:

1) La práctica de diseño profesional es caracterizar entérminos de conocer, actuar en situaciones, conversacióncon la situación y reflexión en acción. Hay un distintomedio de proceso - orientación en esta aproximación aldiseño

2) La necesidad para diseñadores de tomar la práctica detrabajo seriamente, de supervisar las formas en las que eltrabajo se esté haciendo, en el sentido de una soluciónabierta y desplegada para aumentar la complejidad de unasituación que el diseñador sólo entiende parcialmente.

LAS ETAPAS DEL MODELO EN ESPIRAL PUEDEN SER LAS SIGUIENTES

Planificación: Determinación de objetivos, limites y condiciones de contorno(condiciones que limitan de alguna manera el desarrollo, económicas, detiempo, etc.) y alternativas .

Análisis de riesgo: Desarrollo de un plan para descubrir los riesgos másimportantes y resolver los mismos.

Ingeniería: Desarrollo del producto o prototipo según las condiciones de laetapa anterior.

Evaluación : Evaluar los resultados del prototipo obtenido, verificar y validar.

Toma de decisiones: Se determina si se pasa al ciclo exterior o se realiza unanueva iteración.

Refinamiento : Si se toma la decisión de continuar en los ciclos internos sesofistican las condiciones a tomar en cuenta en el planeamiento del nuevociclo, en los ciclos exteriores es una etapa que no se utiliza.

4.3. MODELO INCREMENTAL El modelo incremental entrega el software en partes pequeñas,

pero utilizables, llamadas "incrementos". En general, cadaincremento se construye sobre aquel que haya sido entregadoanteriormente.

Perteneciente a la familia de los Modelos de Procesos Evolutivos,el Modelo Incremental combina elementos del Modelo LinealSecuencial (MLS) con la filosofía interactiva de construcción deprototipos.

CARACTERÍSTICAS DEL MODELO INCREMENTAL

a) Combina elementos del modelo de cascada con la filosofía interactiva de construcciónde prototipos.

b) El primer incremento es un producto esencial (núcleo), se afrontan requisitos básicos.

c) Los requisitos son priorizados.

d) Los requisitos de un incremento son inamovibles.

e) El cliente usa el producto central y en base a la utilización y/o evaluación, Este procesose repite hasta que se elabora el producto completo.

f) Es interactivo, al igual que el de construcción de prototipos y otros enfoques evolutivos.

g) Es útil cuando la dotación de personal no está disponible para una implementacióncompleta.

h) Las siguientes son algunas creencias del modelo incremental: La administración de proyectos es más fácil de lograr . Es más fácil comprender y probar incrementos de funcionalidad más pequeños. La funcionalidad inicial se desarrolla más temprano,. Hay más probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos

del software en el tiempo.

LOS PASOS DEL MODELO INCREMENTAL

1) El primer incremento a menudo es un producto esencial, se implementan los requerimientos básicos.

2) Se entrega un producto operacional al cliente

3) El cliente lo utiliza, como resultado de la utilización y/o evaluación.

4) El cliente solicita mejoras al producto

5) Se desarrolla el siguiente incremento incorporando los nuevos requisitos y agregando la nueva función.

6) Se desarrolla el siguiente incremento.

7) Se repite nuevamente el ciclo.

4.4. PROCESO DE DESARROLLO UNIFICADO

De alguna manera, el proceso unificado (PU) es un intentoencaminado a reunir los mejores rasgos y características demodelos de procesos de software, pero los caracteriza demanera que implementa muchos de los mejores principiosdel desarrollo ágil de software.

Fases del proceso unificado1. Inicio del PU abarca la comunicación con cliente - actividades de

planeación. En este punto, la arquitectura no es más que unesquema tentativo de los subsistemas más importantes y de lasfunciones y características que los forman.

2. Elaboración abarca la comunicación con el cliente y las actividadesde modelado del modelo genérico del proceso.

3. Construcción del PU es idéntica a la actividad de construccióndefinida para el proceso genérico del software.

4. Transición del PU abarca las últimas etapas de la actividad genéricade construcción y la primera parte de la actividad genérica dedespliegue.

5. Producción del PU coincide con la actividad de despliegue delproceso genérico.

Fases del proceso unificado1. Inicio del PU abarca la comunicación con cliente - actividades de

planeación. En este punto, la arquitectura no es más que unesquema tentativo de los subsistemas más importantes y de lasfunciones y características que los forman.

2. Elaboración abarca la comunicación con el cliente y las actividadesde modelado del modelo genérico del proceso.

3. Construcción del PU es idéntica a la actividad de construccióndefinida para el proceso genérico del software.

4. Transición del PU abarca las últimas etapas de la actividad genéricade construcción y la primera parte de la actividad genérica dedespliegue.

5. Producción del PU coincide con la actividad de despliegue delproceso genérico.

Fases del proceso unificado1. Inicio del PU abarca la comunicación con cliente - actividades de

planeación. En este punto, la arquitectura no es más que unesquema tentativo de los subsistemas más importantes y de lasfunciones y características que los forman.

2. Elaboración abarca la comunicación con el cliente y las actividadesde modelado del modelo genérico del proceso.

3. Construcción del PU es idéntica a la actividad de construccióndefinida para el proceso genérico del software.

4. Transición del PU abarca las últimas etapas de la actividad genéricade construcción y la primera parte de la actividad genérica dedespliegue.

5. Producción del PU coincide con la actividad de despliegue delproceso genérico.

Fases del proceso unificado1. Inicio del PU abarca la comunicación con cliente - actividades de

planeación. En este punto, la arquitectura no es más que unesquema tentativo de los subsistemas más importantes y de lasfunciones y características que los forman.

2. Elaboración abarca la comunicación con el cliente y las actividadesde modelado del modelo genérico del proceso.

3. Construcción del PU es idéntica a la actividad de construccióndefinida para el proceso genérico del software.

4. Transición del PU abarca las últimas etapas de la actividad genéricade construcción y la primera parte de la actividad genérica dedespliegue.

5. Producción del PU coincide con la actividad de despliegue delproceso genérico.

Fases del proceso unificado1. Inicio del PU abarca la comunicación con cliente - actividades de

planeación. En este punto, la arquitectura no es más que unesquema tentativo de los subsistemas más importantes y de lasfunciones y características que los forman.

2. Elaboración abarca la comunicación con el cliente y las actividadesde modelado del modelo genérico del proceso.

3. Construcción del PU es idéntica a la actividad de construccióndefinida para el proceso genérico del software.

4. Transición del PU abarca las últimas etapas de la actividad genéricade construcción y la primera parte de la actividad genérica dedespliegue.

5. Producción del PU coincide con la actividad de despliegue delproceso genérico.

Fases del proceso unificado1. Inicio del PU abarca la comunicación con cliente - actividades de

planeación. En este punto, la arquitectura no es más que unesquema tentativo de los subsistemas más importantes y de lasfunciones y características que los forman.

2. Elaboración abarca la comunicación con el cliente y las actividadesde modelado del modelo genérico del proceso.

3. Construcción del PU es idéntica a la actividad de construccióndefinida para el proceso genérico del software.

4. Transición del PU abarca las últimas etapas de la actividad genéricade construcción y la primera parte de la actividad genérica dedespliegue.

5. Producción del PU coincide con la actividad de despliegue delproceso genérico.

4.5. PROCESO SOFTWARE PERSONAL

El modelo de Proceso SoftwarePersonal (PSP) se caracterizaporque es de uso personal y seaplica a programas pequeños demenos de 10,000 líneas decódigo. Se centra en laadministración del tiempo y enla administración de la calidada través de la eliminacióntemprana de defectos.

NIVELES DE PSP

PSP tiene un marco de proceso de evolución similar al quetiene CMM (Evaluación basados en la mejora de procesosinternos CBA IPI). PSP trata parcialmente 12 de las 18 capasdefinidas en el CMM.

PSP logra esto proporcionando un marco de proceso personalya definido que el programador puede utilizar. Este marco es:

Desarrollar un plan para cada proyecto y/o componente. Registrar su tiempo de desarrollo. Registrar sus defectos Conservar sus datos en informes del proyecto Utilizar sus datos para planear los proyectos y/o los componentes

futuros. Analizar sus datos para desarrollar sus procesos con más calidad para

mejorar su funcionamiento.