Gestión de Desarrollo de Sistemas

1. Material de complementario de lectura para la asignatura de:
Gestión de Desarrollo de Sistemas de Información
ADMINISTRACIÓN DE PROYECTOS
CICLO DE VIDA
El método de ciclo de vida del desarrollo de los sistemas a menudo funciona bien en los grandes proyectos con requerimientos bien definidos, donde no hay mucha presión para terminar rápido el proyecto. El uso de este método requiere una administración apropiada y efectiva, lo que posiblemente incluye a un usuario como el líder, si el proyecto no es altamente técnico.
La elaboración de prototipos: Es útil en situaciones donde los requerimientos se definen pobremente y/o cuando se necesita velocidad, para esto se requiere una administración efectiva para asegurar que las interacciones en la elaboración de prototipos no continuarán indefinidamente. Es importante contar con herramientas como lenguajes de software de cuarta generación y generadores de pantalla. Desarrollo rápido de aplicaciones (DRA): Es necesario cuando los nuevos sistemas se necesitan muy rápido. El desarrollo rápido de aplicaciones tal vez es menos apropiado que los lenguajes de programación convencionales en grandes proyectos o para desarrollar sistemas con una gran cantidad de cálculos o con procesamiento en tiempo real. Desarrollo orientado a objetos: Este se está volviendo cada vez más popular, pero su uso se ve limitado por una escasez de personal que cuente con las habilidades

2. en este campo. Ej: Java es un lenguaje orientado a objetos que resulta especialmente adecuado para desarrollar aplicaciones de red, a pesar que este tipo de lenguaje tiende a ejecutarse lentamente. Desarrollo del usuario final: Aunque es más apropiado para proyectos pequeños, el desarrollo del usuario final constituye una posibilidad para proyectos más grandes cuyas prioridades no son muy elevadas, para conducir a una respuesta oportuna de la unidad central de sistemas de información. Comprar o subcontratar: En los sistemas más grandes y complejos que tienen un significativo riesgo de fracaso, las organizaciones deben considerar siempre la opción de recurrir a una fuente externa. Los ejecutivos necesitan estar conscientes de los costos relativamente altos de implementaciones adicionales que implican la compra de paquetes de software empresarial.
Características del ciclo de vida del proyecto
El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con su fin. Por ejemplo, cuando una organización identifica una oportunidad a la cual le interesaría responder, frecuentemente autoriza un estudio de viabilidad para decidir si se emprenderá el proyecto. La definición del ciclo de vida del proyecto puede ayudar al director del proyecto a determinar si deberá tratar el estudio de viabilidad como la primera fase del proyecto o como un proyecto separado e independiente. Cuando el resultado de dicho esfuerzo preliminar no sea claramente identificable, lo mejor es tratar dichos esfuerzos como un proyecto por separado. Las fases del ciclo de vida de un proyecto no son lo mismo que los Grupos de Procesos de Dirección de Proyectos.
Las fases del ciclo de vida de un proyecto son: Inicio → Planificación → Ejecución → Cierre del proyecto. La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente implica y, por lo general, está definida por alguna forma de transferencia técnica. Generalmente, los productos entregables de una fase se revisan para verificar si están completos, si son exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No obstante, no es inusual que una fase comience antes de la aprobación de los productos entregables de la fase previa, cuando los riesgos involucrados se consideran aceptables. Esta práctica de superponer fases, que normalmente se realiza de forma secuencial, es un ejemplo de la aplicación de la técnica de compresión del cronograma denominada ejecución rápida.

3. No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal de un proyecto. Algunas organizaciones han establecido políticas que estandarizan todos los proyectos con un ciclo de vida único, mientras que otras permiten al equipo de dirección del proyecto elegir el ciclo de vida más apropiado para el proyecto del equipo. Asimismo, las prácticas comunes de la industria a menudo conducen a usar un ciclo de vida preferido dentro de dicha industria.
Los ciclos de vida del proyecto generalmente definen:
 Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué fase se debe realizar el trabajo del arquitecto?)
 Cuándo se deben generar los productos entregables en cada fase y cómo se revisa, verifica y valida cada producto entregable
 Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente requiere que los implementadores estén involucrados en las fases de requisitos y de diseño)
 Cómo controlar y aprobar cada fase.
Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir formularios, diagramas y listas de control para proporcionar estructura y control.
La mayoría de los ciclos de vida de proyectos comparten determinadas características comunes:
 En términos generales, las fases son secuenciales y, normalmente, están definidas por alguna forma de transferencia de información técnica o transferencia de componentes técnicos.
 El nivel de coste y de personal es bajo al comienzo, alcanza su nivel máximo en las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión

4. Ilustración 1. Coste del proyecto y nivel de personal típicos a lo largo del ciclo de vida del proyecto [PMBOK®]
El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto. La certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto
El poder que tienen los interesados en el proyecto para influir en las características finales del producto del proyecto y en el coste final del proyecto es más alto al comienzo y decrece gradualmente a medida que avanza el proyecto. La ilustración 2 muestra este hecho. Una de las principales causas de este fenómeno es que el coste de los cambios y de la corrección de errores generalmente aumenta a medida que avanza el proyecto
Ilustración 2. Influencia de los interesados a lo largo del tiempo. [PMBOK®]
Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases similares y requieren productos entregables similares, muy pocos ciclos de vida

5. son idénticos. Algunos tienen cuatro o cinco fases, pero otros pueden tener nueve o más. En una misma área de aplicación pueden darse variaciones significativas. El ciclo de vida del desarrollo de software de una organización puede tener una única fase de diseño, mientras que otro puede tener fases separadas para el diseño arquitectónico y el detallado. Los subproyectos también pueden tener distintos ciclos de vida de proyectos.
Por ejemplo, una empresa de arquitectura contratada para diseñar un nuevo edificio de oficinas participa primero en la fase de definición del propietario, mientras hace el diseño, y luego en la fase de implementación del propietario, mientras da soporte al esfuerzo de construcción.
El proyecto de diseño del arquitecto, sin embargo, tendrá su propia serie de fases, desde el desarrollo conceptual, pasando por la definición e implementación, hasta llegar a la conclusión. El arquitecto puede, inclusive, tratar el diseño de los edificios y el soporte a la construcción como proyectos separados, cada uno con su propio conjunto de fases.
También podemos ver en la gráfica siguiente, como se relacionan las fases del ciclo de vida de un proyecto, con las personas que intervienen en él y su impacto en el coste del proyecto.
Ilustracion 3 (Kezner) People with the ability to influence cost

6. Igualmente lo podemos ver cómo según cambiamos de fase en un proyecto, se elevan los costes de los posibles cambios y se reducen la posibilidad de reducir costes.
Ilustracion 4 (Krezner9 People with the ability to influence cost
Características de las fases del proyecto
La conclusión y la aprobación de uno o más productos entregables caracterizan a una fase del proyecto. Un producto entregable es un producto de trabajo que se puede medir y verificar, tal como una especificación, un informe del estudio de viabilidad, un documento de diseño detallado o un prototipo de trabajo. Algunos productos entregables pueden corresponder al mismo proceso de dirección de proyectos, mientras que otros son los productos finales o componentes de los productos finales para los cuales se creó el proyecto. Los productos entregables, y en consecuencia las fases, son parte de un proceso generalmente secuencial, diseñado para asegurar el adecuado control del proyecto y para obtener el producto o servicio deseado, que es el objetivo del proyecto.
En cualquier proyecto específico, las fases se pueden subdividir en subfases en función del tamaño, complejidad, nivel de riesgo y restricciones del flujo de caja. Cada subfase se alinea con uno o más

7. productos entregables específicos para el seguimiento y control. La mayoría de estos productos entregables de las subfases están relacionados con el producto entregable de la fase principal, y las fases normalmente toman el nombre de estos productos entregables de las subfases: requisitos, diseño, construcción, prueba, puesta en marcha, rotación, entre otros, según corresponda.
Por lo general, una fase del proyecto concluye con una revisión del trabajo logrado y los productos entregables, a fin de determinar la aceptación, tanto si aún se requiere trabajo adicional como si se debe considerar cerrada la fase. Con frecuencia, la dirección lleva a cabo una revisión para tomar una decisión a fin de comenzar las actividades de la siguiente fase sin cerrar la fase actual, por ejemplo, cuando el director del proyecto elige la ejecución rápida como curso de acción. Otro ejemplo es cuando una compañía de tecnología de la información elige un ciclo de vida iterativo donde más de una fase del proyecto puede avanzar de forma simultánea. Los requisitos de un módulo se pueden recopilar y analizar antes de que el módulo sea diseñado y construido. Mientras se lleva a cabo el análisis de un módulo, se puede comenzar a recopilar los requisitos de otro módulo de forma paralela.
Del mismo modo, se puede cerrar una fase sin la decisión de iniciar alguna otra fase. Por ejemplo, el proyecto está completo o se considera que el riesgo es demasiado alto para permitir la continuidad del proyecto. La conclusión formal de la fase no incluye la autorización de la fase posterior. Para un control efectivo, cada fase se inicia formalmente para producir una salida, dependiente de la fase, del Grupo de Procesos de Iniciación, que especifique lo que está permitido y lo que se espera para dicha fase, como se muestra en la ilustración5. Se puede realizar una revisión al final de cada fase con el objetivo explícito de obtener la autorización para cerrar la fase actual e iniciar la fase posterior. En ocasiones, se pueden obtener ambas autorizaciones en una sola revisión. Las revisiones al final de cada fase son también conocidas como: salidas de fase, entradas a la fase o puntos de cancelación.

8. Ilustración 5 Secuencia de fases típicas en un Ciclo de Vida del Proyecto .[PMBOK®]
Relaciones del ciclo de vida del proyecto y del ciclo de vida del producto
Muchos proyectos están vinculados con el trabajo continuo de la organización ejecutante. Algunas organizaciones aprueban formalmente los proyectos sólo tras haber concluido un estudio de viabilidad, un plan preliminar o alguna otra forma equivalente de análisis. En estos casos, la planificación o el análisis preliminar adquiere la forma de un proyecto separado. Por ejemplo, se pueden presentar fases adicionales como resultado de desarrollar y probar un prototipo antes de iniciar un proyecto para el desarrollo del producto final. Algunos tipos de proyectos, especialmente los proyectos de desarrollo de servicios internos o productos nuevos, se pueden iniciar de manera informal durante un período limitado que permita obtener la aprobación formal de fases o actividades adicionales.
Las fuerzas impulsoras que crean los estímulos para un proyecto se conocen habitualmente como problemas, oportunidades o requisitos de negocio. El efecto de estas presiones es que, en general, la dirección debe priorizar esta solicitud con respecto a las necesidades y a las demandas de recursos de otros posibles proyectos.

9. La definición del ciclo de vida del proyecto también identificará qué tareas de transición al final del proyecto están incluidas y cuáles no, a fin de vincular el proyecto con las operaciones de la organización ejecutante. Por ejemplo, cuando se envía un nuevo producto a fabricación o comercializa un nuevo programa de software. Debe tenerse cuidado en distinguir entre el ciclo de vida del proyecto y el ciclo de vida del producto. Por ejemplo, un proyecto emprendido para colocar en el mercado un nuevo ordenador de escritorio es sólo un aspecto del ciclo de vida del producto. La Ilustración 6 muestra el ciclo de vida del producto que comienza con el plan de negocio, pasa por la idea, hasta llegar al producto, las operaciones y la retirada del producto. El ciclo de vida del proyecto atraviesa una serie de fases para crear el producto. Proyectos adicionales pueden incluir una actualización del rendimiento del producto. En algunas áreas de aplicación, tales como el desarrollo de nuevos productos o el desarrollo de software, las organizaciones consideran el ciclo de vida del proyecto como parte del ciclo de vida del producto.
Ilustración 6. Relación entre el ciclo de vida del producto y el ciclo de vida del proyecto. [PMBOK®]
TEMA 2
Ingeniería del Software
2.1 “P” de la ingeniería de software
Personas
Proceso
Proyecto
Producto
2.2 Fases genéricas
Definición
Desarrollo

10. Mantenimiento
Corrección
Adaptación
Mejora
Prevención Persona El factor humano siempre será el más importante en el desarrollo de soluciones de software muchos empresarios famosos, líderes de empresas tecnológicas, coinciden que el éxito que han alcanzado sus empresas no se debe a las herramientas que utilizan, son las personas y el trabajo en equipo. Por todos los medios posibles se debe atraer el personal talentoso e inteligente que desea superarse y sobre todo, desea trabajar en equipo para la realización del proyecto en que participe. El reclutamiento y selección es fundamental en la gestión del personal, aquí se ve realmente cuáles son las personas que están en la capacidad de aportar a la organización, y no sólo eso, también se ve si pueden trabajar bajo presiones y sobre todo en equipo. El proceso de software está integrado por participantes, líderes de equipo, arquitectos, desarrolladores, ingenieros de prueba, personal de gestión, usuarios, clientes, etc. Los participantes se los puede clasificar en cinco categorías: 1. Gestores ejecutivo: Definen los aspectos del negocio. 2. Gestores del proyecto: Planifican, motivan, organizan y controlan a los profesionales que construyen el software. 3. Profesionales: Proporcionan las habilidades técnicas necesarias. 4. Clientes: Especifican los requerimientos.

11. 5. Usuarios finales: Interactúan con el software. Los líderes de equipo juegan un importantísimo papel puesto que deben ser capaz de motivar al personal técnico para que produzca lo mejor sobre la base de su capacidad. El equipo de software debe ser uno solo, es decir, funcionar como conjunto, apoyarse mutuamente con el fin de lograr el cumplimiento de los objetivos planteados. Todos los miembros del equipo deben tenerse confianza y distribuir la carga de trabajo según el problema que se esté tratando. No todo equipo es eficiente, pero se puede lograr esto con la suficiente motivación y el apoyo de un buen gestor de proyectos. Producto Se denomina productos a todos aquellos artefactos que se creen durante la vida del proyecto, modelos, códigos, ejecutable, documentación, diagramas UML, bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba, ingeniería y gestión, colección de modelos, modelos de casos de uso, análisis, diseño, despliegue, implementación y prueba. Antes de planear un proyecto, se deben establecer los objetivos y el alcance que tendrá el proyecto, además de sus restricciones, herramientas, técnicas y planes de gestión. Con una buena planificación se puede estimar el tiempo que tomará desarrollar o construir el producto y redimensionar el valor cuantitativo del mismo. Definidos los objetivos y el dominio del producto se determinan soluciones alternativas y viables. Para lograr rapidez en la construcción del producto, se debe dividir la carga de trabajo entre el equipo de desarrollo, es decir, dividir el problema. Esto, con el fin de desarrollar con mayor eficiencia y eficacia y en el tiempo acordado con el cliente, el producto. Proceso Se denomina proceso al conjunto de actividades que se realizan para crear el producto (Plantilla para crear el proyecto). El proceso se define en términos de flujos de trabajo (conjunto de actividades), se identifican trabajadores y artefactos, además de que se utilizan diagramas de actividad de UML para describir los flujos de trabajo. El equipo de desarrollo debe elegir el proceso adecuado y que le permita obtener una solución o producto que satisfaga las necesidades o requerimientos del cliente. Seleccionado el modelo de procesos, se desarrolla una planeación preliminar del proyecto basado en las actividades del marco de trabajo. Esta planeación comienza con la combinación del producto y el proceso. Cuando el equipo de

12. desarrollo de software ha definido correctamente el modelo de proceso, debe de asegurarse de que este sea flexible y adecuado para el proyecto Proyecto Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. Es un elemento organizativo de gestión que establece una secuencia de cambios, por el cual va evolucionando diariamente. El mismo establece una serie de iteraciones e hitos dentro de los cuales se desarrollan una serie de casos de usos o requisitos. Debemos tener en cuenta muchos parámetros para realizar un proyecto con la calidad requerida, y saber que existen factores que atentan con el buen desempeño de un proyecto, estos son: 1. El personal de software no entiende las necesidades del los clientes. 2. El ámbito del producto está mal definido. 3. Los cambios se gestionan mal. 4. La tecnología elegida cambia. 5. Las necesidades comerciales cambian. 6. Los plazos de entrega no son realistas. 7. Los usuarios se resisten a la utilización del software. 8. Se pierde el patrocinio. 9. El equipo del proyecto carece de personal con las habilidades apropiadas. 10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.
2.1 Fases Genéricas de la Ingeniería del Software Fase de Definición: se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales: ingeniería de sistemas o de información, planificación del proyecto del software y análisis de los requisitos.

13. Fase de Desarrollo: se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: diseño del software, generación de código y prueba del software.
Fase de Mantenimiento: se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios: Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo. Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales. Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.
Por lo que los tipos de mantenimiento son:

14.  Perfectivo (60%): mejora del software (rendimiento, flexibilidad, reusabilidad) o implementación de nuevos requisitos. También se conoce como mantenimiento evolutivo.
 Adaptativo (18%): adaptación del software a cambios en su entorno tecnológico (nuevo hardware, otro sistema de gestión de bases de datos, otro sistema operativo...)
 Correctivo (17%): corrección de fallos detectados durante la explotación.
 Preventivo (5%): facilitar el mantenimiento futuro del sistema (verificar pre- condiciones, mejorar legibilidad...).
Es importante tener en cuenta el efecto del Iceberg, es decir, en el momento en el que se le hace mantenimiento a un Software no se cuenta muchas veces con el factor económico (¿Cuánto dinero se invertirá en el mantenimiento?), y una vez se comienza a desarrollar la fase de mantenimiento en la aplicación, comienzan a surgir nuevos requerimientos, el efecto del iceberg (en la superficie se ve solo una parte de lo que realmente es su tamaño).
Dificultades encontradas:
• Documentación inadecuada, obsoleta o inexistente.
• Componentes complejos.
• Componentes mal estructurados.
• Poca familiaridad de las aplicaciones.
• Presión del tiempo.
• Falta de comunicación y participación de los usuarios.
• Gran cantidad de requerimientos.
• Gran cantidad de parches.
Las fases y los pasos relacionados descritos se complementan con un número de actividades protectoras. Entre las actividades típicas de esta categoría se incluyen:
 Seguimiento y control del proyecto de software
 Revisiones técnicas formales
 Garantía de calidad del software
 Gestión de configuración del software

15.  Preparación y producción de documentos
 Gestión de reutilización
 Mediciones
 Gestión de riesgos
Metodología para el Desarrollo de Sistemas
Una Metodología para el Desarrollo, es un conjunto de actividades llevadas a cabo para desarrollar y poner en marcha un Sistema de Información.
Objetivos y Tipos de Metodologías Objetivos de las metodologías
• Definir actividades a llevar a cabo en un proyecto de sistemas
• Unificar criterios en la organización para el desarrollo de S.I.
• Proporcionar puntos de control y revisión. Tipos de Metodologías
• Estructurada
• Evolutiva-Incremental
• Prototipos
• Orientada a objetos
Etapas en el desarrollo de sistemas

16. Análisis de requisitos Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial. De esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-

17. 1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification). Diseño y arquitectura Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos. Programación Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga. La complejidad y la duración de esta etapa está íntimamente ligada al o a los lenguajes de programación utilizados. Pruebas Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría. Documentación Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas,

18. manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. Mantenimiento Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.
Modelos de proceso de sw / metodologías de desarrollo de sw (continúan en la siguiente entrega)
Bibliografía
Recuperado de http://www.ehu.es/asignaturasKO/PM/PMBOK/cap2PMBOK.htm

19. http://www.ecured.cu/index.php/Cuatro_P_%CC%81s, C atro P Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico (Quinta Edición). Madrid: Concepción Femández Madrid, 2005
GUÍA DE LOS FUNDAMENTOS PARA LA DIRECCIÓN DE PROYECTOS (Guía del PMBOK ® ) Quinta edición