rea Informtica Sede Arica

INGENIERIA INFORMATICA Taller de Programacin 2

EVALUACION FINAL
El proyecto final de la asignatura DEBE: 1. Incluir acceso a un gestor de base de datos relacional tal como: SQL SERVER, ORACLE, MYSQL, POSTGRES, etc. 2. Utilizar para el ingreso de datos dispositivos tales como: lector de cdigo de barras, lector ptico, etc. 3. Utilizar tecnologas JAVA: JSP, HTML, SERVLET, etc. 4. Considerar mdulos para: Ingreso y registro de informacin Actualizacin de informacin Consulta y/o bsqueda de informacin Eliminacin de informacin Generar informes de gestin: grficos, estadstica, etc. 5. Calendario de evaluacin de avances Avance Informe de requerimientos del sistema*** Interfaz de usuario y mantenedores Informes de gestin Exposicin proyecto final Fecha Mircoles 26/Junio Mircoles 03/Julio Viernes 05/Julio Mircoles 10/Julio

***Contenidos del informe de requerimientos del sistema: 1. Introduccin En esta seccin se proporcionar una introduccin a todo el documento de Especificacin de Requisitos Software. Consta de varias subsecciones, las cuales son propsito, mbito del sistema, definiciones, etc. 1.1 Propsito Se definir el propsito del documento ERS y se especificar a quin va dirigido el documento. 1.2 mbito del Sistema En esta subseccin se pondr nombre al futuro sistema, se explicar lo que el sistema har y lo que no har, se describirn los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema y se mantendrn referencias a los documentos de nivel superior que puedan existir. 2. Descripcin General En esta seccin se describen todos aquellos factores que afectan al producto y a sus requisitos. En esta seccin no se describen los requisitos, sino su contexto. Los detalles de los requisitos de describen en la seccin 3, detallndolos y haciendo ms fcil su comprensin. Normalmente podemos encontrar las siguientes subsecciones: Perspectiva del producto, funciones del producto, caractersticas de los usuarios, restricciones, suposiciones y futuros requisitos. 2.1 Perspectiva del Producto Esta subseccin debe relacionar el futuro sistema con otros productos. As pues, podramos dividir sta en pequeas subsecciones indicando cada uno de los puntos a tener en cuenta: 2.1.1. Indicar si es un producto independiente o parte de un sistema mayor
Paola A. Cifuentes Berros Ingeniero en Computacin e Informtica Docente Universidad Tecnolgica de Chile paola.cifuentes02@docentes.inacap.cl INACAP - ARICA 1

rea Informtica Sede Arica

2.1.2. Interfaces de sistema 2.1.3. Interfaces de usuario 2.1.4. Modos de operacin de los distintos grupos de usuarios 2.2 Funciones del Producto Esta subseccin debe proporcionar un resumen de las funciones principales que el software debe llevar a cabo. Las funciones deben estar organizadas de manera que el cliente o cualquier otra persona lo entienda perfectamente. Para ello se deben utilizar mtodos textuales y grficos, siempre que dichos grficos reflejen las relaciones entre funciones y no el diseo del sistema. En una metodologa orientada a objetos, el funcionamiento y las relaciones del futuro sistema se modelaran a travs de los Casos de Uso. En ellos se representa lo que el usuario ve del sistema, as pues facilitar en gran medida su comprensin, siempre y cuando en los diagramas se eviten las ambigedades. 2.3 Caractersticas de los usuarios Se indica aqu el tipo de usuario al que se dirige la aplicacin, as como su experiencia tcnica, nivel de conocimientos, etc. 2.4 Restricciones Se debe indicar aqu cualquier tipo de limitacin como pueden ser polticas de la empresa, limitaciones hardware, seguridad, protocolos de comunicacin, interfaces con otras aplicaciones, estndares de la empresa en cuanto a interfaces, etc. Sern las limitaciones que se imponen sobre los desarrolladores del producto. 2.5 Suposiciones y Dependencias En este apartado aparecer cualquier factor, que si cambia puede afectar a los requerimientos. No son restricciones de diseo, por ejemplo, asumir que un determinado sistema operativo estar disponible, presuponer una cierta organizacin de las unidades de la empresa. Si cambian ciertos detalles puede ser necesario revisar los requisitos. 2.6 Requisitos Futuros Se indican aqu posibles mejoras del sistema en el futuro. Estas mejoras deben estudiarse y analizarse una vez concluido y puesto en marcha el sistema. Son modificaciones a realizar en un futuro incierto. 3. Requisitos Especficos Esta seccin de la especificacin de requisitos software contiene todos los requerimientos hasta un nivel de detalle suficiente para permitir a los diseadores disear un sistema que satisfaga dichos requisitos, y que permita disear las pruebas que ratifiquen que el sistema cumple con las necesidades requeridas. Los requisitos que se aqu se indiquen deben describir comportamientos externos del sistema, observables por el usuario as como por parte de los operadores y otros sistemas. Puesto que deben indicarse todos los requisitos, esta seccin es la ms larga de la ERS y debe cumplir los siguientes principios: correccin, no ambigedad, completitud, consistencia, clasificacin, verificabilidad, modificabilidad, explorabilidad y facilidad de mantenimiento. Asimismo, ste documento debe ser perfectamente legible por el cliente y por personas de muy distinta formacin. Otra de las cuestiones a tener en cuenta en esta seccin es la identificacin de cada uno de los requisitos mediante algn cdigo o sistema de numeracin. 3.1 Interfaces Externas En esta subseccin se definirn los requisitos que afecten a la interfaz de usuario e interfaz con otros sistemas (hardware y software), as como a interfaces de comunicaciones. 3.2 Funciones En este subseccin de deben especificar todas aquellas acciones o funciones que deber llevar a cabo el sistema a desarrollar. Las acciones que se indican como el sistema deber ... son las que deben incluirse en este apartado. La estructuracin de las funciones a desarrollar por el nuevo sistema no est del todo claro. Se debe tener en cuenta que en el estndar de IEEE 830 de 1983 se estableca que las funciones de deberan expresar como una jerarqua funcional, puesto que es la que mejor se adaptaba a los DFDs que propona el anlisis estructurado. Con la evolucin de la programacin y los
Paola A. Cifuentes Berros Ingeniero en Computacin e Informtica Docente Universidad Tecnolgica de Chile paola.cifuentes02@docentes.inacap.cl INACAP - ARICA 2

rea Informtica Sede Arica

nuevos mtodos de anlisis se puede observar como esta estructura no se adapta, por tanto es necesaria la modificacin de los estndares. El estndar IEEE 830, en sus ltimas versiones, permite la organizacin de esta subseccin de mltiples formas y simplemente sugiere alguna manera para hacerlo, dejando la oportunidad de utilizar cualquier otra justificando suficientemente la utilizacin de sta. Alguna de las formas sugeridas por el estndar son: Por tipo de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organizacin, se especifican los requisitos funcionales que le afecten o tengan mayor relacin con sus tareas. Por objetos: Los objetos son entidades del mundo real que son reflejadas en el sistema. Por tanto, para cada objeto se detallan sus atributos y sus funciones. Los objetos se pueden agrupar en clases. A pesar de realizar el anlisis con objetos no obliga a que el diseo del sistema siga el paradigma Orientado a Objetos, aunque lo facilita en gran medida. Por objetivos: un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Para cada objetivo o subobjetivo requerido al sistema, se detallarn las funciones que permitan llevarlo a cabo. Por jerarqua funcional: La funcionalidad del sistema se especifica como una jerarqua de funciones que comparten entradas, salidas o datos del propio sistema. Para cada funcin y subfuncin del sistema se detallar la entrada, el proceso en el que interviene y la salida. Normalmente este tipo de anlisis implica que el diseo siga el paradigma de diseo estructurado. Por lo general ste sistema se utiliza cuando ninguno de los anteriores se puede aplicar. 3.3 Restricciones de Diseo Se incluyen aqu todas las restricciones que afecten al diseo de la aplicacin, como pueden ser estndares internos de la organizacin, limitaciones hardware, etc.

Paola A. Cifuentes Berros Ingeniero en Computacin e Informtica Docente Universidad Tecnolgica de Chile paola.cifuentes02@docentes.inacap.cl INACAP - ARICA