Temas:
1.1 Introducción
Tipos de Procesos
Ciclo de Vida
Desarrollo Software
Ejemplos:
RUP
Extreme Programming (XP)
Ejemplo:
ISO 12207 standard (ISO 1998) define un ciclo de vida del
sistema de alto nivel.
Ejemplos:
EUP (Enterprise Unified Process)
1.2 Metodologías
Concepto
Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el
ciclo de vida indica qué es lo que se ha de obtener a lo largo del desarrollo del
proyecto, pero no cómo hacerlo
La metodología indica cómo hay que obtener los distintos productos parciales y
finales
Desde los inicios del desarrollo de software se consideran las siguientes tres
generaciones:
Desarrollo convencional.
Desarrollo estructurado.
Desarrollo orientado a objetos.
Desde el punto de vista de Desde el punto de vista Desde el punto de vista del
administración del desarrollo cliente
1. Metodologías Estructuradas
Comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada;
luego a mediados de los 70’s, aparecieron técnicas para el Diseño primero y
después, para el Análisis.
Están orientadas a procesos, datos y mixtas. Crea los modelos de forma
descendente.
Ejemplos:
- MERISE (Francia),
- MÉTRICA (España),
- SSADM (Reino Unido).
2. Metodologías Tradicionales
Son aquellas que están guiadas por una fuerte planificación durante todo el proceso
de desarrollo. Se realiza una intensa etapa de análisis y diseño antes de la
construcción del sistema.
Ejemplo:
- RUP (Rational Unified Process)
Introducción al RUP y al UML 29
3. Metodologías Ágiles
Un proceso es ágil cuando el desarrollo de software suele ser:
Ejemplo:
- XP (eXtreme Programming)
1.3.1 Métrica
Objetivos:
Estructura:
MÉTRICA V3
PROCESOS INTERFACES
Gestión de la Configuración
(GC)
- Estudio de viabilidad (EVS)
Seguridad (SEG)
- Análisis del SI (ASI)
Aseguramiento de la Calidad
- Diseño del SI (DSI)
(CAL)
- Implantación y aceptación
del SI (IAS)
a. Procesos
Planificación (PSI).
Desarrollo de Sistemas de Información.
- Estudio de Viabilidad del Sistema (EVS).
- Análisis del Sistema de Información (ASI).
- Diseño del Sistema de Información (DSI).
- Construcción del Sistema de Información (CSI).
- Implantación y Aceptación del Sistema (IAS).
Mantenimiento de Sistemas de Información (MSI).
b. Interfaces
Características:
- Desarrollo iterativo.
- Administración de requerimientos.
- Usa UML (Unified Modeling Language)
- Produce artefactos.
- Arquitectura basada en componentes.
- Modelamiento visual.
- Proceso complejo.
- Es un marco de trabajo.
- Configurable y adecuado para proyectos medianos y grandes.
Introducción al RUP y al UML 32
El principal objetivo de
XP consiste en controlar
un problema
fundamental en el
desarrollo de software:
la alta volatilidad,
especificaciones
incompletas cambios y
falta de cultura del
negocio. Esto hace que
los desarrolladores
tarden en entender el
sistema que deben
desarrollar. XP ataca
este problema mediante
ciclos de iteración
extremadamente cortos en los cuales se añade muy poca funcionalidad,
construyendo un sistema completo que posiblemente se utilice incluso, en
producción; permitiendo a los desarrolladores, asimilar la problemática de
una forma más natural. Por otra parte, exige una alta implicación de los
usuarios en el desarrollo para crear un auténtico clima de trabajo en equipo.
Iteración
Ventajas:
Parte de una visión muy realista en el sentido que considera la realidad
en los desarrollos con los clientes. Así, por ejemplo, tiene en cuenta la
dinámica con los clientes en la cual disponer de una definición
razonablemente completa de funcionalidad del producto suele ser pura
ficción.
Extreme Programming enfatiza especialmente la importancia el diseño
simple y la importancia de las pruebas, un punto especialmente
descuidado en el desarrollo.
Aporta algunas ideas “refrescantes” que son útiles como principios
incluso sin aplicar la metodología en sí. La programación en parejas es
un buen ejemplo, o los “stand up meetings”.
Inconvenientes:
La metodología no es escalable, solamente puede tener sentido en
proyectos relativamente pequeños, según XP proyectos de entre 2 y 12
desarrolladores.
Algunos de los principios parecen demasiado extremos y no gozan de
un respaldo con argumentos sólidos por los defensores de esta
metodología. Por ejemplo, el principio de la programación colectiva, es
decir, que todos puedan tocar en todas partes; este es un punto que
genera mucho debate porque el peligro de una evolución anárquica de
las funcionalidades de los módulos parece alta y muy difícilmente
controlable. Otro ejemplo es el refactoring, la misma metodología pide
cierta estabilidad en el diseño base, pero a la vez enfatiza la necesidad
de refactoring, dos principios que entran fácilmente en conflicto, pero
no aporta criterios claros para saber dónde situar punto de equilibrio
entre ambos.
La metodología no responde con soluciones o con sugerencias a
muchos los problemas que plantean sus principios, lo cual da una
impresión de encontrarse aún en un estado relativamente hipotético.
1.4.1 SCRUM
1.4.2 TOGAF
1.5.1 CMMI
Características:
- Software (CMM/SW)
- Ingeniería de Sistemas (CMM/SE EIA-731)
- Adquisiciones (CMM/SS)
- Integrated Product Development (CMM/IPD) entre otros.
Niveles de Madurez
Nivel Descripción
Punto base. La organización tiene procesos ad-hoc o caóticos.
1-Inicial
El éxito se debe a personas heroicas.
La organización empieza a guardar información. Ya hay
2-Repetible
definiciones, pueden repetirse éxitos anteriores.
Se conocen procesos estándares para desarrollar o mantener
3-Definido software. Hay prácticas de Ingeniería de Software y de
Administración de procesos.
Se usan datos recolectados. Las decisiones están basadas en
4-Administrado datos cuantitativos. Los procesos son medidos, hay
retroalimentación.
La organización se dedica a mejorar continuamente. Se
5-Optimizado
localizan debilidades y fortalezas.
1-Inicial
Gestión de Requisitos (REQM), planificación de proyecto,
monitorización y control de proyectos, gestión y acuerdo de
2-Repetible
suministros, medición y análisis, gestión de la calidad de
procesos y productos, gestión de la configuración.
RUP es un proceso que define quién debe hacer las cosas, qué debe
hacerse, cómo y cuándo. Dado su enfoque, mantiene modelos en
lugar de gran cantidad de documentación, utiliza un lenguaje concreto
y bien definido (UML).
CMMI es un modelo estático, que define áreas claves (PA) en las que
se deben llevar a cabo prácticas específicas o genéricas, por lo tanto,
el hecho de implementar RUP en el desarrollo de un proyecto implica
que ciertas KPA de CMMI sean alcanzadas y otras no.
Introducción al RUP y al UML 39
1.5.2 BPM
Objetivos:
• Agilidad de negocio.
• Eficacia.
• Eficiencia.
• Mejorar el rendimiento a los capitales invertidos.
Beneficios:
1.6 Notaciones
1.6.1 UML
Es un lenguaje de propósito general para el modelado, que se
encuentra orientado a objetos, cuyo objetivo es describir cualquier
tipo de sistema en términos de diagramas.
1.6.2 BPMN
Es una notación gráfica estandarizada que permite el modelado de
procesos de negocio, en un formato de flujo de trabajo (workflow).
BPMN fue inicialmente desarrollada por la organización Business
Process Management Initiative (BPMI), y es actualmente mantenida
por el OMG (Object Management Group), luego de la fusión de las
dos organizaciones en el año 2005. Su versión actual, a abril de
2011, es la 2.0.
Laboratorio No. 4
Objetivos:
Duración:
20 minutos
Descripción:
De forma grupal, el participante elabora un cuadro comparativo con las principales
metodologías y notaciones del mercado.
Notas:
Introducción al RUP y al UML 42
2. Introducción al RUP
El RUP incorpora el manejo del riesgo a lo largo del proceso, ya que está manejado
por los casos de uso y su enfoque técnico se centra en la arquitectura del software.
RUP está soportado por herramientas que automatizan gran parte del
proceso.
A pesar que no es indispensable utilizarlas, las herramientas de la suite de
Rational son un gran apoyo para crear y mantener los diversos elementos del
proceso de ingeniería de software: modelización visual, programación, testing,
requerimientos etc. Son invalorables en el apoyo del registro asociado con la
administración de cambios, como para la administración de configuración que
acompaña al proceso.
Cada fase, al concluir, cuenta con un punto de control claramente definido que
es conocido como hito, que normalmente, es un conjunto de metas definidas.
Objetivos:
Establecer el ámbito de software y las condiciones de los límites del
proyecto, incluidas una visión operativa, criterios de aceptación y aquello
que debe contener el producto y lo que no.
Discriminar los casos de uso más importantes del sistema, los principales
casos de ejemplo de las operaciones, de los que dependerán las
principales concesiones del diseño.
Exhibir y demostrar al menos, una arquitectura posible contra alguno de los
principales casos de ejemplo.
Estimar el coste global y la planificación de todo el proyecto (y
estimaciones más detalladas para la fase de elaboración)
Estimar los riesgos potenciales (las causas de incertidumbre)
Preparar el entorno de soporte para el proyecto.
Resultado:
Un documento panorámico: una visión general de los requerimientos
esenciales del proyecto, características clave y principales exigencias.
Un modelo de caso de uso inicial (que será refinado posteriormente).
Un glosario inicial del proyecto.
Un caso de negocio inicial, que incluya contexto del negocio, criterios de
éxito (proyección de ganancias, reconocimiento del mercado, etc.) y
presupuesto financiero.
Una determinación inicial de riesgo.
Un plan grueso del proyecto que muestre fases e iteraciones.
Un modelo del negocio, si fuera necesario.
Si es posible un prototipo inicial.
Las decisiones sobre arquitectura deben ser hechas con comprensión del sistema
completo, el alcance, la funcionalidad principal y los requerimientos no funcionales
(también conocidos como atributos de calidad). Mientras que el proceso debe
siempre considerar los cambios, las actividades de la fase de elaboración
garantizan que la arquitectura, los requerimientos y los planes están
suficientemente estables, y el riesgo suficientemente mitigado, como para poder
determinar previsiblemente el costo, así como, el cronograma para completar el
desarrollo.
Objetivos:
Analizar el dominio del problema.
Establecer una base de arquitectura sólida.
Desarrollar el plan del proyecto.
Eliminar los mayores elementos de riesgo.
Resultado:
Un modelo de casos de uso (completo por lo menos en un 80%), luego de
ser identificados todos los casos de uso y actores, además de haberse
desarrollado la especificación de la mayoría de los casos de uso.
Requerimientos suplementarios que capturen los requerimientos no
funcionales y cualquier requerimiento que no esté asociado a un caso de
uso específico.
Una descripción de la arquitectura de software.
Un prototipo de arquitectura ejecutable.
Una lista de riesgos revisada y el caso de negocio revisado.
Un plan de desarrollo para todo el proyecto, incluyendo el plan grueso, que
muestre iteraciones y criterios de evaluación para cada iteración.
Resultado:
Un producto listo para ser puesto en manos del usuario final. Consiste, como
mínimo, en:
¿Es este release del producto lo suficientemente maduro y estable para ser
instalado en la comunidad usuaria?
¿Están todos los recursos listos para la transición hacia la comunidad
usuaria?
Esto incluye:
“Beta testing” para validar el nuevo sistema contra las expectativas del
usuario.
Operación paralela con un sistema heredado que está siendo reemplazado.
Conversión de las bases de datos operacionales.
Entrenamiento de usuarios y del equipo de mantenimiento.
Asimismo, esta fase se centra en las actividades requeridas para poner el software
en manos de los usuarios. Típicamente, incluye varias iteraciones, incluyendo
versiones beta, versiones de disponibilidad general, así como, reparación de
errores y versiones de mejoramiento. Además, consume considerable esfuerzo en
desarrollar la documentación orientada al usuario, entrenamiento de usuarios,
apoyo a los usuarios durante la utilización inicial del sistema y reaccionar ante la
retroalimentación del usuario. En este punto del ciclo de vida, sin embargo, la
retroalimentación del usuario debe ser limitada a cuestiones de sintonía,
configuración, instalación y utilizabilidad.
Patron de ciclo
Inception Elaboration Construction Transition
vital
Breve, para establecer el Unica, se definen los Varias, se ejecutan los
Varias, para migrar el
Incremental ámbito y la visión, y para requisitos y se establece la Casos de uso y se afina la
producto a los usuarios
definir el caso de negocio arquitectura arquitectura
2.3. Elementos
Roles - el quién
Tareas - el cómo
Productos de Trabajo - el qué
Actividades - el cuándo
2.3.1. Roles
Responsabilidades:
2.3.2. Tareas
Por ejemplo:
Tareas Rol
Planificar una iteración Administrador de proyecto
Encontrar actores y casos de uso Analista
Revisar el diseño Revisor de diseño
Ejecutar pruebas de performance Ing. de pruebas de performance
Ejemplos:
- Una especificación de caso de uso almacenada en Microsoft®
Word®
- Un modelo de diseño almacenado en Rational Software
Architect.
- Un plan de proyecto almacenado en Microsoft® Project®.
2.4. WorkFlows
Son una secuencia de actividades que produce un resultado de valor observable.
En términos de UML, un Workflow puede ser expresado como un diagrama de
secuencias, de colaboración o de actividades. Asimismo, RUP usa un diagrama
de actividad para representarlo.
Core workflows
Iteration workflows
Activity
Introducción al RUP y al UML 54
Workflows
de Proceso
Workflows de
Soporte
Core Workflow
Representa una visión de las actividades pero por cada iteración dentro
de una fase.
Es otra forma de mostrar el proceso, describiéndolo desde la
perspectiva de “qué sucede en una iteración típica”.
Introducción al RUP y al UML 55
Iteration Workflow
– Elaboration Workflow.
– Construction Workflow.
– Transition Workflow.
2.4.3. Activity
Ejemplo:
Tool mentors: proveen una guía adicional para mostrar cómo desarrollar los
steps usando una herramienta de software específica.
Laboratorio Nº 5
Objetivos:
Identificar y navegar por la herramienta con la metodología.
Identificar los elementos de dicha herramienta.
Duración:
20 minutos.
Descripción:
De forma individual, el participante navegará por la herramienta e irá ubicando los elementos
que el instructor vaya indicando. Asimismo, identificará Roles, Actividades, Artefactos.
Notas:
Introducción al RUP y al UML 58
3. Introducción al UML
Cabe mencionar que UML fue desarrollado por Grady Booch, Ivar Jacobson y Jim
Rumbaugh de Rational Software Corporation, con la participación de usuarios,
diseñadores de software y promotores. Éste se basa en las metodologías de OMT,
Booch y OOSE, convirtiéndose en el heredero natural de éstas. Esto significa que
si ya se es usuario de cualquier metodología orientada a objetos, la experiencia
adquirida será ampliada y actualizada con el uso de esta nueva herramienta.
Razones:
- Sistemas de Información.
- Sistemas de Tiempo Real.
- Sistemas Embebidos.
- Sistemas Distribuidos.
- Software de Sistemas.
- Sistemas de Negocios.
ESTRUCTURA UML
BLOQUES DE MECANISMOS
ARQUITECTURA
CONSTRUCCION COMUNES
Para poder elaborar los diagramas en UML es necesario comprender cómo está
estructurado. Asimismo, es necesario adquirir un modelo conceptual del lenguaje y
esto requiere del aprendizaje de los siguientes elementos:
Introducción al RUP y al UML 61
Por último, se deben combinar estos elementos con la forma con la cual pueden ser
unidos: las reglas UML.
BLOQUES DE CONTRUCCION
1. Elementos
a) Elementos estructurales.
b) Elementos de comportamiento.
c) Elementos de Agrupación.
d) Elementos de Anotación.
Clases.
Interfaz.
Colaboración.
Casos de uso.
Clase activa.
Componente.
Nodo.
Introducción al RUP y al UML 62
Producto
-CodProducto
-DesProducto
-StockAct
-Precio
+BuscarProducto()
+GrabarProducto()
+EliminarProducto()
Cadena de
Responsabilidad
+suspender()
+vaciar cola()
Component
Servidor de
Aplicaciones
dibujar
stm Login
2. Relaciones
0..1 *
patrón empleado
Introducción al RUP y al UML 65
3. Diagramas UML
Los diagramas son los gráficos que muestran los símbolos de los elementos
del modelo, arreglados para ilustrar una parte en particular o un aspecto del
sistema. Permite al usuario visualizar y manipular los elementos del modelo.
OrdenCompra Proveedor
-f -wProvee
-NumOrdCom : Char -Proveedor_id : Char
-FecOrdCom : Date -RazonSocial : String
-GlosaOC : String -DireccionLegal : String
Ins_OrdCompra
-CantInsumos : Double
-PreInsumos : Decimal
Insumo
-InsumoId : Char
-wInsumo -DesInsumo : String
-x
-StkInsumo : Double
-PreInsumo : Decimal
+GrabarInsumo()
+ActualizaInsumo()
+DesactivaInsumo()
-. FamInsumo
-FamInsId : Char
-DesFamIns : String
-wFamIns +CargaComboFamilia()
Despachar
productos
Almacenero
Registrar
Inventario
OC 56 : 3.Capa Datos::OrdenCompra
NumOrdCom : Char = 56
FecOrdCom : Date = 15/04/09
GlosaOC : String = Urgente
solicitada
solicitar() [verificar=no]
entry/verificar prerequesitos rechazada
exit/UninterpretedAction1
consultar()[ solo si,,,,] [verificar=si]
cancelar() aprobada
cancelada
debitar()
bloqueada CancelaRobo(pin)
addLineItem()
parte superior del diagrama).
(from Actors)
Client
Introducción al RUP y al UML 68
«executable»
sistema.exe
«document» «library»
Ayuda.doc Elog.dll
«library»
Gestor
Modelos
Diagramas de Diagrama de
Secuencia Diagrama de Diagrama de
Casos de Uso
Clases Objetos
Diagrama de Diagrama Visión
de Interacción Diagrama de Diagrama de
Actividad Componentes Despliegue
Diagrama de Diagrama Diagrama de
Máquina de de Tiempos Diagrama de
Estructura
Paquetes
Estados Compuesta
Diagrama
de Comunicación
Elementos:
UML intenta construir en UML 1.x, no sustituir los elementos por ninguna
razón. OMG especificó que los cambios deben tener el menor impacto
como sea posible, para los usuarios de lenguajes actuales.
d. Marcos o Frames
etiqueta
CasoUso1
Actor1 CasoUso2
Estructural
Dinámica o Comportamiento
SÍMBOLO SIGNIFICADO
Producto
-CodProducto + Público
-DesProducto - Privado
-StockAct
# Protegido
-Precio
$ Estático
+BuscarProducto()
-GrabarProducto() / Derivado (no estándar)
#EliminarProducto() * Abstracto (no estándar)
Introducción al RUP y al UML 73
«extends»
«Business Actor»
Lector
«Business Use Case»
Registrar Pago de
Mora
Los diseñadores de UML han buscado el balance entre las clases built - in
y las extensiones introducidas por estereotipo. Sólo los conceptos
fundamentales han sido expresados como clases distintas. Otros
conceptos que pueden ser derivados desde los conceptos básicos, han
sido tratados como estereotipos.
Estereotipo/ Se aplica al
Significado
Palabra clave símbolo
Especifica un conjunto coherente de roles
que juegan los usuarios de los casos de
Actor Clase
uso, cuando interactúan con estos casos de
uso.
Maneja comunicaciones entre el entorno
del sistema y el sistema, además, suele
Boundary Clase
proporcionar la interfaz del sistema con un
usuario o con otro sistema
Se trata de clases que coordinan los
eventos necesarios para llevar a cabo. El
Control Clase
comportamiento que se especifica en el
caso de uso, representan su dinámica.
Especifica una clase persistente. Este tipo
de clase suele reflejar entidades del mundo
Entidad Clase real o elementos necesarios para realizar
tareas internas al sistema. También se
denominan clase dominio.
Especifica un actor que representa un ROL
desempeñado en relación al negocio por
alguien o algo en el ambiente de negocio.
Business Actor Actor Asimismo, representa a algún participante
fuera del alcance del negocio y, por lo
tanto, tiene una comprensión del
comportamiento visible del negocio
Especifica un componente que representa
File Componente un documento que contiene código, fuente
o datos.
Se aplica al
Valor etiquetado Significado
símbolo
Todos los Especifica un comentario, una descripción o una
documentation
elementos explicación del elemento al que se asocia.
La mayoría de Especifica el nodo o el componente en el que
location
los elementos reside el elemento.
Especifica si el estado de la instancia se
Clase mantiene después de terminar el proceso que la
persistence Asociación creó; los valores posibles son: persistente (se
Atributo mantiene el valor) y transitorio (no se mantiene
el valor).
Clase Especifica el significado de la clase o la
semantics
Operación operación.
Se aplica al
Restricción Significado
símbolo
Especifica que la instancia o el enlace son
Instancia
Destroyed destruidos antes de terminarse la ejecución
Enlace
de la interacción que lo contiene.
Especifica que no se han especificado todos
Incomplete Generalización los hijos en la generalización y que se
permiten hijos adicionales.
Especifica que la instancia o el enlace se
Instancia
New crean durante la ejecución de la interacción
Enlace
que lo contiene.
Especifica que, sobre un conjunto de
Or Asociación asociaciones, exactamente una se manifiesta
por cada objeto asociado.
Tabla 5. Restricciones.
Vista de
Vista Lógica Implementación
Vista de los
Casos de Uso
Vista de Vista de
Procesos Distribución
Nombres
Alcance
Visibilidad
Integridad
Ejecución
Los modelos que, construidos durante el proceso software de un sistema con gran
cantidad de software, tienden a evolucionar y pueden ser vistos por diferentes
usuarios de formas diferentes y en momentos diferentes. Por esta razón, es común
en el equipo de desarrollo no sólo construir modelos bien formados, sino también
construir modelos que posean las siguientes características:
Introducción al RUP y al UML 77
Ejemplo:
Los diagramas de casos de uso pueden usar dos tipos de relaciones
de dependencia, los nombres para estos tipos deberán ser:
«Include» o «Extend»
Los Casos de uso deberán tener como nombre: el verbo de la
acción que realiza asociado al nombre del objeto afectado.
Ejemplo:
Private, sólo el propio clasificador puede utilizar la característica.
Ejemplo:
Un diagrama de secuencia representa la ejecución de un modelo, a
través de objetos
Introducción al RUP y al UML 78
Laboratorio Nº 6:
Objetivos:
Identificar la herramienta de modelado.
Preparar un archivo con la estructura interna inicial en la realización de un
Proyecto.
Duración:
20 minutos.
Descripción:
De forma individual el participante navegará por la herramienta e irá ubicando los elementos
que el instructor vaya indicando. Asimismo, construirá una plantilla inicial de trabajo.
Notas: