Upload
joquest
View
7
Download
0
Embed Size (px)
DESCRIPTION
Proceso de desarrollo de software
Citation preview
Historia de Revisiones
Fecha Versión Descripción Autor
03-08-2007
1.0 Creación del documento
Francia Mejía
Tabla de Contenidos
1. Introducción 4
1.1 Propósito 4 1.2 Alcance 4 1.3 Definiciones, Acrónimos y Abreviaturas 4 1.4 Referencias 4 1.5 Visión General 4
2. Diagrama Panorámico 5
3. Descripción del Proceso 5
3.1 Negociación 8 3.1.1 Entregables del proceso 9
3.2 Modelamiento del Negocio 9 3.2.1 Levantamiento de Información 9
3.2.1.1.1 Entregables del proceso 10 3.3 Requerimientos 11
3.3.1 Análisis de Requerimientos 11 3.3.2 Administración de Requerimientos 11 3.3.3 Definición de Requerimientos 12
3.4 Análisis 13 3.5 Diseño 13 3.5.1 Diseño Lógico 13 3.5.2 Diseño Físico 13 3.6 Desarrollo 14 3.7 Pruebas 15 3.8 Documentación 16 3.9 Implementación 16 3.10 Soporte y Mantenimiento 17
4. Entregables del Proceso 18
5. Recursos del Proceso 19
6. Rutas de Productos de Trabajo 20
Proceso de Desarrollo de Software
1. Introducción
1.1 Propósito
El propósito de este documento es describir y establecer la metodología del Proceso de Desarrollo de Software de xxxx
1.2 Alcance
Esta descripción aplica para todos los proyectos de xxxxxx
1.3 Definiciones, Acrónimos y Abreviaturas
No aplica.
1.4 Referencias
Plan de Infraestructura.
1.5 Visión General
Este documento incluye el diagrama panorámico, descripción del proceso, entregables del proceso, roles y herramientas a utilizar.
2. Diagrama Panorámico
Proyecto
3. Descripción del Proceso
El proceso está clasificado en cuatro fases, las cuales son:
Incepción
Elaboración
PPQA
CM
Proyecto
Proceso
Construcción
Transición
Además de las fases, se desarrollará de manera iterativa e incremental, con el objetivo trabajar los
requerimientos por iteraciones, e ir incrementando los las liberaciones del producto.
A cada etapa se le realizará una inspección, validación o verificación a los artefactos o productos
de trabajo generados, con el objetivo de asegurar la calidad del producto desde el inicio del
proyecto.
Cada fase se administrará a través de un cronograma de actividades Master; y cada etapa se
administrará a través de un cronograma de actividades de acuerdo a la fase, disciplina e iteración a
la cual corresponda:
1. Fase de Incepción
PRY-INC-BNS-ITPLN
PRY-INC-RQM-MSTPLN
PRY-INC-RQM-ITPLN-00
2. Fase de Elaboración
PRY-ELB-A&D-MSTPLN
PRY-ELB-A&D-ITPLN-00
3. Fase de Construcción
PRY-CNS-DEV-MSTPLN
PRY-CNS-DEV-ITPLN-00
PRY-CNS-TST-MSTPLN
PRY-CNS-TST-ITPLN-00
4. Fase de Transición
PRY-TRN-DOC-MSTPLN
PRY-TRN-DOC-ITPLN-00
PRY-TRN-IMP-MSTPLN
PRY-TRN-INS-ITPLN-00
PRY-TRN-IMP-ITPLN-00
PRY-TRN-ENT-ITPLN-00
Donde,
Nomenclatura PRY Fase Disciplina ITPLN
Incepción PRY-INC-BNS-ITPLN
Proyecto INC BNS: Negocios Master Plan de Modelamiento de Negocios
PRY-INC-RQM-MSTPLN
Proyecto INC RQM: Requerimientos Master Plan de Requerimientos
PRY-INC-RQM-ITPLN-00
Proyecto INC RQM: Requerimientos Plan de la Iteración No.
Elaboración
PRY-ELB-A&D-MSTPLN
Proyecto ELB A&D: Análisis y Diseño Master Plan de Análisis y Diseño
PRY-ELB-A&D-ITPLN-00
Proyecto ELB A&D: Análisis y Diseño Plan de Análisis y Diseño de la Iteración No.
Construcción
PRY-CNS-DES-MSTPLN
Proyecto CNS DES: Desarrollo Master Plan de Desarrollo
PRY-CNS-DES-ITPLN-00
Proyecto CNS DES: Desarrollo Plan de Desarrollo la Iteración No.
PRY-CNS-TST-MSTPLN
Proyecto CNS TST: Pruebas Master Plan de Pruebas
PRY-CNS-TST-ITPLN-00
Proyecto CNS TST: Pruebas Plan de Pruebas de la Iteración No.
Transición
PRY-TRN-DOC-MSTPLN
Proyecto TRN DOC: Documentación Master Plan de Documentación
PRY-TRN-DOC-ITPLN-00
Proyecto TRN DOC: Documentación Plan de Documentación de la Iteración No
PRY-TRN-IMP-MSTPLN
Proyecto TRN IMP: Implementación Master Plan de Implementación
PRY-TRN-INS-ITPLN-00
Proyecto TRN INS: Instalación Plan de Instalación de la Iteración No.
PRY-TRN-IMP-ITPLN-00
Proyecto TRN IMP: Implementación Plan de Implementación ón de la Iteración No.
PRY-TRN-ETR-ITPLN-00
Proyecto TRN ETR: Entrenamiento Plan de Entrenamiento de la Iteración No.
Diagrama RUP.
La Administración del Proyecto, será realizada a través del Procedimiento de Administración de
Proyectos.
El ambiente será controlado a través del Plan de Infraestructura.
3.1 Negociación
El proceso de negociación consiste en captar prospectos de futuros clientes. Las actividades que se realizan son las siguientes:
Luego de hacer las demostraciones al cliente y capturar sus requerimientos, se procede a evaluar el proyecto, con la finalidad de determinar su naturaleza, tipo y requerimientos técnicos.
Se procede a generar la Propuesta del Proyecto, con el objetivo de que sea aprobada por el cliente. Teniendo la Propuesta aprobada, se realiza y entrega el Contrato del Proyecto. Los detalles sobre precios y costos del producto son manejados a discreción de los involucrados, por la Gerencia de Sistemas de Negocios en otros documentos, así como las Estrategias de Ventas e Investigación de Mercado.
Los acuerdos de la entrega del producto en la negociación, estará sujeto a las estimaciones de tiempos correspondientes al tipo de producto, esto es la estimación del tiempo de entrega dependerá de si es un producto desarrollado o si es un nuevo proyecto.
Una vez firmado el Contrato del Proyecto, por ambas partes (cliente y representante de Xxxxx), la Gerencia de Sistemas de Negocios, completa y entrega a Proyectos el Formulario Levantamiento de Información Técnica, con el objetivo de dar curso al proceso de desarrollo del producto en caso de ser un nuevo proyecto o a la Implementación en caso de ser un producto desarrollado.
3.1.1 Entregables del proceso
Esta etapa del proyecto debe generar los siguientes documentos:
Propuesta del Proyecto Contrato del Proyecto Requerimientos del Cliente Formulario Levantamiento de Información Técnica
3.2 Modelamiento del Negocio
El modelamiento del negocio se realiza a través del levantamiento de información.
El primer paso del análisis es el levantamiento de información con el objetivo de dar inicio al proceso
de evaluación del negocio para identificar sus necesidades de implementación.
3.2.1 Levantamiento de Información
El proceso de Levantamiento de Información consiste en realizar una investigación de campo, con la
finalidad de identificar las necesidades de los involucrados.
El levantamiento de información de Xxxxx, S. A., tiene dos vertientes, pues se realiza para productos
desarrollados y productos de nuevos proyectos.
3.2.1.1 Productos Desarrollados
Este siempre se realizará por áreas de competencias de acuerdo al proyecto a implementar.
Análisis de áreas, se describe el proceso que siguen los involucrados en la realización de sus
funciones; sean estas áreas Direcciones, Departamentos, Unidades, Secciones o Módulos
propiamente dichos; a través de las cuales se capturan de los posibles usuarios los siguientes
datos:
Nombre del Recurso
Posición
Rol
Preparación Académica
Conocimientos de Informática
Requerimientos de recursos técnicos que deben ser adquiridos por el cliente para poder
ejecutar eficientemente las labores y operaciones de los usuarios a través de la aplicación.
Observaciones
Informaciones Generales
Con los Reportes de Entrevistas y los Cuestionarios, la información anterior es registrada en el
documento Levantamiento de Información, el cual es utilizado exclusivamente para proyectos de
productos ya desarrollados.
3.2.1.1.1 Entregables del proceso
Esta etapa del proyecto debe generar los siguientes documentos:
Reportes de Entrevistas
Informe Levantamiento de Información
Documentos informativos del cliente
3.2.1.2 Productos Nuevos Proyectos
Se crea inicialmente el documento Caso de Negocio, con la finalidad de obtener la siguiente
información:
Descripción del Producto Contexto del Negocio Objetivos del Producto Pronóstico Financiero
En la investigación para este tipo de productos, provee principalmente las siguientes informaciones:
Oportunidades de negocio Enunciado del problema Posicionamiento del producto Descripción de usuarios e involucrados
Nombre del recurso Posición Rol Responsabilidades Área Perfiles Necesidades claves
Visión general del producto Características del producto Requerimientos del producto
La información anterior es registrada en el Documento Visión, el cual es utilizado exclusivamente para
proyectos de nuevos productos.
Se procede a crear el SRS: Especificación de Requerimientos de Software en el cual se indican los
siguientes aspectos:
Descripción Global
Requerimientos Específicos
Requerimientos Suplementarios
Todos éstos con todos sus detalles.
En la finalización de esta etapa se crea el Glosario del Proyecto, en el cual se indican las definiciones
de los términos exclusivos del proyecto.
3.2.1.2.1 Entregables del proceso
Esta etapa del proyecto debe generar los siguientes documentos:
Reportes de Entrevistas
Informe Levantamiento de Información
Documentos informativos del cliente
Caso de Negocio
Documento Visión
SRS
Glosario del Proyecto
3.3 Requerimientos
En esta etapa debe considerarse el análisis, la administración y definición requerimientos:
3.3.1 Análisis de Requerimientos
El objetivo de la etapa de análisis de requerimientos es identificar asociaciones estructurales entre objetos y nuevas clases (entidad) y modelar visualmente los requerimientos, en vista de que la programación de nuestra compañía es Orientada a Objetos, esto implica que el análisis y el diseño lo sean también. Por tanto para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos. También se necesitará realizar un análisis y diseño orientado a objetos.
3.3.2 Administración de Requerimientos
Con el SRS, se procede a identificar los requerimientos; Luego de haber tenido la identificación de
requerimientos se procede a hacer una revisión de esa identificación, con el propósito de reducir
inconsistencias y generar una Lista de Requerimientos.
Con la Lista de Requerimientos revisada se procede a crear la Matriz de Requerimientos, donde se
registran uno a uno especificando los valores a los atributos (tipo, módulo, estado, orden, entre otros)
correspondientes al Plan Administración de Requerimientos.
Cuando se hayan depurado los requerimientos se procede a establecer la trazabilidad entre
requerimientos de acuerdo a la lógica de negocio, y se genera la Matriz de Trazabilidad y Reporte de
Trazabilidad.
3.3.2.1 Entregables del proceso
Esta etapa del proyecto debe generar los siguientes documentos:
Lista de Requerimientos
Matriz de Requerimientos
Matriz de Trazabilidad
Reporte de Trazabilidad
3.3.3 Definición de Requerimientos
Habiendo revisado y corregido la lista de requerimientos y establecido la trazabilidad entre los
mismos; se procede a realizar la definición de los requerimientos.
Cuando los requerimientos hayan sido especificados de acuerdo a la Guía de Especificación de
Casos de Usos y Opciones Suplementarias, se realizará una audiencia interna de revisión de
requerimientos con el objetivo de depurarlos antes de presentarlos al cliente.
La definición de los requerimientos es registrada en los Casos de Usos y Opciones Suplementarias.
En los Casos de Usos se especifican las funcionalidades principales del sistema:
Mantenimientos
Procesos
En las Opciones Suplementarias se especifican las funcionalidades secundarias del sistema:
Consultas
Reportes
Otros de menor complejidad
Habiendo definido todos los requerimientos se convoca a los involucrados internos y externos para
sostener el WorkShop de revisión de requerimientos.
Este WorkShop, generará un Informe de Validación de Requerimientos, con el cual se procederá a
hacer los cambios a las definiciones previamente realizadas y así generar el informe final: Elicitación
de Requerimientos, éste será firmado por el cliente garantizando que los requerimientos capturados y
definidos corresponden con las necesidades planteadas.
3.3.3.1 Entregables del proceso
Esta etapa del proyecto debe generar los siguientes documentos:
Lista de Requerimientos Corregida
Casos de Usos Iniciales
Opciones Suplementarias iniciales
Convocatoria WorkShop
WorkShop de Revisión de Requerimientos
Informe Validación de Requerimientos
Casos de Usos Revisados y Corregidos
Opciones Suplementarias Revisadas y Corregidas
Elicitación de Requerimientos
3.4 Análisis
El análisis del sistema se hace desde dos puntos de vistas: Análisis de Negocio y Análisis de
Requerimientos; éstos de acuerdo a la Guía de Análisis.
Las actividades de Levantamiento de Información y Definición de Requerimientos fungen como
antesala al Análisis del Sistema, todos los documentos generados anteriormente, son la plataforma
para la creación de los Modelos de Casos de Usos, los cuales deben ser creados por pagackage o por
módulos, así como cada uno de manera individual ,por requerimiento identificado y definido.
3.4.1 Entregables del proceso
El análisis general del sistema debe generar los siguientes documentos:
Modelos de Casos de Usos
3.5 Diseño
El diseño se realizará también con la metodología orientada a objetos (DOO), ya que los modelos
orientados a objetos generados cuando se construyen en forma correcta, nos permitirán cambiar,
expandir, validar, verificar y comunicar más fácilmente. Este modelamiento en UML es flexible al
cambio y permite crear componentes plenamente reutilizables.
Sin embargo, el diseño del sistema responde a dos tipos:
3.5.1 Diseño Lógico
En esta etapa se identifican todas las entidades necesarias en la aplicación incluyendo los objetos de
interfaz y control.
3.5.1.1 Entregables del proceso
Diagrama de Entidad Relación
Diccionario de Datos
Script de Base de Datos
3.5.2 Diseño Físico
El diseño físico responde al Diseño Arquitectónico del sistema, por tanto en esta etapa del proyecto se
deben generar los modelos, diagramas y prototipos.
3.5.2.1 Entregables del proceso
BPM: Modelo de Procesos de Negocios
TSM: Modelo de Secuencia de Transacciones
OSM : Modelo de Estructura de Objetos
LCM: Modelo de Ciclo de Vida de Objetos
SGM: Modelo Global del Sistema
OID : Diagrama de Interacción de Objetos
AFD: Diagrama de Flujo de Actividad
CD: Diagrama de Clases
Todos los anteriores de acuerdo a la Guía de Diseño.
Prototipos
De acuerdo a la Guía de Interfaz de Usuario (GUI).
3.6 Desarrollo
Habiendo analizado y diseñado el sistema y sus componentes, se procede a la codificación de las
partes del sistema. Ver Guía de Programación.
Antes de iniciar con el desarrollo del producto, debe estar creada la Base de Datos de Desarrollo. El
desarrollo es parte del final de la construcción del producto.
En esta etapa se generan las unidades, las librerías, reportes, entre otros que permitirán poner en
ejecución la aplicación en construcción.
Cada unidad desarrollada debe ser validada por el desarrollador correspondiente, por tanto debe
realizar las siguientes pruebas:
Prueba de Caja Blanca
Prueba de Caja Negra
Prueba Unitaria
Estos tipos de pruebas permitirán liberar el código al personal de QA, con el menor número de errores
y/o defectos, lo cual se convertirá en beneficio de tiempo y esfuerzo a favor del proyecto. Ver ***
Durante todo el proceso de pruebas puede existir la necesidad de generar Discusiones con el objetivo
de obtener aclaraciones sobre los requerimientos, así como Requerimientos de Cambios o Change
Request, con éstos últimos, luego de estar claros en los detalles del requerimiento, será posible
generar solicitudes de cambios con la finalidad de mejorar o corregir inconsistencias en los
requerimientos.
El integrador de cambios debe generar el Plan de Integración Build, con el cual se realizarán las
actividades de integración del producto, tanto para pruebas como para la entrega al cliente.
Se debe crear un Release y un Baseline por cada iteración aprobada. Ver Plan de Administración de
Configuración.
Además debe crear el Plan de Instalación con los mismos fines de entrega del producto.
3.6.1 Entregables del proceso
Código o Unidades
Dlls
Reportes
Scripts Update SQL
Imágenes
Data
Discusiones
Change Request
Plan de Integración Build
Plan de Instalación
Release
Baseline
3.7 Pruebas
Las pruebas del producto se realizarán cuando hayan sido liberados los ejecutables del producto para
fines de pruebas, con el propósito de validar las funcionalidades de la aplicación de acuerdo a la
definición de los requerimientos.
Inicialmente, se debe crear el Plan de Pruebas, a través del cual será definida la estrategia de pruebas
a utilizar y se identificarán los requerimientos para pruebas. En este plan se incluye la definición de
una ambiente de pruebas, por lo cual se requiere una Base de Datos de pruebas.
Serán creados Casos de Pruebas con el fin de planificar los tipos de pruebas a ejecutarse. Durante la
ejecución de las pruebas pueden surgir Script SQLs, para interactuar y verificar la información
directamente en la Base Datos de pruebas.
El resultado de las pruebas será notificado a través del Reporte de Errores, donde se indicará la
descripción de dichos errores y/o defectos.
Durante todo el proceso de pruebas puede existir la necesidad de generar Discusiones con el objetivo
de obtener aclaraciones sobre los requerimientos, así como Requerimientos de Cambios o Change
Request, con éstos últimos, luego de estar claros en los detalles del requerimiento, será posible
generar solicitudes de cambios con la finalidad de mejorar o corregir inconsistencias en los
requerimientos.
Al finalizar la etapa de pruebas de acuerdo al Plan de Iteración, se generará el documento Evaluación
de Pruebas, para indicar el estado general del proyecto en la iteración correspondiente.
Las pruebas deben realizarse sujetas al Procedimiento de Administración de Pruebas y Guía de
Pruebas.
3.7.1 Entregables del proceso
Plan de Pruebas
Discusiones
Casos de Pruebas
Scripts SQL
Reporte de Errores
Change Request
Evaluación de Pruebas
3.8 Documentación
El equipo de Documentación será el responsable de generar los Manuales de Usuarios y Manuales
Técnicos en formato .doc, .pdf y .html. Así como la Ayuda en Línea y la Ayuda Técnica, ambos
artefactos serán de utilidad en el Deployment o lanzamiento del producto durante el entrenamiento a
usuarios a través del proceso de implementación.
El inicio de la creación de estos documentos será paralelo al proceso de pruebas, una vez las Formas
estén disponibles y sin errores.
También serán almacenadas todas las imágenes utilizadas (Pantallas, Botones, Iconos, etc.) en dichos
documentos en un Repositorio de Imágenes.
Existe la posibilidad que durante el proceso de documentación, sean generados requerimientos de
cambios o Change Request., ver Plan Administración de Cambios.
La documentación del sistema será realizada de acuerdo a la Guía de Estilo de Manuales.
3.8.1 Entregables del proceso
Manuales de Usuarios
Ayuda en Línea
Repositorio de Imágenes
3.9 Implementación
El proceso de implementación inicia una vez todos los requerimientos de una iteración se encuentren
en estado Aprobado por QA. Ver Plan de Administración de Requerimientos.
Las implementaciones se realizarán por módulos o iteraciones.
Antes de iniciar el proceso, el equipo de implementación y la Gerencia de Proyectos sostendrán una
reunión para definir y planificar implementación correspondiente.
Luego debe coordinar y sostener una reunión de inicial con los involucrados externos a través de una
Comunicación formal sea vía electrónica o medio impreso, con previa confirmación del cliente.
Se realiza con los involucrados del cliente un Taller, con la finalidad de establecer el concepto de la
aplicación en los usuarios finales para su posterior entrenamiento. Los resultados de estos talleres son
tabulados y presentados al comité del proyecto a través del documento Evaluación del Taller.
Luego se procede a generar el Plan de Implementación, Cronograma de Implementación, Plan de
Entrenamientos, Cronogramas de Entrenamientos.
Existe la posibilidad que durante el proceso de entrenamientos, sean generados requerimientos de
cambios o Change Request, de acuerdo a Plan Administración de Cambios, a través de los cuales
serán solicitadas mejoras y adaptaciones al sistema. Además durante todo el período se sostendrán
reuniones de seguimiento, donde los acuerdos serán registrados a través de las Minutas de Reuniones.
En caso de existir inconvenientes, serán manejados a través del Plan de Solución de Problemas.
Una vez concluida la implementación, y no tener cambios pendientes por entregar, se procederá a
realizar el cierre del proceso a través de las Comunicaciones de Descargo al Cliente y Entrega a
Servicio al Cliente.
Todo este proceso se realizará basado en el Procedimiento de Implementación y la Guía de
Implementación.
3.9.1 Entregables del proceso
Comunicación de Coordinación
Plan de Implementación
Presentaciones de Talleres
Programas Talleres
Formularios Evaluación de Talleres
Evaluaciones de Talleres
Plan de Entrenamientos
Cronogramas de Entrenamientos
Minutas de Reunión
Plan de Solución de Problemas
Change Request
Comunicación Descargo Cliente
Comunicación Entrega a Servicio al Cliente
3.10 Soporte y Mantenimiento
Luego de haber realizado y entregado las comunicaciones de descargo y entrega a Servicio al Cliente,
el proyecto pasa a la etapa de Soporte y Mantenimiento, en caso de existir cambios y anomalías en el
mismo.
Ver:
Procedimiento de Servicio al Cliente
Plan Administración de Cambios
4. Entregables del Proceso
A continuación es descrita la documentación por áreas mínima que debe ser producida
durante el proceso de Desarrollo de Software.
•Propuesta del Proyecto
•Contrato del Proyecto
Negociación
•Reportes de Entrevistas
•Informe Levantamiento de Información
•Documentos informativos del cliente
•Caso de Negocio
•Documento Visión
•SRS
•Glosario del Proyecto
Levantamiento de Información
• Lista de Requerimientos
•Matriz de Requerimientos
•Matriz de Trazabilidad
•Reporte de Trazabilidad
•Cronograma Definición de Requerimientos
•Casos de Usos
•Opciones Suplementarias
•Convocatoria WorkShop
•WorkShop a Ejecutivos
• Informe Validación de Requerimientos
•Elicitación de Requerimientos
Requerimientos
•Cronograma de Análisis
•Modelos de Casos de Usos
Análsis
•Cronograma de Diseño
•Diagrama de Entidad Relación
•Diccionario de Datos
•Script de Base de Datos
•Diagrama de Clases
•Diagrama de Secuencia
•Prototipos
Diseño
Arquitectura
•Cronograma de Desarrollo
•Código o Unidades
•Dlls
•Reportes
•Scripts update SQL
•Imágenes
•Data
•Discusiones
•Change Request
•Plan de Integración Build
•Plan de Instalación
•Release
•Baseline
Desarrollo
5. Recursos del Proceso
Disciplina
Rol
Herramienta
Negociación Vendedor
• MS Word • MS Power Point
Levantamiento de Información
Analista de Negocios • MS Word • MS Power Point
Requerimientos
Analista de Requerimientos
• MS Word • MS Project • Borland Caliber Define IT • Borland Caliber RM
Análisis
Analista de Sistemas
• MS Project • Herramienta Modelado
Diseño Arquitectura
Arquitecto
• MS Project • MS Excel • Borland Delphi
•Plan de Pruebas
•Cronograma de Pruebas
•Casos de Pruebas
•Scripts SQL
•Reporte de Errores
•Discusiones
•Change Request
•Evaluación de Pruebas
Pruebas
•Manuales de Usuarios
•Ayuda en Línea
•Repositorio de Imágenes
•Change Request
Documentación
•Comunicación de Coordinación inicio implementación
•Plan de Implementación
•Cronograma de Implementación
•Presentaciones de Talleres
•Programas Talleres
•Formularios Evaluación de Talleres
•Plan de Entrenamientos
•Cronogramas de Entrenamientos
•Minutas de Reunión
•Plan de Solución de Problemas
•Change Request
•Informe Cierre de Implementación
•Comunicación Entrega a Soporte Técnico y Mantenimiento
Implementación
• Borland Together • MS BD • Herramienta de Modelado
Desarrollo
Desarrollador
• MS Project • MS Word • Borland Delphi • SMBD • Report Builder • Borland Caliber RM • Borland Stat Team
Integración Integrador • Borland Delphi • SMBD • Borland Stat Team •
Pruebas Analista de Pruebas
• MS Project • MS Word • Borland Startr Team • Borland Caliber RM • Borland Caliber Define IT • SMBD • Herramienta Adm. Pruebas
Documentación
Documentador
• MS Project • MS Word • Acrobat Reader • Borland Start Team • Doc-O-Matic
Implementación
Implementador
• MS Project • MS Word • MS Power Point • Borland Stat Team
6. Rutas de Productos de Trabajo
Templates Descripción del Documento Ruta Propuesta del Proyecto
Contrato del Proyecto
Reportes de Entrevistas
levinf Informe Levantamiento de
Información
Documentos informativos del
cliente
rup_buscs Caso de Negocio
rup_bvis Documento Visión
rup_srs SRS
rup_glss Glosario del Proyecto
Lista de Requerimientos
Matriz de Requerimientos
Matriz de Trazabilidad
Reporte de Trazabilidad
Cronograma Definición de
Requerimientos
rup_ucspec Casos de Usos
Opciones Suplementarias
Convocatoria WorkShop
WorkShop a Ejecutivos
Informe Validación de
Requerimientos
Elicitación de Requerimientos
Templates Descripción del Documento Recurso Responsable Propuesta del Proyecto Utilizados por Xxxxx
Contrato del Proyecto Utilizados por Xxxxx
entinf Reportes de Entrevistas
levinf Informe Levantamiento de Información
Documentos informativos del cliente Todps los adquiridos
rup_buscs Caso de Negocio
rup_bvis Documento Visión
rup_srs SRS
rup_glss Glosario del Proyecto
Lista de Requerimientos
Matriz de Requerimientos Será generada por Caliber RM
Matriz de Trazabilidad Será generada por Caliber RM
Reporte de Trazabilidad Será generada por Caliber RM
PRY-INC-RQM-MSTPLN PRY-INC-RQM-ITPLN-00
Cronograma Definición de Requerimientos
rup_ucspec Casos de Usos
Opciones Suplementarias
Convocatoria WorkShop
WorkShop a Ejecutivos MS PowerPoint
Informe Validación de Requerimientos
Elicitación de Requerimientos
PRY-ELB-ANS-MSTPLN PRY-ELB-ANS-ITPLN-00
Cronograma de Análisis
Modelos de Casos de Usos
De acuerdo a la herramienta de
modelado
PRY-ELB-DES-MSTPLN PRY-ELB-DES-ITPLN-00
Cronograma de Diseño
Diagrama de Entidad Relación