UNIVERSIDAD YACAMBÚ
Asignatura: Análisis y Diseño de
Sistemas
Fase II
Trabajo Nro: 4
Profesor: Yaros Pérez
Autor: Rusbel R. Dimas G.
“DESARROLLO DE UN SISTEMA DE INFORMACIÓN BASADO EN TECNOLOGÍA
WEB CON ACCESO A BASE DE DATOS”
1. Softwares que permitan realizar acceso a Base de Datos
utilizando un sistema de información en la Web.
Java Server Pages (JSP)
Es una
tecnología Java que permite generar contenido dinámico para Web, en forma de
documentos HTML, XML o de otro tipo.
JSP puede
considerarse como una manera alternativa, y simplificada, de construir servlets. Es por esto que una página puede
hacer todo lo que un servlet puede hacer, y viceversa. Cada versión de la
especificación de JSP está fuertemente vinculada a una versión en
particular de la especificación de servlets.
El
funcionamiento general de la tecnología JSP es que el Servidor de Aplicaciones
interpreta el código contenido en la página JSP para construir el código
Java del servlet a generar. Este servlet será el que genere el documento
(típicamente HTML) que se presentará en la pantalla del Navegador del
usuario.
JSP -> Servidor
Aplicaciones (Servlets) -> Cliente (Navegador)
La principal
ventaja de JSP frente a otros lenguajes es que el lenguaje Java es un
lenguaje de propósito general que excede el mundo Web y que es apto para crear
clases que manejen lógica de negocio y acceso a datos de una manera prolija.
Esto permite separar en niveles las aplicaciones Web, dejando la parte
encargada de generar el documento HTML en el archivo JSP. Otra
ventaja es que JSP hereda la portabilidad de Java, y es posible ejecutar
las aplicaciones en múltiples plataformas sin cambios. Es común incluso que los
desarrolladores trabajen en una plataforma y que la aplicación termine siendo
ejecutada en otra.
Los servlets y
Java Server Pages (JSPs) son dos métodos de creación de páginas Web dinámicas
en servidor usando el lenguaje Java. En ese sentido son similares a otros
métodos o lenguajes tales como el PHP, ASP o los CGIs
(common gateway interface), programas que generan páginas Web en el servidor.
Sin embargo, se diferencian de ellos en otras cosas.
Para empezar,
los JSPs y servlets se ejecutan en una máquina virtual Java, lo cual permite
que, en principio, se puedan usar en cualquier tipo de ordenador, siempre que
exista una máquina virtual Java para él. Cada servlet (o JSP, a partir
de ahora lo usaremos de forma indistinta) se ejecuta en su propia hebra, es
decir, en su propio contexto; pero no se comienza a ejecutar cada vez que recibe
una petición, sino que persiste de una petición a la siguiente, de forma que no
se pierde tiempo en invocarlo (cargar programa + intérprete). Su persistencia
le permite también hacer una serie de cosas de forma más eficiente: conexión a
bases de datos y manejo de sesiones, por ejemplo.
Los JSPs son en
realidad servlets: un JSP se compila a un programa en Java la primera
vez que se invoca, y del programa en Java se crea una clase que se empieza a
ejecutar en el servidor como un servlet. La principal diferencia entre los
servlets y los JSPs es el enfoque de la programación: un JSP es una
página Web con etiquetas especiales y código Java incrustado, mientras que un
servlet es un programa que recibe peticiones y genera a partir de ellas una
página Web.
Ambos necesitan
un programa que los contenga, y sea el que envíe efectivamente páginas Web al
servidor, y reciba las peticiones, las distribuya entre los servlets, y lleve a
cabo todas las tareas de gestión propias de un servidor Web. Mientras que
servidores como el Apache están especialmente pensados para páginas Web
estáticas CGIs, y programas ejecutados por el servidor, tales como el PHP.
HyperText Markup Language (HTML)
El lenguaje HTML, a pesar de su sencillez, es sin duda un
invento prodigioso. Es el más exitoso sistema de presentación de documentos de
la historia. Desde que apareció el WWW, gracias al HTML hemos podido
publicar y acceder a más información de la que jamás hemos podido imaginar.
Pero a su vez, el HTML ha sido víctima de su propio
éxito. El gran crecimiento de Internet, los intereses comerciales y la
necesidad de poder realizar páginas Web vistosas, ha dado lugar a que en poco
tiempo este lenguaje haya evolucionado muy rápidamente y, por desgracia, no
siempre por el camino más adecuado. Actualmente estamos en la versión 4.0 y,
sin embargo, sigue siendo igual de rígido e inflexible como era en un
principio. Y es que es un lenguaje limitado en cuanto que no nos permite
realizar sobre Internet todas las aplicaciones o cosas que nos gustaría.
Extensible Markup
Language (XML)
Es un Lenguaje
de Etiquetado Extensible muy simple, pero estricto que juega un papel fundamental
en el intercambio de una gran variedad de datos. Es un lenguaje muy similar
a HTML;
pero su función principal es describir datos y no mostrarlos como es el caso de
HTML. XML es un formato que permite la lectura de datos a través de
diferentes aplicaciones.
Las tecnologías XML
son un conjunto de módulos que ofrecen servicios útiles a las demandas más
frecuentes por parte de los usuarios. XML sirve para estructurar,
almacenar e intercambiar información.
Entre las
tecnologías XML disponibles se pueden destacar:
XSL: Lenguaje
Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar cómo debería
estar estructurado el contenido, cómo debería ser diseñado el contenido de
origen y cómo debería ser paginado en un medio de presentación como puede ser
una ventana de un navegador Web o un dispositivo móvil, o un conjunto de
páginas de un catálogo, informe o libro.
XPath: Lenguaje de
Rutas XML, es un lenguaje para acceder a partes de un documento XML.
XLink: Lenguaje de
Enlace XML, es un lenguaje que permite insertar elementos en documentos XML
para crear enlaces entre recursos XML.
XPointer: Lenguaje de
Direccionamiento XML, es un lenguaje que permite el acceso a la estructura
interna de un documento XML, esto es, a sus elementos, atributos y contenido.
XQL: Lenguaje de Consulta XML, es un
lenguaje que facilita la extracción de datos desde documentos XML. Ofrece la
posibilidad de realizar consultas flexibles para extraer datos de documentos
XML en la Web.
HTML,
XML, versus SGML
Tampoco tenemos que equivocarnos y pensar que el XML es
un HTML++. Tanto el XML como el HTML tienen su base en el SGML. El
SGML (Standard Generalized Markup Language, ISO 8879) es el estándar
internacional para la definición de la estructura y el contenido de diferentes
tipos de documentos electrónicos. Es decir, es un metalenguaje que nos
permite definir lenguajes para definir la estructura y el contenido de nuestros
documentos. La definición de la estructura y el contenido de un tipo de
documento se realiza en una DTD. En ella definimos los elementos que
conformarán ese tipo de documentos y como tienen que estar organizados para que
sea correcto.
Un ejemplo de DTD es por ejemplo la que define cómo tendrán que
ser los documentos HTML. Por tanto, el HTML no es más que un tipo de
documento SGML que se utiliza en la Web, y esto es importante, ya que
aquí radica su principal diferencia con el XML. El XML no es ningún tipo
de documento SGML, sino que es una versión abreviada de SGML
optimizada para su utilización en Internet. Esto significa que con él vamos a
poder definir nuestros propios tipos de documentos (podremos definir nuestras
propias etiquetas) y, por tanto, ya no dependeremos de un único e inflexible
tipo de documento HTML.
El XML más que un HTML++ hay que considerarlo como un SGML--
optimizado para su utilización en Internet.
Como escribió Richard Ligth en su libro Presenting XML, "XML ofrece
el 80% de las ventajas del SGML con un 20% de su complejidad". Y es que
los diseñadores de XML intentaron dejar fuera sólo aquellas partes que
raramente se utilizan. Esta reducción resultó ser muy importante: la
especificación XML ocupa aproximadamente 30 páginas, frente a las 500 del SGML.
Active Server Pages (ASP)
Es la tecnología para la creación de páginas dinámicas del lado
del servidor desarrollada por Microsoft.
La tecnología ASP
está estrechamente relacionada con el modelo tecnológico de su fabricante.
Intenta ser solución para un modelo de programación rápida ya que programar
en ASP es como programar en Visual Basic, por supuesto con muchas
limitaciones.
Lo interesante
de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados
como algunos controles ActiveX así como componentes del lado del servidor,
tales como CDONTS, por ejemplo, que permite la interacción de los scripts con
el servidor SMTP que integra IIS.
Se facilita la
programación de sitios Web mediante varios objetos integrados, como por ejemplo
un objeto de sesión basada en cookies, que mantiene las variables mientras se
pasa de página a página.
Diferencia de ASP.net con el ASP común que
conocemos
Mucha, realmente es mucha. Mientras ASP se escribía en
VBScript, ASP.net puede ser escrito en cualquier lenguaje soportado por
el .net Framework, es decir: VB.net; C# y JScript.net. Si, ya no se puedes
utilizar VBScript sino se debe utilizar VB.net que es lo que más se aproxima.
Otro cambio radical es que ASP.net es un lenguaje totalmente orientado a
objetos.
Profesional Home
Pages (PHP)
La solución para
la construcción de Webs con independencia de la Base de Datos y del servidor
Web, válida para cualquier plataforma. El objetivo final es conseguir la
integración de las paginas HTML con aplicaciones que corran en el
servidor como procesos integrados en el mismo, y no como un proceso separado,
como ocurría con los CGIs. Igualmente interesa que dichas aplicaciones sean
totalmente independientes del navegador (lo que no ocurría con otros lenguajes
basados en scripts, como JavaScript o VisualBasic Script), independientes de la
plataforma y de la Base de Datos.
El lenguaje PHP es un lenguaje de programación de estilo
clásico, con esto quiero decir que es un lenguaje de programación con
variables, sentencias condicionales, bucles, funciones.... No es un lenguaje de
marcas como podría ser HTML, XML o WML. Está
mas cercano a JavaScript o a C.
Pero a diferencia de Java o JavaScript que se ejecutan en
el navegador, PHP se ejecuta en el servidor, por eso nos permite acceder
a los recursos que tenga el servidor como por ejemplo podría ser una base de
datos. El programa PHP es ejecutado en el servidor y el resultado
enviado al navegador. El resultado es normalmente una página HTML pero
igualmente podría ser una pagina WML.
Al ser PHP
un lenguaje que se ejecuta en el servidor no es necesario que su navegador lo
soporte, es independiente del navegador, pero sin embargo para que sus páginas PHP
funcionen, el servidor donde están alojadas debe soportar PHP.
2. Caso Práctico. Suponga que usted lo contrata una empresa que tiene un producto
y lo quiere comercializar en la Web. Usted debería realizar el análisis y
diseño de un Sistema de Información de un portal Web.
Análisis y diseño de un Sistema de Información de un portal Web
para la Empresa Petroritupano S.A. Filial de PDVSA
TÍTULO:
Análisis y Diseño de un Sistema de
Información de un Sitio Web para la Administración y Control de los equipos industriales y los suministros del Almacén Principal de la Empresa Petroritupano S.A. del
Estado Anzoátegui.
ACERCAMIENTO AL PROBLEMA DE INVESTIGACIÓN:
Actualmente
el Almacén Principal de
la Empresa Petroritupano S.A. del Estado Anzoátegui tiene problemas en el manejo de inventario,
ya que para dar de alta o de baja a los suministros y equipos industriales, se
hace de forma manual, mediante una hoja de cálculo en excel; este método es
inseguro y muy lento, es decir, cada suministro o equipo tiene que ser tecleado
y cada cambio a las existencias tiene que ser capturada nuevamente. La
confiabilidad del Inventario de la empresa: Petroritupano S.A. del estado Anzoátegui, depende del
cuidado con que se realicen estas tareas tan importantes como lo es dar de alta
y baja a los suministros y equipos, en una hoja de cálculo de excel.
Se desea Diseñar un Sitio Web para la Administración
y Control de los equipos industriales y los suministros. Este Sitio Web va
poder ser accesado de una manera pública (sólo consultas) y privada (todas las
operaciones internas relacionadas al Almacén Principal). El acceso al sistema
se podrá realizar por Internet o por la Intranet de la empresa.
El Diseño a
realizar pretende dar una solución al problema presentado por la Gerencia de
Servicios, Petroritupano S.A. del Estado Anzoátegui, por la no existencia
de un Sitio Web, para la administración y control de suministros y equipos del
Almacén Principal.
FORMULACIÓN
DEL PROBLEMA:
¿Cómo se puede llevar a cabo un mejor control del inventario en la
empresa Petroritupano S.A. del estado Anzoátegui?
¿Cuáles
son los beneficios, en términos de agilizar los procesos de entrada y salida,
al implementar el Sitio Web para la Administración y Control de los equipos industriales y
los suministros?
La
estrategia a seguir en esta investigación se basará en el desarrolló de un
estudio teórico-práctico encaminado al Diseño de un Sitio Web de un modelo de
inventario de tipo probabilístico. El modelo pretende establecer las políticas
óptimas del inventario, considerando el carácter aleatorio de la demanda y los
tiempos de entrega. La solución propuesta tiene como finalidad disminuir la
tasa de faltantes y el alto nivel de inventario que afecta a la empresa. Como
producto final de la investigación, se diseñará un Sitio Web para la Administración y
Control de los equipos industriales y los suministros.
En el Sitio Web también se podrá realizar una clasificación de los suministros
y equipos, clientes y proveedores en pro de prestar mayor control y eficiencia
en la administración de las existencias.
El
estudio se realizará en la empresa: Petroritupano S.A. Filial de PDVSA.
Campo petrolero la Leona, Sector 4 Vías, Carretera San Tome - Oritupano,
jurisdicción del Municipio Freites del estado Anzoátegui.
El
desarrollo e implementación de esta investigación puede aportar al ambiente
laboral un significativo avance por su gran importancia y los beneficios que
puede brindar.
Al
aportarse un beneficio para la empresa, se puede decir que indirectamente se está beneficiando a la
sociedad y al país por ser esta una empresa del estado venezolano.
JUSTIFICACIÓN:
La importancia de los sistemas de información a través de una
mirada retrospectiva a la administración permite llevar a las empresas u
organizaciones a desarrollar las
funciones del proceso administrativo como planear, organizar, dirigir y
controlar de una manera más eficaz las actividades que se designa a cada
uno de los miembros de la organización.
Lo interesante del sistema de información del Sitio Web para el
control del inventario de la empresa Petroritupano S.A. del estado Anzoátegui,
es que se busca a que contribuya a mejorar la eficacia y eficiencia en la
recepción y despacho de los mismos para salvaguardar la operatividad de la
empresa
Así mismo, para el departamento de almacén es indispensable, ya
que le permitirá contar con una herramienta para obtener información rápida y
oportuna ya que con el mismo se lleva la administración y el control de los
suministros y equipos.
Es conveniente informar que para la puesta en marcha del Sitio
Web, se debe contar con una serie de requerimientos técnicos, tales como:
Acceso a Internet, Servidor Web para alojar la aplicación, El Dominio será el
que asigne la empresa Petroritupano S.A. del estado Anzoátegui.
La inversión de los equipos necesarios para la puesta en marcha
del Sitio Web, se justifica en la necesidad de conectividad constante y
actualizada de los distintos entes relacionados con el Sitio Web.
HIPOTESIS DE LA INVESTIGACIÓN:
Mediante
el desarrollo de un Sitio Web para la Administración y Control de los equipos industriales y los suministros, se puede llevar a cabo un eficiente control de inventario de la
empresa Petroritupano S.A. del estado Anzoátegui.
NOMBRE DEL SISTEMA BASADO EN WEB:
SAC-WEB
OBJETIVO GENERAL:
Diseño de un Sistema de Información Basado en Web, para la Administración y Control de los equipos industriales y los
suministros del Almacén
Principal de la Empresa Petroritupano S.A. del Estado Anzoátegui. (SAC-WEB).
OBJETIVOS
ESPECÍFICOS:
1. Analizar la importancia de las operaciones del Almacén Principal.
2. Realizar un estudio de todas las actividades del Almacén Principal.
3. Utilizar una herramienta de modelado para lograr la
especificación de los requerimientos del sistema.
4.
Diseñar
la interfaz del usuario,
la estructura o formato de cada pantalla y los mensajes de error.
5.
Diseñar los reportes y formularios que el sistema va
a generar.
6.
Diseñar
la base de datos.
7.
Diseñar
la estructura del Software.
8.
Codificar
los procedimientos diseñados, utilizando como herramienta de programación Visual
Basic.
9.
Realizar
prueba e integración de los procedimientos codificados.
10. Elaborar el manual de usuario y el
manual de mantenimiento del Sitio Web.
1. FASE DE INICIO
El objetivo global de la
Fase de Inicio está guiado fundamentalmente a la captura de requisitos, este se
logra con una efectiva identificación de casos de uso del sistema y el
refinamiento de los mismos mediante las etapas de análisis y diseño. Todos los
objetivos de cada fase pueden lograrse a través de iteraciones, en las cuales
se realizan los flujos de trabajos (requisitos, análisis, diseño,
implementación y prueba); adaptados a las necesidades y al contexto de dicha
fase. Dependiendo de la fase que esté en desarrollo, se puede hacer mayor
énfasis en algunos de los flujos de trabajos antes mencionados.
El Proceso Unificado de
Desarrollo de Software está dirigido por los casos de uso, estableciendo así
las funcionalidades que se deben alcanzar tanto en las fases como en las
iteraciones.
En la Figura 1., se muestra en la columna izquierda los flujos de trabajo,
(requisitos, análisis, diseño, implementación y prueba). Las curvas mostradas
son una aproximación de hasta donde se llevan a cabo los flujos de trabajo en
cada fase y además cada fase se divide normalmente en iteraciones. Para la Fase
de Inicio del SAC-WEB, sólo fue
necesaria una iteración en la cual se logró un 85% de los requisitos, llegando
a un 35% del análisis; para los flujos de trabajo diseño, implementación y
prueba no se realizó ningún progreso por
ser la fase inicial.
1.1.
CAPTURA DE REQUISITOS
El inicio de todas las
tareas del ciclo de desarrollo es realmente el conocimiento de los
requerimientos. Para la Fase de Inicio, precisamente por ser la primera se
necesita de un trabajo arduo en la captura de requisitos ya que se presenta un
proyecto desconocido y que seguramente no esté definido claramente.
Inicialmente se puede contar con una breve descripción del sistema que de una
base para la extracción de requisitos. La exactitud de dicha descripción va a
depender de la procedencia de la misma, puede ser de un grupo de usuarios que
tienen poco conocimiento de lo que se puede realizar de forma automatizada. Se
necesita reunir los aspectos más importantes que puedan ser aportados por todos
los participantes en el desarrollo del sistema, debido a que se trata de crear
una lista de requisitos que significan el punto de partida del proyecto,
teniendo en cuenta que más adelante estos pueden ser modificados o cambiados
dependiendo de las necesidades y limitaciones que se puedan tener. Existen una
serie de pasos factibles y efectivos para una buena captura de requisitos.
1.1.1.
Contexto del Sistema
La recolección de datos
se basó inicialmente en la observación directa del funcionamiento del Almacén Principal en condiciones normales de servicio, lo que permitió tener una
descripción más precisa de las características del almacén, tanto su
administración como el control de todas sus actividades. Estas observaciones se
realizaron mediante visitas guiadas por el asesor industrial y el personal
encargado del almacén.
Luego se procedió con la
revisión bibliográfica en la cual se consultó y recopiló toda la bibliografía y
documentos internos (disponibles) de la empresa, que se relacionaban con el
avance y/o desarrollo del sistema SAC-WEB.
Se analizó el sistema
actual, definiendo los problemas. Para lograr esto, se realizaron entrevistas
informales no estructuradas al personal relacionado con el Almacén Principal de tal manera de obtener la información necesaria de manera
rápida, producto de la experiencia sobre la realización de las labores de
administración y control, las cuales se realizaban de una manera poco eficaz
para el funcionamiento de dicho almacén, originando todo esto un aumento en los
costos e inversión de trabajos y así llegando a tener una considerable
disminución en el nivel de servicio.
Al finalizar las
entrevistas y revisiones bibliográficas, se estableció el contexto de creación
del sistema “SAC-WEB” y se
determinaron los distintos requerimientos de información con los cuales debía
cumplir.
1.1.2.
Modelo del Dominio
La elaboración de un Modelo del Dominio o Modelo Conceptual,
es necesaria para entender mejor el contexto del sistema y representar
conceptos concernientes al dominio del mismo de una forma clara. En términos
informales un concepto es una idea, cosa u objeto. En un lenguaje más formal,
se puede considerar a partir de su símbolo, intención y extensión. La intención
de un concepto es la descripción de sus atributos, operaciones y significado. La
extensión es el conjunto de instancias u objetos muestra que pertenecen a él.
La identificación de conceptos forma parte de una investigación del dominio del
problema.
El lenguaje UML,
contiene la notación en diagramas de estructura estática que explican
gráficamente los modelos conceptuales. Una cualidad esencial que debe ofrecer
un modelo conceptual es que representa cosas del mundo real, no componentes del
software.
Un Modelo del Dominio
captura los tipos más importantes de objetos en el contexto del sistema. Muchos
de los objetos del dominio o clases (para emplear una terminología más precisa)
pueden obtenerse de una especificación de requisitos o mediante de entrevistas
con los futuros usuarios.
Mediante diagramas de
UML (especialmente diagramas que bosquejan las clases), se describe el Modelo
del Dominio. En este modelo se debe obviar cualquier información acerca del
comportamiento interno del sistema y de como soportará las funcionalidades
esperadas, ya que tiene un fin de tratamiento y comprensión del problema, y no
de la solución. En la Figura 2., se
muestra el Modelo del Dominio del Sistema Propuesto en el cual se describen las
clases más importantes dentro del contexto del sistema, estas clases también
representan algunos entes físicos tales como Empresa, Almacén Principal y PC que están relacionados con el
sistema.
1.1.3.
Glosario de Términos
El Glosario de Términos,
(Ver Tabla 1.), incluye y define la
mayoría de los términos que requieren ser explicados para mejorar la
comunicación y aminorar los riesgos de malos entendidos entre los
desarrolladores y los clientes o usuarios. De esta manera se facilita el
intercambio de ideas y la colaboración entre los interesados en el desarrollo
del sistema.
|
TÉRMINO |
DEFINICIÓN |
|
Usuario |
Persona que interactúa con el sistema SAC-WEB. |
|
Clave |
Contraseña para conectarse al sistema SAC-WEB,
la cual conjuntamente con el nombre del usuario conforman los datos
necesarios para tener acceso al SAC-WEB. |
|
SAC-WEB |
Sistema de Administración y Control, del
Almacén Principal. |
|
Personal |
Empleados pertenecientes a Petroritupano S.A. que están relacionados con las
actividades del Almacén Principal. |
|
Petroritupano S.A. |
Compañía venezolana encargada de la
exploración, explotación y producción de petróleo y sus derivados. |
Tabla 1. Glosario de
Términos
1.1.4.
Requisitos Funcionales
Los Requisitos
Funcionales especifican:
·
Acciones que el sistema debe ser capaz de realizar, sin
considerar restricciones físicas.
·
El comportamiento de entrada/salida del sistema.
1.1.4.1.
Identificación de Riesgos
Es necesario contar con
una serie de parámetros que indiquen de una forma intuitiva la correspondencia
de ciertas actividades a las iteraciones, y que permitan la asignación de los
casos de uso a las mismas y así poder determinar el contenido de cada
iteración. Se dice de forma intuitiva ya que todo depende de la naturaleza y
dificultad del proyecto a desarrollar y de la compresión del dominio del
problema que se pueda tener. De cualquier manera, estos parámetros están
constituidos por los riesgos.
Un riesgo es una
probabilidad de que el proyecto se vea afectado en su desarrollo o
posteriormente en su comportamiento. Estos deben ser tratados de acuerdo a su
importancia y prioridad.
Para la identificación
de riesgos se realizaron como en las secciones anteriores, la observación
directa, entrevistas informales no estructuradas, revisión bibliográfica y
consultas de documentos internos (disponibles) de la empresa. Estas fueron las
técnicas utilizadas para la recopilación de datos y posterior análisis con el
cual fue posible identificar los principales riesgos que podrían limitar la
construcción del sistema.
Entre los riesgos que se
pueden presentar en un proyecto de desarrollo se encuentra el de no poder
realizarlo. A este tipo de riesgos se le conoce como riesgo crítico y deben ser
tratados muy pronto en el ciclo de desarrollo.
Los riesgos dirigen la
viabilidad del sistema en el Proceso Unificado de Desarrollo de Software. Para
saber si el sistema era factible, se identificaron los riesgos críticos y a
partir de ellos se diseñaron los casos de uso principales del sistema, para así
de esta forma poder tratar y eliminar dichos riesgos.
Luego de haber
identificado y priorizado los riesgos, se procede a decidir como tratar cada
uno de ellos. (Ver Tabla 2.).
Fundamentalmente se cuenta con cuatro
elecciones: evitarlo, limitarlo, atenuarlo o controlarlo. Existen riesgos que
se pueden y deberían evitarse, posiblemente mediante una nueva planificación
del proyecto o un cambio en los requisitos, otros deberían limitarse
restringiéndolos de modo que sólo afecten a una parte del proyecto, algunos
riesgos pueden atenuarse ejercitándolos y observando si aparecen o no. Aunque,
existen riesgos que no pueden atenuarse. Únicamente se pueden controlar y
observar si aparecen. Se debe tener un
plan de contingencia si esto ocurre.
Los riesgos críticos
principales del proyecto, los cuales responden a las probabilidades de errores
o insuficiencias que se pueden presentar en el desarrollo de cualquier sistema,
tales como la inseguridad que puede existir acerca del uso de las herramientas
apropiadas para resolver el problema o las fallas en acceso a la Base de Datos,
se muestran en la Tabla 2. En la
cual puede observarse: la descripción del riesgo, impacto que puede causar,
responsable del riesgo, plan de contingencia (para mitigar los riesgos).
En ésta Fase de Inicio
se lograron atenuar unos pocos riesgos críticos, en posteriores iteraciones se
tratará de mitigarlos en su totalidad.
|
DESCRIPCIÓN |
IMPACTO |
RESPONSABLE |
CONTINGENCIA |
|
Falta de dominio del contexto |
Producto Software |
Desarrollador |
Insistir en el dominio del contexto |
|
Uso de herramientas inadecuadas para resolver el problema |
Producto Software |
Desarrollador |
Analizar previamente las herramientas a utilizar, verificando
sus capacidades |
|
Fallas en acceso a la Base de Datos |
Consultas |
Desarrollador |
Revisar exhaustivamente todo lo relacionado a la Base de Datos
|
|
Incompatibilidad en integración a plataforma |
Producto Software |
Desarrollador |
Verificar la compatibilidad del sistema con la plataforma,
tanto de hardware como de software |
Tabla 2. Lista de
Riesgos Críticos
1.1.4.2.
Identificación de Actores
Los actores tienen las
siguientes características:
·
Son externos al sistema.
·
Interactúan con el sistema. Los actores pueden utilizar
funcionalidades provistas por el sistema, pero también pueden proveer
funcionalidad al sistema. Los actores pueden obtener o ingresar información al
sistema.
Los actores principales del
sistema SAC-WEB, identificados durante esta primera fase (y primera iteración)
son los siguientes:
·
Usuario: Persona
encargada de dirigir las actividades del Almacén Principal, el usuario necesita
del sistema para controlar y administrar las actividades de dicho almacén.
·
Manejador de
Base de Datos (BDdatos): Se considera un actor debido a que interactúa directamente con
el sistema. Toda la información que el SAC-WEB manipula está contenida en esta
base de datos (BDdatos) distribuidas en tablas diseñadas exclusivamente para su
uso.
·
Manejador de
Ayuda: Sistema que permite codificar la ayuda del SAC-WEB.
1.1.4.3.
Identificación de Casos de Uso
Luego de haber
identificado los riesgos críticos y los actores principales, se procede a
identificar los casos de uso que servirán como medio de interacción entre estos
y el sistema SAC-WEB. En la Figura 3.,
se muestran los casos de uso necesarios para cumplir con lo que establece el
Proceso Unificado de Desarrollo de Software, para esta fase.
El caso de uso Accesar al Sistema se estableció debido
a que se necesitaba controlar el acceso al sistema. Luego se creó el caso de
uso Controlar Suministros para
llevar a cabo el control general, referente al manejo de los suministros y
equipos.
Para manejar o agrupar
los datos de los proveedores a los cuales
se les realizan los pedidos de suministros y equipos para el Almacén Principal,
se estableció el caso de uso Manipular
Información de Proveedores. Por otra parte se necesitaba respaldar la
información generada mediante el sistema y es por eso que se implanto el caso
de uso Respaldar Información. Y por
todas las necesidades planteadas por los encargados del control de las
actividades del almacén se crearon los otros casos de uso: Aplicar Opciones Avanzadas para permitir manipular opciones
avanzadas disponibles sólo para usuarios autorizados. Generar Reportes para generar los reportes requeridos por el
usuario, pueden ser generados por pantalla o impresora. Utilizar ayuda facilita un conjunto de ayudas del sistema.
1.1.4.3.1.
Casos de Uso detallados
Los diagramas de casos
de uso, dirigen todo el proceso de desarrollo debido a que la mayoría de las
actividades como el análisis, diseño y prueba se llevan a cabo partiendo de
estos diagramas.
Con la finalidad de
presentar información pormenorizada para la fase de análisis, a continuación se
explican detalladamente los casos de usos identificados anteriormente.
Caso
de Uso: Accesar al Sistema
Actores:
Usuario,
Manejador de Base de Datos (BDdatos)
Descripción: Permite al
usuario tener acceso al sistema SAC-WEB, mediante la verificación de los datos.
Estado
Inicial: El sistema está en espera de los datos del usuario.
Flujo
de Sucesos:
- El
usuario ingresa sus datos al sistema.
- El
usuario confirma o cancela.
- El
sistema verifica los datos si el usuario confirma.
- El
sistema se cierra si el usuario cancela.
- El
sistema muestra un mensaje de “acceso negado” si el usuario coloca los
datos incorrectos.
- El
sistema permite tres intentos de datos incorrectos.
- Si
los datos son correctos el sistema permite el acceso al usuario.
- Finaliza
el caso de uso.
Caso
de Uso: Controlar Suministros
Actores:
Usuario,
Manejador de Base de Datos (BDdatos)
Descripción: Este caso de
uso es fundamental para el sistema SAC-WEB, ya que permite el control general
referente al manejo de los suministros y equipos.
Estado
Inicial: Una vez iniciado el sistema es posible que se ejecute la opción
de controlar suministros.
Flujo
de Sucesos:
- El
usuario solicita controlar suministros.
- El
sistema muestra las opciones de controlar suministros.
- El
usuario selecciona la opción de su preferencia.
- El
sistema presenta al usuario una pantalla perteneciente a la opción
elegida.
- El
usuario realiza su objetivo.
- Cuando
el usuario lo decida finaliza el caso de uso.
Caso
de Uso: Manipular Información de Proveedores
Actores:
Usuario,
Manejador de Base de Datos (BDdatos)
Descripción: Maneja o agrupa
los datos de los proveedores a los cuales se les realizan los pedidos de
suministros y equipos para el almacén.
Estado
Inicial: Se encuentra en espera de ser ejecutado por el usuario.
Flujo
de Sucesos:
- El
usuario solicita registro de proveedores.
- El
sistema muestra una lista con los datos de los proveedores.
- El
usuario desea eliminar un proveedor.
- El
sistema borra ese proveedor.
- El
usuario desea modificar los datos de un proveedor.
- El
sistema modifica los datos de ese proveedor.
- El
usuario desea agregar un proveedor.
- El
sistema agrega el proveedor.
- Cuando
el usuario lo decida finaliza el caso de uso.
Caso
de Uso: Respaldar Información
Actores:
Usuario,
Manejador de Base de Datos (BDdatos)
Descripción: Este caso de
uso permite respaldar la información generada por el sistema SAC-WEB.
Estado
Inicial: Una vez iniciados el sistema es posible respaldar la
información.
Flujo
de Sucesos:
- El
usuario solicita respaldar información.
- El
sistema emite un mensaje al usuario, para que éste prepare la unidad a la
que desea copiar la información.
- El
usuario confirma la opción de respaldar información.
- El
sistema guarda la información.
- Cuando
el usuario lo decida finaliza el caso de uso.
Caso
de Uso: Aplicar Opciones Avanzadas
Actores:
Usuario,
Manejador de Base de Datos (BDdatos)
Descripción: Permite un
conjunto de opciones avanzadas disponibles sólo para usuarios autorizados.
Estado
Inicial: El usuario autorizado desea tener acceso a las opciones
avanzadas.
Flujo
de Sucesos:
- El
usuario autorizado desea acceder a las opciones avanzadas.
- El
sistema muestra las opciones al usuario.
- El
usuario elige una opción.
- El
sistema muestra una pantalla relacionada a la opción elegida por el
usuario.
- Este
caso de uso finaliza cuando el usuario lo decida.
Caso
de Uso: Generar Reportes
Actores:
Usuario,
Manejador de Base de Datos (BDdatos)
Descripción: Este caso de
uso facilita generar el reporte requerido por el usuario.
Estado
Inicial: Luego de estar cargados los datos al sistema es posible
ejecutar la opción de generar reportes.
Flujo
de Sucesos:
- El
usuario desea generar un reporte.
- El
sistema muestra el reporte solicitado por el usuario.
- El
usuario elige si sólo quiere ver el reporte por pantalla o imprimirlo.
- El
sistema responde a la decisión del usuario.
- Cuando
el usuario así lo desee, finalizará el caso de uso.
Caso
de Uso: Utilizar Ayuda
Actores:
Usuario,
Manejador de Ayuda
Descripción:
Facilita
un mecanismo de ayuda al usuario.
Estado
Inicial: El usuario solicita una ayuda referente al sistema.
Flujo
de Sucesos:
- El
usuario solicita ayuda al sistema.
- El
sistema accede al manejador de ayuda, el cual muestra al usuario los
tópicos que abarca.
- El
usuario selecciona el tópico y solicita la información.
- El
manejador de ayuda muestra la información solicitada,
- El
usuario puede solicitar toda la información que desee, que esté
contemplada entre los tópicos del sistema de ayuda.
- Este
caso de uso finaliza cuando el usuario lo decida.
1.1.5.
ANÁLISIS
En el análisis se pueden
incluir detalles internos del sistema, sin llegar a un nivel tan preciso como
los del diseño y la implementación, pero dejando claros algunos puntos que
pudieron pasar desapercibidos en la etapa de recopilación de requisitos.
1.1.5.1.
Análisis General
El análisis no requiere
ser exhaustivo en la Fase de Inicio, por el contrario, solo se realiza una
primera versión del modelo de análisis que permita tener una noción, por lo
menos general, de lo que puede ser la etapa de diseño. No obstante, hay que
recordar que esta primera versión del modelo de análisis incluye a los casos de
uso más importantes del sistema, los que llevarán al cumplimiento de los
objetivos de esta fase, por lo que no se le puede restar importancia al trabajo
que se puede llevar a cabo en este momento.
Siguiendo las
directrices del Proceso Unificado de Desarrollo de Software, se realizan una
serie de actividades cuyos resultados constituyen la versión inicial del modelo
de análisis.
En la etapa de análisis
se busca modelar el sistema desde un punto de vista representativo de lo que va
a ser en realidad. En la Fase de Inicio, el objetivo principal del análisis es
esbozar un modelo de análisis.
Se realizó un esbozo del
modelo de análisis, mediante un diagrama de paquetes de UML, en el cual se
muestra un paquete general llamado SAC-WEB que viene siendo el sistema, y
dentro de éste se encuentran los principales subsistemas (Control de
Suministros, Opciones Avanzadas, Respaldo de Información, Reportes) y sus
dependencias accediendo a entidades con las que guardan relación (Ver Figura 4.).
Los procesos de Control
de Suministros y Opciones Avanzadas se presentan como subsistemas que modifican
la información almacenada en la base de datos del sistema (BDdatos).
Por último se muestran
las dependencias de los subsistemas (Respaldo de Información y Reportes) hacia
la base de datos del sistema, ya que de ella surge la información de la que
dependen estos procesos.
El producto software
depende de las operaciones que se realizan en el sistema, ya que son ellas
quienes le permiten ofrecer sus beneficios.
1.1.5.2.
Análisis del caso de uso Controlar Suministros
Este caso de uso revela
una faceta importante del proyecto: su complejidad. En el diagrama de la Figura 5., se muestra al usuario en la
etapa inicial de utilización del sistema, cuando realiza la carga de datos al
sistema. Es en este momento en el que se
almacena toda la información en la base de datos del sistema, todas estas
actividades se realizan de manera automática, dada la solicitud del usuario.
Primeramente, es
necesaria la identificación de las clases del análisis, las cuales pueden
pertenecer a uno de tres estereotipos de UML:
·
Clases de
Interfaz: Se utilizan para modelar la interacción entre el sistema y sus
actores (es decir, usuarios y sistemas externos). Esta interacción a menudo
implica recibir (y presentar) información y peticiones de (y hacia) los
usuarios y los sistemas externos.
·
Clases de
Entidad: Se utilizan para modelar información que posee una vida larga
y que es a menudo persistente. Las clases de entidad modelan información y el
comportamiento asociado de algún fenómeno o concepto, como una persona, un
objeto del mundo real o un suceso del mundo real.
·
Clases de
Control: Representan coordinación, secuencia, transacciones y control
de otros objetos y se usan con frecuencia para encapsular el control de un caso
de uso en concreto.
Estos estereotipos están
estandarizados en UML y se utilizan para ayudar a los desarrolladores a
distinguir el ámbito de las diferentes clases. Cada uno de estos estereotipos
de clase encapsula un tipo diferente de comportamiento (o funcionalidad, si se
quiere). Cada estereotipo tiene su propio símbolo, como se pueden observar en
la Figura 6.
Estas clases representan
una abstracción de una o varias clases y/o subsistemas del diseño del sistema y
se utilizan en el modelo del análisis para encapsular la información
preliminar.
En el modelo inicial de
análisis mostrado en la Figura 5., se presentan dos clases de interfaz: Interfaz de Control, quien le permite
interactuar al usuario con el sistema, mediante el uso de las opciones
disponibles pudiendo ejecutar los procesos de control de suministros; Interfaz de Base de Datos, quien
internamente se comunica con el Manejador
de la Base de Datos del sistema BDdatos y así de esta manera almacenar
información. Este modelo inicial de análisis, también cuenta con una clase de
entidad (Base de Datos BDdatos) y
una clase de control denominada: Gestor
de Suministros, que es la clase que se encarga de realizar la gestión del
control de suministros y almacenar la información de forma organizada en la
base de datos del sistema, completando así la función substancial de este caso
de uso.
2. FASE DE ELABORACIÓN DEL SAC-WEB
En la Fase de
Elaboración del SAC-WEB, se especifican en detalle la mayoría de los casos de
usos del sistema y se diseña la arquitectura, es decir, el objetivo principal
de ésta fase es formular la línea base de la arquitectura, lo cual implica
desarrollar alrededor del cien por ciento de los casos de uso y abordar los
riesgos que interfieran en la consecución de este objetivo.
En ésta fase, se
aumentará el entorno de desarrollo, no sólo para llevar a cabo las actividades
de esta fase sino para guiar el trabajo durante la próxima fase, así como la
adición de mejoras y nuevas funcionalidades en posteriores generaciones del
sistema.
Para ésta Fase del SAC-WEB,
sólo fue necesaria una iteración en la cual se logró completar casi el total de
los requisitos, incrementando en esta fase un 15% que agregado al obtenido en
la Fase de Inicio lograron el 100% del flujo de trabajo de requisitos.
También, se
establecieron nuevos modelos de análisis, logrando agregar al 35% obtenido en
la Fase de Inicio, un 65% de análisis del sistema, para lograr un 100% del
análisis. Para el flujo de trabajo de diseño, se logró obtener el 100% de su
desarrollo. Sin embargo, los flujos de trabajo implementación y prueba no
obtuvieron ningún avance significativo. (Ver Figura 7.)
2.1.
Diseño de las Clases
Las clases de diseño
participantes en la realización de los casos de uso y las interacciones entre
sus respectivos objetos para tal fin, se identificaron en la sección anterior.
Sin embargo, no se definieron los atributos y operaciones de cada clase. La
mayoría de los atributos y operaciones se encuentran dentro de los diagramas y
artefactos obtenidos en los diferentes flujos de trabajo, por lo que es necesario
efectuar una revisión exhaustiva de estos y así reunir las responsabilidades de
las clases.
Luego de finalizar la
revisión exhaustiva y tener claras las relaciones existentes entre las clases
participantes en los casos de uso del sistema SAC-WEB, se identificaron los
atributos y operaciones de cada una de ellas, como se muestran en la Figura 8. y Figura 9.
2.2.
Diseño de la Base de Datos
En los diferentes
diagramas elaborados en los flujos de trabajo anteriores, se puede observar que
muchas de las tareas realizadas por los casos de uso requieren el acceso a la
base de datos (BDdatos) del sistema SAC-WEB. Esto indica que es necesario el
diseño e implementación de una base de datos. Para el diseño de la base de
datos del sistema SAC-WEB, se empleará el modelo entidad-relación, que consiste
en describir la información requerida mediante la definición de entidades y
asociaciones o interrelaciones entre ellas.
Una de las principales
ventajas del modelo entidad-relación es facilitar la comprensión de la
estructura lógica de la base de datos, pero la implementación de este modelo no se puede realizar
directamente.
Para lograr una buena
implementación se necesita la utilización de un modelo que se aproxime más a la
representación real de la base de datos, es por eso que se emplea el modelo
relacional. Los datos de este modelo se estructuran en forma de tablas o
relaciones manteniendo la independencia de esta estructura lógica con las
características físicas.
En los sistemas de
gestión de bases de datos comerciales, el modelo relacional es el más
utilizado, debido a que se fundamenta en una teoría muy extensa para lograr un
diseño y un procesamiento de información eficaz.
2.3.
Diseño de la Interfaz de Usuario
Para un desarrollador de
software la interfaz de usuario forma parte del proceso de diseño del sistema,
mientras que para los usuarios significa todo el sistema.
La experiencia de los
usuarios con la interfaz los lleva a formar la base de su juicio sobre las características
del sistema, porque en realidad poseen poca o ninguna apreciación por los
detalles internos y técnicos del software, ya que son invisibles para ellos. Si
la interfaz no permite la captura fácil de los datos o de la inicialización de
acciones, con sencillez y sin el riesgo de cometer errores serios, no se puede
esperar que los usuarios relacionados con la funcionalidad del sistema lo
juzguen aceptable.
Existen diferentes
esquemas para representar la navegabilidad del usuario con el sistema mediante
una interfaz; y el que cuenta con mayor auge en la actualidad es el de Interfaz
de Múltiples Documentos (MDI), por ser comúnmente observado en diferentes
aplicaciones. Éste esquema fue creado para el ambiente operativo gráfico de
Microsoft Windows. También se emplearán algunos esquemas relacionados al diseño
de páginas Web.
3. FASE DE CONSTRUCCIÓN DEL SAC-WEB
Para la Fase de
Construcción del SAC-WEB, se persigue como objetivo principal dejar lista una
versión operativa del sistema, el cual debe tener la calidad adecuada para su
aplicación y cumplir con los requisitos exigidos por el cliente.
Luego de concluidas,
tanto la Fase de Inicio como la Fase de Elaboración, los flujos de trabajos requisitos, análisis y diseño han
alcanzado el 100% de su desarrollo, y los riesgos críticos significativos han
sido reducidos y el sistema SAC-WEB,
ha quedado en una línea base de la arquitectura ejecutable.
En la Fase de
Construcción, la línea base de la arquitectura crece hasta convertirse en el
sistema completo. Al final de esta fase, el software contiene todos los casos
de uso que el desarrollador y el cliente han acordado para el desarrollo de
esta versión.
En ésta Fase del
SAC-WEB, sólo fue necesaria una iteración para lograr cumplir con el objetivo
principal de dicha fase, y así obtener un avance significativo en los flujos de
trabajo que no habían tenido progreso alguno en las fases anteriores. Para el
de implementación se obtuvo un 100%
logrando alcanzar su total desarrollo, mientras que el flujo de trabajo de prueba alcanzó un significativo avance
de un 97%. La Figura 10., muestra
los flujos de trabajos en la Fase de Construcción.
4. FASE DE TRANSICIÓN DEL SAC-WEB
Esta fase del sistema
SAC-WEB, comienza con la entrega de la versión operativa del software obtenida
en la fase anterior. En éste momento se considera que esa versión del sistema
está lista para funcionar en el entorno del usuario, aunque podrían presentarse
algunos inconvenientes no previstos anteriormente. El funcionamiento en el
entorno del usuario constituye una prueba más severa del sistema SAC-WEB, ya
que realiza las operaciones reales, bajo las circunstancias reales y con los
actores reales. No solamente podrían ponerse de manifiesto algunos defectos del
sistema, sino que el cliente puede descubrir con retraso la necesidad de nuevas
características. El desarrollador puede decidir agregar las nuevas
funcionalidades si estas son importantes y encajan en la arquitectura del
sistema o, si por el contrario, estas implican el regreso a fases tempranas del
desarrollo y al replanteamiento de la arquitectura, se pueden planificar para
una nueva versión del software.
Las actividades de la
Fase de Transición del sistema SAC-WEB, están dirigidas a preparar el entorno
de funcionamiento de dicho sistema, y a prestar colaboración a los usuarios
finales en su instalación y uso. Esta fase está dedicada mayormente a la
solución de los problemas que se hayan presentado en plena operación. Sin
embargo, esto no quiere decir que la actividad de ésta fase sea menor o de
menos importancia. Por el contrario, ésta fase está orientada a conseguir la
total satisfacción del cliente, que a fin de cuentas es el objetivo principal
de todo desarrollo.
Luego de concluidas, la Fase de Inicio, la
Fase de Elaboración y la Fase de Construcción, los flujos de trabajo requisitos, análisis, diseño e
implementación han alcanzado el 100%
de su desarrollo, mientras que el flujo de trabajo prueba alcanzó un 97%, y
además, los riesgos críticos significativos han sido mitigados en su totalidad.
En ésta fase del sistema
SAC-WEB, fue necesaria una iteración para lograr cumplir con las actividades de
dicha fase. Para el flujo de trabajo prueba
se obtuvo un 3% logrando alcanzar un total desarrollo del 100%. La Figura 11., muestra los flujos de
trabajo en la Fase de Transición.
4.1.
Manual de Usuario del sistema SAC-WEB
La finalidad del manual del usuario, es permitirle al usuario
las siguientes ventajas:
Facilitar el adiestramiento sobre las
operaciones básicas del SAC-WEB.
Interactuar fácilmente con el SAC-WEB.
Ayudar a corregir problemas que se puedan presentar al operar el
SAC-WEB.
CONCLUSIONES
El lenguaje UML proporciona una notación
universal, que entre muchos de sus beneficios, permite que el mantenimiento de
una aplicación se realice de manera eficaz. En la elaboración de los
diferentes modelos del sistema, UML brinda un gran mecanismo para el
entendimiento entre el cliente y el desarrollador, lo que da como resultado
realizar una captura de requisitos de una forma eficaz.
El Proceso Unificado de Desarrollo de Software tiene como
finalidad guiar a los desarrolladores en la implementación y distribución
eficiente de sistemas que se ajusten a las necesidades de los clientes. La
eficiencia se mide en términos de costo, calidad, y tiempo de desarrollo.
Dividir el proyecto en fases e iteraciones, facilita la
realización de los casos de uso, debido a que cada una de ellas se convierte en
un mini-proyecto, que agrega funcionalidades al sistema de manera incremental.
Permitiendo de esta manera localizar las fallas en una construcción
determinada, facilitando así su identificación y posterior corrección.
Los casos de uso, son de gran importancia para la captura de
requisitos del sistema en general, y para sistemas basados en componentes en
particular. Son la entrada fundamental cuando se identifican y especifican
clases, subsistemas e interfaces, y cuando se planifican las iteraciones del
desarrollo y la integración del sistema. En el sistema (SAC-WEB), los diagramas
de casos de uso rigieron todo el proceso de desarrollo, debido a que la mayoría
de los flujos de trabajo como el análisis, diseño y prueba se realizaron,
partiendo de estos diagramas.
En la Fase de Inicio del sistema (SAC-WEB), se lograron
objetivos tales como cumplir con los criterios de evaluación relacionados al
ámbito del sistema, y la identificación de los requisitos funcionales. Además,
se identificaron los riesgos críticos mediante un análisis exhaustivo de los
requerimientos iníciales del sistema. Dichos riesgos fueron mitigados en su
totalidad en las posteriores fases.
Para la Fase de Elaboración del (SAC-WEB), se deben especificar
en detalle los casos de uso fundamentales para el sistema, y así de esta manera
lograr el diseño de la línea base de la arquitectura. Finalmente se diseña la
interfaz de usuario, lo que para los usuarios significa todo el sistema,
mientras que el desarrollador de software lo considera como parte del proceso
de diseño.
Al concluir la Fase de Construcción del sistema (SAC-WEB), debe
quedar lista una versión operativa del sistema, la cual cumple con todos los
casos de uso que el desarrollador y el cliente acordaron para el desarrollo de
dicho sistema.
En la Fase de Transición del (SAC-WEB), las actividades se
centran en preparar el entorno de funcionamiento del sistema y a prestar
colaboración a los usuarios finales en la instalación y uso del sistema.
Al desarrollar el sistema (SAC-WEB) este contribuirá a mejorar
la participación del personal del almacén
principal en la operación física diaria, permitiéndole al usuario interactuar
con el sistema de una manera agradable, ya que el SAC-WEB va poseer una
interfaz gráfica amigable y sencilla.
BIBLIOGRAFÍA E INFOGRAFÍAS
1. Larman, C. (1999). “UML
y Patrones”, Editorial Prentice Hall, Primera Edición, México.
2.
http://es.wikipedia.org/wiki/Java_Server_Pages
3.
http://geneura.ugr.es/~jmerelo/JSP/
4. http://www.w3c.es/divulgacion/guiasbreves/tecnologiasXML
5.
http://www.programacion.net/html/xml/htmdsssl/capitulo1/capitulo1.htm#cap1s1
6. http://es.wikipedia.org/wiki/Active_Server_Pages
7. http://www.webestilo.com/php/php00.phtml