Introducción

Document Sample
Introducción Powered By Docstoc
					                                                                    Cátedra: Ingeniería del software
                                                                                         Nivel: 4to.
                                                                                  Dpto. de Sistemas

Ciclo de vida del proyecto

Al nivel de abstracción más alto, el ciclo de vida del proyecto se descompone en tres fases
principales: inicio del proyecto, durante el cual se definen el enlace y los recursos del proyecto,
estado estable, durante el cual se sucede la mayor parte del trabajo de desarrollo, y terminación
del proyecto, durante el cual se entrega y acepta el sistema.

Antes de describir cada una de estas fases, serán necesarios manejar los siguientes conceptos..
• Un equipo es un pequeño grupo de personas que trabajan sobre el mismo subproblema. El
concepto de equipo maneja la complejidad asociada con la comunicación entre muchas personas.
En vez de organizar y coordinar a los participantes del proyecto como un grupo grande, el proyecto
se divide en equipos donde cada uno ataca un subproblema separado.
• Un rol representa un conjunto de responsabilidades asignadas a un participante o a un equipo. La
definición clara de los papeles permite que se descubran y asignen con facilidad las tareas no
planeadas. El papel de un probador, por ejemplo, es diseñar y ejecutar pruebas. Si se identifican
nuevas actividades de pruebas no planeadas se asignan al participante que cumple el papel de
probador.
• Un producto de trabajo representa un producto entregable concreto producido por un papel. Los
productos de trabajo incluyen documentos técnicos y administrativos, características de productos,
casos de prueba, resultados de las pruebas, estudios de tecnología y reportes de usabilidad.
• Una tarea representa un producto de trabajo desde el punto de vista de una actividad. Una tarea da
como resultado uno o más productos de trabajo, está asignada a un papel y consume recursos. Las
tareas están relacionadas entre sí mediante dependencias. Por ejemplo, Planeación de pruebas de la
base de datos es la tarea de diseñar pruebas para el subsistema de base de datos. Requiere la interfaz
hacia el subsistema, y da como resultado un plan de pruebas y un paquete de pruebas a ejecutar
durante la Tarea de prueba de la base de datos.
• Una calendarización representa tareas asignadas en una línea de tiempo. La calendarización es,
por lo general, el más visible y evolutivo de todos los modelos de administración. La
calendarización se revisa cuando se refinan las estimaciones, cuando cambian las restricciones o
cuando se reasignan recursos.


Inicio del proyecto

El inicio del proyecto se enfoca en la definición del problema, la planeación de una solución y la
asignación de recursos. El inicio del proyecto da como resultado los siguientes productos de trabajo:
• El enunciado del problema es un documento corto que describe el problema que debe resolver el
sistema, el ambiente de destino, los productos a entregar al cliente y los criterios de aceptación. El
enunciado del problema es una descripción inicial, y es la semilla para el Acuerdo del proyecto, que
formaliza la comprensión común del proyecto por parte del cliente y la administración, y para la
SRS (Software Requirements Specification IEEE 830), que es una descripción precisa del sistema
que se está desarrollando.
• El diseño de alto nivel representa la descomposición inicial del sistema en subsistemas. Se usa
para asignar subsistemas a equipos individuales. El diseño de alto nivel también es la semilla para el
SDD (Software Design Description IEEE 1016), el documento de la arquitectura del software.
• La organización describe los equipos iniciales del proyecto, sus papeles y sus rutas de
comunicación. El plan inicial de tareas y la calendarización inicial son las descripciones iniciales
de la manera de asignar recursos. La organización, el plan inicial de tareas y la calendarización
inicial son las semillas para el SPMP (Software Project Management Plan IEEE 1058), que
documenta todos los aspectos administrativos del proyecto.

Unidad 1: Ciclo de Vida del proyecto                                                Página 1 de 7
                                                                    Cátedra: Ingeniería del software
                                                                                         Nivel: 4to.
                                                                                  Dpto. de Sistemas

Durante el inicio del proyecto la gerencia ensambla los equipos de acuerdo con el diseño de alto
nivel y las organizaciones seleccionadas, establecen la infraestructura de comunicación y luego
arranca el proyecto organizando la primera reunión. Una vez que se han asignado las tareas a todos
los participantes y se encuentran en su lugar los mecanismos de reporte, se considera que el
proyecto está en estado estable.

     PRODUCTOS DEL INICIO DEL                   PRODUCTOS A ENTREGAR
           PROYECTO

                                                          Acuerdo del
        Enunciado del                                      proyecto
          problema

                                                       Especificación de
        Diseño de alto                               Requisitos de Software
            nivel

                                                         Documento de
                                                       diseño del sistema
        Organización



        Plan inicial de                                Plan de Gestión de
            tareas                                    proyecto de Software




                      Calendarización




Desarrollo del enunciado del problema

El enunciado del problema lo desarrollan el gerente del proyecto y el cliente como una
comprensión mutua del problema a resolver con el sistema. El enunciado del problema describe la
situación actual, la funcionalidad que debe soportar y el ambiente en que se desplegará el sistema.
También define los productos a entregar que espera el cliente, junto con las fechas de entrega y un
conjunto de criterios de aceptación. El enunciado del problema también puede especificar
restricciones en el ambiente de desarrollo, como el lenguaje de programación a usar. El enunciado
del problema no es una especificación precisa o completa del sistema. En vez de ello, es un resumen
de alto nivel de dos documentos del proyecto que todavía no se desarrollan: el SRS y el SPMP.
El enunciado del problema lo desarrollan de manera iterativa el gerente del proyecto y el cliente. El
desarrollo del enunciado del problema es tanto una actividad de negociación como una de
recopilación de información, y durante éste ambas partes aprenden las expectativas y restricciones
de la otra. Aunque el enunciado del problema contiene una descripción de alto nivel de la
funcionalidad del sistema, también debe proporcionar ejemplos concretos para asegurar que ambas
partes comparten la misma visión.
El siguiente cuadro es un ejemplo de esquema para el enunciado del problema. La primera sección
describe el dominio del problema. La sección 2 proporciona escenarios de ejemplo que describen la
interacción entre los usuarios y el sistema para la funcionalidad esencial. Los escenarios se usan
para describir la situación actual y la futura.
Unidad 1: Ciclo de Vida del proyecto                                               Página 2 de 7
                                                                       Cátedra: Ingeniería del software
                                                                                            Nivel: 4to.
                                                                                     Dpto. de Sistemas

ENUNCIADO DEL PROBLEMA
1. Dominio del problema.
2. Escenarios.
3. Requerimientos funcionales.
4. Requerimientos no funcionales.
5. Ambiente de destino: descripción del ambiente de la organización, incluyendo la
plataforma, el ambiente físico, los usuarios, etc.
6. Productos a entregar y fechas de entrega.

Definición del diseño de alto nivel

El diseño de alto nivel describe la arquitectura de software del sistema. En una organización basada
en proyecto o equipo, el diseño de alto nivel se usa como base para la organización: cada
subsistema se asigna a un equipo y éste es responsable de su definición y realización. La
descomposición en subsistemas se refina y modifica más adelante durante el diseño del sistema. Sin
embargo, sólo necesitamos identificar los sistemas principales y sus servicios, y en este momento
no necesitamos definir sus interfaces. Los equipos que trabajan en subsistemas dependientes
negociarán los servicios individuales y sus interfaces conforme lo necesiten.

Identificación de las tareas iniciales

Los puntos iniciales para la identificación de tareas son el enunciado del problema (incluyendo los
productos a entregar y las fechas de entrega, el ciclo de vida de las actividades y la experiencia
pasada. El cliente y el gerente del proyecto acuerdan una serie de revisiones cuyo propósito es
revisar el avance del proyecto. Cada producto a entregar debe ser cubierto por una tarea, al menos.
La actividad de planeación identifica productos de trabajo adicionales para el consumo propio del
proyecto. Estos incluyen productos de trabajo administrativos, como el SPMP, productos de trabajo
para el desarrollo, como las definiciones de interfaz preliminares, prototipos rápidos y evaluaciones,
como las hojas de resumen de herramientas, métodos o procedimientos.
El trabajo se descompone al principio en tareas que son lo bastante pequeñas para que se estimen y
asignen a una sola persona. A esta descomposición inicial se le llama con frecuencia estructura de
división del trabajo (WBS, por sus siglas en inglés) y se parece a una gran lista de pendientes. Por
lo general, entre más específicos sean los requerimientos y los productos a entregar será más fácil
definir tareas precisas. Cuando los requerimientos no están bien definidos el gerente debe asignar
tiempo adicional para la replaneación y revisar el plan de tareas conforme se estabilizan los
requerimientos.

La estructura de la división del trabajo inicial no debe ser demasiado detallada. Muchos gerentes de
proyecto tienen una tendencia a crear listas de pendientes detalladas al inicio del proyecto. Aunque
es deseable un modelo detallado del trabajo, es difícil crear al principio una estructura de división
del trabajo detallada significativa. El refinamiento de la definición del sistema durante el análisis, y
del diseño de la arquitectura de software durante el diseño del sistema genera muchos cambios en la
estructura de la división del trabajo original, incluyendo nuevas tareas para investigar tecnología
reciente, nuevos subsistemas y funcionalidad adicional. La creación de una estructura de división
del trabajo detallada sólo da lugar a trabajo adicional cuando se revisa el plan. En vez de ello, un
gerente detalla la estructura de la división del trabajo sólo a corto plazo, y describe las tareas a largo
plazo con menor detalle. El gerente revisa y detalla la estructura de la división del trabajo sólo
conforme avanza el proyecto.

Identificación de las dependencias de tareas

Unidad 1: Ciclo de Vida del proyecto                                                   Página 3 de 7
                                                                      Cátedra: Ingeniería del software
                                                                                           Nivel: 4to.
                                                                                    Dpto. de Sistemas

Una vez que se han identificado las tareas necesitamos encontrar las dependencias entre ellas. La
identificación de dependencias nos permite asignar con más eficiencia los recursos a las tareas. Por
ejemplo, dos tareas independientes pueden asignarse a diferentes participantes para que las realicen
en paralelo. Encontramos dependencias entre tareas examinando los productos de trabajo que
requiere cada tarea. Por ejemplo, una tarea de prueba de unidad requiere la especificación de la
interfaz de programador de la unidad, generada por la tarea de diseño del sistema. La tarea de
diseño del sistema debe terminarse antes de que pueda iniciarse la tarea de prueba. El conjunto de
tareas y sus dependencias constituye el modelo de tareas. El siguiente paso es establecer la
correspondencia entre el modelo de tareas y los recursos y el tiempo para crear una calendarización.

Creación de la calendarización inicial

La calendarización inicial se crea estableciendo la correspondencia entre el modelo de tareas y el
tiempo y los recursos. Las dependencias entre las tareas, la duración estimada de las mismas y la
cantidad de participantes se usan para crear la calendarización inicial. La calendarización inicial se
usa para planear las fechas de las interacciones primarias con el cliente y los usuarios, incluyendo
las entrevistas con los usuarios, las revisiones del cliente y las entregas. Estas fechas se hacen parte
del enunciado del problema y representan fechas de entrega acordadas mutuamente entre el cliente
y el gerente del proyecto. Estas fechas se planean de tal forma que, aunque cambien, todavía
satisfagan los tiempos de entrega.

Así como sucede con el modelo de tareas, no es realista crear una calendarización detallada al inicio
del proyecto. La calendarización inicial debe incluir fechas de entrega para todos los productos que
se entregan al cliente y una calendarización detallada a corto plazo (por ejemplo, los dos primeros
meses). La calendarización detallada para el resto del proyecto se realiza conforme avanza el
mismo. Además, una vez que está en marcha el proyecto cada equipo puede contribuir a la
planeación de sus tareas, tomando en cuenta que tiene una visión más detallada del trabajo a
realizar. La calendarización general se realiza como parte de un compromiso continuo entre
recursos, tiempo y funcionalidad implementada, y se actualiza en forma constante.


Preparación de los equipos
El siguiente paso en el inicio del proyecto es armar los equipos que elaborarán los productos a
entregar. Pueden asignarse todos los desarrolladores que trabajarán en el proyecto de una vez
(contratación llana) o el proyecto puede crecer en forma gradual contratando personal conforme se
necesita (contratación gradual). Por un lado, la contratación gradual está motivada por el ahorro de
recursos en la primera parte del proyecto. La obtención de requerimientos y el análisis no requieren
tantas personas como la codificación y las pruebas. Además, analista e implementador son papeles
que requieren diferentes habilidades y, por lo tanto, deben asignarse a personas diferentes. Por otro
lado, la contratación llana tiene la ventaja del pronto establecimiento de los equipos y del ambiente
social necesario para la comunicación espontánea. Algunos de los desarrolladores pueden asignarse
a las actividades de análisis con los analistas, mientras que los demás pueden iniciar otras
actividades, como la especificación del ambiente de administración de la configuración,
investigaciones tecnológicas y evaluación y entrenamiento.
El gerente del proyecto asigna personal a los equipos examinando el diseño de alto nivel y
considerando las habilidades requeridas para cada subsistema. A menudo no se tienen disponibles
los suficientes desarrolladores con las habilidades necesarias, y en ese caso el gerente del proyecto
incluye tiempo en el modelo de tareas para el entrenamiento técnico del nuevo personal. El gerente
del proyecto distribuye al nuevo personal por todo el proyecto en forma tal que cada equipo tenga,
al menos, un desarrollador experimentado. El desarrollador experimentado proporciona el liderazgo

Unidad 1: Ciclo de Vida del proyecto                                                  Página 4 de 7
                                                                     Cátedra: Ingeniería del software
                                                                                             Nivel: 4to.
                                                                                    Dpto. de Sistemas
técnico y sirve como mentor para los nuevos desarrolladores quienes obtienen experiencia más
rápido cuando ponen en práctica su nuevo entrenamiento. El entrenamiento formal y el aprendizaje
por la práctica es un compromiso que evalúa el gerente del proyecto tomando en cuenta las
restricciones de tiempo del proyecto. El entrenamiento formal permite que los desarrolladores
lleguen más pronto a ser más productivos, pero es caro y constituye una inversión a más largo plazo
que beneficia a los proyectos futuros.
El gerente del proyecto selecciona a los líderes de equipo antes de que se formen los equipos.
Además de poder comprender el estado del equipo, el líder del mismo necesita poder comunicarse
de manera efectiva, reconocer crisis pendientes (sociales o técnicas) y resolver compromisos
tomando en cuenta los asuntos en el nivel de proyecto. El inicio del proyecto también es un
momento ideal para el entrenamiento de los líderes de equipo, para que se familiaricen con los
procedimientos y las reglas básicas del proyecto. El papel de líder de equipo es distinto al de líder
técnico.

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, sitios web, herramientas para las administración de la 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.


Arranque del proyecto

La reunión de arranque del proyecto marca el final de la fase de inicio del proyecto y el principio de
la fase de desarrollo. El gerente del proyecto ha terminado gran parte de la planeación inicial y el
diseño de alto nivel, ha seleccionado una organización, ha contratado desarrolladores y ha
designado a los líderes de equipo. El arranque del proyecto consta de tres reuniones.
• La presentación al cliente. En esta reunión están incluidos todos los participantes en el proyecto.
Incluye una presentación, por parte del cliente, de los requerimientos del sistema, y una
presentación, por parte del gerente, de la organización y calendarización iniciales.
• La reunión de arranque de la administración. El gerente del proyecto organiza esta reunión que
incluye a todos los líderes de equipo. La reunión sirve para definir los procedimientos
administrativos, como los procedimientos de reunión, la administración de la configuración y el
reporte de problemas, y dar entrenamiento sobre ellos.
• Reuniones de arranque de equipos individuales. Estas reuniones las organizan los líderes de
equipo e incluyen a los miembros del equipo. A los participantes se les comunican los proce-
dimientos definidos durante la reunión de administración. Se presentan entre sí los miembros del
equipo. Aquí es donde comienza el involucramiento del líder del equipo.
El objetivo de las tres reuniones de arranque es que los participantes se conozcan y que se inicie la
comunicación. Los participantes se familiarizan con los procedimientos de reunión básicos, la
organización y la asignación de papeles y los mecanismos generales del proyecto. Poco después se
distribuyen las tareas y se realizan las reuniones de estado normales. Después de unas cuantas
reuniones de estado los aspectos calendarizados de la comunicación ya deben estar bien cimentados.
Luego describimos las actividades de supervisión del proyecto durante el estado estable. Las
actividades de administración durante el estado estable se enfocan sobre todo en eventos
inesperados y planes de contingencia.


Estado estable


Unidad 1: Ciclo de Vida del proyecto                                                 Página 5 de 7
                                                                      Cátedra: Ingeniería del software
                                                                                              Nivel: 4to.
                                                                                       Dpto. de Sistemas
Durante esta fase llega a ser crítico el papel del líder de equipo. Durante el inicio del proyecto la
mayoría de las decisiones las toma el gerente del proyecto. Durante el estado estable los líderes de
equipo son responsables del seguimiento del estado de su equipo y de la identificación de
problemas mediante reuniones del equipo. Los líderes de equipo reportan el estado de su equipo al
gerente del proyecto, el cual luego evalúa el estado de todo el proyecto. Los líderes de equipo
responden a las desviaciones del plan reasignando tareas a los desarrolladores u obteniendo recursos
adicionales del gerente del proyecto. El gerente del proyecto todavía es responsable de la
interacción con el cliente, obteniendo el acuerdo formal y renegociando recursos y fechas límite.
Las actividades del estado estable incluyen las siguientes:

• Definición del acuerdo del proyecto. Una vez que está estable el modelo de análisis, el cliente y
  el gerente del proyecto acuerdan de manera formal el alcance del sistema y la fecha de entrega. El
  documento Acuerdo del proyecto se deriva del enunciado del problema y se revisa durante el
  análisis. El Acuerdo del proyecto define de manera formal el alcance, la duración, el costo y los
  productos a entregar del proyecto. La forma del Acuerdo del proyecto puede ser un contrato, una
  declaración de trabajo, un plan de negocios o una carta de proyecto. El Acuerdo del proyecto se
  termina, por lo general, poco después de que se estabiliza el modelo de análisis y está en marcha
  la planeación del resto del proyecto.
  Un Acuerdo del proyecto debe contener, al menos, lo siguiente:
                • Una lista de los documentos a entregar.
                • Los criterios para la demostración de los requerimientos funcionales.
                • Los criterios para la demostración de los requerimientos no funcionales, incluyendo
                precisión, confiabilidad, tiempo de respuesta y seguridad.
                • Los criterios para la aceptación.
  El Acuerdo del proyecto representa la línea base de las pruebas para la aceptación del cliente.
  Cualquier cambio en la funcionalidad a entregar, los requerimientos no funcionales, los tiempos
  de entrega o el presupuesto del proyecto requieren la renegociación del Acuerdo del proyecto.

• Supervisión del estado. A lo largo del proyecto los líderes de equipo y la administración
  supervisan el estado y lo comparan con la calendarización planeada. Los líderes de equipo son
  responsables de la recopilación de información de estado mediante reuniones, revisiones, reportes
  de problemas y terminación de productos de trabajo, y de resumirla para el gerente del proyecto.

• Administración del riesgo. Durante esta actividad los participantes en el proyecto identifican los
  problemas potenciales que pueden causar retrasos en la calendarización y sobregiros en el
  presupuesto. El gerente del proyecto y los líderes de equipo identifican, analizan y priorizan los
  riesgos y preparan planes de contingencia para los riesgos importantes.

• Replaneación del proyecto. Cuando el proyecto se desvía de la calendarización, o cuando se
  activa un plan de contingencia, el gerente del proyecto o el líder de equipo revisa el calendario y
  reasigna recursos para satisfacer el tiempo de entrega. El gerente del proyecto puede contratar
  nuevo personal, crear nuevos equipos o intercalar equipos existentes.


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 con la
envoltura del sistema para su instalación y aceptación, y recopilan la historia del proyecto para
usarla en el futuro.

Unidad 1: Ciclo de Vida del proyecto                                                  Página 6 de 7
                                                                    Cátedra: Ingeniería del software
                                                                                         Nivel: 4to.
                                                                                  Dpto. de Sistemas

   Prueba de aceptación del cliente. El propósito de la prueba de aceptación del cliente es la
    presentación del sistema y la aprobación del cliente de acuerdo a los criterios de aceptación
    establecidos en el Acuerdo del proyecto. El resultado de la prueba de aceptación del cliente es la
    aceptación formal (o el rechazo) del sistema por parte del cliente. Puede ser que la instalación
    del sistema y las pruebas de campo hechas por el cliente ya hayan sucedido antes de esta prueba.
    La prueba de aceptación del cliente constituye el final visible del proyecto.
    La prueba de aceptación del cliente se realiza como una serie de presentaciones de la fun-
    cionalidad y características novedosas del sistema. Se ejercitan los escenarios importantes del
    Enunciado del problema y los demuestran los desarrolladores a los futuros usuarios. Las demos-
    traciones adicionales se enfocan en los requerimientos no funcionales del sistema, como la pre-
    cisión, la confiabilidad, el tiempo de respuesta o la seguridad. Si la instalación y las
    evaluaciones del usuario sucedieron antes de la prueba de aceptación del cliente, se presentan y
    resumen los resultados. Por último, la prueba de aceptación del cliente también sirve como un
    foro de discusión para actividades subsiguientes, como el mantenimiento, la transferencia de
    conocimientos o la mejora del sistema.

   Instalación. La fase de instalación del proyecto incluye la prueba de campo del sistema, la
    comparación de los resultados del sistema con el sistema heredado, la eliminación de sistema
    heredado y el entrenamiento de los usuarios. El proveedor o el cliente pueden realizar
    instalación, dependiendo del Acuerdo del proyecto.
    Para minimizar los riesgos, la instalación y la prueba de campo se realizan incremental-mente,
    usando sitios no críticos como ambiente de pruebas de campo. Sólo hasta que el cliente está
    convencido que la interrupción de su negocio se mantendrá al mínimo es cuando el sistema
    entregado entra en operación a escala completa. Los sistemas de reemplazo y las mejoras rara
    vez se introducen en forma de "gran explosión", ya que la mayor cantidad de problemas se des-
    cubre durante los primeros días de operación.

   Post mortem. Todo proyecto descubre nuevos problemas, eventos no previstos y fallas
    inesperadas. Por tanto, cada proyecto constituye una oportunidad para el aprendizaje y la
    anticipación de nuevos riesgos. Muchas compañías de software realizan un estudio post mortem
    de cada proyecto después de que termina. El post mortem incluye la recopilación de datos
    acerca de las fechas de entrega planeadas al inicio y las reales, la cantidad de defectos
    descubiertos, información cualitativa acerca de problemas técnicos y administrativos
    descubiertos y sugerencias para proyectos futuros. Aunque esta fase es la menos visible del
    ciclo de vida, la compañía depende mucho de ella para el aprendizaje y mejora de su eficiencia.




Unidad 1: Ciclo de Vida del proyecto                                               Página 7 de 7

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:5
posted:7/20/2011
language:Spanish
pages:7