ANALISIS Y DISEÑO DE

SISTEMAS

SESION 02
Parte 1
UNIVERSIDAD NACIONAL DE INGENIERIA
Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com
 Objetivos
 Introducir modelos de proceso del software
 Describir tres modelos de proceso genéricos
y cuando pueden ser utilizados
 Describir los modelos de proceso para la
ingeniería de requisitos, el desarrollo del
software, pruebas y la evolución
 Explicar el modelo de proceso unificado
racional

2
Agenda
 Modelos de proceso del software
 Iteración del Proceso
 Actividades del Proceso
 El Proceso Unificado Racional

3
Desarrollo de SI
Comunicación compleja

1. Lo que el director desea. 2. Como lo define el director de 3. Como se diseña el Sistema.

proyecto.

4. Como lo desarrolla el 5. Como se ha realizado la 6. Lo que el usuario quería.

programador. instalación.

Origen: desconocido
4
 Modelos del ciclo de vida del
software.
Bibliografía
 Ian Sommerville 2005 7ma edición Cap. 4

Apartados 4.1- 4.3

 Roger Pressman 2005, 6ta edición) Cap. 3

Apartados. 3.2-3.7

5
 El proceso del software
 Es la estructura de actividades requeridas para
desarrollar un sistema de Software
 Especificación;
 Diseño;
 Validación;
 Evolución.
 Un modelo del proceso del software es una
representación abstracta de un proceso.
 Representa una descripción de un proceso desde
una perspectiva particular.

6
 Modelos genéricos del proceso
del software
 El modelo waterfall
 Fases distintas y separadas de la especificación y
desarrollo.
 Desarrollo Evolutivo
 Especificación, desarrollo y validación son interpolados.
 Ingeniería de Software basado en componentes
 El sistema se ensambla de componentes existentes.
 Hay muchas variantes de estos modelos de
desarrollo formal por ejemplo, un proceso del tipo
cascada es utilizado pero la especificación es una
especificación formal que es refinada por varias
etapas a un diseño ejecutable.
7
 Modelo Waterfall (cascada)
 Primer modelo empleado (Royce 1970)
 También denominado
 “ciclo de vida clásico” o “paradigma clásico”
 “orientado a fases”
 “lineal secuencial”
 Ejecución secuencial de una serie de fases
 Cada fase genera documentación para la
siguiente
 Varias propuestas
8
Modelo Waterfall (cascada)

9
 Modelo Waterfall por fases
 Fases
 Análisis y definición de Requisitos
 Diseño del Sistema y del software
 Implementación y pruebas unitarias
 Integración y pruebas del sistema
 Implantación y Mantenimiento
 La desventaja principal del modelo cascada es la
dificultad del cambio después de que el proceso esté
en curso.
 Una fase tiene que estar completa antes de iniciar la
siguiente fase.
10
 Problemas del Modelo cascada
 La flexibilidad de cambios del proyecto durante los
distintos niveles hace dificultoso atender los
cambios de los requisitos del cliente.
 Por lo tanto, este modelo es apropiado cuando los
cambios de los requisitos son limitados durante el
proceso del diseño.
 Pocos sistemas del negocio tienen requisitos
estables
 El modelo de la cascada se utiliza sobre todo para
los proyectos de la ingeniería de sistemas grandes
donde un sistema se desarrolla en varios sitios o
sistemas de duración corta donde se desarrolla en
un solo sitio. 11
 Desarrollo evolutivo
 Desarrollo Exploratorio
 El objetivo es trabajar con el cliente para explorar sus
requerimientos y entregar un sistema final.
 El desarrollo empieza con las partes del sistema que se
comprenden mejor.
 El sistema evoluciona agregando nuevos atributos
propuestos por el cliente

 Prototipo desechable
 El objetivo es entender los requisitos del sistema.
 Debe comenzar con los requisitos del cliente que son
mal entendidos para clarificar cuál es realmente
necesario 12
 Desarrollo evolutivo
Actividades concurrentes

Versión
Especificación
inicial

Esbozo de la Desarrollo Versión

descripción intermedia

Versión
validación final

13
 Desarrollo Evolutivo
 Problemas
 Falta de visibilidad del proceso;
 Los Sistemas a menudo son mal estructurados;
 Las habilidades especiales (por ejemplo. el lenguaje
para el prototipado rápido) que puede ser requerido.
 Aplicabilidad
 Para sistemas pequeño o medianos;
 Para partes de sistemas grandes (por ejemplo. el
interfaz de usuario);
 Para sistemas cuyo ciclo de vida sea corto.

14
 Ingeniería de Software basada en
Componentes
 Basado en reutilización de sistemas donde los
sistemas son integrados a partir de componentes
existentes ó Sistemas comerciales.
 Etapas del Proceso
 Análisis de Componentes;
 Modificación de Requerimientos;
 Diseño de Sistemas con reutilización;
 Desarrollo e integración.
 Este enfoque esta cada vez más utilizado por la
estandarización de componente que han surgido.

15
Desarrollo Orientado a la
Reutilización

16
 Iteración de Procesos
 Los cambios son inevitables en todos los
grandes proyectos de software .
 Los requerimientos de sistemas cambian
cuando el negocio que soporta el sistema
responde a las presiones externas.
 La iteración puede aplicar uno de los modelos
genéricos.
 Dos modelos de procesos
 Entrega Incremental;
 Desarrollo en espiral.
17
 Entrega Incremental
 En vez de entregar el sistema como una sola entrega,
el desarrollo y la entrega se analiza en incrementos
con cada incremento se entrega la parte de la
funcionalidad requerida.
 Los requisitos del usuario son priorizados y los
requisitos con más alta prioridad se incluyen en los
primeros incrementos.
 Una vez que el desarrollo de un incremento es
iniciado, los requisitos son congelados aunque los
requisitos para incrementos posteriores pueden
continuar evolucionando.

18
Desarrollo Incremental

19
 Modelo Incremental (Pressman 2005) pp. 51-52
Incremento 1

Entrega
Análisis Diseño Código Prueba Incremento 1

Entrega
Incremento 2 Análisis Diseño Código Prueba Incremento 2

Entrega
Incremento 3 Análisis Diseño Código Prueba Incremento 3

Entrega
Incremento 4 Análisis Diseño Código Prueba Incremento 4

Tiempo

 Cada secuencia produce un “incremento” del sw.

 Con cada incremento, se entrega un producto totalmente
operacional 20
 Ventajas del desarrollo
Incremental
 El cliente no tiene que esperar a que el sistema este
terminado para sacar provecho de el, el primer
incremento satisface la funcionalidad de sistema y
pueden utilizar el software inmediatamente.
 Los primeros Incrementos actúan como un prototipo
para ayudar a obtener experiencia sobre los
requisitos de los incrementos posteriores.
 Bajar el riesgo del fracaso del proyecto..
 Los servicios más altos del sistema requieren de la
prioridad de hacer mas pruebas.

21
 Programación Extrema
 Es una variante del enfoque incremental
 Basado en el desarrollo y la entrega de
incrementos pequeños de la
funcionalidad.
 Confía en la mejora constante del
código, implicación del usuario en el
equipo y en la programación por
parejas

22
 Desarrollo en Espiral
 El proceso se representa como espiral en vez de
secuencia de actividades con retorno hacia atrás.
 Cada ciclo en la espiral representa una fase en el
proceso.
 Las fases no son fijas tales como la especificación o
el diseño – los lazos en la espiral son seleccionados
dependiendo de que es lo que se requiere.
 Los riesgos se determinan y se resuelven
explícitamente a través del proceso.

23
Modelo espiral del proceso del
software (Boehm IEEE 1998)

24
 Fases del Modelo Espiral
 Definición de Objetivos
 Se identifican los objetivos específicos para cada
fase.
 Evaluación y reducción de riesgos
 Se identifican los riesgos y se determinan las
actividades para reducir los riesgos del proyecto.
 Desarrollo y validación
 Se escoge un modelo de desarrollo para el sistema
eligiendo cualquiera de los modelos genéricos.
 Planeamiento
 Se revisa el proyecto y se planea la próxima fase del
espiral
25
Actividades del proceso
 Especificación de Software
 Diseño e implementación de Software
 Validación de Software
 Evolución de Software

26
 Especificación de Software
 Es el proceso de comprensión y definición de
qué servicios se requieren del sistema y de la
identificación de las limitaciones de
funcionamiento y desarrollo del.
 Procesos de la Ingeniería de Requisitos
 Estudio de viabilidad;
 Obtención y análisis de Requisitos;
 Especificación de Requisitos;
 Validación de Requisitos.

27
El proceso de la ingeniería de requisitos

28
 Diseño e implementación de
Software
 Proceso de convertir la especificación del
sistema en un sistema ejecutable.
 Diseño de Software
 Diseñar una estructura de software para realizar
la especificación;
 Implementación
 Traducir la estructura en un programa
ejecutable;
 Las actividades del diseño y la
implementación se relacionan y pueden ser
retroalimentados.
29
Actividades del proceso de
diseño
 Diseño de la Arquitectura
 Especificación abstracta
 Diseño de Interfase
 Diseño de Componentes
 Diseño de la estructura de Datos
 Diseño de Algoritmos

30
Proceso del diseño de
software

31
 Métodos estructurados
 Enfoques sistemáticos para desarrollar un
diseño de software.
 El diseño es documentado generalmente
como un conjunto de modelos gráficos.
 Modelos Posibles
 Modelo de objetos;
 Modelo de comportamiento (interacción de
objetos);
 Modelo de transición de estados;
 Modelo Estructural;
 Modelo de flujo de Datos.
32
 Programación y depuración de
errores
 Traducir un diseño a un programa y depurar
errores del programa.
 La programación es una actividad personal
 No hay proceso de programación genérico.
 Los programadores llevan a cabo algunas
pruebas de código para descubrir los defectos
en el programa y quitar estos defectos en el
proceso de la depuración.

33
El proceso de depuración

34
 Validación de Software
 Verificación y validación (V & V) se utiliza
para mostrar que un sistema esta conforme
con su especificación y que cumple con las
expectativas del cliente.
 Implica procesos de comprobación como las
inspecciones y revisiones.
 Probar el sistema implica verificar el sistema
con los casos de la prueba que son derivados
de la especificación de los datos verdaderos
que se procesara por el sistema.
35
Etapas del proceso de pruebas

36
 Prueba de componentes
 Pruebas unitarias o de componentes
 Los componentes individuales se prueban
independientemente;
 Los componentes pueden ser funciones u objetos o
conjuntos coherentes de estas entidades
 Pruebas del sistema
 Pruebas integrales del sistema (funcionales y no
funcionales). Y probar las propiedades emergentes
dado que los componentes se integran para formar el
sistemas.
 Pruebas de Aceptación
 Probar con datos de cliente para verificar que el
sistema cubre las necesidades de cliente.
37
Fases de Prueba en el proceso
del software

38
 Evolución del Software
 El software es intrínsecamente flexible y
puede cambiar.
 Cuando los requisitos cambian por
circunstancias cambiantes de negocio, el
software que sostiene el negocio debe
evolucionar y también debe cambiar.
 Aunque haya existido una separación entre
el desarrollo y la evolución (mantenimiento)
esto es cada vez más irrelevante porque hoy
en día pocos sistemas son completamente
nuevos.
39
Evolución del Sistema

40
 ANALISIS Y DISEÑO DE
SISTEMAS

FIN SESION 02
Parte 1
UNIVERSIDAD NACIONAL DE INGENIERIA
Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com 41