Este documento describe los conceptos clave de la ingeniería de software y la gestión de proyectos de desarrollo de software. Explica las fases típicas de un proyecto de desarrollo de software, incluido el análisis, diseño, desarrollo, prueba y mantenimiento. También discute los modelos de ciclo de vida de software, la participación del equipo, la planificación económica y el control de configuración.

1. GESTION DE PROYECTO DE DESARROLLO DE SOFTWAREAydee Fonseca MedinaDecimo Semestre Ingeniería de SistemasUAN – NEIVA2010

2. La ingeniería del Software es definida como la disciplina que se encarga de ofrecer métodos y técnicas para desarrollar y mantener software de calidad. *Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978) *Es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software (Bohem, 1976).

3. Trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972). Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993). La ingeniería del software parte del concepto de ciclo de vida como conjunto de actividades que ocurren durante el desarrollo de software, esto es determinar la secuencia desde que se inicia hasta que termina. En un ciclo de vida participan: Gestor, Analista, Usuarios, plan de software, Requisitos de software, Equipo SW.

4. Interrelación de los agentes que configuran el proceso de desarrollo de softwareGESTORUSUARIOSEQUIPO SWANALISTAPLAN SOFTWAREREQUISITOS SOFTWARE

5. Fases del ciclo de vida Existen muchas metodologías de desarrollo de software, pero todas ellas comprenden los mismos pasos y las mismas técnicas. Fase de análisis y planificación del sistema. Comprende: -Definición de requisitos de usuarios (RU) -Definición de requisitos de software (RS) Fase de Desarrollo. Incluye: -Diseño de la arquitectura(DA)-Diseño detallado y codificación(DD)-Transferencia (TR) Fase de operación y mantenimiento (OM)

6. Fase de análisis y Planificación Objetivo: Definir exactamente qué es lo que se pretende que el software a desarrollar haga, y cómo queremos que lo haga, respondiendo a las preguntas tales como: ¿Qué es lo que debe hacer el sistema? ¿Qué es lo que debe hacer el software a desarrollar? ¿En qué condiciones debe funcionar? ¿Qué limitaciones tendrá? ¿Cómo se implantará? ¿Qué recursos materiales, temporales y humanos hacen falta para ello? ¿Cómo se verificará que el sistema funcione correctamente?

7. Fase de análisis y planificación Esta fase comienza con la definición del sistema global (hardware, software, etc.) y la caracterización del problema a resolver, de donde se extraen las pertinentes conclusiones acerca de las restricciones temporales, económicas. Fase (o sub-fase) de definición de los requisitos de usuario(RU): Documentación del sistema, entrevista con el Cliente o usuarios, construcción de prototipos o cualquier otro procedimiento que se estime oportuno, se “capturan” los requisitos que debe cumplir el sistema con el fin de que satisfaga las necesidades del usuario.

8. Fase: Definición de requisitos del software (RS): Objetivo: Construir un modelo conceptual de lo debe hacer el software, estimar el coste asociado al mismo (con una precisión aproximada del 30%), y definir las responsabilidades individuales dentro del equipo de trabajo.Concluida esta fase se da por terminada la participación directa del cliente o usuario, como parte interesada en el proceso de definición del trabajo. A partir de este momento, al comenzar la fase de desarrollo, el Cliente pasa a ser un supervisor del avance de los trabajos, como en cualquier otro tipo de proyecto.

9. Fase de análisis y planificación DEFINICON DE REQUISITOOSREVISION DE REQUISITOSPLANIFICACIÓNCOSTE RECURSOS PLANIFICACIONDATOS DE USUARIODEFINICION DEL SISTEMAFUNCIONES HARDWAREREVISION REQUISITOS SOFTWARE(RRS)DEFINICION REQUISISTOS SOFTWARE (DRS)NECESIDADDISEÑO, OPERACIÓN, MANTENIMIENTO

10. Fases de Desarrollo Comienza con la aprobación formal de los requisitos del software por parte del usuario o Cliente hasta la puesta en funcionamiento del sistema, incluyendo tres sub-fases, de diseño de alto nivel, diseño detallado y transferencia.La fase (o sub-fase) de diseño de alto nivel o diseño arquitectónico(DA) Objeto: Definir la estructura del software a desarrollar a partir del modelo establecido en la fase RS. Dicha arquitectura se obtiene asignando funciones a componentes de software, y definiendo los flujos de datos y de control entre dichas componentes.

11. Fase de Diseño detallado (DD). Objetivo: Refina los detalles más significativos el diseño de alto nivel de la fase anterior, se codifica, documento y prueba. La verificación y pruebas del software, debe realizarse a cuatro niveles diferentes: A nivel de unidad de software. A nivel de integración de todas las unidades software. A nivel de validación del software con respecto a los requisitos de DRS. A nivel del sistema completo, según los requisitos de usuario (DRU)

12. Fase de transferencia (TR) Objeto: Se instala el software sobre la plataforma (hardware) final, se lleva a cabo los test de aceptación especificada, y se comprueba que el programa satisface los requisitos para los que fue concebido. En tales condiciones el software recibe la aceptación provisional, y comienza su operación y uso.

13. Fase de Desarrollo ESTANDARESDRSDARDADDRDDDDAPlan Desarrollo DDPLAN DESARROLLO DADDDCODIFPlan Desarrollo TRTU1TUnMUS…SRDTRTEST INTEGRTEST VALIDTEST SISTEMASOFTWARETRANSFERIDOSWINTEGRADA

14. Fase de Operación y Mantenimiento (OM) Fase de operación, es la de supervisión (y corrección de los vicios o defectos del producto). Fase de Mantenimiento, a las modificaciones que se le deben realizar al software como consecuencia de errores detectados, o como respuesta ante nuevas necesidades del usuario. Durante la fase de OM, se genera y actualiza el documento de historia del proyecto (DHP), que reúne todos los errores y todas las modificaciones realizadas sobre el software, y que permite calcular y analizar la fiabilidad del software, y el rendimiento del equipo de trabajo (para futuros proyectos).

15. Fase de Operación y Mantenimiento SISTEMADEFINITIVAMENTEDTROPERACIÓN Y EVALUACIOACEPTACION DEFINITIVASWProvisionalmente aceptadoDHPERRORESREGISTRO DE MANTENIMIENTOMMTO Y DEPURACIONREGISTRO DE FALLOSMODELO DE FIABILIDADFIABILIDAD

16. Tipos de ciclo de vida Se adopta un modelo de ciclo de vida que defina en que secuencia relativa se ejecuta cada fase y, sobre cambios al software.Modelo en Cascada o Waterfall Cada fase se ejecuta una única vez, a continuación de la que le precede y con inmediata anterioridad a la que le sigue. Cuando en una fase se detectan errores o cambios que deben incluirse, se debe hacer una iteración en la fase inmediatamente anterior.

17. Modelo en Cascada o WaterfallRURSDADDTROM

18. Modelo Incremental Coincide con el modelo de cascada hasta el final de la fase de diseño de alto nivel (DA). A partir de ese momento, las fases DD, TR y OM se descomponen en un cierto número de unidades menores, más simples y manejables, que se implantan por separado.RURSDADD1TR1OM1DD2TR2OM2

19. Modelo Evolutivo Se diferencia del incremental en que no se reaprovechan las fases de requisitos ni de diseño arquitectónico, y que todas las versiones del producto son el resultado de un ciclo completo que incorpora toda la experiencia de los ciclos precedentes. Se utiliza cuando existe la intención a priori, de liberar en el tiempo varias versiones del mismo desarrollo del software. Obliga a mantener “vivas” varias versiones a la vez, en el caso de haya más de un usuario y no se produzca un cambio coordinado de versiones entre todos los usuarios a la vez. Los costes se incrementan de manera notable. Provoca frustración en los usuarios, que perciben cada versión como una corrección de errores de la anterior y, en definitiva, como un software aún no terminado por completo.

20. RURSDADDOM1TRRURSDADDOM2TRRURSDADDOM3TR

21. EVALUACIÓN ECONOMICA Objetivo: Ayudar al responsable de un proyecto a identificar las peculiaridades de un trabajo de este tipo que tienen incidencia sobre los aspectos de gestión del mismo, como son: -La descomposición en actividades y tareas. -La configuración del equipo de trabajo -La planificación más adecuada. -El riesgo en el que se incurre. -El control de configuración de los elementos del proyecto.

22. EVALUACIÓN ECONOMICAVolumen relativo de participación según categoría y fase del proyecto

23. Participación del equipo de trabajo en cada fase. La experiencia demuestra que el nivel al que se involucran en el proyecto cada tipo de persona (según la categoría profesional a la que pertenece) cambia durante el ciclo de vida del proyecto.Modelos de costes de desarrollo software. Modelo “40-20-40” -El 40% del esfuerzo total se destina a tareas de análisis y planificación, el 20% a codificación y transferencia, y el 40% restante a validación y pruebas. -Del 40% asociado a las tareas de análisis y planificación, a su vez, el 40% se destina a labores de planificación, el 20% al análisis de requisitos y el 40% restante a actividades de desarrollo.

24. Modelos de costes de desarrollo software.Modelo “40-20-40” -El 40% del esfuerzo total se destina a tareas de análisis y planificación, el 20% a codificación y transferencia, y el 40% restante a validación y pruebas. -Del 40% asociado a las tareas de análisis y planificación, a su vez, el 40% se destina a labores de planificación, el 20% al análisis de requisitos y el 40% restante a actividades de desarrollo.

25. Modelo “40-20-40”

26. Coste de los cambiosEl coste de un cambio en el alcance del trabajo depende en gran medida del momento en el que se identifique la necesidad del mismo. Según avanza el ciclo de vida del proyecto, el coste de un cambio individual se incrementa, según muestra la gráfica. En la figura muestra cómo los cambios a los requisitos implican costes bajos en la etapa de análisis y planificación del sistema, costes que crecen de manera abultada al comenzar las fases de diseño, pruebas y transferencia, y que se estabilizan durante la fase de operación y mantenimiento.

27. Coste de mantenimiento Se deben considerar dos aspectos: Todo contrato estipula una cobertura por garantía, y la responsabilidad del equipo de trabajo se limita a dicho período, exclusivamente. Incluso aunque se detecte un defecto en la realización del software, el equipo no tiene porque responsabilizarse del mismo si se ha agotado dicho período. Tipo de mantenimiento Correctivo, es decir, aquél orientado a corregir los defectos de diseño e implantación del software, siendo responsabilidad del contratista solo este mantenimiento.

28. CONTROL DE CONFIGURACION El control de configuración (gestión de la documentación y de los productos) de un proyecto. Conviene considerar configurable, los siguientes elementos: Documentación Código de Fuente Código objeto y ejecutables. Ficheros. Herramientas de desarrollo. Herramientas de validación y prueba. Conjunto de datos (de prueba, de configuración, etc.).

29. Cada vez que alguna de las partes (cliente, equipo de trabajo, usuarios) detecte algún fallo o disconformidad en el software o en la documentación generada en el proyecto, es conveniente generar, como parte de las actividades de control de configuración, una hoja de notificación de disconformidad, donde se refleje y describa la misma, la solución recomendada y la solución adoptada. La figura Muestra un posible formato para esta hoja de incidencia.

31. Tener una idea clara de los cambios realizados sobre los elementos configurables, los autores de los mismos, las razones de los cambios, etc. Plasmar documentalmente la evolución de las diferentes versiones y revisiones de cada elemento configurable. Dirimir a posteriori las responsabilidades derivadas de cambios (o no cambios) en los elementos de configuración del proyecto. Controlar todas las disconformidades y documentar el proceso y resolución de las mismas.

32. Muestra un posible formato para el informe de modificación del software, como respuesta a un cambio al mismo, en el que se documentan los cambios realizados, el responsable y la fecha, así como las razones de la modificación y el esfuerzo asociado a las mismas.

33. Muestra un posible formato para la hoja de control de configuración de cada documento. Por lo general, dicha hoja forma parte del propio documento (a continuación de la portada), y sirve para reflejar qué versión del documento se está manejando, y qué cambios y modificaciones incluye con respecto a ediciones anteriores del mismo.

35. RECOMENDACIONES FINALES En cuanto a la Planificación del trabajo, tener en cuenta que: -Los desarrollos de software son tareas de muy alto valor añadido, donde la transformación de bienes es prácticamente inexistente, y en las que el resultado (el software) es un producto intangible de mucha complejidad y difícil de analizar. -Conviene elegir y aplicar desde el principio un modelo de ciclo de vida y un conjunto de metodologías de desarrollo, que se mantendrán durante todo el proyecto. -No es conveniente solapar las fases del desarrollo. -Definir desde el principio un plan de validación del software y un plan de aceptación del mismo que permita establecer un límite claro a las obligaciones y a la responsabilidad del equipo de trabajo, ante el cliente y / o los usuarios.

36. Con respecto a los requisitos: -La correcta especificación de los requisitos es clave para la culminación, con éxito del proyecto. -La especificación de los requisitos del usuario es responsabilidad única del usuario (aunque se le preste la ayuda necesaria para desenvolverse adecuadamente en dicha tarea). -Hay que definir requisitos completos, consistentes, verificables y que se propaguen a través de todo el ciclo de desarrollo del software. La evaluación económica: -Hay que valorar proporcionalmente el esfuerzo necesario para la gestión, planificación, prueba y mantenimiento, y no sólo las actividades de desarrollo y codificación. -Hay que valorar adecuadamente el impacto de un control de configuración adecuado sobre el coste del proyecto.

37. GRACIAS ………