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
Agenda
 Modelos de proceso del software
 Iteración del Proceso
 Actividades del Proceso
 El Proceso Unificado Racional
 Procesos de software.
Bibliografía
 Ingeniería de Software; Ian Sommerville 2011

9ma edición Cap. 2 Numeral 2.1- 2.4

 Ingeniería de Software; Roger Pressman

2006, 6ta edición) Cap. 3 Numeral. 3.2-3.6
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
 El proceso del software
 Es la estructura de actividades requeridas para
desarrollar un sistema de Software
 Especificación del software;
 Diseño e implementación del software;
 Validación del software;
 Evolución del software.
 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.
 Modelos de proceso de
software
 El modelo en cascada (waterfall)
 Fases distintas y separadas de la especificación y
desarrollo.
 Desarrollo Incremental
 Especificación, desarrollo y validación en versiones
(incrementos).
 Ingeniería de Software orientada a la reutilización
 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 en incrementos (los modelos
no son mutuamente excluyentes)
 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

Modelo Waterfall (cascada)
 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.
 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.
 Desarrollo incremental
 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
 Desarrollo incremental
Actividades concurrentes

Versión
Especificación
inicial

Esbozo de la Desarrollo Versión

descripción intermedia

Versión
validación final
 Desarrollo incremental
 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.
 Ingeniería de Software orientada a
la reutilización
 Basado en reutilización de sistemas donde los
sistemas son integrados a partir de componentes
existentes ó Sistemas comerciales.
 Etapas del Proceso
 Especificación de requerimientos;
 Análisis de Componentes;
 Modificación de Requerimientos;
 Diseño de Sistemas con reutilización;
 Desarrollo e integración;
 Validación del sistema.
 Este enfoque esta cada vez más utilizado por la
estandarización de componente que han surgido.
Ingeniería de Software
orientada a la reutilización
 Ingeniería de Software
orientada a la reutilización
Existen 3 tipos de componentes de software que
pueden usarse en un proceso orientado a la
reutilización
1. Servicios Web que se desarrollan en concordancia para
atender servicios estándares y que están disponibles
para la invocación remota
2. Colección de objetos que se desarrollan como un
paquete para su integración con un marco de
componentes como .NET o JEE
3. Sistemas de software independientes que se configuran
para usar en un entorno particular.
Actividades del proceso
1. Especificación de Software
2. Diseño e implementación de Software
3. Validación de Software
4. Evolución de Software
 1. 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 sistema
 Existen 4 actividades principales en el proceso
de la Ingeniería de Requisitos
 Estudio de factibilidad;
 Obtención y análisis de Requisitos;
 Especificación de Requisitos;
 Validación de Requisitos.
 Especificación de Software

(Somerville 2011) pp. 37 - 38

 2. 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.
Actividades del proceso de
diseño
 Diseño de la Arquitectura
 Diseño de Interfaz
 Diseño de Componentes
 Diseño de la base de Datos
Proceso del diseño de
software (Somerville 2011) pp. 39 - 40
 3. 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.
 Etapas del proceso de pruebas

(Somerville 2011) pp. 41

 Proceso de pruebas
 Pruebas de desarrollo
 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.
 Fases de Prueba en el proceso
del software

(Somerville 2011) pp. 43

 4. 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.
 Evolución del Software

Somerville 2011 pp. 44

 Cómo enfrentar el cambio
 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.
 Los cambios se pueden enfrentar de 3
formas.
 Creación del Prototipo;
 Entrega incremental
 Modelo en espiral de Boehm.
 1. Creación del prototipo
 Un prototipo es una versión inicial de un sistema de
SW que se usa para demostrar conceptos, tratar
opciones de diseño y encontrar más sobre el
problema y sus posibles soluciones.
 Un prototipo de SW se usa en un proceso de
desarrollo de SW para contribuir a anticipar los
cambios que se requieran:
 En el proceso de ingeniería de requerimientos, un prototipo
ayuda con la selección y validación de requerimientos del
sistemas
 En el proceso de diseño de sistemas, un prototipo sirve
para buscar soluciones especificas de SW y apoyar el
diseño de interfaz de usuario
 Creación del prototipo

Somerville 2011 pp. 45

 2. 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.
Desarrollo Incremental (Somerville 2011) pp. 47
 Modelo Incremental (Pressman 2006) pp. 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
 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.
3. Modelo en espiral de Boehm
 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.
 Modelo espiral del proceso del
software (Boehm IEEE 1998)

Somerville 2011 pp. 49

 Fases del Modelo Espiral
 Establecimiento de Objetivos
 Se identifican los objetivos específicos para cada
fase.
 Valoració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
 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