PROYECTO:

SISTEMA DE FACTURACION E INVENTARIO

(FACTINV)

DOCUMENTO GENERAL

Contenido
INTRODUCCION............................................................................................................3 MOTIVACION.................................................................................................................4 OBJETIVO.....................................................................................................................5 GLOSARIO DE TERMINOS..........................................................................................6 PRIMERA PARTE:.........................................................................................................7
ADMINISTRACIN DEL PROYECTO...........................................................................7 Introduccin....................................................................................................................8 Objetivo...........................................................................................................................9 Grupo de Trabajo............................................................................................................9 Modelo del Proceso de Software ...................................................................................9 Planeacin.....................................................................................................................11 Requerimientos de recursos de Hardware y Software..............................................11 Definicin de Actividades.........................................................................................13 Calendarizacin del Proyecto....................................................................................15 Administracin de Riesgos...........................................................................................19

SEGUNDA PARTE:.....................................................................................................23
REQUERIMIENTOS DEL SISTEMA............................................................................23 Introduccin..................................................................................................................24 Estudio de Factibilidad.................................................................................................25 Factibilidad Econmica.............................................................................................25 Factibilidad Operativa...............................................................................................25 Factibilidad Tcnica..................................................................................................25 Obtencin y Anlisis de Requerimientos......................................................................26 Mtodo VORD..........................................................................................................26

INTRODUCCION
La simulacin asistida por computador consiste bsicamente en construir modelos informticos que describen la parte esencial del comportamiento de un sistema de inters, y proceder a experimentar con estos modelos, para extraer conclusiones de sus resultados que permitan apoyar la toma de decisiones. La simulacin ha crecido como una metodologa de experimentacin fundamental en campos tan diversos como la Economa, la Estadstica, la Informtica o la Fsica y con enormes aplicaciones industriales y comerciales, como los simuladores de vuelo, los juegos de simulacin, los procesos industriales, o la prediccin burstil o meteorolgica. En lo que respecta al mbito industrial la simulacin de procesos es una las herramientas ms utilizadas por la ingeniera industrial, por lo general una vez que se detecta que cierto sistema de inters no opera en forma adecuada, se plantea al ingeniero la forma de mejorar el funcionamiento del mismo, y para ello emplea la simulacin, ya que en la mayora de los casos experimentar con el sistema real tomar mucho tiempo, ser costoso y adems tendr que interrumpir el funcionamiento actual de las operaciones que ejecuta el sistema dentro de la empresa. El modelo debe permitir estudiar, predecir o explicar un fenmeno, proceso o metodologa con un grado de precisin determinado. El grado de precisin del modelo est asociado a factores como la definicin de las variables relevantes que explican el sistema, la interrelacin de estas en el modelo y el nivel en que el modelo representa el sistema real. En trminos generales, un modelo debe ser una representacin aceptable de la realidad, es decir, debe existir una buena correlacin entre lo que predice el modelo y lo que sucede en la realidad. Para tener la certeza de que se a alcanzado esta correlacin, resulta indispensable realizar un proceso de validacin. El desarrollo del sistema de informacin propuesto, esta orientado a proporcionar un ambiente de prueba, que permita validar modelos representados como ecuaciones algebraicas diferenciales, capaces de representar en forma adecuada gran parte de los procesos industriales actuales. Este documento describe el proceso del software seleccionado para Analizar, Disear, codificar y Probar el desarrollo de un sistema de Facturacin e Inventario (FACTINV). El documento se encuentra dividido en cinco partes principales, como a continuacin se describe: I. Primera parte: Descripcin de la Administracin del proyecto. II. Segunda Parte: Se encuentra documentada la Ingeniera de Requisitos. III. Tercera Parte: Contiene el Diseo del proyecto. IV. Cuarta Parte: Presenta la Validacin, Verificacin y Pruebas del proyecto.

MOTIVACION
Para que todo proceso de simulacin sea til, es necesario que el modelo sea una representacin aceptable de la realidad, es decir, debe existir una buena correlacin entre lo que se simula y lo que sucede en la realidad, y para establecer adecuadamente esta correlacin resulta indispensable realizar un proceso de validacin. La validacin de un modelo es un problema, relativamente complejo. Si se dice que un modelo es correcto o vlido, significa que est representando en forma adecuada el sistema real, pero es obvio que nunca se puede estar absolutamente seguro y ningn modelo, por ms sofisticado que sea, puede representar exactamente la realidad, y siempre ser una aproximacin del sistema real. Por lo tanto se considera que en el proceso de validacin de un modelo, se trata de obtener el mayor grado de confianza posible para su uso. En trminos generales la validacin de un modelo est relacionada con la necesidad de efectuar un conjunto de pruebas que permitan verificar que tan seguro es utilizar el modelo propuesto, y esto depender de lo aproximado que sea la salida real y la calculada mediante la simulacin, sin pretender en ningn momento que esta sea una representacin exacta de la realidad. Por otro lado el conjunto de pruebas a realizar se puede generalizar de forma tal que sean independientes del modelo que se desea validar, lo que permitir aplicarlas a varios modelos que pretenden simular diferentes procesos industriales de inters y mientras menos sesgadas sean las pruebas realizadas, ms fiable ser el proceso de validacin. En vista de que es comn que dentro de una empresa converjan diferentes procesos industriales, y que el proceso de validacin de un modelo es indispensable para que este sea aplicado en forma segura, resulta sumamente interesante abstraer el proceso de validacin, ganando as generalidad en dicho proceso, esto permitir reducir los costos de prueba, ya que no hay que disear un proceso de validacin para cada modelo, por otro lado al hacer que el conjunto de pruebas a realizar, sean lo ms independientes posibles del modelo, los resultados obtenidos sern mucho ms confiables, estas dos caractersticas generalidad para reducir costos y confiabilidad en los resultados obtenidos, constituyen sin duda alguna la motivacin principal para desarrollar el sistema de informacin propuesto.

OBJETIVO
El objetivo del presente proyecto es el desarrollo de un sistema de Facturacin e Inventario para un negocio dedicado a la compra y venta de hules industriales y automotrices, el negocio desea llevar control y mantener actualizados sus registros de adquisiciones, ventas, proveedores, clientes e inventario de productos en bodega. En la figura 1, se presenta el diagrama lgico del sistema.

SISTEMA PRINCIPAL COMPRAS

ADMINISTRACION DE CLIENTES Y PROVEEDORES

PROVEEDOR ES

VENTAS

COMPRAS Y VENTAS

CONTROL DE INVENTARIO INVENTARIO REPORTES

CLIENTES

Figura 1 Diagrama lgico del sistema de Facturacin e Inventario.

GLOSARIO DE TERMINOS
Trmino FACTINV BD CASE RtS WBS POS INAOE VORD Descripcin Sistema de Facturacin e Inventario Base de Datos Computer-Aided Systems Engineering, traduccin Ingeniera de Sistemas Asistida por Computadora Real Time Studio, traduccin Estudio en Tiempo Real Work Breakdown Structure Project Overview Statement Instituto Nacional de Astrofsica, ptica y Electrnica Definicin de requerimientos orientados a puntos de vista

PRIMERA PARTE:
ADMINISTRACIN DEL PROYECTO

Introduccin
La Administracin de Proyectos es un mtodo y un conjunto de tcnicas basadas en los principios aceptados de la Administracin usados en la planeacin, estimacin y control de actividades de trabajo para alcanzar un resultado final deseado en tiempo, dentro de un presupuesto asignado y acorde a una especificacin. La gestin de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan administracin o planeacin del proyecto. Antes de que el proyecto comience, el administrador y el grupo de trabajo deben realizar una estimacin del trabajo a realizar, de los recursos necesarios y del tiempo que transcurrir desde el comienzo hasta el final de su realizacin. Siempre que estimamos, lo hacemos mirando hacia el futuro y debemos aceptar resignados cierto grado de incertidumbre. A pesar de que resulta sumamente difcil estimar, existen un conjunto de tcnicas tiles para la estimacin del esfuerzo y del tiempo. Las mtricas del proyecto y del proceso proporcionan una perspectiva histrica y una potente introduccin para generar las estimaciones cuantitativas, por otro lado la experiencia en proyectos anteriores, puede ayudar en gran medida al desarrollo y revisin de las estimaciones. En resumen el objetivo de la planificacin del proyecto es proporcionar un marco de trabajo que permita al administrador hacer estimaciones razonables de sus recursos, estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo del proyecto, y en caso de ser necesario debern actualizarse a medida que progresa el proyecto. Adems las estimaciones deben definirse los escenarios del mejor y peor caso de forma que los resultados del proyecto puedan limitarse. En esta seccin se estudia cada una de las actividades asociadas a la administracin del proyecto, partiendo desde la seleccin del modelo a seguir para desarrollar el mismo, la definicin de las actividades a realizar, su calendarizacin, y el anlisis de riesgos del proyecto propuesto.

Objetivo
Esta seccin describe un panorama de la Administracin del Proyecto FACTINV, iniciando con la seleccin del Modelo del Proceso del Software a seguir en el desarrollo del presente proyecto y su justificacin, as como las actividades asociadas a la administracin del proyecto, que comprenden los siguientes puntos: 1. Planeacin del Proyecto 2. Calendarizacin de las actividades del Proyecto. 3. Administracin de los Riesgos

Grupo de Trabajo
El grupo de trabajo para el desarrollo del proyecto esta formado por dos desarrolladores, como a continuacin se describe: Nombre Puesto Administrador Proyecto Desarrollador Especialista en del Ingeniera de Software y Programacin Ingeniera de Software y Programacin

Modelo del Proceso de Software

Cuando se trabaja para construir un producto o un sistema, es importante seguir una serie de pasos predecibles -un mapa de carreteras que le ayude a obtener el resultado oportuno de calidad-. El mapa de carreteras a seguir en el desarrollo de sistemas de software es llamado, el Proceso del Software. Los ingenieros de software y sus gestores adaptan el proceso a sus necesidades y entonces lo siguen. Adems las personas que han solicitado el software tienen un papel a desempear en el proceso del software. Los procesos de software tradicionales conocidos actualmente son complejos y, como en todo proceso intelectual, se basa en el juicio humano. Aunque existen muchos procesos diferentes de software, tienen actividades fundamentales que son comunes para todos ellos. Estas son: Anlisis, Diseo, Implementacin y Pruebas. La seleccin de un modelo de proceso para la ingeniera del software, debe hacerse de acuerdo a la naturaleza del proyecto, de la aplicacin, mtodos y herramientas a utilizarse, y de los controles de entrega que se requieren. Para el desarrollo del sistema propuesto fue seleccionado el modelo Cascada o modelo lineal secuencial, el cual sugiere un enfoque sistemtico y secuencial para el desarrollo del software, en este modelo los clientes piden lo que desean, por 9

medio de esos requerimientos se disea el sistema, despus el diseo se codifica y por ultimo se efectan las pruebas que determinaban si el sistema funciona correctamente de acuerdo a los requerimientos del cliente., tal como se muestra en la figura 2. A pesar de que el modelo original en cascada propuesto por Winston Royce en 1970, hace provisiones para bucles de retroalimentacin, en la gran mayora de los casos este modelo se aplica como si fuera estrictamente lineal.

Ingeniera de Requerimient os

Verificacin y Validacin

Diseo del Sistema de Software

Verificacin y Validacin

Programaci n

Verificacin y Validacin

Figura 2 Modelo de Proceso de Software seleccionado. Modelo Cascada.

10

El modelo cascada es el paradigma ms antiguo y ms extensamente utilizado en la ingeniera de software, sin embargo la crtica del paradigma en algunos casos a puesto en duda su eficiencia, es por ello que a continuacin se describen las causas que justificaron la seleccin de este modelo. Se puede desarrollar con facilidad ya que sus etapas estn bien definidas. El proyecto a desarrollar ya ha sido puesto en practica con xito en otros lugares. Los requerimientos del proyecto son comprendidos en su totalidad.

Planeacin
La planeacin tiene como finalidad fijar los recursos disponibles, dividir el trabajo del proyecto en actividades que puedan ser realizadas por el grupo de desarrollo en poco tiempo, crear un calendario de trabajo y un realizar un anlisis de riesgos. Requerimientos de recursos de Hardware y Software Este punto de la planeacin describe los requerimientos de hardware y software que se utilizaran para el desarrollo del proyecto, como a continuacin se indican:
Recursos de Hardware Cant Descripcin
Procesador Intel Pentium 4 Sistema Operativo Microsoft Windows XP Profesional Bus de Sistema 800 MHz. Memoria: 512MB PC3200 DDR 400MHz (2x256) Disco Duro de 80 GB minimo. Disco ptico: CD-ROM RW/ (48x) Unidad de disquete de 3.5 pulg. y 1.44 MB. Grficos Integrados Intel UMA AGP8x hasta 64 MB de memoria compartida. Tarjeta de red 10/100 integrada. Mdem Integrado de 56K ITU V.90. Interfase: 6 USB2.0, Serial, 2PS/2, VGA, Paralelo, RJ45/11, Ranuras de expansin: 4 ranuras de expansin (1 ocupada y 3 disponibles)

Justificacin

Computadora de escritorio

Se requieren para el desarrollo del sistema y al finalizar una de las computadoras servir como administrador de la BD.

11

Recursos de Software

Cant

Descripcin

Justificacin

Herramienta de desarrollo CASE y licencia

Base de Datos y ambiente de desarrollo. Ambiente de desarrollo Visual C++ Paquete de Trabajo Office

1 1 1

Puede ser Racional Rose o similar, actualmente en el lugar donde se desarrolla el sistema se tiene acceso al Artisam RtS. MySQL 4.0 o superior Se requiere la ultima versin, Visual Studio.Net Office XP o 2003

Se requieren para el modelado y diseo del sistema bajo el estndar de UML Este tipo de base de datos es de fcil uso y es software libre. Por ser el ambiente que domina el grupo de desarrollo. Elaborar la documentacin del Proyecto.

12

Definicin de Actividades
Para poder alcanzar los objetivos o metas del proyecto, las tcnicas de divisin del proyecto en actividades parece ser la ms acertada. En este proyecto, para la definicin de las actividades se utilizo una tcnica denominada Work Breakdown Structure (WBS), que es la divisin del proyecto en una jerarqua de actividades, teniendo como cabeza de la jerarqua al sistema FACTINV completo y en niveles inferiores a las actividades que se deben realizar para alcanzar la construccin total del sistema FACTINV. Las actividades se subdividen a su vez en actividades de menor nivel, esta divisin se detiene, cuando se tengan actividades bien definidas, su ejecucin lleve poco tiempo y su progreso pueda ser medido. Al final de cada actividad se rinde un hito de esa actividad, que es un informe no extenso que indica al administrador del proyecto que esa actividad ha sido concluida. Las actividades en las que se ha dividido el desarrollo del sistema FACTINV han sido descritas en la tabla 1. Actividades Proyecto FACTINV
H0 T1.1 T1.2 T1.3 T1.4 H1 T2 T2.1 T2.2 T2.3 H2 T3 T3.1 T3.2 H3 T4 T4.1 T4.2 T4.3 H4 T5 H5 T6 T6.1 T6.2 H6 Inicio del Proyecto Definicin del Proyecto Reunin con stakeholders Definicin del problema a resolver Generacin del POS (Project Overview Statement) Hito: Documento del POS Estudio de factibilidad Analizar la factibilidad econmica. Analizar la factibilidad operativa. Analizar la factibilidad tcnica. Hito: Informe de factibilidad Anlisis de Requerimientos de Usuario a partir del POS Anlisis del Contexto del Sistema Generacin del Diagrama de Contexto Hito: Diagrama de contexto del sistema Anlisis de Escenarios y Casos de Usos Definir escenarios del sistema Definir casos de uso del sistema Generacin de Diagrama de Casos de Usos Hito: Diagrama de Casos de Usos Verificacin y Validacin con stakeholders Hito: Informe de verificacin y validacin del mbito del sistema Definicin de requerimientos de usuario Requerimientos Funcionales Requerimientos no funcionales Hito: Documento de definicin de requerimientos en lenguaje natural

Actividades Proyecto FACTINV

T7 H7 T8 T8.1 T8.2 T8.3 H8 T9 T9.1 T9.2 T9.3 T9.4 H9 T10 H10 T11 H11 T12 T12.1 H12 T13 H13 T14 H14 Verificacin y Validacin con stakeholders Hito: Informe de verificacin y validacin requerimientos de usuario Definicin de requerimientos del sistema Requerimientos Funcionales Requerimientos no funcionales Especificacin de requerimientos Hito: Documento de Requerimientos Diseo del Sistema Diseo arquitectnico Estructuracin del sistema Modelado de control Descomposicin modular Hito: Reporte Tcnico del diseo Arquitectnico Anlisis y diseo de Secuencia de Objetos Hito: Diagrama de Secuencia de Objetos Anlisis y Diseo de Clases Hito: Diagrama de Clases Anlisis y Diseo de Base de Datos Diseo de las tablas de la base de datos Hito: Diagrama del diseo de base de datos Anlisis, diseo de interfaces Usuario del sistema" Hito: Diagramas de interfaces usuario del sistema Verificacin y validacin del diseo Hito: informe de verificacin y validacin del diseo

Actividades Proyecto FACTINV

13

T15 H15 T16 T16.1 T16.2 T16.3 T16.4 T16.5 T16.6 T16.7 T16.7 H16 T17 H17 T18 H18 T19 H19 T20 H20

Documento de Diseo Hito: Documento de Diseo Programacin del Sistema Programacin Modulo de Ventas Programacin Modulo de Compras Programacin Modulo de Administracin de Inventario Programacin Modulo de Registro de Clientes y Proveedores Programacin Modulo de Reportes Programacin de interfaces entre Mdulos y base de datos Programacin Base de Datos Programacin de Interfaces de Usuario Hito: Cdigo del programa "Verificacin, validacin y pruebas del cdigo" Hito: Informe de pruebas Documentacin del Cdigo Hito: Manual del Programador Capacitacin del usuario final Hito: Plan de capacitacin del usuario final Entrega del Proyecto Hito: Documentacin del Proyecto

Tabla 1 Definicin de Actividades del Proyecto FACTINV

14

Calendarizacin del Proyecto

En esta etapa del proyecto se estima el tiempo requerido para completar cada una de las actividades previamente definidas, para ello se debe calendarizar cada una de las mismas, indicando su fecha de inicio, duracin y fecha de culminacin, adems se deben establecer las dependencias que existen entre las diferentes actividades que conforman el proyecto. Una forma sencilla de representar la informacin del calendario del proyecto, es a travs de un grfico de barras, llamado tambin grfico de Gantt. En la calendarizacin solo el domingo se considero como dia no laborable y debido a que la jornada laboral diaria era irregular, se decidi estimarla semanalmente, a un promedio de 40 horas laborales a la semana.

ID

Descripcin de Actividad

H0 Inicio T1.1 Definicion del Proyecto T1.2 Reunion con stakeholders T1.3 Definicin del problema a resolver T1.4 Generacin del POS (Project Overview Statement) H1 Hito: Documento del POS (H1) T2 Estudio de factibilidad T2.1 Analizar la factibilidad econmica. T2.2 Analizar la factibilidad operativa. T2.3 Analizar la factibilidad tcnica. H2 Hito: Informe de factibilidad (H2) T3 Anlisis de Requerimientos de Usuario a partir del POS T3.1 Anlisis del Contexto del Sistema T3.2 Generacin del Diagrama de Contexto H3 Hito: Diagrama de contexto del sistema (H3) T4 Anlisis de Escenarios y Casos de Usos T4.1 Definir escenarios del sistema T4.2 Definir casos de uso del sistema T4.3 Generacin de Diagrama de Casos de Usos H4 Hito: Diagrama de Casos de Usos (H4) T5 Verificacin y Validacin con stakeholders H5 Hito: Informe de verificacin y validacin del mbito del sistema (H5)

Fecha Inicio Duracin Actividad 0 das 24/08/2004 8 das 1 da 4 das 1 da 0 das 3 das 4 das 4 das 4 das 0 das 8 das 6 das 2 das 0 das 11 das 6 das 3 das 2 das 0 das 2 das 0 das 24/08/2004 24/08/2004 25/08/2004 30/08/2004 30/08/2004 28/08/2004 25/08/2004 25/08/2004 25/08/2004 31/08/2004 01/09/2004 01/09/2004 07/09/2004 08/09/2004 09/09/2004 09/09/2004 15/09/2004 17/09/2004 18/09/2004 20/09/2004 21/09/2004

Fecha Termino Actividad 24/08/2004 31/08/2004 24/08/2004 28/08/2004 30/08/2004 30/08/2004 31/08/2004 28/08/2004 28/08/2004 28/08/2004 31/08/2004 08/09/2004 06/09/2004 08/09/2004 08/09/2004 18/09/2004 14/09/2004 17/09/2004 18/09/2004 18/09/2004 21/09/2004 21/09/2004

ID T6

Descripcin de Actividad Definicin de requerimientos de usuario

Fecha Inicio Duracin Actividad 4 das 22/09/2004 3 das 3 das 22/09/2004 22/09/2004

Fecha Termino Actividad 25/09/2004 24/09/2004 24/09/2004

T6.1 Requerimientos Funcionales T6.2 Requerimientos no funcionales

15

H6 T7 H7 T8

Hito: Documento de definicin de requerimientos en lenguaje natural (H6) Verificacin y Validacin con stakeholders Hito: Informe de verificacin y validacin requerimientos de usuario (H7) Definicin de requerimientos del sistema

0 das

25/09/2004

25/09/2004

1 da 0 das

27/09/2004 27/09/2004

27/09/2004 27/09/2004

9 das 3 das 4 das 3 das 0 das 34 das 6 das 6 das 3 das 6 das 0 das 4 das 0 das 7 das 0 das 14 das 1 da 0 das

28/09/2004 28/09/2004 29/09/2004 04/10/2004 06/10/2004 21/10/2004 07/10/2004 09/10/2004 15/10/2004 15/10/2004 20/10/2004 21/10/2004 25/10/2004 26/10/2004 03/11/2004 21/10/2004 04/11/2004 06/11/2004

06/10/2004 30/09/2004 02/10/2004 06/10/2004 06/10/2004 24/11/2004 12/10/2004 14/10/2004 18/10/2004 20/10/2004 20/10/2004 25/10/2004 25/10/2004 03/11/2004 03/11/2004 05/11/2004 04/11/2004 06/11/2004

T8.1 Requerimientos Funcionales T8.2 Requerimientos no funcionales T8.3 Especificacin de requerimientos H8 T9 Hito: Documento de Requerimientos (H8) Diseo del Sistema

T9.1 Diseo arquitectnico T9.2 Estructuracin del sistema T9.3 Modelado de control T9.4 Descomposicin modular H9 Hito: Reporte Tcnico del diseo Arquitectnico (H9)

T10 Anlisis y diseo de Secuencia de Objetos H10 Hito: Diagrama de Secuencia de Objetos (H10) T11 Anlisis y Diseo de Clases H11 Hito: Diagrama de Clases (H11) T12 Anlisis y Diseo de Base de Datos T12.1 Diseo de las tablas de la base de datos H12 Hito: Diagrama del diseo de base de datos (H12)

T13 Anlisis, diseo y modelado de las interfaces Usuario del sistema H13 Hito: Diagramas de interfaces usuario del sistema (H13) T14 Verificacin y validacin del diseo H14 Hito: informe de verificacin y validacin del diseo (H14) T15 Documento de Diseo H15 Hito: Documento de Diseo (H15)

11 das 0 das 3 das 0 das 3 das 0 das

08/11/2004 17/11/2004 18/11/2004 20/11/2004 22/11/2004 24/11/2004

17/11/2004 17/11/2004 20/11/2004 20/11/2004 24/11/2004 24/11/2004

ID

Descripcin de Actividad

T16 Programacin del Sistema T16.1 Programacin Modulo de Ventas T16.2 Programacin Modulo de Compras T16.3 Programacin Modulo de Administracin de Inventario T16.4 Programacin Modulo de Registro de Clientes y Proveedores T16.5 Programacin Modulo de Reportes

Fecha Inicio Duracin Actividad 17 das 26/11/2004 4 das 4 das 8 das 7 das 10 das 26/11/2004 26/11/2004 30/11/2004 29/11/2004 27/11/2004

Fecha Termino Actividad 11/12/2004 30/11/2004 30/11/2004 07/12/2004 04/12/2004 07/12/2004

16

T16.6 Programacin de interfaces entre Mdulos y base de datos T16.7 Programacin Base de Datos T16.7 Programacin de Interfaces de Usuario H16 Hito: Cdigo del programa (H16) T17 Verificacin, validacin y pruebas del cdigo H17 Hito: Informe de pruebas (H17) T18 Documentacin del Cdigo H18 Hito: Manual del Programador (H18) T21 Capacitacin del usuario final H21 Hito: Plan de capacitacin del usuario final (22) T22 Entrega del Proyecto H22 Hito: Documentacin del Proyecto (23)

13 das 14 das 6 das 0 das 26 das 0 das 17 das 0 das 4 das 0 das 6 das 0 das

29/11/2004 27/11/2004 06/12/2004 11/12/2004 26/11/2004 20/12/2004 30/11/2004 15/12/2004 16/12/2004 20/12/2004 16/12/2004 22/12/2004

10/12/2004 10/12/2004 10/12/2004 11/12/2004 20/12/2004 20/12/2004 15/12/2004 15/12/2004 20/12/2004 20/12/2004 21/12/2004 22/12/2004

Tabla 2 Duracin de las Actividades del proyecto FACTINV.

17

AGOSTO 22 29
Inicio T1.1 T1.2 T1.3 H1 T2.1 T2.2 T2.3 H2 T3.1 T3.2 T3.3 T3.4 T4.1 T4.2 T4.3 T4.4 T4.5 H3 T5.1 T5.2 H4 T6.1 T6.2 T6.3 T7.1 T7.2 T8.1 T8.2 T8.3 H5 T9.1 T9.2 T9.3 T9.4 H6 T10.1 T10.2 T10.3 T10.4 T10.5 H7 T11.1 T11.2 T11.3 T11.4 H8 T12.1 T12.2 T12.3 T12.4 Fin

05

SEPTIEMBRE 12 19 26

03

10

OCTUBRE 17 24

31

07

NOVIEMBRE 14 21 28

05

DICIEMBRE 12 19 26

02

09

ENER 16

Figura N 3 Diagrama de Actividades del Proyecto.

Documento General

18

Administracin de Riesgos
A continuacin se presentan las tablas 3, 4, 5 y 6, en donde se muestra en forma resumida, la definicin, anlisis, estrategias de administracin y supervisin de los principales riesgos asociados con el desarrollo del proyecto.

TIPO DE RIESGO

RIESGOS POSIBLES La Base de Datos que se utilizara es de cdigo abierto y podra tener problemas de incompatibilidad con el lenguaje de programacin seleccionado. El personal asignado al proyecto, no cuenta con la capacitacin adecuada para desarrollar el sistema. El personal esta comprometido con otros proyectos, que le impiden atender plenamente el proyecto. Es ineficiente el cdigo generado por las herramientas CASE Las herramientas CASE son de alto costo

Tecnologa

Personas Herramientas

Requerimientos Organizacionales

Surgen nuevos requerimientos que requieren cambiar el diseo. El personal del negocio se opone a los cambios, que representa introducir FACTINV en la organizacin El tiempo requerido para la capacitacin adecuada del personal esta subestimado

Estimacin El tiempo requerido para desarrollar el sistema de software esta subestimado El tamao del software esta subestimado
Tabla 3 Clasificacin e Identificacin de Riesgos del Proyecto FACTINV.

Documento General

19

RIESGO El tiempo requerido para la capacitacin adecuada del personal esta subestimado. El personal esta comprometido con otros proyectos, que le impiden atender plenamente el proyecto. Surgen nuevos requerimientos que requieren cambiar el diseo. El personal asignado al proyecto, no cuenta con la capacitacin adecuada para desarrollar un sistema de Base de Datos El personal de la organizacin donde se instalara el sistema FACTINV, se opone a los cambios El tiempo requerido para desarrollar el sistema de software esta subestimado. El lenguaje de programacin no cuenta con mtodos previamente desarrollados, que permitan satisfacer ciertos requerimientos del sistema.

PROBABILIDAD EFECTOS Media Catastrfico

Alta

Serio

Media Alta

Serio Serio

Alta

Tolerable

Alta

Tolerable

Media

Tolerable

Tabla 4 Anlisis de Riesgos del proyecto FACTINV

Documento General

20

RIESGO Problemas con la Base de Datos

ESTRATEGIA Investigar sobre otras aplicaciones similares, que se hayan desarrollado con este tipo de Base de Datos seleccionado Realizar un diagnostico de las habilidades individuales del personal en las reas relacionadas con el desarrollo del sistema, y canalizar los planes de capacitacin de forma individualizada, para que se puedan fortalecer estas habilidades en el menor tiempo posible. Realizar una clasificacin de los proyectos de acuerdo al grado de dificultad que este represente para el personal involucrado en su desarrollo. Disear un plan de trabajo que asigne tiempos de atencin a cada proyecto, acorde con la clasificacin previamente realizada.

Problemas con la capacitacin del personal de desarrollo

Problemas relacionados con el desarrollo de otros proyectos.

Problemas del personal del negocio

Realizar un anlisis minucioso de las causas por la cual se oponen a la implementacin del sistema y tomar medidas radicales Elaborar un buen plan de entrenamiento que muestre al personal las bondades del sistema FACTINV

Cambios de requerimientos Tiempo de desarrollo subestimado

Utilizar tcnicas de diseo que limiten el impacto de los cambios de requerimientos Alertar al cliente de las dificultades de desarrollar el sistema completo en el tiempo estimado.

Tabla 5 Administracin de Riesgos del sistema FACTINV.

Documento General

21

TIPO DE RIESGO Tecnologa

INDICADORES POTENCIALES Documentacin excesiva de la Base de Datos seleccionada hace difcil la tarea de clasificar la informacin relevante a este proyecto Preocupacin excesiva de personal por temor a no cumplir con los proyectos asignados Miembros del equipo con poco mpetu para resolver problemas y aportar ideas al equipo de desarrollo

Personas

Requerimientos Herramientas Organizacionales

Dificultad de integrar los nuevos requerimientos en la fase de codificacin. Dificultad para conseguir una herramienta CASE que cumpla con las expectativas del proyecto Comentarios dentro de la organizacin referentes al bajo rendimiento presentado por el grupo trabajo asignado al proyecto

Estimacin

Fracaso en el cumplimiento de los tiempos estimados en el plan de administracin del proyecto.

Tabla 6 Supervisin de Riesgos del proyecto FACTINV.

Documento General

22

SEGUNDA PARTE:
REQUERIMIENTOS DEL SISTEMA

Documento General

23

Introduccin
En esta segunda parte del documento general se establecen y documentan las tcnicas de la Ingeniera de Requerimientos, facilitando con esto que se delimite el alcance del sistema y se comprendan los requerimientos del cliente, llevndolos a un estado donde cada uno de los requerimientos del cliente llegue a ser independiente, completo y sin ambigedades, negociando una solucin razonable, validando la especificacin y administrando los requerimientos para que se transformen en un sistema operacional. El proceso de ingeniera de requerimientos expuesto por este documento realiza un estudio de factibilidad del proyecto. As mismo se usa una tcnica para el anlisis y obtencin de requerimientos, que incluye las plantillas de punto de vista y de servicios (mtodo VORD) y los diagramas de casos de uso y de secuencia, con los resultados del mtodo VORD se definen los requerimientos en lenguaje natural para el usuario y luego se especifican en lenguaje natural estructurado, siguiendo el mtodo VOLARE, finalmente se presenta una parte de validacin y administracin de los requerimientos que incluye la matriz de de rastreo de requerimientos.

Documento General

24

Estudio de Factibilidad
En el presente estudio se analiz la disponibilidad de los recursos necesarios para alcanzar los objetivos trazados, el mismo se apoy en anlisis de 3 aspectos bsicos: Econmico Operativo Tcnico

La decisin de continuar o no con el proyecto, fue determinada por el grado de factibilidad presentado en cada uno de los tres aspectos anteriores.

Factibilidad Econmica
En el presente proyecto la factibilidad econmica se encuentra garantizada en su totalidad, ya que todos los costos del proyecto sern absorbidos por el INAOE, estos incluyen: costo de la tecnologa a utilizar (hardware y software), del personal de desarrollo, de la infraestructura (planta fsica y servicios) y del acceso al informacin.

Factibilidad Operativa
Esta depende de los recursos humanos que participen durante la operacin del proyecto, de forma tal que se pueda garantizar el uso del sistema a desarrollar. La factibilidad operativa es baja ya que: 1. El sistema ser administrado y usado por personal que no cuenta con conocimientos en computadoras, sin embargo se le dar capacitacin para el uso adecuado del sistema 2. El personal del rea administrativa y contable del negocio no acepta los cambios Sin embargo, para minimizar las consecuencias se atacaran durante el desarrollo del proyecto los dos aspectos anteriores, tomndose las medidas necesarias para el xito del proyecto de comn acuerdo con el cliente.

Factibilidad Tcnica
La factibilidad tcnica analiza los recursos de hardware y software necesarios para desarrollar el sistema, as como tambin a los conocimientos, habilidades y experiencia del personal que conforma el grupo de trabajo, para poder efectuar las actividades o procesos que requiere el proyecto. Hardware: El negocio como el grupo de desarrollo cuenta con el equipo de computo necesario para la realizacin y desarrollo del sistema. Software: El equipo de desarrollo cuenta con el software necesario para el desarrollo del sistema proporcionado por el INAOE. Personal: Se pudo determinar que para el inicio del proyecto este no contaba con ninguna experiencia en el desarrollo de sistemas de Base de Datos, sin embargo se estim que el mismo, poda adquirir los conocimientos y las habilidades necesarios para culminar exitosamente el proyecto, ya que era factible acceder a la informacin necesaria par su capacitacin.

Documento General

25

Obtencin y Anlisis de Requerimientos

Esta etapa del proceso de Ingeniera de Requerimientos se encarga de la obtencin y anlisis de requerimientos. En esta actividad el personal de desarrollo del software trabajo con los clientes y usuarios finales del sistema realizando visitas al negocio determinando el dominio de la aplicacin y cuales son los servicios que debe proveer el sistema, para la realizacin de esta actividad se utilizo un mtodo de obtencin de requerimientos orientado a puntos de vista, esta mtodo es mejor conocido como mtodo VORD, y es descrito a continuacin.

Mtodo VORD
Este mtodo se ha diseado como un marco de trabajo orientado a servicios, para poder estructurar y organizar la obtencin y anlisis de requerimientos, el mismo esta basado en el punto de vista de los usuarios finales del sistema, es por ello que se debe definir el perfil de cada uno estos usuarios, para as poder analizar su perspectiva que este tiene del sistema que se desea desarrollar. En este sentido es bueno recalcar que el sistema propuesto no es una herramienta de propsito general, si no de uso especfico, por lo tanto el usuario final debe ser un usuario especializado, que debe estar estrechamente familiarizado, tanto con el proceso industrial real, como con el modelo que pretende simular dicho proceso, ya que para poder realizar el proceso de en forma adecuada, debe inferir conclusiones comparado el comportamiento de ambos. Por todo lo expuesto anteriormente, slo se estudio el punto de vista de este tipo de usuario, que puede estar representado por un ingeniero industrial, que intenta validar un modelo, que probablemente haya sido diseado por el mismo. A continuacin se muestran las plantillas de punto de vista y de servicio para este usuario final.

Referencia : Atributos : Eventos:

Ingeniero Industrial Parmetros del modelo. Observaciones de la prueba.

Seleccionar modelo Introducir parmetros Seleccionar mtodo Iniciar simulacin Detener simulacin Perturbar simulacin Continuar simulacin Repetir simulacin Anotar Observaciones Finalizar simulacin

Servicios: Probar modelo Imprimir resultados

Documento General

26

Figura N 5 Plantilla de punto de vista.

Referencia: Fundamento:

Probar modelo. Validar un modelo que simula un proceso industrial de inters para la organizacin.

Especificacin: El usuario selecciona un modelo, introduce los parmetros necesarios, luego selecciona un mtodo para calcular su solucin, despus inicia la simulacin, durante la misma puede detener la simulacin, repetir parte de esta, perturbar la simulacin, continuar la simulacin, anotar los resultados observados y finalizar la simulacin. Punto de vista: Ingeniero Industrial. Requerimientos La simulacin debe presentarse en colores que no funcionales: contrasten con el fondo de la pantalla, para que se pueda apreciar claramente el proceso que se desea simular. Se debe poder cambiar el intervalo de tiempo en que se capturan las soluciones parciales, que se deseen repetir. Proveedor : Modulo de Prueba.

Figura N 6 Plantilla del Servicio: Probar Modelo.

Documento General

27

Referencia: Fundamento:

Imprimir resultados. Facilitar el anlisis de la validacin del modelo, de forma tal que el usuario pueda compartir y discutir las observaciones de la prueba con el resto de su equipo de trabajo.

Especificacin: El usuario selecciona el archivo que contiene las observaciones de la prueba al modelo que desea validar, y luego selecciona la opcin de obtener reporte por impresora. Punto de vista: Ingeniero Industrial. Requerimientos Los resultados a imprimir sern extrados de no funcionales: un archivo de texto.

Proveedor :

Modulo de Reportes.

Documento General

28

Figura N 7 Plantilla del Servicio: Imprimir Resultados.

Diagrama de Casos de Uso Esta es una tcnica basada en el uso de escenarios, en donde los usuarios dan ejemplos de las acciones que desean realizar al momento de interactuar con el sistema, lo que permite modelar su comportamiento, ya que se puede visualizar grficamente cada una de estas interacciones, la relacin que existe entre ellas, y quien llevar a cabo determinada interaccin, todo esto sin importar como ser implementada. En resumen los diagramas de casos de uso nos ayudas a describir las funciones del sistema y a complementar el enfoque basado en el punto de vista de los usuarios. Para el diseo del diagrama de casos de uso mostrado en la figura N 8 se siguieron los pasos indicados a continuacin.

Paso 1. Identificar los actores que interactuar con el sistema. Paso 2. Seleccionar un actor. Paso 3. Que quiere hacer el actor con el sistema? (caso de uso) Paso 4. Para cada caso Que pasa? (inclusiones) Paso 5. Describirlo textualmente. Paso 6. Considerar las alternativas para cada de uso (exclusiones). Paso 7. Encontrar casos comunes o generales (generalizaciones). Paso 8. Repetir los pasos del 2 al 7 con todos los actores.

Documento General

29

Como se menciono en el mtodo VORD solo se construyeron los casos de uso para un solo actor, tal como se muestra en la siguiente futuro.

Documento General

30

Continuar Normalizar 6 Iniciar 7 Detener 8

11

Seleccionar Mtodo

Graficar Solucin

5 Alterar 9

Retroceder Probar el Modelo 1 Anotar Observaciones 12

10

Seleccionar Modelo 2 Capturar Parmetros 3

Generar Reporte

13

Documento General

31

Figura N 8 Diagrama de Casos de Uso.

Documento General

32

Diagrama de Secuencias Esta es otra tcnica que se basa en escenarios y que permite agregar informacin a un caso de uso. En este diagrama se muestran los actores que interactan con el sistema los objetos con que se puede interactuar y las operaciones asociadas con otros objetos. Si el modelo que se piensa adoptar para el diseo y desarrollo del sistema es orientado a objetos, este diagrama resulta un buen punto de partida para identificar las futuras clases a disear.

Interfaz
Solicitar(Modelo)

Modelo
Modelo

Mtodo

Generador de Grficos

Libreta

Generador de Reportes

Parametrizar Enviar(Modelo) Iniciar Modelo Solucin Simulacin Parar Perturbar Continuar Modelo Solucin Simulacin Finalizar Anotar Anotacin Solicitar (Reporte) Reporte Solicitar Enviar (Reporte) Anotacin Observacin

Figura N 9 Diagrama de Secuencias.

Documento General

33

Definicin de Requerimientos
En esta seccin se definen los requerimientos funcionales y no funcionales del usuario. Estos requerimientos son presentados en lenguaje natural estructurado y se les ha agregado el fundamento que soporta cada requerimiento. Requerimientos del Usuario Funcionales 1.- El sistema debe permitir que el usuario pruebe un modelo determinado. Fundamento: Antes de que un modelo se pueda aplicar, necesariamente debe ser probado, y el usuario es la persona ms indicada para hacerlo, ya que este debe conocer el proceso real que se desea simular, lo que le permitir inferir conclusiones de que tan seguro es utilizar el modelo propuesto, a partir de la observacin de la solucin del modelo y de la comparacin con la salida del sistema real. 1.1.- Preparar el escenario de prueba. 1.1.1.- El sistema debe permitir que el usuario seleccione el modelo que se desea probar. 1.1.2- El sistema debe permitir ingresar los parmetros iniciales del modelo seleccionado. 1.1.3.- El sistema debe permitir el usuario seleccione un mtodo para solucionar el modelo. Fundamento: Debido a que en la organizacin pueden existir o surgir varios procesos de inters que se desean simular, el usuario debe adaptar el ambiente de prueba para el modelo que desea probar. 1.2. Presentacin de la solucin del modelo 1.2.1.- La solucin del modelo debe ser presentada grficamente. 1.2.1.- El sistema debe permitir que el usuario visualice como se va construyendo la solucin grfica. 1.2.2.- El sistema debe permitir normalizar la solucin grafica

Documento General

34

Fundamento: Considerando que la base de la prueba es comparar el comportamiento del modelo con la salida del sistema real, la mejor forma es representar la solucin del modelo grficamente.

1.3. Herramientas para probar el Modelo 1.3.1.- El usuario puede iniciar la graficacin de la solucin. 1.3.2.- El usuario puede detener la graficacin de la solucin. 1.3.3.- El usuario puede cambiar los parmetros del modelo durante la simulacin. 1.3.3.- El sistema debe permitir tomar fotos de la graficacin de la solucin. 1.3.4.- El usuario puede retroceder a una solucin grafica previa. 1.3.5.- El usuario puede reiniciar la graficacin de la solucin. Fundamento: Como se menciono anteriormente la mejor forma de validar el modelo es comparar la salida real y la calculada mediante la simulacin, es por ello que el sistema debe proveer al usuario un conjunto de herramientas que permitan que este visualice detalladamente el comportamiento del modelo, tanto en condiciones normales, como perturbado, y as poder inferir conclusiones de que tan seguro es aplicar el modelo probado.

2.- El sistema debe permitir que se obtenga un reporte de los resultados de la prueba. 2.1.- El sistema debe permitir que el usuario realice anotaciones durante la prueba del modelo. 2.2.- El sistema debe permitir que las observaciones sean guardadas. 2.3. El sistema debe permitir que el usuario modifique las anotaciones. 2.4. El sistema debe permitir que el usuario consulte anotaciones anteriores. 2.5. El sistema debe permitir obtener un reporte impreso de las anotaciones.

Documento General

35

Fundamento: Durante la prueba del modelo el usuario infiere un conjunto de observaciones que es recomendable anotar, una forma prctica de hacerlo es a travs del mismo sistema, de forma que el usuario pueda revisar luego estas anotaciones con ms calma y con el resto de su equipo de trabajo, a pesar de que los mismos no hayan estado presentes en la prueba, una manera de hacer esto es obteniendo un reporte impreso de dichas observaciones.

No Funcionales 3.- La solucin grfica debe ser presentada en colores que permitan visualizar claramente la simulacin. 3.1.- El sistema debe permitir que el usuario pueda cambiar estos colores. Fundamento: El xito de la prueba depende de el usuario pueda observar el comportamiento del modelo de la forma ms clara posible, por lo tanto el es el indicado para seleccionar los colores ms agradables a su vista, que lo provean una mejor visualizacin del comportamiento del modelo. 4.- El usuario puede cambiar la escala en que ser presentada la solucin grfica. Fundamento: Al igual que en el fundamento anterior este requerimiento esta orientado a proveer de acuerdo al criterio del usuario, una mejor visualizacin del comportamiento del modelo. 5.- El tiempo en que se representa la solucin grfica no se considera una restriccin del sistema. Fundamento: Debido a que la simulacin no esta orientada a representar un sistema de tiempo real y que una de las motivaciones del desarrollo del sistema es probar diferentes modelos observando su comportamiento, la rapidez con que se muestra la solucin no representa una limitante. 6.- El tiempo en que se toman las fotos que contienen parte de la solucin grfica puede ser cambiado por el usuario. Fundamento: El usuario es quien debe establecer las pautas a seguir para probar el modelo, por lo tanto el sistema le debe proveer las facilidades necesarias que le permitan adaptar la prueba a sus necesidades.

Documento General

36

7.- El sistema debe ser desarrollado en un lenguaje de programacin que permita crear programas ejecutables. Fundamento: Esto le dar mayor portabilidad al sistema, ya que no lo ligara con una herramienta de software especfica, y le permitir probar modelos ms complejos que dependan de la capacidad del hardware utilizado y no de una herramienta de software especfica.

8.- El usuario realizar las anotaciones de la prueba, en una ventana de texto. 8.1- El usuario podr abrir y cerrar esta ventana. 8.2.- El usuario podr mover la ventana. 8.3.- El usuario podr cambiar el tamao de la ventana. Fundamento: Debido a que lo ideal es que el usuario realice sus observaciones durante la prueba del modelo, es recomendable que este pueda cambiar el entorno en donde va a anotar dichas observaciones. 9.- Las observaciones de la prueba sern guardadas en un archivo de texto. Fundamento: Los archivos de texto son un estndar que puede ser editados fcilmente por otros editores de texto, y este formato tambin facilita y hace ms rpida la impresin del reporte. 10.- El sistema debe proveer ventanas de ayuda que faciliten el uso del sistema. Fundamento: El uso de todo nuevo sistema al principio puedes resultar complejo, es por ello que el sistema debe contar con los medios necesarios que guen al usuario al operar el mismo.

Documento General

37

Especificacin de Requerimientos
En esta seccin se presentan descripciones ms detalladas de los requerimientos del usuario, y representan el punto de partida para la siguiente etapa que es el diseo del sistema. En el presente proyecto fue seleccionada la metodologa VOLARE para especificar los requerimientos del sistema. Esta se basa en especificaciones en lenguajes estructurado presentadas en plantillas. La ventaja de este enfoque es que mantiene mucha de la expresividad y comprensin del lenguaje natural y asegura que cierto grado de uniformidad se imponga a la especificacin.

Requerimientos Funcionales
Requerimiento: # 1 Tipo de Evento/caso de uso #: 1 requerimiento: 9 Descripcin: El sistema debe permitir probar un modelo de inters para el usuario. Razn: Analizar que tan seguro es el modelo probado, para determinar si debe ser o no utilizado. Fuente: Coordinador del Proyecto Criterio de La funcionalidad del modelo una vez aprobado y utilizado. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Los modelos a probar deben estar Conflictos: No existen conflictos representados como ecuaciones algebraicas diferenciales. Materiales de apoyo: Diagrama de Casos de Uso Historia: Creado el 31 de Octubre del 2004

Requerimiento: # 1.1

Tipo de Evento/caso de uso #: 1,2 requerimiento: 9 Descripcin: El sistema debe permitir que el usuario pruebe diferentes modelos. Razn: Ahorrar costos en el desarrollo de diferentes sistemas para probar un modelo especifico. Fuente: Coordinador del Proyecto Criterio de Que el usuario pueda seleccionar el modelo que desea probar. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Los modelos a probar deben estar Conflictos: No existen conflictos representados como ecuaciones algebraicas diferenciales. Materiales de apoyo: Diagrama de Casos de Uso Historia: Creado el 1 de Noviembre del 2004

Documento General

38

Requerimiento: # 1.2

Tipo de Evento/caso de uso #: 1,3 requerimiento: 9 Descripcin: El sistema debe permitir que el usuario configure el modelo que desea probar. Razn: Permite ensayar un conjunto de casos a travs del mismo modelo Fuente: Coordinador del Proyecto Criterio de Que el usuario pueda parametrizar el modelo que desea probar. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Los modelos a probar deben estar Conflictos: No existen conflictos representados como ecuaciones algebraicas diferenciales. Materiales de apoyo: Diagrama de Casos de Uso Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 1.3

Tipo de Evento/caso de uso #: 1,4 requerimiento: 9 Descripcin: El sistema debe permitir solucionar el modelo a travs de diferentes mtodos numricos. Razn: Que el usuario verifique cual es la solucin que representa mejor la salida real. Fuente: Coordinador del Proyecto Criterio de Que el usuario pueda seleccionar el mtodo numrico con que desea solucionar el medida: Modelo. Satisfaccin del cliente: 4 Insatisfaccin del cliente: 4 Dependencias: Los mtodos numricos seleccionados deben Conflictos: No existen conflictos solucionar modelos representados como ecuaciones algebraicas diferenciales. Materiales de apoyo: Diagrama de Casos de Uso. Seccin de Fundamentos Bsicos Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 1.4

Tipo de Evento/caso de uso #: 1,5 requerimiento: 9 Descripcin: La solucin del modelo debe representarse grficamente. Razn: Es la mejor forma de observar el comportamiento del modelo. Fuente: Coordinador del Proyecto Criterio de Que se pueda visualizar la solucin grafica del modelo. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo cuente con Conflictos: No existen conflictos libreras adecuadas para la representacin grfica.

Documento General

39

Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 1.5

Tipo de Evento/caso de uso #: 1,5 requerimiento: 9 Descripcin: El sistema debe construir la solucin grafica en forma dinmica. Razn: Que el usuario pueda observar detalladamente el comportamiento del modelo. Fuente: Coordinador del Proyecto Criterio de Que el usuario pueda observar como se va construyendo grficamente la solucin del medida: Modelo. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo cuente con Conflictos: No existen conflictos libreras adecuadas para la representacin grfica. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 1.6

Tipo de Evento/caso de uso #: 1,5,6 requerimiento: 9 Descripcin: El sistema debe permitir normalizar la solucin grafica del modelo. Razn: Que el usuario pueda visualizar la solucin grafica en una escala adecuada. Fuente: Coordinador del Proyecto Criterio de Que la solucin grafica se pueda mostrar completa en la pantalla. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 4 Dependencias: Desarrollar las rutinas necesarias para Conflictos: No existen conflictos normalizar la solucin del modelo antes de graficarla. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 1.7

Tipo de Evento/caso de uso #: 1,7,8,9,10,11 requerimiento: 9 Descripcin: El sistema debe proveer las funciones necesarias para probar el modelo. Razn: Sin estas funciones el proceso de validacin no ser seguro. Fuente: Coordinador del Proyecto Criterio de La cantidad y el tipo de funciones que ofrece el sistema para probar el modelo. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que las funciones propuestas puedan ser Conflictos: No existen conflictos desarrolladas con la herramienta de desarrollo seleccionada.

Documento General

40

Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.1

Tipo de Evento/caso de uso #: 1,7 requerimiento: 9 Descripcin: El sistema debe tener una funcin que permita iniciar la simulacin. Razn: Poder controlar el proceso de simulacin. Fuente: Coordinador del Proyecto Criterio de Verificar que la solucin inicial se corresponda con los parmetros iniciales. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que el modelo acepte un estado inicial de Conflictos: No existen conflictos partida. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.2

Tipo de Evento/caso de uso #: 1,8 requerimiento: 9 Descripcin: El sistema debe tener una funcin que permita detener la simulacin. Razn: Poder controlar el proceso de simulacin. Fuente: Coordinador del Proyecto Criterio de Que la solucin grafica se detenga una vez que se active esta funcin. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que el modelo se pueda resolver Conflictos: No existen conflictos parcialmente. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 3 de Noviembre del 2004

Requerimiento: # 1.7.3

Tipo de Evento/caso de uso #: 1,9 requerimiento: 9 Descripcin: El sistema debe tener una funcin que permita cambiar los parmetros del modelo durante la simulacin Razn: Poder controlar el proceso de simulacin y ver como responde ante nuevas condiciones Fuente: Coordinador del Proyecto Criterio de Verificar que la solucin grafica se represente correctamente una vez introducidos los medida: nuevos parmetros. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5

Documento General

41

Dependencias: Que el modelo se pueda resolver correctamente a partir de los nuevos parmetros Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 3 de Noviembre del 2004

Conflictos: No existen conflictos

Requerimiento: # 1.7.4

Tipo de Evento/caso de uso #: 1,10 requerimiento: 9 Descripcin: El sistema debe permitir el fotografiado periodico de la solucin grfica. Razn: Capturar soluciones graficas previas a las que el usuario pueda retroceder y observar nuevamente, sin tener que graficar desde el inicio la solucin. Fuente: Coordinador del Proyecto Criterio de Verificar si la foto tomada se corresponde con la solucin grafica presentada previamente medida: en tiempo de ejecucin Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo provea las Conflictos: No existen conflictos libreras necesarias para llevar a cabo esta funcin. Materiales de apoyo: Diagrama de Casos de Uso. Seccin de Fundamentos Bsicos Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 1.7.5

Tipo de Evento/caso de uso #: 1,10 requerimiento: 9 Descripcin: El sistema debe tener una funcin que permita retroceder a un estado anterior de la simulacin. Razn: Poder controlar el proceso de simulacin y visualizar nuevamente una parte de la misma. Fuente: Coordinador del Proyecto Criterio de Verificar si a la etapa de la simulacin a donde se retrocedi, forma parte de la solucin medida: parcial del modelo. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que se pueda realizar el fotografiado Conflictos: Requerimiento 1.7.4 periodico. Materiales de apoyo: Diagrama de Casos de Uso. Seccin de Fundamentos Bsicos Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 1.7.6

Tipo de Evento/caso de uso #: 1,11 requerimiento: 9 Descripcin: El sistema debe tener una funcin que permita continuar la simulacin Razn: Poder controlar el proceso de simulacin, y observar como se comporta el modelo despus de haber sido detenida la simulacin.

Documento General

42

Fuente: Coordinador del Proyecto Criterio de Verificar que la solucin grafica se construya a partir de donde se detuvo la simulacin. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que el modelo acepte un estado inicial de Conflictos: No existen conflictos partida. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 4 de Noviembre del 2004

Documento General

43

Requerimiento: # 2

Tipo de Evento/caso de uso #: 1,12,13 requerimiento: 9 Descripcin: El sistema debe permitir que se obtenga un reporte impreso de los resultados de la prueba. Razn: Facilitar el anlisis posterior a la prueba del modelo. Fuente: Coordinador del Proyecto Criterio de Obtener el reporte impreso, tal cual como se edito durante la prueba. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Debe existir un archivo en donde estn Conflictos: Requerimientos 2.2 almacenadas las observaciones que corresponden al reporte que se desea imprimir. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 5 de Noviembre del 2004

Requerimiento: # 2.1

Tipo de Evento/caso de uso #: 1,12 requerimiento: 9 Descripcin: El sistema debe proveer un medio para que el usuario pueda escribir las observaciones de la prueba on-line durante la simulacin. Razn: Facilitar el anlisis posterior a la prueba del modelo. Fuente: Coordinador del Proyecto Criterio de Que las observaciones anotadas, se correspondan con el reporte impreso. medida: Satisfaccin del cliente: 4 Insatisfaccin del cliente: 4 Dependencias: Que se pueda detener la simulacin para Conflictos: Requerimiento 1.7.2 anotar estas observaciones. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 2.2

Tipo de Evento/caso de uso #: 1,12 requerimiento: 9 Descripcin: El sistema debe permitir almacenar las observaciones en un medio de almacenamiento secundario. Razn: Proveer el medio necesario para extraer la informacin contendr el reporte impreso. Fuente: Coordinador del Proyecto Criterio de Verificar que se haya creado el archivo correspondiente. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que se pueda importar la informacin Conflictos: No existen conflictos editada en memoria principal a memoria secundaria. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 6 de Noviembre del 2004

Documento General

44

Requerimiento: # 2.3

Tipo de Evento/caso de uso #: 1,12 requerimiento: 9 Descripcin: El sistema debe permitir que se puedan modificar las observaciones. Razn: Corregir observaciones previas. Fuente: Coordinador del Proyecto Criterio de Verificar que el archivo contenga las ltimas modificaciones realizadas medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 4 Dependencias: Que se pueda importar la informacin Conflictos: Requerimiento 2.2 editada en memoria principal a memoria secundaria. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 2.4

Tipo de Evento/caso de uso #: 1,12 requerimiento: 9 Descripcin: El sistema debe permitir que se consulten observaciones de pruebas realizadas anteriormente. Razn: Corroborar si las observaciones anteriores se corresponden con los criterios actuales del usuario. Fuente: Coordinador del Proyecto Criterio de Verificar que el archivo contenga las ltimas modificaciones realizadas medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 4 Dependencias: Que se pueda importar la informacin Conflictos: Requerimiento 2.2 editada en memoria principal a memoria secundaria. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 7 de Noviembre del 2004

Documento General

45

Requerimientos No Funcionales

Requerimiento: # 3

Tipo de Evento/caso de uso #: 1,5 requerimiento: 10a Descripcin: La interfaz grfica en la que se muestra la solucin del modelo, debe presentarse por defecto en colores agradables a la vista del usuario, donde exista un claro contraste entre el fondo de la pantalla y la solucin grafica. Razn: Evitar producir cansancio en la vista del usuario, ya que esto podra dificultar la observacin adecuada de la prueba del modelo. Fuente: Coordinador del Proyecto Criterio de Consultar al usuario con respecto al cansancio de su vista, tras varias sesiones de medida: prueba. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo cuente con Conflictos: No existen conflictos libreras adecuadas para modificar los colores de la representacin grfica. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 1 de Noviembre del 2004

Requerimiento: # 3.1

Tipo de requerimiento: Evento/caso de uso #: 1,5 10a,11b Descripcin: El usuario puede modificar los colores por defecto de la solucin grafica. Razn: Que el usuario pueda adecuar el ambiente de graficacin de la prueba de acuerdo a sus preferencias, lo que lo har sentir ms a gusto al momento de realizar las pruebas del modelo. Fuente: Coordinador del Proyecto Criterio de Que el usuario pueda utilizar los colores de su preferencia. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo cuente con Conflictos: No existen conflictos libreras adecuadas para modificar los colores de la representacin grfica. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 1 de Noviembre del 2004

Documento General

46

Requerimiento: # 4

Tipo de requerimiento: Evento/caso de uso #: 1,5 10a,11b Descripcin: El usuario puede modificar la escala en que se representa la solucin grafica del modelo. Razn: Que el usuario pueda adecuar el ambiente de graficacin de la prueba de acuerdo a sus preferencias, y que de acuerdo pueda observar mejor el comportamiento del modelo. Fuente: Coordinador del Proyecto Criterio de Que el usuario pueda realizar los cambios deseados. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo cuente con Conflictos: No existen conflictos libreras adecuadas para modificar loa escala de la representacin grfica. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 5

Tipo de requerimiento: Evento/caso de uso #: 1,5 12a Descripcin: El tiempo en que se grafica la solucin del modelo no representa una limitante del sistema. Razn: La simulacin no esta orientada a representar un sistema de tiempo real, sino a estudiar el detalladamente el comportamientos del modelo. Fuente: Coordinador del Proyecto Criterio de Verificar que la salida del modelo sea graficada correctamente sin importar el tiempo en medida: que sea graficada. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo cuente con Conflictos: No existen conflictos libreras adecuadas para representar la solucin grfica del modelo correctamente. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 2 de Noviembre del 2004

Requerimiento: # 6

Tipo de requerimiento: Evento/caso de uso #: 1,5,10 11b

Documento General

47

Descripcin: Los intervalos de tiempo en que se realiza el fotografiado periodico se pueden configurar. Razn: Aumentar el grado de precisin de la prueba. Fuente: Coordinador del Proyecto Criterio de Que la cantidad de estados capturados se corresponda con el intervalo de tiempo medida: Seleccionado y el tiempo de la prueba. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: El mnimo intervalo de tiempo seleccionado, Conflictos: No existen conflictos debe ser mayor al tiempo en que se genera y muestra la solucin grafica. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 4 de Noviembre del 2004

Requerimiento: # 7

Tipo de requerimiento: Evento/caso de uso #: 1,10 14d Descripcin: Las fotos deben ser guardadas en archivos tipo jpg o gif. Razn: La portabilidad que ofrece este tipo de formatos Fuente: Coordinador del Proyecto Criterio de Verificar que los archivos creados puedan ser abiertos con herramientas orientadas a medida: procesar este tipo de archivos. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo provea los Conflictos: No existen conflictos mecanismos necesarios para la creacin de archivos de este tipo. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 5 de Noviembre del 2004

Documento General

48

Requerimiento: # 8

Tipo de requerimiento: Evento/caso de uso #: 14d, 12f Descripcin: El sistema debe ser desarrollado en un lenguaje de alto nivel y no en una herramienta como SIMULINK. Razn: Que el sistema pueda solucionar modelos complejos, que no pueden ser resueltos con herramientas como SIMULINK. Fuente: Coordinador del Proyecto Criterio de Verificar que el sistema resuelva correctamente modelos complejos medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo permita Conflictos: No existen conflictos desarrollar rutinas eficientes para la aplicacin de los mtodos numricos seleccionados. Materiales de apoyo: Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 9

Tipo de requerimiento: Evento/caso de uso #: 12 10a Descripcin: El sistema debe permitir que se active una ventana de texto usuario puede escribir las observaciones correspondientes a la prueba que esta realizando en ese momento. Razn: Proveer un mecanismo prctico para que el usuario lleve a cabo esta operacin. Fuente: Coordinador del Proyecto Criterio de Verificar que la ventana se pueda activar durante la prueba del modelo. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo este Conflictos: No existen conflictos orientada a un ambiente visual Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 6 de Noviembre del 2004

Requerimiento: # 9.1

Tipo de requerimiento: Evento/caso de uso #: 12 12g Descripcin: La ventana de edicin debe permitir el scroll-back. Razn: Procesar el volumen del texto escrito por el usuario sin importar su tamao. Fuente: Coordinador del Proyecto Criterio de Verificar que el texto escrito se desplace correctamente a medida que se va llenando la medida: ventana. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo este Conflictos: No existen conflictos orientada a un ambiente visual. Materiales de apoyo: Diagrama de Casos de Uso. Seccin de Fundamentos Bsicos. Historia: Creado el 7 de Noviembre del 2004

Documento General

49

Requerimiento: # 9.2

Tipo de requerimiento: Evento/caso de uso #: 12 10a, 11a Descripcin: El sistema debe permitir que el usuario active y desactive la ventana de edicin. Razn: Hacer mas sencillo al usuario la utilizacin de esta herramienta. Fuente: Coordinador del Proyecto Criterio de Que la ventana aparezca y desaparezca cuando se activen los mecanismos adecuados medida: (click del ratn) Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo este Conflictos: No existen conflictos orientada a un ambiente visual. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 9.3

Tipo de requerimiento: Evento/caso de uso #: 12 10a, 11a Descripcin: El sistema debe permitir que el usuario mueva la ventana de edicin. Razn: Hacer mas sencillo al usuario la utilizacin de esta herramienta. Fuente: Coordinador del Proyecto Criterio de Que la ventana se mueva cuando se activen los mecanismos adecuados (arrastre a travs medida: del ratn) Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo este Conflictos: No existen conflictos orientada a un ambiente visual. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 7 de Noviembre del 2004

Requerimiento: # 9.4

Tipo de requerimiento: Evento/caso de uso #: 12 10a, 11a, 11b Descripcin: El sistema debe permitir que el usuario configure el tamao de la ventana de edicin. Razn: Hacer mas sencillo al usuario la utilizacin de esta herramienta. Fuente: Coordinador del Proyecto Criterio de Que la ventana cambie de tamao va cuando se activen los mecanismos adecuados medida: ( a travs del ratn) Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo este Conflictos: No existen conflictos orientada a un ambiente visual. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 9 de Noviembre del 2004

Documento General

50

Requerimiento: # 10

Tipo de requerimiento: Evento/caso de uso #: 12,13 12a, 14d Descripcin: Las anotaciones de la ventana deben ser almacenadas en un archivo de texto. Razn: La portabilidad que ofrece este tipo de formatos, y por la rapidez con que se pueden imprimir. Fuente: Coordinador del Proyecto Criterio de Verificar que los archivos creados puedan ser abiertos con herramientas orientadas a medida: procesar este tipo de archivos. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo provea los Conflictos: No existen conflictos mecanismos necesarios para la creacin de archivos de texto. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 10 de Noviembre del 2004

Requerimiento: # 10.1

Tipo de requerimiento: Evento/caso de uso #: 12,13 11a Descripcin: Las archivos de texto almacenados deben guardar por defecto la fecha de creacin y un nmero que identifique el modelo que se esta probando en ese momento. Razn: Facilidad para que el usuario pueda relacionar la informacin contenida en el archivo con el modelo que desea analizar. Fuente: Coordinador del Proyecto Criterio de Verificar que los archivos creados guarden esta informacin. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Desarrollar la rutinas de programacin que Conflictos: No existen conflictos anexen automticamente esta informacin al archivo de texto. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 10 de Noviembre del 2004

Requerimiento: # 10.2

Tipo de requerimiento: Evento/caso de uso #: 12,13 11a Descripcin: El nombre con que se guarda el archivo de texto, se creara por defecto con el nmero que identifica el modelo que se esta probando, concatenado con la fecha de creacin. Razn: Facilidad para ubicar el archivo e imprimirlo. Fuente: Coordinador del Proyecto Criterio de Verificar que los archivos creados se guardan con estos parmetros. medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Desarrollar la rutinas de programacin que Conflictos: No existen conflictos permitan crear los archivos de esta forma .

Documento General

51

Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 11 de Noviembre del 2004

Requerimiento: # 11

Tipo de requerimiento: Evento/caso de uso #: 1,5 12c Descripcin: El sistema debe proveer una buena precisin en la graficacin de la solucin Razn: El xito o fracaso de la prueba depende de la observacin del comportamiento de la prueba, por lo tanto los resultados de la solucin del modelo deben graficarse con la mayor precisin posible. Fuente: Coordinador del Proyecto Criterio de Verificar la graficacin de la solucin de modelos caractersticos, donde ya se conoce su medida: salida. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo provea las Conflictos: No existen conflictos funciones adecuadas para calcular y graficar con precisin las soluciones del modelo. Materiales de apoyo: Diagrama de Casos de Uso. Historia: Creado el 12 de Noviembre del 2004

Requerimiento: # 12

Tipo de requerimiento: Evento/caso de uso #: 11a Descripcin: El sistema debe permitir que el usuario etiquete las entradas de las variables del modelo. Razn: Facilidad para que el usuario pueda utilizar el sistema, ya que las etiquetas de las variables permiten relacionar mejor el modelo con el sistema real que se pretende simular. Fuente: Coordinador del Proyecto Criterio de Ninguno medida: Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5 Dependencias: Que la herramienta de desarrollo este Conflictos: No existen conflictos orientada a un ambiente visual. Materiales de apoyo: Historia: Creado el 13 de Noviembre del 2004

Requerimiento: # 13

Tipo de requerimiento: Evento/caso de uso #: 11a Descripcin: El sistema debe proveer una ventana de ayuda al usuario, por cada uno de los mdulos presentados. Razn: Facilidad para que el usuario pueda utilizar el sistema. Fuente: Coordinador del Proyecto Criterio de Verificar que los la informacin contenida en cada ventana, se relaciones con el uso del medida: modulo en donde fueron activadas. Satisfaccin del cliente: 5 Insatisfaccin del cliente: 5

Documento General

52

Dependencias: Que la herramienta de desarrollo este orientada a un ambiente visual. Materiales de apoyo: Historia: Creado el 13 de Noviembre del 2004

Conflictos: No existen conflictos

Validacin y Administracin de Requerimientos

La validacin y administracin de los requerimientos se fundamento en determinar si los requerimientos eran verificables, comprensibles, rasteables y adaptables. Para ello se establecieron reuniones entre los stakeholders y el grupo de trabajo, y se realizaron presentaciones pblicas de los avances del proyecto, donde participaron los stakeholders, el grupo de trabajo y desarrolladores de otros proyectos, en estas presentaciones se atendieron las dudas y consultas tanto de los stakeholder y de los desarrolladores invitados, de igual forma de grupo trabajo asisti a las presentaciones de otros proyectos, lo que sirvi como punto de comparacin y fuente para extraer aspectos comunes de proyectos diferentes. Otras de las estrategias utilizadas aparte de las revisiones formales e informales realizadas, fue la utilizacin de una matriz de rastreo de requerimientos, la cual permiti vincular requerimientos con otros requerimientos y establecer la dependencia existente entre los mismos. La notacin utilizada consisti en usar una U para establecer una relacin fuerte entre los requerimientos, e indicar que el requerimiento de la fila utilizaba los requerimientos sealados en la columna. Mientras que una R significaba exista una relacin dbil entre los requerimientos. La aplicacin de este tipo de estrategia fue posible debido a que el nmero de requerimientos a administrar fue relativamente pequeo y por lo tanto no hizo falta capturar la informacin de rastreo en una base de datos de requerimientos. En la tabla N 7 se muestran los resultados de la revisin, que determinaron si los requerimientos eran verificables, comprensibles y adaptables, mientras que en la tabla N 8 se muestra la matriz de rastreo que permiti determinar si los requerimientos eran rasteables y evaluar el impacto del cambio en los requerimientos de acuerdo a la dependencia existente entre los mismos.

Documento General

53

Verificable Requerimiento 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.7.1 1.7.2 1.7.3 1.7.4 1.7.5 1.7.6 2 2.1 2.2 2.3 2.4 3 3.1 4 5 6 7 8 9 9.1 9.2 9.3 9.4 10 10.1 10.2 11 12 Si X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X No

Comprensible Si X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X No

Adaptable Si No X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Documento General

54

13

Tabla N 7 Validacin de los Requerimientos.

Documento General

55

R e q .
1 1 . 1 1 . 2 1 . 3 1 . 4 1 . 5 1 . 6 1 . 7 1 . 7 . 1 1 . 7 . 2 1 . 7 . 3 1 . 7 . 4 1 . 7 . 5 1 . 7 . 6 2 2 . 1 2 . 2 2

1 . 1

1 . 2

1 . 3

1 . 4

1 . 5

1 . 6

1 . 7

1 . 7 . 1

1 . 7 . . 2

1 . 7 . . 3

1 . 7 . 4

1 . 7 . . 5

1 . 7 . . 6

2 . 1

2 . 2

2 . 3

2 . 4

3 . 1

9 . 1

9 . 2

9 . 3

9 . 4

1 0

1 0 . 1

1 0 . 2

1 1

1 2

1 3

R R

R U

Documento General

56

. 3 2 . 4 3 3 . 1 4 5 6 7 8 9 9 . 1 9 . 2 9 . 3 9 . 4 1 0 1 0 . 1 1 0 . 2 1 1 1 2 1 3

R R

R U R R R U R

R R

R U U

Tabla N 8 Matriz de Rastreo de los Requerimientos.

Documento General

57