Manejo de Procesos de Software

Ciclo de Vida

Serie de fases que se producen una tras otra
Serie de cambios en la vida de un organismo

Ciclo de vida un Software

Serie de fases que caracterizan el curso y la existencia de un producto de software
Desde la concepción hasta la muerte
El ciclo de vida inicia desde que es concebido y finaliza cuando el software ya no se usa más

Concepción

Siguiente fase

Retiro

Fases del ciclo de vida de un Software

Describen cómo un producto de software es creado
Son las mismas para todos los procesos de creación de software
Hay diferentes implementaciones de fases a lo que llamamos Modelos de Procesos de desarrollo de software

Ejemplo: una casa

Concepto: casa para la familia de 4 personas
Tipo de casa: número de cuarto, niveles, etc.
Cómo la construiremos: arquitecto, planos, etc.
Construir la casa
Inspección: fontanería, electricidad, estructura, etc.
Inspección final: aceptación del propietario, certificación de que se puede ocupar
Ocupar a la casa
Renovar la casa

Concepción

Análisis de Requerimientos

Diseño

Implementación

Prueba e Integración

Aceptación e Instalación

Operación y mantenimiento

Retirar

Resumen

Ciclo de vida no significa ciclo
Proceso
Una serie de fases que caracterizan el curso de existencia de un Software
El ciclo de vida comienza cuando el producto de software es concebido y finaliza cuando el software deja de usarse más
En los modelos de proceso de desarrollo de software de esta asignatura conoceremos las diversas manera en que el ciclo de vida de un software puede ser implementado

Modelo en Cascada

REQUERIMIENTO

DISEÑO

IMPLEMENTACIÓN

PRUEBA (TESTING)

MANTENIMIENTO

Historia

REQUERIMIENTO

MANTENIMIENTO

Winston W. Royce (1929 - 1995) fue un científico informático estadounidense y director del Centro de Tecnología de Software Lockheed en Austin, Texas.
"Gestión del desarrollo de grandes sistemas de software", Proceedings of IEEE Wescon, agosto de 1970, págs. 328-338
Royce no usó el término "modelo de cascada"
Royce no sugirió un "modelo de cascada" puro
Irónicamente, Royce describió este modelo como "riesgoso e invita al fracaso"

Modelo en cascada

REQUERIMIENTO

MANTENIMIENTO

Cada fase se ejecuta secuencialmente
El resultado producido por una fase se convierte en la entrada para la siguiente
Una nueva fase no comienza hasta que finaliza la fase actual
 En la práctica, puede haber una pequeña superposición entre las fases
 En la práctica, una relación iterativa entre fases adyacentes es inevitable
La ejecución avanza a una nueva fase cuando
 Documentación requerida para la fase actual ha sido completada
 Se completaron los criterios de salida para la fase actual
 Se completaron los criterios de entrada para la siguiente fase

Ventajas

REQUERIMIENTO

MANTENIMIENTO

Simple de entender e implementar
 Cada fase se ejecuta en un orden establecido, uno después del otro
 Las fases secuenciales paso a paso son fáciles de entender
 Cada fase requiere criterios específicos de entrada y salida que deben cumplirse
Probado y conocido
 El proceso se ha utilizado con éxito durante muchos años
 Muchas personas han sido parte de un proyecto de desarrollo de software que utilizó este modelo de proceso
Simple de administrar
 Dado que el modelo de proceso es tan rígido, la gestión del proceso se simplifica
 Los resultados de cada fase son claros

Ventajas

REQUERIMIENTO

MANTENIMIENTO

Asignación de recursos simplificada

 El orden secuencial de las fases facilita la asignación y administración recursos
 Dado que cada fase tiene sus propias necesidades específicas, las personas con esas habilidades específicas pueden asignarse fácilmente a fases distintas

Ideal para pequeños proyectos

 Este proceso supone que todos los requisitos se entienden claramente al comienzo del proyecto
 En proyectos más pequeños, los requisitos son generalmente más pequeños y más fáciles de entender

Desventajas

REQUERIMIENTO

MANTENIMIENTO

Requisitos claros y completos desde el principio
 Es muy difícil capturar con precisión y completamente todos los requisitos
 Normalmente, un proyecto comienza sin una comprensión completa de todos los requisitos
 A medida que el proyecto avanza, se descubren más requisitos y el proyecto se altera en consecuencia

Desventajas

REQUERIMIENTO

MANTENIMIENTO

Retroalimentación retrasada
 Los interesados no pueden dar su opinión hasta después de la Fase de prueba
 Dado que el proceso no es iterativo, no proporciona fácilmente a los Stakeholders versiones intermedias del producto
 Con frecuencia es deseable y necesario brindar a los Grupos de interés seguridad sobre el progreso, así como también confirmarles que lo que se está desarrollando cumple con sus requisitos.

Desventajas

REQUERIMIENTO

MANTENIMIENTO

Problemas descubiertos tarde
 Según este proceso, los problemas se encuentran durante la Fase de prueba
 Dependiendo del número y la naturaleza de los problemas encontrados, su impacto podría tener un efecto desastroso en el proyecto, tanto en términos de costo como de calendario

Desventajas

REQUERIMIENTO

MANTENIMIENTO

Sin procesos paralelos
 Cada fase se ejecuta en orden y se completa antes de pasar al siguiente
 En realidad, podría ser posible ejecutar algunas fases en paralelo, en lugar de secuencialmente
 Por ejemplo, el producto que se está construyendo puede estar compuesto de subsistemas que están relativamente desconectados. Estos subsistemas separados podrían concebiblemente desarrollarse en paralelo

Desventajas

REQUERIMIENTO

MANTENIMIENTO

Uso de recursos ineficiente
 Dado que las fases deben ejecutarse en orden, algunos miembros del equipo pueden estar inactivos mientras
esperando que se complete una fase en particular
 Aunque la tentación es mover individuos inactivos a la fase activa actual, la realidad es que estos individuos pueden no estar calificados para las tareas en esa fase

Resumen

REQUERIMIENTO

MANTENIMIENTO

 Old, well-known, fundamental model for software development
 It’s easy to understand and easy to use
 It works great for small, simple projects
 Unfortunately, it just has too many disadvantages to be used for complex development projects

Modelo en Espiral

Proceso iterativo
 El proceso de desarrollo de software se ejecuta a través de una serie de iteraciones
Impulsado por el riesgo
 La gestión del riesgo está incluida en el modelo
 Los riesgos se identifican y analizan al comienzo de cada iteración
 Durante cada iteración, se desarrolla un plan para abordar estos riesgos
 La planificación también está incluida en el modelo
Los 2 objetivos generales de cada iteración:
 Incrementar el grado de definición e implementación del sistema
 Disminuir el grado de riesgo

Pasos en cada iteración

Paso 1: evaluación / determinación de objetivos
 Revisar la iteración anterior
 Comprometerse con un enfoque para la próxima iteración
 Determinar objetivos, alternativas y restricciones

Paso 2: Análisis de riesgo

 Análisis
 Simulación

 Benchmarks

 Modelos
 Prototipos

Pasos en cada iteración

Paso 3: Ingeniería

 Requisitos
 Diseño
 Codificación
 Prueba: Unidad, Integración, Aceptación
 Lanzamiento

Paso 4: planifique la siguiente iteración

 Plan de ciclo de vida
 Plan de requisitos
 Plan de desarrollo
 Plan de integración y prueba

Modelo en espiral

Iteración 1: concepción del producto

Se crea el concepto inicial del producto de software
Los riesgos son analizados / resueltos
Se crea un prototipo
Documentos creados:

"Concepto de operaciones"

"Plan de ciclo de vida"

"Plan de requisitos"

Iteración 2: plan de requerimientos

Se recopilan los requisitos
Se analizan / resuelven los riesgos
Se crea un prototipo.
Documentos creados: "Plan de desarrollo"

Contenido del plan de desarrollo

Descripción general
Función del producto, clientes, entornos / plataformas y programa
Funcionalidad de alto nivel
Funcionalidad del producto; suficiente detalle para que los programadores capten los requisitos de implementación
Personal del proyecto

Roles requeridos para este proyecto, junto con la cantidad de personal requerido
para cada rol
Proceso de software
El proceso de desarrollo de software utilizado para producir el producto
Métodos de ingeniería de software
Los métodos y técnicas de ingeniería de software que se utilizarán para construir el producto de software

Contenido del plan de desarrollo

Horario y esfuerzo

 Un resumen del cronograma general del proyecto, junto con estimaciones de esfuerzo
 Incluye una lista de supuestos que se realizan y los riesgos asociados con esas suposiciones
Mediciones
 Una lista de métricas que se recopilarán a lo largo del curso de este proyecto
 Incluye una descripción de cómo se recopilarán las mediciones, qué roles las recopilarán, y cómo y dónde se almacenarán las mediciones
Riesgos del proyecto
 Una lista de los riesgos más importantes para este proyecto, con un párrafo por riesgo, clasificados en orden de probabilidad e impacto

Contenido del plan de desarrollo

Herramientas de software
 Una lista de las herramientas de software necesarias (como compiladores, editores, automatizados
herramientas de prueba, etc.), con referencia a cómo y cuándo se usarán
Soporte de hardware
 Una lista de todo el hardware necesario para ejecutar nuestro proyecto, tomando nota de cualquier hardware que deberá comprarse, instalarse o actualizarse
Soporte de software
 Una lista de todo el software necesario para completar nuestro proyecto, tomando nota de cualquier software que deberá comprarse, instalarse o actualizarse
Apoyo de personal
 Una lista de todas las personas o grupos de personas que brindarán apoyo

Iteración 3: plan de desarrollo

 El plan de desarrollo se desarrolla y refina
 Los riesgos son analizados / resueltos
 Se crea un prototipo
 Documentos creados:
"Plan de integración y prueba"

Contenido del plan de integración y prueba

Descripción general
Una lista de los principales tipos de pruebas que planea realizar y los objetivos de cada uno
Hitos de alto nivel
Una lista de hitos de prueba específicos, junto con los criterios necesarios para alcanzar esos hitos (como el número de pruebas ejecutadas, módulos específicos que se probarán, etc.)
Test Staffing
Una lista de los roles que realizarán las pruebas, y exactamente lo que deberán estar probando
Proceso de prueba
Descripciones de cómo se ejecutarán las pruebas, los datos que se utilizarán para ejecutar las pruebas, cómo se rastrearán los defectos y cualquier otra actividad de prueba relevante

Contenido del plan de integración y prueba

Métodos de prueba
Una lista de los métodos utilizados para realizar pruebas, como las pruebas basadas en el usuario, pruebas automatizadas, etc.
Mediciones
Una lista de los tipos de métricas capturadas, cómo serán capturadas y por qué roles y cómo se usarán y analizarán las mediciones
Probando riesgos
Una lista de todos los riesgos para las pruebas, clasificados por probabilidad e impacto
Herramientas de software

Una lista de cualquier herramienta de prueba especial requerida

Contenido del plan de integración y prueba

Soporte para prueba
Cualquier soporte de prueba adicional requerido, como hardware adicional, software o documentación
Apoyo de personal
Cualquier personal requerido fuera del equipo

Iteración 4: Planes de Integración, Prueba, Implementación

 Se desarrollan / refinan los planes de integración y prueba

 Los riesgos son analizados / resueltos

 Un prototipo operacional es creado

 Comienza la implementación real

 Diseño detallado

 Codificación

 Prueba

 UnitTesting

 IntegrationTesting

 AcceptanceTesting

 Lanzamiento del producto

Ventajas

Gestión de riesgos
 Los riesgos se manejan temprano y durante todo el proceso
 Los riesgos se reducen antes de que se vuelvan problemáticos, ya que se consideran en todas las etapas
 Las partes interesadas pueden comprender mejor y reaccionar ante los riesgos
Evolución del producto
 El producto de software comienza a producirse temprano en el ciclo de vida
 El producto de software evoluciona a medida que avanza el proyecto
 Es un enfoque realista para el desarrollo de software a gran escala
 Errores y alternativas poco atractivas se eliminan temprano

Ventajas

Énfasis en la planificación
 La planificación está integrada en el proceso
 Cada ciclo incluye un paso de planificación para ayudar a controlar y mantener un proyecto en marcha

Desventajas

Proceso complicado

 No es fácil de usar
 El análisis de riesgos requiere una experiencia altamente específica
 El éxito del proyecto depende en gran medida de un análisis de riesgos preciso
 Existe inevitablemente cierta superposición entre las iteraciones
Más adecuado para grandes proyectos
 Puede ser excesivo para pequeños proyectos
 La complicación puede no ser necesaria para proyectos más pequeños
 No tiene sentido si el costo del análisis de riesgos es una parte importante del costo total del proyecto