Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

Modelo CMMI (página 4)



Partes: 1, 2, 3, 4, 5

  1. Nombre: Realizar
    Análisis y Diseño de la
    Solución

    Artefactos de Entrada:
    Planteamiento de Arquitectura Inicial, Mecanismos de
    Diseño (Patrones), Prototipo de Sistema, Requerimiento de Sistema,
    Arquitectura del Sistema

    Artefactos de Salida:
    Arquitectura del Sistema, Mecanismos de
    Implementación, Especificación de
    Diseño

    Actores Involucrados:
    Analista, Arquitecto

    Descripción (ver
    Figura 9 ):

     

    El objetivo que se intenta alcanzar es de
    lograr una definición técnica de
    cómo debe construirse el sistema. Esta
    definición debe contemplar todas las
    decisiones a tomar al momento de construir la
    solución, incluyendo aspectos de arquitectura,
    de diseño particular, etc. En este contexto el
    diseño existe como un facilitador para
    transformar los requerimientos en código ejecutable, conteniendo
    las guías necesarias para lograr la
    fabricación de la
    aplicación.

     

    Después de realizar el
    análisis de los requerimientos se deben
    aplicar los mecanismos de diseño establecidos
    y junto a los prototipos no funcionales desarrollados
    en la disciplina anterior se debe producir
    la Especificaciones de Diseño para cada caso
    tomando en cuenta la arquitectura planteada para el
    sistema para poder definir exactamente cómo
    el sistema va a producir el comportamiento definido. La
    obtención de la Especificación de
    Diseño de la aplicación posee las
    ventajas de que provee una mejor visualización
    de las dependencias y del uso de los componentes,
    algo esencial al momento de tener que realizar una
    modificación; lo mismo trae a su vez la
    desventaja de que los diseños se deben
    mantener y esta mantención debe realizarse
    junto con la del código fuente, si se espera
    beneficiarse posteriormente de estos planos de
    diseño.

     

    A medida que se van diseñando los
    componentes del sistema se debe ir completando la
    Arquitectura del Sistema con más detalle. Al
    finalizar la fase de Elaboración se debiera
    tener un plano completo del sistema, ya que a este
    punto es posible predecir la cantidad y los tipos de
    componentes que generará el sistema.
    También en este punto deben generarse los
    mecanismos de implementación para cada
    mecanismo de diseño establecido que aún
    no tenga definida su forma de implementar.

    Figura 9: Realizar
    Análisis y Diseño de la
    Solución

    Nombre: Desarrollar
    Solución Sistémica

    Artefactos de Entrada:
    Arquitectura del Sistema, Prototipo de Sistema,
    Especificación de Diseño, Mecanismos de
    Implementación

    Artefactos de Salida:
    Pruebas Unitarias, Componente de
    Software

    Actores Involucrados:
    Desarrollador, Analista

    Descripción:

    El objetivo principal es producir las piezas
    de código especificadas de la manera
    más eficiente y eficaz posible. Los
    desarrolladores deben tomar las Especificaciones de
    Diseño y los Prototipos del Sistema y, luego
    de revisarlos, debe generar los componentes de
    código que sean necesarios de acuerdo a la
    especificación y siguiendo los mecanismos de
    implementación. Junto con la construcción de cada componente
    se deben generar Pruebas Unitarias para las mismas
    que aseguren su correcto comportamiento. Para ello
    estos deben conocer en profundidad la herramienta de
    desarrollo y estar familiarizados con
    el
    lenguaje utilizado en las
    especificaciones.

    Nombre: Asegurar
    Correctitud y Funcionalidad de la
    Solución

    Artefactos de Entrada:
    Requerimiento de Sistema, Especificación de
    Diseño, Prototipo de Sistema, Componente de
    Software, Criterios de
    Aceptación

    Artefactos de Salida:
    Pruebas de Funcionalidad, Incidencias

    Actores Involucrados:
    Analista, Desarrollador, Tester

    Descripción (ver
    Figura 10)

    Esta disciplina tiene por objetivos asegurar dos cosas: que se
    está construyendo la pieza adecuada para el
    trabajo y que dicha pieza está
    construida de la manera correcta.

     

    En primera instancia se deben elaborar
    pruebas funcionales para los requerimientos que
    están siendo desarrollados. Se debe tener en
    cuenta tanto el Requerimiento de Sistema y su
    prototipo como la Especificación de
    Diseño para generar la prueba funcional que
    esté probando todos los escenarios necesarios
    para lograr la mayor cobertura posible del
    código. Al generar la prueba se deben tener en
    cuenta además los Criterios de
    Aceptación definidos por el cliente de manera de que las pruebas
    funcionales aseguren cobertura de estos
    criterios.

     

    Las pruebas son ejecutadas por un actor no
    involucrado en el análisis ni desarrollo del
    componente con el objetivo de generar Incidencias
    cuando los resultados esperados no concuerdan con los
    obtenidos, para que estos puedan ser corregidos por
    los desarrolladores y luego las pruebas ser
    ejecutadas nuevamente hasta lograr un resultado
    satisfactorio, es decir, el cumplimiento de los
    Criterios de Aceptación.

     

    Figura 10: Asegurar Correctitud
    y Funcionalidad de la Solución

    Nombre: Desplegar
    Solución

    Artefactos de Entrada:
    Arquitectura de Sistema, Componente de
    Software.

    Artefactos de Salida:
    Versión desplegada del sistema, Documentación de
    Despliegue.

    Actores Involucrados:
    Arquitecto, Integrador

    Descripción:

    En el despliegue se debe instalar o asegurar
    la instalación de los componentes de software
    desarrollados en los ambientes computacionales que
    corresponda. Lo relevante en esta etapa es tener una
    versión funcional del sistema desarrollado y
    no módulos sueltos que no se puedan probar ni
    instalar. Es importante además actualizar la
    documentación con los nuevos componentes
    desplegados. Se considera útil tener una
    versión desplegada desde los primeros
    componentes construidos, ya que para cuando se
    termine el desarrollo del sistema estos componentes
    ya habrán estado en producción por un tiempo, reduciendo la cantidad de
    errores potenciales no encontrados.

    La Fase de Transición tiene por finalidad
    asegurar que el sistema desarrollado esté disponible
    para los usuarios finales. Esto implica que se lleven a
    cabo las pruebas de certificación del software en el
    ambiente
    de control de
    calidad y se genere además la
    documentación final necesaria para su
    utilización en producción. En el diagrama
    de la Figura 11 se presenta modelada esta fase.

     

    Figura 11: Fase de
    Transición

    A esta altura todos los procesos
    se encuentran detallados en la disciplina de Describir el
    Problema de Negocio, todos los requerimientos ya han sido
    completamente detallados y analizados en la disciplina de
    Especificar Requerimientos de la Solución, el
    diseño completo de la aplicación debe estar
    completo en la disciplina de Realizar Análisis y
    Diseño de la Solución y todos los componentes
    necesarios ya deben haber sido desarrollados en la
    disciplina Desarrollar Solución Sistémica,
    por lo que no se entrará en detalle en estas
    disciplinas para su documentación.

    Nombre: Asegurar
    Correctitud y Funcionalidad de la
    Solución

    Artefactos de Entrada:
    Pruebas de Aceptación

    Artefactos de Salida:
    Incidencias.

    Actores Involucrados:
    Jefe de Proyecto, Cliente

    Descripción:

    Acá se deben ejecutar las pruebas de
    aceptación definidas por el cliente. Cualquier
    inconformidad genera una incidencia que debe ser
    revisada. La conformidad de las pruebas de
    aceptación es un hito importante que debe ser
    registrado.

    Nombre: Desplegar
    Solución

    Artefactos de Entrada:
    Componente de Software, Versión desplegada del
    sistema

    Artefactos de Salida:
    Documentación de Despliegue, Versión
    1.0.0

    Actores Involucrados:
    Integrador

    Descripción:

    Se genera la primera versión del
    sistema, en función de sus componentes de
    software construidas y probadas y de las versiones
    desplegables que se han generado del sistema hasta
    ese momento. Se asocia en esta disciplina la
    generación de instaladores y de
    documentación de instalación y
    operación necesaria para las personas que
    serán luego las encargadas de mantener el
    sistema operando dentro de los rangos de rendimiento
    necesarios. Además se debe realizar el
    despliegue final sobre el ambiente de
    producción de la primera versión del
    sistema y se hace una copia de esta versión
    para entrega al cliente junto con la
    documentación final.

    Artefactos

    Los artefactos generados y utilizados en los
    diagramas de procesos mostrados
    anteriormente serán detallados a
    continuación. Dentro de este detalle se
    incluyen:

    Nombre: Nombre utilizado para referirse al
    artefacto.

    Tipo: Si el artefacto corresponde a un
    Diagrama de Clase,
    Diagrama de Casos de Uso, Diagrama de Componentes, Diagrama
    de Despliegue, Diagrama de Actividades, Documento o
    Código, Ejecutable.

    Actores Responsables: Persona,
    rol u organización encargada de la
    producción y mantención del artefacto.
    Típicamente es quien lo genera.

    Descripción: Describe los objetivos
    y usos del artefacto.

    Nombre: Bases de
    Licitación

    Tipo:
    Documento

    Actores Responsables:
    Cliente

    Descripción

    Las bases de Licitación deber ser
    revisadas en busca de requerimientos
    específicos con respecto a la entrega de
    productos al cliente.

    Nombre: Contrato y Anexos

    Tipo:
    Documento

    Actores Responsables:
    ORDEN Integración y
    Cliente.

    Descripción

    El contrato es un acuerdo pactado entre
    ORDEN Integración y la
    empresa cliente en el cual se definen una serie
    de compromisos y responsabilidades entre ambas partes
    que deben ser cumplidas. Los Anexos son documentos extra como minutas de
    reuniones con el cliente, entrevistas, etc.

    Nombre: Descripción de la
    Solución

    Tipo:
    Documento

    Actores responsables: Equipo de
    Proyecto

    Descripción

    Corresponde a una breve descripción
    de la Solución. Debe contener:

    – Planteamiento de la arquitectura: Consiste
    en un diagrama de subsistemas o componentes estimados
    a partir de los requerimientos detectados y un
    diagrama de despliegue que contenga los
    requerimientos de plataforma, ubicación de
    componentes y herramientas.

    – Decisiones respecto a tecnologías,
    frameworks, motores de integración u otros
    componentes de terceros que se haya decidido
    utilizar.

    Nombre: Visión
    del Sistema

    Tipo: Diagrama de Casos
    de Uso

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Se busca concentrar en un solo lugar la
    visión original que tiene cada uno de los
    Stakeholders respecto al sistema. Debe contener los
    objetivos principales y secundarios que el sistema
    debe cumplir y una descripción lo más
    detallada posible del problema de negocio que debe
    resolver. La visión del sistema una vez
    establecida queda congelada para poder tener en todo
    momento una referencia a lo que originalmente el
    sistema buscaba resolver.

    Nombre: Concepto de Dominio

    Tipo: Diagrama de
    Clases

    Actores Responsables:
    Jefe de Proyecto y Analista

    Descripción

    Se expresa en términos de una clase.
    Incluye la definición del concepto que se
    quiere representar y sus principales atributos, que a
    su vez son definidos como atributos de esa clase.
    Además incluye las relaciones entre los
    conceptos en forma de asociaciones con sus diversos
    estereotipos. Al conjunto completo de conceptos con
    sus relaciones se le llama Diagrama de Dominio ya que representa todos los
    conceptos involucrados de alguna manera en el
    ámbito o dominio del problema.

    Nombre: Proceso de Negocio

    Tipo: Diagrama de
    Actividades

    Actores Responsables:
    Jefe de Proyecto y Analista de la Fábrica de
    Software

    Descripción

    Incluye los procesos junto con los eventos que los gatillan, los
    trabajadores y objetos involucrados en la
    organización y los ámbitos en los
    que se estima que el sistema tenga influencia. Los
    procesos deben estar debidamente descritos con el
    nivel de detalle que corresponda; se espera que
    puedan relacionarse en términos de sus
    entradas y salidas. Esto para poder a futuro
    identificar las partes de la aplicación que
    van a ser sistematizadas. Los conceptos mencionados
    en los procesos como entradas, salidas, etc. deben
    estar definidos en los conceptos de dominio, para
    asegurar un entendimiento de lo que involucra el
    generar como salida o recibir como entrada el objeto
    al que se hace referencia.

    Nombre: Requerimiento
    original ofrecido

    Tipo:
    Documento

    Actores Responsables:
    Analista

    Descripción

    Expresados en la forma original en que
    fueron ofrecidos al cliente cuando este aceptó
    el proyecto. Buscan mantener una referencia de lo que
    se ofreció originalmente y conocer cuál
    era el tamaño del proyecto al momento de
    comenzarlo.

    Nombre: Requerimiento de
    Negocio

    Tipo:
    Documento

    Actores Responsables:
    Analista

    Descripción

    Se especifican en forma de prosa o de forma
    textual a como aparecen en los documentos originales
    (sean bases de licitación, documentos de
    reuniones, etc.). Buscan preservar en un artefacto
    los deseos y necesidades originales del cliente para
    con el sistema al momento de proponer una primera
    solución.

    Nombre: Requerimiento de
    Sistema

    Tipo: Diagrama de Casos
    de Uso

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Deben incluir a los actores involucrados en
    el sistema, los casos de uso con sus descripciones,
    escenarios, restricciones y finalmente todo aquello
    que pueda dar una idea completa sobre qué debe
    hacer el sistema.

    Los Requerimientos de Sistema deben estar
    relacionados con aquellos Procesos de Negocio que
    deben ser automatizados y con aquellos Conceptos de
    Negocio con los cuales deben interactuar.
    Además deben satisfacer al menos uno de los
    requerimientos ofrecidos, en caso contrario se
    considerarán como requerimientos
    nuevos.

    Nombre: Criterios de
    Aceptación

    Tipo:
    Documento

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Los criterios definidos por el cliente para
    dar por satisfecho el cumplimiento de cada
    requerimiento. Generalmente escritos en prosa. Esto
    puede variar desde la definición de una prueba
    hasta unos índices generales de funcionamiento
    que se deben poder comprobar con la
    realización de una prueba
    funcional.

    Nombre: Requerimientos
    Funcionales

    Tipo:
    Documento

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Los requerimientos funcionales representan
    las características fundamentales del producto final; constituyen una
    expresión del tamaño del proyecto
    así como la base de toda su planificación posterior. La
    volatilidad que experimenten durante el transcurso
    del proyecto debe ser rigurosamente monitoreada por
    el Jefe de Proyecto, a fin de evitar impacto en el
    desarrollo normal del trabajo. Es importante vigilar
    que los requerimientos se encuentren siempre dentro
    del ámbito definido para el proyecto. En caso
    contrario, se deberá activar el procedimiento de control de cambios.

    Nombre: Requerimientos
    No Funcionales

    Tipo:
    Documento

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Estos requerimientos están asociados
    generalmente a características cualitativas
    del producto final, expresadas en términos
    amplios y sin criterios de aceptación claros.
    Dichos requerimientos pueden representar una
    importante fuente de riesgo si no se logra acotar su
    alcance a un nivel claro y objetivo. Para tal efecto,
    el Jefe de Proyecto deberá intentar, con la
    aprobación del cliente, transformar los
    criterios cualitativos en cuantitativos.

    Nombre: Prototipo de
    Sistema

    Tipo:
    Código

    Actores Responsables:
    Desarrollador, Analista, Arquitecto

    Descripción

    Los prototipos buscan dar una vista previa
    de cómo debiera verse el Sistema una vez que
    esté construido. Por lo general los prototipos
    no deberían ser funcionales, a menos que el
    costo/beneficio justifique que se
    gaste esfuerzo en construirlos
    funcionales.

    Nombre: Planteamiento de
    Arquitectura Inicial

    Tipo: Diagrama de
    Despliegue / Diagrama de Componentes

    Actores Responsables:
    Arquitecto

    Se identifican en primera instancia
    módulos y componentes principales y las
    posibles soluciones tecnológicas
    asociadas a cada uno de ellos, además de
    determinar cuáles son aquellos componentes
    más riesgosos.

    Nombre: Arquitectura del
    Sistema

    Tipo: Diagrama de
    Componentes

    Actores Responsables:
    Arquitecto

    Descripción

    La Arquitectura del Sistema involucra un
    plano en términos de paquetes, módulos
    y componentes de cada uno de los elementos del
    sistema. Esto artefacto se va elaborando a medida que
    se diseña el sistema, ya que es a medida que
    se ataca cada problema que aparecen las componentes
    que los van a resolver. Es posible que al finalizar
    la fase de Elaboración se pueda lograr un
    plano teórico de cómo debiera ser la
    Arquitectura del Sistema con una baja incertidumbre,
    ya que para esa altura se debiese haber terminado de
    estereotipar todos los componentes del sistema y ya
    es posible, en función de los requerimientos
    de los componentes faltantes, estimar la forma y
    tamaño que ellos tendrán.

    Nombre: Mecanismos de
    Diseño (Patrones)

    Tipo:
    Documento

    Actores Responsables: Arquitecto

    Descripción

    Los mecanismos de diseño son
    instrucciones de cómo se debe diseñar
    cada tipo de problema identificado. Indican en forma
    de instructivo cuáles son los patrones de
    diseño que se deben aplicar y cuáles
    debieran ser los resultados en cada caso.

    Nombre:
    Especificación de Diseño

    Tipo: Diagrama de
    Clases

    Actores Responsables:
    Analista, Arquitecto

    Descripción

    Las especificaciones de diseño
    consisten en diagramas de clases donde aparecen
    claramente estereotipadas los distintos componentes,
    descritos sus atributos, métodos y las relaciones de
    dependencia entre ellos. En el caso de los atributos
    se requiere que se especifique su tipo y las
    validaciones básicas asociadas al mismo. En el
    caso de los métodos, se requiere que se
    especifique la firma y el comportamiento que tiene el
    mismo; en caso que sea demasiado complejo se debe
    crear un diagrama de actividades dentro de la clase
    que describa el comportamiento del mismo y que
    represente su flujo de actividades. Cada componente
    debe estar explícitamente realizando al menos
    uno de los Requerimientos de Sistema.

    Nombre: Mecanismos de
    Implementación

    Tipo: Documento /
    Código

    Actores Responsables:
    Arquietecto

    Descripción

    En estrecha relación con los
    Mecanismos de Diseño, ya que se debe
    establecer para cada uno de ellos la forma de
    transformar dicha especificación a
    código.

    Nombre: Prueba de
    Concepto

    Tipo:
    Código

    Actores Responsables:
    Arquitecto, Desarrollador

    Descripción:

    Corresponde a un pequeño proyecto de
    desarrollo que busca probar la factibilidad de una solución
    para un problema en particular que generalmente es
    innovadora y no existe experiencia previa con esa
    tecnología o línea de
    solución en general.

    La prueba de concepto se da por concluida
    cuando queda demostrado, por una aplicación o
    algún tipo de demostración, que la
    solución propuesta cumple con necesidades
    funcionales que se requieren de ella y con las
    restricciones de escalabilidad, performance,
    robustez, etc. asociadas con el proyecto.

    Nombre: Componente de
    Software

    Tipo:
    Código

    Actores Responsables:
    Desarrollador

    Descripción

    Módulo software desarrollado,
    adquirido o reutilizado que posee una funcionalidad
    definida y que cumple con al menos un Requerimiento
    de Sistema.

    Nombre: Pruebas
    Unitarias

    Tipo:
    Código

    Actores Responsables:
    Desarrollador, Analista

    Descripción

    Pruebas de caja blanca diseñadas para
    probar un componente de software en particular,
    generalmente apoyadas por la misma herramienta de
    desarrollo del componente. Son generadas por los
    desarrolladores con apoyo de los analistas en
    aquellos aspectos que no estén indicados en la
    especificación.

    Nombre: Pruebas de
    Funcionalidad

    Tipo: Diagrama de
    Actividades

    Actores Responsables: Tester

    Descripción

    Estas pruebas están orientadas a
    probar la funcionalidad de un conjunto de componentes
    en forma de escenarios de operación para
    comprobar el correcto funcionamiento del sistema. Las
    Pruebas de Funcionalidad dependen de la funcionalidad
    y del sistema que se quiere probar.

    Nombre: Pruebas de
    Aceptación

    Tipo:
    Documento

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Es un conjunto de pruebas que una vez
    ejecutadas aseguran la conformidad del cliente con el
    producto. Estas pruebas deben estar descritas en el
    formato de pruebas definido para el proyecto o estar
    acompañadas de una guía de acción que indique cómo
    realizarlas.

     

    Las pruebas de aceptación debieran
    ser ejecutadas por un ente distinto al cliente y al
    equipo del proyecto, pero típicamente las
    ejecuta el mismo cliente o el mismo equipo de pruebas
    del proyecto, previo acuerdo por las dos
    partes.

    Nombre:
    Incidencias

    Tipo: Entidad de
    Negocio

    Actores Responsables:
    Jefe de Proyecto

    Descripción

    Una Incidencia es un hecho que no
    está considerado en la planificación
    del proyecto, ya sea una necesidad, problema o
    requerimiento que no estaba considerado como parte
    del proyecto y que surge en forma inesperada.
    También puede ser un riesgo que estaba
    incluido en el Plan de Administración de Riesgos que se ha materializado, en
    cuyo caso se debe realizar el plan de contingencia
    allí definido.

    Un evento de este tipo puede nacer del mismo
    proyecto, puede ser un requerimiento de otro proyecto
    o de otra área de negocios y puede afectar los recursos y el cronograma de
    actividades del proyecto.

    Una incidencia debe entenderse como una
    orden de servicio que debe ser atendida por la
    fábrica de software. En la resolución
    de una incidencia pueden participar más de una
    persona natural e incluso una incidencia puede llegar
    a dar origen a un proyecto en sí que debe
    abordarse en forma separada.

    Nombre: Versión
    1.0.0

    Tipo:
    Código

    Actores Responsables:
    Integrador

    Descripción

    Corresponde a la primera versión del
    sistema completo que ya ha pasado los criterios de
    aceptación planteados por el
    cliente.

    Nombre: Versión
    desplegada del sistema

    Tipo:
    Código

    Actores Responsables:
    Integrador

    Descripción

    Una versión parcial del sistema que
    es funcional y desplegable, dado un conjunto de
    requerimientos de plataforma determinados que se
    encuentran indicados en la documentación de
    despliegue asociada a esta versión.

    Nombre:
    Documentación de Despliegue

    Tipo: Diagrama de
    Despliegue

    Actores Responsables:
    Integrador

    Descripción

    Esta documentación debe incluir
    descripciones de los nodos donde serán
    desplegadas las componentes del sistema (incluyendo
    las configuraciones necesarias para asegurar el
    funcionamiento del sistema), la lista de componentes
    desplegadas indicando en qué nodo se han
    desplegado, los procedimientos de respaldo y
    recuperación (todos los pasos y antecedentes a
    tener en cuenta en caso de un respaldo o
    recuperación van juntos por la dependencia que
    tienen uno del otro) y los procedimientos de
    mantención necesarios (incluye balanceos de
    carga, indexación de las bases
    de datos, etc.).

    Actores Participantes

    Cliente: Parte responsable de aceptar el
    producto o de autorizar el pago de este. Es externo al
    proyecto pero no necesariamente externo a la
    organización. Los clientes
    son parte de los Stakeholders.

    Jefe de Proyecto: Es el responsable ante
    la gerencia
    del desarrollo y mantención del proyecto.

    Analista: Incluye a los analistas de
    requerimientos avocados en un proyecto.

    Arquitecto: Responsable de definir la
    arquitectura lógica y tecnológica que
    será usada para el desarrollo, soporte,
    mantención y operación del
    Sistema.

    Desarrollador: Corresponde a los
    programadores del Sistema.

    Tester: Encargados de hacer las pruebas
    de los componentes del Sistema y del Sistema
    completo.

    Integrador: Responsable de unir los
    componentes separados para formar el Sistema
    completo.

    Stakeholders: Involucra a todas las
    personas u organizaciones que son afectados por el
    Sistema. Puede incluir a miembros del proyecto, proveedores, clientes, usuarios finales y
    otros.

    Procesos de Apoyo

    1. El Proceso de Administración de Requerimientos
      permite establecer y mantener un entendimiento
      común entre el cliente y el proyecto acerca de
      los requerimientos que serán abordados y que
      serán el vínculo coherente y rastreable
      que une a todo el ciclo de desarrollo. Dicho acuerdo
      representa la base para estimar, planificar, ejecutar y
      controlar las actividades del proyecto a través
      del ciclo de
      vida.

      La
      Administración de Requerimientos comprende
      actividades relacionadas con la definición,
      clasificación, asignación, seguimiento y
      control de los requerimientos durante todo el ciclo de
      vida de desarrollo de software. En la Figura 12 se
      muestra un diagrama que modela el ciclo
      de actividades de este proceso.

      Figura 12:
      Administración de Requerimientos

      El proceso se inicia con Ingresar el
      Requerimiento, actividad que se modela en la Figura
      13.

      Figura 13: Ingresar
      Requerimiento

      Actividad: Analizar
      Antecedentes e historia de los requerimientos del
      proyecto

      Entradas: Bases de
      Licitación, Términos de Referencia,
      Propuesta Técnica, Mail, Documentos
      Adjuntos

      Salidas: N.
      A.

      Actores
      Involucrados
      : Jefe de
      Proyecto

      Descripción:

      Se deben analizar todos los antecedentes
      y la historia de los requerimientos del proyecto,
      desde que se realiza la propuesta hasta el
      momento actual en que este se encuentra. Pueden
      existir otros artefactos de entrada; en el
      diagrama por simplicidad se señalan
      sólo algunos típicamente
      usados.

      Actividad:
      Determinar tipo de requerimiento

      Entradas: N.
      A.

      Salidas: N.
      A.

      Actores
      Involucrados
      : Jefe de
      Proyecto

      Descripción:

      De esta decisión pueden surgir
      dos alternativas:

      1.- El requerimiento es un Cambio de
      Requerimiento.

      El requerimiento es una
      modificación, corrección o
      simplemente la eliminación de un
      requerimiento que pertenece a la Línea
      Base vigente y aprobada.

      2.- El requerimiento es un Requerimiento
      Nuevo.

      El requerimiento no ha sido analizado
      antes, por lo tanto es necesario hacer su estudio
      detallado.

      Actividad: Ingresar
      Información del Proyecto y
      del requerimiento

      Entradas: N.
      A.

      Salidas: Registro de
      Requerimientos.

      Actores
      Involucrados
      : Jefe de
      Proyecto

      Descripción:

      La información de cada
      requerimiento incluye:

      Fecha: Fecha en que se realiza este
      plan.

      ID Proyecto: Identificación del
      proyecto.

      Nombre Proyecto: Nombre completo del
      proyecto.

      Responsable GR: Nombre de la persona
      responsable de la Administración de los
      Requerimientos.

      Fase: Número de la fase del mismo
      proyecto. Se genera un nuevo encabezado por cada
      fase del mismo proyecto.

      ID LB: Identificación de la
      Línea Base vigente de la fase y el
      proyecto

      Fecha inicio LB: Fecha planificada del
      comienzo de esta fase, aprobada por CM. Si
      está en blanco implica que aun no
      está definida.

      Fecha aprobación LB: Fecha de
      aprobación de LB utilizada cuando hay
      cambio de LB debido a Control de Cambios, si
      está en blanco implica que aún no
      se ha modificado la Línea Base
      inicial.

      Se actualiza además el
      estado del requerimiento como
      "Ingresado".

      El Registro de Requerimientos se realiza
      en el software Enterprise Architect.

      Actividad: Completar
      o adaptar requerimientos predefinidos
      según aplican al proyecto

      Entradas: Glosario y Ayuda. 2.7 Forma de
      llenado del Registro de Requerimientos

      Salidas: Registro de
      Requerimientos

      Actores
      Involucrados
      : Jefe de
      Proyecto

      Descripción:

      En base a la forma de llenado de los
      requerimientos en el Enterprise Architect se
      actualiza los datos en el sistema, agregando a
      su vez mayor detalle a cada uno, dependiendo del
      proyecto y del requerimiento en
      sí.

       

      Si existe un control de cambios en
      algún requerimiento se activa esta actividad,
      que se modela en la Figura 14

      Figura 14: Control de
      Cambios

    2. Administración
      de Requerimientos
  2. Fase de
    Transición

Partes: 1, 2, 3, 4, 5
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter