I
M b lT
2 k4
2k7
UNIDAD 2: CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN Y LOS SISTEMAS DE SOFTWARE l os Sistemas de Información Ciclo de vida de los Componentes del Sistema de Información Proceso de desarrollo de los Sistemas Modelos de procesos de desarrollo del software Metodologías: estructurada y orientada a objetos
UNIDAD 2: CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN Y LOS SISTEMAS DE SOFTWARE l os Sistemas de Información Ciclo de vida de los Componentes del Sistema de Información Proceso de desarrollo de los Sistemas Modelos de procesos de desarrollo del software Metodologías: estructurada y orientada a objetos
BIBLIOGRAFÍA [1] Kendall & Kendall. Análisis y Diseño de Sistemas. Prentice Hall. 6ta.
Ed. o
Capítulo 1: El rol del analista
[2] Somme Sommervill rville e Ian. Ingeniería del Software. Prentice Hall. 7ta. Ed. o
Capítulo 2: Sistemas Socio-Técnicos Socio-Técnicos
o
Capítulo 4: Procesos del Software
D ESPUÉS ESPUÉS DE LA CLASE UDS. PODRÁN…
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
CICLO DE VIDA PARA LOS SISTEMAS DE INFORMACIÓN
Desde el punto de vista de los Sistemas de Información, el
ciclo de vida es el conjunto de fases [o procesos] por las que pasa el sistema desde que se concibe [o inicio], se desarrolla hasta que se retira del servicio finalizando su uso [desmantelamiento del sistema]. Las fases o procesos están estandarizados de manera que
puedan ser adaptados a las necesidades de quién lo use. El estándar para el ciclo de vida de los sistemas de
información es el ISO/IEC 12207.
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
¿Q UÉ ES UN ESTÁNDAR? Un estándar es un documento establecido por consenso,
aprobado por un organismo reconocido, y que ofrece reglas, guías o características para que se use repetidamente. Especifican qué hacer no cómo hacerlo.
Organización internacional de estandarización (International Organization for Standardization)
Comisión Electrónica Internacional
ESTÁNDAR ISO/IEC 12207 PARA EL CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
Las actividades asociadas al ciclo de vida del desarrollo de los SI son continuas. Conforme se construye el sistema, el proyecto tiene cronogramas y fechas límite, hasta que el sistema se instale y acepte. La vida del sistema continúa mientras se mantiene y revisa. Si el sistema necesita sustituirse debido a una nueva generación de tecnología, o si las necesidades de los Sistemas de Información de la organización cambian significativamente, el sistema puede desmantelarse y se iniciará un nuevo proyecto y el ciclo comenzará de nuevo.
CICLO DE VIDA
No hay un acuerdo en la cantidad de fases que incluye el ciclo de vida del desarrollo de sistemas
Kendall y Kendall divide el ciclo de vida del desarrollo en siete fases las cuales se pueden observar en la siguiente figura:
PROCESO DE INGENIERÍA EN SISTEMAS
Este tema se completará en la próxima clase
PROCESO DE INGENIERÍA EN SISTEMAS
Sommerville, enfoca el ciclo de vida del sistema como el Proceso de la Ingeniería de Sistemas
ETAPA DEFINICIÓN DE REQUERIMIENTOS
Involucra a la fase Análisis de Sistemas Se especifica qué es lo que el sistema debe hacer,
es decir: • • •
Las funciones que el sistema debe proporcionar El comportamiento o propiedades esenciales y deseables La relación del sistema con otros sistemas de información
Para lograrlo se consulta con los clientes y usuarios
finales del sistema
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
IMPORTANCIA DEL CICLO DE VIDA DE DESARROLLO El Ciclo de Vida de Desarrollo de Sistemas sirve de base
de los procesos utilizados para desarrollar un sistema de información. Es conveniente seleccionar una metodología de trabajo porque: construir un sistema socio-técnico es una actividad compleja
que requiere un gran esfuerzo sobre todo de las personas. el sistema tiene un conjunto de componentes como el software, hardware, datos, documentos, redes, etc., los cuales debemos gestionar. las personas que interactúan entre sí, tienen diferentes grados de conocimiento, asumen diferentes roles y poseen diferentes intereses hacia el sistema. definir un marco de trabajo nos permite organizar el proceso de desarrollo definiendo pautas a seguir y restricciones a cumplir.
Las personas interactúan entre sí, con diferentes grados de conocimiento, con diferentes roles y con diferentes intereses.
Clientes Proveen las necesidades
Obtienen y Capturan las necesidades
Adoptar
Ingenieros en Sistemas Especifican Requisitos
Basado en Ciclo de Vida
Elegimos un marco de trabajo que nos permita organizar el proceso de desarrollo
Tenemos que ordenar nuestro trabajo para planificar el proceso de desarrollo
Implementan Requisitos Desarrollar
Equipo de Desarrollo
Construir Sistemas de Información socio-técnicos requiere un gran esfuerzo sobre todo de las personas
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
¿Q UÉ ES UN PROCESO DE DESARROLLO DEL SOFTWARE? Un proceso de desarrollo del software es un conjunto
completo de actividades y resultados asociados necesarios para transformar los requerimientos de un cliente / usuario en un producto o sistema.
Ingeniería del software, Sommerville, cap. 1
ACTIVIDADES COMUNES A LOS PROCESOS DE DESARROLLO DEL SOFTWARE Existen cuatro actividades fundamentales comunes
para todos los procesos de desarrollo:
¿Q UÉ ES UN MODELO DE PROCESO DE DESARROLLO DEL SOFTWARE? Un modelo de proceso es una descripción simplificada
de un proceso del software que presenta una visión de ese proceso. El modelo de proceso define el ciclo de vida que se adoptará para el proyecto de sistemas. Los modelos de proceso pueden incluir: Flujo de trabajo: muestra la secuencia de actividades en el proceso con sus entradas, salidas y dependencias. Las actividades representan acciones humanas. Flujo de documentos: muestra los documentos o artefactos que producen cada una de las actividades y cómo esos documentos se transforman por acción de las personas o por las computadoras. Modelo de rol/acción: representa los roles de las personas involucradas en el proceso del software y las actividades de ls que son responsables Ingeniería del software, Sommerville, cap. 1
MODELO DE PROCESOS DE DESARROLLO DEL SOFTWARE Un modelo de rol/acción: representa los roles de las personas involucradas en el proceso del software y las actividades de las que son responsables.
Rol El flujo de documentos: muestra los documentos o artefactos que producen cada una de las actividades y cómo esos documentos se transforman por acción de las personas o por las computadoras.
Flujo de trabajo 1
2 Actividades
El flujo de trabajo: muestra la secuencia de actividades en el proceso con sus entradas, salidas y dependencias. Las actividades representan acciones humanas.
AGENDA DE TEMAS Definición de ciclo de vida de los Sistemas de Información El ciclo de vida de los sistemas de información según el
estándar ISO/IEC 12207 Las actividades del ciclo de vida del desarrollo de los
sistemas de información Importancia del ciclo de vida para el trabajo de los ingenieros en
sistemas
Modelos de proceso de desarrollo del Software Modelo en Cascada Modelo Evolutivo Modelo en Espiral
MODELOS DE PROCESOS DE DESARROLLO DEL SOFTWARE
Modelo en Cascada
Modelo Evolutivo
Modelo en Espiral
MODELO EN CASCADA Modelo en cascada – Conocido también como: Modelo lineal secuencial o Ciclo de vida del software
Definición de Requerimientos
Diseño del Software y del Sistema
Implementación y Prueba de unidades
Flujo de trabajo Integración y Prueba del Sistema
Operación y Mantenimiento
MODELO EN CASCADA Modelo en cascada – Conocido también como: Modelo lineal secuencial o Ciclo de vida del software
Definición de Requerimientos
Diseño del Software y del Sistema
Implementación y Prueba de unidades
Flujo de trabajo Integración y Prueba del Sistema
Operación y Mantenimiento
MODELO EN CASCADA Modelo en cascada – Conocido también como: Modelo lineal secuencial o Ciclo de vida del software
Definición de Requerimientos
Diseño del Software y del Sistema
Implementación y Prueba de unidades
Flujo de trabajo Integración y Prueba del Sistema
Operación y Mantenimiento
MODELO EN CASCADA FLUJO DE DOCUMENTOS Especificación de Requerimientos Definición de Requerimientos
Especificación del Diseño Diseño del Software y del Sistema
Código fuente y pruebas Implementación y Prueba de unidades
Flujo de trabajo Integración y Prueba del Sistema
Diseño y resultado de pruebas
Operación y Mantenimiento
Cambio
MODELO EN CASCADA ROLES POR CADA FASE
Definición de Requerimientos •
Analista de Sistemas • •
Diseño del Software y del Sistema
Diseñador de Sistemas Arquitecto de Sistemas • •
Implementación y Prueba de unidades
Programador Ingeniero de pruebas o tester
Integración y Prueba del Sistema
•
Integrador de Sistema
•
Ingeniero de pruebas de Sistema •
Ingeniero de soporte y cambios
Operación y Mantenimiento
MODELO EN CASCADA Modelo en cascada – Conocido también como: Modelo lineal secuencial o Ciclo de vida del software
Definición de Requerimientos
Diseño del Software y del Sistema
Implementación y Prueba de unidades
Integración y Prueba del Sistema
Operación y Mantenimiento
MODELO EN CASCADA
•
Este modelo refleja un desarrollo marcado por la sucesión escalonada de las etapas que lo componen : Análisis de requerimientos, diseño, codificación, pruebas e implementación
•
Es necesario terminar por completo cada fase para pasar a la siguiente
•
Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchas veces resulta difícil poder disponer de requisitos completos o del diseño pormenorizado del sistema en las fases iniciales, creando una barrera que impide avanzar
MODELO EN CASCADA DESVENTAJAS Los proyectos reales raras veces siguen el desarrollo
secuencial que propone el modelo en cascada.
Los cambios pueden causar confusión cuando el equipo de
desarrollo comienza a trabajar.
A menudo es difícil que el cliente exponga explícitamente
todos los requisitos. El modelo en cascada así lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos.
El cliente debe tener paciencia. Una versión de trabajo del
(los) programa(s) no estará disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.
MODELO EN CASCADA VENTAJAS Produce sistemas bien documentados susceptibles de
cambios fundamentalmente por la separación del diseño y la implementación. Funciona bien para proyectos pequeños donde los
requisitos están bien entendidos. Es un modelo en el que todo el trabajo está bien organizado
y no se mezclan las fases. Es simple y fácil de usar. Es el modelo de proceso más antiguo y utilizado para el
desarrollo de aplicaciones de software
MODELO EN CASCADA
¿CUÁNDO ES CONVENIENTE UTILIZARLO? El modelo en cascada se utiliza preferentemente cuando: Las necesidades del cliente y los requerimientos del
sistema se comprenden y están completamente definidos y conocidos de antemano.
Es
poco probable el pedido de cambio en los requerimientos.
El equipo de trabajo no tiene experiencia en el desarrollo
de sistemas.
El sistema requiere documentación detallada de cada
una de las fases.
MODELOS DE PROCESOS DE DESARROLLO DEL SOFTWARE
Modelo en Cascada
Modelo Evolutivo
Modelo en Espiral
MODELO EVOLUTIVO
Actividades Concurrentes
Especificación
Esbozo del sistema
Desarrollo
Validación
Versión Inicial del sistema
Versiones Intermedias del sistema
Versión Final del sistema
MODELO EVOLUTIVO Las actividades de especificación, desarrollo y validación son
concurrentes.
No existe una especificación detallada del sistema y la
documentación se minimiza.
El sistema se desarrolla en una serie de incrementos o
versiones añadiendo funcionalidad a las anteriores.
Las versiones se muestran a los clientes y otros stakeholders
para que ellos las evalúen y propongan cambios y se continúa así hasta agotar el tiempo, el presupuesto o hasta que el cliente esté satisfecho.
MODELO EVOLUTIVO
Prototipos del sistema
•
Prototipo exploratorio –
•
El objetivo es trabajar con clientes hasta evolucionar a un sistema final, a partir de una especificación inicial. Se debe comenzar con unas especificaciones bien entendidas.
Prototipo desechable o “throw-away”. –
El objetivo es entender los requerimientos del sistema. Se puede comenzar con especificaciones poco entendidas resolviendo las incertidumbres
MODELO EVOLUTIVO VENTAJAS Continua revisión por parte del cliente Los clientes pueden validar las versiones del sistema y de esta forma, dado que se inicia el trabajo con un esbozo del sistema, los posibles fallos conceptuales u otros posibles motivos de disconformidad por parte del cliente pueden ser detectados antes de que se impliquen cambios en el sistema. Permite cambios de requerimientos Permite la modificación de requerimientos sobre la marcha, y una mayor implicación por parte del cliente en las pruebas y validación de requerimientos
MODELO EVOLUTIVO DESVENTAJAS Desde la perspectiva de ingeniería y gestión, el modelo evolutivo tiene las siguientes desventajas: El proceso no es visible Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.
A menudo los sistemas tienen una estructura
deficiente
Origina un software que puede estar débilmente estructurado y difícil de comprender y mantener. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.
MODELO EVOLUTIVO
¿CUÁNDO ES CONVENIENTE UTILIZARLO? El modelo evolutivo se utiliza preferentemente
cuando: Se
desarrollan sistemas pequeños y tamaño medio (hasta 500.000 líneas de código). Es necesario resolver incertidumbres en la especificación del sistema. No
se recomienda para sistemas grandes, complejos y con período de vida largo donde diferentes equipos desarrollan distintas partes del sistema. Es difícil establecer una arquitectura estable del sistema
MODELOS DE PROCESOS DE DESARROLLO DEL SOFTWARE
Modelo en Cascada
Modelo Evolutivo
Modelo en Espiral
MODELO EN ESPIRAL EL Modelo Espiral, propuesto en 1988 por Barry Boehm. El modelo reconoce la naturaleza iterativa del desarrollo y combina
actividades de desarrollo con gestión de riesgo, para minimizar y controlar el riesgo.
El modelo divide el desarrollo en cuatro regiones o sectores:
1- determinar objetivos, alternativas y restricciones 2- evaluar alternativas, identificar y resolver los riesgos 3- desarrollar, verificar el producto del siguiente nivel 4- planificar las siguientes fases. Cada una de las regiones están compuestas por un conjunto de tareas las
cuales se adaptan a las características del proyecto que va a emprenderse.
Ejemplo de tareas: Análisis de sistemas, Diseño de Sistemas, Construcción
de programas, Pruebas, Mantenimiento.
MODELO EN ESPIRAL
1- Determinar objetivos. alternativos y restricciones
4- Planificar la siguiente fase
2- Evaluar alternativas, identificar y resolver riesgos
3- Desarrollar y verificar
MODELO EN ESPIRAL ¿Q UÉ SE REALIZA EN LA 1° ITERACIÓN? Cada ciclo o iteración en la espiral representa una fase del proceso de desarrollo del software. El ciclo más interno, 1° iteración, podría referirse a un estudio
de la viabilidad del sistema, es decir que incluye por ejemplo: el presupuesto: la viabilidad económica del proyecto un cronograma inicial de desarrollo con un Diagrama de Gantt restricciones tecnológicas [Hardware y Software] alternativas para el personal
MODELO EN ESPIRAL ¿Q UÉ SE REALIZA EN LA 1° ITERACIÓN? Luego se evalúan riesgos del proyecto y se construye
prototipos de las alternativas y la simulación [ es la segunda región de la espiral ].
Después se escribe un documento con el "concepto de las
operaciones“, el cual describe la funcionalidad del sistema en un nivel alto, desde el punto de vista del usuario [es la tercera región de la espiral].
El
“Concepto de las operaciones” es el documento produce la primera iteración.
que
MODELO EN ESPIRAL
2- Evaluar alternativas, identificar y resolver riesgos
1- Determinar objetivos. alternativos y restricciones
Análisis de Riesgos Prototipos
Inicio 1° iteración o ciclo [ Estudio de viabilidad ]
4- Planificar la siguiente fase
Plan
Concepto
Fin
Concepto de las operaciones
3- Desarrollar y verificar
MODELO EN ESPIRAL
ACCIONES COMUNES A TODAS LAS ITERACIONES En cada iteración o ciclo de la espiral se hace un análisis de
riesgo de las alternativas según los requisitos y restricciones.
Se construyen prototipos para analizar las alternativas y
seleccionar una.
Los prototipos pueden ser simples maquetas en papel,
prototipos de interfaz de usuario o simulaciones del sistema, dependiendo del riesgo a evaluar, según el ciclo en el proceso y del tipo de aplicación.
Cada vez que se pasa por la región de planificación de ajusta el
costo y el calendario del proyecto.
MODELO EN ESPIRAL
¿Q UÉ SE REALIZA EN CADA ITERACIÓN? En la segunda iteración, una vez que se han evaluado los
riesgos y se decide continuar con el proyecto, se planifica definición de los requerimientos que se realizará en la siguiente fase del proceso [es la cuarta región de la espiral].
A partir del documento “Concepto de las operaciones”, en la
segunda iteración se realiza el proceso de definición de los requerimientos del sistema.
Los requerimientos del sistema son validados por el cliente
con los prototipos que evolucionan desde la 2° región.
Luego se escribe un documento denominado Especificación
de Requerimientos del Sistema.
MODELO EN ESPIRAL
1- Determinar objetivos. alternativos y restricciones
Análisis de Riesgos
2- Evaluar alternativas, identificar y resolver riesgos
Prototipos
Plan de RQ
2° iteración [ Definición de requerimientos ]
4- Planificar la siguiente fase
Inicio
Concepto
Requerimientos Validación de Requerimientos
Fin
3- Desarrollar y verificar Especificación de
MODELO EN ESPIRAL
¿Q UÉ SE REALIZA EN CADA ITERACIÓN? En la tercera iteración se hace un plan de desarrollo, y se
produce el Diseño del Sistema que es verificado y validado.
El la cuarta iteración se hace un plan de integración y prueba,
se genera el software y se realizan las pruebas de aceptación.
Se realiza la entrega y la puesta en servicio del sistema.
MODELO EN ESPIRAL
2- Evaluar alternativas, identificar y resolver riesgos
1- Determinar objetivos. alternativos y restricciones Análisis de Riesgos Prototipos Plan
Plan de integración y pruebas Plan de Desarrollo
Concepto Requerimientos
Diseño del producto
4- Planificar la siguiente fase Planificar siguiente fase
Diseño detallado
3- Desarrollar y verificar
MODELO EN ESPIRAL
1- Determinar objetivos. alternativos y restricciones
4- Planificar la siguiente fase
2- Evaluar alternativas, identificar y resolver riesgos
3- Desarrollar y verificar
MODELO EN ESPIRAL
MODELO EN ESPIRAL VENTAJAS Es un enfoque realista del desarrollo de Sistemas y de Software a gran
escala.
Utiliza la construcción de prototipos como mecanismo de reducción de
riesgos.
La construcción de prototipos facilita la validación de los requerimientos al
entregar versiones del sistema desde el final de la primera iteración.
El riesgo de sufrir retrasos en el proyecto es menor porque los problemas
se identifican en etapas tempranas y hay tiempo para subsanarlos.
El análisis del riesgo se hace de forma explícita y clara.
Utiliza el enfoque sistemático del modelo en cascada y el trabajo iterativo del modelo evolutivo, lo cual refleja de forma más realista la construcción del software.
