1

CICLO DE VIDA

2

Sistemas II.

CICLO DE VIDA DECICLO DE VIDA DE

Los Sistemas de InformaciónLos Sistemas de Información

• “Es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de información y aplicaciones informáticas”. (Whitten J., Bentley L., Barlow V. 1996)

3EL DESARROLLO DESISTEMAS DE INFORMACION

Ciclo de Vida = Ciclo de Desarrollo + Mantenimiento

Sistemas II.

MetodologíasMetodologías

1. ESTRUCTURADA. 2. ORIENTADO A OBJETO

4

EL CICLO TRADICIONAL DE LOS S.I.

FASE 1

FASE 2

FASE 3

FASE N

FASE N + 1

Desarro

llo e

Implem

entac

ión FASES

QUE VARIAN DE

AUTOR

ENAUTOR

5

Sistemas II.

MODELOS PARA EL CICLO DE VIDA MODELOS PARA EL CICLO DE VIDA DE DESARROLLO DE SOFTWAREDE DESARROLLO DE SOFTWARE

CASCADA ESTRUCTURADO ESPIRAL PROPTOTIPO

MODELOS

•Análisis de requerimientos•Especificaciones.•Diseño.•Implementación.•Prueba•Mantenimiento.

•Encuesta•Análisis.•Diseño.•Implantación..•Pruebas•Control de calidad.•Procedimientos.•Conversión B.D.•Instalación.

•Requerimientos.•Análisis de riesgo.•Prototipo 1, 2.•Req. software•Validación de Req.•Análisis de riesgo.•Prototipo 3.•Diseño software.•Validación diseño.• Integración y prueba.

• Requerim. Básicos•Desarr. Prot. oper.•Uso prot.•Usuario satisfecho?. Si. Aceptar. No. Revisar y mejorar.

6

Sistemas II.

CICLO DE VIDA TRADICIONALCICLO DE VIDA TRADICIONAL

Los Sistemas de InformaciónLos Sistemas de InformaciónDefinición

delProyecto

Estudiode

Sistemas

Diseño

Programación

Instalación

PosimplantaciónLaudon y Laudon. 1996

Auditoría.

Pruebas

Código.

Especificaciones.

Propuesta sistema.

Propuesta.

PRODUCTOS.

7

EL CICLO DE VIDA SEGÚN BIBLIOGRAFÍA

FABREGAS:FABREGAS:

1- Requerimientos2- Análisis/Diseño3- Construcción4- Pruebas5- Producción/Mantenimiento

SENN:SENN:

1- Investigación Preliminar2- Determ. de Requerimientos.3- Diseño del Sistema4- Desarrollo del Software5- Prueba del Sistema6- Implantación y Evaluación

PRESSMAN:PRESSMAN:

1- Análisis 2- Diseño3- Codificación4- Prueba5- Mantenimiento

EN GENERAL EN GENERAL USAREMOSUSAREMOS:

1- Análisis2- Diseño3- Implementación4- Mantenimiento

8CARACTERISTICAS DEL CICLO DE VIDA

CLASICO

• Implantación Ascendente

• Las fases deben sucederse de manera Secuencial

• El usuario no ve resultados, sino hasta el final

• El usuario o el ambiente pueden cambiar las especificaciones originales del sistema.

• Presenta numerosos problemas Analista-Usuario

• Manejable como proyecto

9

EL CICLO TRADICIONAL DE LOS S.I.

EL USUARIO:

FASE 1

FASE 2

FASE 3

FASE N

FASE N + 1

10

Sistemas II.

Su sistema definitivo

?

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

El usuarioysuSistemaDefinitivo.

Su sistema

definitivo

11

Sistemas II.

Su sistema

definitivo

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

Esto no es lo que yo esperaba...

12

Sistemas II.

Su sistema definitivo

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

¿ Será que no supe explicarles mis requerimientos ?

Su sistema

definitivo

13

Sistemas II.

Su sistema definitivo

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

Tal vez ellos no me entendieron...

Su sistema

definitivo

14

Sistemas II.

Su sistema definitivo

?

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

Su sistema

definitivo

15Los Requerimientos y su importancia en el desarrollo del Software 

16Los Requerimientos y su importancia en el desarrollo del Software 

17Los Requerimientos y su importancia en el desarrollo del Software 

18Los Requerimientos y su importancia en el desarrollo del Software 

19

Sistemas II.

LA EXPERIENCIA DEMUESTRA QUE

No siempre se definen los requerimientos en forma:

Completa

Correcta y

ConsistenteLos requerimientos

son:

20

Sistemas II.

El modelaje de requerimientos

Sr. Usuario:Tiene que leerse esto, esto, esto...

A veces resulta difícil para el usuario, revisar todas las especificaciones

Especificaciones

detalladas de

requerimientos TOMO 1

TOMO 2 Analista

21

Sistemas II.

ANALISISANALISIS

IMPLEMENTACIONIMPLEMENTACION

CICLO DE VIDA TRADICIONALCICLO DE VIDA TRADICIONAL

Los Sistemas de InformaciónLos Sistemas de Información

DISEÑO

MANTENIMIENTO

22

Sistemas II.

CICLO DE VIDA

1. ANALISIS:1. ANALISIS:

1.1. Estudio Preliminar

1.2. Levantamiento de Información

1.3. Definición del Problema

1.4. Elaboración del Modelo Funcional del Sistema actual

1.5. Determinación de Requerimientos

1.6. Descripción y Evaluación de Alternativas

1.7. Aprobación de alternativas

23

Sistemas II.

CICLO DE VIDA

2.DISEÑO2.DISEÑO

2.1. Elaborar Modelo Funcional del Sistema Propuesto

2.2. Diseño Lógico

2.3. Elaboración y Presentación del prototipo del Sistema

2.4. Aprobación del Sistema Propuesto

24

Sistemas II.

CICLO DE VIDA:

3. IMPLEMENTACION3. IMPLEMENTACION

3.1. Desarrollo del Software

3.2. Prueba del Sistema

3.3. Puesta en Marcha

¿ Qué significa poner en Marcha un Sistema ?

25

Sistemas II.

CICLO DE VIDA:PUESTA EN MARCHA:

Actividad de traslado de una aplicación probada a un ambiente de producción

- Acondicionamiento de locales- Organización del Cliente- Entregar aplicación probada- Elaborar datos en Vivo- Adiestramiento- Carga de datos en vivo- Entrega de documentación- Asignar Responsabilidades- Determinar FIN de la instalación

26

Sistemas II.

MANTENIMIENTO DE SISTEMAS• Es la última fase del Ciclo de Vida de Desarrollo deSistemas, en donde los SI son sistemáticamentereparados y mejorados.• Por definición, el proceso de mantenimiento de un SI esun proceso de devolución al principio del Ciclo de Vida yde repetición de los pasos de desarrollo para laimplementación de cambios.• Las 4 actividades más importantes que ocurren dentrodel mantenimiento son:–Obtención de los requerimientos de mantenimiento.– Transformación de los requerimientos en cambios.–Diseño de los cambios.– Implementación de los cambios.

27

Sistemas II.

TIPOS DE MANTENIMIENTO• CORRECTIVO. Para reparar fallas en el diseño, codificación o implementación, del sistema.• ADAPTATIVO. Para que las funcionalidades del sistemaevolucionen a la par de los cambios del negocio o de lastecnologías.• PERFECTIVO. Para agregar nuevas funciones al sistema opara mejorar su desempeño.• PREVENTIVO. Para evitar posibles problemas del sistema a Futuro.

28

28

Tópicos cubiertos

Requerimientos funcionales y no funcionales

Requerimientos del usuario Requerimientos del sistema El documento de requerimientos del

software

29

Definición de RequerimientoEs decir, los requerimientos son lo que los clientes/usuarios esperan que haga el sistema.

Los analistas, por lo tanto, deben entender el problema de los usuarios en SU cultura y con SU lenguaje y construir el sistema que resuelve sus necesidades.

En si el objetivo del análisis de requerimientos es resolver el problema.

30

Requerimientos v/s DiseñoLos requerimientos definen el Qué (el problema) del sistema.

El Diseño define el Cómo (la solución).

Durante el análisis de requerimientos no se consideran descripciones especificas de la implementación como requerimientos, a menos que el cliente lo pida (Ej.: bases de datos especificas, lenguajes de programación, etc.).

Los requerimientos, por lo tanto deben centrarse en el cliente/usuario y el problema.

31

Maneja el Sistema de Requerimientos Permite la solución de un problema del

mundo real. Son una combinación compleja de

requerimientos de diferentes personas en diferentes niveles de una organización y entorno.

Es verificable

REQUERIMIENTOS DE SOFTWAREREQUERIMIENTOS DE SOFTWARE

32

32

Requerimientos Los requerimientos para un sistema son la

descripción de los servicios proporcionados por el sistema y sus restricciones operativas.

Los requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema

33

33

Ingeniería de requerimientos El proceso de descubrir, analizar,

documentar y verificar estos servicios y restricciones

34

34

Abstracción de requerimientos (Davis, 1993)

“Si una compañía desea establecer un contrato para un proyecto de desarrollo de software grande, debe de definir sus necesidades de una forma suficientemente abstracta para establecer a partir de ella una solución. Los requerimientos deben redactarse de tal forma que varios contratistas pueden licitar el contrato, ofreciendo, quizás, formas diferentes de cumplir con necesidades de los clientes en la organización. Una vez que el contrato se asigna, el contratista debe redactar una definición del sistema para el cliente más detalladamente de forma que éste comprenda y pueda validar lo que dará el software. Ambos documentos se pueden denominar documento de requerimientos para el sistema.”

35

35

Tipos de requerimientos Requerimientos del usuario

– Declaraciones en lenguaje natural en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe de funcionar

Requerimientos del sistema– Documento estructurado que establece una descripción

detallada de los servicios y restricciones operativas del sistema

Especificación del Software– Una descripción detallada del software que es una base

para el diseño e implementación. Esta orientada para ser leída por los desarrolladores

36

36

Definiciones y especificaciones Definición de Requerimientos

1. El Software proporciona significado de representación y acceso a archivos externos creados por otras herramientas.

Especificación de Requerimientos1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos

externos.1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual,

será aplicada para el archivo.1.3 Cada tipo de archivo externo será representado como un icono específico

mostrado al usuario.1.4 Las facilidades proporcionadas para la representación del icono en un tipo de

archivo externo será definido por el usuario.1.5 Cuando un usuario selecciona una representación de icono de un archivo

externo, el efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo externo al archivo representado por la selección del icono.

37

37

Lectores de requerimientos

38Importancia de los requerimientosEn 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar como les estaba llendo. Los resultados fueron desencantadores:

El 31% de los proyectos de software fueron cancelados antes de tiempo (2480 proyectos).

En las grandes compañías, sólo el 9% de los proyectos fue entregado en el termino de tiempo y dentro del costo que se presupuestaron; el 16% satisfizo estos requerimientos en las compañías pequeñas.

39

En 1995 Standish pidió a los participantes que especificarán las causas. Los resultados fueron los siguientes:

Requerimientos incompletos (13,1%). Falta de compromiso del usuario (12,4%). Falta de recursos (10,6%). Expectativas no realistas (9,9%). Falta de soporte ejecutivo (9,3%). Requerimientos y especificaciones cambiantes (8,7%). Falta de planeamiento (8,1%). Fin de la necesidad del sistema (7,5%).

Importancia de los requerimientos

40Importancia de los requerimientosBoehm y Papaccio en 1988, realizan un cuantificación del costo de corregir los errores asociados a requerimientos en las diversas etapas del software.

Etapa en la que se encuentra el error Costo en USD

Análisis y Esp. Requerimientos 1Diseño 5Codificación 10Prueba Unitaria 20Producción 200

41

Documentos de Requerimientos

Existen dos documentos que emanan del análisis de requerimientos:

Definición de requerimientos

Es un documento que debe escribirse en términos que el cliente pueda entender. Es decir, este documento es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Este documento es escrito en forma conjunta por el cliente y el desarrollador.

42

Documentos de RequerimientosEspecificación de requerimientos

Documento que reitera la definición de los requerimientos en los términos técnicos apropiados para el desarrollador del diseño de un sistema. Es la contrapartida técnica al documento de definición de requerimientos y es escrito por los analistas de requerimientos.

A veces un único documento puede servir para ambos propósitos, lo que lleva a un entendimiento común entre clientes, analistas de requerimientos y diseñadores.

Pero a menudo se necesitan ambos documentos.

43

Documentos de Requerimientos

Es muy importante, que al usar ambos documentos exista un correspondencia directa entre cada requerimiento del documento de definición y aquellos documentos en la especificación.

Esto para que la visión del cliente este unida a la de los desarrolladores (esto se logra gracias a la gestión de configuración).

44

Clasificación de RequerimientosSegún el Tipo los requerimientos se clasifican en:

Requerimientos funcionales. Requerimientos no funcionales. Requerimientos del Dominio.

Según a quien van dirigidos se clasifican en:

Requerimientos del Usuario. Requerimientos del Sistema.

45

45

Requerimientos funcionales Describen la funcionalidad o los servicios del sistema que el

sistema proveerá. Dependen del tipo de software, del sistema que se desarrollo y de

los posibles usuarios. Cuando se expresan como Requerimientos del usuarios, se

definen de forma general. Cuando se expresan como requerimiento del sistema describen

con detalle la función de éste, sus entradas y salidas, excepciones, etc.

Dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software

46

46

Requerimientos NO funcionales Definen propiedades y restricciones del sistema,

por ejemplo, fiabilidad, respuesta en el tiempo y la capacidad de almacenamiento. Describen restricciones como las capacidades de los dispositivos de E/S, representaciones del sistema, etc.

El proceso de requerimientos puede especificarse a través de sistema particular de CASE, lenguaje de programación o método desarrollado

47

Clasificación de RequerimientosRequerimientos no funcionales

Los requerimientos no funcionales se clasifican según su implicancia:

Del producto: especifican comportamiento del producto. Ej.: de desempeño en la rapidez de ejecución del sistema, cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para el sistema sea aceptable, los de portabilidad y de usabilidad.

Organizacionales: se derivan de las políticas y procedimientos existentes en la organización del cliente y del desarrollador. Ej.: estándares en los procesos que deben utilizarse, requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar.

48

Clasificación de RequerimientosRequerimientos no funcionales

Externos: cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales, requerimientos éticos.

Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar.

De forma ideal los requerimientos no funcionales se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva. En la práctica, es difícil. El costo es muy alto.

49

49

Clasificación de requerimientos NO funcionales

Requerimientos del producto– Éstos especifican el comportamiento del producto, por ejemplo,

rapidez de ejecución, fiabilidad, etc. Requerimientos organizacionales

– Estos requerimientos son una consecuencia de las políticas y procedimientos de la organización, por ejemplo, estándares usados en los procesos, los requerimientos de implementación, etc.

Requerimientos externos– Son requerimientos que se originan por factores externos al

sistema y de su proceso de desarrollo, por ejemplo, requerimientos legales, éticos, etc.

50

50

Ejemplos de requerimientos NO funcionales

Requerimientos del producto8.1 La interfaz de usuario del LIBSYS se implementará como

HTML simple sin marcos o applets Java Requerimientos organizacionales

9.3.2 El proceso de desarrollo del sistema y los documentos a entregar deberán ajustarse a proceso y a los productos e entregar definidos en XYDR-STRE-99

Requerimientos externos– 10.6 El sistema no deberá revelar al personal de la biblioteca que

lo utilice ninguna información de los usuarios del sistema aparte de su nombre y número de referencia de la biblioteca.

51

51

Métricas para los requerimientos no funcionalesPropiedad Medida

Rapidez Transacciones procesadas por segundoTiempo de respuesta al usuario y a eventosTiempo de actualización de la pantalla

Tamaño KBNúmero de chips de RAM

Facilidad de uso Tiempo de capacitaciónNúmero de cuadros de ayuda

Fiabilidad Tiempo promedio entre fallasProbabilidad de no disponibilidadTasa de ocurrencias de las fallas Disponibilidad

Robustez Tiempo de reinicio después de fallasPorcentaje de eventos que provocan fallasProbabilidad de corrupción de los datos después de las fallas

Portabilidad Porcentajes de declaraciones dependientes del objetivoNúmero de sistemas objetivo

52

Clasificación de RequerimientosRequerimientos del dominio

Se derivan del dominio del sistema más que de las necesidades especificas del usuario.

Son importantes debido a que a menudo reflejan los fundamentos del dominio de la aplicación. Si estos no se satisfacen es imposible que el sistema trabaje de forma satisfactoria.

Estos se expresan utilizando un lenguaje especifico del dominio de la aplicación que a menudo es difícil de comprender. Ej.: operación para calcular desaceleración del tren, para un sistema de control de trenes.

53

Características de los requerimientosEs importante señalar que los requerimientos pueden servir a tres propósitos:

Permitir que el desarrollador explique como ha entendido lo que el cliente pretende del sistema.

Indican a los diseñadores que funcionalidades y características va a tener el sistema resultante.

Los requerimientos indican al equipo de pruebas que demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es de hecho lo que había ordenado.

54

Características de los requerimientosLos requerimientos deben ser de alta calidad para la buena comprensión de clientes y desarrolladores.

Con este fin debe comprobarse que los requerimientos posean las características que se desprenden de las siguientes preguntas:

¿los requerimientos son correctos?. Cliente y desarrollador deben revisarlos para asegurarse que no tienen errores.

¿los requerimientos son consistentes?. Es decir, ¿los requerimientos planteados son no conflictivos ni ambiguos?. Dos requerimientos son inconsistentes cuando es imposible satisfacerlos simultáneamente.

55

SISTEMAS II

Sistemas II.

¿QUE HACER PARA

IMPLEMENTAR

UN EXITOSO

SISTEMA DE INFORMACION?

56

Sistemas II.

BIBLIOGRAFÍA.

•Laudon K. Y Laudon J. 1996. Administración de los Sistemas de Información. 3era. Edición. Pág: 426.•Senn J. 1992. Análisis y Diseño de Sistemas de Información. 2da. Edición. Pág: 33 .•Sage A. Y Palmer. J. 199_. Software Systems Engineering. Pág: 48 •Whitten J., Bentley L., Barlow V. 1996. Análisis y Diseño de Sistemas de Información. 3era. Edición. Pág: 95 • Yourdon E. 1993. Análisis Estructurado Moderno. Pág: 86