ACI491: Ingeniería de Software

1. ACI491:Ingeniería de Software Unidad 6: Administración de Proyectos de Software

2. Contenidos • Recursos, productividad y calidad de software. • Métricas como herramientas de software. • Técnicas de estimación de costos, Planificación y control de proyectos de Software. • Plan de proyectos de software, Organización del equipo de Proyecto. • El administrador de proyecto y sus roles, El líder de proyecto y sus roles, Selección del equipo de proyecto.

3. Objetivos específicos • Conocer y manejar las diferentes herramientas de administración. • Manejar en forma eficiente los recursos asociados al software. • Conformar un equipo de trabajo, siendo capaz de identificar las labores mas adecuadas para cada uno de los integrantes

4. Introducción • Uno de los principales motivos de fallas en los proyectos de software tiene su origen en la mala administración de los mismos. • Definición de alcance incorrecto, • estimaciones erróneas, • manejo deficiente de los recursos humanos, • escasa administración de los riesgos, son sólo algunas de las actividades que frecuentemente se subestiman al momento de gestionar un proyecto de software. • Las empresas buscan y valoran la productividad. • Las personas que utilizan las mejores prácticas para el trabajo en equipo, donde cada una de ellas toma un rol preponderante en la cadena tienen la de ganar.

5. La Fábula de Esopo "La tortuga y la liebre" 1. Antecedentes y Problemas o Retos

6. La Fábula de Esopo "La tortuga y la liebre" 2. Análisis de Requerimientos y Especificaciones

7. La Fábula de Esopo "La tortuga y la liebre" 3. Modelos de Desarrollo del Ciclo de Vida y Procesos

8. La Fábula de Esopo "La tortuga y la liebre" 4. Diseño de Software y Metodologías

9. La Fábula de Esopo "La tortuga y la liebre" 5. Sistemas de Alta Integridad

10. La Fábula de Esopo "La tortuga y la liebre" 6. Métodos Formales

11. La Fábula de Esopo "La tortuga y la liebre" 7. Administración de Proyectos de Software

12. La Fábula de Esopo "La tortuga y la liebre" 8. Administración de la Calidad del Software

13. La Fábula de Esopo "La tortuga y la liebre" 9. Ambientes de Desarrollo de Software

14. La Fábula de Esopo "La tortuga y la liebre" 10. Mantenimiento del Software

15. La Fábula de Esopo "La tortuga y la liebre" 11. Cumplimiento Exitoso del Proyecto

16. Planificación de Proyectos de Software • La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan planificación del proyecto. • la planificación implica la estimación, su intento por determinar cuánto dinero, esfuerzo, recursos, y tiempo supondrá construir un sistema o producto específico de software. • Antes de que el proyecto comience, el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización. • Siempre que estimamos, estamos mirando hacia el futuro y aceptamos cierto grado de incertidumbre.

17. Planificación de Proyectos de Software (2) • Aunque la estimación es más un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. • Existen técnicas Útiles para la estimación del esfuerzo y del tiempo. • Las métricas del proyecto y del proceso proporcionan una perspectiva histórica y una potente introducción para generar estimaciones cuantitativas. • La experiencia anterior (de todas las personas involucradas) puede ayudar en gran medida al de las estimaciones. • Y, dado que la estimación es la base de todo desarrollo y revisión de las demás actividades de planificación del proyecto, y que sirve como guía para una buena ingeniería del software, no es en absoluto aconsejable embarcarse sin ella.

18. Preguntas claves • ¿Cómo establezco las actividades del proyecto de software? • ¿Cómo llego a conocer el contexto del proyecto de software? • ¿Cómo manejo los riesgos? • ¿Cómo manejo los proyectos iterativos e incrementales? • ¿En qué consiste el método de la cadena crítica? • ¿Cómo influye el factor humano en la administración de proyectos de software? • ¿Cómo influyen la comunicación, la calidad y los “stakeholders” en la administración de proyectos de software?

19. Recursos, productividad y calidad de software.

20. Proyecto, Proceso, Portafolio • Simplificación de priorización de las inversiones • Racionalización de la capacidad y gestión de los recursos • Automatización de las mejores prácticas en los procesos de desarrollo • Ayudar a asegurar la disponibilidad de los conocimientos técnicos adecuados • Mantener los proyectos aprobados sincronizados • La gestión de riesgos eficaz • Hacer más fácil el cumplimiento • La medición de los resultados del proyecto y evaluar con precisión el valor comercial • Responder con rapidez a los proyectos y cambios de cartera Ejemplo: IBM Rational

21. Recursos • Equipos de personas • Herramientas • CMMI • IBM Rational • Capital • El Proceso Unificado

22. El Proceso Unificado • “Es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational" • El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. • El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. • El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. • El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas.

23. Proceso unificado (UP) Sitúa su espiral principal en su fase de construcción: • Inicio: Visión aproximada, análisis del negocio, alcance, estimaciones imprecisas. Finaliza con el compromiso del patrocinador del proyecto de seguir adelante, conocidos el caso de negocios del proyecto, su viabilidad y alcance básicos. • Elaboración: Visión refinada, implementación iterativa del núcleo central de la arquitectura. Resolución de los riesgos altos. Identificación de otros requisitos y alcance. Estimaciones mas realistas. Finaliza con • La arquitectura básica del sistema en cuestión. • Un plan convenido para la construcción • Todos los riesgos significativos identificados. • Los principales riesgos comprendidos lo suficiente • Construcción: Implementación iterativa de los restantes requisitos de menor riesgo y elementos mas fáciles. Preparación para el despliegue. Finaliza con una versión beta del sistema. • Transición: Pruebas beta. Proceso de presentación del sistema a sus usuarios. Despliegue.

24. El Proceso Unificado (UP) visitado nuevamente • El Proceso Unificado es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. • Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational, donde confluyen 'los tres amigos' como se llaman a sí mismos los tres grandes de la OO: Grady Booch, James Rumbaugh e Ivar Jacobson.

25. El UP … (2) • El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. • El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. • El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. • El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas.

26. Disciplinas del UP Tomado de Larman, p21

27. Disciplinas y fases del UP • Las disciplinas (flujos de trabajo) del UP son el conjunto de actividades y artefactos (productos del trabajo: códigos, gráficos Web, esquema de base de datos, documentos de texto, diagramas, modelos, etc.) relacionados en un área determinada. • Modelado del negocio: Consiste en modelar los objetos del dominio. A gran escala, referencia el modelado de los procesos de negocio de toda la empresa. • Requisitos: Análisis de los requerimientos para una aplicación: escritura de casos de uso e identificación de requisitos no funcionales. • Diseño: Todos los aspectos, incluyendo arquitectura global, objetos, bases de datos, comunicación en red, etc. Tomado de Larman, p21

28. Enfoque del UP El Proceso Unificado ha adoptado un enfoque que se caracteriza por: • Interacción con el usuario continua desde un inicio. • Mitigación de riesgos antes de que ocurran. • Liberaciones frecuentes. • Aseguramiento de la calidad. • Involucrar a todo el equipo en todas las decisiones del proyecto. • Anticiparse al cambio de requerimientos. • Se enfoca en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reutilización.

29. Perspectivas de arquitectura • Se considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa: • Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios. • Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. • Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios y como poner esa información eficientemente en manos de quienes la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. • Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.

30. Características • Una vista arquitectónica es "una descripción simplificada (una abstracción) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva" [Booch]. • Según el mismo autor, las características primordiales del Proceso Unificado son: • Iterativo e incremental • Centrado en la arquitectura • Guiado por casos de uso • Confrontación de riesgos • El diseño del software se realiza a tres niveles: conceptual, lógico y físico.

31. Sistema, diseño, modelo, diagrama • Cualquier proceso de desarrollo pretende producir un sistema. • El diseño, y especialmente la arquitectura del sistema, incorporan las decisiones importantes sobre cómo construirlo, abstrayéndose de muchos detalles. • Se construirán diferentes modelos del diseño utilizando diagramas en un lenguaje de modelado: • Modelo de casos de uso: describe el sistema requerido desde el punto de vista del usuario. • Modelo estático: describe los elementos del sistema y sus relaciones. • Modelo dinámico: describe el comportamiento del sistema a lo largo del tiempo.

32. Vistas • Lógica: ¿qué partes teóricamente están juntas? ¿cuáles son las clases? ¿cómo están relacionadas? Se modela para comprobar los requisitos funcionales. • De proceso: ¿qué hilos de control existen? ¿qué cosas pueden darse concurrentemente? ¿Cuándo sincronizar? Ayuda a asegura que se cumplan los requisitos no funcionales tales como la disponibilidad y las prestaciones. • De desarrollo: ¿qué partes puede desarrollar el mismo equipo de personas? ¿qué puede reutilizarse? Ayuda a gestionar el proyecto. • Física: ¿qué partes se ejecutarán sobre el mismo computador? Ayuda a asegurar que se cumplan los requisitos no funcionales. Es una vista mas concreta que la vista de proceso.

33. Conceptos clave del UP • El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson]. • Según [Booch], los conceptos clave del Proceso Unificado son: • Fase e iteraciones: ¿Cuándo se hace? • Flujos de trabajo de procesos (actividades y pasos): ¿Qué se está haciendo? • Artefactos (modelos, reportes, documentos): ¿Qué se produjo? • Trabajador: un arquitecto ¿Quién lo hace?)

34. Diseño conceptual • Se considera como un análisis de actividades y consiste en la solución de negocios para el usuario. Se expresa con los casos de uso. • El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: • Identificar los usuarios y sus roles. • Obtener datos de los usuarios • Evaluar la información • Documentar los escenarios de uso • Validar con los usuarios • Validar contra la arquitectura de la empresa • Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución. • Este tema se ampliará en próximas clases.

35. Diseño lógico • Traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. • El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. • El diseño lógico es independiente de la tecnología. Refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. • Un objeto de negocios es el encapsulado de un servicio que abstrae las cualidades esenciales de algo de interés. • Un servicio es una unidad con capacidad de cómputo que debe satisfacer: • Ser seguro, lo que equivale a un uso correcto y con autorización • Ser válido, qué tareas o reglas se pueden aplicar • Manejar excepciones, informando al cliente • Contar con un catálogo de servicios que constituye un repositorio de servicios.

36. Objetos de negocio • Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos operen como unidades completas de trabajo. • Las tareas de verificación incluyen: • Una verificación independiente: • Pre y post condiciones • Lógica y funcionalidad individual • Una verificación dependiente: • Verificación de dependencias • Que operan como una unidad específica de trabajo

37. Tareas del diseño lógico • Identificar y definir los objetos de negocio y sus servicios. • Definir las interfaces. • Identificar las dependencias entre objetos. • Validar contra los escenarios de uso. • Comparar con la arquitectura de la empresa. • Revisar y refinar tanto como sea necesario. Para definir los objetos de negocios y sus servicios se puede usar la técnica de análisis nombre-verbo de los escenarios de uso. También se puede emplear la técnica sujeto-verbo-objeto directo. En estas técnicas, los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios.

38. Interfaces • Una interfaz tiene las siguientes partes: • Nombre. • Precondiciones: Lo que debe estar presente antes de ejecutarse • Postcondiciones: Estado final • Capacidad ó funcionalidad (SQL, seudo código, función matemática) • Dependencias • La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización de tareas de negocios transaccional ó coordinadamente.

39. Consideraciones con las interfaces • Identificar los eventos disparadores (triggers). • Determinar cualquier dependencia (existencial o funcional). • Determinar cualquier problema de consistencia o secuencia. • Identificar cualquier regulación de tiempo crítica. • Considerar algún problema organizacional (transacciones). • Identificar y auditar los requerimientos de control. • Determinar lugares y dependencias a través de la ubicación. • Determinar cuando el servicio que controla la transacción es dependiente de los servicios contenidos en otros objetos de negocio.

40. Validación del modelo lógico • Debe ser tal que garantice que éste sea: • Completo: Debe representar todos los escenarios de uso, • Correcto: El comportamiento lógico debe corresponder con el comportamiento conceptual, y • Claro: Los objetos de negocio y servicios no deben ser ambiguos. • En el diseño lógico conceptualmente se divide en tres niveles de servicios: • de usuario, • de negocio y • de datos; con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias.

41. Servicios de usuario (user services) • Controlan la interacción. • Un servicio de usuario son: personas, aplicaciones, otros servicios o la combinación de éstos. • Generalmente involucra una interfaz gráfica de usuario (GUI) u otra interfaz que puede ser no visual (mensajes o funciones); la cual maneja todos los aspectos de la interacción con la aplicación. • El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. • Cuando es necesaria la comunicación, un servicio de usuario incluye un contenido: qué se necesita comunicar al usuario; y una forma: cómo se comunica el contenido.

42. Servicios de negocio(bussines services) • Convierten datos recibidos de los servicios de datos y de usuario en información: datos + regla de negocio. • Las tareas de los servicios de negocio son: • Dar formato a los datos • Obtener y mover datos desde y hasta los servicios de datos • Transformar los datos en información • Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transacción. • Pueden usar otros servicios de negocio para completar su tarea.

43. Servicios de datos (data services) • Son los servicios de bajo nivel que apoyan a los servicios de negocio e incluyen una amplia gama de categorías: • Declaración del esquema y su evolución: Estructuras de datos, tipos, acceso indexado, SQL, APIs, etc. • Respaldo y recuperación: Recuperación de datos si un evento falla. • Búsqueda y Lectura: Búsquedas, compilación, optimización y ejecución de solicitudes. Formación de un conjunto de resultados. • Inserción, actualización y borrado: Procesar modificaciones consistentemente transaccional. Una transacción es • Atómica: Ocurre o no, • Consistente: Preserva la integridad, • Aislada: Otras transacciones ocurren antes o después; y • Durable: Una vez completada, sobrevive.

44. Servicios de datos (2) • Bloqueo: Permite al acceso concurrente a los datos. • Validación de datos: Verifica la integridad del dominio, triggers y gateways, para comprobar el estado de los datos antes de aceptarlos: manejo de errores. • Seguridad: Acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios. • Administración de la conexión: Mecanismos básicos para establecer una sesión de los servicios de datos. Establecer una conexión involucra: una identificación, la colocación y provisión de datos, el tiempo de sesión y el tipo de interacción: conversacional, transaccional, multiusuario, monousuario. • Distribución de datos: Distribuye información, a múltiples unidades de recuperación, a bases de datos heterogéneas, etc.; según la topologías de la red.

45. Diseño físico • Traduce el diseño lógico en una solución implementable y costo-efectiva o económica. • En el diseño físico se debe cuidar • el nivel de granularidad: un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico; y • la agregación y contención: un componente puede reutilizarse mediante técnicas de agregación y contención, sin duplicar el código.

46. Componente • La unidad de construcción elemental del diseño físico es el componente. • Las características de un componente son: • Se define según cómo interactúa con otros. • Encapsula sus funciones y sus datos. • Es reutilizable a través de las aplicaciones. • Puede verse como una caja negra. • Puede contener otros componentes.

47. Características de diseño físico El diseño físico debe involucrar: • El diseño para distribución: Debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red. • El diseño para multitarea: Debe diseñarse en términos de la administración concurrente de dos ó más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso. • El diseño para uso concurrente: El desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.

48. Características … (2) • El diseño con el manejo de errores y prueba de eventos: • Validando los parámetros a la entrada antes de continuar con cualquier proceso. • Protegiendo recursos críticos: Manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria. • Protegiendo datos importantes: Contar con una excepción a la mitad de la actuación en las bases de datos. • Puesta a punto (Debugging): Crear una versión para limpiar errores. • Protección integral de transacciones de negocios: Los errores deben regresarse al componente que llama.

49. Tareas de diseño físico • El diseño físico comprende las siguientes tareas: • Definir los componentes • Refinar el empaquetamiento y distribución de componentes • Especificar las interfases de los componentes • Distribuir los componentes en la red • Distribuir los repositorios físicos de datos • Examinar la tolerancia a fallas y la recuperación de errores • Validar el diseño físico • De las tareas anteriores, la más importante es la distribución de los datos, que pueden estar centralizados, como una partición, en un extracto ó ser una réplica.

50. Distribuciones de datos (1) • Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. • Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay superposición entre particiones. En una partición horizontal, cada hilera existe en una sola base de datos. En una partición vertical, cada columna es contenida en una y solo una base de datos.