TypeCiclo de Vida de un Proyecto.
Cada vez son más las organizaciones grandes y pequeñas que están adoptando un ciclo de vida uniforme y único para sus proyectos. Esto muchas veces se conoce como el plan del proyecto o metodología del desarrollo del sistema. El manual del ciclo de vida del proyecto suele ser un libro tan voluminoso como el compendio de normas. Este manual ofrece un procedimiento común a seguir para desarrollar un sistema que puede orientar a cualquier miembro de la organización de desarrollo de sistemas.
El enfoque puede ser casero o también la organización para el desarrollo de sistemas puede comprar un paquete de administración de proyectos y ajustarlo a las necesidades de la compañía. Además de dar empleo a personas que crean manuales de ciclo de vida de proyectos, es conveniente la metodología del proyecto. ¿De qué sirve entonces tener un ciclo de vida de un proyecto? Existen tres objetivos principales:
1. Definir las actividades a llevarse a cabo en un proyecto de desarrollo de sistemas.
2. Lograr congruencia entre la multitud de proyectos de desarrollo de sistemas en una misma organización.
3. Proporcionar puntos de control y revisión administrativos de las decisiones sobre continuar o no con un proyecto.
La ayuda que proporciona el ciclo de vida del proyecto es que puede organizar las actividades del administrador, aumentando la probabilidad de que se traten los problemas pertinentes en el momento adecuado.

Bullet1.gif El Ciclo de Vida de un Proyecto Clásico.
Cada proyecto atraviesa por algún tipo de análisis, diseño e implantación. El ciclo de vida de proyecto utilizado puede diferir del que muestra la ilustración en una, varias o todas las siguientes maneras:
Las fases de exploración y análisis pueden juntarse en una sola (sobre todo sí se considera factible desde el inicio cualquier cosa que quiera el usuario).
Puede o no haber fase de estudio de hardware si se cree que cualquier sistema nuevo puede instalarse con las computadoras existentes.
Las fases de diseño preliminar y de diseño de detalles podrían juntarse en una sola llamada simplemente diseño.
Diversas fases de pruebas podrían juntarse en una sola de hecho podrían incluirse con la codificación.


Implantación Ascendente.
El uso de la implantación ascendente es una de las grandes debilidades de los ciclos de vida de los proyectos clásicos. Se espera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas de subsistemas y finalmente las pruebas del sistema mismo, conocido como ciclo de vida en cascada. Una de las dificultades de esta implantación es que la eliminación de fallas suele ser extremadamente difícil durante las ultimas etapas de prueba del sistema.
Bullet7.gif Progresión Secuencial.
La segunda debilidad del ciclo de vida de un proyecto clásico es su insistencia en que sus fases se sucedan secuencialmente. Esto es una tendencia natural, el problema que trae consigo este progreso ordenado es que no permite el tratamiento de fenómenos reales como los relacionados con el personal, la política de la economía o la economía.

Bullet1.gif El Ciclo de Vida Semiestructurado.
Desde fines de los 70 crece la tendencia a reconocer el diseño estructurado, la programación estructurada y la implantación descendente como parte del ciclo de vida del proyecto.
Se muestran dos detalles no presentes en el enfoque clásico:
La secuencia ascendente de codificación, la prueba de módulos y del sistema se reemplazan por una implantación de arriba hacia abajo, que es un enfoque en el cual los módulos de alto nivel se codifican y prueban primero, seguidos por los de bajo nivel más detallados.
El diseño clásico se reemplaza por el diseño estructurado, que es un es un enfoque de diseño formal de sistemas.
La implantación descendente ofrece retroalimentación entre el proceso de implementación y el de análisis.
Gran parte del trabajo que se realiza bajo el nombre de 'diseño estructurado' es un esfuerzo manual para enmendar especificaciones erróneas.
Para quienes realizan el diseño estructurado como primer tarea es transformar la especificación en un paquete de diagramas de flujo de datos, diccionario de datos, diagramas de entidad - relación y las especificaciones del proceso.

Bullet1.gif Ciclo de Vida Estructurado del Proyecto.
Examinaremos aquí las nueve actividades y los tres terminadores de este ciclo de proyecto.
Los terminadores (usuarios, administradores y personal de operaciones) representan a individuos o grupos que proporcionan las entradas al equipo de trabajo y son los beneficiarios finales del sistema, ellos interactúan con las nueve actividades.

Aclaraciones.
Nada indica que la actividad N debe concluir antes que comience la N+1, pueden llevarse acabo diversas actividades en forma paralela, con la suficiente cordura de paralelismo (Ej. No realizar encuesta y codificación al mismo tiempo).
Prácticamente todas las actividades pueden y suelen producir información que pueden llevar a modificaciones adecuadas de una o más actividades precedentes.
Síntesis de las actividades:

Bullet2.gif Actividad 1. La Encuesta.
Comienza cuando el usuario solicita que una o más partes de su sistema se automaticen, o se modifiquen. Los principales objetivos son:
Identificar a los usuarios responsables y crear un 'campo de actividad' inicial del sistema. Esto puede comprender una serie de entrevistas para determinar usuarios involucrados en el proyecto.
Identificar deficiencias actuales en el ambiente del usuario. Como que el hardware del sistema actual no es confiable; el software no se puede mantener, o no es conveniente.
Preparar el esquema que se usará para guiar el proyecto.

Bullet2.gif Actividad 2. El Análisis de Sistemas.
El propósito de esta actividad es transformar sus entradas principales, políticas del usuario y esquema del proyecto en una especificación estructurada. Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagrama de entidad - relación, diagramas de transición de estados y otras herramientas.
Bullet2.gif Actividad 3. El Diseño.
Esta actividad se dedica a la creación de una jerarquía apropiada de módulos de programas y de interfaces entre ellos para implantar la especificación creada en la actividad de análisis. Además transforma el modelo de datos de entidad - relación en un diseño de base de datos.
Bullet2.gif Actividad 4. Implantación.
Incluye la codificación y la integración de módulos en un esqueleto progresivamente más completo del sistema final. Incluye tanto programación como implantación descendente.
Bullet2.gif Actividad 5. Generación de Pruebas de Aceptación.
Una vez generada la especificación, puede comenzar la actividad de producir un conjunto de casos d pruebas de aceptación desde la especificación estructurada.
Bullet2.gif Actividad 6. Garantía de Calidad.
También llamada prueba final o prueba de aceptación. Requiere como entrada los datos de prueba de aceptación generada en la actividad 5 y el sistema integrado producido en la actividad 4.
Bullet2.gif Actividad 7. Descripción del Procedimiento.
Una de las actividades importantes es la generación de una descripción formal de las partes del sistema que se harán en forma manual, lo mismo que la descripción de cómo interactúan los usuarios con la parte automatizada del nuevo sistema. El resultado de esta actividad es un manual para el usuario.
Bullet2.gif Actividad 8. Conversión de la Base de Datos.
En algunos proyectos la conversión de la base de datos involucra más trabajo y más planeación estratégica que el desarrollo de programas del nuevo sistema. En otros casos puede no existir una base de datos que convertir. En general esta actividad requiere como entrada la base de datos actual del usuario, al igual que la actividad de diseño producida por la actividad 3.
Bullet2.gif Actividad 9. Instalación.
Esta es la actividad final, sus entradas son el manual del usuario producido en la actividad 7, la base de datos convertida que se creó con la actividad 8 y el sistema aceptado producido por la actividad 6. En algunos casos la instalación podrá ser total; pero también puede ser un proceso gradual, en el que un grupo tras otro de usuarios van recibiendo manuales y entrenamiento y comenzando a usar el nuevo sistema.
Bullet1.gifEl Ciclo de Vida de Prototipos.
Es una variación del enfoque descendente, consiste en capturar un conjunto inicial de necesidades e implantarlas rápidamente con la intención declarada de expandirlas y refinarlas iterativamente al ir aumentando la comprensión que del sistema tiene el usuario y quien lo desarrolla; también llamado desarrollo heurístico.
La diferencia con el modelo estructurado supone se construirá un modelo completo del sistema que deberán mantenerse siempre con el sistema, a lo largo de su corrección y mantenimiento.
El de prototipos casi siempre supone que el sistema será operante, es decir un conjunto de programas que simularán algunas o todas las funciones que el usuario desea. Como se supone que son programas modelos, al concluir el modelado se descartan y se reemplazan por los reales.
Para realizar prototipos se requieren las siguientes herramientas:

Bullet2.gif Un diccionario de datos integrado.
Bullet2.gif Un generador de pantallas.
Bullet2.gif Un generador de reportes no guiado por procedimientos.
Bullet2.gif Un lenguaje de programación de cuarta generación.
Bullet2.gif Un lenguaje de consultas no guiado por procedimientos.
Bullet2.gif Medios poderosos de administración de bases de datos.
El ciclo comienza con un sondeo de si el proyecto es un buen candidato para el enfoque de prototipos, lo serán si tienen algunas de las siguientes características:
El usuario no puede o no está dispuesto a examinar modelos como el diagrama de flujo de datos.
El usuario no puede especificar sus requerimientos, solo se pueden determinar mediante un proceso de tanteo.
in the content of your page here.