GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES

Transcripción

1 Ciclo Formativo: Módulo: Desarrollo de Aplicaciones Informáticas Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión Unidad de Trabajo 10: GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES Arturo Mora Rioja 1. Introducción a la gestión de proyectos La tendencia general es ver un proyecto de desarrollo de software como una serie de etapas a desarrollar de forma secuencial, incluso admitiendo el solapamiento entre ellas (análisis, programación, pruebas). No obstante, se puede identificar una serie de tareas que han de estar presentes durante todo el desarrollo, desde la aparición de las primeras ideas de alto nivel hasta la retirada del software. Dentro de esas tareas la más importante es la de gestión de proyectos. Según Métrica-3: La gestión de proyectos tiene como finalidad principal la planificación, el seguimiento y control de las actividades y los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. Como consecuencia de este control es posible conocer en todo momento qué problemas se producen y resolverlos o paliarlos de manera inmediata. Siguiendo con los criterios formulados por Métrica-3, la gestión de proyectos implica la realización de una serie de actividades, a agrupar en tres bloques temporales del desarrollo: Actividades de Inicio del Proyecto. Una vez contrastada la viabilidad del proyecto, se realizarán las estimaciones de esfuerzo y la planificación del desarrollo. Actividades de Seguimiento y Control. En un mayor nivel de concreción se asignan tareas al equipo del proyecto y se establecen los mecanismos oportunos para tener control sobre cualquier posible eventualidad que

2 pueda surgir durante el desarrollo, intentando, además, garantizar la calidad interna y externa del software. Estas actividades abarcan desde el comienzo de la fase de análisis hasta la de mantenimiento. Actividades de Finalización del Proyecto. Al cerrar el proyecto se registra la documentación de gestión del mismo. 2. Planificación La planificación de un proyecto implica la definición y preparación de las condiciones de trabajo, estableciendo recursos, fechas y costes con el fin de lograr los objetivos planteados. Esta actividad implica las siguientes tareas: Selección de la estrategia de desarrollo. Implica la elección del Modelo de Ciclo de Vida más apropiado, así como la adecuación del MCV elegido al proyecto concreto. Selección de la estructura de actividades, tareas y productos. Se subdivide el proyecto de forma modular, buscando no sólo una óptima asignación de recursos, sino un control eficaz de cada una de las tareas resultantes de la división. Se intenta relacionar cada módulo de la estructura con un producto, de forma que los objetivos a fijar sean lo más concretos posible. Es importante en esta fase ver cómo se relacionan tiempo cronológico con esfuerzo humano, de cara a buscar paralelismos en el desempeño de tareas, teniendo en cuenta dos grandes premisas: Personas y tiempo no son intercambiables. Cuanto más paralelismo menos duración. Establecimiento del calendario de hitos y entregas. Se fijan las fechas de entrega de los módulos del proyecto, de los productos a desarrollar por terceros, así como las condiciones derivadas de la necesidad de finalizar una tarea para poder comenzar con otras, etc. Habrá de tenerse en cuenta, entre otras cosas, la disponibilidad de recursos. Planificación detallada de actividades y recursos necesarios. Es una concreción del punto anterior, centrándonos en los recursos individuales con que se cuenta y asignándoles tareas en función de su perfil y disponibilidad. De esa forma se calculará con exactitud el patrón de costes del proyecto Arturo Mora Rioja 2

3 En este punto se suele utilizar como referencia información histórica de proyectos similares realizados con anterioridad, y también modelos como los siguientes: Regla Se estima que el 40% del tiempo del proyecto se dedicará a análisis y diseño, el 20% a programación y el 40% restante a pruebas e implantación. Regla 3 veces programación. El esfuerzo total de desarrollo del proyecto es 3 veces el esfuerzo destinado a la fase de programación. Regla del ciclo de vida. Se estiman los siguientes porcentajes de tiempo: 10% Estudio de viabilidad del sistema 17% Planificación y educción de requisitos 15% Diseño general 15% Diseño detallado 33% Programación 10% Pruebas e implantación Presentación y aceptación de la planificación general del proyecto. Tras representar gráficamente la planificación escogida, es necesario contar con la aprobación de los superiores sobre la planificación realizada, siendo este un requisito indispensable para la continuidad del proyecto. Es aquí donde se utilizan los métodos de planificación temporal históricamente más extendidos: PERT/CPM. Técnica de evaluación y revisión de programas / método del camino crítico. Diagrama de Gantt. Representación de la agenda del proyecto. WBS. Estructura de descomposición de trabajos. Útil para planificar costes. 3. Estimación Aparte de los indispensables criterios técnicos que siempre hay que tener claros de cara a un desarrollo software, nunca debemos olvidar los criterios económicos, sin los cuales ningún desarrollo sería posible. Dichos criterios van de la mano de los aspectos técnicos ya desde los albores del proyecto, al realizar el estudio de viabilidad del sistema (viabilidad técnica y económica). Una vez se decide seguir adelante con el proyecto, y como fuente de información para la planificación del sistema, se ha de realizar una serie de estimaciones, es decir, medidas sobre distintos aspectos que influirán de cara al futuro desarrollo Arturo Mora Rioja 3

4 Concretando, cuando hablamos de estimación en un desarrollo software, generalmente nos centramos en estimación del esfuerzo, actividad cuyo objetivo es conocer el tamaño aproximado del sistema a desarrollar, y establecer el coste, la duración y los recursos necesarios para su consecución. Para realizar una buena estimación primero hay que tener muy claro cuáles son los elementos a desarrollar. Una vez conocidos se aplicarán una serie de técnicas mediante las cuáles se medirá el tamaño del proyecto. Dicha medición se realiza en líneas de código (LDC) o en puntos de función (PF). Una vez conocido dicho tamaño se podrá perfilar el tiempo que se tardará en desarrollarlo, los recursos necesarios y, en definitiva, el coste asociado al desarrollo. Dichas técnicas, basadas a veces en cálculos matemáticos y otros en la experiencia previa, variarán en función del tipo de desarrollo (estructurado u orientado a objetos). 4. Criterios para la selección de hardware y software Nunca hay dos proyectos iguales. Por ese motivo la elección del hardware y software con que se trabajará, tanto por parte del cliente como del desarrollador, es una tarea crucial que depende de gran cantidad de factores económicos, técnicos, legales y operativos. La elección de la alternativa más adecuada viene precedida por el establecimiento del alcance del SI a desarrollar, el estudio de la situación actual y la definición de requisitos (es posible que ya dispongamos de parte de la solución a elegir), el estudio y evaluación de alternativas posibles y, finalmente, la elección deseada. Todos estos elementos han desembocado en una clasificación de alternativas de elección tanto de software como de hardware, que vemos a continuación: Alternativas con respecto al software: Abordar un desarrollo propio. J Es lo que mejor se adapta a las necesidades de la organización. J Hay total control sobre el desarrollo. L Exige contar con recursos humanos cualificados. L La pelota está en nuestro tejado. Contratar a una empresa externa. J No se necesita disponer de plantilla permanente de personal de desarrollo informático Arturo Mora Rioja 4

5 J Las responsabilidades se encuentran en tejado ajeno. L Alto coste. L Se pierde control sobre el desarrollo. Comprar paquetes de software genéricos. J Es el coste más bajo posible. J Es la solución más rápida. L Es muy difícil encontrar un paquete que se adapte a nuestras necesidades. L Si se realiza una adaptación del paquete encontramos los problemas de contratar a una empresa externa, elevamos costes y perdemos rapidez. Alternativas con respecto al hardware: Comprar. Se hace cuando: o Hay presupuesto suficiente. o No se van a realizar cambios a corto plazo en la configuración del hardware. o La vida esperada del equipo es mayor al período de amortización (aproximadamente 3 años en PC s, 6 en equipos medios). o Los riesgos de obsolescencia son reducidos. Alquilar. Se hace en el resto de casos. Generalmente se puede tomar una opción intermedia, que es alquilar con opción a compra, cuando no se tiene muy claro qué hacer o hay un alto riesgo de necesidad de prescindir de los equipos en un momento dado. Una tercera alternativa es la compra de equipos usados. Es una opción poco utilizada. Generalmente se emplea cuando hemos de enfrentarnos a una ampliación temporal del sistema (campañas por estación, picos puntuales de trabajo, etc.). 5. Seguimiento y control de proyectos Las tareas popularmente más conocidas del jefe de proyecto son las relativas al seguimiento y control del desarrollo. El jefe de proyecto es quien se encarga de comprobar el cumplimiento de plazos, respuesta del equipo de desarrollo, calidad del software desarrollado, etc. Muy básicamente podemos centrarnos en dos grandes aspectos: 2005 Arturo Mora Rioja 5

6 Seguimiento de la planificación Una vez tenemos establecido un calendario de hitos y entregas, el jefe de proyecto ha de velar por el cumplimiento de las fechas propuestas, demostrando capacidad de adaptación en caso de que dichas fechas no puedan cumplirse. Para ello siempre tendrá actualizados sus Diagramas de Gantt. Ver Métrica 3 - Guía de técnicas y prácticas. Diagrama de Gantt (páginas ) Control de calidad Según la Real Academia de la Lengua, calidad es la propiedad o conjunto de propiedades inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las restantes cosas de su misma especie. Según ISO, es el conjunto de todas o aquellas propiedades y características de un producto o servicio que se refieren a su capacidad para satisfacer unas necesidades implícitas o explícitas, y según IEEE es el grado en el cual un cliente o usuario percibe que el software satisface sus expectativas. Las dificultades que se encuentran en un producto software son que: No es tangible. No se fabrica, se desarrolla. No se deteriora con el tiempo. Si tiene errores no se rechaza. La calidad no sólo está en el producto, sino en el proceso de desarrollo. Por esos motivos al hablar de software dividimos dos aspectos claros: Factores de calidad (calidad externa). Se refieren a la calidad del producto. Criterios de calidad (calidad interna). Se refieren a la calidad del proceso de desarrollo. Al igual que ocurría con las pruebas del software, la calidad externa ha de ser medida por un grupo de control de calidad ajeno al equipo de desarrollo del proyecto. En grandes empresas hay un Plan General de Garantía de Calidad que especifica las líneas a seguir en pro de la consecución de los factores de calidad deseados, especificándose posteriormente un plan específico de garantía de calidad para cada proyecto. En ese sentido es interesante la aproximación de pruebas estáticas, que son aquellas que se realizan sobre productos que no son ficheros ejecutables, es decir, sobre la documentación del proyecto. Cabe destacar en este apartado las auditorías, las revisiones y las verificaciones formales Arturo Mora Rioja 6

7 En cuanto a la calidad interna, ésta va a venir dada por las pruebas de aplicación, si bien la garantía de calidad va a nutrirse también de uno de los aspectos más importantes del desarrollo de software: el control de versiones. Dependiendo del ciclo de vida y metodología empleadas, podemos encontrarnos con un sinfín de fases claramente diferenciadas durante el desarrollo de un proyecto. Al final de cada fase podemos encontrar un estado del producto software (o de partes de él) que esté lo suficientemente probado como para darlo por definitivo. No obstante, avances posteriores, lecturas detalladas de las especificaciones o simples efectos laterales pueden ocasionar la revisión de dicho producto software, con el consiguiente descontrol y efecto dominó. Es importantísimo, por tanto, guardar cada versión del producto software para, en un momento dado, poder volver a ella, o bien tener un histórico de evolución del proyecto en el que basarse para cambios posteriores. Estamos hablando ya de las labores de control del proyecto, que la mayoría de autores incluyen dentro de la gestión del mismo. No sólo se debe guardar cada una de las versiones, sino además documentarla adecuadamente. Bibliografía: Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información Métrica-3 (Consejo Superior de Informática y para el impulso de la Administración Electrónica Ministerio de Administraciones Públicas) Apuntes propios ( ) 2005 Arturo Mora Rioja 7