1.1. LA GESTIÓN DEL CICLO DE VIDA DE UN PROYECTO
El presente esquema recoge las fases de las que se compone el Ciclo de Vida de un Proyecto: Definición, Planificación, Control y Seguimiento y Finalización.
El proyecto comienza con una definición que incluye la elaboración de la oferta y la especificación de requisitos, cuando se ha aprobado la oferta, se procede a la contratación y lanzamiento del proyecto, entonces se planifica y posteriormente se pasa a la ejecución que habrá que supervisar para que no se produzcan desviaciones con respecto al Baseline o para replanificarlo en caso de que sea necesario establecer un nuevo Baseline debido a que las condiciones iniciales planificadas (objetivos, plazos, presupuestos) hayan variado tanto que no sirvan como referentes. La última fase es la finalización.
La presente metodología abarca todas las fases del Ciclo de Vida del Proyecto facilitando la gestión de las mismas. A continuación se realiza una descripción más extensa de los aspectos a tener en cuenta en cada una de las fases:
1.1.1. INICIO
El Inicio es la primera etapa del Ciclo de Vida del proyecto. Se materializa elaborando la oferta y determinando los requisitos del producto/servicio que ofreceremos al cliente para su aceptación. Ambos elementos, oferta y requisitos, constituyen una presentación de la empresa y el proyecto al cliente, con el que nos comprometeremos, proporcionando una imagen de nosotros mismos, que trataremos que sea lo más positiva posible.
Por otro lado la labor de definición del proyecto nos permite conocer la disponibilidad de recursos para el desarrollo del mismo y por lo tanto nuestras limitaciones en ese aspecto a la vez que nos da la posibilidad de prevenir errores.
La definición del proyecto no sólo ha de responder a las tres preguntas fundamentales: QUÉ, CUÁNDO y CUÁNTO sino que ha de encontrar el equilibrio entre los parámetros que estas implican: ASPECTOS TÉCNICOS, TIEMPO DE EJECUCIÓN y COSTE respectivamente.
En cuanto al QUÉ (aspectos técnicos), la definición a de recoger las necesidades del cliente y determinar los requisitos del producto/servicio. El CUÁNDO (tiempo de ejecución) reflejará las principales fases del proyecto, la estimación de las horas y plazo de ejecución y el CUÁNTO (coste) recogerá el presupuesto final del proyecto que será la suma del coste, los riesgos y el margen de beneficio.
Es imprescindible, para eliminar posibles riesgos, realizar una revisión de la definición tanto de los aspectos técnicos como de los económicos (precio de venta, condiciones de aceptación y forma de pago). Además es conveniente realizar otras revisiones como: revisión de conformidad con el sistema de calidad, jurídica para cubrir posibles riesgos derivados del proyecto y revisión de tipo administrativo (justificaciones a la administración, previsión de inversiones, etc.)
En este sentido, la metodología contiene los estándares para la elaboración de las ofertas y determinación de los requisitos contemplando los aspectos anteriormente comentados, así como los mecanismos correspondientes para el control de acuerdo con sistema de calidad.
1.1.2. PLANIFICACIÓN DE UN PROYECTO
Tras la aceptación de la oferta y lanzamiento del proyecto se pasa a la fase de planificación que consiste en transformar el modelo teórico presentado en la oferta en un plan de acción aplicable que recoja: lo que hay que hacer, en el orden necesario y con los medios de que se dispone para alcanzar los objetivos tanto de costes como de plazos.
Acciones a realizar en la planificación de proyectos.
- Identificación de Actividades o Tareas.- Desglosar el trabajo a realizar tratando de no mezclar lo accesorio con lo importante y cuidando el nivel de detalle. Que todo el trabajo a realizar pueda imputarse a alguna tarea.
- Secuenciación de Actividades.- Determinación de actividades paralelas, interdependencias, retrasos.
- Estimación de la duración/esfuerzo de las Actividades.- Por parte del responsable de la realización de esa tarea y revisada por el Director del Proyecto
- Estimación de las necesidades de recursos.- Cada recurso de un proyecto debe de ir asignado a una o varias actividades e incluso de forma simultanea siempre que no sobrepase la dedicación del 100%.
- Estimación de los costes de las Actividades.
- Representación gráfica del flujo de Actividades.- Mediante un Diagrama Gantt.
- Optimización de la planificación.- Una vez finalizada la planificación y antes de poner en marcha el proyecto, es necesario revisar y optimizar el plan mediante la reducción, si es posible, de los siguientes aspectos:
§ Duración.- Modificando el camino, asignando más recursos, trabajo en horas extras, etc.
§ Sobreasignación.- Cambiando la asignación de tareas al recurso, modificando la secuencia de tareas, aumentando las horas de trabajo del recurso en su calendario laboral, reasignación automática, etc.
§ Costes.- Remplazando recursos caros por otros menos costosos, eliminando tareas de baja prioridad, revisando la duración y esfuerzo de las tareas, etc.
Todos los aspectos anteriormente señalados se recogen mediante distintos elementos, como la ficha de proyecto, el plan de desarrollo del proyecto, etc. que se integran para posibilitar no solo la planificación sino también la supervisión y control tanto técnico como económico del proyecto.
1.1.3. CONTROL Y SEGUIMIENTO DE UN PROYECTO
Las mayores desviaciones que se producen en un proyecto son debidas a deficiencias en el control del mismo. Para asegurar la eficacia de la ejecución es necesario que el director de proyecto realice un buen seguimiento:
- Seguimiento técnico.- Controlando el avance de las tareas, esto es, lo realmente conseguido, que será mucho más fiable si se calcula en función de estimaciones de las tareas individuales.
- Seguimiento económico.- De las horas invertidas, compras o pedidos realizados, subcontrataciones, viajes y otros gastos de forma que la suma de todo ello no supere el crédito asignado para completar el proyecto.
Estas son algunas acciones a llevar a cabo para realizar un adecuado Proceso de Control y Seguimiento de un Proyecto:
- Recoger datos.- La información es la principal herramienta de que dispone el director de proyectos para mantenerse alejado de los problemas. Existen varias formas de recogerla: informes (Informes de tarea), reuniones (Internas o Externas), de otros departamentos (Administración, Finanzas, etc.), etc.
- Análizar Datos referentes al esfuerzo, costes, plazos y avances intermedios.
§ ESFUERZO (horas empleadas por recurso y tarea)
§ COSTES y PLAZOS (duraciones, fechas de inicio y fin, márgenes)
§ AVANCES INTERMEDIOS
- Sacar conclusiones comparando los datos reales con los planificados.
- Informar.- Es tarea del director de proyecto elaborar los informes de seguimiento de forma periódica, puntual, concisa e impersonal y presentar propuestas de soluciones en el caso de producirse desviaciones. Estos informes deben de ser analizados por el supervisor que deberá sacar conclusiones y tomar medidas. Es conveniente que los informes tengan un formato fijo, que evite la tentación de seleccionar su contenido.
- Tomar medidas asegurándose de que la decisión se puede justificar con datos.- Teniendo en cuenta las aportaciones de la gente más afectada por la decisión, fijando prioridades y alternativas (criterios de ejecución, tiempos, costes) y comunicando las decisiones con tacto y consideración.
- Replanificación.- En caso de ser necesario realizar una replanificación del proyecto efectuando los cambios que sean necesarios e integrarlos de nuevo en todo el sistema de gestión de proyectos.
1.1.4. CIERRE DE UN PROYECTO
Una buena finalización del proyecto requiere realizar una serie de tareas para las que se recomienda reservar tiempo en la planificación. Estas tareas son las siguientes;
- La actualización de datos.- Tanto técnicos como de gestión para incorporar las últimas modificaciones al trabajo desarrollado.
- Revisar toda la documentación del proyecto.- Eliminar la documentación inútil y organizarla, de forma que sirva para:
§ Dar un buen soporte de garantía o mantenimiento.
§ Realizar modificaciones o ampliaciones del producto entregado.
§ Aprovechar aspectos técnicos para otros proyectos de la empresa.
§ Apoyar la planificación y estimación otros proyectos de la empresa.
- Realización de copia de seguridad de toda la información que se encuentre en el ordenador.- La realización de la memoria o informe de conclusiones
- El archivo del proyecto.- Así no queda ligado a una o varias personas que son las que tienen en su cabeza el trabajo realizado sino que toda la información estará disponible para el resto de la empresa.
La finalización del proyecto también implica la realización de las tareas correspondientes para modificar su estado dentro del sistema de activo a cerrado, así como su archivo tanto físico como en la gestión documental que soporta el sistema.
1.2. ADMINISTRACIÓN DE PROYECTOS
1.2.1. INTRODUCCIÓN A LA ADMINISTRACION DE PROYECTOS
1.2.1.1. SIGNIFICADO DE ADMINISTRACION DE PROYECTOS
La administración de proyectos consiste en gestionar la producción de un producto dentro del tiempo dado y los limites de fondos. Como esto requiere recursos humanos, la administración del proyecto involucra no solo la organización técnica y las habilidades organizacionales, sino también el arte de administrar personas. La administración de proyectos no es una actividad insignificante m pueden ser tan emocionante como aterrizar un jet jumbo en una pista corta.
1.2.1.2. LOS COMPONENTES DE LA ADMINISTRACIÓN DE PROYECTOS
La administración de proyectos comprende
Ø Estructura (elementos organizacionales involucrados)
Ø Proceso administrativo (responsabilidades y supervisión de los participantes)
Ø Proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo.
Ø Programa (tiempos en los que se deben realizarse las porciones del trabajo)
1.2.1.3. VARIABLES PRINCIPALES. COSTO, CAPACIDAD, CALIDAD Y PROGRAMA
Quienes planean los proyectos pueden varios costos, calidad y fecha de entrega como muestra la figura 1. El grado en el que estos cuatro factores pueden controlarse depende del proyecto. Aunque con frecuencias los costos pueden estar fijos de antemano, muchas veces hay cierta flexibilidad. Por ejemplo, suponga que el cliente es un químico que necesita una visualización molecular en 2D. Después de ver el prototipo de 3D se ve mucho mejor que el de 2D. Las capacidades tampoco son entidades fijas que parecen, Por ejemplo, el cliente puede estar de acuerdo con eliminar un requerimiento si hacerlo disminuye 15% la duración del proyecto (un trueque entre capacidades y programa). Aunque puede parecer poco ortodoxo, incluso las metas de calidad pueden variar. Cuando las metas de calidad se establecen demasiado bajas, se crea un desequilibrio en los costos a corto y largo plazo debido al retrabajo e insatisfacción del cliente. Cuando las metas de calidad son demasiado altas el costo de encontrar hasta el detalle más pequeño puede ser prohibitivo. La mayor parte de las personas no estarían dispuestas a pagar tres veces el precio por un procesador de palabra con el fin de tener una versión sin un defecto trivial reconocido. En ocasiones se pueden negociar las fechas de terminación. Por ejemplo, un gerente puede estar dispuesto a cambiar una fecha de entrega si el producto resultante tiene tantas capacidades que es probable que capte el mercado.
Una manera de visualizar estas cuatro variables es mediante el uso de un diagrama "polar". En este tipo de diagrama, cada una de las variables se grafica en un eje que se origina en el centro. Los ejes se dibujan simétricos entre si. En particular, el diagrama polar de la figura 1 contiene cuatro variables, de manera que los ejes están a ángulos rectos. En cada uno de estos ejes, el origen es el valor menos favorable, y el valor meta es el marcado en cada eje a la misma distancia del origen formando un cuadrilátero. (Si hubiera cinco variables, formarían un pentágono etc.) Por ejemplo, en el eje de capacidades, el origen denota "ningún requerimiento satisfechos". Los valores reales suelen estar en algún lugar en medio, aunque podría haber valores fuera del polígono si exceden las metas, como se ve en la figura 2. El estado de un proyecto se puede visualizar como un polígono solido, uniendo los valores en los ejes y sombreando el interior. Cuanto más se coincida con el polígono regular original mayor será el logro de las metras del proyecto. El ejemplo mostrado se queda corto en la mayoría de las variables pero se desempeña bien en las metas de costo. Esta visualización ayuda al administrador del proyecto al alterar las prioridades para alcanzar las metas de forma más pareja. Por ejemplo, el líder del proyecto de la figura debe permitir mayor gasto para obtener la densidad de defectos requerida.
Para resumir, el administrador del proyecto maneja de firma constante el trueque entre costo, capacidades, calidad y fecha de terminación. Los administradores de proyectos profesionales cuantifican estos trueques lo más que pueden.
1.2.1.4. MAPA CONCEPTUAL TÍPICO DE UN PROCESO DE ADMINISTRACIÓN DE PROYECTOS
1.2.2. ADMINISTRACIÓN DEL PERSONAL DEL PROYECTO
1.2.2.1. PROFESIONALISMO
Este es uno de los temas del creciente profesionalismo de la ingeniería del software; pero, ¿qué significa con exactitud? Los profesionalitas tienen responsabilidades de sus empleadores y supervisores. Con el impacto tan grande del software en el mundo moderno, los ingenieros de software tienen que contraer cada vez más responsabilidades.
Las prácticas de los ingenieros de software en la planeación, programación, diseño, inspección y pruebas de los artefactos pasan por un escrutinio cada vez mayor dentro y fuera de la profesión.
1.2.2.2. IMPORTANCIA DE ADMINISTRAR A LAS PERSONAS
El ingrediente principal requerido para producir software es la gente. Las aptitudes técnicas de los ingenieros cuentan, por supuesto, pero deben aprovecharse en el problema adecuado, en el tiempo correcto. Esto requiere una combinación de trabajo en equipo y liderazgo. La meta de esta sección es familiarizarlo con los aspectos comunes de personal. Esto aspectos analizarán desde varios puntos de vista: de la empresa que desea aplicación, de los administradores responsables de crearla de los ingenieros involucrados.
1.2.2.3. PERSPECTIVAS DE LA EMPRESA
Desde el punto de vista de la compañía que encomienda un proyecto, su desarrollo se ve como una contribución las metas de la empresa, producir un producto que justifique con creces su costo. Esta perspectiva es de negocios. El nombre mismo de la organización corporativa responsable del personal del proyecto ilustra esta perspectiva: “recursos humanos”, un tipo de recurso de la variedad de personas que apoya las metas de la organización.
1.2.2.4. PERSPECTIVAS DE LA ADMINISTRACIÓN
Se ha dicho que “no existen los errores técnicos, solo las fallas administrativas”. Aunque esto no es cierto en general, si nos recuerda la importancia de la administración para la terminación exitosa de las iniciativas de la ingeniería. El puesto de vista del administrador respecto a sus subordinados suele ser una mezcla de preocupación pro los negocios, por un lado, y un interés en las personas involucradas, por el otro. A pesar de las frecuentes inquietudes de los subordinados, el administrador promedio intenta que se haga el trabajo y al mismo tiempo trata de impulsar una fuerza de trabajo satisfecha. Esto va en el interés del administrador: los trabajadores descontentos no son productivos. Los administradores aseguran que los esfuerzos técnicos de los ingenieros vayan en la dirección adecuada. En especial los nuevos administradores encuentran difícil integral el hecho de dictar órdenes y permitir que los ingenieros hagan lo que crees más adecuado.
Los líderes de proyecto tienen diferentes grados de responsabilidad administrativa, dependiendo de la magnitud del proyecto.
1.2.2.5. PERSPECTIVAS DE LOS INGENIEROS
Por último considere los aspectos de “personas” que afectan al ingeniero de software típico. Los ingenieros desean trabajo interesante, quieren oportunidades para mostrar que son competentes, desean ser reconocidos y recompensados, y una relación cordial con sus compañeros de equipo. Un auto respeto sano es un prerrequisito para estos deseos. Una fuente importante de autoestima en el lugar de trabajo es la percepción de la calidad. No hay nada nuevo en esta observación.
1.2.3. IDENTIFICACIÓN Y RETIRO DEL RIESGO
1.2.3.1. DEFINICIÓN DE “RIESGOS”
Un riesgo es algo que puede ocurrir en el curso de un proyecto que, según el peor resultado, lo afectaría de manera negativa y significativa. Los factores que a la larga ocasionan que un proyecto fracase aparecen como riesgos cuando se reconocen con prontitud, y al reconocerlos tal vez pueda prevenirse el fracaso mediante la acción adecuada.
Existen dos tipos de riesgos.
Ø Riesgos que pueden evitarse o que se les puede sacar la vuelta (retirarlos)
Ø Riesgos que no pueden evitarse.
1.2.3.2. PANORAMA DE LA ADMINISTRACIÓN DEL RIESGO
Las aplicaciones muy similares a trabajos realizados con anterioridad por los mismos ingenieros de software pueden no tener riesgos; sin embargo, el universo de las aplicaciones de software es vasto y crece con rapidez. Muchos trabajos consisten en nuevas formas de realizar tareas, o son realizaciones de nuevas ideas. Por ello, es común que el desarrollo de aplicaciones de software incluya muchos riesgos.
Cada riesgo identificado debe ser bienvenido en el equipo del proyecto porque pueden comenzar a prevenirlo. Los problemas reales son los riesgos que no se han identificado. Estos son como minas en el campo que esperan explotar.
1.2.3.3. IDENTIFICACIÓN DE RIESGOS
La identificación de riesgos consiste en escribir todas las inquietudes o preocupaciones de quienes están relacionados con el proyecto, después presionar continuamente a los integrantes del equipo a pensar en más inquietudes. La identificación de riesgos requiere de una mentalidad escéptica similar a la requerida para la inspección, una búsqueda global de defectos en el plan de desarrollo. Las categorías de riesgos incluyen subestimación de tamaño del trabajo, cambios demasiados rápidos en los requerimientos, falta de habilidad para encontrar una implantación con suficiente eficiencia, deficiencias en las aptitudes del personal., un lapso grande para aprender a usar las herramientas y definiciones de los lenguajes.
1.2.3.4. RETIRO DE RIESGO
Retirar el riesgo es el proceso mediante el cual los riesgos se reducen o incluso se anulan. Existen dos maneras de retirar un riesgo. Una es hacer cambios en los requerimientos del proyecto para retirar (“evitar”) el aspecto que causa el riesgo. Otra manera es desarrollar técnicas y diseños que resuelvan el problema (“conquistar”, como manera de hablar). Cuando el equipo identifica un obstáculo para construir el paso, puede evitarlo si modifica la dirección o inicia de inmediato el trabajo de desarrollo para superarlo.
1.2.4. ELECCIÓN DE HERRAMIENTAS DE DESARROLLO Y SOPORTE
1.2.4.1. MÉTODOS DEL PROCESO
Debe tomarse una decisión en cuanto a que metodología de desarrollo o combinación de metodologías se usara. Las opciones de metodologías de casada, espiral, USDP y por incrementos.
1.2.4.2. HERRAMIENTAS
La ingeniería del software es un mercado sustancial. Un gran número de proveedores venden herramientas y entornos para ayudar a los ingenieros a desarrollar aplicaciones de software. Estas con frecuencias reciben el nombre de herramientas de ingeniería de software asistida por computadora.
1.2.4.3. DECISIONES DE CONSTRUIR O COMPRAR
Existe un número creciente de herramientas y aplicaciones en el mercado que prometen ayudar en, o formar la base para, nuevas aplicaciones. En general, estas decisiones se pueden retrasar gasta que se conocen los requerimientos, pero aquí se presentarán ya que son parte de la administración del proyecto-.
1.2.4.4. SELECCIÓN DEL LENGUAJE
Debe identificarse el lenguaje o lenguajes para el desarrollo casi al principio del proyecto. En ocasiones esta decisión es directa, como cuando una organización impone el lenguaje, o cuando el lenguaje es el único capaz de desarrollar requerimientos. Sin embargo, algunas veces deben elegirse varias alternativas para el desarrollo.
1.2.4.5. DOCUMENTACIÓN
Durante la etapa de la planeación, el equipo decide qué conjunto de documentación específico se producirá para el proyecto.
1.2.4.6. SERVICIOS DE APOYO
Los proyectos requieren apoyo para los administradores del sistema, de la red, de las bases de datos, los secretarios y otros. El administrador del proyecto debe asegurar que estas personas están disponibles.
1.3. ADMINISTRACIÓN DE PROYECTOS
La administración de proyectos asegura la entrega de un sistema de un sistema de calidad a tiempo y dentro del presupuesto. Los componentes principales de esta definición son calidad, tiempo y dinero. Para asegurar la entrega dentro del presupuesto se requiere que un gerente estime y asigne los recursos requeridos por el sistema desde el punto de vista de participantes, entrenamiento y herramientas. Para asegurar la entrega a tiempo se requiere que un gerente planee los esfuerzos de trabajo y supervise el estado del proyecto desde el punto de vista de tareas y productos de trabajo. Por último, para asegurar el control de calidad se requiere que un gerente de proyecto proporcione mecanismos para el reporte de problemas y supervise el estado del producto en cuanto a defectos y riesgos. Los tres aspectos del proyecto, calidad, presupuesto y tiempo, son esenciales y necesitan abordarse juntos para que el proyecto tenga éxito.
1.3.1. UN PANORAMA DE LA ADMINISTRACIÓN DE PROYECTOS.
La administración de proyectos tiene que ver con la planeación y asignación de recursos para asegurar la entrega de un sistema de software a tiempo y dentro del presupuesto. La administración de proyectos está sujeta a las mismas barreras que las actividades técnicas: complejidad y cambio.
Los modelos de administración nos permiten representar los recursos disponibles para el proyecto, las restricciones a las que están sujetos los recursos y las relaciones entre recursos. En este capítulo describimos los siguientes elementos:
Ø Los equipos representan conjuntos de participantes que trabajan en un problema común.
Ø Los papeles representan conjuntos de responsabilidades. Los papeles se usan para distribuir el trabajo a los participantes del equipo.
Ø Los productos de trabajo representan los productos a entregar e intermedios del proyecto. Los productos de trabajo son los resultados visibles del trabajo.
Ø Los calendarios representan la correspondencia entre un modelo de tareas y una línea de tiempo. Un calendario representa el trabajo desde el punto de vista de tiempo de calendario.
El gerente del proyecto y los lideres de equipo construyen y mantienen estos elementos del modelado a todo lo largo del desarrollo.
A nivel de abstracción más alto, el ciclo de vida del desarrollo puede descomponerse en tres fases principales: inicio del proyecto, durante el cual definen el alcance y recursos el proyecto, estado estable, durante el cual sucede la mayor parte del trabajo de desarrollo, y terminación del proyecto, durante la cual se entrega y acepta el sistema.
1.3.1.1. INICIO DEL PROYECTO
Durante esta fase el gerente del proyecto define el alcance del sistema junto con el cliente y construye la versión inicial del os modelos de administración. Al principio, solo están involucrados el gerente del proyecto, algunos líderes de equipo seleccionados y el cliente. El gerente del proyecto especifica el ambiente del proyecto, organiza los equipos, contrata participantes y arranca el proyecto. El inicio del proyecto incluye las siguientes actividades:
1.3.1.1.1. DEFINICIÓN DEL ENUNCIADO DEL PROBLEMA
Durante esta actividad el cliente y el gerente del proyecto definen el alcance del sistema desde el punto de vista de la funcionalidad, restricciones y productos a entregar. El cliente y el gerente del proyecto se ponen de acuerdo sobre los criterios de aceptación y fechas de destino.
1.3.1.1.2. DISEÑO INICIAL DE ALTO NIVEL
El gerente del proyecto y el arquitecto del sistema descomponen el sistema en subsistemas para efectos de la asignación de equipos. El gerente del proyecto define los equipos y productos de trabajo en función de los subsistemas. El arquitecto del sistema y los desarrolladores revisarán la descomposición en subsistemas durante el diseño del sistema.
1.3.1.1.3. FORMACIÓN DE EQUIPOS
El gerente del proyecto asigna un equipo a cada subsistema, define los equipos de funcionalidad cruzada y selecciona a los líderes de equipo. El gerente del proyecto y los líderes de equipo asignan juntos los papeles y responsabilidades a los participantes en función de las habilidades de éstos. Durante esta fase los líderes de equipo establecen las necesidades de entrenamiento para el equipo.
1.3.1.1.4. ESTABLECIMIENTO DE LA INFRAESTRUCTURA DE COMUNICACIÓN
El gerente del proyecto y los líderes de equipo establecen la infraestructura de comunicación del proyecto, incluyendo tableros de noticias, sitios web, herramientas para la administración de configuración, plantillas de documentos y procedimientos de reunión. Los participantes en el proyecto usarán esta infraestructura para la distribución de información y el reporte de problemas en forma ordenada.
1.3.1.1.5. PLANEACIÓN INICIAL DE INDICADORES DE AVANCE
El gerente del proyecto calendariza los productos de trabajo intermedios y los productos a entregar en forma extrema y los asigna a los equipos.
1.3.1.1.6. ARRANQUE DEL PROYECTO
El gerente del proyecto, los líderes de equipo y el cliente arrancan el proyecto en forma oficial. El propósito de las reuniones de arranque es explicar a los participantes el alcance del proyecto, la infraestructura de comunicación y las responsabilidades de cada equipo. Después del arranque el proyecto está en el estado estable.
1.3.1.1.7. TERMINACIÓN DEL PROYECTO
Durante esta fase se entrega el producto y se recopila la historia del proyecto. La mayor parte de la participación de los desarrolladores en el proyecto termina antes de esta fase. Unos cuantos desarrolladores principales, los escritores técnicos y los líderes de equipo se involucran del sistema para su instalación y aceptación, y recopilan la historia del proyecto para usarla en el futuro.
1.4. ADMINISTRACIÓN DE PROYECTOS
Es una combinación de muchas disciplinas que incorpora los procesos de comunicación, los ciencias de computación y administración, así como también las técnicas para la solución de problemas. Su objetivo principal es el mejoramiento de la productividad de todos los individuos involucrados en el desarrollo de software y la calidad de los sistemas de software.
1.4.1. COMPONENTES DE LA ADMINISTRACIÓN DE PROYECTOS
1.4.1.1. HABILIDADES CLAVE
Ø Liderazgo
Ø Comunicación
Ø Negociación
Ø Solución de problemas
Ø Lograr objetivos
1.4.1.2. CONOCIMIENTOS
Ø Técnicos
Ø Administrativos
Ø Herramientas
Ø Técnicas
1.4.2. ELEMENTOS RELACIONADOS CON EL PROYECTO
Ø Tiempo
Ø Calidad
Ø Alcance
Ø Entorno
Ø Recursos
Ø Costo
1.4.3. CICLO DE VIDA DEL PROYECTO
1.5. ADMINISTRACIÓN DE PROYECTO
La administración del proyecto no produce ningún artefacto por sí misma. En vez de ello, incluye las actividades de vigilancia que aseguran la entrega de un sistema de alta calidad a tiempo y dentro del presupuesto. Esto incluye la planeación y presupuestación del proyecto durante las negociaciones con el cliente, la contratación de desarrolladores y su organización en equipos, la vigilancia del estado del proyecto y las intervenciones cuando suceden desviaciones. La mayoría de las actividades de administración del proyecto que son visibles ante los desarrolladores y las técnicas que hacen más efectiva la comunicación entre el desarrollo y la administración.
1.6. CONCEPTO PERSONAL
La aplicación racional de conocimientos, habilidades, herramientas y técnicas para alcanzar los objetivos de un proyecto, a través de una serie de actividades interrelacionadas.
Son las actividades que permiten asegurar que el software se lleva a cabo a tiempo y de acuerdo con la planificación. Así como de acuerdo con los requerimientos de software.
Utilización eficiente de los recursos humanos y computacionales para el desarrollo de un proyecto.
