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

¿Qué?

Proceso de Desarrollo del Software

Definición Sinónimos
Proceso de Desarrollo Software: el conjunto total de actividades necesarias llevadas a cabo por distintos roles para transformar los requerimientos del cliente en un conjunto consistente de artefactos que representan un producto software y, en un momento posterior, para transformar los cambios de estos requerimientos en una nueva versión del producto software
— Booch
1985

  • Metodologías / Método de Desarrollo Software

  • Ciclo de Vida del Desarrollo Software
Unidad Definición Ejemplo Características

Actividad

  • unidad de trabajo que puede ser solicitado o realizado por un rol individual y que produce un resultado significativo en el contexto del proyecto

  • especificar un caso de uso,

  • implementar una clase,

  • ejecutar pruebas de rendimiento,

  • …​

  • propósito claro expresado en términos de crear o modificar artefactos, generalmente, tales como un modelo, una clase o un plan

  • es asignada a un rol específico

  • afecta a un solo o un pequeño número de artefactos

  • granularidad entre unas horas o unos pocos días, generalmente

Rol

  • define el comportamiento y responsabilidad de un individuo o un grupo de individuos juntos como un equipo

  • analista de sistemas,

  • ingeniero de componentes,

  • integrador de sistemas,

  • …​

  • comportamiento expresado en términos de actividades que el rol realiza y cada rol es asociado con un conjunto cohesivo de actividades (cada rol es asociado con un conjunto de habilidades para realizar las actividades del rol)

  • responsabilidad expresada en relación a ciertos artefactos que el rol crea, modifica o controla

  • no son individuos sino que son títulos de trabajo intercambiables

Artefacto

  • pieza de información que es producida, modificada o usada por un proceso

  • código fuente,

  • especificación de un caso de uso,

  • arquitectura del software,

  • …​

  • formales, típicamente no son documentos abiertos: código, UML, …​, algún texto_

  • productos tangibles: los elementos que el proyecto produce o usa mientras se trabaja hacia el producto

  • usados como entrada por los diferentesroles para realizar una actividad y son el resultado o salida de tales actividades

  • sujetos al control de versiones y gestión de la configuración, muy posiblemente

ProyectoSoftware

  • El desarrollo software es como criar a un hijo …​ tonto?!?

    • la producción del software sería la gestación del niño, que es un periodo vital en el crecimiento del hijo

    • el mantenimiento del software sería la educación del niño, que es un periodo largo que depende de la gestación y crianza previas

El software no se muere, se convierte en un zombi!!!

¿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 inherente

davidProyectoImplantacionDiseño

arbolMantenible

¿Cómo?

  • Una mera enumeración de todos los roles, actividades y artefactos no alcanza a constituir un proceso

  • Un Proceso es un flujo de trabajo, una secuencia de actividades que producen algún valor observable en artefactos y muestra las interacciones entre los roles
height32

coloresDisciplinas

  • Metodologías sin requisitos

    • Metodología Top-Down

    • Metodología Bottom-Up

  • Metodologías con requisitos

    • Metodología en Cascada

    • Metodología en V, doble Cascada

  • Metodologías iterativas

    • Metodológías Rational Unified Process

    • Metodologías Agiles (XP, CrystalClear, Scrum, Kanban, …​)

    • Metodologías en Software Libre: La Catedral y el Bazar
Cascada RUP, Rationale Unified Process XP, eXtreme Programming

coloresCascada

coloresRUP

coloresXP
Cronología Popularidad
historia3

normalesGestion

Metodo-logía en Cascada

Año Autores Publicación Referencia

1911

F.W. Taylor

Producción en Cadena

  • Organización industrial del trabajo mediante la división de las distintas tareas del proceso de producción.

    • Objetivo: aumentar la productividad y evitar el control que el obrero podía tener en los tiempos de producción

1970

W.W. Royce

Managing the development of large Software Systems

IEEE WESCON Proceedings, pp. 1-9

cascada

coloresCascada
Ventajas Desventajas

  • Son modelos fáciles de implementar y entender. Son modelos conocidos y utilizados con frecuencia.

  • Promueven una metodología de trabajo efectiva: definir antes que diseñar, diseñar antes que codificar, …​

Si el 90% o más de los requisitos de tu sistema se espera que sean estables a lo largo de la vida del proyecto, entonces aplicar una política dirigida por los requisitos es una oportunidad apropiada de dar razonablemente una solución óptima
— Booch
Object Solutions

  • Cualquier error detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo

  • No hay método para gran parte del proyecto, mantenimiento

Otros grados menores de estabilidad en los requisitos requieren un enfoque de desarrollo diferente para dar un valor tolerable del coste total
— Booch
Object Solutions
Aportaciones: Excesos:

  • Formalización de disciplinas: Metodologías Jackson, Warnier, Yourdon, DeMarco, …​,

  • Formalización de técnicas: DFD, E/R, Acoplamiento Aferente/Eferente, Cohesión, Granularidad, Métricas del Software, Diseño de Pruebas de Caja Negra y Caja Blanca, …​

  • Herramientas CASE: gestión, requisitos, análisis, diseños, …​, generación de código!!!

    • Proyecto ISDOS: Problem Statement Analyzer (PSA) automatizaba la relación existente entre los requisitos de un problema dados en Problem Statement Language (PSL) y las necesidades que éstos generaban

  • Enfocó en primeras disciplinas: gestion, requisitos, análisis, …​, certificaciones, documentación, …​ "abandonando" al "humilde programador"

  • Planificaciones absurdas, control del calendario, Big Design Up Front (BDUF) …​

  • Excesiva documentación de dudosa calidad

  • Mantenimiento sin método, a veces el 80% del proyecto

Desarrollo Iterativo

Leyes del Cambio Continuo
Ley del Cambio Continuo: Un programa que se usa en un ámbito del mundo real, necesariamente debe cambiar o convertirse cada vez en menos útil y menos satisfactorio para el usuario.
— Lehman y Belady
Ley del Crecimiento continuado: La funcionalidad ofrecida por los sistemas tiene que crecer continuamente para mantener la satisfacción de los usuarios.
— Lehman y Belady
Ley de la Complejidad Creciente: Debido a que los programas cambian por evolución, su estructura se convierte en más compleja a menos que se hagan esfuerzos activos para evitar este fenómeno
— Lehman y Belady
Ley del Decremento de la calidad: La calidad de los sistemas software comenzará a disminuir a menos que dichos sistemas se adapten a los cambios de su entorno de funcionamiento.
— Lehman y Belady
Año Autores Publicación Referencia

1950

W A. Shewhart, W.E. Deming

Ciclos de Demming-Shewhart

  • espiral de mejora continua en 4 pasos:

    • Plan-Do-Check-Act (PDCA) o Planificar-Hacer-Verificar-Actuar (PHVA)

    • enfocando con el teorema de Pareto (80% de las consecuencias proviene del 20% de las causas), Diagrama de Ishikawa (representación gráfica de las relaciones múltiples de causa-efecto entre las diversas variables que intervienen en un proceso), …​

    • aplicado a todos los ámbitos: calidad, medioambiental, seguridad, …​

1960

NASA

Proyecto Mercury

primer programa de vuelo espacial humano de los Estados Unidos

1965~

Taichi Ohno

Kanban

  • Toyota

    • Just-in-time (JIT) manufacturing

    • Radiadores de información: burndowns, tareas, …​

1986

H. Takeuchi y I. Nonaka

The New Product Development Game

  • Harvard Business Review, vol. January/February, pp. 285-305

    • Scrum!!! (melé)

1988

B.W. Boehm

A Spiral Model of Software Development and Enhancement

IEEE, vol. 21, nº 5, pp. 61-72 bohem

1990

A. Cockburn

Crystal, marco metodológico

IBM crystal

1991

J. Martin

Rapid Application Development (RAD)

1997

J.De Luca, P. Coad

Feature-driven development

Java modelling in Color with UML

1999

J. Highsmith

Adaptative Software Development

Press New York: Dorset House

2003

J. Stapleton

DSDM: The Method in Practice

Addison-Wesley
Iteración, Sprint Incremento

  • Conjunto distinto de actividades llevado a cabo de acuerdo con un plan dedicado (iteración) y criterios de evaluación que se traduce en una entrega, ya sea interna o externa.

  • Una parte del sistema pequeña y manejable, por lo general, la diferencia entre dos construcciones sucesivas

entregas

  • Cada iteración se traducirá en al menos una nueva construcción y, por lo tanto, se añadirá un incremento en el sistema

  • Entrega. Un conjunto de artefactos (documentos y posiblemente una construcción ejecutable) relativamente completos y consistente entregada a usuarios externos o internos
Planificar de un poco. Especificar, diseñar e implementar un poco. Integrar, probar y ejecutar un poco en cada iteración
— Booch

  • Entrega interna. Una entrega no expuesta a los clientes y usuarios pero sí internamente solo para el proyecto y sus miembros

  • Entrega externa. Una entrega expuesta a clientes y usuarios externos al proyectos y sus miembros.
Ventajas Desventajas

  • Permite la participación del usuario desde fechas tempranas del proyecto para corregir las desviaciones de sus necesidades

  • Permite elevar el ánimo del equipo de desarrollo con las entregas externas que superan las pruebas de aceptación

  • Errores de programación, diseño, … se localizan con facilidad en el incremento producido en la iteración vigente

  • Dificultad para gestionar a los miembros del equipo de desarrollo en un iteración cerrada o con varias iteraciones abiertas en paralelo

Rational Unified Process

Año Autor Publicación Referencia

1967

I.H. Jacobson

Ericsson approach

Ericsson

1992

I.H. Jacobson

Object-Oriented Software Engineering: A Use Case Driven Approach

ACM Press Addison-Wesley

1995

G. Booch

Rational Approach

Rational Softare

2001

G. Booch, I. Jacobson, J. Rumbaugh

Rational Unified Process

Rational Software

2007

Eclipse

OpenUP de IBM Corp, Telelogic AB, Armstrong Process Group Inc., Number Six Software Inc. y Xansa

http://repositorio.espe.edu.ec/bitstream/21000/6316/1/AC-SISTEMAS-ESPE-047042.pdf

2011

S. Ambler

Agile Unified Process

http://www.ambysoft.com/unifiedprocess/agileUP.html
RUP es un marco de procesos que tiene que ser configurado e instanciado según el contexto del proyecto, basado en componentes, dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental
— IBM

RUP

coloresRUP

Scrum

Año Autor Publicación Referencia

1995

K. Schwaber

The Scrum development process

OOPSLA ’95 Workshop on Business Object Design and Implementation, Austin
Scrum es un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables para problemas complejos.
— Ken Schwaber & Jeff Sutherland
La Guía Scrum

Scrum

  • Deliberadamente incompleto: sólo gestión, sin ningún aspecto técnico

eXtreme Programming

Año Autor Publicación Referencia

1999

Kent Beck

Extreme Programming Explained: Embrace Change: xUnit, refactoring, test-driven development, …​

Addison-Wesley

1999

Martin Fowler

Refactoring: Improving the Design of Existing Code

Addison-Wesley

2000

Ron Jeffries

Extreme Programming Installed

Addison-Wesley

2000

Kent Beck

Planning Extreme Programming

Addison-Wesley

2002

Kent Beck

Test Driven Development: by example

Addison-Wesley
Es un método ligero, eficiente, de bajo riesgo, predecible, científico y divertido para que equipos de tamaño mediano a pequeño (de 10 a 2 programadores) desarrollen software frente a requisitos imprecisos y muy cambiantes xp
— Kent Beck

coloresXP

Comparativa entre RUP vs Scrum+XP

RUP Scrum+XP

RUP

GradyBooch

ciclosxp

KentBeck

coloresRUP

coloresXP
Fases de RUP Fases de Scrum/XP

  • Por perfil del proyecto

    • Inicio

    • Elaboración

    • Construcción

    • Transición

  • Ciclo trimestral

    • Exploración, Sprint 0?

    • Planificación, Sprint 0?

    • Producción

    • Mantenimiento

    • Muerte
Disciplinas en RUP Actividades en Scrum/XP

  • Requisitos y Análisis

  • Diseño

  • Implemetación

  • Pruebas

  • Escuchar

  • Probar

  • Programar

  • Diseñar

  • Disciplina de Requisitos

    • Casos de Uso

  • Disciplina de Análisis

  • Sprint Planning

    • Historias de Usuario

    • Tareas: ToDo, Doing, Done del Burndown

  • Test-Last/First/Driven Development

    • Disciplina de Diseño

    • Disciplina de Pruebas

    • Disciplina de Programación

  • Test-driven Development

    • Disciplina de Pruebas/Diseño de la interfaz del SUT (rojo)

    • Disciplina de Progrmación (verde)

    • Disciplina de Diseño: refactoring
Actividades RUP Concepto Ágil Fuente Ágil

  • Modelo del Dominio

  • Contextos, Values, Entidades, …​

  • Domain-Driven Development

  • Encontrar Actores y Casos de Uso

  • Priorizar Casos de Uso por Riesgo

  • Detallar Caso de Uso

  • Estructurar Casos de Uso

  • Prototipar Interfaz de Usuario

  • Roles e Historias de Usuario

  • Priorización por Retorno de Inversión

  • Historias de Usuario, Aceptación y Conversación

  • TDD, Refactoring

  • Historias de Usuario, Prototipo de Interfaz

  • Scrum/eXtreme Programming

  • Scrum/eXtreme Programming

  • Scrum/eXtreme Programming

  • eXtreme Programming

  • Scrum/eXtreme Programming

  • Análisis de la Arquitectura

  • Análisis de Caso de Uso

  • Análisis de Clase

  • Análisis de Paquete

  • Sprint 0

  • Sprint Planning

  • TDD, Refactoring

  • TDD, Refactoring

  • ¿?

  • Scrum/eXtreme Programming

  • eXtreme Programming

  • eXtreme Programming

  • Diseño de la Arquitectura

  • Diseño de Caso de Uso

  • Diseño de Clase

  • Diseño de Paquete

  • Sprint 0 y Spyke

  • TDD, escuelas Clasica vs Londres

  • TDD, Refactoring

  • TDD, Refactoring

  • ¿?/eXtreme Programming

  • eXtreme Programming/Growing Oject Oriented Software

  • eXtreme Programming

  • eXtreme Programming

  • Implementar la Arquitectura

  • Integración de Sistemas

  • Implementar Clase

  • Pruebas Unitarias

  • Implementar Subsistema

  • Arquitectura emergente

  • Sprint Backlog

  • TDD, código mínimo

  • TDD, prueba primero

  • _

  • eXtreme Programming

  • Scrum/eXtreme Programming

  • eXtreme Programming

  • eXtreme Programming

  • Planificar Pruebas

  • Diseñar Pruebas

  • Implementar Pruebas

  • Realizar Pruebas de Integración

  • Realizar Pruebas de Sistemas

  • Evaluar Pruebas

  • Integración continua

  • Integración continua

  • Integración continua

  • Integración continua *

  • Continuous Delivery/Análisis y Diseño Orientado a Objetos

  • Continuous Delivery/Análisis y Diseño Orientado a Objetos

  • Continuous Delivery/Análisis y Diseño Orientado a Objetos

  • Continuous Delivery/Análisis y Diseño Orientado a Objetos

  • Continuous Delivery/Análisis y Diseño Orientado a Objetos

  • Apertura de la Iteración

  • Realización del Iteración

    • Dirigido por Casos de Uso y Riesgos

  • Cierre de la Iteración

  • Cierre/Apertura de Fase

  • Planificación del Sprint

  • Realización del Sprint

    • Dirigido por el Retorno de Inversión de las Historias de Usuario

  • Demo del Sprint

  • Retrospectiva del Sprint

  • Scrum/eXtreme Programming

  • Scrum/eXtreme Programming

  • Scrum/eXtreme Programming

  • Scrum/eXtreme Programming

  • Scrum/eXtreme Programming

TheUnifiedSoftwareDevelopmentProcess

ExtremeProgrammingExplainedEmbraceChangeEmbracingChange

Planning

RationalUnifiedProcessMadeEasy

TestDrivenDevelopment

Refectoring

TheUnifiedModelingLanguageUserGuide

ScrumElRevolucionario

ddd
Enfasis de RUP Enfasis de Scrum+XP

  • Pequeños/medianos/grandes proyectos (millones de líneas de código)

    • sin límite de desarrolladores ni duración

  • Pequeños/medianos proyectos (40.000-50.000 líneas de código)

    • con 10 desarrolladores máximo durante 15 meses como máximo

  • Iteraciones entre pocas semanas y pocos meses, dependiendo del proyecto

  • Sprints de 2 o 3 semanas

  • Equipo variable en el proyecto, crece y decrece

  • Equipo constante en el proyecto, se mantiene

  • Entrevistas con el cliente en cada iteración, cada vez menos, y en cada entrega

  • Entrevistas con el cliente in situ durante todo el proyecto parte del proyecto

  • Planifica con Casos de Uso priorizados por riesgos técnicos, políticos, …​ del proyecto

  • Planifica con Historias de Usuario priorizado por el retorno de inversión (return of invesment, ROI) del cliente

  • Diseño de la Arquitectura con diseño suficiente (análisis) previa al desarrollo

  • Arquitectura emergente según se re-diseña (TDD y refactoring)

  • Roles especializados por desarrollador: analista de sistemas, arquitecto del software, ingeniero de componentes, integrador de sistemas, …​

  • Desarrolladores multidisciplinares por funcionalidad: product owner, equipo, gestor/scrum master

  • Gestión de documentación de requisitos, análisis y diseño: pesadas/ligeras

  • Poca documentación porque la mejor documentación es el código: ligeras

  • Artefactos/documentación: entre 23 y >100

    • Modelo del Dominio

    • 4+1 vistas

      • Vista de Casos de Uso

      • Vista de Diseño

      • Vista de Implementación

      • Vista de Despliegue

      • Vista de Procesos

  • Equipo jerarquizado

  • Beneficio mutuo, con 30 artefactos (historias de usuario, restricciones, tareas, pruebas de aceptación, metáforas, diseño, …​)

  • Equipo

    • El equipo como una unidad

    • Programación por pares

    • Propiedad compartida del código

    • El equipo debe estar junto

    • Radiadores de información

    • Trabaja las horas razonables para ser productivo

orquesta

jazz

Microsoft

Linux

BillGates

LinusTorvalds
Etiquetar RUP como peso pesado y XP como liviano sin más calificaciones perjudica a ambos al oscurecer lo que cada uno es y lo que cada uno pretendía hacer. Y, cuando se hace de manera peyorativa, es simplemente una postura sin sentido. Son las implementaciones de estos procesos las que serán "pesadas" o "livianas", y deberían ser tan pesadas o livianas como las circunstancias lo requieran
— John Smith
A Comparison of the IBM Rational Unified Process and eXtreme Programming
XP no está libre forma, no todo vale: se enfoca estrictamente en un aspecto particular del desarrollo de software y una forma de entregar valor, y es bastante prescriptivo sobre la forma en que se debe lograr.
— John Smith
A Comparison of the IBM Rational Unified Process and eXtreme Programming
La cobertura de RUP es mucho más amplia e igual de profunda, lo que explica su aparente "tamaño". Sin embargo, en el nivel micro del proceso, RUP ocasionalmente permite y ofrece alternativas igualmente válidas, donde XP no lo hace; por ejemplo, la práctica de la programación en pareja. Esto no pretende ser una crítica de XP; simplemente una ilustración de cómo XP, como su nombre lo indica, ha reducido su enfoque.
— John Smith
A Comparison of the IBM Rational Unified Process and eXtreme Programming

Síntesis

sintesis

davidProyectoDisenyoTecnico

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