ANALISIS Y DISEÑO DE

SISTEMAS

SESION 09

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com
 Objetivos de la clase
n Definir que es un método
n métodos pesados y métodos ágiles

2
Contenidos

1.Método (Tecnología, Proceso,

organización)
2.Métodos pesados vs. Desarrollo
Ágil

3
 Método

n Establece cómo abordar de un modo sistemático

la construcción de software.
n Se describe el problema y la solución mediante
un conjunto de modelos.
n Ayuda pero no asegura el éxito.
n Es difícil asegurar la calidad del software.
n Un método ofrece guías y es fruto de la
experiencia.
n No sustituye a la necesidad creativa.
n Lo más importante son las personas.


4
 Método

 Dimensión Tecnológica
 Conceptos, Notación, Técnicas y Herramientas


 Dimensión Proceso
 Conjunto de pasos a realizarse y resultados
obtenidos en cada paso (“entregables”)


 Dimensión Organización
 Cómo organizar las personas para acomodar
el proceso

5
 Tecnología
Conceptos



n ¿Qué conceptos soporta? ¿Paradigma?

n Orientación a objetos
n Diseño estructurado
n

Notación


n Modelos soportados


n Representación de los modelos

 Gráfica, Especificaciones formales,…
• Expresividad de la notación
 Agregación, Generalización, Interfaces, Roles, …
n Especificaciones formales (Plantillas, 6
 Tecnología
 Técnicas


n Las técnicas de desarrollo son un conjunto de

procedimientos que se basan en reglas y
notaciones específicas en términos de
sintaxis, semántica y gráficos, orientadas a
la obtención de productos en el desarrollo de
un sistema de información.
n En desarrollos del tipo estructurado o de
orientación a objetos merecen especial
atención las técnicas gráficas, que proponen
símbolos y notaciones estándares para una
mejor comprensión de los sistemas o sus
7
Proceso
 “Un proceso bien definido es
necesario para desarrollar sistemas
software de manera repetible y
predecible”


 “Permite un negocio sostenible y que

puede mejorar en cada nuevo proyecto,
incrementando la eficiencia y
productividad de la organización”


 G. Booch
8
Proceso
n Un proceso software debe indicar:
n la secuencia de actividades a realizar

por el equipo de desarrollo: flujo de

actividades
n los productos que deben crearse: qué y

cuándo
n una asignación de tareas a cada

miembro del equipo y al equipo como

un todo
n heurísticas

n los criterios para controlar el proceso

9
 Proceso


• ¿Para qué contexto de desarrollo es

apropiado?


 Nuevo software, Reingeniería,

 Prototipado, Desarrollo de
componentes


• ¿En qué grado cubre el ciclo de vida?



 Análisis, Diseño, Implementación,

Pruebas
10
 Proceso


• Basados en casos de uso

• Debe ser iterativo e incremental.
§ Conviene centrarse en los aspectos
críticos en las primeras iteraciones
para minimizar riesgos.
§ Rápida retroalimentación
n Establecer un proceso marco: “Cada
empresa de desarrollo debe definir su
propio proceso”.

11
Organización


• Software de alta calidad no puede producirse sin una

organización adecuada.
• Reutilización
• Factoría software
• “Comprar antes que construir”
• Especialización
• Trabajos y responsabilidades organizadas en una cadena de
valor.
• Adecuar tareas a las capacidades del personal
• Múltiples facetas: Marketing, Ventas, Planificación,
Diseño, Producción, etc.

12
 Método completo

Además de tecnología, proceso y organización:



• Guías para la gestión y planificación del

proyecto
• Guías de estimación de costes
• Guías para elaboración de los “entregables”
• Métricas
• Políticas y procesos para asegurar calidad del
software
• Programas de entrenamiento
• Descripciones de roles
• Ejemplos elaborados de aplicación y ejercicios
para el aprendizaje
• Técnicas para adecuación del método 13
Método
TECNOLOGIA
(OO, UML, Rational Rose,
Power Designer y Poseidon)

ORGANIZACION PROCESO
(IBM, Microsoft, UNI) (RUP, Metrica y Larman)

14
 Métodos Pesados y Agiles


• Proceso Unificado, UP
− Marco para definir procesos
• Rational Unified Process, RUP
− Estándar de facto, basado en UP
• Movimiento de la “Extreme Programming,
XP”
− Rechazo a procesos “pesados” como RUP
• Movimiento del “Desarrollo Agil”
− Métodos Ágiles y Modelado Ágil

15
 Métodos Pesados y Agiles


• Proceso pesado
− Muchos artefactos creados en un
ambiente burocrático
− Muchas actividades realizadas con
rigidez y control
− Planificación detallada a largo plazo
− Predictivos en vez de adaptativos
•

16
Dos Dimensiones (RUP)

17
Fases del Ciclo de Vida
§ El ciclo de vida consiste en una serie de
ciclos, cada uno de los cuales
produce una nueva versión del
producto
§
§ Cada ciclo está compuesto por fases y
cada una de estas fases está
compuesta por un número de
iteraciones
§
§ Las fases son:
n Inicio o Estudio de oportunidad 18
 ...Fases del Ciclo de Vida
§ Inicio o Estudio de oportunidad
(inception)
n Define el ámbito y objetivos del proyecto
n Se define la funcionalidad y capacidades
del producto
n

§ Elaboración
n Tanto la funcionalidad como el dominio
del problema se estudian en
profundidad
n Se define una arquitectura básica
n Se planifica el proyecto considerando
recursos disponibles 19
...Fases del Ciclo de Vida
 Construcción
n El producto se desarrolla a través de
iteraciones donde cada iteración
involucra tareas de análisis, diseño e
implementación
n Las fases de estudio y análisis sólo dieron
una arquitectura básica que es aquí
refinada de manera incremental
conforme se construye (se permiten
cambios en la estructura)
n Gran parte del trabajo es programación y
pruebas
n Se documenta tanto el sistema construido
como el manejo del mismo 20
 ...Fases del Ciclo de Vida
§ Transición
n Se libera el producto y se entrega al
usuario para un uso real
n Se incluyen tareas de marketing,
empaquetado atractivo, instalación,
configuración, entrenamiento, soporte,
mantenimiento, etc.
n Los manuales de usuario se completan y
refinan con la información anterior
n Estas tareas se realizan también en
iteraciones
21
 Fases e Hitos

Inception Elaboration Construction Transition

Objetivos Arquitectura Capacidad Lanzamiento

(Vision) Operacional del Producto
Inicial

tiempo

22
 Elementos en RUP
n Workflows (Disciplinas)
n

Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis & Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)



Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration & Change Management (Gestión de
Configuración y Cambios) 23
 ... Elementos en RUP
Workflow, Workflow Detail , Workers, Actividades y


Artefactos
n Workflow: Requirem ent s Workflow Det ail:Analyse t he Problem
 Ejemplo

Workers Art efact os

Act ividades 24
 ... Elementos en RUP
 Workers
 Analyst workers Test ing professional workers
®Test Designer
n Business-Process Analyst
®Test er
n Business Designer
n Business-Model ReviewerManager w orkers
®Change Cont rol Manager
n Requirements Reviewer
®Configurat ion Manager
n System Analyst
n Use-Case Specifier ®Deploym ent Manager
n User-Interface Designer ®Process Engineer
®Project Manager
 Developer workers
®Project Reviewer
n Architect
n Architecture Reviewer Ot her w orkers
®Any Worker
n Capsule Designer
®Course Developer
n Code Reviewer
®Graphic Art ist
n Database Designer
®St akeholder
n Design Reviewer
®Syst em Adm inist rat or
n Designer
®Technical Writ er
n Implementer
®Tool Specialist
n Integrator 25
 ... Elementos en RUP


Workers, Actividades, Artefactos
 Ejemplo: System Analyst Worker


26
 ... Elementos en RUP
Artefactos


§ Resultado parcial o final que es producido y usado

durante el proyecto. Son las entradas y salidas de las
actividades
§
§ Un artefacto puede ser un documento, un modelo o un
elemento de modelo
§ §Business Modeling Set §Deploym ent Set
§ Conjuntos de
§Requirem Artefactos §Project Managem ent Set
ent s Set
§ §Configurat ion & Change Managem ent
§Analysis & Design Set
Set
§Im plem ent at ion Set
§Environm ent Set
§Test Set
27
 Características Esenciales de
RUP
n Proceso Dirigido por los Casos de
Uso
n Proceso Iterativo e Incremental
n Proceso Centrado en la
Arquitectura
n

n
28
Proceso dirigido por los Casos de Uso

Requisitos Capturar, definir y

validar los casos de uso
Análisis & Diseño
Realizar los
casos de uso
Implementación
Verificar que se
Pruebas satisfacen los
casos de uso

29
 ... Proceso dirigido por los Casos de Uso
«trace» «trace»

Caso de Uso Realización de Análisis Realización de Diseño

«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba

[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
30
... Proceso dirigido por los Casos de
Uso

31
Proceso Iterativo e
Incremental
§ El ciclo de vida iterativo se basa en la
evolución de prototipos ejecutables
que se muestran a los usuarios y
clientes
§ En el ciclo de vida iterativo a cada
iteración se reproduce el ciclo de vida
en cascada a menor escala
§ Los objetivos de una iteración se
establecen en función de la
evaluación de las iteraciones
precedentes 32
 ... Proceso Iterativo e
Incremental

§ Las actividades se encadenan en una

mini-cascada con un alcance limitado
por los objetivos de la iteración
Análisi
s
Diseño
Codific
.
n veces Pruebas e
Integración

33
... Proceso Iterativo e
Incremental

§ Cada iteración comprende:

n Planificar la iteración (estudio de
riesgos)
n Análisis de los Casos de Uso y
escenarios
n Diseño de opciones arquitectónicas
n Codificación y pruebas. La integración
del nuevo código con el existente de
iteraciones anteriores se hace
gradualmente durante la
construcción
n Evaluación de la entrega ejecutable
(evaluación del prototipo en función
34
de las pruebas y de los criterios
 Proceso Iterativo e
Incremental

Enfoque
Cascada

Enfoque
Iterativo e
Incremental

35
 Proceso Centrado en la
Arquitectura
n Arquitectura de un sistema es la organización o
estructura de sus partes más relevantes
n

n Un arquitectura ejecutable es una implementación

parcial del sistema, construida para demostrar
algunas funciones y propiedades
n

n RUP establece refinamientos sucesivos de una

arquitectura ejecutable, construida como un prototipo
evolutivo

Incept ion Elaborat ion Const ruct ion Transit ion

Archit ect ure

36
 Extreme Programming, XP
Valores Pr á ct ica s
n Comunicació nEl juego de la planificación
n nVersiones pequeñas

n Simplicidad nMet áfora

n Realimentaci nDiseño sim ple

ón nPruebas

n Valentía nRecodificación
Pr incip ios
nProgram ación por parejas
nAcept ar cam bios
nCódigo colect ivo
nAsum ir Sim plicidad
nInt egraciones cont inuas
nRápida

Realim ent ación nSem anas de 40 horas

nCam bio increm ent al nClient e en el equipo

nTrabajo de calidad nEst ándares de codificación

37
 Manifiesto para el Desarrollo
de
Software Ágil


Nosotros estamos descubriendo mejores formas de

desarrollar software haciéndolo y ayudando a hacerlo.


 A través de nuestro trabajo hemos llegado a

apreciar:



- Personas e interacciones antes que procesos y herramientas
- Trabajar con el software antes que documentación
- Colaborar con el cliente antes que la negociación de un contrato
- Responder al cambio antes que seguir un plan



Esto es, aunque reconocemos que los ítems de la
derecha tienen valor, nosotros valoramos más los ítems
de la izquierda.

38
 Principios detrás del
Manifiesto de Ágil
n Satisfacer al cliente es lo principal
n Aceptar los cambios
n Versiones pequeñas
n Integrar a la gente del negocio
n Motivación del equipo
n La conversación cara a cara es el
medio más eficiente de
comunicación
n Software funcionando es la mejor
medida de progreso.
n Mantener velocidad constante por
parte de todos
n
http://www.agilealliance.com
nAtención continua a la excelencia
técnica y buenos diseños mejorar la
agilidad.
nSimplicidad es esencial
nLas mejores arquitecturas, requisitos y
diseños surgen de equipos que se
auto-organizan.
nA intervalos regulares, el equipo
refleja cómo llegar a ser más
efectivo.
n
39
Métodos Ágiles
n Iteraciones corta de duración fijada.
n Refinamiento evolutivo de planificación,
requisitos y diseño.
n Simplicidad, ligereza, comunicación.
n Ejemplos: Scrum, XP, DSDM,..

40
 Modelado Ágil
(http://www.agilemodeling.com)
n “El propósito de modelar es principalmente
comprender y comunicar no documentar”.
n “No hay que modelar todo el diseño software”
n Se define y muestra cómo poner en práctica un
conjunto de valores, principios y prácticas
para un modelado efectivo y ligero.
n Se explora como aplicar las técnicas de modelado
en proyectos con enfoque ágil (XP)
n Explorar cómo mejorar el modelado en procesos
predictivos como el RUP

41
 Modelado Ágil
(http://www.agilemodeling.com)
n Utilizar herramientas simples: pizarras y
fotografías
n Herramientas CASE de modelado son
complementarias
n Integrada con un IDE y con ingeniería inversa
n Programar por pares
n Modelo estructural y de comportamiento en
paralelo
n No complicarse la vida con UML
n Los modelos serán imprecisos e incompletos
n Lo importante es el diseño OO
n Dedicar al modelado unas pocas horas (un día a 42
lo
 Tendencia
• Enfoque industrial para la producción de software:
“Capacidad de producir software de alta calidad a bajo
coste”
 Automatización
 Estándares
 Reutilización: Componentes, Patrones,
Frameworks
 Configurar soluciones
• MDA: nuevo paradigma de desarrollo dirigido
43
 Un proceso simple

n Descrito en “UML y Patrones”, C.

Larman, Prentice-Hall, 2002.
n Fácil de aprender y usar.
n No incluye modelado del negocio.
n Conforma con UP
n Dirigido por casos de usos.
n Desarrollo iterativo e incremental
n Conforma con modelado ágil
n

44
Etapas del Proceso

n Inicio
n Comprender procesos del negocio
(opcional)
n Obtener y especificar requisitos del
sistema
n Identificar y especificar clases y
colaboraciones para objetos del dominio
(análisis)
n Resolver problemas de diseño
(arquitectura, base de datos, redes,
patrones, nuevas clases y
colaboraciones,..) 45
Etapas del Proceso

n Modelado del Negocio (opcional)

n Modelado de Requisitos
n Modelado del Análisis
n Modelado del Diseño
n Implementación
n Pruebas
n

46
ModelodeCasos Modelode Diagramas
deUso Dom inio deProceso
Modelode
Modelo deRequisitos Negocio

Diagramade
Secuenciadel
Sistem a(DSS)
(unoporcasodeuso)

Contratos Diagramade
(unoporinteracción) Clases

Colaboraciones
(unaporcontrato)

Modelo deAnálisis

Arquitecturadel
Sistema

Paquetes DiseñoGUI

PatronesdeDiseño Persistencia

Estructuras
Datos
de Distribución
El Proceso
Modelodel Diseño

47
 Analisis y Diseño de
Sistemas

FIN Sesión 9

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com
48