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]

Complejidad del Proyecto Software

Complejidad Disciplina

  • Complejidad del dominio del problema

    • Los problemas que tratamos de resolver en el software a menudo implican elementos de complejidad ineludible, en las que encontramos una gran variedad requisitos que pueden ser contradictorios, ambiguos u omitidos.

    • Una complicación adicional es que los requisitos de un sistema de software a menudo cambian durante su desarrollo

  • Requisitos

  • Limitaciones de la capacidad humana

    • Numero mágico de Miller (7+-2), Ley de Shyk

  • Mantenibilidad con Análisis

  • Posible flexibilidad a través del software

    • No existen muchos estándares en la industria del software como en la industria de la construcción que tiene códigos y estándares para la calidad de las materias primas de construcción.

      • Como resultado, el desarrollo de software sigue siendo una empresa de trabajo intensivo.

  • Reusabilidad con Diseño

  • Comportamiento de los sistemas discretos

    • Dentro de una aplicación grande, puede haber cientos o incluso miles de variables, así como más de un hilo de control. Toda la colección de estas variables, sus valores actuales y su dirección actual y la pila de llamadas de cada proceso dentro del sistema constituyen el estado actual de la aplicación.

      • Por desgracia, es absolutamente imposible para una sola persona realizar un seguimiento de todos estos detalles a la vez. Este es el problema de la caracterización del comportamiento de los sistemas discretos (exponencial).

  • Pruebas y Despliegue

  • Dificultad de gestionar el proceso de desarrollo

    • La gran cantidad de requisitos de un sistema a veces es inevitable y nos obliga a escribir una gran cantidad de software nuevo o volver a utilizar el software existente en formas novedosas.

  • Gestión

Hace tan sólo unas décadas, los programas en lenguaje ensamblador de sólo unos pocos miles de líneas de código subrayaron los límites de nuestras capacidades de ingeniería de software.

Hoy en día, no es raro encontrar sistemas entregados cuyo tamaño se mide en cientos de miles o incluso millones de líneas de código, y todo eso en un lenguaje de programación de alto nivel
Los problemas en los proyectos se pueden remontar a alguien que no dijo a otro algo importante. La mala comunicación no sucede por casualidad
— Kent Beck
eXtreme Programming

El software es un problema de comunicación …​ como todo!!!:

  • Telefono escharrado telefonoEscacharrado

Expectations vs Reality of Client + Business Analyst + Developer = Coding

¿Qué?

Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software
— Bohem
1976
El software es sagrado
— Booch
y lo importante requiere de un ritual
— sentido común / sabiduría popular
...
Las Disciplinas son contenedores usadas para organizar las actividades del proceso que representan una partición de todos los roles, artefactos y actividades en agrupaciones lógicas por áreas de asuntos o especialidades
— Booch

height32
Disciplinas técnicas Disciplinas de soporte

coloresDisciplinas

  • Modelado del dominio

  • Requisitos

  • Análisis

  • Diseño

  • Implementación

  • Pruebas

  • Despliegue

  • Gestión del Proyecto

  • Gestión del Ecosistema, forja del devop para desarrollo colaborativo

    • Entorno

    • Configuración y Gestión de Cambios

    • Herramientas de desarrollo

¿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

No se convierte en un maestro del software aprendiendo una lista de heurísticas. El profesionalismo y la maestría provienen de valores que impulsan las disciplinas
— Martin Fowler
Refactoring

davidProyectoImplantacionDiseño

arbolMantenible

¿Cómo?

Disciplina de Requisitos

Objetivo principal Objetivos

dirigir el desarrollo hacia el sistema correcto al describir los requisitos del sistema así que pueda alcanzarse un acuerdo entre los clientes, usuarios y desarrolladores sobre lo que el sistema debería hacer:

  • Establecer y mantener el acuerdo entre los clientes y otros implicados (stakecholders – gerencia, marketing, comunidad de usuarios, …) sobre lo que el sistema debería hacer

  • Definir los límites del sistema

  • Proveer las bases para planificar los aspectos técnicos del desarrollo

  • Proveer las bases para estimar los costes y tiempos para desarrollar el sistema

  • Proveer a los desarrolladores del sistema con una mejor comprensión de los requisitos del sistema, funcionales y no funcionales
Requisitos funcionales Requisitos no funcionales

  • Enfocados en el problema determinando la correspondencia (función) entre las entradas (de usuarios via ratón, teclado, …​ y/u otros sistemas vía interfaces de comunicaciones) y salidas (por las vías correspondientes)

  • Enfocados en la solución con las restricciones de todas las posibles soluciones que cumplen los mismos requisitos funcionales dados, refierendose a umbrales válidos para valores concretos de distintas cualidades del software: eficiencia, usabiliad, interoperabilidad, seguridad, …​, mantenibilidad, …​, lenguaje, protocolos, plataformas, …​

Artefactos

Diagramas de Casos de Uso y de Estados Historias de Usuario

casosUso

historiasUsuario
Prototipo de Interfaz Interfaz de Comunicaciones

prototipoInterfaz

comunicaciones

Disciplina de Diseño

Sin diseño/análisis

Con diseño/análisis

corriendoAgua

corriendoBarro

corriendoCharcos

corriendoOrilla

Ágil

Iterativo

noSOLID

superCali

mecano

puenteSpagueti
Análisis Diseño

analisisMVC

diseñoMVC

Disciplina de Análisis

Objetivo principal Objetivos

analizar los requisitos a través de su refinamiento y estructura para realizar una compresión más precisa de los requisitos, una descripción de los requisitos que es fácil de mantener y ayuda a estructurar el sistema:

  • Dar una especificación más precisa de los requisitos obtenidos en la captura de requisitos

  • Describir usando el lenguaje de los desarrolladores y poder introducir más formalismo y ser utilizado para razonar sobre el funcionamiento interno del sistema

  • Estructurar los requisitos de manera que facilite su comprensión, cambiándolos y, en general, mantenerlos

  • Acercase al diseño, aunque sea un modelo en sí mismo, y es por tanto un elemento esencial cuando el sistema está conformado en diseño e implementación

Artefactos

Diarama de Clases MVC Diagrama de Colaboración

  • Partir en clases

  • Partir en Métodos

diagramaClases

diagramaColaboracion

Comparativa entre Requisitos y Análisis

Requisitos Análisis

Descrito usando el lenguaje del cliente

Descrito usando el lenguaje de los desarrolladores (diagramas de clases)

Visión externa del sistema

Visión interna del sistema

Estructurado por requisitos, da estructura a la vista externa

Estructurado por clases estereotipadas y paquetes, da estructura a la vista interna

Usado principalmente como contrato entre los clientes y los desarrolladores sobre lo que el sistema debería hacer

Usado principalmente por desarrolladores para [yellow]render qué forma debería tener el sistema*

Contiene muchas redundancia, inconsistencias, .. entre los requisitos

No debería contener redundancias, inconsistencias, … entre los requisitos

Captura la funcionalidad del sistema, incluyendo funcionalidad arquitectónica significativa

Esboza cómo realizar la funcionalidad en el sistema, incluyendo la funcionalidad arquitectónica significativa;

Disciplina de Diseño

Objetivo principal Objetivos

desarrollar enfocados en los requisitos no funcionales y en el dominio de la solución para preparar para la implementación y pruebas del sistema:

  • Adquirir una comprensión profunda sobre los aspectos de los requisitos no funcionales y limitaciones relacionadas con:

  • los lenguajes de programación,

  • la reutilización de componentes,

  • sistemas operativos,

  • tecnologías de distribución y concurrencia,

  • tecnologías de bases de datos,

  • tecnologías de interfaz de usuario,

  • tecnologías de gestión de transacciones,

  • y así sucesivamente

Artefactos

Diagramas de Despliegue Diagramas de Secuencia

diagramaDespliegue

diagramaSecuencia

Comparativa entre Diseño y Análisis

Análisis Diseño

Modelo conceptual porque es una abstracción del sistema y evita cuestiones de implementación

Modelo físico porque es un esbozo de la implementación

Menos formal

Más formal

Diseño genérico, aplicable a varios diseños concretos

No es genérico sino específico para una implementación

Tres estereotipos conceptuales en las clases: modelo, vista, controlador

Cualquier número de estereotipos físicos en las clases, dependiendo del lenguaje de implementación

Menos costoso para el desarrollo (1:5 frente al diseño)

Más costoso para el desarrollo (5:1 frente al análisis)

Pocas capas arquitectónicas

Muchas capas arquitectónicas

Puede no ser mantenido a través de todo el ciclo de vida del software

Debería ser mantenido a través de todo el ciclo de vida del software

Principalmente creado en trabajo de campo, talleres y similares

Principalmente creado por “programación visual” (ingeniería directa e inversa)

Define la estructura que es la entrada esencial para dar forma al sistema, incluyendo la creación del modelo de diseño

Dar forma al sistema mientras intenta preservar la estructura definida por el modelo de análisis

Enfatiza la investigación del problema y sus requisitos

Enfatiza en la solución conceptual que cubra los requisitos más que en su implementación

Enfocado en los requisitos funcionales, en hacer lo correcto

Enfocado en los requisitos no funcionales, en hacerlo correctamente

Disciplina de Implementación

Objetivo principal Objetivos

implementar el sistema en términos de componentes, p.ej. código, scripts, ficheros binarios, código ejecutables:

  • 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

  • Probar el desarrollo de componentes como unidades

  • Integrar en un sistema ejecutable el resultado producido por implementadores individuales o equipos

Disciplina de Pruebas

Objetivo principal Objetivos

comprobar el resultado de la implementación al probar cada versión, incluyendo internas e intermedias, y versiones finales del sistema a entregar:

  • Encontrar y documentar fallos en el producto software: defectos, problemas, …

  • Avisar a la gestión sobre la calidad del software percibida

  • Evaluar las asunciones hechas en el diseño y especificación de requisitos a través de demostraciones concretas

  • Validar que el software trabaja como fue diseñado

  • Validar que los requisitos son implementados apropiadamente

Disciplina de Despliegue

Objetivo principal Objetivos

permtir el acceso a los usuarios finales a los componentes software en el entorno de producción para su explotación:

  • Probar el software en el entorno de producción

  • Configurar componentes para su despligue

  • Distribución de los componentes software

  • Instalar los componentes software

  • Formación de usuarios finales

  • Migracion de bases de datos, …​

Gestión del Ecosistema

  • La complejidad del software justifica la necesidad de herramientas que aceleren su producción, controlen su calidad y monitoricen su gestión a lo largo de todas las disciplinas de la ingeniería del software

  • El ecosistema es un conjunto de servicios integrados orientados al desarrollo de software y su objetivo es mejorar la coordinación y el trabajo realizado por el equipo de desarrollo.
Disciplina Necesidad Herramienta

Requisitos

Se requiere un entorno colaborativo con editores, historial, autoría, respaldos, … donde los especificadores de requisitos (casos de uso / historias de usuario) puedan escribir y el resto del equipo de desarrollo (analistas/diseñadores, programadores, probadores y desplegadores) puedan leer dichos requisitos centralizados

Wiki de GitHub

Análisis y Diseño

Se requiere de una herramienta CASE *(Computer Aided Software Engineering) que facilite la edición de *diagramas de análisis y diseño (diagramas de casos de uso, clases,objetos, paquetes, secuencia, colaboración, estados y actividades, implementación y despliegue) junto con su trazabilidad

MagicDraw

Análisis y Diseño

Se requiere de una herramienta de métricas del software que determine automáticamente el grado de bondad de los componentes de la arquitectura del software

SonarQube

Programación

Se requiere un entorno de desarrollo integrado para la edición, compilación, ejecución, … del código en desarrollo en la máquina local

Eclipse

Programación

Se requiere ayudas para el cumplimiento de las reglas de estilo (formato, identificadores, …) dadas en la arquitectura del software

Eclipse, Checkstyle, PMD, FindBugs y Sonarqube

Programación

Se requiere, en el contexto de metodologías ágiles, ayudas para automatizar en lo posible la refactorización del código (renombrado de identificadores, nombrar constantes, mover métodos, …)

Eclipse

Programación

Se requiere un sistema de registro para gestionar (escritura, destino, avisos, …) los mensajes de trazas, depuración, errores, …) durante la ejecución

Log4j

Programación

Se requiere de un sistema de control de versiones del repositorio de código común del proyecto para facilitar la gestión (actualizaciones, vuelta atrás, mezclas, …) de la rama de desarrollo, la rama de entregas, la rama de producción

GitHub

Pruebas

Se requiere un sistema para la gestión de pruebas que facilite la edición, ejecución, evaluación, … de la pruebas

Junit, Selenium, …

pruebas

Se requiere de un sistema de integración continua para comprobar que el código y las pruebas funcionan tras cualquier cambio

Travis

Pruebas

Se requiere un sistema de cobertura de pruebas que facilite la misión y estrategias de pruebas

SonarQube

Despliegue

Se requiere un gestor de proyectos para la automatización, en lo posible, de la construcción de entregables (compilación, pruebas, reglas de estilo, empaquetado, …)

Maven

Gestión

De proyectos se requiere una herramienta para gestión de tickets que permitan la asignación de tareas con su tiempo estimado y real, finalización por parte del asignado y cierre tras la comprobación por el emisor de la tarea

Tickets de GitHub

Síntesis

sintesis

sintesis
Disciplinas técnicas Disciplinas de soporte

  • Modelado del dominio

  • Requisitos

  • Análisis

  • Diseño

  • Implementación

  • Pruebas

  • Despliegue

coloresDisciplinas

  • Gestión del Ecosistema, forja del devop para desarrollo colaborativo

    • Entorno

    • Configuración y Gestión de Cambios

    • Herramientas de desarrollo

  • Gestión del Proyecto
Relación Disciplina Enfoque

davidProyectoImplantacionDiseño

Modelo del Dominio

Sistema de información del mundo real

Requisitos

Sistema informático como caja negra

Análisis

Sistema informático como caja blanca sin decisiones tecnologicas

Diseño

Sistema informático como caja blanca con decisiones tecnologicas

Implementación

Sistema informático como caja blanca con tecnologías

Pruebas

Sistema informático como caja blanca y/o negra con tecnologías

Despliegue

Usuario con sistema informático

Bibliografía

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

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Addison-Wesley Professional (1789)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Imprint Addison-Wesley Educational s Inc (3 de junio de 2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson Education (US); Edición: 2 ed (28 de junio de 2005)

height32

  • The Mythical Man Month. Essays on Software Engineering

    • Frederick P. Brooks

    • Prentice Hall; Edición: Nachdr. 20th Anniversary (1 de enero de 1995)

height32

  • Extreme Programming Explained. Embrace Change. Embracing Change

    • Kent Beck,Cynthia Andres

    • Addison-Wesley Educational Publishers Inc; Edición: 2nd edition (16 de noviembre de 2004)

height32

  • Refactoring. Improving the Design of Existing Code

    • Martin Fowler,Kent Beck,John Brant,William Opdyke,Don Roberts

    • Addison Wesley; Edición: 01 (1 de octubre de 1999)

height32

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

    • Martin Fowler,Kendall Scott

    • Addison-Wesley Educational Publishers Inc; Edición: 3 ed (15 de septiembre de 2003)

height32

  • Patrones de diseño

    • Erich Gamma et al

    • Grupo Anaya Publicaciones Generales; Edición: 1 (1 de noviembre de 2002)

height32

  • Clean Code. A Handbook of Agile Software Craftsmanship

    • Robert C. Martin

    • Prentice Hall; Edición: 01 (1 de agosto de 2008)

height32

  • Object-Oriented Software Construction

    • Bertrand Meyer

    • Prentice Hall; Edición: 2 ed (3 de abril de 1997)

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