ejemplo 2 - proyecto - documento general factinv_luis.pdf

7/17/2019 Ejemplo 2 - Proyecto - Documento General FACTINV_luis.pdf

1/58

Documento General 1

PROYECTO:

SISTEMA DE FACTURACION E INVENTARIO

(FACTINV)

DOCUMENTO GENERAL


2/58

Documento General 2

Contenido

INTRODUCCION .......................................................................................................... 3MOTIVACION ............................................................................................................... 4OBJETIVO .................................................................................................................... 5GLOSARIO DE TERMINOS ......................................................................................... 7PRIMERA PARTE: ....................................................................................................... 8

ADMINISTRACIN DEL PROYECTO .......................................................................... 8Introduccin ................................................................................................................... 9Objetivo ........................................................................................................................ 10Grupo de Trabajo ......................................................................................................... 10Modelo del Proceso de Software .................................................................................. 10

Planeacin .................................................................................................................... 12Requerimientos de recursos de Hardware y Software ............................................. 12Definicin de Actividades ........................................................................................ 14Calendarizacin del Proyecto ................................................................................... 16

Administracin de Riesgos ........................................................................................... 20SEGUNDA PARTE: .................................................................................................... 24

REQUERIMIENTOS DEL SISTEMA ............................................................................ 24Introduccin ................................................................................................................. 25Estudio de Factibilidad ................................................................................................. 26

Factibilidad Econmica ............................................................................................ 26Factibilidad Operativa .............................................................................................. 26

Factibilidad Tcnica ................................................................................................. 26Obtencin y Anlisis de Requerimientos ..................................................................... 27Mtodo VORD ......................................................................................................... 27


3/58

Documento General 3

INTRODUCCION

La simulacin asistida por computador consiste bsicamente en construir modelosinformticos que describen la parte esencial del comportamiento de un sistema de inters,y proceder a experimentar con estos modelos, para extraer conclusiones de susresultados que permitan apoyar la toma de decisiones. La simulacin ha crecido comouna metodologa de experimentacin fundamental en campos tan diversos como laEconoma, la Estadstica, la Informtica o la Fsica y con enormes aplicacionesindustriales y comerciales, como los simuladores de vuelo, los juegos de simulacin, losprocesos industriales, o la prediccin burstil o meteorolgica. En lo que respecta almbito industrial la simulacin de procesos es una las herramientas ms utilizadas por laingeniera industrial, por lo general una vez que se detecta que cierto sistema de intersno opera en forma adecuada, se plantea al ingeniero la forma de mejorar elfuncionamiento 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 ademstendr que interrumpir el funcionamiento actual de las operaciones que ejecuta el sistemadentro 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 delmodelo est asociado a factores como la definicin de las variables relevantes queexplican el sistema, la interrelacin de estas en el modelo y el nivel en que el modelorepresenta el sistema real. En trminos generales, un modelo debe ser unarepresentacin aceptable de la realidad, es decir, debe existir una buena correlacin entrelo que predice el modelo y lo que sucede en la realidad. Para tener la certeza de que se aalcanzado esta correlacin, resulta indispensable realizar un proceso de validacin. Eldesarrollo del sistema de informacin propuesto, esta orientado a proporcionar unambiente de prueba, que permita validar modelos representados como ecuaciones

algebraicas diferenciales, capaces de representar en forma adecuada gran parte de losprocesos 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). Eldocumento se encuentra dividido en cinco partes principales, como a continuacin sedescribe:

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.


4/58

Documento General 4

MOTIVACION

Para que todo proceso de simulacin sea til, es necesario que el modelo sea unarepresentacin aceptable de la realidad, es decir, debe existir una buena correlacin entrelo que se simula y lo que sucede en la realidad, y para establecer adecuadamente estacorrelacin resulta indispensable realizar un proceso de validacin. La validacin de unmodelo es un problema, relativamente complejo. Si se dice que un modelo es correcto ovlido, significa que est representando en forma adecuada el sistema real, pero es obvioque nunca se puede estar absolutamente seguro y ningn modelo, por ms sofisticadoque sea, puede representar exactamente la realidad, y siempre ser una aproximacin delsistema real. Por lo tanto se considera que en el proceso de validacin de un modelo, setrata de obtener el mayor grado de confianza posible para su uso. En trminos generalesla 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 estodepender 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 seanindependientes del modelo que se desea validar, lo que permitir aplicarlas a variosmodelos que pretenden simular diferentes procesos industriales de inters y mientrasmenos 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 procesosindustriales, y que el proceso de validacin de un modelo es indispensable para que estesea aplicado en forma segura, resulta sumamente interesante abstraer el proceso devalidacin, ganando as generalidad en dicho proceso, esto permitir reducir los costos deprueba, 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 posiblesdel modelo, los resultados obtenidos sern mucho ms confiables, estas doscaractersticas generalidad para reducir costos y confiabilidad en los resultados obtenidos,constituyen sin duda alguna la motivacin principal para desarrollar el sistema deinformacin propuesto.


5/58

Documento General 5

OBJETIVO

El objetivo del presente proyecto es el desarrollo de un sistema de Facturacin eInventario para un negocio dedicado a la compra y venta de hules industriales yautomotrices, el negocio desea llevar control y mantener actualizados susregistros de adquisiciones, ventas, proveedores, clientes e inventario de productosen bodega.

En la figura 1, se presenta el diagrama lgico del sistema.

Figura 1 Diagrama lgico d el sistema de Facturacin e Inventario.

COMPRAS

VENTAS

INVENTARIO

CLIENTES

PROVEEDORESADMINISTRACION

DE

CLIENTES Y

COMPRAS YVENTAS

CONTROL DEINVENTARIO

REPORTES

SISTEMA PRINCIPAL


6/58

Documento General 6


7/58

Documento General 7

GLOSARIO DE TERMINOS

Trmino Descripcin

FACTINV Sistema de Facturacin e InventarioBD Base de DatosCASE Computer-Aided Systems Engineering, traduccin

Ingeniera de Sistemas Asistida por ComputadoraRtS Real Time Studio, traduccin Estudio en Tiempo RealWBS Work Breakdown StructurePOS Project Overview StatementINAOE Instituto Nacional de Astrofsica, ptica y ElectrnicaVORD Definicin de requerimientos orientados a puntos de vista


8/58

Documento General 8

PRIMERA PARTE:

ADMINISTRACIN DEL PROYECTO


9/58

Documento General 9

Introduccin

La Administracin de Proyectos es un mtodo y un conjunto de tcnicasbasadas en los principios aceptados de la Administracin usados en la planeacin,estimacin y control de actividades de trabajo para alcanzar un resultado finaldeseado en tiempo, dentro de un presupuesto asignado y acorde a unaespecificacin.

La gestin de un proyecto de software comienza con un conjunto de actividadesque globalmente se denominan administracin o planeacin del pro yecto.

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 deltiempo que transcurrir desde el comienzo hasta el final de su realizacin.Siempre que estimamos, lo hacemos mirando hacia el futuro y debemos aceptarresignados cierto grado de incertidumbre. A pesar de que resulta sumamentedifcil estimar, existen un conjunto de tcnicas tiles para la estimacin delesfuerzo y del tiempo. Las mtricas del proyecto y del proceso proporcionan unaperspectiva histrica y una potente introduccin para generar las estimacionescuantitativas, por otro lado la experiencia en proyectos anteriores, puede ayudaren gran medida al desarrollo y revisin de las estimaciones. En resumen elobjetivo de la planificacin del proyecto es proporcionar un marco de trabajo quepermita al administrador hacer estimaciones razonables de sus recursos, estasestimaciones se hacen dentro de un marco de tiempo limitado al comienzo delproyecto, y en caso de ser necesario debern actualizarse a medida que progresael proyecto. Adems las estimaciones deben definirse los escenarios del mejor ypeor caso de forma que los resultados del proyecto puedan limitarse. En estaseccin se estudia cada una de las actividades asociadas a la administracin delproyecto, partiendo desde la seleccin del modelo a seguir para desarrollar elmismo, la definicin de las actividades a realizar, su calendarizacin, y el anlisisde riesgos del proyecto propuesto.


10/58

Documento General 10

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 eldesarrollo del presente proyecto y su justificacin, as como las actividadesasociadas a la administracin del proyecto, que comprenden los siguientes puntos:

1. Planeacin del Proyecto2. 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 Especialista enDavid Gonzales L.Fernando Lucero P.

Administrador delProyecto

Ingeniera de Software yProgramacin

Jos Luis Chvez G. Desarrollador Ingeniera de Software yProgramacin

Modelo del Proceso de Software

Cuando se trabaja para construir un producto o un sistema, es importante seguiruna serie de pasos predecibles -un mapa de carreteras que le ayude a obtener elresultado oportuno de calidad-. El mapa de carreteras a seguir en el desarrollo desistemas de software es llamado, el Proceso del Software.

Los ingenieros de software y sus gestores adaptan el proceso a sus necesidades yentonces lo siguen. Adems las personas que han solicitado el software tienen unpapel 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 existenmuchos procesos diferentes de software, tienen actividades fundamentales queson comunes para todos ellos. Estas son: Anlisis, Diseo, Implementacin yPruebas.

La seleccin de un modelo de proceso para la ingeniera del software, debehacerse de acuerdo a la naturaleza del proyecto, de la aplicacin, mtodos yherramientas a utilizarse, y de los controles de entrega que se requieren. Para el


11/58


desarrollo del sistema propuesto fue seleccionado el modelo Cascadao modelol ineal secuencial, el cual sugiere un enfoque sistemtico y secuencial para el

desarrollo del software, en este modelo los clientes piden lo que desean, pormedio de esos requerimientos se disea el sistema, despus el diseo se codificay por ultimo se efectan las pruebas que determinaban si el sistema funcionacorrectamente de acuerdo a los requerimientos del cliente., tal como se muestraen la figura 2. A pesar de que el modelo original en cascada propuesto porWinston Royce en 1970, hace provisiones para bucles de retroalimentacin, en lagran mayora de los casos este modelo se aplica como si fuera estrictamentelineal.

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

Ingeniera deRequerimientos

Diseo delSistema deSoftware

Programacin

Verificacin yValidacin




12/58


El modelo cascada es el paradigma ms antiguo y ms extensamente utilizado enla 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 lascausas 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 prctica 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 trabajodel proyecto en actividades que puedan ser realizadas por el grupo de desarrolloen 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 seutilizaran para el desarrollo del proyecto, como a continuacin se indican:

Recursos de Hardware Cant Descripcin Justificacin

Computadora de escritorio 2 Procesador Intel Pentium 4

Sistema Operativo MicrosoftWindows 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 memoriacompartida.

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 3disponibles)

Se requieren para el

desarrollo del sistemay al finalizar una delas computadorasservir comoadministrador de laBD.


13/58


Recursos de Software Cant Descripcin Justificacin

Herramienta de desarrolloCASE y licencia

1 Puede ser Racional Rose osimilar, actualmente en ellugar donde se desarrolla elsistema se tiene acceso alArtisam RtS.

Se requieren para elmodelado y diseo delsistema bajo elestndar de UML

Base de Datos y ambientede desarrollo.

1 MySQL 4.0 o superior Este tipo de base dedatos es de fcil uso yes software libre.

Ambiente de desarrolloVisual C++

1 Se requiere la ultimaversin, Visual Studio.Net

Por ser el ambienteque domina el grupode desarrollo.

Paquete de Trabajo Office 1 Office XP o 2003 Elaborar ladocumentacin delProyecto.


14/58


Definicin de Actividades

Para poder alcanzar los objetivos o metas del proyecto, las tcnicas de divisin delproyecto en actividades parece ser la ms acertada. En este proyecto, para la definicinde 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 dela jerarqua al sistema FACTINV completo y en niveles inferiores a las actividades que sedeben realizar para alcanzar la construccin total del sistema FACTINV. Las actividadesse subdividen a su vez en actividades de menor nivel, esta divisin se detiene, cuando setengan actividades bien definidas, su ejecucin lleve poco tiempo y su progreso pueda sermedido. Al final de cada actividad se rinde un hito de esa actividad, que es un informe noextenso que indica al administrador del proyecto que esa actividad ha sido concluida. Lasactividades en las que se ha dividido el desarrollo del sistema FACTINV han sido

descritas en la tabla 1.Actividades Proyecto FACTINV Actividades Proyecto FACTINV

H0 Inicio del ProyectoT1.1 Definicin del ProyectoT1.2 Reunin con stakeholdersT1.3 Definicin del problema a resolverT1.4 Generacin del POS (Project Overview

Statement)H1 Hito: Documento del POS

T2 Estudio de factibilidadT2.1 Analizar la factibilidad econmica.T2.2 Analizar la factibilidad operativa.T2.3 Analizar la factibilidad tcnica.

H2 Hito: Informe de factibilidad

T3 Anlisis de Requerimientos de Usuario a partirdel POS

T3.1 Anlisis del Contexto del SistemaT3.2 Generacin del Diagrama de ContextoH3 Hito: Diagrama de contexto del sistema

T4 Anlisis de Escenarios y Casos de UsosT4.1 Definir escenarios del sistemaT4.2 Definir casos de uso del sistemaT4.3 Generacin de Diagrama de Casos de UsosH4 Hito: Diagrama de Casos de Usos

T5 Verificacin y Validacin con stakeholdersH5 Hito: Informe de verificacin y validacin del

mbito del sistema

T6 Definicin de requerimientos de usuarioT6.1 Requerimientos FuncionalesT6.2 Requerimientos no funcionalesH6 Hito: Documento de definicin de

requerimientos en lenguaje natural

T7 Verificacin y Validacin con stakeholdersH7 Hito: Informe de verificacin y validacin

requerimientos de usuario

T8 Definicin de requerimientos del sistemaT8.1 Requerimientos FuncionalesT8.2 Requerimientos no funcionalesT8.3 Especificacin de requerimientosH8 Hito: Documento de Requerimientos

T9 Diseo del SistemaT9.1 Diseo arquitectnico

T9.2 Estructuracin del sistemaT9.3 Modelado de controlT9.4 Descomposicin modularH9 Hito: Reporte Tcnico del diseo Arquitectnico

T10 Anlisis y diseo de Secuencia de ObjetosH10 Hito: Diagrama de Secuencia de Objetos

T11 Anlisis y Diseo de ClasesH11 Hito: Diagrama de Clases

T12 Anlisis y Diseo de Base de DatosT12.1 Diseo de las tablas de la base de datosH12 Hito: Diagrama del diseo de base de datos

T13 Anlisis, diseo de interfaces Usuario del sistema"H13 Hito: Diagramas de interfaces usuario del sistema

T14 Verificacin y validacin del diseoH14 Hito: informe de verificacin y validacin del

diseo


15/58


Actividades Proyecto FACTINV

T15 Documento de DiseoH15 Hito: Documento de Diseo

T16 Programacin del SistemaT16.1 Programacin Modulo de VentasT16.2 Programacin Modulo de ComprasT16.3 Programacin Modulo de Administracin de InventarioT16.4 Programacin Modulo de Registro de Clientes y ProveedoresT16.5 Programacin Modulo de ReportesT16.6 Programacin de interfaces entre Mdulos y base de datosT16.7 Programacin Base de DatosT16.7 Programacin de Interfaces de UsuarioH16 Hito: Cdigo del programa

T17 "Verificacin, validacin y pruebas del cdigo"H17 Hito: Informe de pruebas

T18 Documentacin del CdigoH18 Hito: Manual del Programador

T19 Capacitacin del usuario finalH19 Hito: Plan de capacitacin del usuario final

T20 Entrega del ProyectoH20 Hito: Documentacin del Proyecto

Tabla 1 Definicin de Ac tividades del Proyecto FACTINV


16/58


Calendarizacin del Proyecto

En esta etapa del proyecto se estima el tiempo requerido para completar cada una de lasactividades previamente definidas, para ello se debe calendarizar cada una de lasmismas, indicando su fecha de inicio, duracin y fecha de culminacin, adems se debenestablecer las dependencias que existen entre las diferentes actividades que conforman elproyecto. Una forma sencilla de representar la informacin del calendario del proyecto, esa travs de un grfico de barras, llamado tambin grfico de Gantt. En la calendarizacinsolo el domingo se considero como dia no laborable y debido a que la jornada laboraldiaria era irregular, se decidi estimarla semanalmente, a un promedio de 40 horaslaborales a la semana.

ID Descripcin de Actividad DuracinFecha InicioActividad

Fecha TerminoActividad

H0 Inicio 0 das 24/08/2004 24/08/2004

T1.1 Definicion del Proyecto 8 das 24/08/2004 31/08/2004

T1.2 Reunion con stakeholders 1 da 24/08/2004 24/08/2004

T1.3 Definicin del problema a resolver 4 das 25/08/2004 28/08/2004

T1.4 Generacin del POS (Project Overview Statement) 1 da 30/08/2004 30/08/2004

H1 Hito: Documento del POS (H1) 0 das 30/08/2004 30/08/2004

T2 Estudio de factibilidad 3 das 28/08/2004 31/08/2004

T2.1 Analizar la factibilidad econmica. 4 das 25/08/2004 28/08/2004

T2.2 Analizar la factibilidad operativa. 4 das 25/08/2004 28/08/2004T2.3 Analizar la factibilidad tcnica. 4 das 25/08/2004 28/08/2004

H2 Hito: Informe de factibilidad (H2) 0 das 31/08/2004 31/08/2004

T3 Anlisis de Requerimientos de Usuario a partir del POS 8 das 01/09/2004 08/09/2004

T3.1 Anlisis del Contexto del Sistema 6 das 01/09/2004 06/09/2004

T3.2 Generacin del Diagrama de Contexto 2 das 07/09/2004 08/09/2004

H3 Hito: Diagrama de contexto del sistema (H3) 0 das 08/09/2004 08/09/2004

T4 Anlisis de Escenarios y Casos de Usos 11 das 09/09/2004 18/09/2004

T4.1 Definir escenarios del sistema 6 das 09/09/2004 14/09/2004

T4.2 Definir casos de uso del sistema3 das 15/09/2004 17/09/2004

T4.3 Generacin de Diagrama de Casos de Usos 2 das 17/09/2004 18/09/2004

H4 Hito: Diagrama de Casos de Usos (H4) 0 das 18/09/2004 18/09/2004

T5 Verificacin y Validacin con stakeholders 2 das 20/09/2004 21/09/2004

H5 Hito: Informe de verificacin y validacin del mbito del sistema (H5)0 das 21/09/2004 21/09/2004


17/58




T6 Definicin de requerimientos de usuario 4 das 22/09/2004 25/09/2004

T6.1 Requerimientos Funcionales 3 das 22/09/2004 24/09/2004T6.2 Requerimientos no funcionales 3 das 22/09/2004 24/09/2004

H6Hito: Documento de definicin de requerimientos en lenguaje natural(H6)

0 das 25/09/2004 25/09/2004

T7 Verificacin y Validacin con stakeholders 1 da 27/09/2004 27/09/2004

H7Hito: Informe de verificacin y validacin requerimientos de usuario(H7)

0 das 27/09/2004 27/09/2004

T8 Definicin de requerimientos del sistema 9 das 28/09/2004 06/10/2004

T8.1 Requerimientos Funcionales 3 das 28/09/2004 30/09/2004

T8.2 Requerimientos no funcionales4 das 29/09/2004 02/10/2004

T8.3 Especificacin de requerimientos 3 das 04/10/2004 06/10/2004

H8 Hito: Documento de Requerimientos (H8) 0 das 06/10/2004 06/10/2004

T9 Diseo del Sistema 34 das 21/10/2004 24/11/2004

T9.1 Diseo arquitectnico 6 das 07/10/2004 12/10/2004

T9.2 Estructuracin del sistema 6 das 09/10/2004 14/10/2004

T9.3 Modelado de control 3 das 15/10/2004 18/10/2004

T9.4 Descomposicin modular 6 das 15/10/2004 20/10/2004

H9 Hito: Reporte Tcnico del diseo Arquitectnico (H9) 0 das 20/10/2004 20/10/2004

T10 Anlisis y diseo de Secuencia de Objetos 4 das 21/10/2004 25/10/2004

H10 Hito: Diagrama de Secuencia de Objetos (H10) 0 das 25/10/2004 25/10/2004

T11 Anlisis y Diseo de Clases 7 das 26/10/2004 03/11/2004

H11 Hito: Diagrama de Clases (H11) 0 das 03/11/2004 03/11/2004

T12 Anlisis y Diseo de Base de Datos 14 das 21/10/2004 05/11/2004

T12.1 Diseo de las tablas de la base de datos 1 da 04/11/2004 04/11/2004

H12 Hito: Diagrama del diseo de base de datos (H12) 0 das 06/11/2004 06/11/2004

T13 Anlisis, diseo y modelado de las interfaces Usuario del sistema11 das 08/11/2004 17/11/2004

H13 Hito: Diagramas de interfaces usuario del sistema (H13) 0 das 17/11/2004 17/11/2004

T14 Verificacin y validacin del diseo 3 das 18/11/2004 20/11/2004

H14 Hito: informe de verificacin y validacin del diseo (H14) 0 das 20/11/2004 20/11/2004

T15 Documento de Diseo 3 das 22/11/2004 24/11/2004

H15 Hito: Documento de Diseo (H15) 0 das 24/11/2004 24/11/2004


18/58




T16 Programacin del Sistema 17 das 26/11/2004 11/12/2004

T16.1 Programacin Modulo de Ventas 4 das 26/11/2004 30/11/2004T16.2 Programacin Modulo de Compras 4 das 26/11/2004 30/11/2004

T16.3 Programacin Modulo de Administracin de Inventario 8 das 30/11/2004 07/12/2004

T16.4 Programacin Modulo de Registro de Clientes y Proveedores7 das 29/11/2004 04/12/2004

T16.5 Programacin Modulo de Reportes 10 das 27/11/2004 07/12/2004

T16.6 Programacin de interfaces entre Mdulos y base de datos13 das 29/11/2004 10/12/2004

T16.7 Programacin Base de Datos 14 das 27/11/2004 10/12/2004

T16.7 Programacin de Interfaces de Usuario 6 das 06/12/2004 10/12/2004

H16 Hito: Cdigo del programa (H16) 0 das 11/12/2004 11/12/2004

T17 Verificacin, validacin y pruebas del cdigo 26 das 26/11/2004 20/12/2004

H17 Hito: Informe de pruebas (H17) 0 das 20/12/2004 20/12/2004

T18 Documentacin del Cdigo 17 das 30/11/2004 15/12/2004

H18 Hito: Manual del Programador (H18) 0 das 15/12/2004 15/12/2004

T21 Capacitacin del usuario final 4 das 16/12/2004 20/12/2004

H21 Hito: Plan de capacitacin del usuario final (22) 0 das 20/12/2004 20/12/2004

T22 Entrega del Proyecto 6 das 16/12/2004 21/12/2004

H22 Hito: Documentacin del Proyecto (23) 0 das 22/12/2004 22/12/2004

Tabla 2 Duracin de las Act ividades del proy ecto FACTINV.


19/58


Inicio

T1.1

T1.2

T1.3

H1

T2.1

T2.2

T2.3H2

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.2T6.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

AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE22 29 05 12 19 26 03 10 17 24 31 07 14 21 28 05 12 19 26

Figura N 3 Diagrama de Actividades del Proyecto .


20/58


Administracin de Riesgos

A continuacin se presentan las tablas 3, 4, 5 y 6, en donde se muestra en formaresumida, la definicin, anlisis, estrategias de administracin y supervisin de losprincipales riesgos asociados con el desarrollo del proyecto.

TIPO DE RIESGO RIESGOS POSIBLES

Tecnologa

La Base de Datos que se utilizara es de cdigo abierto y podratener problemas de incompatibilidad con el lenguaje deprogramacin seleccionado.

Personas

El personal asignado al proyecto, no cuenta con la capacitacinadecuada para desarrollar el sistema.

El personal esta comprometido con otros proyectos, que leimpiden atender plenamente el proyecto.

Herramientas Es ineficiente el cdigo generado por las herramientas CASE

Las herramientas CASE son de alto costo

Requerimientos Surgen nuevos requerimientos que requieren cambiar el diseo.

Organizacionales

El personal del negocio se opone a los cambios, que representa

introducir FACTINV en la organizacin

Estimacin

El tiempo requerido para la capacitacin adecuada del personalesta subestimado

El tiempo requerido para desarrollar el sistema de software estasubestimado

El tamao del software esta subestimado

Tabla 3 Clasif icacin e Identi f icacin de Riesgo s del Proyecto FACTINV.


21/58


RIESGO PROBABILIDAD EFECTOS

El tiempo requerido para la capacitacin adecuada delpersonal esta subestimado.

Media Catastrfico

El personal esta comprometido con otros proyectos,que le impiden atender plenamente el proyecto.

Alta Serio

Surgen nuevos requerimientos que requieren cambiarel diseo. Media Serio

El personal asignado al proyecto, no cuenta con lacapacitacin adecuada para desarrollar un sistema deBase de Datos

Alta Serio

El personal de la organizacin donde se instalara elsistema FACTINV, se opone a los cambios

Alta Tolerable

El tiempo requerido para desarrollar el sistema desoftware esta subestimado.

Alta Tolerable

El lenguaje de programacin no cuenta con mtodospreviamente desarrollados, que permitan satisfacerciertos requerimientos del sistema.

Media Tolerable

Tabla 4 Anlisis de Riesg os del pro yect o FACTINV


22/58


RIESGO ESTRATEGIA

Problemas con la Base deDatos

Investigar sobre otras aplicaciones similares, que sehayan desarrollado con este tipo de Base de Datosseleccionado

Problemas con la capacitacindel personal de desarrollo

Realizar un diagnostico de las habilidadesindividuales del personal en las reas relacionadascon el desarrollo del sistema, y canalizar los planesde capacitacin de forma individualizada, para que sepuedan fortalecer estas habilidades en el menortiempo posible.

Problemas relacionados con eldesarrollo de otros proyectos.

Realizar una clasificacin de los proyectos deacuerdo al grado de dificultad que este representepara el personal involucrado en su desarrollo.

Disear un plan de trabajo que asigne tiempos deatencin a cada proyecto, acorde con la clasificacinpreviamente realizada.

Problemas del personal delnegocio

Realizar un anlisis minucioso de las causas por lacual se oponen a la implementacin del sistema ytomar medidas radicales

Elaborar un buen plan de entrenamiento que muestreal personal las bondades del sistema FACTINV

Cambios de requerimientosUtilizar tcnicas de diseo que limiten el impacto delos cambios de requerimientos

Tiempo de desarrollosubestimado

Alertar al cliente de las dificultades de desarrollar elsistema completo en el tiempo estimado.

Tabla 5 Adminis tracin de Riesgos del sistem a FACTINV.


23/58


TIPO DE RIESGO INDICADORES POTENCIALES

Tecnologa Documentacin excesiva de la Base de Datos seleccionada hacedifcil la tarea de clasificar la informacin relevante a este proyecto

Personas Preocupacin excesiva de personal por temor a no cumplir con losproyectos asignados

Miembros del equipo con poco mpetu para resolver problemas yaportar ideas al equipo de desarrollo

Requerimientos Dificultad de integrar los nuevos requerimientos en la fase decodificacin.

Herramientas Dificultad para conseguir una herramienta CASE que cumpla conlas expectativas del proyecto

Organizacionales Comentarios dentro de la organizacin referentes al bajorendimiento presentado por el grupo trabajo asignado al proyecto

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

Tabla 6 Supervisin de Riesgos d el proyecto FACTINV.


24/58


SEGUNDA PARTE:

REQUERIMIENTOS DEL SISTEMA


25/58


Introduccin

En esta segunda parte del documento general se establecen y documentan las tcnicasde la Ingeniera de Requerimientos, facilitando con esto que se delimite el alcance delsistema y se comprendan los requerimientos del cliente, llevndolos a un estado dondecada uno de los requerimientos del cliente llegue a ser independiente, completo y sinambigedades, negociando una solucin razonable, validando la especificacin yadministrando los requerimientos para que se transformen en un sistema operacional.

El proceso de ingeniera de requerimientos expuesto por este documento realiza unestudio de factibilidad del proyecto. As mismo se usa una tcnica para el anlisis yobtencin 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 resultadosdel 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 requerimientosque incluye la matriz de de rastreo de requerimientos.


26/58


Estudio de Factibilidad

En el presente estudio se analiz la disponibilidad de los recursos necesarios paraalcanzar 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 defactibilidad presentado en cada uno de los tres aspectos anteriores.

Factibilidad Econmica

En el presente proyecto la factibilidad econmica se encuentra garantizada en sutotalidad, ya que todos los costos del proyecto sern absorbidos por el INAOE, estosincluyen: costo de la tecnologa a utilizar (hardware y software), del personal dedesarrollo, 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 delproyecto, de forma tal que se pueda garantizar el uso del sistema a desarrollar. Lafactibilidad operativa es baja ya que:

1. El sistema ser administrado y usado por personal que no cuenta conconocimientos en computadoras, sin embargo se le dar capacitacin para eluso adecuado del sistema

2. El personal del rea administrativa y contable del negocio no acepta los cambiosSin embargo, para minimizar las consecuencias se atacaran durante el desarrollo delproyecto los dos aspectos anteriores, tomndose las medidas necesarias para el xitodel proyecto de comn acuerdo con el cliente.

Factibilidad Tcnica

La factibilidad tcnica analiza los recursos de hardware y software necesarios paradesarrollar el sistema, as como tambin a los conocimientos, habilidades y experienciadel personal que conforma el grupo de trabajo, para poder efectuar las actividades oprocesos 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 delsistema proporcionado por el INAOE.Personal: Se pudo determinar que para el inicio del proyecto este no contaba conninguna experiencia en el desarrollo de sistemas de Base de Datos, sin embargo seestim que el mismo, poda adquirir los conocimientos y las habilidades necesarios paraculminar exitosamente el proyecto, ya que era factible acceder a la informacinnecesaria par su capacitacin.


27/58


Obtencin y Anlisis de Requerimientos

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

Mtodo VORD

Este mtodo se ha diseado como un marco de trabajo orientado a servicios, parapoder 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 debedefinir el perfil de cada uno estos usuarios, para as poder analizar su perspectiva queeste tiene del sistema que se desea desarrollar. En este sentido es bueno recalcar queel sistema propuesto no es una herramienta de propsito general, si no de usoespecfico, por lo tanto el usuario final debe ser un usuario especializado, que debeestar estrechamente familiarizado, tanto con el proceso industrial real, como con elmodelo que pretende simular dicho proceso, ya que para poder realizar el proceso deen 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 deusuario, que puede estar representado por un ingeniero industrial, que intenta validar unmodelo, que probablemente haya sido diseado por el mismo. A continuacin semuestran las plantillas de punto de vista y de servicio para este usuario final.

Referencia : Ingeniero Industrial

Atributos : Parmetros del modelo.Observaciones de la prueba.

Eventos: Seleccionar modeloIntroducir parmetrosSeleccionar mtodoIniciar simulacinDetener simulacinPerturbar simulacinContinuar simulacinRepetir simulacinAnotar ObservacionesFinalizar simulacin

Servicios: Probar modeloImprimir resultados


28/58


Figura N 5 Planti l la de punto de vista.

Figura N 6 Planti l la del Servicio: Probar Modelo.

Referencia: Probar modelo.

Fundamento: Validar un modelo que simula un procesoindustrial de inters para la organizacin.

Especificacin: El usuario selecciona un modelo, introduce losparmetros necesarios, luego selecciona un mtodopara calcular su solucin, despus inicia lasimulacin, durante la misma puede detener lasimulacin, repetir parte de esta, perturbar la

simulacin, continuar la simulacin, anotar losresultados observados y finalizar la simulacin.

Punto de vista: Ingeniero Industrial.

Requerimientos La simulacin debe presentarse en colores queno funcionales: contrasten con el fondo de la pantalla, para que

se pueda apreciar claramente el proceso que sedesea simular.

Se debe poder cambiar el intervalo de tiempo en

que se capturan las soluciones parciales, que sedeseen repetir.

Proveedor : Modulo de Prueba.


29/58


Referencia: Imprimir resultados.

Fundamento: Facilitar el anlisis de la validacin del modelo,de forma tal que el usuario pueda compartir ydiscutir las observaciones de la prueba con elresto de su equipo de trabajo.

Especificacin: El usuario selecciona el archivo que contienelas observaciones de la prueba al modelo quedesea validar, y luego selecciona la opcin deobtener reporte por impresora.

Punto de vista: Ingeniero Industrial.

Requerimientos Los resultados a imprimir sern extrados deno funcionales: un archivo de texto.

Proveedor : Modulo de Reportes.


30/58


Figura N 7 Planti l la del Servicio: Imprimir Resultados.

Diagrama de Casos de Uso

Esta es una tcnica basada en el uso de escenarios, en donde los usuarios danejemplos de las acciones que desean realizar al momento de interactuar con el sistema,lo que permite modelar su comportamiento, ya que se puede visualizar grficamentecada una de estas interacciones, la relacin que existe entre ellas, y quien llevar a

cabo determinada interaccin, todo esto sin importar como ser implementada. Enresumen los diagramas de casos de uso nos ayudas a describir las funciones delsistema y a complementar el enfoque basado en el punto de vista de los usuarios. Parael diseo del diagrama de casos de uso mostrado en la figura N 8 se siguieron lospasos 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.


31/58


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


32/58


Probar el Modelo 1

Graficar Solucin 5Seleccionar Mtodo 4

Normalizar 6 Iniciar 7

Detener 8

Alterar 9

Continuar 11

Retroceder 10

Generar Reporte 13

Anotar

Observaciones 12

Seleccionar Modelo 2

Capturar Parmetros 3


33/58


Figura N

8 Diagrama de Casos de Uso.


34/58


Diagrama de Secuencias

Esta es otra tcnica que se basa en escenarios y que permite agregar informacin a uncaso de uso. En este diagrama se muestran los actores que interactan con el sistemalos 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 orientadoa objetos, este diagrama resulta un buen punto de partida para identificar las futurasclases a disear.

Figura N 9 Diagrama de Secuencias.

Anotacin

Solicitar

Anotacin

Enviar (Reporte)

ReporteSolicitar (Reporte)

ObservacinAnotar

Finalizar

Modelo

Simulacin

Simulacin

Continuar

Perturbar

Parar

Iniciar ModeloEnviar(Modelo)

Modelo

Parametrizar

Solicitar(Modelo)

Interfaz Modelo Mtodo

Solucin

Solucin

LibretaGenerador

deGrficos

Generadorde

Reportes


35/58


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 haagregado 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 serprobado, y el usuario es la persona ms indicada para hacerlo, ya que este debeconocer el proceso real que se desea simular, lo que le permitir inferir conclusiones deque tan seguro es utilizar el modelo propuesto, a partir de la observacin de la solucindel 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 quese desea probar.

1.1.2- El sistema debe permitir ingresar los parmetros iniciales delmodelo seleccionado.

1.1.3.- El sistema debe permitir el usuario seleccione un mtodo parasolucionar el modelo.

Fundamento: Debido a que en la organizacin pueden existir o surgirvarios procesos de inters que se desean simular, el usuario debeadaptar 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 vaconstruyendo la solucin grfica.

1.2.2.- El sistema debe permitir normalizar la solucin grafica


36/58


Fundamento: Considerando que la base de la prueba es comparar elcomportamiento del modelo con la salida del sistema real, la mejor formaes 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 lasimulacin.

1.3.3.- El sistema debe permitir tomar fotos de la graficacin de lasolucin.

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 elmodelo es comparar la salida real y la calculada mediante la simulacin, es porello que el sistema debe proveer al usuario un conjunto de herramientas que

permitan que este visualice detalladamente el comportamiento del modelo, tantoen condiciones normales, como perturbado, y as poder inferir conclusiones deque tan seguro es aplicar el modelo probado.

2.- El sistema debe permitir que se obtenga un reporte de los resultados de laprueba.

2.1.- El sistema debe permitir que el usuario realice anotaciones durante laprueba 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.


37/58


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

No Funcionales

3.- La solucin grfica debe ser presentada en colores que permitan visualizarclaramente 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 elcomportamiento del modelo de la forma ms clara posible, por lo tanto el es elindicado para seleccionar los colores ms agradables a su vista, que lo proveanuna 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 visualizacindel comportamiento del modelo.

5.- El tiempo en que se representa la solucin grfica no se considera una restriccindel sistema.

Fundamento: Debido a que la simulacin no esta orientada a representar unsistema de tiempo real y que una de las motivaciones del desarrollo del sistemaes probar diferentes modelos observando su comportamiento, la rapidez conque se muestra la solucin no representa una limitante.

6.- El tiempo en que se toman las fotos que contienen parte de la solucin grficapuede ser cambiado por el usuario.

Fundamento: El usuario es quien debe establecer las pautas a seguir paraprobar el modelo, por lo tanto el sistema le debe proveer las facilidadesnecesarias que le permitan adaptar la prueba a sus necesidades.


38/58


7.- El sistema debe ser desarrollado en un lenguaje de programacin que permita crearprogramas ejecutables.

Fundamento: Esto le dar mayor portabilidad al sistema, ya que no lo ligaracon una herramienta de software especfica, y le permitir probar modelos mscomplejos que dependan de la capacidad del hardware utilizado y no de unaherramienta 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 observacionesdurante la prueba del modelo, es recomendable que este pueda cambiar elentorno 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 editadosfcilmente por otros editores de texto, y este formato tambin facilita y hacems 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 resultarcomplejo, es por ello que el sistema debe contar con los medios necesarios queguen al usuario al operar el mismo.


39/58


Especificacin de Requerimientos

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

Requerimientos Funcionales

Requerimiento: # 1 Tipo derequerimiento: 9

Evento/caso de uso #:1

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 demedida:

La funcionalidad del modelo una vez aprobado y utilizado.

Satisfaccin del cliente:5 Insatisfaccin del cliente:5Dependencias:Los modelos a probar deben estarrepresentados como ecuaciones algebraicas diferenciales.

Conflictos: No existen conflictos

Materiales de apoyo: Diagrama de Casos de Uso

Historia: Creado el 31 de Octubre del 2004

Requerimiento: # 1.1 Tipo derequerimiento: 9

Evento/caso de uso #:1,2

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.


Criterio demedida:

Que el usuario pueda seleccionar el modelo que desea probar.

Satisfaccin del cliente:5 Insatisfaccin del cliente:5

Dependencias:Los modelos a probar deben estarrepresentados como ecuaciones algebraicas diferenciales.



40/58



Historia: Creado el 1 de Noviembre del 2004



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


Criterio demedida:

Que el usuario pueda parametrizar el modelo que desea probar.

Satisfaccin del cliente:5 Insatisfaccin del cliente:5Dependencias:Los modelos a probar deben estarrepresentados como ecuaciones algebraicas diferenciales.






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.


Criterio demedida:

Que el usuario pueda seleccionar el mtodo numrico con que desea solucionar elModelo.


Dependencias:Los mtodos numricos seleccionados debensolucionar modelos representados como ecuacionesalgebraicas diferenciales.


Materiales de apoyo: Diagrama de Casos de Uso. Seccin de Fundamentos Bsicos




Descripcin: La solucin del modelo debe representarse grficamente.

Razn: Es la mejor forma de observar el comportamiento del modelo.


Criterio demedida:

Que se pueda visualizar la solucin grafica del modelo.


41/58



Dependencias:Que la herramienta de desarrollo cuente conlibreras adecuadas para la representacin grfica.


Materiales de apoyo: Diagrama de Casos de Uso.




Descripcin: El sistema debe construir la solucin grafica en forma dinmica.

Razn: Que el usuario pueda observar detalladamente el comportamiento del modelo.


Criterio demedida: Que el usuario pueda observar como se va construyendo grficamente la solucin delModelo.Satisfaccin del cliente:5 Insatisfaccin del cliente:5

Dependencias:Que la herramienta de desarrollo cuente conlibreras adecuadas para la representacin grfica.





Evento/caso de uso #:1,5,6

Descripcin: El sistema debe permitir normalizar la solucin grafica del modelo.

Razn: Que el usuario pueda visualizar la solucin grafica en una escala adecuada.


Criterio demedida:

Que la solucin grafica se pueda mostrar completa en la pantalla.


Dependencias:Desarrollar las rutinas necesarias paranormalizar la solucin del modelo antes de graficarla.





Evento/caso de uso #:1,7,8,9,10,11

Descripcin: El sistema debe proveer las funciones necesarias para probar el modelo.

Razn: Sin estas funciones el proceso de validacin no ser seguro.



42/58


Criterio demedida:

La cantidad y el tipo de funciones que ofrece el sistema para probar el modelo.


Dependencias:Que las funciones propuestas puedan serdesarrolladas con la herramienta de desarrollo seleccionada.




Requerimiento: # 1.7.1 Tipo derequerimiento: 9


Descripcin: El sistema debe tener una funcin que permita iniciar la simulacin.

Razn: Poder controlar el proceso de simulacin.


Criterio demedida:

Verificar que la solucin inicial se corresponda con los parmetros iniciales.


Dependencias:Que el modelo acepte un estado inicial departida.






Descripcin: El sistema debe tener una funcin que permita detener la simulacin.

Razn: Poder controlar el proceso de simulacin.


Criterio demedida:

Que la solucin grafica se detenga una vez que se active esta funcin.


Dependencias: Que el modelo se pueda resolverparcialmente.


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



Descripcin: El sistema debe tener una funcin que permita cambiar los parmetros del modelodurante la simulacin


43/58


Razn: Poder controlar el proceso de simulacin y ver como responde ante nuevas condiciones


Criterio demedida:

Verificar que la solucin grafica se represente correctamente una vez introducidos losnuevos parmetros.


Dependencias: Que el modelo se pueda resolvercorrectamente a partir de los nuevos parmetros




Requerimiento: # 1.7.4 Tipo de

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 observarnuevamente, sin tener que graficar desde el inicio la solucin.


Criterio demedida:

Verificar si la foto tomada se corresponde con la solucin grafica presentada previamenteen tiempo de ejecucin


Dependencias: Que la herramienta de desarrollo provea laslibreras necesarias para llevar a cabo esta funcin.






Descripcin: El sistema debe tener una funcin que permita retroceder a un estado anterior de lasimulacin.Razn: Poder controlar el proceso de simulacin y visualizar nuevamente una parte de la misma.


Criterio de

medida:

Verificar si a la etapa de la simulacin a donde se retrocedi, forma parte de la solucin

parcial del modelo.


Dependencias: Que se pueda realizar el fotografiadoperiodico.

Conflictos: Requerimiento 1.7.4




44/58




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 dehaber sido detenida la simulacin.


Criterio demedida:

Verificar que la solucin grafica se construya a partir de donde se detuvo la simulacin.


Dependencias: Que el modelo acepte un estado inicial departida.





45/58


Requerimiento: # 2 Tipo derequerimiento: 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.


Criterio demedida:

Obtener el reporte impreso, tal cual como se edito durante la prueba.


Dependencias:Debe existir un archivo en donde estnalmacenadas las observaciones que corresponden al reporteque se desea imprimir.

Conflictos: Requerimientos 2.2





Descripcin: El sistema debe proveer un medio para que el usuario pueda escribir las observacionesde la prueba on-line durante la simulacin.Razn: Facilitar el anlisis posterior a la prueba del modelo.


Criterio demedida:

Que las observaciones anotadas, se correspondan con el reporte impreso.


Dependencias: Que se pueda detener la simulacin paraanotar estas observaciones.

Conflictos: Requerimiento 1.7.2





Descripcin: El sistema debe permitir almacenar las observaciones en un medio de almacenamientosecundario.Razn: Proveer el medio necesario para extraer la informacin contendr el reporte impreso.

Fuente:Coordinador del ProyectoCriterio demedida:

Verificar que se haya creado el archivo correspondiente.


Dependencias: Que se pueda importar la informacineditada en memoria principal a memoria secundaria.





46/58




Descripcin: El sistema debe permitir que se puedan modificar las observaciones.

Razn: Corregir observaciones previas.


Criterio demedida:

Verificar que el archivo contenga las ltimas modificaciones realizadas



Conflictos: Requerimiento 2.2





Descripcin: El sistema debe permitir que se consulten observaciones de pruebas realizadasanteriormente.Razn: Corroborar si las observaciones anteriores se corresponden con los criterios actuales delusuario.


Criterio de

medida:

Verificar que el archivo contenga las ltimas modificaciones realizadas



Conflictos: Requerimiento 2.2




47/58


Requerimientos No Funcionales

Requerimiento: # 3 Tipo derequerimiento: 10a


Descripcin: La interfaz grfica en la que se muestra la solucin del modelo, debe presentarse pordefecto en colores agradables a la vista del usuario, donde exista un claro contraste entre el fondo de lapantalla y la solucin grafica.Razn: Evitar producir cansancio en la vista del usuario, ya que esto podra dificultar la observacinadecuada de la prueba del modelo.


Criterio demedida:

Consultar al usuario con respecto al cansancio de su vista, tras varias sesiones deprueba.


Dependencias:Que la herramienta de desarrollo cuente conlibreras adecuadas para modificar los colores de larepresentacin grfica.




Requerimiento: # 3.1 Tipo de requerimiento: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 suspreferencias, lo que lo har sentir ms a gusto al momento de realizar las pruebas del modelo.


Criterio demedida:

Que el usuario pueda utilizar los colores de su preferencia.

Satisfaccin del cliente:5 Insatisfaccin del cliente:5Dependencias:Que la herramienta de desarrollo cuente conlibreras adecuadas para modificar los colores de larepresentacin grfica.





48/58


Requerimiento: # 4 Tipo de requerimiento: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 suspreferencias, y que de acuerdo pueda observar mejor el comportamiento del modelo.


Criterio demedida:

Que el usuario pueda realizar los cambios deseados.


Dependencias:Que la herramienta de desarrollo cuente conlibreras adecuadas para modificar loa escala de larepresentacin grfica.




Requerimiento: # 5 Tipo de requerimiento:12a


Descripcin: El tiempo en que se grafica la solucin del modelo no representa una limitante delsistema.Razn: La simulacin no esta orientada a representar un sistema de tiempo real, sino a estudiar eldetalladamente el comportamientos del modelo.


Criterio demedida:

Verificar que la salida del modelo sea graficada correctamente sin importar el tiempo enque sea graficada.


Dependencias:Que la herramienta de desarrollo cuente conlibreras adecuadas para representar la solucin grfica delmodelo correctamente.





49/58


Requerimiento: # 6 Tipo de requerimiento:11b


Descripcin: Los intervalos de tiempo en que se realiza el fotografiado periodico se pueden configurar.

Razn:Aumentar el grado de precisin de la prueba.


Criterio demedida:

Que la cantidad de estados capturados se corresponda con el intervalo de tiempoSeleccionado y el tiempo de la prueba.


Dependencias:El mnimo intervalo de tiempo seleccionado,debe ser mayor al tiempo en que se genera y muestra lasolucin grafica.



Requerimiento: # 7 Tipo de requerimiento: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 ProyectoCriterio demedida:

Verificar que los archivos creados puedan ser abiertos con herramientas orientadas aprocesar este tipo de archivos.


Dependencias: Que la herramienta de desarrollo provea losmecanismos necesarios para la creacin de archivos de estetipo.





50/58


Requerimiento: # 8 Tipo de requerimiento:14d, 12f

Evento/caso de uso #:

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 conherramientas como SIMULINK.


Criterio demedida:

Verificar que el sistema resuelva correctamente modelos complejos


Dependencias: Que la herramienta de desarrollo permitadesarrollar rutinas eficientes para la aplicacin de los mtodosnumricos seleccionados.


Materiales de apoyo:




Descripcin: El sistema debe permitir que se active una ventana de texto usuario puede escribir lasobservaciones correspondientes a la prueba que esta realizando en ese momento.Razn: Proveer un mecanismo prctico para que el usuario lleve a cabo esta operacin.


Criterio demedida:

Verificar que la ventana se pueda activar durante la prueba del modelo.

Satisfaccin del cliente:5 Insatisfaccin del cliente:5Dependencias: Que la herramienta de desarrollo esteorientada a un ambiente visual




Requerimiento: # 9.1 Tipo de requerimiento: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.


Criterio demedida:

Verificar que el texto escrito se desplace correctamente a medida que se va llenando laventana.


Dependencias: Que la herramienta de desarrollo esteorientada a un ambiente visual.


Materiales de apoyo: Diagrama de Casos de Uso. Seccin de Fundamentos Bsicos.


51/58



Requerimiento: # 9.2 Tipo de requerimiento: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.


Criterio demedida:

Que la ventana aparezca y desaparezca cuando se activen los mecanismos adecuados(click del ratn)





Requerimiento: # 9.3 Tipo de requerimiento:10a, 11a


Descripcin: El sistema debe permitir que el usuario mueva la ventana de edicin.



Criterio de

medida:Que la ventana se mueva cuando se activen los mecanismos adecuados (arrastre atravs del ratn)






Requerimiento: # 9.4 Tipo de requerimiento:10a, 11a, 11b


Descripcin: El sistema debe permitir que el usuario configure el tamao de la ventana de edicin.



Criterio demedida:

Que la ventana cambie de tamao va cuando se activen los mecanismos adecuados( a travs del ratn)





52/58




Requerimiento: # 10 Tipo de requerimiento: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.


Criterio demedida:

Verificar que los archivos creados puedan ser abiertos con herramientas orientadas aprocesar este tipo de archivos.

Satisfaccin del cliente:5 Insatisfaccin del cliente:5Dependencias: Que la herramienta de desarrollo provea losmecanismos necesarios para la creacin de archivos de texto.




Requerimiento: # 10.1 Tipo de requerimiento:11a


Descripcin: Las archivos de texto almacenados deben guardar por defecto la fecha de creacin y unnmero 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 elmodelo que desea analizar.


Criterio demedida:

Verificar que los archivos creados guarden esta informacin.


Dependencias: Desarrollar la rutinas de programacin queanexen automticamente esta informacin al archivo de texto.




Requerimiento: # 10.2 Tipo de requerimiento:11a


Descripcin: El nombre con que se guarda el archivo de texto, se creara por defecto con el nmero queidentifica el modelo que se esta probando, concatenado con la fecha de creacin.Razn: Facilidad para ubicar el archivo e imprimirlo.



53/58


Criterio demedida:

Verificar que los archivos creados se guardan con estos parmetros.


Dependencias: Desarrollar la rutinas de programacin quepermitan crear los archivos de esta forma .




Requerimiento: # 11 Tipo de requerimiento: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, porlo tanto los resultados de la solucin del modelo deben graficarse con la mayor precisin posible.


Criterio demedida:

Verificar la graficacin de la solucin de modelos caractersticos, donde ya se conoce susalida.


Dependencias: Que la herramienta de desarrollo provea lasfunciones adecuadas para calcular y graficar con precisin lassoluciones del modelo.






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 variablespermiten relacionar mejor el modelo con el sistema real que se pretende simular.


Criterio demedida:

Ninguno


Dependencias: Que la herramienta de desarrollo este

orientada a un ambiente visual.







54/58


Descripcin: El sistema debe proveer una ventana de ayuda al usuario, por cada uno de los mdulospresentados.Razn: Facilidad para que el usuario pueda utilizar el sistema.


Criterio demedida:

Verificar que los la informacin contenida en cada ventana, se relaciones con el uso delmodulo en donde fueron activadas.






Validacin y Administracin de Requerimientos

La validacin y administracin de los requerimientos se fundamento en determinar si losrequerimientos eran verificables, comprensibles, rasteables y adaptables. Para ello seestablecieron reuniones entre los stakeholders y el grupo de trabajo, y se realizaronpresentaciones pblicas de los avances del proyecto, donde participaron losstakeholders, el grupo de trabajo y desarrolladores de otros proyectos, en estaspresentaciones se atendieron las dudas y consultas tanto de los stakeholder y de losdesarrolladores invitados, de igual forma de grupo trabajo asisti a las presentacionesde otros proyectos, lo que sirvi como punto de comparacin y fuente para extraeraspectos comunes de proyectos diferentes. Otras de las estrategias utilizadas aparte delas revisiones formales e informales realizadas, fue la utilizacin de una matriz derastreo de requerimientos, la cual permiti vincular requerimientos con otros

requerimientos y establecer la dependencia existente entre los mismos. La notacinutilizada consisti en usar una U para establecer una relacin fuerte entre losrequerimientos, e indicar que el requerimiento de la fila utilizaba los requerimientossealados en la columna. Mientras que una R significaba exista una relacin dbilentre los requerimientos. La aplicacin de este tipo de estrategia fue posible debido aque el nmero de requerimientos a administrar fue relativamente pequeo y por lo tantono 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 losrequerimientos eran verificables, comprensibles y adaptables, mientras que en la tablaN8 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 ladependencia existente entre los mismos.


55/58


RequerimientoVerificable

Si No

Comprensible

Si No

Adaptable

Si No1 X X X

1.1 X X X1.2 X X X1.3 X X X1.4 X X X1.5 X X X1.6 X X X

1.7 X X X1.7.1 X X X1.7.2 X X X1.7.3 X X X1.7.4 X X X1.7.5 X X X1.7.6 X X X

2 X X X2.1 X X X2.2 X X X2.3 X X X2.4 X X X

3 X X X3.1 X X X4 X X X5 X X X6 X X X7 X X X8 X X X9 X X X


56/58


9.1 X X X9.2 X X X9.3 X X X9.4 X X X10 X X X

10.1 X X X10.2 X X X11 X X X12 X X X13 X X X

Tabla N 7 Val idacin de los Requerimientos .


57/58


Req

.

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

13

1 R U U R R1.1

R

1.2

U

1.3

R

1.4

U R

1.5

R

1.6

R U U

1.7

R R R R R R U

1.7.1

U U

1.7.2

U U

1.7.3

R

1.7.4

R U

1.7.5

U R

1.

7.6

U U

2 R R2.1

U

2.2

U

2.

R R


58/58

32.4

R R

3 R U3.1

R

4 R5 U6 R7 R8 R9 U9.1

R

9.2

R

9.3

R

9.4

R

10

R

10.1

R

10.2

R

1

1

R

12

U

13

U

Tabla N 8 Matriz de Rastreo de los Requerimientos .

ejemplo 2 - proyecto - documento general factinv_luis.pdf

Documents

estudio de factibilidad

factibilidad econmica

factibilidad operativa

factibilidad tcnica

requerimientos de recursos

anlisis de requerimientos

sistema de facturacion

proceso de software