Ciclo de Vida Proyecto de Software

Lic. César Alcántara Loayza

CAL/Requerimientos

¿qué es un proyecto?

Documentación que se elabora para la ejecución de una iniciativa de envergadura, con previsión de todos los detalles necesarios para su logro.

CAL/Requerimientos

¿qué es un proyecto?

Objetivo – Establece el propósito. Alcance – Detalla el objetivo. Complejidad – Determina los pasos

o subproyectos. Estructura y condiciones.

Unico – Realizados de una vez. Producto – Un resultado tangible o

intangible.

CAL/Requerimientos

¿qué es un proyecto? El primer paso para la elaboración de un

proyecto técnico es la presentación de un ‘pliego de condiciones técnicas’, en el que se detalla lo que se quiere hacer y sus características generales

El pliego de condiciones técnicas pretende establecer los compromisos técnicos que deberá asumir el gerente de proyecto

CAL/Requerimientos

Metodología

La forma, manera, en que se realiza algo (proyecto).

Conjunto de actividades y otros elementos asociados al tiempo (ciclo de vida) y a la consecución de uno o mas objetivos.

En Informática se le llama Proceso de Desarrollo de softfware.

CAL/Requerimientos

Gerente de ProyectoDocumentadorDiseñadorTester

HitosPlaneamiento

Testing

MBWAUse casesCRC cards

Modelo ObjetosPlan Proyecto

Modelo de Casos de Uso

Microsoft Project3month increments

UML Java

PrecisiónExactitud

Tolerancia

Team Values

Metodología : el quien, que, y cuando de interacciones clave

entre personas.

Actividades

Técnicas

Tools Habilidades

Roles

Estándares

Calidad Equipo

Artefactos

Microsoft ProjectSofware Through Pictures

Envy/Developer

ModelingJava programming

JAD facilitation

CAL/Requerimientos

Ciclo de Vida

Mas información sobre ciclo de vida ver: SEI Interactive,  http://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htm

CAL/Requerimientos

Dimensiones La dimensión horizontal representa

el tiempo y muestra los aspectos del ciclo de vida del proceso.

La dimensión vertical representa las disciplinas nucleo del proceso (o flujos de trabajo), que agrupan actividades de ingeniería de software por su naturaleza.

CAL/Requerimientos

Dimensión horizontal La dimensión horizontal representa

los aspectos dinámicos en términos de ciclos, fases, iteraciones y milestones (hitos). Un producto de software se diseña y construye en una sucesión de iteraciones incrementales. Permitiendo la prueba y validación así como el mitigar los riesgos.

CAL/Requerimientos

Dimensión Vertical

Representa los aspectos estáticos del proceso descritos en términos de componentes de procesos: Actividades, disciplinas, artefactos y roles.

CAL/Requerimientos

Ciclo de Vida Cascada

Ciclo de vida tradicional, en el que se debía terminar una tarea para continuar otra. El desarrollo del software se hacía de una sola vez.

CAL/Requerimientos

El desarrollo de Software se construye en una sucesión de iteraciones

Ciclo de Vida Iterativo

CAL/Requerimientos

Sucesión de iteraciones incrementales

Artefactos : Producto del trabajo

CAL/Requerimientos

Ciclo de desarrollo Una pasada a través de las cuatro fases es un ciclo de

desarrollo; cada paso a través de las cuatro fases produce una generación de software.

CAL/Requerimientos

Releases

Cada Iteración en una fase resulta en un release ejecutable del sistema

CAL/Requerimientos

Iteración

Una iteración lleva cabo el desarrollo de actividades que conducen a producir un release del producto – una versión del producto ejecutable, estable, junto a otro conjunto de elementos periféricos necesarios para usar este release.

Es como una pequeña cascada. Un release puede ser interno o

externo.

CAL/Requerimientos

Hitos La elección de los hitos del ciclo

de vida debería reflejar el mismo enfoque (iterativo incremental).

Las cuatro fases se concentran en remover las incertidumbres y por lo tanto manejar el acuerdo con el stakeholder de que los riesgos sean eliminados.

CAL/Requerimientos

Desarrollo Iterativo

El uso del ciclo de vida iterativo es mejor al cascada por muchas razones: Nos permite estar al tanto de cambios en

los requerimientos. La verdad es que los requerimientos usualmente cambian.

La integración no debe ser un “big bang” al final; los elementos deben intregrarse progresivamente en el tiempo.

CAL/Requerimientos

Desarrollo Iterativo

Los riesgos, normalmente, se descubren y tratan durante la integración. Con este enfoque se pueden mitigar mas temprano.

El desarrollo interativo proporciona un medio al gerente, para hacer cambios tácticos al producto.

CAL/Requerimientos

Desarrollo Iterativo Facilita el reuso; es mas fácil

identificar partes comunes diseñadas o implementadas parcialmente que reconocerlas durante el planeamiento.

El proceso de desarrollo en si puede ser mejorado y refinado.

CAL/Requerimientos

Inception : Creación La primera fase inception (creación) se

enfoca en el espacio del problema: determinando lo que el sistema necesita para ser entregado, sus límites, interacciones, servicios, y asi sucesivamente. La fase se completa cuando todos los stakeholders estan de acuerdo con la descripción del sistema.

Definimos una “visión” del producto final y los casos de uso del negocio asociados, definiendo el alcance global del proyecto.

CAL/Requerimientos

Incepción (creación)

Trabajos ejecutados en esta fase

CAL/Requerimientos

Elaboración La segunda fase Elaboración se enfoca

en identificar una arquitectura robusta para lograr satisfacre las necesidades del stakeholder.

Se refina la definción del producto, se define y se establece una línea base de arquitectura y se desarrolla un plan mas preciso para su desarrollo y despliegue.

CAL/Requerimientos

Elaboración

CAL/Requerimientos

Arquitectura

Es el nivel conceptual de mas alto nivel de un sistema y su ambiente (IEEE). La arquitectura de un sistema de software (en un momento dado del tiempo), es su organización o estructura de componentes significativos que interactúan a través de interfaces, cuyos componentes estan a su vez compuestos de componentes mas pequeños e interfaces

CAL/Requerimientos

Arquitectura Estructura organizativa de un

sistema: una arquitectura puede descomponerse recursivamente en partes que interactúan a través de interfaces, vínculos y partes conectadas y restricciones para el ensamble de sus partes. Partes que interactúan a través de una interface incluye: clases, componentes y subsistemas.

CAL/Requerimientos

Criterios de evaluación - Elaboración

¿La visión del producto es estable? ¿La arquitectura es estable? ¿Las demostraciones ejecutables,

muestran que los principales elementos de riesgo han sido considerado y resueltos?

¿Está el plan de construcción suficientemente detallado, tiene una base creible de estimados?.

CAL/Requerimientos

¿Todos los stakeholder concuerdan que la visión actual se puede lograr si se ejecuta el plan para desarrollar el sistema completo, en el contexto de la arquitectura?.

¿Son aceptables los gastos en recursos actuales versus los planeados?.

Criterios de evaluación - Elaboración

CAL/Requerimientos

Construcción

La tercera fase, construcción, se enfoca en la construcción incremental del sistema que elimine los riesgos para una entrega exitosa.

Cada una de las iteraciones en esta fase proporcionan mas capacidad que la anterior y por lo tanto puede pasar por mas pruebas del sistema.

CAL/Requerimientos

Construcción

CAL/Requerimientos

Transición

La cuarta fase, transición, concluye con la adopción exitosa del sistema.

El producto es entregado a la comunidad de usuarios; incluye manufactura, entrenamiento, soporte, entrega y mantenimiento del producto.

CAL/Requerimientos

Transición Objetivos:

Lograr que el usuario sea autosuficiente. Lograr el producto tan rápido y efectivo

en costo como sea practico. Actividades:

Hacer el despliegue de ingeniería del producto, empaque, entrenamiento del personal de campo, ventas.

Actividades de afinamiento.

CAL/Requerimientos

Participantes Equipo Roles

System Analyst

User-Interface Designer

Use case Specifier

System Integrator

Integration Tester

System Tester

Test Engineer

Requerimientos

Implementación

Test

Análisis

Use case Engineer

Architect

Diseño Component Engineer

CAL/Requerimientos

Gestión de Requerimientos

Necesidades

Características

Problema

Producto a Desarrollar

Dominio delProblema

Dominio de laSolución

Requerimientos de SwProcedimientos de Prueba

Traz

abili

dad

CAL/Requerimientos

El problema es Describir el problema

Afecta Describir los stakeholders afectados por el problema.

Impacta en Describir cual es el impacto del problema

Una solución exitosa sería

Beneficios clave de la solución propuesta.

Visión : Problema

CAL/Requerimientos

El problema es Solución inadecuada y fuera de tiempo de servicios al cliente.

Afecta a Nuestros clientes, representantes de soporte al cliente y técnicos de servicio.

Impacta en Insatisfacción del cliente, percepción de falta de calidad, empleados descontentos y pérdida de ingresos.

Una solución exitosa sería

Proporcionar acceso en tiempo real a una base de datos de problemas por parte de los representantes de soporte (help desk) y facilitar el despacho de técnicos de servicio a tiempo, solo a aquellas localidades que necesitan atender.

Visión : Problema - ejemplo

CAL/Requerimientos

Visión : Producto 

Para Cliente Objetivo

Quien Describir la necesidad u oportunidad

El Describir el nombre del producto o una categoría de productos.

Que Nombre los beneficios clave, razón para efectuar la compra o desarrollo.

A diferencia de

Alternativas de competencia principales

Nuestro producto

Diferencia(s) principal(es).

CAL/Requerimientos

Para Actuales clientes de contabilidad

Quien Requieren acceso instantáneo a sus cuentas en detalle y a los fondos que ellos contienen,

El Super ATM es una máquina cajera automática.

Que Proporciona la capacidad de ejecutar una simple transacción bancaria.

A diferencia de

Acceder a fondos y detalle a través de una oficina sucursal.

Nuestro producto

Está disponible las 24 horas del día y no necesita asistencia de empleados.

 Visión : Producto - Ejemplo