PROCESOS PARA LA IS - uv.mx

Facultad de Estadística e Informática

PROCESOS PARA LA INGENIERÍA DE SOFTWARE


Bibliografía▪ Pressman, R.S., Ingeniería del Software. Un enfoque práctico, quinta edición, 2002, España.

▪ Sommerville I., Ingeniería de Software, Addison-Wesley, 6ª. Edición, 2002, México.


En la clase anterior…

▪ Unidad III.Modelos de proceso de desarrollo de software◦Cascada

◦ Incremental

◦Evolutivo

◦Prototipo


Modelos de procesos de desarrollo de software

Repaso…



▪ Proceso de software

Se define proceso del software como una estructura para las actividades, acciones y tareas que se requieren a fin de construir software de alta calidad.



▪ Cada una de las actividades, acciones y tareas se

encuentra dentro de una estructura o modelo que

define su relación tanto con el proceso como entre sí.


▪Modelo general de

proceso



Actividades EstructuralesC

OM

UN

ICA

CIÓ

NP

LAN

EAC

IÓN

MO

DEL

AD

O

CO

NST

RU

CC

IÓN

DES

PLI

EGU

E

Actividades Sombrilla



▪ Flujo del proceso de las actividades estructurales



▪ Todos los modelos del proceso del software pueden

incluir las actividades estructurales generales

descritas anteriormente, pero cada una pone distinto

énfasis en ellas y define en forma diferente el flujo de

proceso que invoca cada actividad estructural (así

como acciones y tareas de ingeniería de software).



Modelos de procesos de desarrollo de

software existentes


Modelo en cascada



▪ Modelo en cascada o ciclo de vida clásico



Modelo en cascada o ciclo de vida clásico

Modelo en V


Modelo incremental



Modelos de proceso incremental




▪Como resultado del uso y/o evaluación de los incrementos previos se desarrolla un plan para el incremento que sigue.

▪El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad.

▪Este proceso se repite después de entregar cada incremento, hasta terminar el producto final.




▪ En cada incremento se entrega un producto que ya

opera.

▪ Útil en particular cuando no se dispone de personal

para la implementación completa del proyecto en el

plazo establecido por el negocio.


Modelo evolutivo



Modelos de proceso evolutivos

▪ Plazos apretados

▪Se comprende bien el conjunto de requerimientos o

el producto básico

▪ Los detalles del producto o extensiones del sistema

aún están por definirse.




❖Prototipo

❖Espiral


Modelo evolutivo. Prototipo




Prototipo

El modelado se centra en la representación de aquellos aspectos del software que serán visibles para los usuarios finales




Prototipo

✓El cliente define un conjunto de objetivos generales.

✓No identifica los requerimientos detallados para las

funciones y características.




Prototipo

¿Qué hacer con el prototipo cuando ya sirvió para el

propósito descrito?




Prototipo. Problemas

✓Los participantes ven lo que parece ser una versión

funcional del software, pero no se consideró la calidad, la

facilidad de mantenimiento, por la prisa. Los usuarios

exigen el prototipo como producto funcional.




Prototipo. Problemas

✓Se toman decisiones que inicialmente son las adecuadas

(con el fin de lograr el prototipo rápidamente): Lenguaje

de programación conocido, algoritmo ineficiente. Esta

elección formará parte del sistema final.




Prototipo. Paradigma exitoso si…

✓Se definen desde el principio las reglas del juego.

El prototipo sirve como el mecanismo para definir los requerimientos. Después se descartará (al menos en parte) y se hará la ingeniería del software real con la mirada puesta en la calidad.


Clase. Agenda

▪ Unidad III.Modelos de procesos de desarrollo de software◦Evolutivo

◦Espiral

◦PUDS (Proceso Unificado de Desarrollo de Software)


Modelo evolutivoESPIRAL


Modelos de proceso de desarrollo de software. Modelos de proceso evolutivos. Espiral.

Propuesto en primer lugar por Barry Boehm.

▪ Es un modelo con la naturaleza iterativa de hacer prototipos y los aspectos controlados y sistémicos del modelo de cascada.

▪Representa el proceso de desarrollo de software como una espiral.



✓El software se desarrolla en una serie de versiones incrementales.

✓Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo.

✓Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.



Consideración explícita del

riesgo.


Modelos de procesos de desarrollo de software. Modelos de proceso evolutivos. Espiral.

1. Definición de objetivos. • Define los objetivos específicos. • Identifica las restricciones del proceso y el

producto. • Se traza un plan detallado de gestión. • Se identifican los riesgos del proyecto.• Dependiendo de los riesgos se planean las

estrategias.


Modelos de procesos de desarrollo de software. Modelos de proceso evolutivos. Espiral

2. Evaluación y reducción del riesgo. • Análisis detallado de cada riesgo.• Plan para reducir los riesgos. • Diseño del prototipo de la fase.


Planes de contingencia.

1. Identificación de riesgos. Identificar los posibles riesgos para el proyecto, el producto y los negocios.

2. Análisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos.

3. Planificación de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto.

4. Supervisión de riesgos. Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible.




3. Desarrollo y validación.• Tareas requeridas para construir una o

más representaciones de la aplicación.• Construir, probar, instalar



4. Planificación.• El proyecto es revisado.• Se decide si continuar con otro ciclo en la

espiral.• Si se decide continuar se desarrollan

planes para la siguiente fase.



Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en

cada uno de los niveles evolutivos.

Utiliza la construcción de prototipos como mecanismo de reducción de riesgos.

Ventajas



Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de

evolución del producto.

Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.

Ventajas



Requiere una considerable habilidad para la evaluación del riesgo.

No se ha utilizado tanto como los paradigmas lineales secuenciales o de

construcción de prototipos.

Desventajas


Proceso Unificado de Desarrollo de SoftwareRUP (RATIONAL UNIFIED PROCESS)


Modelos de proceso de desarrollo de software. PUDS (Proceso Unificado de Desarrollo de Software)

Metodología de desarrollo de software basada en

componentes e interfaces bien definidas, y junto con

el Lenguaje Unificado de Modelado (UML), constituye

la metodología estándar más utilizada para el análisis,

implementación y documentación de sistemas

orientados a objetos.



Intenta obtener los mejores rasgos y características de los modelos tradicionales del proceso del software, implementando los mejores principios del desarrollo ágil.

Reconoce la importancia de la comunicación con el cliente y los métodos

directos para describir su punto de vista respecto de un sistema (el caso de uso)

Características


Ayuda a que el arquitecto se centre en las metas correctas: que sea comprensible, permita cambios futuros y la reutilización (Hace énfasis en la importancia de la arquitectura del software)


Características


Modelos de procesos de desarrollo de software. PUDS (Proceso Unificado de Desarrollo de Software)

Al principio de la década de 1990, James Rumbaugh [Rum91], Grady Booch [Boo94] e Ivar Jacobson [Jac92] comenzaron a trabajar en un “método unificado”, combinando sus métodos individuales de análisis y diseño oo.

El resultado fue UML, lenguaje de modelado unificado: Una notación robusta para el modelado y desarrollo de sistemas orientados a objetos.

Breve historia



UML brinda la tecnología necesaria para apoyar la práctica de la ingeniería de software orientada a objetos, pero no da la estructura del proceso que guíe a los equipos del proyecto cuando aplican la tecnología

Breve historia


Los orígenes de RUP remontan al modelo espiral original de Barry Boehm.

Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación.

En 1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson (famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos.)


Breve historia


Rational Unified Process fue el resultado de una convergencia de RationalApproach y Objectory (el proceso de la empresa Objectory AB).

El primer resultado de esta fusión fue Rational Objectory Process, la primera versión de RUP

Puesta en el mercado en 1998.


Breve historia



Ivar Jacobson, Grady Booch y James

Rumbaugh en su libro Unified Process,

analizan la necesidad de un proceso del

software “impulsado por el caso de uso,

centrado en la arquitectura, iterativo e

incremental”.



Principales elementos

Trabajadores

quién

Actividades

cómo

Artefactos

qué

Flujo de actividades

cuándo




Trabajadores

• Define comportamiento y responsabilidades (rol) de un individuo, grupo o sistema que trabajan en conjunto.

• Realizan las actividades.

Actividades

• Tarea que tiene un propósito claro




Artefactos

• Productos tangibles del proyecto que son producidos, modificados y usados por las actividades.

• Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.

Flujo de actividades

• Secuencia de actividades realizadas por trabajadores y que produce un resultado de valor observable.



Ciclo de vida

Dirigido por casos de uso

Iterativo e Incremental

Centrado en la

arquitectura



Ciclo de vida

Dirigido por casos de uso

Reflejan lo que los usuarios futuros necesitan y desean. Se captan cuando se modela el negocio y se representa a través de los requerimientos.

Los casos de uso guían el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo).



Ciclo de vida

Centra-do en la arqui-tectura

Muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo

Describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente.

RUP se desarrolla mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la arquitectura.

El modelo de arquitectura se representa a través de vistas en las que se incluyen los diagramas de UML.



Ciclo de vida

Iterativo e Incre-mental

Una iteración involucra actividades de todos los flujos de trabajo, aunque desarrolla fundamentalmente algunos más que otros.

Es práctico dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento.

Las iteraciones hacen referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del producto.



Ciclo de vida


Modelos de proceso de desarrollo de software. PUDS (Proceso Unificado de Desarrollo de Software).

Fases

Cada fase representa un ciclo de desarrollo en la vida de un producto de software.

❖Concepción❖Elaboración❖Construcción❖Transición



Fases. Concepción

✓Comunicación con el cliente y planeación.

✓ Identifica los requerimientos del negocio.

✓Propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.



Fases. Concepción✓Los requerimientos fundamentales

del negocio se describen por medio de un conjunto de casos de uso preliminares (detallan las características y funciones ).

✓La arquitectura son subsistemas principales con funciones y características



Fases. Concepción✓ Finalidad: Definir la visión, los objetivos y el

alcance del proyecto, tanto desde el punto de vista funcional como del técnico.

✓Resultados: Lista de los casos de uso y lista de los factores de riesgo del proyecto

✓ Principal esfuerzo: En el Modelamiento del Negocio y el Análisis de Requerimientos.

✓No necesariamente culmina con una versión ejecutable.



Fases. Concepción

La planeación:

✓Identifica los recursos.

✓Evalúa los riesgos principales.

✓Define un programa de actividades.



Fases. Elaboración✓Mejora y amplía los casos de uso preliminares.

✓Aumenta la representación de la arquitectura:

Los modelos del caso de uso, de requerimientos, del diseño, de la implementación y del despliegue

✓Al terminar la fase se revisa el plan.



Fases. Elaboración

✓Finalidad: Completar el análisis de los casos de uso y definir la arquitectura del sistema.

✓Se obtiene una aplicación ejecutable que responde a los casos de uso correspondientes.



Fases. Construcción

✓Se implementan en código fuente todas las características y funciones.

✓Compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto.




✓Se diseñan y efectúan pruebas unitarias.

✓Integración (ensamble de componentes y pruebas de integración).

✓Se emplean casos de uso para obtener un grupo de pruebas de aceptación que se ejecutan antes de comenzar la siguiente fase.




✓Permite contar en forma temprana con versiones el sistema que satisfacen los principales casos de uso.

✓Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración.



Fases. Transición✓Incluye las últimas etapas de la actividad

general de construcción y la primera parte de la actividad de despliegue general.

✓Entrega y retroalimentación.

✓Pruebas beta con usuarios finales.



Fases. Transición

✓Usuarios reportan tanto los defectos como los cambios necesarios.

✓Se generan manuales de usuario, guías de solución de problemas, etc.

✓Resultado: Producto utilizable que se lanza.

✓ Inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción.



Fases. Producción

✓Producción=Despliegue.

✓Se vigila el uso que se da al software

✓Se da apoyo al ambiente de operación (infraestructura)

✓Reporte de defectos y solicitudes de cambio para su evaluación.



▪Es posible que al mismo tiempo que se llevan a cabo las

fases de construcción, transición y producción, comience

el trabajo sobre el siguiente incremento del software.

▪Esto significa que las cinco fases del PU no ocurren en

secuencia sino que concurren en forma escalonada.


GRACIAS POR SU ATENCIÓN

PROCESOS PARA LA IS - uv.mx

Documents

Transcript of PROCESOS PARA LA IS - uv.mx