Proceso de Desarrollo de Software

Calidad Proceso de Desarrollo de Software

Versión 1.0

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


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



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


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.



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.


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.


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.


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.


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.


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.


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.


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


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


Matriz de Requerimientos

Matriz de Trazabilidad

Reporte de Trazabilidad

Cronograma Definición de

Requerimientos

rup_ucspec Casos de Usos

Opciones Suplementarias


WorkShop a Ejecutivos

Informe Validació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


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


WorkShop a Ejecutivos MS PowerPoint

Informe Validació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

Diccionario de Datos

Script de Base de Datos

Diagrama de Clases

Diagrama de Secuencia

Prototipos

• Cronograma de Desarrollo

• Release

• Baseline

• Código o Unidades

• Dlls

• Reportes

Scripts update SQL

Imágenes

Data

Discusiones

Change Request

Plan de Integración Build

Plan de Instalación

Proceso de Desarrollo de Software

Documents

Transcript of Proceso de Desarrollo de Software