ACI491: Ingeniería de Software

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

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 Capital El Proceso Unificado
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.

51 Distribuciones de datos (2)
Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa una etiqueta de tiempo (timestamp) para indicar qué tan viejos son los datos. Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe de haber sincronización entre ambas.

52 Alternativas tecnológicas
El diseño físico está íntimamente ligado a una alternativa tecnológica. Ante la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias, ya que una mala decisión implicará un costo enorme -en dinero y en tiempo- al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado (ó liviano) que no acapare al servidor, comunicándose entre sí en una plataforma Internet con protocolos estándar en redes heterogéneas.

53 Herramientas de ingeniería de software
Un ingeniero de software necesita herramientas. Las herramientas de Rational son las más avanzadas, pero son muy costosas. La versión de prueba dura sólo 30 días. También pueden utilizarse las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de código abierto y aún están de desarrollo. Herramientas de Ingeniería de Software: Enlace a información sobre las herramientas líderes que implementan la ingeniería de software, desde el modelado de sistemas con UML hasta el proceso unificado que tiene que ver con la administración de proyectos.  SourceForge.net: Es una base de datos de proyectos de software de código abierto u open source software, generalmente gratuitos (freeware), bajo licencia GNU ó equivalente.

54 Ejemplo de herramienta: MS Visio

55 Ejemplo de herramienta: Power Designer

56 Ejemplo de herramienta: NetBeans

57 Ejemplo de herramienta: ArgoUML

58 Otras herramientas ampliamente difundidas
Borland Together Enterprise Architect Visual – Paradigm IBM Rational

59 Preparación para un proyecto de Modelado
IBM Rational Rose Preparación para un proyecto de Modelado

60 Introducción El modelado contribuye al desarrollo satisfactorio de sistemas complejos. Como preparación para un proyecto de modelado, debe crear una base que permita que los miembros del equipo trabajen conjuntamente para crear un conjunto de modelos conceptuales. Los modelos conceptuales son aquellos que expresan conceptos abstractos como, por ejemplo, guiones de uso, clases de análisis y componentes de diseño. Estos modelos no están estrechamente vinculados al código de implementación y se almacenan en archivos con extensiones de nombre de archivo .emx. Los modelos conceptuales son distintos de los modelos de implementación, que constan del código de implementación y diagramas de código que se almacenan en archivos con extensiones de nombre de archivo .dnx. Un modelo de implementación equivale al proyecto que contiene el código y los diagramas de código.

61 Rol de modelado y desglose del trabajo
Debe decidir cómo desea utilizar los modelos conceptuales en la tarea de desarrollo. Por lo general, los modelos conceptuales se utilizan para desarrollo dirigido, o bien, con fines retrospectivos (por ejemplo, como un formato de documentación). La herramienta proporciona plantillas de modelo que se pueden utilizar para crear instancias de nuevos modelos conceptuales de tipos específicos como, por ejemplo, guiones de uso, análisis y diseño IT empresarial. Por lo general, las plantillas proporcionan una estructura de paquete UML básica y algún contenido de ejemplo. También pueden contener algunos perfiles de proyectos UML2 aplicados. Si utiliza modelos conceptuales para desarrollo dirigido, debe determinar los aspectos siguientes:

62 Rol de modelado y desglose del trabajo
Qué tipos de modelos (por ejemplo, guión de uso, análisis y diseño IT empresarial) se van a utilizar La composición (conjuntos de niveles y tamaños) del equipo de modelado conceptual. El ámbito anticipado de la tarea de modelado conceptual. Cómo dividir las asignaciones del trabajo de modelado conceptual entre los miembros del equipo Qué probabilidades hay de que varios miembros del equipo trabajen simultáneamente en las mismas áreas de los modelos conceptuales. Qué herramienta de gestión de la configuración se va a utilizar para almacenar y crear versiones de activos de modelos conceptuales, y los flujos de trabajo de gestión de configuración típicos

63 IBM - Rational

64 Calidad de Software Administración de la Calidad del Software

65 Reflexión final Todo lo visto muestra tal como la teoría aconseja que se deben hacer las cosas. En la práctica común de la ingeniería de software frecuentemente se menosprecia el valor de una metodología para crear el producto de software, lo que demerita la incipiente profesión de Ingeniero de Software en particular, la del especialista en Tecnologías de la Información, en general y a las empresas de Consultoría de software, ya que en múltiples ocasiones se cede ante el “chantaje” profesional del jefe o del cliente, quien ordena la construcción del software con argumentos como: “¡No hay tiempo para eso! ¡A programar!"

66 Reflexión final (2) Para reflexionar, preguntémonos:
¿Qué pasaría si el ingeniero civil o el arquitecto construye una casa o un edificio sin hacer sus planos, proyectos y maquetas? ¿Cree que la obra pueda concluirse cubriendo las necesidades, con la calidad necesaria y a tiempo? ¿Permitiría que un cirujano le interviniera sin hacer los estudios respectivos para obtener las evidencias del problema de salud que le aqueja? ¿Permitiría a un abogado que le defendiera sin conocer las pruebas y sin un plan para su defensa?

67 ¿Entonces …? ¿Por qué los ingenieros en software ceden a veces ante el “chantaje de la falta de tiempo” y construyen software sin el análisis y diseño expresado en un proyecto, más allá de las ideas existentes “en su cabeza”? ¿Por qué se intenta hacer análisis y diseño sobre la marcha, pero nunca se concluyen, pues ya no hay tiempo? ¿Dónde queda la ética profesional? Consulte, como referencia, el Código de Ética del Ingeniero en Software y de la Práctica Profesional en el sitio de la Association for Computing Machinery.

68 Fuentes de información
Sommerville, I. “Ingeniería de Software” 7ma edición. Pressman, R. “Ingeniería de Software: Un enfoque práctico” 5ta edición: cap 2 12p cap 5 22p Kendall, K.E. y Kendall, J.E. “Análisis y diseño de sistemas” 6ta edición. ¿Qué son los Stakeholders?

69 Referencias Stevens, P. “Utilización de UML en Ingeniería del Software con Objetos y Componentes”, Addison Wesley, 2002 (en inglés: “Using UML: software engineering with objects and components”) Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004 Grady Booch, James Rumbaugh, Ivar Jacobson “The Unified Modeling Language User Guide”, Addison Wesley, 1998 OMG Unified Modeling Language Specification, Version 1.3, June 1999 Kruchten, P. “The Rational Unified Process”, Addison Wesley, 2000

70 Referencias en Internet
Ingeniería de Software. Conceptos y evolución. Ingeniería del software basada en componentes. Curso sobre Ingeniería del Software Basada en Componentes. Wikipedia: Programación Orientada a Objetos Lenguaje Unificado de Modelado Proceso Unificado de Desarrollo Software Programación Orientada a Aspectos Patrón de diseño

71 Referencias en Internet (en inglés)
The Object Oriented Programming Web The Object Management Group (OMG) Introducing UML: Object-Oriented Analysis and Design Architecture & Design: Overview Computer programming/Object oriented programming Topic: Object-Oriented Programming

72 Referencias de Microsoft
MSDN Domain-Specific Language Tools MSDN Software Factories Microsoft patterns & practices Developer Center patterns & practices: Web Applications MSDN Solution Architecture Center

73 Literatura presente ya en Internet
Booch G Software Architecture and the UML. Presentación disponible en: como arch.zip. Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999 Disponible en: Conallen, J. "UML Extension for Web Applications 0.91" Drafted Conallen, Inc. 22-Mar-1999 Disponible en: Jacobson, I "Applying UML in The Unified Process" Presentación. Rational Software. Presentación disponible en como UMLconf.zip Microsoft y Rational A White Paper on the Benefits of Integrating Microsoft Solutions Framework and The Rational Process. Rational Software Corporation y Microsoft Corporation. Documento msfratprocs.doc Disponible en Object Management Group OMG Unified Modeling Language Specification (Draft). Versión 1.3. alfa R5, marzo de Disponible en:

74 Literatura aún ausente de Internet
Booch, G Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2. Feb pp Cota A "Ingeniería de Software". Soluciones Avanzadas. Julio de pp Greiff W. R. Paradigma vs Metodología; El Caso de la POO (Parte II). Soluciones Avanzadas. Ene-Feb pp Jacobson, I. et. al Object-Oriented Software Engineering; A Use Case Driven Aproach. ACM Press. Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus. pp Lewis G "What is Software Engineering?" DataPro (4015). Feb pp [Microsoft 1997] Microsoft Microsoft Solutions Framework 1.0. Microsoft Corporation. USA.

75 Adictos al trabajo Todos los Tutoriales
Gestión de proyectos con Project Este tutorial enseña como crear un plan, realizar seguimiento del proyecto, como cerrarlo y comunicar sus resultados. Problemas al planificar un proyecto Este tutorial /artículo presenta una plantilla modelo (básica) para un proyecto software (orientado a aplicaciones Web/Java OOP) Se comenta por qué es tan difícil cumplir con un plan de proyecto informático. Repositorio CVS en Windows Muestra como montar un servidor para control de versiones CVS en Windows y como accederlo mediante WinCVS. Todos los Tutoriales