Sistema de facturación e inventario – FACTINV (página 2)

Tabla 1 Definición de Actividades del Proyecto FACTINV

Calendarización 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, duración y fecha de culminación, además se deben establecer las dependencias que existen entre las diferentes actividades que conforman el proyecto. Una forma sencilla de representar la información del calendario del proyecto, es a través de un gráfico de barras, llamado también gráfico de Gantt. En la calendarización 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.

Tabla 2 Duración de las Actividades del proyecto FACTINV.

Administración de riesgos

A continuación se presentan las tablas 3, 4, 5 y 6, en donde se muestra en forma resumida, la definición, análisis, estrategias de administración y supervisión de los principales riesgos asociados con el desarrollo del proyecto.

Tabla 3 Clasificación e Identificación de Riesgos del Proyecto FACTINV.

Tabla 4 Análisis de Riesgos del proyecto FACTINV

Tabla 5 Administración de Riesgos del sistema FACTINV.

Tabla 6 Supervisión de Riesgos del proyecto FACTINV.

SEGUNDA PARTE:

Requerimientos del sistema

En esta segunda parte del documento general se establecen y documentan las técnicas de la Ingeniería de Requerimientos, facilitando con esto que se delimite el alcance del sistema y se comprendan los requerimientos del cliente, llevándolos a un estado donde cada uno de los requerimientos del cliente llegue a ser independiente, completo y sin ambigüedades, negociando una solución razonable, validando la especificación y administrando los requerimientos para que se transformen en un sistema operacional. El proceso de ingeniería de requerimientos expuesto por este documento realiza un estudio de factibilidad del proyecto. Así mismo se usa una técnica para el análisis y obtención de requerimientos, que incluye las plantillas de punto de vista y de servicios (método VORD) y los diagramas de casos de uso y de secuencia, con los resultados del método VORD se definen los requerimientos en lenguaje natural para el usuario y luego se especifican en lenguaje natural estructurado, siguiendo el método VOLARE, finalmente se presenta una parte de validación y administración de los requerimientos que incluye la matriz de de rastreo de requerimientos.

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 análisis de 3 aspectos básicos:

• Económico

• Operativo

• Técnico

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

Factibilidad Económica

En el presente proyecto la factibilidad económica se encuentra garantizada en su totalidad, ya que todos los costos del proyecto serán absorbidos por el INAOE, estos incluyen: costo de la tecnología a utilizar (hardware y software), del personal de desarrollo, de la infraestructura (planta física y servicios) y del acceso al información.

Factibilidad Operativa

Esta depende de los recursos humanos que participen durante la operación 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á capacitación 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, tomándose las medidas necesarias para el éxito del proyecto de común acuerdo con el cliente.

Factibilidad Técnica

La factibilidad técnica analiza los recursos de hardware y software necesarios para desarrollar el sistema, así como también 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 realización 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, podía adquirir los conocimientos y las habilidades necesarios para culminar exitosamente el proyecto, ya que era factible acceder a la información necesaria par su capacitación.

Obtención y Análisis de Requerimientos

Esta etapa del proceso de Ingeniería de Requerimientos se encarga de la obtención y análisis 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 aplicación y cuales son los servicios que debe proveer el sistema, para la realización de esta actividad se utilizo un método de obtención de requerimientos orientado a puntos de vista, esta método es mejor conocido como método VORD, y es descrito a continuación.

Método VORD

Este método se ha diseñado como un marco de trabajo orientado a servicios, para poder estructurar y organizar la obtención y análisis 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 propósito general, si no de uso específico, 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, sólo 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 diseñado por el mismo. A continuación se muestran las plantillas de punto de vista y de servicio para este usuario final.

Figura N( 5 Plantilla de punto de vista.

Figura N( 6 Plantilla del Servicio: Probar Modelo.

Figura N( 7 Plantilla del Servicio: Imprimir Resultados.

Diagrama de Casos de Uso

Esta es una técnica 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 gráficamente cada una de estas interacciones, la relación que existe entre ellas, y quien llevará a cabo determinada interacción, 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 diseño del diagrama de casos de uso mostrado en la figura N( 8 se siguieron los pasos indicados a continuación.

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.

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

Figura N( 8 Diagrama de Casos de Uso.

Diagrama de Secuencias

Esta es otra técnica que se basa en escenarios y que permite agregar información a un caso de uso. En este diagrama se muestran los actores que interactúan 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 diseño y desarrollo del sistema es orientado a objetos, este diagrama resulta un buen punto de partida para identificar las futuras clases a diseñar.

Figura N( 9 Diagrama de Secuencias.

Definición de Requerimientos

En esta sección 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 más 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 observación de la solución del modelo y de la comparación 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 parámetros iniciales del modelo seleccionado.

1.1.3.- El sistema debe permitir el usuario seleccione un método para solucionar el modelo.

Fundamento: Debido a que en la organización pueden existir o surgir varios procesos de interés que se desean simular, el usuario debe adaptar el ambiente de prueba para el modelo que desea probar.

1.2. Presentación de la solución del modelo

1.2.1.- La solución del modelo debe ser presentada gráficamente.

1.2.1.- El sistema debe permitir que el usuario visualice como se va construyendo la solución gráfica.

1.2.2.- El sistema debe permitir normalizar la solución grafica

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 solución del modelo gráficamente.

1.3. Herramientas para probar el Modelo

1.3.1.- El usuario puede iniciar la graficación de la solución.

1.3.2.- El usuario puede detener la graficación de la solución.

1.3.3.- El usuario puede cambiar los parámetros del modelo durante la simulación.

1.3.3.- El sistema debe permitir tomar fotos de la graficación de la solución.

1.3.4.- El usuario puede retroceder a una solución grafica previa.

1.3.5.- El usuario puede reiniciar la graficación de la solución.

Fundamento: Como se menciono anteriormente la mejor forma de validar el modelo es comparar la salida real y la calculada mediante la simulación, 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.

Fundamento: Durante la prueba del modelo el usuario infiere un conjunto de observaciones que es recomendable anotar, una forma práctica de hacerlo es a través del mismo sistema, de forma que el usuario pueda revisar luego estas anotaciones con más 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 solución gráfica debe ser presentada en colores que permitan visualizar claramente la simulación.

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 más clara posible, por lo tanto el es el indicado para seleccionar los colores más agradables a su vista, que lo provean una mejor visualización del comportamiento del modelo.

4.- El usuario puede cambiar la escala en que será presentada la solución gráfica.

Fundamento: Al igual que en el fundamento anterior este requerimiento esta orientado a proveer de acuerdo al criterio del usuario, una mejor visualización del comportamiento del modelo.

5.- El tiempo en que se representa la solución gráfica no se considera una restricción del sistema.

Fundamento: Debido a que la simulación 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 solución no representa una limitante.

6.- El tiempo en que se toman las fotos que contienen parte de la solución gráfica 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.

7.- El sistema debe ser desarrollado en un lenguaje de programación que permita crear programas ejecutables.

Fundamento: Esto le dará mayor portabilidad al sistema, ya que no lo ligara con una herramienta de software específica, y le permitirá probar modelos más complejos que dependan de la capacidad del hardware utilizado y no de una herramienta de software específica.

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 tamaño 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 serán guardadas en un archivo de texto.

Fundamento: Los archivos de texto son un estándar que puede ser editados fácilmente por otros editores de texto, y este formato también facilita y hace más rápida la impresión 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 guíen al usuario al operar el mismo.

Especificación de Requerimientos

En esta sección se presentan descripciones más detalladas de los requerimientos del usuario, y representan el punto de partida para la siguiente etapa que es el diseño del sistema. En el presente proyecto fue seleccionada la metodología 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 comprensión del lenguaje natural y asegura que cierto grado de uniformidad se imponga a la especificación.

Requerimientos Funcionales