PDF de programación - Tema 4 Proceso de software: CMM - Lenguaje de modelado unificado (UML)

1.264 Tema 4

Proceso de software: CMM

Lenguaje de modelado unificado (UML)

Modelo de madurez de capacidad para software

• Desarrollado en el Software Engineering Institute (SEI)

Carnegie-Mellon University (w w w .sei.c mu.edu).

• Norma de facto para la evaluación del proceso de

softw are.

• Modelo de cinco niveles:

– 1: Inicial.
– 2: Repetibl e.
– 3: Definido.
– 4: Gestion ado.
– 5: Optimizado.

• La previsibilidad, la eficacia y el control del proceso

de softw are mejoran a m edida que la organiza ción
sube a estos niveles.

Motivación CMM

• 20 años de promesas no cumplidas sobre

productividad y mejora de calidad a partir de
nuevas tecnologías de softw are.

• Las empresas se dieron cuenta de que el
problema principal es la incapacidad para
gestionar el proceso de softw are.

• CMM ofrece pautas para evolucionar hacia una

cultura de ingeniería de software y gestión
raci onal.

CMM - Nivel 1: Inicial

• Ad hoc, en ocasiones caótico.
• Pocos procesos definidos.
• El éxito depende del esfuerzo individual y de

los actos heroicos.

CMM - Nivel 2: Repetible

• Procesos básicos de gestión de proyectos para el

seguimiento de costes, programac ión, etc.

• Disciplina para repetir hitos anteriores en proyectos

con aplicaciones similares.

• Los procesos clave se centran en pautas básicas de

gestión de proyectos:
– Gestión de r equisitos.
– Planificación del pr oyecto de software.
– Seguimiento y supervisión del pr oyecto de software.
– Gestión d e subcontratación de software.
– Control de calidad del software.
– Gestión de l a configuración del software.

• En el ni vel 2 se puede me dir la s ituaci ón actual para

poder entender me jor los proyectos en e l futuro.

CMM - Nivel 3: Definido

• El proceso de software para gestión y desarrollo se
documenta, normaliza e integra en el proceso global
de la empresa.

• Todos los proyectos utilizan la versión ajustada y

• En el ni vel 3 se empi eza a tene r algo de c ontrol; e s

posible tener pla zos, costes y tomar decis iones.

aprobada del proceso estándar.

• Las áreas clave del proceso se centran en la

institucionalizaci ón del proceso efectivo:
– Objetivo del proceso de la empresa.
– Definición del pr oceso de l a empresa.
– Programa de formación.
– Gestión del software integrado.
–
– Coordinación entre gru pos.
– Revisiones de colegas.

Ingeniería del pr oducto de software.

CMM - Nivel 4: Gestionado

• Se recopilan mediciones detalladas del proceso de

softw are y de la calidad del producto.

• Se controlan y analizan cuantitativamente los

procesos y los productos.

• Los procesos clave se centran en el análisis

cuantitativo del proceso.
– Gestión cuantitativa del proceso.
– Gestión de la calidad del software.

• En el ni vel 4 se obtiene c ontrol real : e s posi ble me dir

y gestionar todos los aspec tos del proyecto.

CMM - Nivel 5: Optimización

• Mejora continua del proceso mediante comentarios

cuantitativos.

• Tecnología innovadora de puesta a prueba e ideas
• Las á rea s c lave del proces o se ce ntran en las

mejoras continuas:
– Prevención de defectos.
– Gestión de cambio de tecnolo gía.
– Gestión de cambio de procesos.

• En el nivel 5 no sólo se obtie ne control: tambié n se

consigue eficacia.

ISO 9000

• Organización Internacional de Estándares (ISO)
– Organismo de normas nacionales de más de 100 países.
ISO 9000
– Familia de normas de calidad de entornos de trabajo, modelos,

•

especificaciones para sistemas de gestión de calid ad.

– Prácticas recomendadas aplicadas a la prod ucción.
ISO 9001
– Normas de calidad para empresas de diseño, desarrollo y

•

servicios.

– Las directrices para software son ISO 9000-3.
– Es preciso cumplir 20 requisitos.
– Procesos de documentación y normalización para el

desarrollo del producto final.
ISO 9001 no normaliza pr oductos.

–

ISO 9000 (continuación)

• Certificación ISO 9000 obligatoria para negocios
en Europa y para el desa rrollo e mpresa rial en el
Pacífico y, en última instancia, en América.

• Enfoque general:

– Desarrollar un equipo de calidad.
–

Informar sobre lo que se hace: documentar procesos a través
de diagramas de flujo.
Informar sobre lo que se hace.

–
– Demostrarlo : auditorí as anuales.

• Tras completar las cuatro tareas: auditoría indepen-

te y obtención de certificaci ón.

• A menudo, sin grandes c ambios re specto a ISO 9000.

Lenguaje de modelado unificado

• Lenguaje de modelado orientado a objetos, migrado
desde el modelado de bases de datos relacionales.
– Gestión estándar del Grupo de gestión d e objetos (CORBA).
– Rational Rose, de Rational Corp, es una implementación
habitual del UML. Ahora hay muchos más proveedores.

• Combina e nfoques competitivos anteriores.

– Técnica de modelado de ob jetos Raumbaugh (OMT).
– Método Shlaer-Mellor.
– Método Bo och.

• Poco uso; actualmente s e está haciendo más común.

Lenguaje de modelado unificado (2)

• ¿Por qué el UML se utiliza cada vez más?

– Acelera el proceso de los requisitos.
– Reduc e la pé rdida d e info rmaci ón en tre el p roces o de re quis itos y el

de diseño, y entre el diseño y la implementación.

– Comunicación: lenguaje más claro y natural, mayor nivel de precisión,

pero ahorra detalles.

– Compatible con el desarrollo iterativo (p.ej., modelo de la espiral).

• Acepta requisitos y diseño de alto nivel en las primeras espirales y diseño

y requisitos más detall ados en fases posteriores.

• UML sólo es el lenguaje de modelado.

– El Proceso Racional Unificado (RUP) es un proceso recomendado

que se basa en el uso de UML.

Inicio (requisitos).

•
• Elaboración (diseño).
• Construcción (desarrollo): “programación extrema” (muy de moda).
• Transición (pruebas, i mpl ementación).

Lenguaje de modelado unificado (3)

• Se utiliza en los requisitos:

– Diagrama de implementación, diagrama de componentes para

la vista de alto ni vel del sistema.

– Recurre a casos con escenarios muy estructurados que se utilizan

para los requisitos del sistema.

• Buen enfoque básico, pero necesita documentación.

• Se utiliza en el diseño:

– Los modelos de datos (no estrictamente UML) se realizan junto con

modelos de clases (objetos) y tienen muchas cosas en común.

• A menudo realiz ados área a área y consolidados a continuación.

– Diagramas de actividad, usados para modelar flujos de trabajo y

encontrar procesos duplicados que pueden suprimirse.

– Prototipos usados para partes arriesgadas, críticas y complicadas.

Diagramas de modelos estáticos de UML

• Utili zar di agrama de casos:

• Diagr ama de clases:

– Gráficos y descripciones estructuradas de los pasos del flujo.

– Estructura interna del sistema, ampliación del diagrama de

entidades-relaciones.

– Tres elementos en cada entidad: nombre, atributos, métodos.

• Diagr ama de implementación:

– Componentes físicos: procesa dores, estaciones de trabajo, redes.

• Diagrama de paquetes o de componentes.

– Modelo de alto nivel de arquitectura física de softw are.
– Consta de módulos que se agrupan en paquetes.
– Los paquetes contienen la definición del grupo de clases (entidades,

métodos).

Nombre del caso

Resumen

Iteración

Sucesos

Rutas de excepción

Detección
Premisas

Ejemplo de caso de uso

Locali zar pedidos y productos mediante número de pedido y código postal.

Permiti r que el usuario locali ce el cli ente y la información del pedido de los artículos devueltos al
introducir el número de pedido (normalmente en la factura) y el código postal.
Completa

1. El si stem a m uestr a l a pantal l a de búsqueda.
2. El usuario introduce los criterios de búsqueda. En este caso son:

a. Núm ero de pedido (norm alm ente en la f actura).
b. Código postal de f acturación.

3. El sistema recupera el pedido y los detall es del cli ente y los m uestra.

1. Si no se han localizado resultados de búsqueda:

a. El si stem a m ostrará un m ensaj e de error aclar ando que no ha encont rado l a i nf orm aci ón.
b. El sistem a v uel v e a m ostrar la búsqueda en l a pantal l a del núm ero del pedido y el códi go postal.
c. El usuari o i ntr oduce l os atr i butos de l a búsqueda.
d. El si stem a recuper a el pedido y l os detal l es del cl i ente y l os m uestra.

2. Si la búsqueda del cliente falla tres veces seguidas:

a. El sistema muestra un mensaje de error y se disculpa por no encontrar el pedido y sugiere que el
usuario se ponga en cont act o con el departam ento de atenc i ón al cl i ente.
b. El usuario puede optar por repetir la búsqueda o ir a otra sección del sit
io.

El cl i ente se ha re gi strad o, ha l l amado, se ha i denti fi cado y se l ecci onad o l a opci ón "nuevo resultado".
Los pedidos y los datos del producto son correctos y se corresponden con los del día anterior.
Los datos del cli ente se corresponden con los del día anterior. (En tiempo real para devoluciones).

Condiciones previas 1. El usuario ha seleccionado este comando en la página de atención al cli ente.

2. El usuario ha adqui ri do un producto de este vendedor.
3. El usuario tiene el número de pedido (por resguardos de correo, la factura y otros medios).

Condiciones posteriores 1. El sistema local iza y muestra el pedido y sus detal les (productos).

Reglas de negocio
relacionadas
Notas
Historial

1. Posible problema: cambio de código postal. Comprobar el nuevo y el antiguo durante la transición.
2. ¿Y si el cliente quiere devolver artículos de dos pedidos? Correcto: permitir selección múltiple.
--
Todd Clarke – 15/03/01 - Iteración superfici al.
Todd Clarke – 16/03/01 - Iteración completa.

Ejemplo de caso de uso (2)

Producto devuelto

«usos»

CSR

Buscar por atributos

del cliente

Cliente

Actores (figuras): CSR, Cliente

Casos de uso (óvalos): Búsqueda, devolución

Relación (línea, flecha)

Diagramas de clases

• Utiliz ados en requisitos, diseño e i mplementación:

– Conceptua