1.264 Tema 4. Proceso de software: CMM Lenguaje de modelado unificado (UML)

Transcripción

1 1.264 Tema 4 Proceso de software: CMM Lenguaje de modelado unificado (UML)

2 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.

3 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.

4 CMM - Nivel 1: Inicial Ad hoc, en ocasiones caótico. Pocos procesos definidos. El éxito depende del esfuerzo individual y de los actos heroicos.

5 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.

6 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 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. Ingeniería del pr oducto de software. Coordinación entre gru pos. Revisiones de colegas. 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.

7 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.

8 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.

9

10

11

12

13 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 Es preciso cumplir 20 requisitos. Procesos de documentación y normalización para el desarrollo del producto final. ISO 9001 no normaliza pr oductos.

14 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 indepente y obtención de certificaci ón. A menudo, sin grandes c ambios re specto a ISO 9000.

15 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.

16 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).

17 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.

18 Diagramas de modelos estáticos de UML Utili zar di agrama de casos: Gráficos y descripciones estructuradas de los pasos del flujo. Diagr ama de clases: 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).

19 Nombre del caso Resumen Iteración 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 Sucesos El si stem a m uestr a l a pantal l a de búsqueda. 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. Rutas de excepción a. 1. Si no se han localizado resultados de búsqueda: 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. Detección 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". Premisas 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 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. Notas -- Historial Todd Clarke 15/03/01 - Iteración superfici al. Todd Clarke 16/03/01 - Iteración completa.

20 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)

21 Diagramas de clases Utiliz ados en requisitos, diseño e i mplementación: Conceptuales, para representar entidades generales en el sistema. Especificación, donde se especifica qué entidad (clase) es válida (pero no de qué manera). Enumera los m étodos y las acciones. Implementación: Diagrama de clases detallado del software real (Java o C++). Enumera los atribu tos, como el modelo de datos. Enumera métodos, op eraciones y funciones. Actividades asociadas naturalmente a los datos de la entidad. También li mitaciones, condi ciones previas y posterior es del modelo que se describen en lo s casos de uso. No se modela todo: es demasiado complicado de leer. Nos ce ntramos e n la s partes c lave del sistema.

22 Diagrama de clases Nom. químico -UNNbr -NomQuímico +ObtNombr() -Extremo1 -Extremo2 1..* * Prod. químico -NúmUN -ClasHaz -Descripción +obtclashaz() +obtdescr() Análisis químico ProductoGas ProductoLíquido ProductoSólido

23 Diagrama de implementación EscánerEtiquetaElec *4 -EnvíoInalámbrico -Recep.Inalámbr Servidor «enviar» Estación trabajo *20 * * * -Extremo5 * -Extremo6 Impresora Diagrama de paquetes similar, pero más detallado

24 Modelos dinámicos Los modelos estáticos se realizan para el sistema completo, pero los dinámicos sólo para componentes clave. Diagrama de estado: Especifica el comportamiento de un ob jeto (entidad). Diagrama secuencial (o diagrama de esca lera): Muestra detalles del caso y mensajes que fluyen entre los objetos a lo l argo del tiempo. Muy utili zado en l as normativas. Diagrama de colaboración: Muestra los mensajes de flujo como un gráfico.

25 Diagrama de estado Cuenta activa Inactiv a Finalizada Cuenta caducada Colecciones

26 Diagrama secuencial Cliente Seguridad Base de datos IntroducirNombreContraseña() LeerNombreContraseña() CrearSesión() Sesión web ComprobarNombreContraseña() ConsultarPedidos () ObtenerEncabezadoPedido() ObtenerArtículosPedido () NuevoPedido() GuardarPedido() Pedido InformarDisponibilidad() ComprobaciónFinal() GuardarFinal() Compromiso()

27 Resumen UML Demostración Visio (Software->modelo UML, todos lo s tipos). Uso de UML después de: Redactar escenarios y casos como documento inicial de requisitos. Perfeccionarlo s para que sean casos de uso. Preparar el modelo de datos inicial. Añadir operaciones/métodos a las entidades, después de analizar l os datos, para crear un diagrama de clases. Usar modelos de paquetes y componentes UML para una visión general del sistema en l os requisitos. Usar modelos UML de estado, de colaboración y secuenciales de forma selectiva en partes complicadas del sistema. UML se está convirtiendo en u n lengu aje "universal": los nuevos programadores pueden leerlo y esto reduce la curva de aprendi zaje de forma sustancial.