Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
Agustín J. González Elo329: Diseño y Programación Orientados a Objeto Tomado de: entre otras fuentes.

2 Definición (1993) La aplicación mecanismos sistemáticos, disciplinados, y cuantificables para el desarrollo, operación y mantención de software; esto es la aplicación de la ingeniería al software. Establecimiento y uso de principios con caracteres de ingeniería apropiados para obtener, eficientemente, software confiable, que opere eficaz y eficientemente en máquinas reales La aplicación del arte de desarrollo software junto con las ciencias matemáticas y computadores para diseñar, construir, y mantener eficientes y económicos programas computacionales que logran sus objetivos.

3 Estado del arte en Ing. De Software
¿Es una ciencia rigurosa con fuertes fundamentos matemáticos? ¿Es una campo técnico bien desarrollado con mucho de disciplina de ingeniería? O está realmente en un estado primitivo... A lo más una sería de “mejores prácticas”, desarrolladores de software construyen software y si éstos funcionan entonces nosotros estudiamos como ellos lo hicieron. Si éstos funcionan por un largo tiempo entonces estudiamos sus procesos de software aún más cuidadosamente.

4 Construcción de una casa para “fido”
I. Introducción: Modelado de SW Construcción de una casa para “fido” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

5 Construcción de una casa
I. Introducción: Modelado de SWI Construcción de una casa Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

6 Construcción de un rascacielos
I. Introducción: Modelado de SI Construcción de un rascacielos Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, para proyectos de envergadura es difícil eludir un proceso y modelado más rigurosos. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."

7 Claves en Desarrollo de SI
I. Introducción: Modelado de SWI Claves en Desarrollo de SI Notación (UML) Calidad: Ej: CMM Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas (Ej: Rational Rose) Proceso (Metodologías Ej: ITIL, Extreme Programming, RUP: Rational Unified Process)

8 Abstracción - Modelado Visual (MV)
I. Introducción: Modelado de SW Abstracción - Modelado Visual (MV) “El modelado captura las partes esenciales del sistema” Proceso de Negocios Orden Item envío Sistema Computacional

9 Notación (Visual) - Beneficios
Manejar la complejidad Interfaz de Usuario (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Servidor de BDs (C++ & SQL, ..) Múltiples Sistemas Componentes Reutilizados “... Hay dos formas de construir software: una es hacerlo tan simple que obviamente no existan deficiencias, otra es hacerlo tan complejo que no existan deficiencias obvias” C:A.R. Hoare, Turing Award Lecture 1980. “Modelar el sistema independientemente del lenguaje de implementación” Promover la Reutilización

10 ¿Por qué la Orientación a Objetos?
Proximidad de los conceptos de modelado respecto de las entidades del mundo real Mejora la captura y validación de requisitos Acerca el “espacio del problema” y el “espacio de la solución” Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema Facilita construcción, mantenimiento y reutilización Podedríamos dar muchas razones pero hay problemas..

11 Problemas en OO “...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendida como los beneficios que esta tecnología puede sugerir”

12 … Problemas en OO Un objeto contiene datos y operaciones que operan sobre los datos, pero ... Podemos distinguir dos tipos de objetos degenerados: Un objeto sin datos (que sería lo mismo que una biblioteca de funciones) Un objeto sin “operaciones”, con sólo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondería con las estructuras de datos tradicionales) Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos Para mayores detalles respecto de estos problemas consultar: “Real-Life Object-Oriented Systems”, Soren Lauesen, IEEE Software March/April 1998.

13 Proceso de Desarrollo de SW

14 El proceso de desarrollo “Completo”
Se da en un contexto que dependiendo el texto o investigador destaca más o menos etapas. El más completo que he visto incluye: El desarrollo es a lo que normalmente se la da más énfasis en la literatura. Sueño Lanzamiento Investigación Desarrollo Soporte Tiempo

15 Caso de desarrollo de productos (Francys Lillo & Victor Grimblatt, Motorola)

16 Caso de desarrollo de productos (Francys Lillo & Victor Grimblatt)

17 ¿Qué es un Proceso de Desarrollo de SW?
Sueño Lanzamiento Investigación Desarrollo Soporte Tiempo Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable Sistema nuevo o modificado Requisitos nuevos o modificados Proceso de Desarrollo de Software

18 Planificar y Evaluar Proyectos ...
¿Podré cumplir con los plazos? ¿Estaré dentro de lo presupuestado? ¿El “cliente” quedará satisfecho? Las Metodologías pueden ser la ayuda que necesitamos, si podemos usarlas correctamente !!

19 Procesos, Metodologías

20 ¿Qué es una Metodología ...
Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente.

21 Las ágiles más conocidas ...
XP (Programación Extrema) La familia Cristal de Cockburn Código Abierto ASD (Desarrollo de Software Adaptable) SCRUM FFD (Desarrollo Manejado por Rasgos) DSDM (Método de desarrollo de sistema dinámico) RUP (Rational Unified Process) Yo no conozco todas, pero vale la pena conocer al menos una. Aquellas en rojo son la más populares.

22 Metodologías en área TI
Más detalles aquí.

23 Apostando por RUP ...

24 Desarrollo de software:Características de RUP ...
Guiado y Manejado por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental Desarrollo Basado en Componentes Utilización de UML Proceso Integrado

25 Principales metodologías en el tiempo
Definición de Requerimientos Análisis & Diseño Construcción/Pruebas Modelo Tradicional de Cascada Implementación y Test Unitarios Integración y test del sistema Operación y mantención Tiempo t Iteración 1 Iteración 2 Iteración 3 Modelo Iterativo Incremental R R R A&D A&D A&D C C C P P P t Tiempo

26 RUP Define Fases de Desarrollo ...
Flujos de Trabajo (Workflow) Concepción Elaboración Construcción Transición A & D C P D R A & D C P D R A & D C P D R A & D C P D R Requerimientos Análisis & Diseño Construcción Esfuerzo Necesario por Actividad Pruebas Distribución Iteración Preliminar Iteración 1 Iteración 2 Iteración n Iteración n+1 Tiempo

27 Importancia de los Hitos en RUP ...
Compromiso de recursos para fase elaboración Aceptación del cliente Concepción Elaboración Construcción Transición Tiempo Hito Objetivos, visión Hito Arquitectura Hito Capacidad Operacional Liberación Producto

28 Mejores Prácticas de RUP ...
Desarrolle Iterativamente Administre los Requerimientos Use Arquitectura de Componentes Modele Visualmente Verifique Calidad Controle los Cambios

29 Un Ejemplo: Comparar con V-Model (Motorola)

30 Rational Unified Process (RUP)
IV. Proceso de Desarrollo de SW basado en UML Rational Unified Process (RUP) Pruebas funcionales Pruebas de desempeño Gestión de requisitos Gestión de cambios y configuración Ingeniería de Negocio Ingeniería de datos Diseño de interfaces Rational Unified Process 1998 Rational Objectory Process UML Objectory Process Enfoque Ericsson

31 Otra visión similar con más Actividades
IV. Proceso de Desarrollo de SW basado en UML Otra visión similar con más Actividades

32 IV. Proceso de Desarrollo de SW basado en UML
Elementos en RUP Workflows (Disciplinas) Workflows Primarios Business Modeling (Modado del Negocio) Requirements (Requisitos) Analysis & Design (Análisis y Diseño) Implementation (Implementación) Test (Pruebas) Deployment (Despliegue) Workflows de Apoyo Environment (Entorno) Project Management (Gestión del Proyecto) Configuration & Change Management (Gestión de Configuración y Cambios)

33 IV. Proceso de Desarrollo de SW basado en UML
... Elementos en RUP Artefactos Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades Un artefacto puede ser un documento, un modelo o un elemento de modelo Conjuntos de Artefactos Business Modeling Set Requirements Set Analysis & Design Set Implementation Set Test Set Deployment Set Project Management Set Configuration & Change Management Set Environment Set

34 Características Esenciales de RUP
IV. Proceso de Desarrollo de SW basado en UML Características Esenciales de RUP Proceso Dirigido por los Casos de Uso Proceso Iterativo e Incremental Proceso Centrado en la Arquitectura

35 Proceso dirigido por los Casos de Uso
IV. Proceso de Desarrollo de SW basado en UML Proceso dirigido por los Casos de Uso Capturar, definir y validar los casos de uso Casos de Uso integran el trabajo Requisitos Análisis & Diseño Realizar los casos de uso Implementación Verificar que se satisfacen los casos de uso Pruebas

36 ... Proceso dirigido por los Casos de Uso
IV. Proceso de Desarrollo de SW basado en UML ... Proceso dirigido por los Casos de Uso «trace» «trace» Caso de Uso Realización de Análisis Realización de Diseño «trace» «trace» Pruebas Unitarias X Pruebas Funcionales Caso de Prueba [The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

37 IV. Proceso de Desarrollo de SW basado en UML
... Proceso dirigido por los Casos de Uso

38 Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes El proceso propuesto tiene mucho en común con el modelo de proceso propuesto por Barry Bohem en 1988: “El modelo espiral”. Los cuadrantes de la espiral son: Determinar objetivos, alternativas y restricciones Evaluar alternativas, identificar y resolver riesgos, construir proptotipos Desarrollo y verificación del producto Planificación de las siguientes fases

39 ... Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML ... Proceso Iterativo e Incremental Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración Análisis Diseño Codific. Pruebas e Integración n veces

40 ... Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML ... Proceso Iterativo e Incremental Cada iteración comprende: Planificar la iteración (estudio de riesgos) Análisis de los Casos de Uso y escenarios Diseño de opciones arquitectónicas Codificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos) Preparación de la entrega (documentación e instalación del prototipo)

41 Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML Proceso Iterativo e Incremental Enfoque Cascada Enfoque Iterativo e Incremental

42 ... Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML ... Proceso Iterativo e Incremental Grado de Finalización de Artefactos

43 Proceso Centrado en la Arquitectura
IV. Proceso de Desarrollo de SW basado en UML Proceso Centrado en la Arquitectura Arquitectura de un sistema es la organización o estructura de sus partes más relevantes Un arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo Inception Elaboration Construction Transition Architecture

44 IV. Proceso de Desarrollo de SW basado en UML
Fases del Ciclo de Vida El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones Las fases son: Inicio o Estudio de oportunidad Elaboración Construcción Transición

45 IV. Proceso de Desarrollo de SW basado en UML
...Fases del Ciclo de Vida Inicio o Estudio de oportunidad (inception) Define el ámbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto Elaboración Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles

46 IV. Proceso de Desarrollo de SW basado en UML
...Fases del Ciclo de Vida Construcción El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación

47 IV. Proceso de Desarrollo de SW basado en UML
...Fases del Ciclo de Vida Transición Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior Estas tareas se realizan también en iteraciones

48 Esfuerzo respecto de las Workflows
I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o 15% Requisitos Una iteración en la fase de elaboración 10% Análisis 15% Diseño 30% Implementación 15% Pruebas P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1

49 ...Esfuerzo respecto de las Fases
IV. Proceso de Desarrollo de SW basado en UML ...Esfuerzo respecto de las Fases I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o Requisitos Una iteración en la fase de elaboración Análisis Diseño Implementación Pruebas P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 Esfuerzo: % 20% % % Duración: 10% 30% % %

50 Idea relacionada: Patrones de Diseño
Es una solución a un problema general de diseño. Tiene la forma de un conjunto de clases que interactúan. Las clases requieren personalización al caso específico (partes en blanco)

51 Ejemplo: Patrón Observador
Vista Controlador Modelo Modelo, vista, controlador

52 Dos lecciones importantes
El tiempo es independiente del contexto. Ahorrar una semana la comienzo de un proyecto es tan bueno como ahorrarla al final. Una semana es una semana. Es mucho más fácil ahorrar tiempo al inicio del proyecto (cuando los entregables son menos claros). Conclusión: Pronto hay que tener claro el proyecto del ramo.