TN51WR4HLVHTWDZD94AZ

El proyecto informtico de construccin de software
Miquel Barcel Garca

P03/75069/02141
FUOC P03/75069/02141
FUOC P03/75069/02141
ndice
Introduccin .............................................................................................. 5 Objetivos ..................................................................................................... 7 1. El proyecto informtico .................................................................... 9 1.1. Objetivos ........................................................................................... 11 1.2. Etapas ................................................................................................ 12 1.3. Caractersticas ................................................................................... 13 1.4. Recursos ............................................................................................ 14 1.5. Funciones de la direccin ................................................................. 15 1.6. La documentacin de la gestin ....................................................... 16 1.7. La dinmica ...................................................................................... 18 1.8. El ciclo de vida .................................................................................. 19 1.9. Los costes reales ................................................................................ 21 1.10.Causas posibles de fracaso ............................................................... 22 2. La construccin del software ............................................................ 25 2.1. Productividad en la construccin del hardware y el software ........... 26 2.1.1. La productividad en la construccin del hardware ............... 26 2.1.2. La productividad en la construccin 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 informticas ............................................ 28 2.1.5. La mayor complejidad del software nuevo ............................ 28 2.2. Introduccin a la ingeniera del software .......................................... 29 2.2.1. Especificidad en la construccin de software de aplicacin .......................................................................... 31 2.2.2. Objetivos generales ............................................................... 32 2.2.3. Componentes ........................................................................ 33 2.2.4. Distribucin de costes en la construccin del software ......... 34 2.2.5. Origen e importancia de los errores en el software ............... 35 2.3. Metodologas de construccin del software ...................................... 36 2.3.1. Precisin terminolgica previa ............................................. 37 2.3.2. Metodologas explcitas y metodologas implcitas .............. 38 2.3.3. Componentes ........................................................................ 39 2.3.4. Ciclo de vida y procedimiento .............................................. 42 2.3.5. Caractersticas generales y supuestos implcitos ................... 43 Resumen ...................................................................................................... 46 Actividades ................................................................................................. 49
FUOC P03/75069/02141
Ejercicios de autoevaluacin ................................................................. 49 Solucionario ............................................................................................... 50 Glosario ....................................................................................................... 50 Bibliografa ................................................................................................ 51
FUOC P03/75069/02141
Introduccin
De una manera tal vez insospechada para muchos, los proyectos informticos presentan unas particularidades que obligan a darles un tratamiento especializado, hecho que, en cierto modo, los diferencia de otros proyectos del mbito de la ingeniera. A menudo, los directores y responsables de una empresa constatan que los proyectos informticos los de desarrollo de un nuevo software son un caso paradigmtico difcilmente 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 informticos se planifican de manera que despus es francamente difcil, por no decir imposible, conseguir los objetivos previstos. Y, a pesar de todo, prcticamente no existen diferencias entre lo que se debe realizar para llevar a cabo de forma satisfactoria un proyecto informtico 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 informtico y en conocer con suficiente antelacin su alcance y complejidad. Por todo ello, en este mdulo didctico exponemos la problemtica general de los proyectos informticos y de sus caractersticas y etapas, sin olvidar las dificultades que suelen acompaarlos. Dejamos para otro mdulo didctico la explicacin detallada de las complejidades de la estimacin correcta de cargas y de la planificacin de proyectos informticos a partir de las diferentes mtricas disponibles. Cabe advertir, ya de entrada, que tal como corresponde a una asignatura de Informtica de gestin, la visin que damos de los proyectos informticos se limita a los aspectos de conduccin, supervisin y realizacin. No entraremos en detalles acerca del contenido tcnico del proyecto informtico de construccin de software de aplicaciones, ya que es un tema propio de la ingeniera del software que se trata con detalle en otras asignaturas. Como el mismo texto del mdulo indica, existe una gran variedad de proyectos informticos: de adquisicin de hardware, de adquisicin de software (de aplicacin, de sistema, etc.), de contratacin y control de desarrollo externo de aplicaciones, de contratacin y seguimiento de servicios de consultora y un largo etctera. A pesar de todo, nos centramos en los ms caractersticos de la actividad profesional informtica actual: los proyectos de construccin de software de aplicaciones que, adems de ser los ms haPodis ver la estimacin de cargas de los proyectos informticos y las mtricas disponibles en el mdulo Estimacin de costes de un proyecto informtico de esta asignatura.
FUOC P03/75069/02141
bituales, son aqullos en los que es ms evidente la especificidad de los proyectos informticos. Comenzaremos definiendo el trmino proyecto informtico, sus objetivos, las etapas que lo forman, sus caractersticas principales as como los requisitos que impone una visin orientada a la gestin. Una vez situado el tema central que nos ocupa, los proyectos informticos, conviene llevar a cabo un rpido repaso de la problemtica especfica de la construccin de software de aplicaciones en el mbito de la informtica de gestin. Por ello, incluimos un breve comentario sobre las metodologas de anlisis y programacin y la problemtica de la ingeniera del software, vista, sobre todo, desde la ptica de la productividad, que es la que ms nos interesa.
FUOC P03/75069/02141
Objetivos
En los materiales didcticos relacionados con este mdulo, el estudiante encontrar las herramientas necesarias para alcanzar los siguientes objetivos: 1. Conocer qu es un proyecto informtico, sus caractersticas principales y las etapas por las que pasa, siempre desde la ptica de la gestin. 2. Comprender la dificultad asociada a los proyectos informticos de construccin de software de aplicaciones, que a menudo se inician sin saber del todo el objetivo, el cual no se determina hasta que no se ha realizado un anlisis y se han establecido los requisitos y las especificaciones definitivas. 3. Conocer las funciones del jefe de un proyecto informtico y saber en qu consiste la documentacin. sta no debe reflejar los aspectos tcnicos de la aplicacin que se quiere elaborar, sino la gestin del proyecto de construccin. 4. Saber definir y caracterizar el enfoque que corresponde a la ingeniera del software, sobre todo con relacin a los proyectos informticos. 5. Analizar el concepto informtico de metodologa y exponer las principales caractersticas y los diferentes ciclos de vida.
FUOC P03/75069/02141
1. El proyecto informtico
Existen diferentes maneras de definir lo que es un proyecto informtico, sobre todo a causa de la multiplicidad de formas que presentan estos proyectos. Segn el Diccionario de uso del espaol de Mara Moliner, un proyecto es, entre otras acepciones, una idea que se tiene de algo que se piensa hacer y de cmo hacerlo. O, dicho de otra manera, un proyecto supone la voluntad de realizar o alcanzar algo y, como dice el diccionario, tambin es escrito, dibujo, etc., en que se expone una cosa que se piensa hacer o que se puede hacer. En el mbito de la informtica existen muchas actividades que se pueden llevar a cabo y, de hecho, se puede pensar en todo tipo de proyectos informticos: de adquisicin de un hardware nuevo; de adquisicin de software nuevo, bien sea de sistema (sistema operativo, sistema de gestin de base de datos, monitor de transacciones, herramientas de desarrollo, etc.), o bien de aplicacin; de construccin de un hardware nuevo; de construccin de un software nuevo; de mantenimiento de un software ya existente que se debe corregir, mejorar o modificar para adaptarlo a nuevas necesidades; de contratacin y control del desarrollo externo de nuevas aplicaciones; de contratacin y control de diferentes servicios proporcionados por terceros: mantenimiento, servicios de datos, servicios de comunicaciones, etc. Ahora bien, las diferencias de un proyecto informtico respecto de otros proyectos son ms evidentes en un caso concreto que, adems, es el ms habitual en la prctica profesional informtica. Por tanto, desde un punto de vista prctico, es interesante centrarnos en una modalidad concreta de proyectos informticos, como es la construccin directa de software nuevo.
Un proyecto informtico de construccin de software es la actividad que consiste en planificar, seguir y controlar la produccin de un software nuevo.
Generalmente, en el mbito de la actividad profesional informtica, tan aplicada a la gestin, el proyecto de construccin de software nuevo, de una nueva
FUOC P03/75069/02141
10
aplicacin, consiste en la elaboracin de la versin informatizada de un sistema de informacin, a veces ya existente y a veces nuevo, en la organizacin o en la empresa. Dicho esto, y teniendo en cuenta la perspectiva de los sistemas de informacin, conviene introducir una nueva definicin del trmino proyecto informtico adecuada al mbito de la gestin propio de esta asignatura.
Un proyecto informtico es un sistema de informacin que nos ayuda a tomar decisiones en las actividades de construccin de software.
En esta definicin se recoge el hecho de que, para llevar a cabo una buena gestin de un proyecto informtico, adems del sistema de informacin que se construye como nueva aplicacin informtica, es necesario efectuar un metasistema de informacin. Lo que se quiere decir es que para gestionar de manera eficiente el proyecto de construir software nuevo tambin conviene elaborar un nuevo sistema de informacin especfico que haga referencia a tems como: trabajos que se deben realizar, recursos que conviene utilizar, plazos, presupuesto y, en definitiva, todo lo necesario para controlar una actividad econmica centrada en la informtica.
La gestin de un proyecto informtico es un proceso de direccin y control que se concentra en la concepcin, la puesta en funcionamiento, el seguimiento y la evaluacin de un sistema de informacin particular denominado proyecto. De hecho, la eficiencia en este tipo de gestin se mide en funcin 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 informtico.
El jefe de proyecto es la persona que coordina los diferentes aspectos del proyecto informtico y se responsabiliza de ello. En el caso de que un proyecto sea demasiado grande y/o importante, se da la posibilidad de subdividirlo en varios subproyectos supervisados por diferentes lderes de proyecto que, a su vez, son supervisados y coordinados por el jefe del mismo.
En resumen, un proyecto informtico se configura como un conjunto de actividades y tareas limitado en el tiempo y que tiene como finalidad obtener unos objetivos concretos, en unos plazos y con unos recursos determinados.
FUOC P03/75069/02141
11
1.1. Objetivos Para sintetizar los objetivos generales de cualquier proyecto informtico, a los objetivos propios de la aplicacin que se quiere desarrollar o mantener debe aadirse todo aquello que hace referencia a la gestin de las actividades que se han de llevar a cabo para terminar con xito el proyecto. En cualquier caso, se puede decir que los objetivos generales de la actividad de la gestin de un proyecto informtico son los siguientes: 1) Alcanzar unas funcionalidades determinadas que indiquen lo que se ha concretado que se debe realizar. 2) Respetar los plazos que se han establecido para conseguir las funcionalidades, los cuales sealan cundo se ha de terminar el proyecto informtico. 3) Respetar el presupuesto asignado al proyecto ajustndose a los costes predeterminados. Evidentemente, el hecho de obtener las funcionalidades que se desean con unos costes superiores a los previstos o con ms tiempo del que se haba calculado es la manera ms habitual de que un proyecto informtico termine en un fracaso declarado. Desgraciadamente, la mala prctica profesional provoca que en ocasiones parezca que se respetan los plazos y el presupuesto, pero en realidad se han acortado y reducido las funcionalidades que se deban implementar. Normalmente las funcionalidades suprimidas no son las ms aparentes, sino las que tienen que ver con la calidad intrnseca del software*, hecho que ha generado preocupaciones serias y fundamentadas en relacin con lo que se denomina calidad, tanto del software como del proceso de creacin y mantenimiento. Por tanto, en todo proyecto informtico existe siempre el riesgo de no conseguir los objetivos deseados. En general, se considera que el hecho de no poder cumplir la previsin porque fallen las funcionalidades, los plazos o el presupuesto depende de varios factores como los que mencionamos a continuacin: 1) El tamao y la duracin: en los grandes proyectos existen ms posibilidades de errores y de fracaso. 2) La tecnologa: si el equipo de trabajo conoce bien la tecnologa que se debe utilizar*, el riesgo disminuye y, obviamente, si se utiliza tecnologa nueva y poco probada, el riesgo de no cumplir los objetivos aumenta. 3) La calidad y la estabilidad de las especificaciones reduce el riesgo de un proyecto informtico, a pesar de que, concretamente en el mbito de la informtica
* Es decir, facilidad de mantenimiento, buena documentacin, funcionamiento sin errores, etc.
Objetivos del proyecto informtico Los objetivos que definen cualquier proyecto informtico son: las funcionalidades, los plazos, el presupuesto.
* Como metodologas de anlisis y programacin; lenguajes de especificacin; herramientas que deben utilizarse; etc.
FUOC P03/75069/02141
12
de gestin, los requisitos de adaptacin a la realidad y la complejidad del trato con los futuros usuarios de la aplicacin que debe desarrollarse en el proyecto provoca que nunca se pueda estar seguro de la estabilidad de las especificaciones, hecho que introduce incertidumbre y riesgo en los proyectos de este mbito.
1.2. Etapas La caracterstica ms importante de un proyecto informtico es que se trata de algo temporal, es decir, que no dispone indefinidamente de los recursos que se le asignan. Un proyecto informtico es una actividad viva en el sentido de que nace, se desarrolla y finalmente termina. El objetivo principal de la gestin de un proyecto informtico es, precisamente, dirigir el desarrollo del mismo para llevarlo a su fin y obtener las funcionalidades deseadas, en los plazos establecidos y con el presupuesto autorizado. La gestin de un proyecto debe permitirnos saber hacia dnde va (los objetivos), cmo se va (planificacin de recursos y actividades) y tambin nos debe informar en todo momento de dnde se encuentra el proyecto (seguimiento). Una faceta importante de esta gestin es la determinacin del cierre del proyecto, ya sea porque se han conseguido los objetivos, ya sea por una interrupcin brusca cuando el proyecto informtico est mal calificado. La gestin de un proyecto informtico puede verse como la secuencia (y tambin la interrelacin) de cuatro grandes etapas: 1) El inicio del proyecto, que establece los requisitos y los objetivos funcionales generales que se deben conseguir y, de hecho, da origen al proyecto y lo hace nacer. 2) La calificacin del proyecto, que permite realizar una evaluacin global de la carga de trabajo necesario para la realizacin del proyecto y, teniendo en cuenta los recursos disponibles, ayuda a repartir en el tiempo las diferentes actividades que se han de llevar a cabo. La calificacin incluye la estimacin del volumen de trabajo que se debe realizar y la planificacin en el tiempo de las diferentes actividades. 3) El desarrollo del proyecto o, ms exactamente, el seguimiento y control del desarrollo del proyecto, en el cual se renen datos de cmo se efecta el proyecto y se identifican las desviaciones entre la planificacin y la realidad (seguimiento) para poder tomar las medidas de correccin necesarias (control). 4) El cierre del proyecto, que indica la finalizacin definitiva del proyecto y permite efectuar un balance de la realizacin al mismo tiempo que libera los recursos que se le haban asignado.
Etapas de un proyecto informtico En la gestin de un proyecto informtico podemos distinguir las etapas siguientes: Inicio. Calificacin, que incluye estimacin y planificacin. Desarrollo, que implica seguimiento y control. Cierre.
FUOC P03/75069/02141
13
De hecho, la segunda y la tercera etapa interaccionan de manera inevitable y a menudo forman un bucle o ciclo. Como veremos ms adelante, la calificacin de un proyecto informtico es uno de los aspectos ms problemticos y que genera ms errores. Por ello, es muy usual que, a lo largo del desarrollo del proyecto, se constaten diferencias entre lo que se realiza y lo que se haba previsto en la calificacin (la estimacin del trabajo que se debe efectuar y la planificacin temporal de actividades). Por este motivo, a menudo conviene repetir la etapa de calificacin. As, se pueden utilizar las nuevas informaciones de las que se dispone durante el desarrollo del proyecto informtico. Conviene destacar tambin la dificultad asociada a una buena finalizacin del proyecto. El hecho de que la primera calificacin (estimacin y planificacin) sea muy precaria, provoca que difcilmente se alcancen los objetivos iniciales de un proyecto informtico. Por este motivo, cerrar un proyecto informtico de construccin de software no es una tarea fcil, ya que no siempre todos los objetivos se pueden considerar cumplidos. Adems, como a menudo este tipo de proyectos se realiza para unos determinados clientes o futuros usuarios de la aplicacin que se desarrolla, es normal que los usuarios intenten alargar tanto como puedan la presencia y la colaboracin de los especialistas informticos que llevan a cabo el proyecto y que, en la prctica, dificulten la finalizacin. Por otra parte, en el caso concreto de la informtica de gestin, el problema de la poca estabilidad de los requisitos y las especificaciones de la aplicacin que se quiere desarrollar puede llevar a lo que se denomina fenmeno de los requisitos crecientes, el cual provoca la evolucin de los requisitos de manera que, si el jefe de proyecto no reacciona a tiempo, es difcil saber cules son las funcionalidades que se han de implementar, ya que continuamente surgen nuevas necesidades. Un proyecto consta siempre de actividades finales, que se suelen agrupar en fases o grupos de actividades. Es responsabilidad del jefe de proyecto informtico proceder a establecer las fases y las agrupaciones durante la etapa de calificacin del proyecto.
Podis ver la importancia de los errores en la etapa de calificacin en el subapartado 2.2.5 de este mdulo didctico.
1.3. Caractersticas Por norma general, cualquier proyecto informtico est marcado por un conjunto de caractersticas que, en cierta manera, lo diferencian de otros tipos de
FUOC P03/75069/02141
14
proyectos. Los proyectos informticos presentan siempre las siguientes caractersticas: 1) Concrecin. Un proyecto informtico se lleva a cabo para resolver un problema perfectamente identificado y, por tanto, tiene un objetivo definido, concreto y tangible. No es una actividad genrica cuyo final se desconoce a priori, como en ocasiones ocurre en las actividades de bsqueda. 2) Excepcionalidad. Cualquier proyecto informtico es excepcional en el sentido de que es nico y diferente de otros proyectos anteriores o futuros. En todo caso, se trata siempre de un conjunto de actividades que se efectan de manera excepcional para responder a una necesidad puntual en el tiempo. La analoga con otros proyectos slo es un recurso aproximativo, ya que, generalmente, en cada proyecto informtico se persiguen unos objetivos diferentes, intervienen varias personas y se utiliza tecnologa diversa. 3) Duracin limitada. Tal como ya hemos visto, cualquier proyecto informtico tiene una duracin limitada en el tiempo; es decir, un da se inicia y otro da se ha de finalizar. Los recursos que se le asignan son para un periodo de tiempo limitado y, en ocasiones, las mismas funcionalidades que se persiguen tienen una caducidad bien definida en el tiempo, sobre todo si pensamos en proyectos del mbito de la informtica de gestin. 4) Flexibilidad. Normalmente, un proyecto informtico requiere la movilizacin rpida de los recursos asignados. Adems, la dificultad que conlleva realizar una primera calificacin correcta del proyecto ocasiona que, de vez en cuando, a lo largo del desarrollo del proyecto, sea necesario reasignar estos mismos recursos de manera dinmica para responder a las necesidades de las estimaciones y planificaciones sucesivas posteriores al inicio del proyecto.
Caractersticas de los proyectos informticos Cualquier proyecto informtico presenta las siguientes caractersticas: Concrecin. Excepcionalidad. Duracin limitada. Flexibilidad.
1.4. Recursos Un proyecto informtico moviliza diferentes recursos, de los cuales se debe conocer las caractersticas. Adems, una vez realizadas la estimacin y la planificacin del proyecto, conviene saber tambin qu necesidades concretas y puntuales se darn de estos recursos. El jefe de proyecto es el responsable final de que se utilicen correcta y eficientemente. En el caso concreto de proyectos de desarrollo de software, intervienen una gran cantidad de recursos como, por ejemplo, los siguientes: 1) El hardware de las mquinas objetivo, en el cual se ha de ejecutar finalmente la aplicacin que se desarrolla. 2) El hardware de las mquinas de desarrollo y pruebas, en el cual trabaja el equipo tcnico que lleva a cabo el proyecto de construccin de software de aplicacin.
FUOC P03/75069/02141
15
3) El software de las diferentes herramientas de apoyo, ya sean orientadas al cdigo*, ya sean orientadas al mtodo**.
* Como sistemas operativos, sistemas de gestin de bases de datos, editores, compiladores, etc. ** Como herramientas CASE.
4) Los recursos humanos, de los cuales se debe conocer las aptitudes* y las actitudes**.
* Experiencia, conocimientos, habilidad, etc. ** Grado de disponibilidad, estabilidad, espritu de colaboracin, etc.
En la prctica, el jefe de proyecto es quien debe garantizar la disponibilidad de cada uno de los recursos segn se establece en la planificacin del proyecto informtico en los diferentes procesos de calificacin. Sin embargo, la generalizacin reciente de la informtica y el fenmeno del redimensionamiento a la baja de los sistemas* provoca que los recursos de software y hardware cada vez sean ms accesibles. En cambio, no se puede decir lo mismo del coste de los recursos humanos que se destinan a los proyectos informticos (analistas, programadores, especialistas de todo tipo, etc.). Por ello, de ahora en adelante nos centraremos de manera casi exclusiva en el coste de los recursos humanos. Conviene tener en cuenta que esto es una simplificacin y que nunca exime al jefe de proyecto de su responsabilidad de garantizar la disponibilidad de todo tipo de recursos necesarios para el proyecto.
* En ingls, downsizing o rightsizing.
El coste de los recursos humanos de un proyecto informtico se analiza con detalle en el mdulo Estimacin de costes de un proyecto informtico de esta asignatura.
1.5. Funciones de la direccin Las responsabilidades de un jefe de proyecto informtico son numerosas y variadas: calificar (estimar y planificar) el proyecto, asignar las actividades a las personas ms adecuadas, recoger los datos que permitan llevar a cabo un buen seguimiento del proyecto e, incluso, a partir de estos datos, volver a calificar el proyecto y, si es necesario, asignarle de nuevo los recursos o proponer la finalizacin anticipada. En general, se puede decir que el jefe de proyecto tiene como misiones principales las que comentamos a continuacin: 1) Asegurarse de que el proyecto est bien definido. 2) Establecer las diferentes fases y etapas, estimar el coste en esfuerzo y recursos y realizar la planificacin de las actividades. 3) Garantizar la disponibilidad de los recursos (humanos, tcnicos o financieros). 4) Establecer los procedimientos estndar de comunicacin interna del proyecto para permitir la recogida de datos, la validacin y las actividades de control y decisin.
FUOC P03/75069/02141
16
5) Distribuir el trabajo entre los miembros del equipo. 6) Asegurarse de que el personal tiene la cualificacin necesaria para llevar a cabo el proyecto, tanto la tcnica* como la administrativa**, y en caso de que no haya cualificacin, planificar tambin las actividades especficas necesarias de formacin. 7) Controlar el desarrollo del proyecto y avisar con tiempo de los problemas que se puedan presentar y que exijan decisiones importantes en relacin con la continuacin del mismo. 8) Cerrar cada una de las actividades, fases y, en definitiva, el proyecto informtico, una vez alcanzados los objetivos asignados o decidida la interrupcin definitiva.
* Conviene conocer las herramientas informticas que se deben utilizar. ** Es necesario estar al da de los procedimientos y estndares de documentacin.
En particular, el jefe de proyecto debe preocuparse de los aspectos ms dinmicos del proyecto informtico y, en concreto, ha de ser capaz de: Redefinir los objetivos de cada fase en las calificaciones sucesivas del proyecto. Evaluar alternativas analizando los riesgos y los costes relacionados con cada nueva opcin tomada en consideracin. Elegir soluciones a los problemas planteados y volver a calificar el proyecto en funcin de estas soluciones.
1.6. La documentacin de la gestin Concebido como un sistema de informacin que nos ayuda a tomar decisiones en las actividades de construccin de software, un proyecto informtico supone necesidades paralelas de documentacin que no se agotan con la documentacin tcnica de la aplicacin que se debe desarrollar. Conviene mencionar que, en la prctica, de la misma manera que no se suele aportar la documentacin tcnica de la que hablamos en los libros, manuales y cursos de ingeniera de software, todava se tiene menos en cuenta la necesidad de documentar de forma explcita y especfica la actividad de gestin de un proyecto informtico. Como siempre, existen excepciones, a menudo en las grandes instalaciones y/o proyectos, pero en realidad, lo que en la prctica profesional se documenta de la gestin de un proyecto informtico es siempre mucho menor de lo que es necesario. A pesar de todo, si los aspectos de gestin de un proyecto informtico estuvieran bien documentados, la dificultad de abordar nuevos proyectos se reducira. Es cierto que todo proyecto es concreto y nico, pero disponer de datos reales de otros proyectos llevados a cabo en una determinada instalacin, casi
FUOC P03/75069/02141
17
siempre con aplicaciones, tecnologa y recursos humanos del mismo tipo, debera ser una ayuda considerable en la califiacin de nuevos proyectos y, en concreto, en la estimacin de cargas, que siempre es muy precaria. En cualquier caso, si vivisemos en un mundo perfecto, sera evidente el inters por documentar suficientemente las actividades de gestin de un proyecto informtico. Por tanto, desde que un proyecto se inicia debe abrirse un expediente al servicio del jefe de proyecto que recoja toda la documentacin necesaria que se utiliza para recopilar los datos de las actividades de gestin del proyecto. Este expediente incluye dos partes: una de archivo, de los datos que hacen referencia a las actividades del proyecto ya cerradas, y otra activa, que es la que el jefe de proyecto actualiza da a da. De manera global, un buen expediente de proyecto debera contener los documentos siguientes: 1) La definicin general del proyecto con los objetivos, los lmites, la determinacin de lo que se ha de llevar a cabo y de cmo debe realizarse y las posibles restricciones. 2) La estructura del proyecto, es decir, la descomposicin en fases y actividades y la organizacin interna. 3) Las evaluaciones iniciales desde el punto de vista de los riesgos y los costes, as como tambin las estimaciones iniciales de carga de trabajo que conlleva el proyecto. 4) La planificacin temporal de las actividades del proyecto o, mejor an, las diferentes planificaciones: La inicial, es decir, la de la primera calificacin del proyecto (planificacin de referencia). La planificacin vigente en cada momento (planificacin actual), tanto en lo referente al calendario como a los recursos y costes. 5) El seguimiento, a menudo semanal, de las actividades en curso. Se suele realizar, como veremos, con unas hojas de trabajo en las que se indican las actividades, su grado de desarrollo y tambin las diferentes incidencias que se hayan podido presentar. 6) Lo que podramos denominar diario de a bordo del proyecto, en el cual se anota lo que ocurre y se informa, da tras da, de las incidencias y de la situacin del proyecto. 7) La correspondencia (correo electrnico incluido) y las notas, y tambin los informes externos de quien ha encargado el trabajo que el jefe de proyecto entrega al eventual comit de seguimiento del proyecto.
FUOC P03/75069/02141
18
Como ya avanzbamos, este conjunto de informaciones compone un verdadero expediente de la gestin de un proyecto informtico y tiene una importancia fundamental. Un expediente como ste es til, sobre todo, como una ayuda a la realizacin y, especialmente, a la calificacin inicial de los proyectos informticos futuros.
1.7. La dinmica Un proyecto informtico no permanece fijo y esttico, sino que es algo vivo. No es una actividad que se pueda contemplar de manera lineal, sino que ms bien debemos imaginarla como una actividad en espiral. De hecho, cualquier estimacin de cargas, riesgos y costes es una conjetura y, por tanto, posiblemente, sea falsa. Las estimaciones y planificaciones deben revisarse y, cuando convenga, corregirse. Durante el desarrollo del proyecto, el seguimiento ha de permitir efectuar controles regulares y medir las desviaciones entre la realidad y aquello que se ha planificado anteriormente. Con estos datos debe reelaborarse tanto la estimacin (a partir de los datos reales de productividad que se alcanzan en cada momento con el equipo humano que interviene en el proyecto), como la planificacin (por los cambios en la estimacin del esfuerzo necesario y, tambin, por los posibles desajustes en la disponibilidad de los recursos). Sin embargo, si esta nocin de evolucin de la planificacin es importante, tambin debemos tener en cuenta que, en proyectos que duran unos cuantos meses, cambia incluso el mismo entorno en el que se desarrolla el proyecto informtico. Lo que pareca una verdad incuestionable al inicio del proyecto, puede dejar de serlo ms adelante. Las especificaciones, sobre todo en el caso de la informtica de gestin, pueden cambiar y ello, como hemos dicho, contribuye a aumentar el riesgo del proyecto en s. En definitiva, en la direccin de proyectos informticos debe pensarse en la necesidad de convivir con el cambio. La pregunta principal es cmo llevarlo a cabo. Para muchos especialistas, una de las condiciones esenciales para poder absorber todos estos cambios posibles sin demasiadas dificultades es descomponer el proyecto en diferentes fases. Cada fase constituye un tipo de subproyecto con un objetivo muy preciso, un paquete aislado (de manera natural o artificial) del resto y, si es posible, 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). As, si el proyecto terminara prematuramente*, el trabajo parcial efectuado se podra evaluar. Este planteamiento, imprescindible cuando el proyecto es grande, 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.
* Por ejemplo, como consecuencia de un cambio de objetivos.
FUOC P03/75069/02141
19
2) Evaluar las alternativas y analizar los riesgos inherentes a las diferentes posibilidades. 3) Elegir una solucin y planificar de nuevo en funcin de la eleccin realizada.
1.8. El ciclo de vida De manera general, todo proceso de construccin de software pasa por etapas, cuyo nombre, contenido y especificacin van variando a lo largo del tiempo de acuerdo con los diferentes mtodos utilizados. A menudo, las etapas por las que pasa la construccin de software se ven como un ciclo de vida completo, sobre todo si se une el inevitable mantenimiento de las aplicaciones y la retirada del software al final de su vida til. La denominacin de ciclo de vida sirve para marcar este carcter evolutivo y perecedero de cualquier aplicacin informtica. Las diferentes metodologas de la ingeniera de software parten de varios puntos de vista sobre el ciclo de vida de una aplicacin: ciclo de vida en cascada, con prototipos, en espiral, ciclo de vida en fuente para la orientacin a objetos, etc. No es ste el lugar adecuado para tratar con detalle estos puntos de vista, sino que corresponde a las asignaturas de ingeniera del software. Imaginaremos un proceso de desarrollo en el sistema clsico de un ciclo de vida en cascada, en el cual las diferentes etapas de la construccin del software se ven como una secuencia casi lineal, en la que una etapa debe finalizar antes de que se inicie la siguiente, como se observa en la figura:
Podis ver la descripcin de las etapas sucesivas segn el mtodo utilizado en el apartado 2 de este mdulo didctico.
FUOC P03/75069/02141
20
Esta convencin no se corresponde del todo con la realidad y a menudo debe volverse atrs para corregir pasos anteriores. En cualquier caso, las etapas por las que, desde este punto de vista, pasa el proceso de construccin de software son las que presentamos a continuacin: 1) El anteproyecto o estudio de oportunidad, al final del cual se toma la decisin de promover el proyecto informtico, teniendo en cuenta los requisitos ms generales establecidos normalmente en esta etapa. 2) El anlisis del sistema de informacin y la elaboracin posterior de las especificaciones, las funciones y los objetivos del sistema informtico que se quiere implementar. A menudo, la tradicin profesional ha etiquetado este primer anlisis con la denominacin anlisis funcional. 3) El diseo de una solucin tcnica concreta que satisfaga las especificaciones establecidas en la fase de anlisis. Hace aos, esta etapa se denominaba etapa de anlisis orgnico, pero esta denominacin parece que ha cado en desuso. 4) La implementacin final del sistema informtico, que se concreta en dos aspectos: a) La programacin, que puede ser de procedimientos nuevos codificados o puede reutilizar procedimientos provenientes de una librera de rutinas ya realizadas y probadas. b) La prueba imprescindible de todo ello, que debe permitir finalmente instalar el sistema de una manera definitiva para poder pasar as a la etapa de funcionamiento y explotacin real. 5) El mantenimiento de la aplicacin durante su vida til o explotacin, que ha de responder a las necesidades siguientes: Corregir los posibles errores a medida que se detectan. Mejorar las funcionalidades en la medida en que sea posible. Adaptar la aplicacin a los requisitos necesariamente cambiantes del entorno donde se ejecuta y es til. En la figura de la pgina siguiente se muestra la denominada curva del caracol, que indica de manera general los recursos que se emplean a lo largo del ciclo de vida de una aplicacin. Hemos marcado claramente el plazo de puesta en funcionamiento en el que se inicia la explotacin, que es en realidad el que
FUOC P03/75069/02141
21
consideramos que se encuentra bajo el control del proceso de gestin de un proyecto informtico para desarrollar una nueva aplicacin:
1.9. Los costes reales La figura anterior puede crear confusin, ya que puede parecer que el coste final total de un proyecto informtico de construccin de software de aplicacin slo incluye las actividades necesarias hasta llegar a la etapa de explotacin de la aplicacin que se quiere construir. A pesar de que lo que acabamos de exponer es el punto de vista ms habitual, cabe sealar que contiene un grave error, que tal vez explica la mala calidad de muchos proyectos informticos y del producto, el software, que construyen. Si reflexionamos acerca del hecho de que los costes de tener una aplicacin nueva en disposicin de ser operativa (en definitiva, los costes de un proyecto informtico) no incluyen el coste del mantenimiento, es evidente que todo lo que ayuda a tener un buen mantenimiento no se toma en consideracin a la hora de construir una aplicacin, sobre todo si se dan problemas en el cumplimiento de los objetivos del proyecto. Ahora bien, el mantenimiento es muy importante en la vida de una aplicacin. La figura de la pgina siguiente refleja con ms realismo la curva del caracol de reparto del esfuerzo a lo largo del tiempo.
FUOC P03/75069/02141
22
La importancia del mantenimiento En un caso normal, es posible pensar en una aplicacin en la que la etapa habitualmente asociada al proyecto informtico de construccin de software de aplicacin (el tiempo previo a la puesta en funcionamiento y a la entrada en explotacin) sea, pongamos por caso, de un ao o incluso menos. Y, normalmente, una vez en explotacin, es lgico pensar que la aplicacin que tantos esfuerzos ha costado se querr mantener en funcionamiento tanto tiempo como sea posible, pongamos unos diez aos.
Como se observa, a pesar de que se necesitan muchos recursos en la etapa previa a la puesta en funcionamiento de la aplicacin, la realidad es que los recursos empleados en el mantenimiento tampoco son negligibles: siempre existe necesidad de mantenimiento, ya sea correctivo, perfectivo o adaptativo, y ello durante el largo periodo en el que la aplicacin se encuentra en explotacin.
Podis ver los tipos de mantenimiento en el subapartado 2.1.4 de este mdulo didctico.
Por tanto, es muy posible que, si calculamos el coste real de construir y mantener en funcionamiento una aplicacin informtica, la parte que corresponda al mantenimiento sea la mayor de todas, pese a que, insistimos, este hecho nunca se tiene en cuenta cuando se decide si conviene o no iniciar un proyecto informtico para construir una nueva aplicacin.
El hecho de que no se tengan en cuenta los costes reales del mantenimiento en la vida completa de una aplicacin informtica permite entender que la mala prctica profesional puede provocar, en ocasiones, la apariencia de que se respetan los objetivos de un proyecto, cuando, en realidad, se eliminan funcionalidades poco aparentes que convierten en mucho ms problemtico y costoso el largo periodo de mantenimiento. A pesar de todo, como se lleva a cabo en todas partes, aunque hayamos hecho esta advertencia, aqu tambin consideraremos que los costes del proyecto informtico son los que se cuentan hasta que se llega a la situacin que denominamos puesta en funcionamiento, cuando en cierta manera se cierra el proyecto informtico y se entra en la etapa larga y compleja del mantenimiento.
Algunas funcionalidades poco aparentes... ... que se suelen no realizar para que parezca que se respetan los objetivos son, entre otras, una buena documentacin, un estudio de alternativas tcnicas posibles y la seguridad de las pruebas para garantizar un funcionamiento sin errores.
1.10.
Causas posibles de fracaso
Seguramente se pueden encontrar ms ejemplos de proyectos informticos que han terminado en fracaso que de proyectos en los que se han podido cum-
FUOC P03/75069/02141
23
plir todos los objetivos. La razn principal de este hecho es la dificultad de realizar una calificacin inicial correcta del proyecto informtico, a menudo por falta de datos. Sea como sea, entre los proyectos fracasados probablemente haya algunos que han fallado por dificultades de gestin, las cuales generalmente se pueden atribuir al jefe de proyecto o a determinadas caractersticas del mismo proyecto o aplicacin. Entre las causas de fracaso por razn de la gestin, la ms frecuente suele ser una falta de comunicacin, que se produce por varias razones: 1) Incapacidad del jefe de proyecto de delegar responsabilidades, es decir, ste no promueve la participacin de los miembros del equipo en las decisiones. 2) Falta de conocimientos de los objetivos, a menudo porque el estudio de oportunidad no se ha llevado a cabo de forma adecuada y correcta. 3) Un mal anlisis del problema, el cual conduce a una descomposicin del proyecto en actividades y tareas que no es eficiente o, tambin a una definicin incorrecta de los lmites del proyecto. 4) Una evaluacin errnea de las personas que forman el equipo tcnico del proyecto, tanto en lo que corresponde a sus conocimientos, competencia y formacin como en lo referente a su capacidad de cooperacin. 5) Falta de capacidad de decisin, que provoca que demasiadas cuestiones queden sin respuesta, hecho que obliga a menudo a trabajar sobre hiptesis provisionales que, cuando son incorrectas o falsas, retrasan y ponen en peligro todo el proyecto. Cabe mencionar que si la intervencin y la capacidad directiva del jefe de proyecto son muy importantes, no lo son menos la capacidad y la disponibilidad de todo el equipo tcnico que interviene en el proyecto informtico. 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. De hecho, el jefe de proyecto es el responsable de su equipo de trabajo. Como siempre que se trata de tareas intelectuales, se debe pensar en un factor imprescindible: la motivacin del personal que forma el equipo del proyecto. Un dato relevante es que, en el equipo de un proyecto informtico, a menudo habr especialistas ms cualificados que el jefe de proyecto, al menos en algunos aspectos tcnicos concretos de la actividad de desarrollo de software (conocimiento del sistema de base de datos, conocimiento y experiencia en los lenguajes de programacin, etc.). La capacidad de actuar como lder es bsica
Lectura complementaria Podis consultar la opinin de Barry Boehm respecto a las consecuencias de formar un mal equipo para un proyecto informtico en la obra siguiente: B.W. Boehm (1981). Software Engineering Economics. Englewood Cliffs: Prentice Hall.
FUOC P03/75069/02141
24
para un buen jefe de proyecto que, entre otras, tiene la responsabilidad de informar personalmente a cada miembro del equipo de los aspectos que presentamos a continuacin: La estructura del proyecto y el lugar que cada uno ocupa. El circuito de informaciones y el conjunto de procedimientos administrativos que se deben respetar. Los trabajos que corresponden a cada miembro. Los retrasos que se puedan producir. Los objetivos personales de cada uno en cada etapa del proyecto y los objetivos generales. Las dificultades previstas y las opciones de correccin que se deban efectuar. Del mismo modo, es necesario tomar en consideracin las otras causas de fracaso asociadas al riesgo mismo del proyecto, como ya hemos comentado al tratar el tamao del proyecto informtico: la familiarizacin con la tecnologa que debe utilizarse y la solidez de las especificaciones. La siguiente lista es otra manera de resumir estas posibles causas de fracaso: Una mala definicin de los objetivos. Unas responsabilidades que no estn bien determinadas, que sean demasiado difusas: lo que ocasiona que no sea posible determinar quin es realmente responsable de las actividades que se deben llevar a cabo. La falta de certeza sobre el momento de inicio del proyecto (y sobre la asignacin de recursos) o de inicio de cada actividad. Una deficiente determinacin de las prioridades internas entre las actividades del proyecto (y, en ocasiones, en relacin con las actividades externas al proyecto en las cuales puedan intervenir algunos miembros del equipo). Una incorrecta definicin de la finalizacin del proyecto o de las actividades y fases. En el primer caso, el proyecto contina indefinidamente cuando se confunde el proyecto informtico de construccin de una aplicacin con el trabajo de mantenimiento.
Podis ver las causas de fracaso asociadas al riesgo del proyecto en el subapartado 1.1 de este mdulo didctico.
FUOC P03/75069/02141
25
2. La construccin del software
Parece que fue en el ao 1968, durante la conferencia de la OTAN en Garmish (Alemania), cuando se utiliz por primera vez la expresin ingeniera del software. La razn por la que se introdujo este trmino fue la constatacin de lo difcil que era en s mismo el trabajo de construir un software nuevo que fuese seguro, fiable y de calidad. Entonces, se comenz a hablar de una presunta crisis del software para reflejar la gran cantidad de problemas que surgan en su diseo y construccin. En realidad, este punto de vista result muy optimista. La problemtica de construir software seguro, fiable y de calidad no pasaba por una crisis momentnea y temporal (que es lo que sugiere, en definitiva, la palabra crisis), sino que en aquel momento ya se comenzaba a detectar un problema central e intrnseco de los proyectos informticos de construccin de software: disear, construir y mantener software seguro, fiable y de calidad es una actividad siempre llena de dificultades. Por ello, muchos autores se plantean si el proceso de disear, construir y mantener software no pasa por una crisis momentnea, sino que atraviesa lo que se podra denominar una verdadera enfermedad crnica. Existen muchas razones que podran explicar esta enfermedad crnica, pero las principales son las siguientes: 1) La dificultad de determinar las especificaciones, a menudo altamente inciertas (particularmente en el mbito de la informtica de gestin), del sistema de informacin que se construye. 2) La tecnologa informtica, con un ritmo de cambio muy rpido, que convierte en difcil la utilizacin de la experiencia tcnica anterior porque rpidamente queda obsoleta. 3) La escasa consistencia y la volatilidad elevada de las necesidades expresadas por los futuros usuarios de los sistemas de informacin propios de la informtica de gestin. 4) El hecho de que los sistemas que se han de construir en la informtica de gestin deban ser al mismo tiempo de larga duracin (para amortizar la inversin realizada con el fin de obtenerlos) y modificables (para que se puedan adaptar al entorno siempre cambiante de la informtica de gestin).
FUOC P03/75069/02141
26
A pesar de que estas razones no son las nicas, es evidente que, ante esta compleja problemtica (que aqu, de momento, slo hemos esbozado), desde la conferencia de Garmish se quiso abordar el proceso de diseo, construccin y mantenimiento del software con la misma seriedad y los mismos modelos tpicos de cualquier otra actividad de ingeniera, hecho que ha dado lugar a la denominada ingeniera del software y a diferentes mtodos o metodologas* de diseo, construccin y mantenimiento del software.
* En el argot profesional informtico se habla de metodologas en lugar de utilizar el trmino mtodos.
2.1. Productividad en la construccin del hardware y el software En la gestin de proyectos informticos, lo que ms nos interesa es, precisamente, la productividad.
La productividad es la capacidad de obtener producto (en nuestro caso, software de aplicacin) que corresponde a cada unidad de los recursos utilizados para conseguirlo.
De hecho, en el campo de la informtica el aumento de la productividad muestra un ritmo muy diferente en la construccin de hardware y en la de software.
2.1.1. La productividad en la construccin del hardware Para todo el mundo es un hecho obvio el aumento casi increble de la potencia y la seguridad del hardware informtico. El que se considera el primer ordenador digital, el ENIAC, se desarroll en la Universidad de Pensilvania (EE.UU.) Eckert y Mauchly y fue presentado pblicamente el 15 de febrero de 1946. Pesaba 30 toneladas, ocupaba un piso entero de la Escuela de Ingeniera Elctrica Moore y tena unos 18.000 tubos de vaco que fallaban a una media de uno cada siete minutos.
Coches y ordenadores Estableciendo una comparacin entre la industria de la automocin y la del hardware informtico, podemos afirmar que si la primera hubiera seguido una evolucin similar a la del hardware, hoy podramos disponer, por menos de sesenta cntimos, de un Rolls Royce con la potencia de un transatlntico que sera capaz de dar veinticinco veces la vuelta al mundo solamente con un litro de gasolina.
Imagen de un microprocesador.
Actualmente, cuando han pasado poco ms de cincuenta aos desde la creacin del ENIAC, la misma potencia de clculo de aquella mquina se consigue y se supera con creces con un chip de tamao diminuto y de mucha ms fiabilidad tecnolgica. Sobre una mesa de despacho, hoy encontramos ordenadores personales infinitamente ms potentes y seguros que el ENIAC y al alcance de mucha gente. La productividad del hardware ha aumentado de manera espectacular, incluso insospechada si lo comparamos con el software.
Imagen del ENIAC, el primer ordenador digital.
FUOC P03/75069/02141
27
2.1.2. La productividad en la construccin del software Desgraciadamente, el ritmo de avance en la productividad del hardware informtico no tiene un equivalente en la construccin del software, tan imprescindible para el funcionamiento de los sistemas informticos. Diferentes autores, entre los cuales destaca Barry Boehm, han recogido datos sobre la productividad real en la construccin del software. Las cifras no son tan espectaculares como las del hardware, ms bien al contrario, son claramente preocupantes porque indican dnde radica el problema real de la actividad informtica. Boehm nos explica que, en un proyecto informtico de tamao medio (que de momento podemos establecer en torno a las 20.000 o 30.000 lneas de cdigo fuente), no se debe esperar que se alcancen ms de 10 lneas de cdigo fuente por da y persona ocupada en el proyecto, aunque la cifra de errores llegue a casi 30 por cada 1.000 lneas de cdigo fuente durante el proceso de desarrollo. Desgraciadamente, el nmero de errores por cada 1.000 lneas de cdigo se mantiene entre 8 y 12 incluso en los productos considerados ya definitivos. Adems, las actividades de mantenimiento de las aplicaciones informticas suponen, de media, el doble del coste que representa producirlas. A pesar de que las medidas en las que se basan estos datos se comprenden mejor cuando se conocen las diferentes mtricas del software y su significado ms profundo, cuestin que desarrollaremos en otro mdulo, lo cierto es que aqu nos ofrecen una primera idea de cmo, en la construccin de software, la productividad queda todava muy lejos de la que se ha alcanzado ya en el hardware.
Lectura complementaria Podis encontrar un conjunto de datos sobre la productividad en la construccin de software elaborado por Barry W. Boehm en la obra siguiente: B.W. Boehm (1981). Software Engineering Economics. Englewood Cliffs: Prentice Hall.
Podis ver las mtricas del software en el apartado 1 del mdulo Estimacin de costes de un proyecto informtico de esta asignatura.
2.1.3. Cambio en el reparto de los costes entre hardware y software
La realidad es que, con la evolucin de la informtica y el aumento creciente de la productividad y la fiabilidad del hardware, se ha producido una clara inversin de la tendencia que, originariamente, situaba la mayor parte del coste informtico en el hardware.
La figura de la pgina siguiente, elaborada a partir de los datos de Barry Boehm, muestra claramente la tendencia mencionada.
Es evidente que la razn principal de este cambio ha sido la generalizacin del hardware y su redimensionamiento a la baja, una muestra clara del aumento de la productividad que ha ido incorporando. Sin embargo, debemos tener en cuenta que tambin han influido mucho el estancamiento de la productividad en la construccin de aplicaciones informticas y el aumento del coste del personal informtico.
FUOC P03/75069/02141
28
Evolucin de los costes de software y hardware Durante los aos cincuenta y sesenta, el hardware representaba prcticamente el 80% del coste de un sistema informtico e incluso se poda llegar a invertir grandes esfuerzos de programacin para conseguir ahorrar espacios de memoria o tiempo de procesamiento en la unidad central del ordenador. A mediados de los sesenta, con el inicio de los grandes proyectos de construccin de software (de sistema o de aplicacin), los costes de ste empezaron a acercarse al 50% del total, como muestra el hecho de que los grandes constructores y proveedores informticos facturasen por separado el hardware y el software, costumbre que se generaliz en la dcada de los setenta. En los aos ochenta, las cifras iniciales ya se haban invertido y dejaban el hardware incluso en menos del 20% del coste global de los sistemas informticos.
2.1.4. La importancia del mantenimiento de las aplicaciones informticas Paralelamente a la inversin de la proporcin de los costes informticos de hardware y software, se ha acentuado el peso del mantenimiento de las aplicaciones informticas. Como decamos anteriormente, la responsabilidad del desarrollo del software no termina cuando el producto se instala y entra en explotacin. Mientras sirven y son tiles, los sistemas de informacin se deben mantener no slo para corregir errores, sino tambin para atender a las modificaciones, adaptaciones y mejoras necesarias de las aplicaciones informticas con el fin de ajustarlas al entorno cambiante de nuestra sociedad.
Podis ver el subapartado 1.9 de este mdulo didctico.
Corregir errores (mantenimiento correctivo), realizar modificaciones (mantenimiento adaptativo) y aadir mejoras (mantenimiento perfectivo) constituyen la actividad conocida como mantenimiento de las aplicaciones informticas, en la cual se invierten ms de dos terceras partes de la capacidad de trabajo de analistas, programadores y otros especialistas informticos.
2.1.5. La mayor complejidad del software nuevo Los avances de las ltimas dcadas han permitido, y al mismo tiempo exigido, el desarrollo de nuevas aplicaciones informticas ms grandes y tambin ms complejas. De los primeros sistemas monousuario de tratamiento por lotes* tpicos de los aos 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 caractersticos de los aos setenta. La tendencia a la distribucin y el nacimiento de nuevas exigencias en las comunicaciones informticas se incre* En ingls, batch.
FUOC P03/75069/02141
29
ment con la extensin de las redes de ordenadores y los nuevos sistemas distribuidos con cooperacin de procesos y bases de datos tambin distribuidas. Por otro lado, no debemos olvidar las nuevas necesidades y los requisitos del hardware y del software para gestionar las interfaces usuario/ordenador modernas, dotadas de sistemas de representacin grfica, ventanas, nuevos dispositivos sealizadores* y todo el mundo de Internet. A pesar de estos cambios en el producto, es triste constatar que la prctica profesional de la construccin de software de aplicacin no ha evolucionado como se esperaba. El proceso de construccin de software todava es demasiado parecido al bricolaje. An se utilizan pocos recursos de productividad como las herramientas CASE*, y los datos de productividad de software no han cambiado demasiado de los que eran habituales en los aos setenta y ochenta.
* CASE es la sigla del trmino ingls Computer Assisted Software Engineering. * Como el ratn, el lpiz ptico, las pantallas que se activan con los dedos, etc.
2.2. Introduccin a la ingeniera del software La expresin ingeniera del software se utiliz por primera vez en 1968 como un tema de un congreso organizado por la divisin de asuntos cientficos de la OTAN. All se lleg a la conclusin de que era necesaria una nueva disciplina cientfica con una gran orientacin prctica que superara las limitaciones que la informtica* haba encontrado en la creacin de productos de software grandes y complejos.
* En ingls, computer science.
Entonces ya surgi la idea de aplicar tcnicas tpicas de la ingeniera a la construccin de software con el fin de incrementar, al mismo tiempo, la productividad del proceso de desarrollo y la calidad del producto obtenido en la construccin de software, sin olvidar la necesidad ineludible de hacer ms fcil el proceso necesario de mantenimiento.
En 1969, en otro congreso sobre el tema, la ingeniera del software era definida por Fritz Bauer como el establecimiento y el uso de principios de ingeniera robustos orientados a obtener de forma econmica software fiable y que funcionara eficientemente en mquinas reales.
La definicin de Bauer puede que sea la que mejor marca los objetivos que entonces persegua (y an persigue) la ingeniera del software, que acababa de nacer.
Con el tiempo se han propuesto otras definiciones, como la de Mills en 1980, que consideraba la ingeniera de software como un conjunto de disciplinas y procedimientos para la construccin y el mantenimiento de software viable y econmico.
FUOC P03/75069/02141
30
Conviene precisar que las definiciones de Bauer y Mills coinciden en provocar la intervencin, posiblemente por primera vez, del aspecto econmico en una reflexin tecnocientfica sobre la produccin del software que, hasta entonces, haba sido objeto de la informtica, una disciplina demasiado terica y poco preocupada por los aspectos pragmticos. Es necesario constatar que la principal obra para el estudio de los proyectos informticos y de su faceta econmica tiene precisamente el ttulo Software engineering economics (La economa de la ingeniera del software), de Barry Boehm, publicado en 1981.
Esta consideracin de la economa es tal vez el aspecto central de lo que muchos ya denominan la orientacin proyecto en la actividad de construir software. Se trata de obtener unas funcionalidades en un determinado plazo y respetando un presupuesto econmico.
En el mencionado libro, Barry Boehm, despus de analizar los conceptos de software e ingeniera, define la ingeniera del software parafraseando la definicin de ingeniera del diccionario Webster, pero aplicndola concretamente al aprovechamiento del equipo informtico y al caso particular de los ordenadores: la aplicacin de la ciencia y las matemticas mediante la cual las capacidades de los ordenadores se hacen tiles a los humanos a travs de los programas de ordenador, los procedimientos y la documentacin que los acompaa. Conviene destacar que la definicin de Boehm no se refiere slo a los programas de ordenador, como era habitual, sino tambin a los procedimientos que se utilizan para obtener estos programas y un hecho fundamental para el mantenimiento a la documentacin que los acompaa.
Lectura complementaria Podis encontrar la cita mencionada en la obra siguiente: IEEE (1983). Standard Glossary of Software Engineering Terminology. Nueva York: Institut of Electrical and Electronic Engineers.
Encontramos un resumen adecuado del alcance de la ingeniera del software en la concisa definicin de una famossima asociacin de profesionales, el IEEE: la ingeniera del software es una perspectiva sistemtica del desarrollo, la operacin, el mantenimiento y la retirada del software.
Un rasgo significativo de esta definicin de ingeniera del software es que, junto con otras fases ms ampliamente reconocidas*, cita una fase de retirada o de sustitucin del software. ste es un punto de vista que refuerza la idea del ciclo de vida del software y de su caducidad. En todos los casos, la ingeniera del software se presenta como un enfoque sistemtico y profesional orientado a producir un software que proporcione sus funcionalidades con la mejor calidad, al coste ms bajo posible (econmicamente) y
* Como desarrollo, utilizacin y mantenimiento.
FUOC P03/75069/02141
31
cumpliendo los plazos de tiempo establecidos. La calidad de este software se debe entender en el sentido de que, adems de ser til para los usuarios, ha de ser eficiente en el uso y en el aprovechamiento del hardware y no ha de incorporar errores; por ltimo, tambin conviene que tenga un mantenimiento fcil.
2.2.1. Especificidad en la construccin de software de aplicacin Evidentemente, el incremento de los costes de software informtico y, principalmente, los de su mantenimiento justifican la necesidad de un enfoque sistemtico y profesional en la construccin de aplicaciones y sistemas informticos. Pero, adems, existen razones especficas ligadas intrnsecamente al proceso de desarrollo y mantenimiento del software. De hecho, los proyectos informticos de construccin de software de aplicacin presentan unas caractersticas diferenciales que, como hemos dicho, impiden gestionarlos exactamente con los mismos mtodos y tcnicas con los que se gestionan otros proyectos de ingeniera. Una de las diferencias ms significativas consiste en el hecho de que, en los proyectos informticos, el diseo y la construccin del sistema son un nico proceso y no existe una fase de diseo totalmente previa a la construccin o fabricacin.
En realidad, la construccin de software es un mero proceso de diseo, pero el hecho de que, al terminar, este diseo tome la forma de una especificacin final en un lenguaje ejecutable para ordenador provoca que el diseo mencionado se asimile a un proceso completo que incluye tambin la fabricacin, de manera que el proceso de produccin y la comprobacin final de la calidad del proceso y del producto son francamente complejos y problemticos.
En otros campos de la ingeniera, se da en primer lugar una etapa de diseo que genera las especificaciones finales de lo que despus probablemente llegar a la fase de produccin.
La etapa de diseo en un proceso clsico de construccin de un producto En la fabricacin de un automvil nuevo, primero se realiza el diseo e, incluso, se efecta un determinado nmero de prototipos de pruebas, antes de tomar la decisin final de producir las cadenas de fabricacin donde se construye el nuevo modelo. No es necesario mencionar que es precisamente en esta segunda parte (la instalacin de las cadenas de produccin) donde se invierte la mayor parte de los recursos del proyecto de fabricacin. Si se dispusiera...
En el caso de la construccin de software de aplicacin, a pesar de que existe una fase de especificacin o de diseo previa a la programacin, es obvio que con un buen lenguaje de especificacin y/o diseo que fuera directamente ejecutable en el ordenador no sera necesario acometer las fases de programacin y de prueba tradicionales. Pero, desgraciadamente, la efectividad real de este
... de un procesador de lenguaje que generara un cdigo ejecutable a partir de las especificaciones expresadas en un lenguaje adecuado, no sera necesario abordar las fases de programacin y prueba.
FUOC P03/75069/02141
32
tipo de lenguajes an es muy precaria y por ello el ciclo de vida real es muy parecido al tradicional, que ya hemos descrito. A pesar de todos los intentos de producir sistemas de construccin de software utilizando prototipos, la realidad es que la prctica profesional todava descansa ampliamente en el ciclo de vida tradicional. Por otra parte, las dificultades en relacin con la calificacin correcta de un proyecto informtico de construccin de software de aplicacin provocan que se recomiende, incluso desde mbitos jurdicos, la descomposicin de cada proyecto informtico en dos proyectos consecutivos: 1) Un primer proyecto que tenga como objetivo funcional principal establecer simplemente las especificaciones detalladas de lo que despus se debe programar e instalar. 2) Un segundo proyecto, generalmente con un volumen de esfuerzo y un coste ms elevado, que cubra la etapa de programacin y pruebas, una vez se han determinado con cierto detalle, en el primer proyecto, las especificaciones y las funcionalidades concretas que deben implementarse. Desgraciadamente, no se realiza de manera habitual esta subdivisin de los proyectos informticos de construccin de software de aplicacin. La prctica profesional ms habitual ve como un nico proyecto la determinacin de los requisitos y la especificacin, seguidas, dentro del mismo proyecto, de la implementacin hasta llegar a la puesta en funcionamiento definitiva de la aplicacin.
Podis ver el ciclo de vida de una aplicacin informtica en el subapartado 1.8 de este mdulo didctico.
Podis ver las dificultades asociadas a la calificacin correcta en el apartado 2 del mdulo Estimacin de costes de un proyecto informtico de este mdulo didctico.
Es recomendable... ... dividir el proyecto informtico 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.
En la prctica profesional,... ... las fases de determinacin de los requisitos y de especificacin se denominan, respectivamente, estudio de oportunidad y anlisis funcional, mientras que la implementacin consta de las fases de diseo, programacin y pruebas.
2.2.2. Objetivos generales Ante la realidad que hemos descrito con relacin a la ingeniera del software, es comprensible que esta la ingeniera en la construccin de software de aplicacin tenga estos dos objetivos centrales: 1) Debe obtener un producto de software de calidad que sea econmico, fiable, eficiente, fcil de usar, fcil de mantener, etc. 2) Se ha de construir este software mediante un proceso correcto y adecuado que implique una gestin eficaz de los recursos puestos en disposicin del ingeniero de software para la construccin de un nuevo sistema informtico: personas y recursos informticos de todo tipo. En definitiva, la ingeniera del software aporta una visin que quiere ser seria y metdica tanto en el proceso de elaboracin del software, como en la gestin del proyecto que tiene como objetivo obtener ste.
FUOC P03/75069/02141
33
2.2.3. Componentes Para conseguir los dos objetivos centrales de la ingeniera del software, Boehm analiza, respecto al producto y al proceso, las caractersticas de tres componentes fundamentales: las relaciones humanas*, la ingeniera de recursos** y la ingeniera de programas***. Como consecuencia de este anlisis se formulan las siguientes conclusiones: 1) Respecto al producto a) Las relaciones humanas se concretan en la necesidad de que el software producido sea fcil de utilizar y pueda satisfacer las necesidades reales de los posibles usuarios. b) La ingeniera de recursos exige que el producto sea modificable y adaptable a cambios futuros totalmente inevitables (sobre todo en el mbito de la informtica de gestin) y que su eficiencia de uso proceda de un equilibrio adecuado entre los costes de producirlo y los beneficios obtenidos en su utilizacin. c) La ingeniera de programas se concreta en el hecho de que el software est especificado con precisin, de una manera completa, consistente, verificable y realizable y que, adems de que sea correcto, tambin sea intrnsecamente adaptable o modificable. 2) Respecto al proceso a) El aspecto de las relaciones humanas obliga a planificar, organizar, dirigir y controlar el proceso de construccin de software de aplicacin y su posible automatizacin*. b) La ingeniera de recursos presupone una estimacin previa a la planificacin adecuada y un anlisis de costes y beneficios correcto y, tambin, el control de los hitos o puntos cruciales del proyecto y el respeto de los plazos y presupuestos. c) La ingeniera de programas exige la validacin de la factibilidad del proyecto y de sus requisitos y especificaciones, adems de la puesta en funcionamiento de un sistema de verificacin y validacin del diseo, la programacin y la misma integracin del sistema, hasta llegar a la implementacin, respetando los procedimientos establecidos para el mantenimiento futuro. Para alcanzar todo esto, es necesario introducir tcnicas concretas que acerquen la actividad de construccin de software de aplicacin a las actividades de ingeniera tradicional y que rechacen las prcticas poco profesionales y demasiado cercanas al bricolaje que, desgraciadamente, an predominan en gran parte del mbito profesional.
* Por ejemplo, con herramientas CASE. * En ingls, human relations. ** En ingls, resource engineering. *** En ingls, program engineering.
Un software preciso y adaptable... ... es conveniente, por ejemplo, para utilizar tcnicas como la estructuracin y porque garantiza la legibilidad y facilita la comprensin de diseos y resultados.
FUOC P03/75069/02141
34
Para un especialista como Mills, todo esto se traduce en la incorporacin y el dominio de tcnicas procedentes de tres entornos conceptuales complementarios: el diseo, el desarrollo y la gestin. Consideremos cada uno de estos entornos: a) En lo referente al diseo*, se deben atender los temas ms tericos propios de la informtica, como los esquemas bsicos de composicin de algoritmos, la estructuracin de los datos y programas o el control de procesos mltiples y asncronos en los sistemas distribuidos y en los de tiempo real. b) Con respecto al desarrollo*, se agrupan los procesos prcticos del proceso de construccin y desarrollo de software desde el punto de vista de las tcnicas y las herramientas puestas a disposicin de las personas responsables de construir el producto final: entornos de desarrollo (lenguajes, ayudas, herramientas de todo tipo, etc.), procedimientos ordenados de desarrollo progresivo (como el diseo descendente top down) y tcnicas formales de documentacin de productos de software. c) En la gestin* se agrupan todas las prcticas necesarias para valorar, planificar y controlar el trabajo de construir software y, en definitiva, gestionar el proyecto informtico, que consiste en la elaboracin de una determinada aplicacin informtica.
* En ingls, software engineering design.
* En ingls, software engineering development.
* En ingls, software engineering management.
2.2.4. Distribucin de costes en la construccin del software Ya se ha realizado una sencilla enumeracin de las diferentes etapas tcnicas por las que pasa el proceso de construccin de software, lo que se denomina ciclo de vida de una aplicacin. Recordemos que existen otras maneras de contemplar el ciclo de vida que se tratan con detalle en las asignaturas de ingeniera del software, pero aqu, en lo referente a la gestin de proyectos informticos, mantendremos genricamente las etapas tradicionales ya mencionadas: 1) La construccin, formada por el estudio de oportunidad, el anlisis, el diseo, la programacin (o codificacin) y las pruebas, hasta llegar a la puesta en funcionamiento o a la entrada en explotacin del sistema de informacin. 2) El mantenimiento del sistema de informacin hasta que los usuarios decidan retirarlo al final de su vida til. Tambin hemos mencionado que, frecuentemente, cuando se considera un proyecto informtico, slo se tiene en cuenta el proceso de construccin hasta llegar a la puesta en funcionamiento de la aplicacin. Por tanto, recordando una vez ms la inconveniencia desde el punto de vista econmico de
Podis ver el ciclo de vida de una aplicacin informtica en el apartado 1.8 de este mdulo didctico.
Las dos grandes etapas... ... en la vida de una aplicacin son: la construccin el mantenimiento.
Podis ver los costes reales de una aplicacin informtica en el subapartado 1.9 de este mdulo didctico.
FUOC P03/75069/02141
35
olvidar los costes del mantenimiento, nos centraremos en los costes de la construccin de software de aplicacin. Se trata, evidentemente, de rdenes de magnitud. Diferentes autores han analizado la distribucin del coste global del desarrollo de un proyecto informtico y, aunque las proporciones exactas pueden depender de cada sistema concreto y del mtodo de medida utilizado para construirlo, se aceptan como referencia general las cifras establecidas a finales de los aos setenta y principios de los ochenta por autores como Boehm y Brooks. Esta distribucin es la que presentamos a continuacin: Un 40% del coste de desarrollar una aplicacin informtica se invierte en las etapas de anlisis y diseo. Un 20%, en la etapa de codificacin. El resto, un 40%, queda para la parte correspondiente a las pruebas. Evidentemente, el mantenimiento, uno de los costes ms elevados del software, se deja al margen de esta distribucin. Insistimos en que el mantenimiento, en las instalaciones informticas en la informtica de gestin, suele representar el doble del coste del desarrollo. Prcticamente se puede decir que las dos terceras partes del personal tcnico informtico* se encargan del mantenimiento de aplicaciones antiguas, mientras que slo una tercera parte o menos se dedica a construir aplicaciones nuevas. En relacin con estos costes, conviene puntualizar que, en la prctica profesional actual, estn mejor pagados los especialistas que trabajan en las etapas de anlisis y diseo, los analistas, que los que se ocupan de las tareas de programacin, los programadores, a pesar de que stas, en general, suponen un mayor esfuerzo en horas de trabajo, como muestra la figura Recursos y ciclo de vida del subapartado 1.8.
* Como analistas, diseadores y programadores.
El porcentaje de coste... ... en las etapas del ciclo de vida de una aplicacin es el que mostramos a continuacin: Anlisis y diseo: 40%. Codificacin: 20%. Pruebas: 40%.
2.2.5. Origen e importancia de los errores en el software Uno de los objetivos de la ingeniera del software es la obtencin de software de calidad. Como veremos con detalle al tratar las mtricas o unidades de medida del software, una de las medidas de calidad, evidentemente, se basa en el nmero de errores presentes en el software, incluso cuando est en explotacin. A pesar de que se intentan utilizar procesos de produccin de software que aseguren la calidad y la ausencia de errores, stos parecen algo inevitable en la construccin de software. Es importante intentar minimizar su nmero, pero conviene saber que, desgraciadamente, siempre quedan algunos.
Podis ver las mtricas del software en el apartado 1 del mdulo Estimacin de costes de un proyecto informtico de esta asignatura.
* En ingls, software quality assurance.
FUOC P03/75069/02141
36
Estudios como el de Jones de finales de los aos setenta y principios de los ochenta han establecido que solamente un 30% de los errores presentes en el software proceden de la etapa de codificacin. Se considera que un 15% de los errores corresponden a las fases de anlisis y diseo funcional, un 20% ms a la fase de diseo lgico y tcnico y hasta un 35% son errores que tienen su origen en insuficiencias de la documentacin, incomprensiones, malentendidos y otras causas a lo largo de todo el ciclo de vida de construccin de software de aplicacin. A medida que la ingeniera del software se ha ido preocupando de los aspectos ms claramente econmicos, ha interesado analizar la importancia de errores y el coste que supone corregirlos. Boehm ha mostrado que este coste difiere segn la etapa en la cual se descubren los errores.
El origen de los errores del software... ... en las diferentes fases del proyecto informtico se distribuye de la manera siguiente: Fase de anlisis: 15%. Fase de diseo: 20%. Fase de codificacin: 30%. Documentacin insuficiente, incomprensiones y malentendidos: 35%.
Tomando como base el coste de corregir un error de anlisis descubierto en la misma fase de anlisis de requisitos y elaboracin de las especificaciones (anlisis funcional), la correccin de un error detectado en la fase de diseo cuesta siete veces ms. El coste de correccin de un error ser diez veces ms alto si se observa en la fase de codificacin y veinte o treinta veces ms si se descubre en la fase de pruebas. Segn Boehm, corregir un error descubierto en la fase de mantenimiento* puede ser hasta cien veces ms caro que si se hubiera detectado durante la fase de anlisis.
* Es decir, cuando el software ya est en explotacin.
Una de las causas de estas cifras (que debemos interpretar en un sentido no rigurosamente exacto, pero s como referencia) se encuentra en el sistema del proceso de construccin de software de aplicacin basado en el ciclo de vida en cascada, que provoca que un error detectado en una fase posterior suponga modificar las etapas anteriores, con lo que ello supone de coste y desorden. En cualquier caso, debera ser evidente la necesidad de establecer mtodos y procesos de construccin de software que permitan evitar los errores o detectarlos lo ms pronto posible.
Un mtodo de deteccin de errores en las fases iniciales ltimamente se ha incrementado la tendencia a experimentar con prototipos provisionales para detectar, sobre todo, los errores (a menudo de interpretacin de las necesidades de los usuarios) nacidos en la fase de anlisis que, desgraciadamente, no se suelen descubrir hasta las pruebas finales de integracin o de aceptacin del sistema.
2.3. Metodologas de construccin del software En la prctica profesional, ya a partir de los aos sesenta, se trat de elaborar procesos de construccin de software de aplicacin que permitieran incorporar un mnimo de seguridad respecto de la calidad del software obtenido, adems de garantizar la mayor facilidad posible para el mantenimiento, siempre inevitable en la informtica de gestin.
FUOC P03/75069/02141
37
Las primeras realizaciones en el campo de la creacin de sistemas de informacin se reducan a la programacin, ms o menos compleja y difcil, y a menudo con lenguajes tediosos de tipo ensamblador. El trabajo de cada programador era esencialmente intuitivo y orientado fundamentalmente a una optimizacin de la eficiencia para ejecutar los programas en una mquina concreta. El problema principal era conseguir algoritmos que fueran rpidos y utilizaran poca memoria; en definitiva, el objetivo era optimizar el uso de los escasos recursos disponibles. En la dcada de los sesenta se plante un nuevo problema: la necesidad de racionalizar la produccin de un software que, adems, se deba mantener. Como se ha dicho, la mejora de prestaciones de los ordenadores no tiene un paralelo en la productividad en el campo de la construccin y la puesta a punto de programas. Al contrario, al aumentar la complejidad de los sistemas de informacin que se construan (ya no simplemente programas) se observaba la dificultad creciente de fabricar correcta y rpidamente el software necesario. Adems, existe un factor que se revel todava ms urgente: la carga de trabajo que supona el mantenimiento de software provoc plantearse la necesidad de convertir la tarea de programar en una actividad mucho ms estructurada y metdica. Si se pensaba en el mantenimiento, ya no eran interesantes las soluciones ingeniosas que podan ahorrar recursos pero que eran difciles de entender para el mismo programador (o para el sustituto de ste) cuando, meses despus, fuera necesario mantener el software. Por ello se puso tanto inters, a finales de la dcada de los sesenta y principios de los setenta, en el diseo de diferentes tcnicas y mtodos de construccin de aplicaciones informticas. Con el presuntuoso nombre de metodologas de anlisis y programacin aparecieron varios procedimientos para crear sistemas de informacin.
Un algoritmo... ... es una secuencia de instrucciones establecida como una descripcin no ambigua de las acciones que se han de llevar a cabo para obtener un resultado determinado.
2.3.1. Precisin terminolgica previa Los profesionales de la informtica suelen hablar de metodologas de anlisis, metodologas de diseo o de metodologas de informacin cuando, en realidad, se refieren a mtodos.
El uso informtico del trmino metodologa... ... no se corresponde con el significado habitual de ciencia del mtodo, que se debera reservar para la ciencia que se ocupa de estudiar, analizar y comparar mtodos. En el caso concreto de la ingeniera del software, indica, por ejemplo, cmo se deben seleccionar los mtodos y las tcnicas ms adecuadas para ser utilizadas en un proyecto informtico concreto.
En la prctica profesional informtica, se utiliza el trmino metodologa para referirse a un conjunto de mtodos, tcnicas e, incluso, herramientas utilizados precisamente en el proceso de construccin de software en la actividad que se etiqueta habitualmente como proyecto informtico.
FUOC P03/75069/02141
38
Por tanto, el trmino metodologa en informtica se utiliza como un sinnimo forzado de mtodo, entendido como el conjunto de aspectos del proceso de construccin de software que en cierta medida son independientes del software concreto que se construye y de las personas que trabajan en l. La parte propiamente informtica de un mtodo est constituida por las herramientas informticas integradas en el entorno de desarrollo y construccin del software. Las personas utilizan las prcticas que conocen para construir el software deseado, siguiendo las directrices de la metodologa y empleando las herramientas del entorno. Durante los aos setenta se hablaba preferentemente de metodologas de anlisis, y tambin de metodologas de programacin, en funcin de la etapa del ciclo de vida en la que las diferentes metodologas incidan ms. Asimismo, se habl en ocasiones de metodologas de diseo, a pesar de que hoy en da, como hacemos en esta asignatura, se comienza a extender el uso de una referencia genrica a las metodologas de construccin (o de desarrollo) del software.
Algunas de las prcticas... ... que utilizan las personas son, por ejemplo, los conceptos tericos, las tcnicas descriptivas, deductivas o de verificacin, los estndares de nomenclatura, la legibilidad o la arquitectura, etc.
2.3.2. Metodologas explcitas y metodologas implcitas Retomando el tema ms general de las metodologas de construccin de software, cualquier proceso de construccin y desarrollo de software se lleva a cabo siguiendo un mtodo determinado.
Se dice que se aplica una metodologa implcita cuando la metodologa de construccin de software que se utiliza no est definida explcitamente y es, simplemente, la manera de trabajar de un determinado profesional o de un grupo de profesionales informticos. Por razones obvias, se suele caracterizar como metodologa (explcita) de construccin de software el mtodo, o al conjunto de mtodos, que rene las caractersticas de ser pblico, documentado y enseable.
Slo tiene sentido decir que se utiliza una determinada metodologa cuando se ha definido explcitamente en normas, cursos, textos, etc. y, adems, cuando la ha adoptado oficialmente una organizacin para aplicarla en todos o en algunos de los proyectos informticos que debe realizar. Las diversas metodologas utilizadas en la prctica profesional se diferencian, a menudo radicalmente, por muchas razones. Las causas ms importantes proceden del entorno organizativo, profesional y tcnico en el que se emplean. La dimensin y el tamao del proyecto informtico, la formacin y los conocimientos del personal que forma el equipo de proyecto y el tipo de sistema
FUOC P03/75069/02141
39
de informacin y/o aplicacin que se quiere construir son algunos de los elementos que justifican la adopcin de diferentes metodologas. Comprobar que una metodologa sea adecuada para un proyecto informtico concreto es un paso previo muy importante para el xito del proyecto informtico de construccin de software de aplicacin y puede tener efectos sobre la calidad del programa construido. Es evidente que un proyecto pequeo seguramente no necesita el mismo grado de complejidad de desarrollo y de gestin que un proyecto muy grande.
2.3.3. Componentes
Los componentes principales de una metodologa tradicionalmente son los siguientes: El procedimiento que aconseja utilizar. La organizacin y el reparto del trabajo que supone. La documentacin que proporciona. Las ayudas mecanizadas de las que dispone para ayudar a realizar, documentar y controlar el proyecto informtico.
De los cuatro componentes mencionados de una metodologa, se suele atribuir la mxima importancia al procedimiento y a la organizacin que se deriva de ste. Muchas veces una metodologa se caracteriza simplemente por el ciclo de vida. 1) El procedimiento de la metodologa
El procedimiento de trabajo determina el conjunto de operaciones que se deben efectuar durante el proceso de construccin de software.
Estas operaciones se agrupan en una serie de etapas, fases, subfases, actividades, etc. Aunque las diferentes metodologas utilizan trminos diferentes, una etapa se puede caracterizar como un conjunto de operaciones o actividades con un inicio y un final claramente definidos, que tiene como resultado una documentacin completa la cual, en el ciclo de vida en cascada tradicional, debe servir de base para evaluar el sistema, comenzar la etapa siguiente, volver a calificar el proyecto informtico y tambin, a veces, decidir si el proyecto debe continuar o no. Por otra parte, la descomposicin en etapas del proceso de construccin de software recibe el nombre genrico de ciclo de vida y se considera uno de los
FUOC P03/75069/02141
40
aspectos ms caractersticos y relevantes de las metodologas. En realidad, las diferentes metodologas que existen tampoco coinciden en el ciclo de vida que proponen, aunque muy a menudo las diferencias son ms terminolgicas que reales. El ciclo de vida consta de diferentes etapas (por ejemplo: estudio de oportunidad, anlisis, diseo, implementacin y mantenimiento) que, a pesar de que en la prctica se interrelacionan, a menudo se considera que son independientes. Se trata, en este caso, del denominado ciclo de vida en cascada, que hemos mencionado anteriormente. Este punto de vista es particularmente importante en la gestin de proyectos informticos, ya que, como veremos, en la prctica del seguimiento a menudo se considera que las diferentes etapas estn separadas por los denominados hitos*, imprescindibles para un buen control del proyecto informtico. En general, se considera que un hito se ha alcanzado y que, por tanto, ha terminado una etapa y comienza la siguiente, cuando toda la documentacin prevista para la etapa se ha realizado. 2) La organizacin de la metodologa El procedimiento que se debe seguir supone, indefectiblemente, una determinada organizacin del trabajo.
* En ingls, milestones.
Podis ver el ciclo de vida en cascada y los hitos en los subapartados 1.8 y 2.3.4, respectivamente, de este mdulo didctico.
La organizacin del trabajo se entiende como un conjunto de normas con el fin de realizar a cabo la calificacin*, el seguimiento, el control y la organizacin del proyecto de construccin de software.
* La calificacin consiste en realizar una estimacin y una planificacin del proyecto informtico.
En definitiva, la organizacin determina el reparto del trabajo entre los diferentes profesionales, hecho que ha tenido como consecuencia que, teniendo en cuenta la relativa inercia del mundo laboral, las primitivas categoras profesionales (que surgen de determinadas metodologas propias de los aos setenta y ochenta) se mantengan ms de lo que sera conveniente y, en cierta manera, dificulten la utilizacin de nuevas metodologas que empleen un ciclo de vida que descomponga y reparta el trabajo de otra manera entre los tcnicos informticos especialistas (por ejemplo, sin mantener las categoras antiguas de analista y programador). 3) La documentacin de la metodologa
La organizacin del trabajo... ... permite determinar, por ejemplo, el tipo de profesionales que deben intervenir en cada etapa del ciclo de vida, cules son las responsabilidades respectivas, cmo se han de relacionar los diferentes miembros de un equipo de proyecto y, tambin, qu formacin tcnica y administrativa han de tener.
La documentacin es el tercer componente de una metodologa y proporciona, en particular, el contenido y las tcnicas con las cuales sta se crea.
Respecto al lenguaje con el que se elabora la documentacin, puede ser grfico o narrativo y, en los dos casos, formalizado o no.
FUOC P03/75069/02141
41
En relacin con la finalidad de la documentacin, se puede hablar de los siguientes casos, no necesariamente excluyentes: a) Documentacin de descripcin tcnica de los modelos y los elementos del sistema de informacin con diferentes grados de abstraccin y detalle. b) Documentacin de trabajo o documentacin interna de una etapa, que incluye aspectos como las alternativas que se han considerado y los clculos y motivaciones que conducen a la eleccin de una de estas alternativas. c) Documentacin de utilizacin, para entregar a los usuarios de la aplicacin con toda la informacin acerca de cmo introducir los datos, el significado de las opciones y cdigos, los errores posibles, la interpretacin de los datos de salida, etc. A menudo, esta documentacin se denomina manual de usuario, aunque la buena prctica profesional actual tambin consigna esta informacin en los sistemas de ayuda al usuario* de la aplicacin. d) Documentacin de explotacin (o documentacin de operacin), para uso de los operadores informticos del sistema, donde se incluyen la forma de instalacin, los controles de calidad de operacin, los mecanismos de seguridad y de reactivacin en caso de fallos, etc. e) Documentacin de presentacin, elaborada con el objetivo de presentar el sistema y sus funcionalidades a los usuarios, a menudo de manera resumida. Los dos primeros tipos de documentacin (a y b) componen lo que se denomina manual tcnico; los dos siguientes forman, respectivamente, el manual de usuario y el manual de explotacin, mientras que el ltimo es documentacin de promocin orientada claramente a la venta o difusin de la aplicacin. Un aspecto muy importante es la dificultad de obtener una documentacin correcta y adecuada a causa de la enorme cantidad de informacin que se genera en un proyecto informtico y, principalmente, por la dificultad de mantener una documentacin consistente y actualizada, incluso en la etapa de mantenimiento. Una caracterstica comn de la mayora de las metodologas es que muestran un nfasis casi desmesurado en la necesidad de disponer de una documentacin tcnica completa y ordenada de todos los pasos realizados en la construccin de una aplicacin. Seguramente, es una reaccin inevitable a la terrible falta de documentacin en el mtodo de trabajo de construccin de software de aplicacin antes de la llegada de las metodologas, pero lo cierto es que exigir un exceso de documentacin ha supuesto que el trabajo de utilizar una metodologa sea pesado y se puede decir que, a menudo, la documentacin elaborada en la prctica suele ser bastante ms escasa de lo que pide la metodologa.
* El sistema de ayuda al usuario de una aplicacin es lo que a menudo se denomina help.
En la documentacin... ... asociada a una metodologa se incluyen los elementos siguientes: un manual tcnico, un manual de usuario, un manual de explotacin documentacin de promocin.
FUOC P03/75069/02141
42
4) Las ayudas de la metodologa

Un buen ejemplo de ayudas automticas... ... son los componentes tpicos de los entornos de programacin y diseo, como los programas editores, los compiladores, los montadores de enlaces (linkers) y otras herramientas, como procesadores de tablas de datos, generadores de pantallas y dilogos, diccionarios de datos, etc.
Las ayudas automticas de las que disponen las metodologas tienen un inters especial. Entendemos por ayudas automticas los programas informticos destinados a facilitar el trabajo de construir software.
Las ayudas automticas pueden facilitar las actividades de anlisis, diseo o implementacin propias del procedimiento recomendado por la metodologa. Tambin pueden ayudar a gestionar la organizacin del proyecto (concretamente, pueden ayudar a controlar el proceso de progreso y realizacin) y facilitar el trabajo de elaborar la documentacin exigida por la metodologa. La visin integrada de las ayudas mecanizadas mencionadas da lugar a los sistemas de ingeniera del software soportada por ordenadores*, los cuales, a pesar de su actual disponibilidad y potencia, no parece que se utilicen tanto como sera conveniente.
* Sistemas CASE.
2.3.4. Ciclo de vida y procedimiento Conviene analizar el papel que en una metodologa ejerce el ciclo de vida en comparacin con el papel atribuido al procedimiento utilizado para construir software.
Existe una visin tradicional que define el ciclo de vida como una parte fundamental del mtodo y considera que es el marco de referencia al cual se han de supeditar los dems componentes de la metodologa. Segn esta visin tradicional, se podra decir que el ciclo de vida define la arquitectura del mtodo de trabajo y es, por tanto, su componente principal. El procedimiento de la metodologa sirve entonces para definir con ms detalle las actividades tipo que se deben llevar a cabo en cada etapa y las tcnicas que es necesario utilizar. En la prctica, las normas de documentacin de una metodologa se describen en relacin con los documentos que definen los hitos del ciclo de vida.
Esta visin tradicional ha sido sustituida recientemente por un enfoque ms prctico y realista que independiza el procedimiento recomendado en la metodologa de las etapas del ciclo de vida.
De esta forma, el procedimiento propio de la metodologa se considera como una gua tcnica para la construccin de software y el ciclo de vida como una superestructura que se sobrepone al mencionado procedimiento.
FUOC P03/75069/02141
43
La manera prctica 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, si es necesario con pequeos ajustes, sean cuales sean las caractersticas de cada nuevo proyecto informtico de construccin de software de aplicacin. El xito de este enfoque depende, naturalmente, de la posibilidad de repetir o no las caractersticas citadas entre los diferentes proyectos sucesivos que se abordan. En determinados planteamientos que forman parte de la ingeniera del software, incluso se ha querido dar un carcter 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 construccin de software. 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, pero es indudable que a lo largo de la corta historia de la informtica profesional, 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. As, en el seno de la ingeniera del software, se habla de ciclo de vida en cascada, ciclo de vida con prototipos, ciclo de vida en espiral, ciclo de vida en fuente, etc. y, con esta caracterizacin del ciclo de vida, se cree que ya se ha dicho todo acerca del mtodo que debe utilizarse para construir software. Cabe recordar, sin embargo, que la realidad es ms compleja y que en la construccin de software de aplicacin, adems del procedimiento (reflejado hasta cierto punto en el ciclo de vida), se debe tener en cuenta la organizacin (el reparto de las tareas entre los profesionales y su cualificacin tcnica implcita), la documentacin que se exige y los ajustes informatizados disponibles.
2.3.5. Caractersticas generales y supuestos implcitos Cualquier metodologa de construccin de software de aplicacin debera tener al menos los siguientes rasgos: a) Comprender todo el proceso de desarrollo del sistema de informacin (a pesar de que existen metodologas restringidas a determinadas etapas: anlisis, programacin, etc.). b) Favorecer una correcta gestin del proyecto informtico. c) Garantizar una comunicacin fluida entre las personas que intervienen en el proyecto mediante la documentacin que se genera. d) Facilitar el proceso de pruebas y, sobre todo, el mantenimiento futuro y la evolucin de la aplicacin.
FUOC P03/75069/02141
44
e) Proporcionar ayudas automatizadas durante el proceso de construccin y mantenimiento que faciliten la pesada tarea de obtener documentacin y que tambin permitan controlar si se utiliza correctamente la metodologa. f) Hacer visible y controlable el progreso en la construccin del sistema de informacin que se quiere llevar a cabo. g) Estar preparada para asumir mejoras en el futuro y poder adaptarse a los cambios en la tecnologa informtica. h) Poder ser enseada y transferida. A pesar de lo que se demanda, la mayora de las metodologas de desarrollo de construccin de software de aplicacin utilizadas por los profesionales informticos parten de supuestos (no claramente explcitos) que no siempre se dan en la prctica. Detectar cules son estos supuestos resulta muy importante para reconocer y evaluar la adecuacin de una metodologa en cada caso concreto.
Es cierto que, con el fin de conseguir un mantenimiento fcil, conviene que haya siempre una uniformidad muy clara con respecto a la metodologa utilizada en todos los proyectos informticos de una determinada organizacin informtica. Ahora bien, tambin conviene tener en cuenta que no todas las metodologas sirven para cualquier tipo de proyecto informtico, aunque muy frecuentemente no se diga.
La mayora de las metodologas se presentan como si fuesen tiles para todo tipo de proyectos, con independencia de los sistemas de informacin* concretos que se quieren alcanzar, de los aspectos tcnicos** o de las herramientas utilizadas***, etc.
* Sistemas transaccionales y de decisin. ** Sistemas batch, en tiempo real, o distribuidos. *** Con lenguajes tradicionales de bajo o alto nivel, con herramientas RAD (Rapid Application Development), etc.
El investigador escandinavo Janis Bubenko ha establecido una lista mnima de estos supuestos implcitos en las diferentes metodologas. Teniendo en cuenta esto, conviene decir que la mayora de las metodologas existentes en la prctica profesional presentan las siguientes caractersticas:
1) Los sistemas de informacin que construyen son relativamente estables y autnomos. Los procesos dominantes son de tipo rutinario o repetitivo y la informacin con la que se trabaja se encuentra estructurada.
2) El proceso de construccin imaginado es lineal y, en la mayora de los casos, se adapta al ciclo de vida en cascada tradicional.
Muchas metodologas suponen tambin, un poco arriesgadamente, que las especificaciones son claras y estables y que los usuarios que utilizarn la aplica-
FUOC P03/75069/02141
45
cin conocen sus necesidades de informacin presentes y futuras y, adems, saben expresarlas y comunicarlas. Excepto algunas metodologas surgidas en el mbito acadmico, de escasa utilizacin real, la mayora de las metodologas utilizan descripciones y tcnicas de especificacin y diseo casi siempre informales para facilitar que los usuarios no especializados las entiendan.
FUOC P03/75069/02141
46
Resumen
Los proyectos informticos presentan suficientes particularidades para exigir un tratamiento especializado que, hasta cierto punto, los diferencia de otros proyectos del mbito de la ingeniera. En demasiadas ocasiones los directores y responsables de empresa han constatado que los proyectos informticos de construccin de software nuevo difcilmente finalizan en el plazo que se haba calculado y con los costes previstos. Parece que exista una tendencia inevitable a menospreciar las dificultades de los proyectos informticos, lo que provoca que se planifiquen de manera que despus es francamente difcil, por no decir imposible, cumplir los objetivos del proyecto. Un proyecto informtico de construccin de software es la actividad que consiste en planificar, seguir y controlar la produccin de software. El jefe de proyecto es la persona que coordina los diferentes aspectos del proyecto informtico y se responsabiliza de ello. Un proyecto informtico debe ser siempre concreto, excepcional (nico), de duracin limitada y flexible; adems, no permanece fijo y esttico, sino que es algo vivo. La actividad de gestin de un proyecto informtico se orienta a obtener como objetivos generales unas determinadas funcionalidades, las cuales deben estar disponibles en los plazos establecidos y deben alcanzarse respetando un determinado presupuesto. En la gestin de un proyecto informtico existen cuatro grandes etapas: inicio, calificacin (estimacin y planificacin), desarrollo (seguimiento y control) y cierre. Desgraciadamente, se ha generalizado la idea de que los costes de tener una aplicacin en disposicin de ser operativa no incluyen los gastos de mantenimiento y durante la construccin del software no siempre se tiene en cuenta todo aquello que ayude a tener un buen mantenimiento, sobre todo si se producen problemas para cumplir los objetivos del proyecto (funcionalidades, plazos y presupuesto). Construir software seguro, fiable y de calidad es una actividad siempre llena de dificultades. Desde la conferencia de Garmish (1968) se quiere abordar el proceso de diseo, construccin y mantenimiento del software con la misma seriedad y los mismos modelos tpicos de cualquier otra actividad de ingeniera, lo que ha dado lugar a la denominada ingeniera del software y a diferentes mtodos (o metodologas, en el argot profesional informtico) de diseo, construccin y mantenimiento del software. En la prctica profesional informtica, el trmino metodologa se aplica al conjunto de mtodos, tcnicas e, incluso, herramientas utilizadas precisamente en el proceso de construccin o mantenimiento de software.
FUOC P03/75069/02141
47
Una metodologa tiene como componentes principales el procedimiento de trabajo (ciclo de vida), la organizacin de las tareas que supone, la documentacin que encarga realizar y las ayudas informticas de las que dispone.
FUOC P03/75069/02141
49
Actividades
1. Pensad razones que justifiquen que la construccin de software en la informtica de gestin siempre es una actividad conflictiva. 2. Intentad imaginar por qu, en la profesin informtica, se utiliza una palabra tan larga como metodologa para referirse a lo que es simplemente un mtodo. Tiene algo que ver con el hecho de que en el siglo XVI, por ejemplo, los mdicos hicieran sus diagnsticos en latn a pesar de que an no se saba gran cosa sobre medicina y el funcionamiento del cuerpo humano? 3. Intentad averiguar si el hecho de que incluso los programas muy utilizados, como el Windows 98, tengan fallos (la famosa pantalla azul), tiene alguna relacin con lo que se estudia en este mdulo. Buscad otros ejemplos semejantes. 4. Durante los aos ochenta, la Administracin norteamericana de Ronald Reagan quiso poner en funcionamiento un sistema informtico de deteccin y contraataque con misiles que se denomin Iniciativa de defensa estratgica (SDI) y que la prensa etiquet como la guerra de las galaxias. Por qu razn este proyecto, al menos desde el punto de vista tcnico, estaba condenado al fracaso?
Ejercicios de autoevaluacin
1. Cules son los objetivos centrales de la gestin de un proyecto informtico de construccin de software? 2. Por qu etapas debe pasar la gestin de un proyecto informtico? 3. Cules son las caractersticas bsicas de un proyecto informtico? 4. Qu funcionalidades suelen fallar cuando un proyecto informtico de construccin de software no puede cumplir con sus objetivos? 5. Dirais que la construccin de software de gestin es una actividad bien conocida, con procedimientos perfectamente establecidos de ingeniera de software y que genera pocos problemas? 6. Cules son los componentes bsicos de una metodologa de construccin de software? 7. Mencionad las diferentes etapas del ciclo de vida de construccin de software con la denominacin ms tradicional. 8. Es cierto que la mayor parte del esfuerzo de anlisis y programacin de las organizaciones se dedica, hoy en da, a la etapa de mantenimiento? 9. Cuando se utiliza nueva tecnologa en una aplicacin, existe ms o menos riesgo de error y de fracaso en el proyecto? 10. Una cifra de productividad de cerca de cincuenta lneas de cdigo por da y persona (teniendo en cuenta el conjunto del proyecto), debe considerarse alta o baja?
FUOC P03/75069/02141
50
Solucionario
Ejercicios de autoevaluacin
1. Los objetivos centrales de la gestin de un proyecto informtico son los siguientes: obtener un software que tenga unas funcionalidades determinadas, que este software est disponible en un plazo fijado y que se ajuste a un presupuesto. 2. La gestin de un proyecto informtico pasa por las etapas de inicio, calificacin (estimacin y planificacin), desarrollo (seguimiento y control) y cierre del proyecto. 3. Un proyecto informtico debe ser concreto, excepcional (nico), de duracin limitada y flexible. 4. Generalmente, las funcionalidades que ms fallan en un proyecto informtico de construccin de software son las que menos ve el usuario: la calidad de diseo y programacin, la documentacin tcnica detallada que hara ms fcil el mantenimiento, el nmero de pruebas, la seguridad de un buen funcionamiento en todos los casos posibles, etc. 5. No, porque se intenta construir software de gestin con procedimientos establecidos de ingeniera de software, pero todava no se ha conseguido; siempre quedar la incertidumbre de saber qu necesitan realmente los usuarios y el ritmo de cambio que impone la realidad de cada da. 6. Una metodologa de software se compone del procedimiento que recomienda (el ciclo de vida), la organizacin del trabajo que supone, la documentacin que encarga realizar y las ayudas informticas de las que dispone. 7. Las etapas tradicionales del ciclo de vida de construccin de software son: el estudio de oportunidad, el anlisis, el diseo, la programacin, las pruebas y el mantenimiento. 8. S, porque en la mayora de las instalaciones con diferentes aplicaciones en funcionamiento la tarea del mantenimiento llega a ocupar ms de las dos terceras partes de los recursos de anlisis y programacin disponibles. 9. Existe ms riesgo porque la novedad de la tecnologa aporta incertidumbre al proceso de construccin de software, como mnimo hasta que los profesionales tcnicos que intervienen en el proyecto dominen la nueva tecnologa. 10. Una productividad de cincuenta lneas de cdigo por da y persona se puede considerar alta porque los estudios efectuados por especialistas como Barry Boehm muestran que la cifra real de lneas de cdigo est ms cercana a diez que a cincuenta.
Glosario
calificacin de un proyecto informtico f Evaluacin global de la carga de trabajo necesaria para la realizacin del proyecto (estimacin) y, segn los recursos disponibles, reparto en el tiempo de las diferentes actividades que se deben llevar a cabo (planificacin). ciclo de vida m Descomposicin, encadenamiento e interrelacin de las etapas del proceso de construccin de software (procedimiento) que define la arquitectura del mtodo de trabajo. desarrollo de un proyecto informtico m Proceso de recogida de datos sobre la evolucin del proyecto para identificar las desviaciones entre la planificacin y la realidad (seguimiento) y poder tomar las medidas de correccin necesarias (control). fases de un proyecto informtico f Conjunto concreto de actividades que forma una clase de subproyecto destinado a ayudar a controlarlo y, adems, a constituir un paquete aislado (de manera natural o artificial) del resto para, si es posible, facturarlo por separado (a un cliente externo o en el seno de la contabilidad de costes interna de una misma empresa). gestin de un proyecto informtico m Proceso de direccin y control que se concentra en la concepcin, la puesta en funcionamiento, el seguimiento y la evaluacin de un sistema de informacin particular denominado proyecto. ingeniera del software f Intento de establecer el uso de principios de ingeniera robustos, orientados a obtener software que sea fiable y que funcione eficientemente en mquinas reales de una manera econmica.
FUOC P03/75069/02141
51
mantenimiento m Etapa de explotacin de la vida de una aplicacin que es la ms larga y costosa. En esta fase debe procederse a corregir errores (mantenimiento correctivo), efectuar modificaciones (mantenimiento adaptativo) y aadir mejoras (mantenimiento perfectivo). metodologa de construccin de software f Conjunto de mtodos, tcnicas e incluso herramientas utilizadas precisamente en el proceso de construccin de software. proyecto informtico de construccin de software m Actividad consistente en planificar, seguir y controlar la produccin de nuevo software. requisito creciente m Fenmeno muy habitual en los proyectos de la informtica de gestin que provoca la evolucin y el crecimiento de los requisitos del proyecto informtico, de manera que si el jefe de proyecto no reacciona a tiempo, es difcil saber cules son las funcionalidades que se deben implementar, ya que continuamente surgen nuevas necesidades. riesgo de un proyecto informtico m Posibilidad de que no se alcancen los objetivos deseados.
Bibliografa
Boehm, B.W. (1981). Software engineering economics. Englewood Cliffs: Prentice Hall. Gane, C.; Sarson, T. (1990). Computer-aided software engineering: The methodologies, the product and the future. Englewood Cliffs: Prentice Hall. Grupp, B. (1985). La gestin del departamento de informtica. Barcelona: Hispano Europea SA. Marco, T. de (1982). Controlling software projects. Englewood Cliffs: Prentice Hall. Page-Jones, M. (1985). Practical project management: Restoring quality to DP projects and systems. Nueva York: Dorset House. Piattini, M.; Calvo-Manzano, J.A; Cervera, J.; Fernndez, L. (1996). Anlisis y diseo detallado de aplicaciones de gestin. Madrid: Ra-ma. Pressman, R.S. (1998). Ingeniera del software: un enfoque prctico (4. ed.). Madrid: McGraw-Hill. Ros, A.; Viallonga, J. (1995). Gesti dels sistemes dinformaci a lempresa. Barcelona: Edicions UPC. Sommerville, I. (1996). Software engineering (5. ed.). Reading: Addison-Wesley. Thomset, R. (1993). Third wave project management: A handbook for managing the complex information systems for the 1990s. Englewood Cliffs: Prentice Hall. Whitten, J.L.; Bentley, L.D.; Barlow, V.M. (1994). Systems analysis & design methods (3. ed.). Burr Ridge: Irwin.

TN51WR4HLVHTWDZD94AZ

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TN51WR4HLVHTWDZD94AZ

Uploaded by

Copyright:

Available Formats

El proyecto informtico de construccin de software

Miquel Barcel Garca

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

* En ingls, downsizing o rightsizing.

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

Causas posibles de fracaso

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

2. La construccin del software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

2.1.3. Cambio en el reparto de los costes entre hardware y software

El proyecto informtico de construccin de software

Podis ver el subapartado 1.9 de este mdulo didctico.

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

* Como desarrollo, utilizacin y mantenimiento.

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

* En ingls, software engineering design.

* En ingls, software engineering development.

* En ingls, software engineering management.

El proyecto informtico de construccin de software

* En ingls, software quality assurance.

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

4) Las ayudas de la metodologa

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

El proyecto informtico de construccin de software

You might also like