sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Soy el cliente de la aplicación que deseo Eres el jefe de proyecto de la aplicación Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías qué y cómo preguntarme, en qué orden y hasta qué nivel de detalle y cuándo?

  • ¿Cuál sería el formato adecuado del resultado de las reuniones?

  • ¿Cómo repartirías las tareas de requisitos entre las personas del equipo de desarrollo? ¿Con cuántas personas empezarías?

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

¿Qué?

  • Flujo de trabajo (realización de casos de uso que incluye trabajadores, actividades y artefactos) cuyo propósito principal es implementar el sistema en términos de componentes

  • código, guiones, fichero binarios, ejecutables, …​

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible

  • Definir la organización del código en términos de subsistemas de implementación organizados en capas

  • Implementar las clases y objetos en términos de componentes (ficheros fuente, binarios, ejecutables y otros)

  • Probar los componentes desarrollados como unidades

  • Integrar en un sistema ejecutable los resultados producidos por implementaciones individuales o equipos

¿Cómo?

Actividades

implementation

Introduccion

Implementar la Arquitectura

implementationArchitecture

ImplementarArquitectura
Identificar los Componentes de importancia arquitectónica relevantes. Identificar Componentes Ejecutables y su correspondencia sobre los Nodos.

  • El principal desafío durante la implementación es crear dentro de los componentes la implementación de los subsistemas que implementen el subsistema de diseño correspondiente.

  • Los desarrolladores deben tener cuidado con no identificar demasiados componentes en esta etapa o ahondar en demasiados detalles

  • Considerar las clases activas encontradas durante el diseño y asignarlas sobre los componentes ejecutables para cada clase activa, denotados por procesos pesados.

  • Esto podría incluir identificar ficheros y componentes binarios que se requieran para construir los componentes ejecutables, aunque esto es de segundo orden de importancia

Integrar Sistemas

integrateSystems

IntegrarSistemas
Planificación de una construcción posterior.

  • Se asume que se da un número de casos de uso y/o escenarios (caminos a través de casos de uso) y otros requisitos que se han de implementar en la iteración actual:

    • La construcción debe añadir funcionalidad a la construcción anterior mediante la implementación de casos de uso y/o escenarios completos

    • La construcción no debe incluir demasiados componentes nuevos o refinados.

      • De lo contrario, puede ser muy duro integrar esta acumulación y realizar pruebas de integración.

      • Si es necesario, algunos componentes pueden ser implementados como dobles, stubs, para reducir al mínimo el número de nuevos componentes introducidos en la construcción

  • La construcción debe basarse en la construcción anterior y debe expandir hacia arriba y por los lados de la jerarquía de capas de subsistemas.

    • Esto significa que la construcción inicial debe comenzar con las capas inferiores

  • Es crucial identificar los requisitos correctos a ser implementados en una construcción y dejar el resto de los requisitos para construcciones futuras:

    • Considerar el diseño del caso de uso para identificar la correspondiente realización de caso de uso

    • Identificar el diseño de subsistemas y clases que participan en la realización del diseño del caso de uso

    • Identificar la implementación de los subsistemas y componentes en el modelo de implementación que trazan el diseño de subsistemas y clases

      • Considerar el impacto de la implementación de los requisitos hechos sobre la implementación de subsistemas y componentes de la construcción actual .

      • Evaluar si este impacto se aceptable de acuerdo con los criterios descritos anteriormente

      • Los resultados deben ser contemplados en el plan de integración de construcciones y comunicadas al ingeniero componente responsable de la implementación de los subsistemas y componentes afectados
Integrar una Construcción.

  • Esto se hace recopilando las versiones correctas de la implementación de los subsistemas y componentes, su compilación y enlace en una construcción.

  • La construcción resultante se somete a pruebas del sistema si pasó las pruebas de integración y es la última construcción creada en la iteración

Implementar Subsistema

implementSubsystem

ImplementarSubsistemas
Mantenimiento de los Contenidos del Subsistema.

  • Se trata de garantizar que los requisitos que afectan al subsistema son implantados correctamente por los componentes u otros subsistemas del subsistema

  • Incluso si los contenidos del subsistema son un esbozo de los arquitectos, es posible que tenga que ser refinado por el ingeniero de componentes según el modelo de implementación evoluciona.

  • El subsistema resultante se pasa luego al integrador de sistemas para la integración

Implementar Clase

implementClass

ImplementarClase
Vincular el código fuente a un fichero de un componente. Generación de código de una clase de diseño

  • El código fuente que implementa una clase de diseño reside en un fichero de un componente. Por lo tanto, se tiene que delinear el fichero del componente y considerar su ámbito.

  • Es común implementar varias clases de diseño en un único fichero del componente.

  • Recordar, sin embargo, que el enfoque modularizaciónde ficheros y las convenciones del lenguaje de programación en uso restringirán cómo se esbozan los ficheros del componente.

  • Generar las partes de código fuente que implementa la clase.

    • En particular, esto es válido para las operaciones y los atributos de la clase, así como las relaciones en la cuales participa la clase.
Implementar las operacones. Proporcionando la Interfaz correcta del Componente.

  • Cada operación definida en el diseño de la clase debe ser implementada, a menos que sea virtual o abstract, implementada por los descendientes de la clase.

  • Esto involucra elegir un algoritmo factible y las estructuras de datos que lo soporten y codificar la acciones requeridas por el algoritmo.

  • Notar también que cualquier estado descrito en el diseño de la clase puede impactar en la forma en que las operaciones son implementadas desde que su estado determina su comportamiento cuando reciba un mensaje.

  • El componente resultante debe proporcionar las mismas interfaces que las clases de diseño que implementa.

Realizar Prueba de Unidad

unitTest

RealizarPruebaDeUnidad
Realizar Pruebas de Especificación Realizar Pruebas de Estructura

  • Pruebas de caja negra

    • Verificar el comportamiento observable externamente de la unidad, sin tener en cuenta la forma en que el comportamiento se implementa en el componente

  • Pruebas de caja blanca

    • Verificar la implementación interna de la unidad, teniendo en cuenta que se prueba todo el código

Síntesis

sintesis

Eres el jefe de proyecto de la aplicación:

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • Casos de Uso Priorizados, especificados, analizados y diseñados,

  • Implementación de la Arquitectura

  • Integrar Sistemas

  • Implementar Subsistema, revisión

  • Implementar Clase, revisión

  • Realizar Prueba de Unidad, revisión

  • Estimando cada actividad, entre 2 y 20 horas, y

  • Repartiendo cohesivamente entre el equipo de desarrollo

  • …​ con trazabilidad de todo!

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Unified Software Development Process

    • Grady Booch, Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (1999)

height32

  • Rational Unified Process Made Easy, The: A Practitioner’s Guide to the RUP

    • Grady Booch, , Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (2003)

height32

  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

    • Craig Larman

    • Pearson; (2004)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Benjamin Cummings; (1995)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson; (2005)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley; (2003)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM