Ingeniería de Software Trabajo práctico Nº 1

Transcripción

1 1. En potencial cliente lo llama y le solicita mediante el siguiente texto realizar un sistema de información: En nuestro centro de atención de Emergencias tenemos un operador que recibe la llamada de una emergencia médica, solicitando los datos de la misma. Necesitamos un sistema que cheque el estado del cliente, selecciona el móvil más próximo, considerando el estado del paciente, informe la demora y espere la confirmación del viaje. Registrando la asignación realizada. Si el cliente tiene suspendido el servicio o no es cliente, se informe al móvil para que se le facture el servicio. Por otra parte si todos los móviles están ocupados se deberá informar según los resultados de la zona que: E1: No hay móvil disponible. Si el lugar esta fuera del alcance de cobertura, emite mensaje: E2: Fuera del radio de cobertura. También necesitamos que el operador mediante el uso del sistema optimice la distribución de los móviles, distribuyendo en forma eficiente los móviles disponibles, indicándoles a cada móvil la base a la que se tienen que dirigir. 1. Realizar un documento de visión que sintetice desde la perspectiva de la aplicación y en sus palabras de que se trata el negocio y que aporta la solución al mismo 2. Enumerar los requisitos candidatos. Lista de características 3. Comprender el contexto del sistema mediante la realización del modelo de dominio o del negocio. 4. Capturar los requisitos funcionales mediante un modelo de Casos de Uso de negocio. 5. Capturar requisitos NO funcionales. 6. Desarrollar la arquitectura preliminar. Según el modelo propuesto en las 4+1 vistas. Página 1

2 1) Documento de visión SLAE Sistema de logistica para atención de emergencias Objetivo Se desarrollará un sistema para la atención de llamadas de emergencias, que permita el registro y administración de abonos de los clientes, facturación de los servicios y coordinación de los móviles respecto a las bases disponibles, para optimizar los tiempos de espera. Motivación El sistema se construirá para ser utilizado en centros de atención médica que atiendas llamadas de emergencia. La atención de llamadas de emergencia es una actividad en la que el tiempo de demora en la atención de un paciente puede ser crítico. La carencia de una buen sistema de información puede acarrear perdida de tiempo en cuestiones burocráticas y falta de optimización en el recorrido de las ambulancias, lo cual puede tener consecuencias no deseadas. Para ello desarrollaremos este sistema de información que permitirá responder de manera rápida y confiable ante una situación de emergencia. Desarrollo Visión General El sistema debe permitir: Chequear rápidamente ante una llamada de emergencia el estado administrativo del paciente. Si tiene suspendido el abono o no es abonado, dar aviso al móvil para facturar el servicio. Asignación del móvil más próximo, teniendo en cuenta el estado del paciente. Optimizar la distribución de los móviles respecto con las bases disponibles. Registrar la asignación realizada. (móvil asignado, demora estimada, etc.). En caso de no haber móviles disponibles, debe registrar el evento e informarlo. En caso de estar fuera del área de cobertura debe informarlo. Cualidades Página 2

3 El sistema debe ser: Colaborativo. Implementación multiusuario. Seguro. Robusta autenticación de usuarios. Protección contra ataques externos. Ágil, de rápida respuesta. Debe responder rápidamente a los requerimientos. Página 3

4 2) Lista de características Lista de características El sistema debe permitir: Chequear rápidamente ante una llamada de emergencia el estado administrativo del paciente. Si tiene suspendido el abono o no es abonado, dar aviso al móvil para facturar el servicio. Asignación del móvil más próximo, teniendo en cuenta el estado del paciente. Optimizar la distribución de los móviles respecto con las bases disponibles. Registrar la asignación realizada. (móvil asignado, demora estimada, etc.). En caso de no haber móviles disponibles, debe registrar el evento y poner en lista de espera la llamada de emergencia. En caso de estar fuera del área de cobertura debe informarlo. 3) Modelo de dominio Página 4

5 4) Requisitos funcionales Casos de Uso del negocio Registrar Asignación Se encargará de registrar los datos correspondientes a la atención de una emergencia, tales como situación administrativa del cliente, móvil asignado, si se pudo o no atender la emergencia, etc. Asignar móviles a bases Permitirá asignar las ambulancias a la base correspondiente. 5) Requisitos No funcionales SLAE - Requisitos NO funcionales Aclaración: Si me limito pura y exclusivamente al texto, no encuentro ningún requisito no funcional explicito. Así que supuse una lista de los mismos, que detallo a continuación. Requisitos globales El sistema debe ser de rápida respuesta, no se puede demorar en la atención de una emergencia. Se incluirán equipos GPS en todas las unidades para que el sistema pueda registrar la ubicación exacta de los móviles en todo momento. Se contratará una empresas idónea para la colocación de los equipos de GPS en las unidades y en el servidor central. bla bla bla Esto lo puse, pero me parece que más que requisitos NO funcionales entraría en el plan de infraestructura. Requisitos para desarrollo del sistema Se contratará un jefe de proyecto, un analista y dos programadores para llevar a cabo el desarrollo del sistema Se alquilará un local acondicionado correctamente para la tarea. Se comprará un servidor y dos PC comunes para la tarea de desarrollo. Este equipamiento servirá luego también para la implementación del sistema. Se requiere una conexión a Intenet de 1mb. mínimo. Se utilizará Fedora 10 como S.O. base. Se utilizará NetBeans como entorno de desarrollo bla bla bla. Página 5

6 6) Arquitectura preliminar Diagrama de Colaboración Vista Funcional Página 6

7 2. De acuerdo a un dominio conocido (por el alumno) elaborar una propuesta de aplicación en dicho negocio mediante la elaboración de un documento de visión del mismo. SPALM Sistema de gestión para negocios de venta minorista de hardware y servicio técnico en informática. Introducción Se ha observado en varios comercios del rubro informático la falta de un software que de soporte a las actividades del negocio de manera completa, ya que en muchos de los mismos se realizan las gestiones administrativas y comerciales con herramientas separadas, incluso muchas veces a mano. Se pretende entonces crear una aplicación web integradora de las actividades realizadas en los minoristas informáticos, potenciado con un sitio web para acceso por parte de los clientes. La información de una empresa actualmente es uno de los activos más valiosos con los que cuenta. El hecho de que el propietario, sus socios, clientes o proveedores puedan tener acceso a ella en el momento que la requieren, le ofrecerá una gran ventaja competitiva. Objetivo Desarrollar un sistema de gestión para comercios minoristas dentro del rubro Informática. Dichos comercios proveen servicio técnico de reparación y mantenimiento de PC's, y venta de hardware e insumos informáticos. El sistema debe dar soporte para las siguiente áreas: Gestión Administrativa: El Sistema deberá proveer soporte informático a todas las actividades realizadas en el comercio en cuanto a compras, ventas y servicios (facturación, control de stock, proveedores, clientes, etc.). Gestión del taller de servicio técnico: el Sistema permitirá administrar las órdenes de servicios y su seguimiento hasta que el mismo esté concluido. También controlará los repuestos utilizados en las reparaciones. Tanto los repuestos como el costo del servicio quedaran registrados para su postrior facturación. Gestión comercial: el Sistema permitirá administrar la gestión comercial del negocio, cómo márgenes de ganancias, comisiones a los vendedores, etc. También se busca mediante este sistema dar valor agregado al negocio, ampliando los horizontes comerciales del mismo, mediante la creación de un sitio web de acceso público. Este sitio permitirá a los clientes realizar un Página 7

8 seguimiento del estado de sus órdenes de servicio, y también permitirá captar nuevos clientes mediante la oferta de contratación de servicio o compra de productos a través de Internet. Motivación Esta idea surge debido a la necesidad de establecer un orden que garantice la velocidad de atención en cuanto a servicios, evitando demoras incómodas para satisfacer la necesidad de los clientes, pues la correcta planificación de las tareas no sólo redundará en beneficio para el cliente sino también para los empleados técnicos y el negocio en general. Asimismo, a la gestión de servicios se le integrará un gestor administrativo para llevar a cabo el resto de las actividades del negocio, como las compras, ventas y la administración comercial, todo esto sumado a una herramienta online que facilite a los clientes acceso a los servicios y productos de la empresa. Como resultado se obtendrá una herramienta integrada muy útil y ágil. Desarrollo Visión General El sistema se divide principalmente en 3 grandes áreas: Administración de Compras y Ventas Venta de productos de hardware al público minorista. Facturación. Administración de clientes. Cuentas corrientes clientes. Compra de productos de hardware a proveedores mayoristas. Administración de proveedores. Cuentas corrientes con proveedores. Administración de los artículos. Stock. Debe contemplar la utilización de repuestos en el taller de servicio técnico. Maestro de productos. Administración del taller (Servicios) Atención de solicitudes de servició técnico. Creación y seguimiento detallados de las órdenes de servicio. Brindar al cliente la posibilidad de consultar el estado de su servicio a través de Internet. Administración de técnicos. Administración contable y comercial Llevar la contabilidad del negocio. Página 8

9 El sistema debe contemplar todos los aspectos contables establecidos por el organismo que corresponda, tales como impuestos, alícuotas, percepciones, etc. Generación de informes contables automáticos. Administración de Sueldos y jornales. Administración de vendedores, sujetos a comisión. Administración de costos y márgenes de ganancias. Listas de precios. Debe contemplar diferentes listas según el tipo de cliente. Adicionalmente, se contempla la creación de una página web de acceso público vinculada a la aplicación, que permita inicialmente las siguientes actividades: Consultar los productos disponibles para la venta (catálogo electrónico de productos). Realizar compras electrónicas mediante un carrito de compras, ofreciendo diferentes formas de pago. Solicitar servicios a domicilio a través del sitio. Consulta del estado de los servicios en proceso a través de la página Registrar a los clientes que realizan una compra en el mismo maestro de clientes de la aplicación. Cualidades El sistema debe ser: Colaborativo. Implementación multiusuario. Seguro. Robusta autenticación de usuarios. Protección contra ataques externos. Accesible. Linea de venta y consultas online. Estándar y ágil. Debe simplificar las tareas rutinarias del negocio. Monitoreado. Los responsables del comercio son los únicos que accederán a toda la información para el control y gestión del negocio. Métricas. Basadas en las ventas, órdenes de pedidos y estadísticas en general. Página 9

10 Gráfico del sistema Página 10

11 3. Entre todos deberán seleccionar el proyecto candidato a realizar (en el resto de la cursada) entre todos los presentados en el punto 2. Proyecto seleccionado: SPALM (Punto 2) 4. Entre todos realizar los puntos 2, 3, 4, 5 y 6 para el proyecto seleccionado. Lista de Características El sistema debe permitir Administrar las siguientes áreas: Compras y Ventas Venta de productos de hardware al público minorista. Gestión de comprobantes. Gestión de clientes. Gestión de Cuentas corrientes para los clientes. Compra de productos de hardware a proveedores mayoristas. Gestión de proveedores. Gestión de Cuentas corrientes con proveedores. Recepción de pedidos Gestión de los artículos. Stock. Debe contemplar la utilización de repuestos en el taller de servicio técnico. Maestro de productos. Gestión de vendedores vinculados con las ventas Cuentas de vendedores por diferencia de listas. Taller de Servicio técnico Atención de solicitudes de servició técnico. Creación y seguimiento detallados de las órdenes de servicio. Brindar al cliente la posibilidad de consultar el estado de su servicio a través de Internet. Administración de técnicos. Comercial El sistema debe contemplar todos los aspectos impositivos establecidos por el organismo que corresponda. Generación de informes de facturación con fines contables. Gestión de costos y márgenes de ganancias. Listas de precios. Debe contemplar diferentes listas según el tipo de cliente. Gestión de concesión de productos a terceros. Sitio Web Página 11

12 Creación de una página web de acceso público vinculada a la aplicación, que permita inicialmente las siguientes actividades: Consultar los productos disponibles para la venta (catálogo electrónico de productos). Realizar compras electrónicas mediante un carrito de compras, ofreciendo diferentes formas de pago. Solicitar servicios a domicilio a través del sitio. Consulta del estado de los servicios en proceso a través de la página Registrar a los clientes que realizan una compra en el mismo maestro de clientes de la aplicación. Modelo de dominio Página 12

13 Requisitos funcionales Casos de Uso de Negocio Vender artículos Un cliente quiere comprar un producto, para lo cual es atendido por un vendedor. El vendedor se identifica en el sistema y registra la venta. Luego entrega al cliente el comprobante de venta. Si el cliente paga en el momento, el vendedor lo registra en el sistema y entrega el comprobante de pago; caso contrario se actualiza la cuenta corriente del cliente. Comprar Mercadería El responsable de compra realiza un pedido de mercadería a un proveedor. El responsable de la compra se identifica y registra el pedido en el sistema. En caso de haber depositado el importe de la compra previo al pedido, el responsable de compra registra el comprobante de depósito. Recibir Mercadería El responsable de compra recibe mercadería enviada por un proveedor. La persona responsable de la recepción de la mercadería se identifica en el sistema, controla la mercadería recibida contra el pedido realizado previamente. Luego le indica al sistema la cantidad de artículos ingresada. Registra el comprobante de compra en el sistema y verifica si el pago del pedido ya fue efectuado chequeando los comprobantes de depósito. Si la compra ya fue pagada, el responsable registra el comprobante de pago, caso contrario se actualiza la cuenta corriente con el proveedor. Recibir solicitud de servicio Un técnico recibe una solicitud de servicio de parte de un cliente. El técnico se identifica en el sistema, ingresa los datos del cliente y de/los equipos recibidos, generando una orden de servicio. El técnico le entrega al cliente un comprobante de servicio. Actualizar orden de servicio Un técnico trabaja sobre el equipo en reparación y registra las tareas en la orden de servicio. El técnico se identifica en el sistema y registra las tareas realizadas sobre la orden de servicio. En caso de usar repuestos, registra en el sistema cuales son y cuantos usa. Finalizar orden de servicio Un técnico finalizó la reparación de un equipo y factura el servicio realizado para su posterior cobro. Página 13

14 El técnico se identifica ante el sistema e indica la finalización del servicio en la orden correspondiente. Genera el comprobante de venta correspondiente al servicio realizado, incluyendo los repuestos utilizados. Recibir pago Un cliente quiere pagar un comprobante de venta emitido. El vendedor chequea en el sistema el comprobante, recibe el pago y lo registra. Entrega al cliente el comprobante de pago emitido por el sistema y se actualiza la cuenta corriente del cliente. Pagar mercadería comprada El responsable de compras quiere pagar un pedido de mercadería. El responsable de compras consulta los comprobantes de compras que quiere pagar, y luego de efectuado el pago registra el comprobante de pago correspondiente. Se actualiza la cuenta corriente con el proveedor. Pagar comisiones El dueño del negocio quiere pagar a un técnico o vendedor la comisión correspondiente por los servicios o ventas realizadas en un período determinado. En caso de un técnico, puede consultar las órdenes de servicios que finalizó en el período establecido. Si se trata de un vendedor, puede consultar las ventas que realizó en dicho período. Ya sea el técnico o el vendedor puede obtener la comisión correspondiente de acuerdo a las reglas de negocio establecidas. Emitir listados con fines impositivos El dueño del negocio requiere un listado de compras y ventas en un período determinado con fines impositivos. El dueño consulta en el sistema los comprobantes de compras y ventas registrados en el período. Luego emite el listado correspondiente. Consultar utilidad del negocio El dueño del negocio requiere un informe de utilidad del negocio en un período determinado. El dueño consulta las utilidades obtenidas en cierto período. Página 14

15 Modelo de casos de uso del negocio Página 15

16 Requisitos No funcionales Interfaz de usuario agradable y de fácil utilidad. Facilidad de soporte y mantenimiento. Compatible con sistema operativo xx.. Utilizable a través de redes. Base de datos en servidor. Frecuencia de backup. Buena estabilidad y soporte de hardware. No requiere grande recursos de hardware para su implementación. La respuesta vía web no debe ser mayor a los 10 segundos, a menos que se halla caído la conexión. Buen tiempo de respuesta en la facturación. Solo los usuarios autorizados pueden tener acceso a los datos. Equipo de trabajo para cada integrante. Conexión de red. Datos compartidos en servidor. UPS para los equipos. Página 16

17 Arquitectura preliminar Vista funcional Diagramas de colaboración Ventas Página 17

18 Compras Servicios Página 18

19 Supervisión Página 19

20 Vista física y de procesos Página 20

21 Vista de desarrollo Página 21

22 5. Cada uno deberá elaborar un plan de infraestructura para el proyecto. SPALM Plan de Infraestructura Objetivos Este documento tiene como finalidad describir la infraestructura requerida para el proceso de desarrollo e implementación del sistema para el Proyecto SPALM. Arquitectura El sistema se construirá con una arquitectura de tres capas, siendo estas: Capa de presentación. Encargada de la interacción con el usuario a través de una interfaz dinámica por medio de un navegador web. El usuario no accede directamente a los datos si no a través de las capas subsiguientes. Capa de negocio o lógica. En donde se ejecuta la lógica del sistema, dentro de un servidor de aplicaciones. Aquí se procesan las peticiones del usuario, se coordina la lógica de la aplicación y se procesan los datos. Capa de datos o back-end. Implementado por un servidor de base de datos transaccional, esta capa se encarga de la persistencia de datos y configuraciones y manejo transaccional. Ambientes Se entiende por ambiente un conjunto de herramientas, elementos, configuraciones e instalaciones mediante los cuales se llevará a cabo el desarrollo del sistema en las diferentes etapas del proyecto. Durante la ejecución del proyecto se hará uso de tres ambientes, Ambiente de Desarrollo En donde se llevará a cabo el proceso de implementación del sistema. Abarca: Desarrollo de casos de uso y diagramas complementarios. Diseño de base de datos. Programación del sistema. Ambiente de Pruebas o Testing Aquí se realizan las pruebas sobre el sistema. De ser exitosas y obtener la aprobación del cliente, se pasa el módulo testeado a producción. Página 22

23 Ambiente de Ejecución para Producción Donde se ejecutará el sistema para su uso final por parte del cliente. Esto comprende el sistema desarrollado, el software de aplicación (base de datos, servidor de aplicaciones) y el software de base necesario. Software Lista del software requerido para la consecución del proyecto, agrupado en categorías. Software de Desarrollo (SD) Código Tarea Software Versión SD1 IDE A definir - SD2 Plataforma A definir - SD3 J2EE IU A definir - SD4 ERD A definir - SD5 Framework A definir - SD6 Control de versiones - Subversion Librerias y Drivers Código Tarea Software Versión LB1 J2EE IU A definir - LB2 JDBC A definir - Software para Análisis y Diseño (S) Código Tarea Software Versió n S1 UML DIA S2 Documentación ZOHO Project Planner S3 Documentación OpenOffice.org Writer 3.0 Software de Implementación (SI) Código Tarea Software Versió n Página 23

24 SI1 DBMS A definir - SI2 AppServer A definir - SI3 HTTP Server A definir - Software de Base (SB) Código Tarea Software Versió n SO1 SO A definir 7.04 SO2 SO Server A definir 7.04 Software para administración del Proyecto (SA) Código Tarea SA1 Software Versió n Planificación A definir Software auxiliar (SAX) Código Tarea Software Versió n SAX1 Versionado de documentos Google Docs Beta SAX2 Artefactos de Google Docs documentación varios Beta SAX3 Artefactos de OpenOffice.org Writer documentación varios SAX4 Artefactos de DIA documentación varios Matriz de Responsabilidades Instalación Configuración Mantenimiento Soporte Técnico SD S Página 24

25 SI SB SA SAX : A definir Herramientas provistas por Terceros El proyecto hará uso de los siguientes servicios dados por terceros: Código Tarea Software, Herramienta o Servicio Comunicaciones ZOHO Project Planner Versió n - Formatos de los documentos Se utilizara como formato predeterminado para los documentos producidos el de Google Docs, OpenDocument y PDF. Por defecto, se utilizará Google docs, o se exportarán al formato que en su momento sea requerido en caso extraordinario. Para archivos de imagen se utilizarán los formatos PNG y JPEG. Hardware Se ofrece a continuación una descripción de las características y distribución del equipamiento informático necesario para la correcta ejecución del software requerido para el desarrollo del sistema y control del proyecto. Equipamiento óptimo Configuraciones recomendadas en base de la exigencia de los requerimientos del sistema, la arquitectura y el proceso. Estación de Trabajo para Desarrollo Servidor de pruebas: Procesador Intel o AMD de 2.5 Ghz o superior. 1 Gb de RAM. Disco Rigido 120 Gb. Unidad de lectoragrabadora de DVD. Placa de red Ethernet 10/100. Monitor color de 17 pulgadas. Servidor para Producción: Procesador Intel o AMD de 3 Ghz o superior. 2 Gb de RAM. Disco Rígido 120 Gb. Unidad de lectograbadora de DVD. Página 25

26 Sistema de resguardo a cinta. Placa de red Ethernet 10/100. Equipamiento disponible A definir Equipamiento Cliente A relevar Comunicaciones Todos los equipos utilizados en el ámbito de desarrollo deberan conectar con una conexión a Internet de 512K como mínimo. Mapeo Equipamiento Ambientes La siguiente tabla indica como se distribuye el equipamiento disponible en cada ambiente de desarrollo del proyecto. Desarrollo? Testing Producción X? X X? X X X Mapeo Equipamiento - Software La siguiente tabla indica como se distribuyen las instalaciones de software en el hardware disponible.??? SD LB S SI SB SA SAX Página 26

27 Instalaciones El proyecto será llevado a cabo en las instalaciones de la UNPSJB, utilizando los equipos en el Centro de Cómputos, y por cada miembro del equipo en su propio lugar de trabajo, utilizando los equipos descriptos anteriormente. Plan de Resguardos Backups en CD-ROM con periodicidad a determinar, que salvaguardaran los artefactos y entregables críticos del proyecto. Distribucir los documentos en los distintos equipos para evitar pérdidas. Documentos anexos y apéndices 6. Entre todos seleccionar el plan a utilizar No definido.- Página 27

28 Bibliografía utilizada El Proceso Unificado de Desarrollo de Software Ivar Jacobson, Grady Booch, James Rumbaugh Página 28