Está en la página 1de 52

El proyecto informático de construcción de software

Miquel Barceló García
P03/75069/02141

© FUOC • P03/75069/02141

El proyecto informático de construcción de software

© FUOC • P03/75069/02141

El proyecto informático de construcción de software

Índice

Introducción .............................................................................................. 5 Objetivos ..................................................................................................... 7 1. El proyecto informático .................................................................... 9 1.1. Objetivos ........................................................................................... 11 1.2. Etapas ................................................................................................ 12 1.3. Características ................................................................................... 13 1.4. Recursos ............................................................................................ 14 1.5. Funciones de la dirección ................................................................. 15 1.6. La documentación de la gestión ....................................................... 16 1.7. La dinámica ...................................................................................... 18 1.8. El ciclo de vida .................................................................................. 19 1.9. Los costes reales ................................................................................ 21 1.10.Causas posibles de fracaso ............................................................... 22 2. La construcción del software ............................................................ 25 2.1. Productividad en la construcción del hardware y el software ........... 26 2.1.1. La productividad en la construcción del hardware ............... 26 2.1.2. La productividad en la construcción del software ................. 27 2.1.3. Cambio en el reparto de los costes entre hardware y software ............................................................................... 27 2.1.4. La importancia del mantenimiento de las aplicaciones informáticas ............................................ 28 2.1.5. La mayor complejidad del software nuevo ............................ 28 2.2. Introducción a la ingeniería del software .......................................... 29 2.2.1. Especificidad en la construcción de software de aplicación .......................................................................... 31 2.2.2. Objetivos generales ............................................................... 32 2.2.3. Componentes ........................................................................ 33 2.2.4. Distribución de costes en la construcción del software ......... 34 2.2.5. Origen e importancia de los errores en el software ............... 35 2.3. Metodologías de construcción del software ...................................... 36 2.3.1. Precisión terminológica previa ............................................. 37 2.3.2. Metodologías explícitas y metodologías implícitas .............. 38 2.3.3. Componentes ........................................................................ 39 2.3.4. Ciclo de vida y procedimiento .............................................. 42 2.3.5. Características generales y supuestos implícitos ................... 43 Resumen ...................................................................................................... 46 Actividades ................................................................................................. 49

© FUOC • P03/75069/02141

El proyecto informático de construcción de software

Ejercicios de autoevaluación ................................................................. 49 Solucionario ............................................................................................... 50 Glosario ....................................................................................................... 50 Bibliografía ................................................................................................ 51

© FUOC • P03/75069/02141

5

El proyecto informático de construcción de software

Introducción

De una manera tal vez insospechada para muchos, los proyectos informáticos presentan unas particularidades que obligan a darles un tratamiento especializado, hecho que, en cierto modo, los diferencia de otros proyectos del ámbito de la ingeniería. A menudo, los directores y responsables de una empresa constatan que los proyectos informáticos –los de desarrollo de un nuevo software son un caso paradigmático– difícilmente se logran terminar en el plazo establecido y con los costes previstos. Parece que existe una tendencia inevitable a menospreciar las dificultades y, casi siempre, los proyectos informáticos se planifican de manera que después es francamente difícil, por no decir imposible, conseguir los objetivos previstos. Y, a pesar de todo, prácticamente no existen diferencias entre lo que se debe realizar para llevar a cabo de forma satisfactoria un proyecto informático y lo que se debe efectuar para completar con éxito proyectos de otros campos de la actividad humana. Con toda seguridad, la dificultad principal recae en el hecho de calificar de forma adecuada el proyecto informático y en conocer con suficiente antelación su alcance y complejidad. Por todo ello, en este módulo didáctico exponemos la problemática general de los proyectos informáticos y de sus características y etapas, sin olvidar las dificultades que suelen acompañarlos. Dejamos para otro módulo didáctico la explicación detallada de las complejidades de la estimación correcta de cargas y de la planificación de proyectos informáticos a partir de las diferentes métricas disponibles. Cabe advertir, ya de entrada, que tal como corresponde a una asignatura de Informática de gestión, la visión que damos de los proyectos informáticos se limita a los aspectos de conducción, supervisión y realización. No entraremos en detalles acerca del contenido técnico del proyecto informático de construcción de software de aplicaciones, ya que es un tema propio de la ingeniería del software que se trata con detalle en otras asignaturas. Como el mismo texto del módulo indica, existe una gran variedad de proyectos informáticos: de adquisición de hardware, de adquisición de software (de aplicación, de sistema, etc.), de contratación y control de desarrollo externo de aplicaciones, de contratación y seguimiento de servicios de consultoría y un largo etcétera. A pesar de todo, nos centramos en los más característicos de la actividad profesional informática actual: los proyectos de construcción de software de aplicaciones que, además de ser los más haPodéis ver la estimación de cargas de los proyectos informáticos y las métricas disponibles en el módulo “Estimación de costes de un proyecto informático” de esta asignatura.

sus objetivos. . Comenzaremos definiendo el término proyecto informático. que es la que más nos interesa. los proyectos informáticos. Una vez situado el tema central que nos ocupa.© FUOC • P03/75069/02141 6 El proyecto informático de construcción de software bituales. incluimos un breve comentario sobre las metodologías de análisis y programación y la problemática de la ingeniería del software. sus características principales así como los requisitos que impone una visión orientada a la gestión. desde la óptica de la productividad. sobre todo. las etapas que lo forman. son aquéllos en los que es más evidente la especificidad de los proyectos informáticos. Por ello. conviene llevar a cabo un rápido repaso de la problemática específica de la construcción de software de aplicaciones en el ámbito de la informática de gestión. vista.

. Analizar el concepto informático de metodología y exponer las principales características y los diferentes ciclos de vida. 5. siempre desde la óptica de la gestión. 2. sus características principales y las etapas por las que pasa. el estudiante encontrará las herramientas necesarias para alcanzar los siguientes objetivos: 1. el cual no se determina hasta que no se ha realizado un análisis y se han establecido los requisitos y las especificaciones definitivas. sino la gestión del proyecto de construcción. que a menudo se inician sin saber del todo el objetivo.© FUOC • P03/75069/02141 7 El proyecto informático de construcción de software Objetivos En los materiales didácticos relacionados con este módulo. Conocer qué es un proyecto informático. sobre todo con relación a los proyectos informáticos. Ésta no debe reflejar los aspectos técnicos de la aplicación que se quiere elaborar. 4. Comprender la dificultad asociada a los proyectos informáticos de construcción de software de aplicaciones. 3. Saber definir y caracterizar el enfoque que corresponde a la ingeniería del software. Conocer las funciones del jefe de un proyecto informático y saber en qué consiste la documentación.

.

Un proyecto informático de construcción de software es la actividad que consiste en planificar. en el ámbito de la actividad profesional informática. Por tanto. • de contratación y control de diferentes servicios proporcionados por terceros: mantenimiento.). es el más habitual en la práctica profesional informática. el proyecto de construcción de software nuevo. Según el Diccionario de uso del español de María Moliner. En el ámbito de la informática existen muchas actividades que se pueden llevar a cabo y. las diferencias de un proyecto informático respecto de otros proyectos son más evidentes en un caso concreto que. seguir y controlar la producción de un software nuevo. o bien de aplicación. • de construcción de un software nuevo.. entre otras acepciones. también es “escrito. desde un punto de vista práctico. tan aplicada a la gestión. monitor de transacciones. • de mantenimiento de un software ya existente que se debe corregir. bien sea de sistema (sistema operativo. Generalmente. herramientas de desarrollo. de hecho. como es la construcción directa de software nuevo. se puede pensar en todo tipo de proyectos informáticos: • de adquisición de un hardware nuevo. servicios de comunicaciones. sistema de gestión de base de datos. un proyecto supone la voluntad de realizar o alcanzar algo y. mejorar o modificar para adaptarlo a nuevas necesidades. un proyecto es. etc. una “idea que se tiene de algo que se piensa hacer y de cómo hacerlo”. en que se expone una cosa que se piensa hacer o que se puede hacer”. etc. • de construcción de un hardware nuevo. • de adquisición de software nuevo. además. O. sobre todo a causa de la multiplicidad de formas que presentan estos proyectos. de una nueva . dibujo. dicho de otra manera. El proyecto informático Existen diferentes maneras de definir lo que es un proyecto informático. Ahora bien. como dice el diccionario. • de contratación y control del desarrollo externo de nuevas aplicaciones. servicios de datos. es interesante centrarnos en una modalidad concreta de proyectos informáticos.© FUOC • P03/75069/02141 9 El proyecto informático de construcción de software 1. etc.

El jefe de proyecto es la persona que coordina los diferentes aspectos del proyecto informático y se responsabiliza de ello. plazos. En esta definición se recoge el hecho de que. un proyecto informático se configura como un conjunto de actividades y tareas limitado en el tiempo y que tiene como finalidad obtener unos objetivos concretos. en la organización o en la empresa. en definitiva. a su vez. En resumen. el seguimiento y la evaluación de un sistema de información particular denominado proyecto. para llevar a cabo una buena gestión de un proyecto informático. Dicho esto. recursos que conviene utilizar. la eficiencia en este tipo de gestión se mide en función de los recursos utilizados y los plazos establecidos para conseguir de manera satisfactoria los objetivos cuantitativos y cualitativos que se hayan fijado para el proyecto informático. además del sistema de información que se construye como nueva aplicación informática. a veces ya existente y a veces nuevo. y teniendo en cuenta la perspectiva de los sistemas de información. consiste en la elaboración de la versión informatizada de un sistema de información. en unos plazos y con unos recursos determinados. es necesario efectuar un “metasistema de información”. se da la posibilidad de subdividirlo en varios subproyectos supervisados por diferentes líderes de proyecto que. presupuesto y. La gestión de un proyecto informático es un proceso de dirección y control que se concentra en la concepción. En el caso de que un proyecto sea demasiado grande y/o importante.© FUOC • P03/75069/02141 10 El proyecto informático de construcción de software aplicación. conviene introducir una nueva definición del término proyecto informático adecuada al ámbito de la gestión propio de esta asignatura. Un proyecto informático es un sistema de información que nos ayuda a tomar decisiones en las actividades de construcción de software. todo lo necesario para controlar una actividad económica centrada en la informática. Lo que se quiere decir es que para gestionar de manera eficiente el proyecto de construir software nuevo también conviene elaborar un nuevo sistema de información específico que haga referencia a ítems como: trabajos que se deben realizar. . son supervisados y coordinados por el jefe del mismo. la puesta en funcionamiento. De hecho.

sino las que tienen que ver con la calidad intrínseca del software*. la mala práctica profesional provoca que en ocasiones parezca que se respetan los plazos y el presupuesto.© FUOC • P03/75069/02141 11 El proyecto informático de construcción de software 1. Por tanto. Desgraciadamente. etc. si se utiliza tecnología nueva y poco probada. obviamente. el riesgo disminuye y. En general. los plazos o el presupuesto– depende de varios factores como los que mencionamos a continuación: 1) El tamaño y la duración: en los grandes proyectos existen más posibilidades de errores y de fracaso. pero en realidad se han acortado y reducido las funcionalidades que se debían implementar. concretamente en el ámbito de la informática * Es decir. a los objetivos propios de la aplicación que se quiere desarrollar o mantener debe añadirse todo aquello que hace referencia a la gestión de las actividades que se han de llevar a cabo para terminar con éxito el proyecto. tanto del software como del proceso de creación y mantenimiento. * Como metodologías de análisis y programación. • los plazos. el riesgo de no cumplir los objetivos aumenta. Evidentemente. Objetivos Para sintetizar los objetivos generales de cualquier proyecto informático. • el presupuesto. 3) La calidad y la estabilidad de las especificaciones reduce el riesgo de un proyecto informático. 3) Respetar el presupuesto asignado al proyecto ajustándose a los costes predeterminados. en todo proyecto informático existe siempre el riesgo de no conseguir los objetivos deseados. . hecho que ha generado preocupaciones serias y fundamentadas en relación con lo que se denomina calidad. etc. el hecho de obtener las funcionalidades que se desean con unos costes superiores a los previstos o con más tiempo del que se había calculado es la manera más habitual de que un proyecto informático termine en un fracaso declarado. lenguajes de especificación. En cualquier caso. facilidad de mantenimiento. 2) Respetar los plazos que se han establecido para conseguir las funcionalidades. funcionamiento sin errores. 2) La tecnología: si el equipo de trabajo conoce bien la tecnología que se debe utilizar*.1. buena documentación. a pesar de que. herramientas que deben utilizarse. los cuales señalan cuándo se ha de terminar el proyecto informático. se considera que el hecho de no poder cumplir la previsión –porque fallen las funcionalidades. Normalmente las funcionalidades suprimidas no son las más aparentes. Objetivos del proyecto informático Los objetivos que definen cualquier proyecto informático son: • las funcionalidades. se puede decir que los objetivos generales de la actividad de la gestión de un proyecto informático son los siguientes: 1) Alcanzar unas funcionalidades determinadas que indiquen lo que se ha concretado que se debe realizar.

cómo se va (planificación de recursos y actividades) y también nos debe informar en todo momento de dónde se encuentra el proyecto (seguimiento). precisamente. Etapas de un proyecto informático En la gestión de un proyecto informático podemos distinguir las etapas siguientes: • Inicio. . Etapas La característica más importante de un proyecto informático es que se trata de algo temporal. 4) El cierre del proyecto. que no dispone indefinidamente de los recursos que se le asignan. Un proyecto informático es una actividad viva en el sentido de que nace. da origen al proyecto y lo hace nacer. La gestión de un proyecto debe permitirnos saber hacia dónde va (los objetivos). teniendo en cuenta los recursos disponibles. ayuda a repartir en el tiempo las diferentes actividades que se han de llevar a cabo. el seguimiento y control del desarrollo del proyecto. que indica la finalización definitiva del proyecto y permite efectuar un balance de la realización al mismo tiempo que libera los recursos que se le habían asignado. hecho que introduce incertidumbre y riesgo en los proyectos de este ámbito. 1. La calificación incluye la estimación del volumen de trabajo que se debe realizar y la planificación en el tiempo de las diferentes actividades. se desarrolla y finalmente termina. La gestión de un proyecto informático puede verse como la secuencia (y también la interrelación) de cuatro grandes etapas: 1) El inicio del proyecto. Una faceta importante de esta gestión es la determinación del cierre del proyecto. ya sea porque se han conseguido los objetivos. 2) La calificación del proyecto. que incluye estimación y planificación.© FUOC • P03/75069/02141 12 El proyecto informático de construcción de software de gestión. de hecho.2. ya sea por una interrupción brusca cuando el proyecto informático está mal calificado. • Cierre. • Calificación. • Desarrollo. dirigir el desarrollo del mismo para llevarlo a su fin y obtener las funcionalidades deseadas. es decir. que establece los requisitos y los objetivos funcionales generales que se deben conseguir y. que implica seguimiento y control. en el cual se reúnen datos de cómo se efectúa el proyecto y se identifican las desviaciones entre la planificación y la realidad (seguimiento) para poder tomar las medidas de corrección necesarias (control). en los plazos establecidos y con el presupuesto autorizado. más exactamente. que permite realizar una evaluación global de la carga de trabajo necesario para la realización del proyecto y. los requisitos de adaptación a la realidad y la complejidad del trato con los futuros usuarios de la aplicación que debe desarrollarse en el proyecto provoca que nunca se pueda estar seguro de la estabilidad de las especificaciones. El objetivo principal de la gestión de un proyecto informático es. 3) El desarrollo del proyecto o.

© FUOC • P03/75069/02141 13 El proyecto informático de construcción de software De hecho. se pueden utilizar las nuevas informaciones de las que se dispone durante el desarrollo del proyecto informático. cerrar un proyecto informático de construcción de software no es una tarea fácil. ya que no siempre todos los objetivos se pueden considerar cumplidos. Características Por norma general.5 de este módulo didáctico. Además. dificulten la finalización. en la práctica. Es responsabilidad del jefe de proyecto informático proceder a establecer las fases y las agrupaciones durante la etapa de calificación del proyecto. en cierta manera. se constaten diferencias entre lo que se realiza y lo que se había previsto en la calificación (la estimación del trabajo que se debe efectuar y la planificación temporal de actividades). si el jefe de proyecto no reacciona a tiempo. El hecho de que la primera calificación (estimación y planificación) sea muy precaria. es difícil saber cuáles son las funcionalidades que se han de implementar. Por este motivo. lo diferencian de otros tipos de . en el caso concreto de la informática de gestión. a lo largo del desarrollo del proyecto. 1. Podéis ver la importancia de los errores en la etapa de calificación en el subapartado 2. Un proyecto consta siempre de actividades finales. Por ello.2. ya que continuamente surgen nuevas necesidades. Conviene destacar también la dificultad asociada a una buena finalización del proyecto. a menudo conviene repetir la etapa de calificación. la calificación de un proyecto informático es uno de los aspectos más problemáticos y que genera más errores. la segunda y la tercera etapa interaccionan de manera inevitable y a menudo forman un bucle o ciclo. Como veremos más adelante. es muy usual que. cualquier proyecto informático está marcado por un conjunto de características que. Por este motivo. como a menudo este tipo de proyectos se realiza para unos determinados clientes o futuros usuarios de la aplicación que se desarrolla.3. provoca que difícilmente se alcancen los objetivos iniciales de un proyecto informático. que se suelen agrupar en fases o grupos de actividades. el problema de la poca estabilidad de los requisitos y las especificaciones de la aplicación que se quiere desarrollar puede llevar a lo que se denomina fenómeno de los requisitos crecientes. el cual provoca la evolución de los requisitos de manera que. Así. es normal que los usuarios intenten alargar tanto como puedan la presencia y la colaboración de los especialistas informáticos que llevan a cabo el proyecto y que. Por otra parte.

en el cual trabaja el equipo técnico que lleva a cabo el proyecto de construcción de software de aplicación. • Duración limitada. un día se inicia y otro día se ha de finalizar. por ejemplo. Los proyectos informáticos presentan siempre las siguientes características: 1) Concreción. sobre todo si pensamos en proyectos del ámbito de la informática de gestión.© FUOC • P03/75069/02141 14 El proyecto informático de construcción de software proyectos. concreto y tangible. se trata siempre de un conjunto de actividades que se efectúan de manera excepcional para responder a una necesidad puntual en el tiempo. Cualquier proyecto informático es excepcional en el sentido de que es único y diferente de otros proyectos anteriores o futuros. 1. intervienen varias personas y se utiliza tecnología diversa. En todo caso. los siguientes: 1) El hardware de las máquinas objetivo. Los recursos que se le asignan son para un periodo de tiempo limitado y. Además. ya que. sea necesario reasignar estos mismos recursos de manera dinámica para responder a las necesidades de las estimaciones y planificaciones sucesivas posteriores al inicio del proyecto. un proyecto informático requiere la movilización rápida de los recursos asignados. la dificultad que conlleva realizar una primera calificación correcta del proyecto ocasiona que. de los cuales se debe conocer las características. 3) Duración limitada. una vez realizadas la estimación y la planificación del proyecto. Normalmente. tiene un objetivo definido. Un proyecto informático se lleva a cabo para resolver un problema perfectamente identificado y. de vez en cuando. en el cual se ha de ejecutar finalmente la aplicación que se desarrolla. 2) El hardware de las máquinas de desarrollo y pruebas. es decir. como en ocasiones ocurre en las actividades de búsqueda. en ocasiones. 4) Flexibilidad. Recursos Un proyecto informático moviliza diferentes recursos. . cualquier proyecto informático tiene una duración limitada en el tiempo. Además. No es una actividad genérica cuyo final se desconoce a priori. intervienen una gran cantidad de recursos como. Tal como ya hemos visto. en cada proyecto informático se persiguen unos objetivos diferentes. El jefe de proyecto es el responsable final de que se utilicen correcta y eficientemente. las mismas funcionalidades que se persiguen tienen una caducidad bien definida en el tiempo. por tanto. La analogía con otros proyectos sólo es un recurso aproximativo. conviene saber también qué necesidades concretas y puntuales se darán de estos recursos. • Flexibilidad. a lo largo del desarrollo del proyecto. Características de los proyectos informáticos Cualquier proyecto informático presenta las siguientes características: • Concreción. • Excepcionalidad.4. 2) Excepcionalidad. generalmente. En el caso concreto de proyectos de desarrollo de software.

4) Los recursos humanos. asignar las actividades a las personas más adecuadas. etc. ya sean orientadas al método**. El coste de los recursos humanos de un proyecto informático se analiza con detalle en el módulo “Estimación de costes de un proyecto informático” de esta asignatura. sistemas de gestión de bases de datos. editores. ** Como herramientas CASE. recoger los datos que permitan llevar a cabo un buen seguimiento del proyecto e. 1. ** Grado de disponibilidad. si es necesario. espíritu de colaboración. etc. En cambio. Conviene tener en cuenta que esto es una simplificación y que nunca exime al jefe de proyecto de su responsabilidad de garantizar la disponibilidad de todo tipo de recursos necesarios para el proyecto. downsizing o rightsizing. etc. la generalización reciente de la informática y el fenómeno del redimensionamiento a la baja de los sistemas* provoca que los recursos de software y hardware cada vez sean más accesibles. el jefe de proyecto es quien debe garantizar la disponibilidad de cada uno de los recursos según se establece en la planificación del proyecto informático en los diferentes procesos de calificación. compiladores. asignarle de nuevo los recursos o proponer la finalización anticipada.© FUOC • P03/75069/02141 15 El proyecto informático de construcción de software 3) El software de las diferentes herramientas de apoyo. especialistas de todo tipo. no se puede decir lo mismo del coste de los recursos humanos que se destinan a los proyectos informáticos (analistas. estimar el coste en esfuerzo y recursos y realizar la planificación de las actividades. 2) Establecer las diferentes fases y etapas. volver a calificar el proyecto y. .5. Sin embargo. se puede decir que el jefe de proyecto tiene como misiones principales las que comentamos a continuación: 1) Asegurarse de que el proyecto está bien definido. de los cuales se debe conocer las aptitudes* y las actitudes**.). 4) Establecer los procedimientos estándar de comunicación interna del proyecto para permitir la recogida de datos. ya sean orientadas al código*. técnicos o financieros). En general. 3) Garantizar la disponibilidad de los recursos (humanos. * Experiencia. Funciones de la dirección Las responsabilidades de un jefe de proyecto informático son numerosas y variadas: calificar (estimar y planificar) el proyecto. de ahora en adelante nos centraremos de manera casi exclusiva en el coste de los recursos humanos. * Como sistemas operativos. estabilidad. En la práctica. la validación y las actividades de control y decisión. conocimientos. incluso. programadores. a partir de estos datos. habilidad. * En inglés. etc. Por ello.

pero disponer de datos reales de otros proyectos llevados a cabo en una determinada instalación. 1. lo que en la práctica profesional se documenta de la gestión de un proyecto informático es siempre mucho menor de lo que es necesario. Conviene mencionar que. un proyecto informático supone necesidades paralelas de documentación que no se agotan con la documentación técnica de la aplicación que se debe desarrollar. Es cierto que todo proyecto es concreto y único. 6) Asegurarse de que el personal tiene la cualificación necesaria para llevar a cabo el proyecto. En particular. planificar también las actividades específicas necesarias de formación. • Elegir soluciones a los problemas planteados y volver a calificar el proyecto en función de estas soluciones. manuales y cursos de ingeniería de software. tanto la técnica* como la administrativa**. pero en realidad. de la misma manera que no se suele aportar la documentación técnica de la que hablamos en los libros. casi . todavía se tiene menos en cuenta la necesidad de documentar de forma explícita y específica la actividad de gestión de un proyecto informático. 8) Cerrar cada una de las actividades. una vez alcanzados los objetivos asignados o decidida la interrupción definitiva.6.© FUOC • P03/75069/02141 16 El proyecto informático de construcción de software 5) Distribuir el trabajo entre los miembros del equipo. si los aspectos de gestión de un proyecto informático estuvieran bien documentados. a menudo en las grandes instalaciones y/o proyectos. A pesar de todo. en la práctica. ** Es necesario estar al día de los procedimientos y estándares de documentación. La documentación de la gestión Concebido como un sistema de información que nos ayuda a tomar decisiones en las actividades de construcción de software. 7) Controlar el desarrollo del proyecto y avisar con tiempo de los problemas que se puedan presentar y que exijan decisiones importantes en relación con la continuación del mismo. • Evaluar alternativas analizando los riesgos y los costes relacionados con cada nueva opción tomada en consideración. Como siempre. y en caso de que no haya cualificación. * Conviene conocer las herramientas informáticas que se deben utilizar. en definitiva. el proyecto informático. fases y. la dificultad de abordar nuevos proyectos se reduciría. ha de ser capaz de: • Redefinir los objetivos de cada fase en las calificaciones sucesivas del proyecto. en concreto. existen excepciones. el jefe de proyecto debe preocuparse de los aspectos más dinámicos del proyecto informático y.

su grado de desarrollo y también las diferentes incidencias que se hayan podido presentar. 2) La estructura del proyecto. con unas hojas de trabajo en las que se indican las actividades. de las incidencias y de la situación del proyecto. Por tanto. 5) El seguimiento. la de la primera calificación del proyecto (planificación de referencia). un buen expediente de proyecto debería contener los documentos siguientes: 1) La definición general del proyecto con los objetivos. De manera global. de las actividades en curso. a menudo semanal. si viviésemos en un mundo perfecto. 3) Las evaluaciones iniciales desde el punto de vista de los riesgos y los costes. es decir. Se suele realizar. las diferentes planificaciones: • La inicial. en la estimación de cargas. y otra activa. Este expediente incluye dos partes: una de archivo. En cualquier caso. • La planificación vigente en cada momento (planificación actual). como veremos. de los datos que hacen referencia a las actividades del proyecto ya cerradas. que es la que el jefe de proyecto actualiza día a día. mejor aún. en concreto. debería ser una ayuda considerable en la califiación de nuevos proyectos y.© FUOC • P03/75069/02141 17 El proyecto informático de construcción de software siempre con aplicaciones. la descomposición en fases y actividades y la organización interna. 6) Lo que podríamos denominar diario de a bordo del proyecto. es decir. desde que un proyecto se inicia debe abrirse un expediente al servicio del jefe de proyecto que recoja toda la documentación necesaria que se utiliza para recopilar los datos de las actividades de gestión del proyecto. tecnología y recursos humanos del mismo tipo. los límites. sería evidente el interés por documentar suficientemente las actividades de gestión de un proyecto informático. así como también las estimaciones iniciales de carga de trabajo que conlleva el proyecto. en el cual se anota lo que ocurre y se informa. día tras día. 7) La correspondencia (correo electrónico incluido) y las notas. la determinación de lo que se ha de llevar a cabo y de cómo debe realizarse y las posibles restricciones. . tanto en lo referente al calendario como a los recursos y costes. y también los informes externos de quien ha encargado el trabajo que el jefe de proyecto entrega al eventual comité de seguimiento del proyecto. que siempre es muy precaria. 4) La planificación temporal de las actividades del proyecto o.

también debemos tener en cuenta que. sino que es algo vivo. De hecho. el seguimiento ha de permitir efectuar controles regulares y medir las desviaciones entre la realidad y aquello que se ha planificado anteriormente. como una ayuda a la realización y. . La pregunta principal es cómo llevarlo a cabo. sobre todo. En definitiva. Así. por tanto. Las estimaciones y planificaciones deben revisarse y.© FUOC • P03/75069/02141 18 El proyecto informático de construcción de software Como ya avanzábamos. supone que al inicio de cada fase nos debamos formular cuestiones como las siguientes: 1) Redefinir los objetivos de la nueva fase y estudiar las restricciones que se puedan dar. si es posible. No es una actividad que se pueda contemplar de manera lineal. Un expediente como éste es útil. sea falsa. posiblemente. como hemos dicho. Este planteamiento. Con estos datos debe reelaborarse tanto la estimación (a partir de los datos reales de productividad que se alcanzan en cada momento con el equipo humano que interviene en el proyecto). si el proyecto terminara prematuramente*. sobre todo en el caso de la informática de gestión. corregirse. cambia incluso el mismo entorno en el que se desarrolla el proyecto informático. como la planificación (por los cambios en la estimación del esfuerzo necesario y. * Por ejemplo. Sin embargo. también. a la calificación inicial de los proyectos informáticos futuros. cualquier estimación de cargas. por los posibles desajustes en la disponibilidad de los recursos). Lo que parecía una verdad incuestionable al inicio del proyecto. cuando convenga. como consecuencia de un cambio de objetivos. si esta noción de evolución de la planificación es importante. sino que más bien debemos imaginarla como una actividad en espiral. La dinámica Un proyecto informático no permanece fijo y estático. una de las condiciones esenciales para poder absorber todos estos cambios posibles sin demasiadas dificultades es descomponer el proyecto en diferentes fases. imprescindible cuando el proyecto es grande. riesgos y costes es una conjetura y. Durante el desarrollo del proyecto. pueden cambiar y ello. especialmente. puede dejar de serlo más adelante. en la dirección de proyectos informáticos debe pensarse en la necesidad de convivir con el cambio. el trabajo parcial efectuado se podría evaluar. Para muchos especialistas. contribuye a aumentar el riesgo del proyecto en sí. Las especificaciones. este conjunto de informaciones compone un verdadero expediente de la gestión de un proyecto informático y tiene una importancia fundamental. en proyectos que duran unos cuantos meses.7. un paquete aislado (de manera natural o artificial) del resto y. que se pueda facturar de manera separada (a un cliente externo o en el seno de la contabilidad de costes interna de una misma empresa). Cada fase constituye un tipo de subproyecto con un objetivo muy preciso. 1.

como se observa en la figura: Podéis ver la descripción de las etapas sucesivas según el método utilizado en el apartado 2 de este módulo didáctico. con prototipos. . todo proceso de construcción de software pasa por etapas. 1. contenido y especificación van variando a lo largo del tiempo de acuerdo con los diferentes métodos utilizados. en el cual las diferentes etapas de la construcción del software se ven como una secuencia casi lineal. en espiral. A menudo. en la que una etapa debe finalizar antes de que se inicie la siguiente. Imaginaremos un proceso de desarrollo en el sistema clásico de un ciclo de vida en cascada. las etapas por las que pasa la construcción de software se ven como un ciclo de vida completo. La denominación de ciclo de vida sirve para marcar este carácter evolutivo y perecedero de cualquier aplicación informática. El ciclo de vida De manera general. No es éste el lugar adecuado para tratar con detalle estos puntos de vista. Las diferentes metodologías de la ingeniería de software parten de varios puntos de vista sobre el ciclo de vida de una aplicación: ciclo de vida en cascada. sobre todo si se une el inevitable mantenimiento de las aplicaciones y la retirada del software al final de su vida útil. 3) Elegir una solución y planificar de nuevo en función de la elección realizada. cuyo nombre.© FUOC • P03/75069/02141 19 El proyecto informático de construcción de software 2) Evaluar las alternativas y analizar los riesgos inherentes a las diferentes posibilidades. sino que corresponde a las asignaturas de ingeniería del software. etc.8. ciclo de vida en fuente para la orientación a objetos.

que ha de responder a las necesidades siguientes: • Corregir los posibles errores a medida que se detectan. b) La prueba imprescindible de todo ello. teniendo en cuenta los requisitos más generales establecidos normalmente en esta etapa. A menudo. que indica de manera general los recursos que se emplean a lo largo del ciclo de vida de una aplicación. que puede ser de procedimientos nuevos codificados o puede reutilizar procedimientos provenientes de una librería de rutinas ya realizadas y probadas. • Mejorar las funcionalidades en la medida en que sea posible. 4) La implementación final del sistema informático. 2) El análisis del sistema de información y la elaboración posterior de las especificaciones. Hace años. En la figura de la página siguiente se muestra la denominada curva del caracol.© FUOC • P03/75069/02141 20 El proyecto informático de construcción de software Esta convención no se corresponde del todo con la realidad y a menudo debe volverse atrás para corregir pasos anteriores. que se concreta en dos aspectos: a) La programación. pero esta denominación parece que ha caído en desuso. las etapas por las que. 5) El mantenimiento de la aplicación durante su vida útil o explotación. En cualquier caso. • Adaptar la aplicación a los requisitos necesariamente cambiantes del entorno donde se ejecuta y es útil. esta etapa se denominaba etapa de análisis orgánico. 3) El diseño de una solución técnica concreta que satisfaga las especificaciones establecidas en la fase de análisis. que debe permitir finalmente instalar el sistema de una manera definitiva para poder pasar así a la etapa de funcionamiento y explotación real. desde este punto de vista. la tradición profesional ha etiquetado este primer análisis con la denominación análisis funcional. las funciones y los objetivos del sistema informático que se quiere implementar. pasa el proceso de construcción de software son las que presentamos a continuación: 1) El anteproyecto o estudio de oportunidad. al final del cual se toma la decisión de promover el proyecto informático. Hemos marcado claramente el plazo de puesta en funcionamiento en el que se inicia la explotación. que es en realidad el que .

© FUOC • P03/75069/02141 21 El proyecto informático de construcción de software consideramos que se encuentra bajo el control del proceso de gestión de un proyecto informático para desarrollar una nueva aplicación: 1. que tal vez explica la mala calidad de muchos proyectos informáticos y del producto. cabe señalar que contiene un grave error. Los costes reales La figura anterior puede crear confusión. el software.9. es evidente que todo lo que ayuda a tener un buen mantenimiento no se toma en consideración a la hora de construir una aplicación. los costes de un proyecto informático) no incluyen el coste del mantenimiento. que construyen. ya que puede parecer que el coste final total de un proyecto informático de construcción de software de aplicación sólo incluye las actividades necesarias hasta llegar a la etapa de explotación de la aplicación que se quiere construir. A pesar de que lo que acabamos de exponer es el punto de vista más habitual. Ahora bien. sobre todo si se dan problemas en el cumplimiento de los objetivos del proyecto. . Si reflexionamos acerca del hecho de que los costes de tener una aplicación nueva en disposición de ser operativa (en definitiva. La figura de la página siguiente refleja con más realismo la curva del caracol de reparto del esfuerzo a lo largo del tiempo. el mantenimiento es muy importante en la vida de una aplicación.

Causas posibles de fracaso Seguramente se pueden encontrar más ejemplos de proyectos informáticos que han terminado en fracaso que de proyectos en los que se han podido cum- . pongamos unos diez años. la apariencia de que se respetan los objetivos de un proyecto. Podéis ver los tipos de mantenimiento en el subapartado 2. Y. en realidad. A pesar de todo. Algunas funcionalidades poco aparentes. cuando. pese a que. si calculamos el coste real de construir y mantener en funcionamiento una aplicación informática.4 de este módulo didáctico. es posible pensar en una aplicación en la que la etapa habitualmente asociada al proyecto informático de construcción de software de aplicación (el tiempo previo a la puesta en funcionamiento y a la entrada en explotación) sea. perfectivo o adaptativo. y ello durante el largo periodo en el que la aplicación se encuentra en explotación. este hecho nunca se tiene en cuenta cuando se decide si conviene o no iniciar un proyecto informático para construir una nueva aplicación. la parte que corresponda al mantenimiento sea la mayor de todas. es muy posible que. 1. pongamos por caso. aquí también consideraremos que los costes del proyecto informático son los que se cuentan hasta que se llega a la situación que denominamos puesta en funcionamiento. insistimos. ya sea correctivo. a pesar de que se necesitan muchos recursos en la etapa previa a la puesta en funcionamiento de la aplicación. cuando en cierta manera se cierra el proyecto informático y se entra en la etapa larga y compleja del mantenimiento. Por tanto. Como se observa. en ocasiones. un estudio de alternativas técnicas posibles y la seguridad de las pruebas para garantizar un funcionamiento sin errores. como se lleva a cabo en todas partes. se eliminan funcionalidades poco aparentes que convierten en mucho más problemático y costoso el largo periodo de mantenimiento. la realidad es que los recursos empleados en el mantenimiento tampoco son negligibles: siempre existe necesidad de mantenimiento.10..1. de un año o incluso menos. El hecho de que no se tengan en cuenta los costes reales del mantenimiento en la vida completa de una aplicación informática permite entender que la mala práctica profesional puede provocar. aunque hayamos hecho esta advertencia. .© FUOC • P03/75069/02141 22 El proyecto informático de construcción de software La importancia del mantenimiento En un caso normal. que se suelen no realizar para que parezca que se respetan los objetivos son. una buena documentación. una vez en explotación. normalmente.... entre otras. es lógico pensar que la aplicación que tantos esfuerzos ha costado se querrá mantener en funcionamiento tanto tiempo como sea posible.

W. a menudo por falta de datos. Englewood Cliffs: Prentice Hall. Como siempre que se trata de tareas intelectuales. que se produce por varias razones: 1) Incapacidad del jefe de proyecto de delegar responsabilidades. éste no promueve la participación de los miembros del equipo en las decisiones.). al menos en algunos aspectos técnicos concretos de la actividad de desarrollo de software (conocimiento del sistema de base de datos. Cabe mencionar que si la intervención y la capacidad directiva del jefe de proyecto son muy importantes. es decir. la más frecuente suele ser una falta de comunicación. Boehm (1981). tanto en lo que corresponde a sus conocimientos. La capacidad de actuar como líder es básica Lectura complementaria Podéis consultar la opinión de Barry Boehm respecto a las consecuencias de formar un mal equipo para un proyecto informático en la obra siguiente: B. competencia y formación como en lo referente a su capacidad de cooperación. Entre las causas de fracaso por razón de la gestión. etc. retrasan y ponen en peligro todo el proyecto. conocimiento y experiencia en los lenguajes de programación. Sea como sea. a menudo habrá especialistas más cualificados que el jefe de proyecto. entre los proyectos fracasados probablemente haya algunos que han fallado por dificultades de gestión. 4) Una evaluación errónea de las personas que forman el equipo técnico del proyecto. Un dato relevante es que. no lo son menos la capacidad y la disponibilidad de todo el equipo técnico que interviene en el proyecto informático. las cuales generalmente se pueden atribuir al jefe de proyecto o a determinadas características del mismo proyecto o aplicación. 5) Falta de capacidad de decisión.© FUOC • P03/75069/02141 23 El proyecto informático de construcción de software plir todos los objetivos. Software Engineering Economics. . se debe pensar en un factor imprescindible: la motivación del personal que forma el equipo del proyecto. 2) Falta de conocimientos de los objetivos. en el equipo de un proyecto informático. cuando son incorrectas o falsas. a menudo porque el estudio de oportunidad no se ha llevado a cabo de forma adecuada y correcta. hecho que obliga a menudo a trabajar sobre hipótesis provisionales que. también a una definición incorrecta de los límites del proyecto. el jefe de proyecto es el responsable de su equipo de trabajo. el cual conduce a una descomposición del proyecto en actividades y tareas que no es eficiente o. De hecho. La razón principal de este hecho es la dificultad de realizar una calificación inicial correcta del proyecto informático. que provoca que demasiadas cuestiones queden sin respuesta. Un gran especialista como Barry Boehm considera que un mal equipo puede llegar a multiplicar por tres o cuatro el tiempo previsto para un proyecto. 3) Un mal análisis del problema.

• Las dificultades previstas y las opciones de corrección que se deban efectuar. • Una incorrecta definición de la finalización del proyecto o de las actividades y fases. .© FUOC • P03/75069/02141 24 El proyecto informático de construcción de software para un buen jefe de proyecto que. • Una deficiente determinación de las prioridades internas entre las actividades del proyecto (y.1 de este módulo didáctico. • Los retrasos que se puedan producir. • Los trabajos que corresponden a cada miembro. en relación con las actividades externas al proyecto en las cuales puedan intervenir algunos miembros del equipo). • La falta de certeza sobre el momento de inicio del proyecto (y sobre la asignación de recursos) o de inicio de cada actividad. en ocasiones. • El circuito de informaciones y el conjunto de procedimientos administrativos que se deben respetar. como ya hemos comentado al tratar el tamaño del proyecto informático: la familiarización con la tecnología que debe utilizarse y la solidez de las especificaciones. La siguiente lista es otra manera de resumir estas posibles causas de fracaso: • Una mala definición de los objetivos. es necesario tomar en consideración las otras causas de fracaso asociadas al riesgo mismo del proyecto. • Los objetivos personales de cada uno en cada etapa del proyecto y los objetivos generales. que sean demasiado difusas: lo que ocasiona que no sea posible determinar quién es realmente responsable de las actividades que se deben llevar a cabo. el proyecto continúa indefinidamente cuando se confunde el proyecto informático de construcción de una aplicación con el trabajo de mantenimiento. En el primer caso. tiene la responsabilidad de informar personalmente a cada miembro del equipo de los aspectos que presentamos a continuación: • La estructura del proyecto y el lugar que cada uno ocupa. entre otras. Podéis ver las causas de fracaso asociadas al riesgo del proyecto en el subapartado 1. Del mismo modo. • Unas responsabilidades que no estén bien determinadas.

la palabra crisis). fiable y de calidad es una actividad siempre llena de dificultades. en definitiva. fiable y de calidad no pasaba por una crisis momentánea y temporal (que es lo que sugiere. Por ello. con un ritmo de cambio muy rápido. cuando se utilizó por primera vez la expresión ingeniería del software. durante la conferencia de la OTAN en Garmish (Alemania). a menudo altamente inciertas (particularmente en el ámbito de la informática de gestión). construir y mantener software seguro. sino que en aquel momento ya se comenzaba a detectar un problema central e intrínseco de los proyectos informáticos de construcción de software: diseñar. pero las principales son las siguientes: 1) La dificultad de determinar las especificaciones. La problemática de construir software seguro. 4) El hecho de que los sistemas que se han de construir en la informática de gestión deban ser al mismo tiempo de larga duración (para amortizar la inversión realizada con el fin de obtenerlos) y modificables (para que se puedan adaptar al entorno siempre cambiante de la informática de gestión).© FUOC • P03/75069/02141 25 El proyecto informático de construcción de software 2. La construcción del software Parece que fue en el año 1968. 2) La tecnología informática. construir y mantener software no pasa por una crisis momentánea. fiable y de calidad. En realidad. del sistema de información que se construye. se comenzó a hablar de una presunta crisis del software para reflejar la gran cantidad de problemas que surgían en su diseño y construcción. que convierte en difícil la utilización de la experiencia técnica anterior porque rápidamente queda obsoleta. Entonces. sino que atraviesa lo que se podría denominar “una verdadera enfermedad crónica”. muchos autores se plantean si el proceso de diseñar. 3) La escasa consistencia y la volatilidad elevada de las necesidades expresadas por los futuros usuarios de los sistemas de información propios de la informática de gestión. . La razón por la que se introdujo este término fue la constatación de lo difícil que era en sí mismo el trabajo de construir un software nuevo que fuese seguro. Existen muchas razones que podrían explicar esta enfermedad crónica. este punto de vista resultó muy optimista.

el primer ordenador digital. Coches y ordenadores Estableciendo una comparación entre la industria de la automoción y la del hardware informático. La productividad en la construcción del hardware Para todo el mundo es un hecho obvio el aumento casi increíble de la potencia y la seguridad del hardware informático. La productividad del hardware ha aumentado de manera espectacular. es evidente que. Sobre una mesa de despacho. la misma potencia de cálculo de aquella máquina se consigue y se supera con creces con un chip de tamaño diminuto y de mucha más fiabilidad tecnológica. incluso insospechada si lo comparamos con el software. la productividad. se desarrolló en la Universidad de Pensilvania (EE.1. sólo hemos esbozado). hoy encontramos ordenadores personales infinitamente más potentes y seguros que el ENIAC y al alcance de mucha gente. El que se considera el primer ordenador digital. ocupaba un piso entero de la Escuela de Ingeniería Eléctrica Moore y tenía unos 18.1.000 tubos de vacío que fallaban a una media de uno cada siete minutos. hoy podríamos disponer. Productividad en la construcción del hardware y el software En la gestión de proyectos informáticos. software de aplicación) que corresponde a cada unidad de los recursos utilizados para conseguirlo. La productividad es la capacidad de obtener producto (en nuestro caso. Pesaba 30 toneladas. * En el argot profesional informático se habla de metodologías en lugar de utilizar el término métodos. Imagen de un microprocesador. 2. Imagen del ENIAC.UU.) Eckert y Mauchly y fue presentado públicamente el 15 de febrero de 1946. de momento. Actualmente. hecho que ha dado lugar a la denominada ingeniería del software y a diferentes métodos o metodologías* de diseño. precisamente. de un Rolls Royce con la potencia de un transatlántico que sería capaz de dar veinticinco veces la vuelta al mundo solamente con un litro de gasolina. cuando han pasado poco más de cincuenta años desde la creación del ENIAC.© FUOC • P03/75069/02141 26 El proyecto informático de construcción de software A pesar de que estas razones no son las únicas. en el campo de la informática el aumento de la productividad muestra un ritmo muy diferente en la construcción de hardware y en la de software.1. 2. . el ENIAC. ante esta compleja problemática (que aquí. De hecho. podemos afirmar que si la primera hubiera seguido una evolución similar a la del hardware. lo que más nos interesa es. desde la conferencia de Garmish se quiso abordar el proceso de diseño. construcción y mantenimiento del software con la misma seriedad y los mismos modelos típicos de cualquier otra actividad de ingeniería. construcción y mantenimiento del software. por menos de sesenta céntimos.

cuestión que desarrollaremos en otro módulo.© FUOC • P03/75069/02141 27 El proyecto informático de construcción de software 2.000 líneas de código fuente).1.000 líneas de código se mantiene entre 8 y 12 incluso en los productos considerados ya definitivos. elaborada a partir de los datos de Barry Boehm.W. debemos tener en cuenta que también han influido mucho el estancamiento de la productividad en la construcción de aplicaciones informáticas y el aumento del coste del personal informático. Software Engineering Economics. Boehm nos explica que. Diferentes autores. con la evolución de la informática y el aumento creciente de la productividad y la fiabilidad del hardware. . Cambio en el reparto de los costes entre hardware y software La realidad es que.2. de media. situaba la mayor parte del coste informático en el hardware. el ritmo de avance en la productividad del hardware informático no tiene un equivalente en la construcción del software. las actividades de mantenimiento de las aplicaciones informáticas suponen. Boehm (1981). tan imprescindible para el funcionamiento de los sistemas informáticos. Podéis ver las métricas del software en el apartado 1 del módulo “Estimación de costes de un proyecto informático” de esta asignatura. no se debe esperar que se alcancen más de 10 líneas de código fuente por día y persona ocupada en el proyecto. en la construcción de software. Englewood Cliffs: Prentice Hall. Lectura complementaria Podéis encontrar un conjunto de datos sobre la productividad en la construcción de software elaborado por Barry W. han recogido datos sobre la productividad real en la construcción del software. originariamente. 2. muestra claramente la tendencia mencionada. Las cifras no son tan espectaculares como las del hardware. Boehm en la obra siguiente: B. A pesar de que las medidas en las que se basan estos datos se comprenden mejor cuando se conocen las diferentes métricas del software y su significado más profundo. una muestra clara del aumento de la productividad que ha ido incorporando. La figura de la página siguiente. en un proyecto informático de tamaño medio (que de momento podemos establecer en torno a las 20.3. el número de errores por cada 1. entre los cuales destaca Barry Boehm. Desgraciadamente.000 o 30. son claramente preocupantes porque indican dónde radica el problema real de la actividad informática. La productividad en la construcción del software Desgraciadamente. aunque la cifra de errores llegue a casi 30 por cada 1. se ha producido una clara inversión de la tendencia que. Además. la productividad queda todavía muy lejos de la que se ha alcanzado ya en el hardware. Es evidente que la razón principal de este cambio ha sido la generalización del hardware y su redimensionamiento a la baja. el doble del coste que representa producirlas.1. más bien al contrario. lo cierto es que aquí nos ofrecen una primera idea de cómo.000 líneas de código fuente durante el proceso de desarrollo. Sin embargo.

y al mismo tiempo exigido. La mayor complejidad del software nuevo Los avances de las últimas décadas han permitido. De los primeros sistemas monousuario de tratamiento por lotes* típicos de los años cincuenta y sesenta se evolucionó a los sistemas interactivos multiusuario soportados en complejos monitores transaccionales y a los sistemas de base de datos que permitieron el teleproceso y el procesamiento en tiempo real característicos de los años setenta. La tendencia a la distribución y el nacimiento de nuevas exigencias en las comunicaciones informáticas se incre* En inglés.4. se ha acentuado el peso del mantenimiento de las aplicaciones informáticas.1. adaptaciones y mejoras necesarias de las aplicaciones informáticas con el fin de ajustarlas al entorno cambiante de nuestra sociedad. La importancia del mantenimiento de las aplicaciones informáticas Paralelamente a la inversión de la proporción de los costes informáticos de hardware y software. 2. con el inicio de los grandes proyectos de construcción de software (de sistema o de aplicación).5. . los sistemas de información se deben mantener no sólo para corregir errores. En los años ochenta. 2. como muestra el hecho de que los grandes constructores y proveedores informáticos facturasen por separado el hardware y el software. A mediados de los sesenta. Podéis ver el subapartado 1. Como decíamos anteriormente. en la cual se invierten más de dos terceras partes de la capacidad de trabajo de analistas. programadores y otros especialistas informáticos.© FUOC • P03/75069/02141 28 El proyecto informático de construcción de software Evolución de los costes de software y hardware Durante los años cincuenta y sesenta.1. el desarrollo de nuevas aplicaciones informáticas más grandes y también más complejas. la responsabilidad del desarrollo del software no termina cuando el producto se instala y entra en explotación. los costes de éste empezaron a acercarse al 50% del total. las cifras iniciales ya se habían invertido y dejaban el hardware incluso en menos del 20% del coste global de los sistemas informáticos.9 de este módulo didáctico. realizar modificaciones (mantenimiento adaptativo) y añadir mejoras (mantenimiento perfectivo) constituyen la actividad conocida como mantenimiento de las aplicaciones informáticas. costumbre que se generalizó en la década de los setenta. sino también para atender a las modificaciones. batch. Mientras sirven y son útiles. el hardware representaba prácticamente el 80% del coste de un sistema informático e incluso se podía llegar a invertir grandes esfuerzos de programación para conseguir ahorrar espacios de memoria o tiempo de procesamiento en la unidad central del ordenador. Corregir errores (mantenimiento correctivo).

es triste constatar que la práctica profesional de la construcción de software de aplicación no ha evolucionado como se esperaba. Por otro lado. Entonces ya surgió la idea de aplicar técnicas típicas de la ingeniería a la construcción de software con el fin de incrementar. 2. Introducción a la ingeniería del software La expresión ingeniería del software se utilizó por primera vez en 1968 como un tema de un congreso organizado por la división de asuntos científicos de la OTAN. ventanas. las pantallas que se activan con los dedos. no debemos olvidar las nuevas necesidades y los requisitos del hardware y del software para gestionar las interfaces usuario/ordenador modernas. . nuevos dispositivos señalizadores* y todo el mundo de Internet. como la de Mills en 1980. dotadas de sistemas de representación gráfica. computer science. * Como el ratón. al mismo tiempo. en otro congreso sobre el tema. sin olvidar la necesidad ineludible de hacer más fácil el proceso necesario de mantenimiento. y los datos de productividad de software no han cambiado demasiado de los que eran habituales en los años setenta y ochenta. que consideraba la ingeniería de software como un conjunto de disciplinas y procedimientos para la construcción y el mantenimiento de software viable y económico. En 1969.2. * En inglés. la ingeniería del software era definida por Fritz Bauer como el establecimiento y el uso de principios de ingeniería robustos orientados a obtener de forma económica software fiable y que funcionara eficientemente en máquinas reales. * CASE es la sigla del término inglés Computer Assisted Software Engineering. La definición de Bauer puede que sea la que mejor marca los objetivos que entonces perseguía (y aún persigue) la ingeniería del software.© FUOC • P03/75069/02141 29 El proyecto informático de construcción de software mentó con la extensión de las redes de ordenadores y los nuevos sistemas distribuidos con cooperación de procesos y bases de datos también distribuidas. Allí se llegó a la conclusión de que era necesaria una nueva disciplina científica con una gran orientación práctica que superara las limitaciones que la informática* había encontrado en la creación de productos de software grandes y complejos. A pesar de estos cambios en el producto. la productividad del proceso de desarrollo y la calidad del producto obtenido en la construcción de software. El proceso de construcción de software todavía es demasiado parecido al bricolaje. Aún se utilizan pocos recursos de productividad como las herramientas CASE*. etc. el lápiz óptico. Con el tiempo se han propuesto otras definiciones. que acababa de nacer.

define la ingeniería del software parafraseando la definición de ingeniería del diccionario Webster. Esta consideración de la economía es tal vez el aspecto central de lo que muchos ya denominan la orientación proyecto en la actividad de construir software. junto con otras fases más ampliamente reconocidas*. En el mencionado libro. Lectura complementaria Podéis encontrar la cita mencionada en la obra siguiente: IEEE (1983). publicado en 1981. . después de analizar los conceptos de software e ingeniería. cita una fase de retirada o de sustitución del software. como era habitual. Encontramos un resumen adecuado del alcance de la ingeniería del software en la concisa definición de una famosísima asociación de profesionales. de Barry Boehm. Barry Boehm. la ingeniería del software se presenta como un enfoque sistemático y profesional orientado a producir un software que proporcione sus funcionalidades con la mejor calidad. posiblemente por primera vez. había sido objeto de la informática. los procedimientos y la documentación que los acompaña. la operación. Standard Glossary of Software Engineering Terminology. Conviene destacar que la definición de Boehm no se refiere sólo a los programas de ordenador. hasta entonces. el IEEE: la ingeniería del software es una perspectiva sistemática del desarrollo. pero aplicándola concretamente al aprovechamiento del equipo informático y al caso particular de los ordenadores: la aplicación de la ciencia y las matemáticas mediante la cual las capacidades de los ordenadores se hacen útiles a los humanos a través de los programas de ordenador. el mantenimiento y la retirada del software. al coste más bajo posible (económicamente) y * Como desarrollo.© FUOC • P03/75069/02141 30 El proyecto informático de construcción de software Conviene precisar que las definiciones de Bauer y Mills coinciden en provocar la intervención. Un rasgo significativo de esta definición de ingeniería del software es que. del aspecto económico en una reflexión tecnocientífica sobre la producción del software que. En todos los casos. sino también a los procedimientos que se utilizan para obtener estos programas y –un hecho fundamental para el mantenimiento– a la documentación que los acompaña. Nueva York: Institut of Electrical and Electronic Engineers. Se trata de obtener unas funcionalidades en un determinado plazo y respetando un presupuesto económico. Es necesario constatar que la principal obra para el estudio de los proyectos informáticos y de su faceta económica tiene precisamente el título Software engineering economics (‘La economía de la ingeniería del software’). Éste es un punto de vista que refuerza la idea del ciclo de vida del software y de su caducidad. una disciplina demasiado teórica y poco preocupada por los aspectos pragmáticos. utilización y mantenimiento.

. Especificidad en la construcción de software de aplicación Evidentemente. ha de ser eficiente en el uso y en el aprovechamiento del hardware y no ha de incorporar errores. principalmente. desgraciadamente... los proyectos informáticos de construcción de software de aplicación presentan unas características diferenciales que. pero el hecho de que. La calidad de este software se debe entender en el sentido de que. la efectividad real de este . Pero. los de su mantenimiento justifican la necesidad de un enfoque sistemático y profesional en la construcción de aplicaciones y sistemas informáticos. En el caso de la construcción de software de aplicación. la construcción de software es un mero proceso de diseño. De hecho. antes de tomar la decisión final de producir las cadenas de fabricación donde se construye el nuevo modelo. además. impiden gestionarlos exactamente con los mismos métodos y técnicas con los que se gestionan otros proyectos de ingeniería. a pesar de que existe una fase de especificación o de diseño previa a la programación. al terminar. Si se dispusiera. de manera que el proceso de producción y la comprobación final de la calidad del proceso y del producto son francamente complejos y problemáticos. el diseño y la construcción del sistema son un único proceso y no existe una fase de diseño totalmente previa a la construcción o fabricación. Una de las diferencias más significativas consiste en el hecho de que. se efectúa un determinado número de prototipos de pruebas. por último. En otros campos de la ingeniería. el incremento de los costes de software informático y. en los proyectos informáticos. se da en primer lugar una etapa de diseño que genera las especificaciones finales de lo que después probablemente llegará a la fase de producción. es obvio que con un buen lenguaje de especificación y/o diseño que fuera directamente ejecutable en el ordenador no sería necesario acometer las fases de programación y de prueba tradicionales. además de ser útil para los usuarios. no sería necesario abordar las fases de programación y prueba. La etapa de diseño en un proceso clásico de construcción de un producto En la fabricación de un automóvil nuevo. como hemos dicho. Pero. incluso. también conviene que tenga un mantenimiento fácil.1. 2.. . existen razones específicas ligadas intrínsecamente al proceso de desarrollo y mantenimiento del software. No es necesario mencionar que es precisamente en esta segunda parte (la instalación de las cadenas de producción) donde se invierte la mayor parte de los recursos del proyecto de fabricación. En realidad. primero se realiza el diseño e. de un procesador de lenguaje que generara un código ejecutable a partir de las especificaciones expresadas en un lenguaje adecuado.2.© FUOC • P03/75069/02141 31 El proyecto informático de construcción de software cumpliendo los plazos de tiempo establecidos. este diseño tome la forma de una especificación final en un lenguaje ejecutable para ordenador provoca que el diseño mencionado se asimile a un proceso completo que incluye también la fabricación.

fiable. En definitiva. dividir el proyecto informático en los dos subproyectos siguientes: • uno en el que se establezcan las especificaciones • otro en el que se implementen las especificaciones detalladas en el subproyecto anterior. mientras que la implementación consta de las fases de diseño. que ya hemos descrito. dentro del mismo proyecto. respectivamente. 2.8 de este módulo didáctico. una vez se han determinado con cierto detalle. Por otra parte.. como en la gestión del proyecto que tiene como objetivo obtener éste.. Es recomendable.2.2. las dificultades en relación con la calificación correcta de un proyecto informático de construcción de software de aplicación provocan que se recomiende. la descomposición de cada proyecto informático en dos proyectos consecutivos: 1) Un primer proyecto que tenga como objetivo funcional principal establecer simplemente las especificaciones detalladas de lo que después se debe programar e instalar.© FUOC • P03/75069/02141 32 El proyecto informático de construcción de software tipo de lenguajes aún es muy precaria y por ello el ciclo de vida real es muy parecido al tradicional. la realidad es que la práctica profesional todavía descansa ampliamente en el ciclo de vida tradicional.. A pesar de todos los intentos de producir sistemas de construcción de software utilizando prototipos. programación y pruebas.. la ingeniería del software aporta una visión que quiere ser seria y metódica tanto en el proceso de elaboración del software. . generalmente con un volumen de esfuerzo y un coste más elevado. . que cubra la etapa de programación y pruebas. La práctica profesional más habitual ve como un único proyecto la determinación de los requisitos y la especificación. las fases de determinación de los requisitos y de especificación se denominan. En la práctica profesional. Desgraciadamente. fácil de usar. las especificaciones y las funcionalidades concretas que deben implementarse. Podéis ver las dificultades asociadas a la calificación correcta en el apartado 2 del módulo “Estimación de costes de un proyecto informático” de este módulo didáctico. 2) Se ha de construir este software mediante un proceso correcto y adecuado que implique una gestión eficaz de los recursos puestos en disposición del ingeniero de software para la construcción de un nuevo sistema informático: personas y recursos informáticos de todo tipo. no se realiza de manera habitual esta subdivisión de los proyectos informáticos de construcción de software de aplicación. fácil de mantener.... de la implementación hasta llegar a la puesta en funcionamiento definitiva de la aplicación. eficiente. seguidas.. incluso desde ámbitos jurídicos. es comprensible que esta la ingeniería en la construcción de software de aplicación tenga estos dos objetivos centrales: 1) Debe obtener un producto de software de calidad que sea económico. 2) Un segundo proyecto. Podéis ver el ciclo de vida de una aplicación informática en el subapartado 1.. en el primer proyecto. Objetivos generales Ante la realidad que hemos descrito con relación a la ingeniería del software. etc. estudio de oportunidad y análisis funcional. .

también. *** En inglés. respetando los procedimientos establecidos para el mantenimiento futuro. Componentes Para conseguir los dos objetivos centrales de la ingeniería del software.. es necesario introducir técnicas concretas que acerquen la actividad de construcción de software de aplicación a las actividades de ingeniería tradicional y que rechacen las prácticas poco profesionales y demasiado cercanas al bricolaje que. consistente. con herramientas CASE. aún predominan en gran parte del ámbito profesional. la ingeniería de recursos** y la ingeniería de programas***.© FUOC • P03/75069/02141 33 El proyecto informático de construcción de software 2. 2) Respecto al proceso a) El aspecto de las relaciones humanas obliga a planificar.3. Un software preciso y adaptable. Para alcanzar todo esto. para utilizar técnicas como la estructuración y porque garantiza la legibilidad y facilita la comprensión de diseños y resultados. c) La ingeniería de programas exige la validación de la factibilidad del proyecto y de sus requisitos y especificaciones. c) La ingeniería de programas se concreta en el hecho de que el software esté especificado con precisión. organizar. hasta llegar a la implementación. b) La ingeniería de recursos exige que el producto sea modificable y adaptable a cambios futuros totalmente inevitables (sobre todo en el ámbito de la informática de gestión) y que su eficiencia de uso proceda de un equilibrio adecuado entre los costes de producirlo y los beneficios obtenidos en su utilización. desgraciadamente. también sea intrínsecamente adaptable o modificable.. program engineering. es conveniente. el control de los hitos o puntos cruciales del proyecto y el respeto de los plazos y presupuestos. b) La ingeniería de recursos presupone una estimación previa a la planificación adecuada y un análisis de costes y beneficios correcto y. la programación y la misma integración del sistema.2. respecto al producto y al proceso. verificable y realizable y que. * Por ejemplo.. de una manera completa. ** En inglés. human relations. además de la puesta en funcionamiento de un sistema de verificación y validación del diseño. . Como consecuencia de este análisis se formulan las siguientes conclusiones: 1) Respecto al producto a) Las relaciones humanas se concretan en la necesidad de que el software producido sea fácil de utilizar y pueda satisfacer las necesidades reales de los posibles usuarios. por ejemplo. dirigir y controlar el proceso de construcción de software de aplicación y su posible automatización*. Boehm analiza. resource engineering. las características de tres componentes fundamentales: las relaciones humanas*. además de que sea correcto.. * En inglés. .

). hasta llegar a la puesta en funcionamiento o a la entrada en explotación del sistema de información. planificar y controlar el trabajo de construir software y. en definitiva. sólo se tiene en cuenta el proceso de construcción hasta llegar a la puesta en funcionamiento de la aplicación.. la estructuración de los datos y programas o el control de procesos múltiples y asíncronos en los sistemas distribuidos y en los de tiempo real. .9 de este módulo didáctico.. * En inglés. el diseño. Recordemos que existen otras maneras de contemplar el ciclo de vida que se tratan con detalle en las asignaturas de ingeniería del software. mantendremos genéricamente las etapas tradicionales ya mencionadas: 1) La construcción.8 de este módulo didáctico. que consiste en la elaboración de una determinada aplicación informática. Podéis ver los costes reales de una aplicación informática en el subapartado 1. se agrupan los procesos prácticos del proceso de construcción y desarrollo de software desde el punto de vista de las técnicas y las herramientas puestas a disposición de las personas responsables de construir el producto final: entornos de desarrollo (lenguajes. pero aquí. el desarrollo y la gestión. cuando se considera un proyecto informático. lo que se denomina ciclo de vida de una aplicación. en lo referente a la gestión de proyectos informáticos. También hemos mencionado que. procedimientos ordenados de desarrollo progresivo (como el diseño descendente top down) y técnicas formales de documentación de productos de software. b) Con respecto al desarrollo*. Distribución de costes en la construcción del software Ya se ha realizado una sencilla enumeración de las diferentes etapas técnicas por las que pasa el proceso de construcción de software. recordando una vez más la inconveniencia desde el punto de vista económico de Podéis ver el ciclo de vida de una aplicación informática en el apartado 1. Consideremos cada uno de estos entornos: a) En lo referente al diseño*. frecuentemente. gestionar el proyecto informático. software engineering development.4. * En inglés. software engineering management.. el análisis.2. todo esto se traduce en la incorporación y el dominio de técnicas procedentes de tres entornos conceptuales complementarios: el diseño. * En inglés. en la vida de una aplicación son: • la construcción • el mantenimiento. etc. Las dos grandes etapas. como los esquemas básicos de composición de algoritmos. Por tanto. se deben atender los temas más teóricos propios de la informática. herramientas de todo tipo.© FUOC • P03/75069/02141 34 El proyecto informático de construcción de software Para un especialista como Mills. . 2) El mantenimiento del sistema de información hasta que los usuarios decidan retirarlo al final de su vida útil. 2. la programación (o codificación) y las pruebas. c) En la gestión* se agrupan todas las prácticas necesarias para valorar. formada por el estudio de oportunidad. ayudas. software engineering design..

conviene puntualizar que. Es importante intentar minimizar su número. software quality assurance. en general. En relación con estos costes. pero conviene saber que. el mantenimiento. Podéis ver las métricas del software en el apartado 1 del módulo “Estimación de costes de un proyecto informático” de esta asignatura. de órdenes de magnitud. Prácticamente se puede decir que las dos terceras partes del personal técnico informático* se encargan del mantenimiento de aplicaciones antiguas.. se deja al margen de esta distribución. • El resto.8. A pesar de que se intentan utilizar procesos de producción de software que aseguren la calidad y la ausencia de errores. suele representar el doble del coste del desarrollo. . en las instalaciones informáticas en la informática de gestión. los programadores. Evidentemente. incluso cuando está en explotación. los analistas. El porcentaje de coste.© FUOC • P03/75069/02141 35 El proyecto informático de construcción de software olvidar los costes del mantenimiento. • Un 20%. evidentemente. están mejor pagados los especialistas que trabajan en las etapas de análisis y diseño. queda para la parte correspondiente a las pruebas. un 40%. * En inglés.2. desgraciadamente. que los que se ocupan de las tareas de programación. suponen un mayor esfuerzo en horas de trabajo. . * Como analistas. • Pruebas: 40%.5. éstos parecen algo inevitable en la construcción de software. Origen e importancia de los errores en el software Uno de los objetivos de la ingeniería del software es la obtención de software de calidad. 2. en la práctica profesional actual. mientras que sólo una tercera parte o menos se dedica a construir aplicaciones nuevas. diseñadores y programadores. Como veremos con detalle al tratar las métricas o unidades de medida del software. uno de los costes más elevados del software. aunque las proporciones exactas pueden depender de cada sistema concreto y del método de medida utilizado para construirlo. Insistimos en que el mantenimiento.. se basa en el número de errores presentes en el software. a pesar de que éstas. Diferentes autores han analizado la distribución del coste global del desarrollo de un proyecto informático y. siempre quedan algunos. en la etapa de codificación. Se trata... se aceptan como referencia general las cifras establecidas a finales de los años setenta y principios de los ochenta por autores como Boehm y Brooks. en las etapas del ciclo de vida de una aplicación es el que mostramos a continuación: • Análisis y diseño: 40%. una de las medidas de calidad. como muestra la figura “Recursos y ciclo de vida” del subapartado 1. • Codificación: 20%. nos centraremos en los costes de la construcción de software de aplicación. evidentemente. Esta distribución es la que presentamos a continuación: • Un 40% del coste de desarrollar una aplicación informática se invierte en las etapas de análisis y diseño.

. Una de las causas de estas cifras (que debemos interpretar en un sentido no rigurosamente exacto. la corrección de un error detectado en la fase de diseño cuesta siete veces más. pero sí como referencia) se encuentra en el sistema del proceso de construcción de software de aplicación basado en el ciclo de vida en cascada. A medida que la ingeniería del software se ha ido preocupando de los aspectos más claramente económicos. corregir un error descubierto en la fase de mantenimiento* puede ser hasta cien veces más caro que si se hubiera detectado durante la fase de análisis.3. un 20% más a la fase de diseño lógico y técnico y hasta un 35% son errores que tienen su origen en insuficiencias de la documentación.. desgraciadamente.. • Documentación insuficiente. Se considera que un 15% de los errores corresponden a las fases de análisis y diseño funcional. debería ser evidente la necesidad de establecer métodos y procesos de construcción de software que permitan evitar los errores o detectarlos lo más pronto posible. ya a partir de los años sesenta. sobre todo. se trató de elaborar procesos de construcción de software de aplicación que permitieran incorporar un mínimo de seguridad respecto de la calidad del software obtenido. * Es decir. que provoca que un error detectado en una fase posterior suponga modificar las etapas anteriores. incomprensiones. malentendidos y otras causas a lo largo de todo el ciclo de vida de construcción de software de aplicación.. • Fase de codificación: 30%. incomprensiones y malentendidos: 35%. no se suelen descubrir hasta las pruebas finales de integración o de aceptación del sistema. 2. con lo que ello supone de coste y desorden. En cualquier caso. siempre inevitable en la informática de gestión. . Un método de detección de errores en las fases iniciales Últimamente se ha incrementado la tendencia a experimentar con prototipos provisionales para detectar. • Fase de diseño: 20%. cuando el software ya está en explotación.© FUOC • P03/75069/02141 36 El proyecto informático de construcción de software Estudios como el de Jones de finales de los años setenta y principios de los ochenta han establecido que solamente un 30% de los errores presentes en el software proceden de la etapa de codificación. Según Boehm. Tomando como base el coste de corregir un error de análisis descubierto en la misma fase de análisis de requisitos y elaboración de las especificaciones (análisis funcional). los errores (a menudo de interpretación de las necesidades de los usuarios) nacidos en la fase de análisis que. además de garantizar la mayor facilidad posible para el mantenimiento. ha interesado analizar la importancia de errores y el coste que supone corregirlos. El coste de corrección de un error será diez veces más alto si se observa en la fase de codificación y veinte o treinta veces más si se descubre en la fase de pruebas. en las diferentes fases del proyecto informático se distribuye de la manera siguiente: • Fase de análisis: 15%. Boehm ha mostrado que este coste difiere según la etapa en la cual se descubren los errores. El origen de los errores del software. . Metodologías de construcción del software En la práctica profesional.

El trabajo de cada programador era esencialmente intuitivo y orientado fundamentalmente a una optimización de la eficiencia para ejecutar los programas en una máquina concreta. en realidad..© FUOC • P03/75069/02141 37 El proyecto informático de construcción de software Las primeras realizaciones en el campo de la creación de sistemas de información se reducían a la programación. herramientas utilizados precisamente en el proceso de construcción de software en la actividad que se etiqueta habitualmente como proyecto informático. En la década de los sesenta se planteó un nuevo problema: la necesidad de racionalizar la producción de un software que. se utiliza el término metodología para referirse a un conjunto de métodos. se debía mantener. en definitiva. más o menos compleja y difícil. . técnicas e. Además. existe un factor que se reveló todavía más urgente: la carga de trabajo que suponía el mantenimiento de software provocó plantearse la necesidad de convertir la tarea de programar en una actividad mucho más estructurada y metódica. Si se pensaba en el mantenimiento. por ejemplo. Con el presuntuoso nombre de metodologías de análisis y programación aparecieron varios procedimientos para crear sistemas de información. se refieren a métodos. no se corresponde con el significado habitual de ‘ciencia del método’. indica.. 2. es una secuencia de instrucciones establecida como una descripción no ambigua de las acciones que se han de llevar a cabo para obtener un resultado determinado. En la práctica profesional informática. y a menudo con lenguajes tediosos de tipo ensamblador. fuera necesario mantener el software. Como se ha dicho. metodologías de diseño o de metodologías de información cuando. el objetivo era optimizar el uso de los escasos recursos disponibles. a finales de la década de los sesenta y principios de los setenta.. la mejora de prestaciones de los ordenadores no tiene un paralelo en la productividad en el campo de la construcción y la puesta a punto de programas. en el diseño de diferentes técnicas y métodos de construcción de aplicaciones informáticas. . . Un algoritmo. meses después. Por ello se puso tanto interés. ya no eran interesantes las soluciones ingeniosas que podían ahorrar recursos pero que eran difíciles de entender para el mismo programador (o para el sustituto de éste) cuando. En el caso concreto de la ingeniería del software.. analizar y comparar métodos.. además. incluso. El uso informático del término metodología. que se debería reservar para la ciencia que se ocupa de estudiar. al aumentar la complejidad de los sistemas de información que se construían (ya no simplemente programas) se observaba la dificultad creciente de fabricar correcta y rápidamente el software necesario. El problema principal era conseguir algoritmos que fueran rápidos y utilizaran poca memoria..3. Precisión terminológica previa Los profesionales de la informática suelen hablar de metodologías de análisis..1.. cómo se deben seleccionar los métodos y las técnicas más adecuadas para ser utilizadas en un proyecto informático concreto. Al contrario.

Metodologías explícitas y metodologías implícitas Retomando el tema más general de las metodologías de construcción de software. Asimismo. simplemente. siguiendo las directrices de la metodología y empleando las herramientas del entorno. Las diversas metodologías utilizadas en la práctica profesional se diferencian. etc. Por razones obvias. que utilizan las personas son. como hacemos en esta asignatura. cualquier proceso de construcción y desarrollo de software se lleva a cabo siguiendo un método determinado.2. se suele caracterizar como metodología (explícita) de construcción de software el método.. textos. Sólo tiene sentido decir que se utiliza una determinada metodología cuando se ha definido explícitamente en normas. la legibilidad o la arquitectura.© FUOC • P03/75069/02141 38 El proyecto informático de construcción de software Por tanto. y. los conceptos teóricos.. y también de metodologías de programación. entendido como el conjunto de aspectos del proceso de construcción de software que en cierta medida son independientes del software concreto que se construye y de las personas que trabajan en él. profesional y técnico en el que se emplean. Se dice que se aplica una metodología implícita cuando la metodología de construcción de software que se utiliza no está definida explícitamente y es.. se habló en ocasiones de metodologías de diseño. 2. los estándares de nomenclatura. además. o al conjunto de métodos. por ejemplo. Las causas más importantes proceden del entorno organizativo. documentado y enseñable. Algunas de las prácticas. el término metodología en informática se utiliza como un sinónimo forzado de método. deductivas o de verificación. por muchas razones. La parte propiamente informática de un método está constituida por las herramientas informáticas integradas en el entorno de desarrollo y construcción del software. la manera de trabajar de un determinado profesional o de un grupo de profesionales informáticos. a menudo radicalmente. las técnicas descriptivas. se comienza a extender el uso de una referencia genérica a las metodologías de construcción (o de desarrollo) del software.3.. etc. Las personas utilizan las prácticas que conocen para construir el software deseado. . en función de la etapa del ciclo de vida en la que las diferentes metodologías incidían más. a pesar de que hoy en día. La dimensión y el tamaño del proyecto informático. que reúne las características de ser público. la formación y los conocimientos del personal que forma el equipo de proyecto y el tipo de sistema . Durante los años setenta se hablaba preferentemente de metodologías de análisis. cuando la ha adoptado oficialmente una organización para aplicarla en todos o en algunos de los proyectos informáticos que debe realizar. cursos.

Por otra parte. 2. Aunque las diferentes metodologías utilizan términos diferentes. • Las ayudas mecanizadas de las que dispone para ayudar a realizar. en el ciclo de vida en cascada tradicional. documentar y controlar el proyecto informático.3. volver a calificar el proyecto informático y también. Es evidente que un proyecto pequeño seguramente no necesita el mismo grado de complejidad de desarrollo y de gestión que un proyecto muy grande. comenzar la etapa siguiente. que tiene como resultado una documentación completa la cual. se suele atribuir la máxima importancia al procedimiento y a la organización que se deriva de éste. a veces. • La documentación que proporciona. Comprobar que una metodología sea adecuada para un proyecto informático concreto es un paso previo muy importante para el éxito del proyecto informático de construcción de software de aplicación y puede tener efectos sobre la calidad del programa construido. actividades. 1) El procedimiento de la metodología El procedimiento de trabajo determina el conjunto de operaciones que se deben efectuar durante el proceso de construcción de software. • La organización y el reparto del trabajo que supone. Estas operaciones se agrupan en una serie de etapas. Muchas veces una metodología se caracteriza simplemente por el ciclo de vida. De los cuatro componentes mencionados de una metodología. una etapa se puede caracterizar como un conjunto de operaciones o actividades con un inicio y un final claramente definidos. fases. Componentes Los componentes principales de una metodología tradicionalmente son los siguientes: • El procedimiento que aconseja utilizar. debe servir de base para evaluar el sistema. etc. decidir si el proyecto debe continuar o no.3. la descomposición en etapas del proceso de construcción de software recibe el nombre genérico de ciclo de vida y se considera uno de los . subfases.© FUOC • P03/75069/02141 39 El proyecto informático de construcción de software de información y/o aplicación que se quiere construir son algunos de los elementos que justifican la adopción de diferentes metodologías.

Respecto al lenguaje con el que se elabora la documentación. Este punto de vista es particularmente importante en la gestión de proyectos informáticos. sin mantener las categorías antiguas de analista y programador). como veremos. permite determinar. . * En inglés. dificulten la utilización de nuevas metodologías que empleen un ciclo de vida que descomponga y reparta el trabajo de otra manera entre los técnicos informáticos especialistas (por ejemplo. En definitiva. . ya que. 2) La organización de la metodología El procedimiento que se debe seguir supone.4. * La calificación consiste en realizar una estimación y una planificación del proyecto informático. en los dos casos.8 y 2.. implementación y mantenimiento) que. hecho que ha tenido como consecuencia que. por ejemplo. en este caso. milestones. el seguimiento. cómo se han de relacionar los diferentes miembros de un equipo de proyecto y. Podéis ver el ciclo de vida en cascada y los hitos en los subapartados 1. cuáles son las responsabilidades respectivas. del denominado ciclo de vida en cascada. a menudo se considera que son independientes. respectivamente. El ciclo de vida consta de diferentes etapas (por ejemplo: estudio de oportunidad. análisis. En realidad.3. puede ser gráfico o narrativo y.. indefectiblemente. en cierta manera. teniendo en cuenta la relativa inercia del mundo laboral. que hemos mencionado anteriormente.. también. diseño. aunque muy a menudo las diferencias son más terminológicas que reales. qué formación técnica y administrativa han de tener. imprescindibles para un buen control del proyecto informático. formalizado o no. una determinada organización del trabajo. Se trata. a pesar de que en la práctica se interrelacionan. el control y la organización del proyecto de construcción de software. las diferentes metodologías que existen tampoco coinciden en el ciclo de vida que proponen. las primitivas categorías profesionales (que surgen de determinadas metodologías propias de los años setenta y ochenta) se mantengan más de lo que sería conveniente y. La organización del trabajo se entiende como un conjunto de normas con el fin de realizar a cabo la calificación*. de este módulo didáctico. En general.© FUOC • P03/75069/02141 40 El proyecto informático de construcción de software aspectos más característicos y relevantes de las metodologías. se considera que un hito se ha alcanzado y que. cuando toda la documentación prevista para la etapa se ha realizado. la organización determina el reparto del trabajo entre los diferentes profesionales.. el contenido y las técnicas con las cuales ésta se crea. ha terminado una etapa y comienza la siguiente. La documentación es el tercer componente de una metodología y proporciona. en la práctica del seguimiento a menudo se considera que las diferentes etapas están separadas por los denominados hitos*. 3) La documentación de la metodología La organización del trabajo. en particular. el tipo de profesionales que deben intervenir en cada etapa del ciclo de vida. por tanto.

• un manual de explotación • documentación de promoción. e) Documentación de presentación. los mecanismos de seguridad y de reactivación en caso de fallos. mientras que el último es documentación de promoción orientada claramente a la venta o difusión de la aplicación. la interpretación de los datos de salida. * El sistema de ayuda al usuario de una aplicación es lo que a menudo se denomina help. d) Documentación de explotación (o documentación de operación). el manual de usuario y el manual de explotación. a menudo de manera resumida. pero lo cierto es que exigir un exceso de documentación ha supuesto que el trabajo de utilizar una metodología sea pesado y se puede decir que. para entregar a los usuarios de la aplicación con toda la información acerca de cómo introducir los datos. . • un manual de usuario. . la documentación elaborada en la práctica suele ser bastante más escasa de lo que pide la metodología. aunque la buena práctica profesional actual también consigna esta información en los sistemas de ayuda al usuario* de la aplicación.© FUOC • P03/75069/02141 41 El proyecto informático de construcción de software En relación con la finalidad de la documentación. que incluye aspectos como las alternativas que se han considerado y los cálculos y motivaciones que conducen a la elección de una de estas alternativas. por la dificultad de mantener una documentación consistente y actualizada. etc.. etc... A menudo. esta documentación se denomina manual de usuario. Una característica común de la mayoría de las metodologías es que muestran un énfasis casi desmesurado en la necesidad de disponer de una documentación técnica completa y ordenada de todos los pasos realizados en la construcción de una aplicación. donde se incluyen la forma de instalación. c) Documentación de utilización. asociada a una metodología se incluyen los elementos siguientes: • un manual técnico. para uso de los operadores informáticos del sistema. no necesariamente excluyentes: a) Documentación de descripción técnica de los modelos y los elementos del sistema de información con diferentes grados de abstracción y detalle. respectivamente. Los dos primeros tipos de documentación (a y b) componen lo que se denomina manual técnico. incluso en la etapa de mantenimiento. es una reacción inevitable a la terrible falta de documentación en el método de trabajo de construcción de software de aplicación antes de la llegada de las metodologías. el significado de las opciones y códigos. los errores posibles. En la documentación. elaborada con el objetivo de presentar el sistema y sus funcionalidades a los usuarios. a menudo.. b) Documentación de trabajo o documentación interna de una etapa. principalmente. los controles de calidad de operación. los dos siguientes forman. Seguramente. Un aspecto muy importante es la dificultad de obtener una documentación correcta y adecuada a causa de la enorme cantidad de información que se genera en un proyecto informático y. se puede hablar de los siguientes casos.

. . El procedimiento de la metodología sirve entonces para definir con más detalle las actividades tipo que se deben llevar a cabo en cada etapa y las técnicas que es necesario utilizar. su componente principal. También pueden ayudar a gestionar la organización del proyecto (concretamente. a pesar de su actual disponibilidad y potencia. pueden ayudar a controlar el proceso de progreso y realización) y facilitar el trabajo de elaborar la documentación exigida por la metodología. 2. los montadores de enlaces (linkers) y otras herramientas.4. como los programas editores. * Sistemas CASE. generadores de pantallas y diálogos. . Entendemos por ayudas automáticas los programas informáticos destinados a facilitar el trabajo de construir software. no parece que se utilicen tanto como sería conveniente. Las ayudas automáticas pueden facilitar las actividades de análisis. por tanto.. los compiladores.© FUOC • P03/75069/02141 42 El proyecto informático de construcción de software 4) Las ayudas de la metodología Un buen ejemplo de ayudas automáticas. Las ayudas automáticas de las que disponen las metodologías tienen un interés especial. Ciclo de vida y procedimiento Conviene analizar el papel que en una metodología ejerce el ciclo de vida en comparación con el papel atribuido al procedimiento utilizado para construir software. Existe una visión tradicional que define el ciclo de vida como una parte fundamental del método y considera que es el marco de referencia al cual se han de supeditar los demás componentes de la metodología. se podría decir que el ciclo de vida define la arquitectura del método de trabajo y es. De esta forma. diccionarios de datos.3. Esta visión tradicional ha sido sustituida recientemente por un enfoque más práctico y realista que independiza el procedimiento recomendado en la metodología de las etapas del ciclo de vida. etc. Según esta visión tradicional. son los componentes típicos de los entornos de programación y diseño. las normas de documentación de una metodología se describen en relación con los documentos que definen los hitos del ciclo de vida.. La visión integrada de las ayudas mecanizadas mencionadas da lugar a los sistemas de ingeniería del software soportada por ordenadores*. los cuales. el procedimiento propio de la metodología se considera como una guía técnica para la construcción de software y el ciclo de vida como una superestructura que se sobrepone al mencionado procedimiento.. como procesadores de tablas de datos. diseño o implementación propias del procedimiento recomendado por la metodología. En la práctica.

la documentación que se exige y los ajustes informatizados disponibles. además del procedimiento (reflejado hasta cierto punto en el ciclo de vida). sean cuales sean las características de cada nuevo proyecto informático de construcción de software de aplicación. naturalmente. pero es indudable que a lo largo de la corta historia de la informática profesional. 2. de la posibilidad de repetir o no las características citadas entre los diferentes proyectos sucesivos que se abordan. programación. ciclo de vida en espiral. ciclo de vida con prototipos. ciclo de vida en fuente. etc. en el seno de la ingeniería del software. . el mantenimiento futuro y la evolución de la aplicación.3. sin embargo.© FUOC • P03/75069/02141 43 El proyecto informático de construcción de software La manera práctica en la que se ha implantado este concepto de ciclo de vida en las organizaciones que construyen software consiste en definir un ciclo de vida normativo para todos los proyectos de desarrollo nuevo que se llevan a cabo y tratar de aplicarlo.5. sobre todo. se habla de ciclo de vida en cascada. d) Facilitar el proceso de pruebas y. incluso se ha querido dar un carácter universal al concepto de ciclo de vida y se han presentado ciclos de vida como “el ciclo de vida que se debe utilizar para cualquier proyecto de construcción de software”. Así. con esta caracterización del ciclo de vida. b) Favorecer una correcta gestión del proyecto informático. y. se debe tener en cuenta la organización (el reparto de las tareas entre los profesionales y su cualificación técnica implícita). En determinados planteamientos que forman parte de la ingeniería del software. El éxito de este enfoque depende. Cabe recordar. Esta idea de un “ciclo de vida universal” no se puede tomar al pie de la letra debido a la gran variedad de productos de software posibles. etc. si es necesario con pequeños ajustes.). el ciclo de vida considerado como paradigma que se debe utilizar ha existido y ha evolucionado a medida que ha progresado el conocimiento del software como producto. Características generales y supuestos implícitos Cualquier metodología de construcción de software de aplicación debería tener al menos los siguientes rasgos: a) Comprender todo el proceso de desarrollo del sistema de información (a pesar de que existen metodologías restringidas a determinadas etapas: análisis. se cree que ya se ha dicho todo acerca del método que debe utilizarse para construir software. c) Garantizar una comunicación fluida entre las personas que intervienen en el proyecto mediante la documentación que se genera. que la realidad es más compleja y que en la construcción de software de aplicación.

*** Con lenguajes tradicionales de bajo o alto nivel. en la mayoría de los casos. o distribuidos. Teniendo en cuenta esto. se adapta al ciclo de vida en cascada tradicional. conviene decir que la mayoría de las metodologías existentes en la práctica profesional presentan las siguientes características: 1) Los sistemas de información que construyen son relativamente estables y autónomos. también conviene tener en cuenta que no todas las metodologías sirven para cualquier tipo de proyecto informático. con el fin de conseguir un mantenimiento fácil. f) Hacer visible y controlable el progreso en la construcción del sistema de información que se quiere llevar a cabo. Detectar cuáles son estos supuestos resulta muy importante para reconocer y evaluar la adecuación de una metodología en cada caso concreto. Es cierto que. g) Estar preparada para asumir mejoras en el futuro y poder adaptarse a los cambios en la tecnología informática. La mayoría de las metodologías se presentan como si fuesen útiles para todo tipo de proyectos. Ahora bien. aunque muy frecuentemente no se diga. de los aspectos técnicos** o de las herramientas utilizadas***. con independencia de los sistemas de información* concretos que se quieren alcanzar. ** Sistemas batch. en tiempo real. etc. * Sistemas transaccionales y de decisión. 2) El proceso de construcción imaginado es lineal y. la mayoría de las metodologías de desarrollo de construcción de software de aplicación utilizadas por los profesionales informáticos parten de supuestos (no claramente explícitos) que no siempre se dan en la práctica. que las especificaciones son claras y estables y que los usuarios que utilizarán la aplica- .© FUOC • P03/75069/02141 44 El proyecto informático de construcción de software e) Proporcionar ayudas automatizadas durante el proceso de construcción y mantenimiento que faciliten la pesada tarea de obtener documentación y que también permitan controlar si se utiliza correctamente la metodología. h) Poder ser enseñada y transferida. Muchas metodologías suponen también. con herramientas RAD (Rapid Application Development). A pesar de lo que se demanda. etc. El investigador escandinavo Janis Bubenko ha establecido una lista mínima de estos supuestos implícitos en las diferentes metodologías. Los procesos dominantes son de tipo rutinario o repetitivo y la información con la que se trabaja se encuentra estructurada. un poco arriesgadamente. conviene que haya siempre una uniformidad muy clara con respecto a la metodología utilizada en todos los proyectos informáticos de una determinada organización informática.

de escasa utilización real. . además. Excepto algunas metodologías surgidas en el ámbito académico.© FUOC • P03/75069/02141 45 El proyecto informático de construcción de software ción conocen sus necesidades de información presentes y futuras y. saben expresarlas y comunicarlas. la mayoría de las metodologías utilizan descripciones y técnicas de especificación y diseño casi siempre informales para facilitar que los usuarios no especializados las entiendan.

por no decir imposible. En la práctica profesional informática. desarrollo (seguimiento y control) y cierre. construcción y mantenimiento del software. en el argot profesional informático) de diseño. hasta cierto punto. lo que provoca que se planifiquen de manera que después es francamente difícil. se ha generalizado la idea de que los costes de tener una aplicación en disposición de ser operativa no incluyen los gastos de mantenimiento y durante la construcción del software no siempre se tiene en cuenta todo aquello que ayude a tener un buen mantenimiento.© FUOC • P03/75069/02141 46 El proyecto informático de construcción de software Resumen Los proyectos informáticos presentan suficientes particularidades para exigir un tratamiento especializado que. En demasiadas ocasiones los directores y responsables de empresa han constatado que los proyectos informáticos de construcción de software nuevo difícilmente finalizan en el plazo que se había calculado y con los costes previstos. construcción y mantenimiento del software con la misma seriedad y los mismos modelos típicos de cualquier otra actividad de ingeniería. plazos y presupuesto). técnicas e. En la gestión de un proyecto informático existen cuatro grandes etapas: inicio. Desde la conferencia de Garmish (1968) se quiere abordar el proceso de diseño. Parece que exista una tendencia inevitable a menospreciar las dificultades de los proyectos informáticos. Construir software seguro. Desgraciadamente. además. excepcional (único). calificación (estimación y planificación). los diferencia de otros proyectos del ámbito de la ingeniería. de duración limitada y flexible. lo que ha dado lugar a la denominada ingeniería del software y a diferentes métodos (o metodologías. seguir y controlar la producción de software. La actividad de gestión de un proyecto informático se orienta a obtener como objetivos generales unas determinadas funcionalidades. Un proyecto informático de construcción de software es la actividad que consiste en planificar. Un proyecto informático debe ser siempre concreto. El jefe de proyecto es la persona que coordina los diferentes aspectos del proyecto informático y se responsabiliza de ello. no permanece fijo y estático. las cuales deben estar disponibles en los plazos establecidos y deben alcanzarse respetando un determinado presupuesto. incluso. cumplir los objetivos del proyecto. fiable y de calidad es una actividad siempre llena de dificultades. el término metodología se aplica al conjunto de métodos. herramientas utilizadas precisamente en el proceso de construcción o mantenimiento de software. . sino que es algo vivo. sobre todo si se producen problemas para cumplir los objetivos del proyecto (funcionalidades.

la documentación que encarga realizar y las ayudas informáticas de las que dispone. la organización de las tareas que supone.© FUOC • P03/75069/02141 47 El proyecto informático de construcción de software Una metodología tiene como componentes principales el procedimiento de trabajo (ciclo de vida). .

.

como el Windows 98. ¿Cuáles son las características básicas de un proyecto informático? 4. Intentad imaginar por qué. ¿Por qué etapas debe pasar la gestión de un proyecto informático? 3. tengan fallos (la famosa pantalla azul). en la profesión informática. Buscad otros ejemplos semejantes. 2. ¿existe más o menos riesgo de error y de fracaso en el proyecto? 10. la Administración norteamericana de Ronald Reagan quiso poner en funcionamiento un sistema informático de detección y contraataque con misiles que se denominó Iniciativa de defensa estratégica (SDI) y que la prensa etiquetó como “la guerra de las galaxias”. con procedimientos perfectamente establecidos de ingeniería de software y que genera pocos problemas? 6. tiene alguna relación con lo que se estudia en este módulo. ¿Diríais que la construcción de software de gestión es una actividad bien conocida. al menos desde el punto de vista técnico. ¿Es cierto que la mayor parte del esfuerzo de análisis y programación de las organizaciones se dedica. ¿debe considerarse alta o baja? . ¿Cuáles son los objetivos centrales de la gestión de un proyecto informático de construcción de software? 2. Pensad razones que justifiquen que la construcción de software en la informática de gestión siempre es una actividad conflictiva. ¿Cuáles son los componentes básicos de una metodología de construcción de software? 7. Cuando se utiliza nueva tecnología en una aplicación. ¿Tiene algo que ver con el hecho de que en el siglo XVI. Mencionad las diferentes etapas del ciclo de vida de construcción de software con la denominación más tradicional. hoy en día. a la etapa de mantenimiento? 9. por ejemplo. 4.© FUOC • P03/75069/02141 49 El proyecto informático de construcción de software Actividades 1. ¿Por qué razón este proyecto. se utiliza una palabra tan larga como metodología para referirse a lo que es simplemente un método. estaba condenado al fracaso? Ejercicios de autoevaluación 1. 8. ¿Qué funcionalidades suelen fallar cuando un proyecto informático de construcción de software no puede cumplir con sus objetivos? 5. Durante los años ochenta. Una cifra de productividad de cerca de cincuenta líneas de código por día y persona (teniendo en cuenta el conjunto del proyecto). los médicos hicieran sus diagnósticos en latín a pesar de que aún no se sabía gran cosa sobre medicina y el funcionamiento del cuerpo humano? 3. Intentad averiguar si el hecho de que incluso los programas muy utilizados.

Existe más riesgo porque la novedad de la tecnología aporta incertidumbre al proceso de construcción de software. a constituir un paquete aislado (de manera natural o artificial) del resto para. de duración limitada y flexible. Un proyecto informático debe ser concreto. la documentación que encarga realizar y las ayudas informáticas de las que dispone. Una productividad de cincuenta líneas de código por día y persona se puede considerar alta porque los estudios efectuados por especialistas como Barry Boehm muestran que la cifra real de líneas de código está más cercana a diez que a cincuenta. 2. pero todavía no se ha conseguido. las funcionalidades que más fallan en un proyecto informático de construcción de software son las que menos ve el usuario: la calidad de diseño y programación. Generalmente. No. 9.© FUOC • P03/75069/02141 50 El proyecto informático de construcción de software Solucionario Ejercicios de autoevaluación 1. el número de pruebas. gestión de un proyecto informático m Proceso de dirección y control que se concentra en la concepción. el análisis. la organización del trabajo que supone. reparto en el tiempo de las diferentes actividades que se deben llevar a cabo (planificación). La gestión de un proyecto informático pasa por las etapas de inicio. Los objetivos centrales de la gestión de un proyecto informático son los siguientes: obtener un software que tenga unas funcionalidades determinadas. desarrollo de un proyecto informático m Proceso de recogida de datos sobre la evolución del proyecto para identificar las desviaciones entre la planificación y la realidad (seguimiento) y poder tomar las medidas de corrección necesarias (control). excepcional (único). fases de un proyecto informático f Conjunto concreto de actividades que forma una clase de subproyecto destinado a ayudar a controlarlo y. desarrollo (seguimiento y control) y cierre del proyecto. Glosario calificación de un proyecto informático f Evaluación global de la carga de trabajo necesaria para la realización del proyecto (estimación) y. el diseño. Las etapas tradicionales del ciclo de vida de construcción de software son: el estudio de oportunidad. encadenamiento e interrelación de las etapas del proceso de construcción de software (procedimiento) que define la arquitectura del método de trabajo. el seguimiento y la evaluación de un sistema de información particular denominado proyecto. calificación (estimación y planificación). 8. la seguridad de un buen funcionamiento en todos los casos posibles. la programación. las pruebas y el mantenimiento. Una metodología de software se compone del procedimiento que recomienda (el ciclo de vida). porque en la mayoría de las instalaciones con diferentes aplicaciones en funcionamiento la tarea del mantenimiento llega a ocupar más de las dos terceras partes de los recursos de análisis y programación disponibles. si es posible. además. Sí. siempre quedará la incertidumbre de saber qué necesitan realmente los usuarios y el ritmo de cambio que impone la realidad de cada día. ciclo de vida m Descomposición. orientados a obtener software que sea fiable y que funcione eficientemente en máquinas reales de una manera económica. ingeniería del software f Intento de establecer el uso de principios de ingeniería robustos. 6. porque se intenta construir software de gestión con procedimientos establecidos de ingeniería de software. la puesta en funcionamiento. que este software esté disponible en un plazo fijado y que se ajuste a un presupuesto. 7. según los recursos disponibles. 5. facturarlo por separado (a un cliente externo o en el seno de la contabilidad de costes interna de una misma empresa). 4. la documentación técnica detallada –que haría más fácil el mantenimiento–. 3. 10. etc. . como mínimo hasta que los profesionales técnicos que intervienen en el proyecto dominen la nueva tecnología.

Nueva York: Dorset House.ª ed. M. Third wave project management: A handbook for managing the complex information systems for the 1990s. Englewood Cliffs: Prentice Hall. Pressman.ª ed. es difícil saber cuáles son las funcionalidades que se deben implementar. A. Cervera. L. J. Sarson. Calvo-Manzano. B. Viñallonga. Marco.. J. B. Madrid: McGraw-Hill. de manera que si el jefe de proyecto no reacciona a tiempo. (1981).L. T.). Thomset. M. (1993). Gestió dels sistemes d’informació a l’empresa. Whitten... Piattini. . C. (1990). Bibliografía Boehm. T. Grupp..A. R. I. Ros. Page-Jones. Computer-aided software engineering: The methodologies. Barcelona: Edicions UPC. Barlow.. La gestión del departamento de informática. J. (1998). Reading: Addison-Wesley. L. Análisis y diseño detallado de aplicaciones de gestión. (1996). R. Practical project management: Restoring quality to DP projects and systems. J. Bentley. (1995). Gane. Barcelona: Hispano Europea SA. Controlling software projects. ya que continuamente surgen nuevas necesidades. efectuar modificaciones (mantenimiento adaptativo) y añadir mejoras (mantenimiento perfectivo). metodología de construcción de software f Conjunto de métodos. Software engineering (5.).S. requisito creciente m Fenómeno muy habitual en los proyectos de la informática de gestión que provoca la evolución y el crecimiento de los requisitos del proyecto informático. (1985). Ingeniería del software: un enfoque práctico (4. Systems analysis & design methods (3. de (1982). Software engineering economics. Madrid: Ra-ma. V. Englewood Cliffs: Prentice Hall.D.ª ed. Englewood Cliffs: Prentice Hall. (1996). Burr Ridge: Irwin.© FUOC • P03/75069/02141 51 El proyecto informático de construcción de software mantenimiento m Etapa de explotación de la vida de una aplicación que es la más larga y costosa.). Sommerville. (1994). the product and the future. Englewood Cliffs: Prentice Hall. técnicas e incluso herramientas utilizadas precisamente en el proceso de construcción de software. En esta fase debe procederse a corregir errores (mantenimiento correctivo).. (1985).W. seguir y controlar la producción de nuevo software. proyecto informático de construcción de software m Actividad consistente en planificar. riesgo de un proyecto informático m Posibilidad de que no se alcancen los objetivos deseados. Fernández.M.