Class 1 - Ciclo de Vida

Ciclos de Vida &

Metodologías de Desarrollo de software

UNIVERSIDAD NACIONAL HERMILIO VALDIZANFACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS

EAP INGENIERÍA DE SISTEMAS

SESION 1 y 2

ConceptoEl software nace, crece y muere

Es su ciclo de vidaNace con sus requerimientos y diseñoCrece con su desarrollo y mantenimientoMuere cuando se reemplaza por otro

Software obsoleto

CICLO DE VIDA

Software ObsoletoRazones

Crecimiento de la empresaCambio de los requerimientos originales Número de usuarios Número de transaccionesDistribución del software

Cambio de operacionesAmpliaciónIntegración con otros sistemas

“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software”

IEEE 1074

“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso”

ISO 12207-1

CONCEPTO DE CICLO DE VIDA

Modelo de proceso: ISO 12207

Son las etapas para el desarrollo del software ¿Para que sirve?

Para la organización, planificación y gestión de personal, corrección de errores, distribución del tiempo.

Para saber la documentación q hay q presentar a los clientes.

Como base para determinar las herramientas ymetodológicas en las distintas actividades.

Software de más calidad. Permite planificar el trabajo

CICLO DE VIDA Vs MODELO DE PROCESO

CICLO DE VIDA DEL DESARROLLO DE SISTEMAS

CURSO: INGENIERÍA DE REQUERIMIENTOS

El Ciclo de Vida del Desarrollo de Sistemas

El CVDS es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo específico de actividades del analista y el usuario

1 .identificación del problema, oportunidades y objetivo.

2.Determinación de los requerimientos de información.

3 .Análisis de las necesidades del sistema.

4 .Diseño del sistema (recomendado).

5.Desarrollo y documentación del software.

6.Prueba y mantenimiento.

7.Implantación y evaluación del sistema.

CICLO DE VIDA

IDENTIFICACION DE PROBLEMAS OPORTUNIDADES Y OBJETIVOS:

Problemas:• Etapa crítica para el éxito del resto del proyecto.• Requiere de la observación honesta del analista s/el negocio.• Analista y personal hacen resaltar los problemas.

Oportunidades:• Situaciones que el analista cree que pueda ser mejores.• Permite que el negocio gane un avance competitivo que ponga un

estándar de la industria.

Objetivo:• Componente importante de la primera fase.• El ing. debe descubrir lo que está tratando de hacer el negocio.• El ing. será capaz de identificar si una aplicación de sistema de

información pude ayudar al sistema, negocio, a que alcance sus objetivos atacando problemas específicos y oportunidades.

INVOLUCRADOSUsuarios.Analista.Administradores de sistemas

ACTIVIDADES• Entrevista a los

administradores y usuarios.• Sumarización de

conocimientos adquiridos.• Estimación del alcance del

proyecto.• Documentación de

resultados.

RESULTADOS• Tomar la decisión se continúa

el proyecto propuesto. Si la empresa no cuenta con dinero.

• Se desea atacar problemas no relacionados. Problemas no automatizados.

• Recomendar una solución manual.

GENERAEstudio de factibilidad.Definición del problema.Sumarización de objetivos.

1ra. FaseIdentificación de

problemas y objetivos

PRIMERA FASEIDENTIFICACION DE PROBLEMAS OPORTUNIDADES Y OBJETIVOS

DETERMINACION DE LOS REQUERIMIENTOS DE INFORMACION

Herramientas: • Muestra e investigación de datos relevantes.• Entrevista.• Cuestionario.• Comportamiento de los tomadores de decisión.• Prototipos.

El Analista: Comprende que información necesitan los usuarios para trabajar.

Sirve: Para formar la imagen que el analista tiene de la organización y sus objetivos.

Involucrados:• Analista.• Usuarios.• Administradores de las operaciones.

SEGUNDA FASE

El analista necesita:Los detalles de las funciones actuales del sistema.

• ¿Quién? Personas• ¿Qué? Actividad del negocio• ¿Dónde? Ambiente• ¿Cuándo? En que momento• ¿Cómo? De que manera se desarrollo

Al término de la fase:El analista debe comprender el porque de los funciones del negocio.Tener informe sobre personas, objetivos y procedimientos.

Herramientas: técnicas para la recolección de datos.

DEFINICION• Proceso que sirve para

recopilar e interpretar los hechos.

• Diagnostica problemas y utiliza estos hechos para mejorar el sistema.

TOMA DE DECISION• Naturaleza de los

programas a construir.• Comprender ámbito o

enlace o alcance de la información a manejar.

• Función y protocolos requeridos.

• Documentar requisitos.

• Revisar con el cliente.

DEFINEPapel de cada elemento de cada parte del Sistema de Información.Asignar a la computadora el papel de desempeñar y en decir en que no tendrá inherencia.

QUIEN LO REALIZA

El analista.

3er. Análisis de las necesidades

del sistema

TERCERA FASEANALISIS DE LAS NECESIDADES DEL SISTEMA

ALCANCES• Analizar requisitos.• Determinar

requisitos.• Estimar costos.• Diferentes tareas.• Planificar por

programas.• Actividades. HERRAMIENTAS

•Diagrama de flujo de datos (E-PRO-S).

•Diccionario de datos.•Análisis de las decisiones (condiciones, acciones y reglas).

•Estructurados.•Semiestructurados (Árbol de decisión, tabla de decisión, Español estructurado).

•Criterios múltiples.• ……

PREPARA• Una propuesta del sistema

que sumará lo encontrado.• Análisis costo beneficio de

las alternativas.

PLANTEAMIENTO DEL PROBLEMA

FACTIBILIDADEconómica.Operativa.Técnica.

Análisis de las necesidades del

sistema.

(Tercera fase)ANALISIS DE LAS NECESIDADES DEL SISTEMA

Usa la información recolectada anteriormente para hacer el diseño lógico de S1 (pseudo código, DF, etc.).Diseña procedimientos precisos para la captura de datos (diseño de entradas).Proporciona entrada efectiva para el sistema de información mediante el uso de técnicas para el diseño de formas y pantallas• Diseña la interfaz del usuario (teclado, menú de pantalla y ratón)• Diseño de salidas• Diseño de base de datos• Diseño de archivo• Diseño de control y respaldo, etc.

Cuarta FaseDiseño Del Sistema (Recomendado).

OBJETIVO: Son las metas o fines hacia las cuales se quiere llegar. Es determinar los

resultados deseados ¿Qué es lo que se requiere?POLITICA: Son reglas que se establecen para dirigir funciones y seguir qué éstas se

desempeñen de acuerdo con los objetivos deseados (son guías para las toma de decisión).MISION: Es la función o tarea básica de una organización o individuo.ESTRATEGIA: Son planes, su función consiste en regir la obtención uso y disposición, de

los medios necesarios para alcanzar los objetivos.REGLAS: Describen con claridad las acciones especificas requeridas o las que no se

deben llevar acabo.Son aquellos que guían una acción sin especificar un orden de tiempo, de

hecho.NORMAS: Todo señalamiento imperativo de algo que ha de realizarse sea genérico o

específico.

Cuarta Fase

Las representaciones del diseño deben ser traducidas a un lenguaje artificial, dando como resultado unas instrucciones ejecutadas por la computadora el paso de la codificación es el que lleva acabo esa traducción.•IdentificarAmbiente operativoLógica de los programasElección del lenguaje de programación

•Tipo de documentaciónManual del usuarioManual de programaciónManual del sistema

•El analista trabaja con los programadores para desarrollar cualquier sw original que necesite.

(Quinta Fase)Desarrollo Y Documentación Del Software

6ª. FasePrueba y mantenimiento del

sistema.

CARACTERISTICASAntes de usar el software debe probarse.Disminuye problemas antes de la entrega del software.

TIPOSPrueba con datos de ejemplo.Prueba con datos reales del sistema.

FORMASProgramadores solo.Analistas y programadores.

MANTENIMIENTOEs efectuado a lo largo de la vida del sistema de información.

PRUEBA

Ojo: Muchos procedimientos sistemáticos que emplea el analista ayuda a mantener al mínimo los mantenimientos.

SEGURIDAD

Se desarrollan a lo largo del ciclo.Sirve para asegurar que toda información del software que este disponible.

Documentación Confiabilidad a usuarios.Debe seguir creciendo.

Tomar en cuenta:Prueba.Verificación y validación.Certificación confirmación que el programa esta bien hecho.

Importancia del mantenimiento. Los programas de computación deben ser modificados y mantenidos y actualizados. La cantidad promedio del tiempo y gastado en mantenimiento en una instalación del sistema de información gerencial (MIS) es de 40% al 60%.

CONTROL

RAZONES• Corregir errores del

SW para mejorar la capacidad del SW en respuesta a las necesidades de la organización.

• .

EVALUACION O REVISION (Después de la implantación)• Determinar si el

sistema cumple con las expectativas donde son necesarias las mejoras.

CONVERSION• Proceso de cambiar un

sistema a una nuevo.• Anticipar los problemas más

comunes:• Sistema paralelo.• Conversión directa.• Enfoque piloto.• Sistema por etapas.

CAPACITACION• Entrenamiento de los

usuarios para manejar el sistema.

• Involucra a los operadores y usuarios.

• Una mala capacitación puede producir errores de usuarios.

Séptima faseImplantación y evaluación del

sistema.

Sistemas II.

Su sistema definitivo

?

Y al final del ciclo de Desarrollo del software.....

El usuarioysuSistemaDefinitivo.

Su sistema

definitivo

Sistemas II.

Su sistema

definitivo


Esto no es lo que yo esperaba...

Sistemas II.



¿ Será que no supe explicarles mis requerimientos ?

Su sistema

definitivo

Sistemas II.



Tal vez ellos no me entendieron...

Su sistema

definitivo

Sistemas II.


?


Su sistema

definitivo

Sistemas II.

LA EXPERIENCIA DEMUESTRA QUE

No siempre se definen los requisitos en forma:

Completa

Correcta y

ConsistenteLos requerim

ientos

son:

Explicación complementaria

AnálisisEntrada

Conocimiento del dominio de la aplicación, actividades de los usuarios, mercado, etc.

ActividadesIdentificar las necesidades del usuarioAnálisis de viabilidadDeterminar los requerimientos de la aplicación

SalidaDocumento de requerimientos del software

DiseñoEntrada

Documento de requerimientos del softwareActividades

Establecer estrategia de soluciónAnálisis de alternativas. Formalizar la soluciónDescomponer y organizar la aplicaciónFijar descripciones de cada módulo

SalidaDocumento de diseño del softwareUML (Universal Modeling Language)

Codificación

EntradaDocumento de diseño del software

ActividadesCreación del código fuentePruebas de unidades

SalidaCódigo de módulos, probado

Integración. ValidaciónEntrada

Código de módulos, probadoDocumento de requerimientos del software (validación)

ActividadesPruebas de integraciónPruebas de validación

SalidaAplicación completa, lista para usar

MantenimientoEntrada

Software listo para usarActividades

InstalaciónUso en paraleloImplementaciónNuevos requerimientos, correcciones y modificacionesSoporte de usuarios

SalidaAplicación respondiendo a las necesidades actuales

Modelo en CascadaInconveniencias

Rígido, difícil de rectificarDocumentación inicial se vuelve obsoleta

Desarrollo evolutivoCiclo de vida en espiralUso de prototipos (de diversa fidelidad)Extreme ProgrammingRAD (Rappid Application Development)

Cambia el proceso pero no las actividades

Primer Modelo de Ciclo de vida

ActividadesModelo en cascada

Análisis

Diseño

Codificación

Integración

Mantenimiento

1. Modelo Incremental Se evitan proyectos largos y se entrega “Algo de valor” a

los usuarios con cierta frecuencia El usuario se involucra más Difícil de evaluar el coste total Difícil de aplicar a sistemas transaccionales que tienden

a ser integrados y a operar como un todo Requiere gestores experimentados Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo

Modelos de Ciclo de vida que usa Procesos Unificados

Modelo Incremental

CICLO DE VIDA INCREMENTALEn cada incremento se entrega una parte completamente funcional. Cada nuevo incremento se realiza sobre el anterior. La práctica de 2º es claramente incremental

2. Modelo Iterativo• Consiste en la iteración de varios ciclos de vida en

cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto.

• El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras.

• Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente.

Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

Ventajas

• Una de las principales ventajas que ofrece este modelo es que no hace falta que los requisitos estén totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando en cada una de las iteraciones.

• Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo en pequeños ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregas…

Inconvenientes

• La primera de las ventajas que ofrece este modelo, el no ser necesario tener los requisitos definidos desde el principio, puede verse también como un inconveniente ya que pueden surgir problemas relacionados con la arquitectura.

2. MODELO DE CICLO DE VIDA ITERATIVOEn el caso del iterativo se mejoran los requisitos (más genéricos a más específicos). Puede verse como uno en cascada con una funcionalidad básica, agregando funcionalidad en la etapa de mantenimiento. Existe unas tareas de análisis y diseño comunes y posteriormente Diseño detallado y codificación para cada iteración.

COMPARATIVA CICLO DE VIDA INCREMENTAL E ITERATIVO

METODOLOGÍA ORIENTADO A OBJETOS

Son iterativas e incrementales Fácil de dividir el sistema en varios

subsistemas independientes Se fomenta la reutilización de componentes

El proceso unificado de desarrollo de software

CICLO DE VIDA

PARTE DINÁMICA

INTERFAZ

PARTE ESTÁTICA

Debe ofrecer un marco de trabajo

genérico

• Es un proceso ORIENTADO A OBJETOS• El proceso es:

• Guiado por casos de uso • Centrado en la arquitectura• Con un ciclo de vida iterativo e incremental

El proceso unificado de desarrollo de software

• El Proceso Unificado de Desarrollo usa UML

PROCESO UNIFICADO DE DESARROLLO DE RATIONAL

UML

Herramientas Proceso

Notación

• RATIONAL ROSE• VISIO

Desarrollo Iterativo e Incremental Esta idea es la base de varios métodos de desarrollo

de software como RUP (Rational Unified Proecess), Extreme Programming y otros métodos de desarrollo ágiles.

La idea básica es desarrollar el sistema siguiendo etapas incrementales caracterizadas por generación de sucesivas versiones que van abarcando requerimientos hasta completar el sistema.

Cada versión tiene sentido para el cliente.

Principales metodologías en el tiempo

Tiempo

Inicialmente se usó el Modelo

Tradicional de Cascada

1980

Definición de Requerimientos

Análisis & Diseño

Implementación y Test Unitarios

Construcción/Pruebas

t

t

Iteración 1 Iteración 2 Iteración 3

P

CA&D

R

P

CA&D

R

P

CA&D

R

Modelo Iterativo Incremental1990

Integración ytest del sistema

Operación y mantención

1. Guiado por casos de uso

Los sistemas se crean para dar servicio a los usuarios.

Qué REQUISITOS se necesitanUn CASO de USO es una pieza de FUNCIONALIDAD de un sistema que le proporciona a algún USUARIO un RESULTADO o VALOR.

Casos de uso

Todos juntos constituyen el modelo de casos de uso (MCU)

FUNCIONALIDAD COMPLETA

PARA TODOS LOS USUARIOS

Persona

SocioTrabajadorBiblio

EncargadoBiblio

Consultar Catálogo

Tomar PréstamoRevista

Devolver Revista

Tomar Préstamo Copia Libro

Reservar Libro

Extender Préstamo

Devolver Copia Libro

Actualizar Catálogo

<<includes>>

<<extends>>

- No disponible

<<extends>>

- No reservado

EJEMPLO DE MODELO DE CASOS DE USO

Desarrollo guiado por casos de uso (CU)

LOS CASOS DE USO:CAPTURAN REQUISITOSSE ESPECIFICAN (ANALIZAN)SE DISEÑANSE IMPLEMENTANY SE PRUEBAN

Persona

Tomar Préstamo

: IU-1 : GestorLibro : Libro elLibro:Libro

1: Introducir Signatura y NumeroDeSocio

2: Aceptar

3: obtenerLibro(signaturaLibro:String)

4: getSignatura()

Se repite hasta que seencuentre un libro

con la signatura que estamos buscando

elLibro

5: getCopias()

6: isCopiaPrestada()

3.- DISEÑO DEL CASO DE USO

4.- IMPLEMENTACIÓN DEL CASO DE USO

5.- PRUEBA DEL CASO DE USO

2.- ANÁLISIS DEL CASO DE USO

1.- CASO DE USO Desarrollo guiado por CASOS DE USO

2. Centrado en la arquitectura

La arquitectura de un sistema software es un extracto de los modelos del sistema

Extracto: VISTA DE CADA MODELOque da una idea de qué forma que tiene el sistema completo

1

: IU-1 : Gro

:1:2: 3: 4

()

: : Gro

:1:2: 3: 4

()

Centrado en la ARQUITECTURA

VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO /

VISTA DEL DIAGRAMA DE CLASES

VISTA DEL MODELO DEL ANÁLISISVISTA DEL MODELO DEL DISEÑO

+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS

SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS).

SÓLO APARECEN LOS QUE CORRESPONDEN

A CASOS DE USOS CRÍTICOS

3. Ciclo de vida iterativo e incrementalITERATIVO

Se repiten VARIOS MINIPROYECTOSINCREMENTAL

Cada miniproyecto AMPLIA EL PRODUCTO

Class 1 - Ciclo de Vida

Documents

Transcript of Class 1 - Ciclo de Vida