Proyecto de Ingeniería de Software I

UIGV – FISCT Ingeniería de Software I
Proyecto de Ingeniería de Software I
SISTEMA DE VENTAS Y RECEPCION DE CITAS

POR INTERNET “VETERINARIA SURCO”
FASES DE INICIO – ELABORACIÓN - CONSTRUCCIÓN - TRANSICIÓN
PROFESOR:
RIOS VIDAL, NADIA IRINA

<SECCIÓN>
0218979497, DÍAZ FLORES NATHALIE IRENE,

NATHALIE_DFLORES@HOTMAIL.COM
<721703620, LAZARO SOTELO CARLOS,
CARLOS091294@HOTMAIL.COM
---------------------------------------------------------------------
16/02/2015
Semestre: 2015-I Página 1

I. Ámbito ó Entorno
Identificación de los entregables en las fases y flujo del RUP:
Revisión Histórica
Fecha Versio Description Autor

n
16/02/2015 <1.0> Plan de Desarrollo de Nathalíe Díaz Flores
Software Carlos Lázaro Sotelo
TABLA DE CONTENIDOS
1 INTRODUCCIÓN ...................................................................... 3
1.1 Objetivo ..................................... Error! Bookmark not defined.

1.2 Alcance.................................................................................... 4
2 VISTA GENERAL DEL PROYECTOERROR! BOOKMARK NOT DEFINED.
2.1 Propósito, alcance y objetivos..... Error! Bookmark not defined.

2.2 Suposiciones, dependencias y restricciones ............................. 6
2.3 Entregables del proyecto ............ Error! Bookmark not defined.
2.4 Evolución del Plan de Desarrollo del SoftwareError! Bookmark not defined.
3 ORGANIZACIÓN DEL PROYECTOERROR! BOOKMARK NOT DEFINED.
3.1 Participantes en el proyecto ....... Error! Bookmark not defined.

3.2 Roles y Responsabilidades ......... Error! Bookmark not defined.
4 GESTIÓN DEL PROCESO ..... ERROR! BOOKMARK NOT DEFINED.
4.1 Estimaciones del proyecto.......... Error! Bookmark not defined.

4.2 Plan del proyecto ....................... Error! Bookmark not defined.
4.2.1 Plan de fases ......................... Error! Bookmark not defined.
4.2.2 Calendario del proyecto ......... Error! Bookmark not defined.
4.3 Seguimiento y Control del ProyectoError! Bookmark not defined.
4.4 Plan de Gestión de Riesgos ........ Error! Bookmark not defined.
1. INTRODUCCIÓN
Este Plan de Desarrollo del Software está preparado para ser implementado en
la Clínica Veterinaria Surco. Este documento provee una visión global del
enfoque de desarrollo propuesto.

El sistema será desarrollado en la metodología RUP (Rational Unified Process),

se detallara las fases de Inicio, Elaboración, Construcción y Transición para
tener una visión global de todo el proceso.
Este enfoque propuesto, constituye una configuración del proceso RUP,
teniendo en cuenta las características del proyecto, y las normas que aplica la
institución, seleccionando los roles de los participantes, las actividades a
realizar y los entregables que serán generados.
Objetivo
Implementar un sistema de ventas y reservaciones que permita mostrar todos
los productos de la empresa y poder hacer reservaciones de atención utilizando
la programación web.
Se implementará un sistema de ventas y reservaciones para la mejora en la
búsqueda y selección de productos, costos y/o precios como mayor orden en la
atención al cliente. Así se podrá tener un mayor control en la información y en
el stock de los respectivos productos.
Alcance
El Sistema de ventas mostrará una interfaz Web fácil de entender y utilizar,
con ayudas que facilitan la enseñanza y aprendizaje del usuario final,
soportando una cantidad concurrente de usuarios.
Este documento representa la descripción textual y gráfica de la arquitectura

del sistema, desglosando o descomponiendo solo aquellos componentes, sub-
sistemas y procesos abarcados por las funcionalidades descritas en los
términos de referencia de este proyecto, el cual es producto de un análisis de
los requisitos del sistema, según estos pueden ser satisfechos con las
tecnologías y características discutidas con los clientes y usuarios.
VISTA GENERAL DEL PROYECTO

Propósito, alcance y objetivos
Propósito

Veterinaria Surco lleva a cabo la atención en medicina especializada para

mascotas. La entrada en un mercado competitivo como en el que encuentra
inmersa esta firma conllevará una previsible adaptación a los nuevos sistemas
de información y a la evolución tecnológica. Por ello, la Veterinaria Surco
considera necesario el desarrollo de un nuevo sistema de ventas de los
productos que además ofrecen en su veterinaria y la reserva de atención que
servirán de mucha ayuda para un orden de atención al cliente, para que así
sus clientes puedan darle una mejor calidad de vida a sus mascotas, así como
contar con una base de datos que recojan datos de los clientes.
El propósito fundamental de este documento consiste en describir textual y
gráficamente la arquitectura del sistema, indicando:
- Estilo Arquitectónico y su propósito (objetivo).
- Componentes de la arquitectura.
- Vista de caso de usos.
- Vista lógica del sistema.
- Representación de los componentes arquitectónicos.
- Distribución de los componentes arquitectónicos a través de los
nodos de la plataforma de operación (Diagrama de Despliegue).
- Representación del modelo de datos a través del diagrama Entidad-
Relación.
Alcance
El proyecto busca minimizar tiempos de espera al momento de hacer la
consulta o compra de algún producto, ya que podrá realizarlo desde su casa y
podrá estar informado de las promociones de la veterinaria.
De esta forma tanto por parte del usuario podrá hacer sus compras y consultas
de productos mediante un sistema web, como por otra parte el usuario
administrador podrá estar relacionado con su empresa , esto quiere decir que
estará enterado de cómo va su negocio(productos disponibles y/o no
disponibles, tiempo de caducidad de los productos, vista de los productos más

vendidos, cuadros estadísticos y comparativos, generar ordenes de compras,

generar citas mediante la web, como reservaciones, etc.), todo esta
administración se realizara también mediante un sistema web con el privilegio
correspondiente.
Objetivo
El proyecto tiene como objetivo dar facilidad y rapidez al momento de consultar

y/o comprar los productos
 Tener en tiempo real los detalles de los productos y su precio.

 Tener la información actualizada sobre la disponibilidad y no
disponibilidad de productos, para hacer pedidos a sus respectivos
proveedores y/o atender a sus clientes.
 Reducir el tiempo en la elaboración y envío de sus productos, órdenes
de pedidos, elaboración de guías de remisión y/o facturas.
 Control de las ventas diarias realizadas.
 Se podrá ingresar, consultar y modificar los productos, así como
modificar precios o ingresar promociones.
 Tener mayor orden de atención al proporcionar reservaciones
2.2 Suposiciones, dependencias y restricciones

2.2.1 Suposiciones:
SU-01 El presupuesto a cargar estará calculado completamente de manera

expresado al mínimo nivel de detalle, de acuerdo a las dimensiones
requeridas por el sistema.
SU-02 Se tiene contactos con la dirección de la empresa para poder acceder a

su infraestructura como a la información de sus productos.

SU-03 Se cuenta con el programador para la realización de modificaciones.
SU-04 Se dispone de los recursos económicos necesarios para ejecutar el

proyecto.
SU-05 El ancho de banda soportará el tráfico generado y evitará la caída de la
red.
SU-06 Se dispone de un sistema de prueba para el cliente.
SU-07 El cronograma de actividades no sufrirá cambios durante el
transcurso del proyecto y el cliente respetará el cronograma convenido
sin peticiones que alteren el proceso.
SU-08 Los informes parciales y finales serán presentados, revisados y
aprobados por el cliente realizando su correspondiente corrección de
ser necesario.
SU-09 Los integrantes del Proyecto tienen los conocimientos necesarios para el
correcto desarrollo del mismo debido a que dominan las herramientas
de desarrollo y cuentan con entornos debidos para la pre-producción.
2.2.2 Dependencias:
DE-01 Los servidores deben de funcionar las 24 horas del día.
DE-02 Los cambios en el sistema deben coordinarse con la Dirección del

Proyecto.
DE-03 Se necesitará capacitar al personal para gestionar la atención vía web a

los usuarios.
DE-04 Los horarios de atención online serán establecidos por la empresa.
DE-05 La empresa necesitará contar con un apoyo informático y/o Área de
Soporte Técnico.

DE-06 Disponibilidad de tiempo de los integrantes del equipo de proyecto

para el desarrollo del mismo.
DE-07 Cumplimiento de cronogramas e hitos.
2.2.3 Restricciones:
Grado de libertad
Restricción Objetivos
Dimensión (rango permisible del
(estados límite) (estados objetivo)
estado)
Funcionalidad Problemas de Sistema 100% 80% de la funcionalidad
incompatibilidad de óptimo, sin caídas de principal debe de ser
software con los la base de datos, ni incluida en la versión 1.0
navegadores web. penetración de
intrusos al sistema.
Características Las características del Tener un sistema El 100% de las
sistema son definidas objetivo que características estarán
en conjunto con el complazca el uso de habilitadas para el
Patrocinador del la página web al administrador y con
proyecto luego de la usuario algunas restricciones para
presentación del el supervisor. El cliente no
último prototipo. tendrá restricción en la
página web.
Calidad Facilidad de uso. La aplicación debe El 97% de las pruebas de
Soporte de cualquier funcionar en Internet aceptación de los usuarios
navegador. Explorer,Firefox y deben pasar la versión 1.0
Soporte de Chrome, y en
dispositivos móviles. cualquier Smartphone
que tenga acceso a
navegador.
Costo El presupuesto Cubrir las Es posible excederse en el
autorizado para el perspectivas presupuesto hasta en un
proyecto es de S/. salariales de cada 10% sin revisión ejecutiva,
23,825 persona que está pero siempre que sean
dentro de este gastos de compra de
proyecto y como equipos o pago de
también la programadores.
adquisición de nuevos
softwares
Programación La aplicación debe Versión 1 Se dispone de tres meses
integrarse a los para desarrollar la
principales sistemas. aplicación hasta tenerla en
óptimo funcionamiento.
Personal Tamaño máximo del Mantener el orden y Es posible añadir un
equipo es un analista la agilidad del proceso analista en caso existan
y un programador en la creación del puntos pendientes por
sistema definir.

Entregables del Proyecto:
Los artefactos que serán generados y utilizados por el proyecto y que

constituyen los entregables están de acuerdo a los términos de referencia,
teniendo en cuenta que estos entregables sean alineados a la metodología RUP.
ACTIVIDAD Y/O PRODUCTO Periodo
Fase 1:
 Desarrollo de Plan de Trabajo y cronograma
de actividades, detallado con los
entregables, para la validación
correspondiente. A 30 días a partir de la
 Levantamiento de información y análisis del aprobación.
sistema a desarrollarse.
 Modelamiento y diseño de base de datos.
 Diseño del sistema y presentación de
prototipo.
Fase 2:
A 50 días a partir de la
 Elaboración del código, pruebas
aprobación.
individuales e integradas.
Fase 3:
 Implementación del Sistema
 Elaborar Documentación: Manuales de A 40 días a partir de la
Sistema y de Usuario. aprobación.
 Capacitación para los usuarios técnicos y
usuarios finales.
Evolución del Plan de Desarrollo del Software
El proyecto se inició el 5 de Enero y terminara el 05 de Mayo de 2014, y está

dividido en tres fases, al final de cada mes termina una fase en la cual se
entregara los documentos para su respectiva revisión y conformidad.

ORGANIZACION DEL PROYECTO
Participantes en el Proyecto
JEFE DE PROYECTO
ANALISTA
PROGRAMADOR
Roles y Responsabilidades
Rol Asumido por Descripción y Origen

 Levantamiento de
información
 Realizar el análisis y
diseño de la
Solución, y
asegurarse que el
desarrollo del
sistema se realice
ajustándose a los
Analista Nathalíe Díaz Flores planteamientos
indicados.
 Generar los inputs
necesarios para que
el Jefe de Proyecto de
Sistema tenga las
herramientas
necesarias para
cumplir sus tareas
 Encargado de la
solución de
Programador Carlos Lázaro Sotelo Algoritmos y
desarrollo de
estructuras de

control para el
desarrollo del
sistema.
 Empleo del lenguaje
de programación
para desarrollo de
aplicación.
 Desarrollo de la
Aplicación.
 Diseño lógico y físico
de las bases de datos
 Verificar o ayudar a
la verificación en la
integridad de datos
 Definir e
implementar
controles de acceso a
los datos.
GESTION DEL PROCESO
DIRECTOR
ADMINISTRACION
ADMINISTRACION
GENERAL
GENERAL
CALIDA ADMINISTRACI RRHH VENTA COMPR

D ON S AS
CALIDA ADMINISTRACI RRHH VENTA COMPR
D ON S AS
PERSONAL
MEDICO
PERSONAL
TECNICO
Semestre: 2015-I PERSONAL Página 11

MANTENIMIENT
O
4.1 Estimaciones del proyecto
RECURSO INVOLUCRADO PORCENTAJE

Jefe de Proyecto 100%
Analista 100%
Programador 100%
4.2 Plan del Proyecto

4.2.1 Plan de Fases
FASE Nº DE ITERACIONES DURACIÓN

Fase de Inicio Iteración I1 1 mes
Fase de Elaboración Iteración E1 1 mes
Fase de Construcción Iteración C1 1 mes
Fase de Transición Iteración T1 1 mes
DESCRIPCIÓN HITO
Ámbito ó Entorno
 Plan de Desarrollo Software
Administración del Proyecto
 Cronograma del proyecto
Modelo de Negocio:
 Diagrama general de casos de uso de negocio
 Diagrama de actividades, descripción dinámica de los
Fase de Inicio
casos de uso de negocio
Crear la Matriz de proceso y requerimiento
 Matriz de trazabilidad
Requerimientos:
 Diagrama general de casos de uso
 Plantilla de especificación de casos de uso
Modelo de Análisis
 Diagrama de paquetes indicando las capas respectivas
Fase de Elaboración  Diagrama de colaboración
Modelo de datos
 Diagrama de clases

 Diagrama del modelo físico

 Script
 Data
 Diccionario de datos
Diseño de clase a nivel de implementación
 Capas
o Presentación o aplicación(Jsp)
o Negocio (Bean, interfaz, servlet, etc.)
 Diagrama de secuencia
Implementación
 Diagrama de componentes
 Diagrama de despliegue
 Programación:
o Archivos. Dat (archivo)
Fase de Construcción o Librerías requeridas
Pruebas
 Pruebas unitarias
 Pruebas funcionales
 Pruebas de esfuerzo
Despliegue
Fase de Transición Entrega y puesta en producción del Sistema de Biblioteca
- SBD
4.2.2 Calendario del Proyecto

Inicio 5 Enero- 4 Febrero
Elaboración 5 Febrero – 4 Marzo
Construcción 5 Marzo – 4 Abril
Transición 5 Abril – 5 Mayo
4.3 Seguimiento y Control del Proyecto

La gestión de los requisitos, se lograra a partir del levantamiento de la
información a través de las entrevistas a usuarios.
En todo cambio de los requerimientos, se tendrá que evaluar el impacto del
cambio y que este en el alcance del proyecto, a través de una solicitud.
4.4 Plan de Gestión de Riesgos
Riesgo Probabilidad Impacto Mitigación

Uso reducido de la 1% Leve Se requiere de marketing que fomente y
aplicación explique a los usuarios los beneficios de
poder realizar sus compras vía web.

Riesgo Probabilidad Impacto Mitigación

Desperfecto del 1% Leve Realizar copias de seguridad del sistema y
hardware verificar que los equipos estén en
perfectas condiciones antes de empezar a
trabajar en ellos.
No hay interactividad 1% Leve El trabajo se puede realizar de manera
en el grupo de desordenada por falta de participación
desarrollo y/o comunicación.
Incumplimiento de las 1% Leve El personal se comprometerá a cumplir con
tareas asignadas por todas sus obligaciones asignadas.
parte de algún integrante
del grupo
El usuario hace mal 1% Leve Realizar un manual de usuario detallando
uso del sistema todos los pasos minuciosamente para
facilitarle el uso del software.
Hay un corte en el 0.5% Leve Guardar constantemente los cambios que

sistema eléctrico se realiza en el sistema.
Errores significativos en 0.5% Leve Los encargados del proyecto deben trabajar
la definición de alguno de correctamente y con la concentración
los puntos clave del necesaria para evitar errores en los puntos
proyecto clave del proyecto, ya que ocasiona un retraso
en su culminación.
Caída de servidor de la 0.5% Leve El personal deberá estar debidamente
aplicación o alguna de capacitado para poder dar solución a estos
sus partes debido a inconvenientes.
agentes externos (,
Internet, ataques
informáticos, etc.)
II. Administración del Proyecto

Cronograma del proyecto:
Considerar todas las actividades del proyecto por fases del RUP.
Entregables:
 Cronograma del proyecto
III. Modelo de Negocio:
3.1. Modelo de Casos de Uso de Negocio.

Relación entre los procesos y actores del negocio.

Entregables:
Diagrama general de casos de uso de negocio

3.2. Modelo de Análisis del Negocio

Aquí se realizan o detallan los procesos del negocio.
Descripción de los casos de uso de negocio

Desarrollar cada caso de uso de negocio al detalle.
CASO DE USO GESTIONAR ALMACEN:
CASO DE USO GESTIONAR COMPRAS

CASO DE USO GESTIONAR FACTURACION
CASO DE USO GESTIONAR SEGURIDAD

CASO DE USO GESTIONAR VENTAS
CASO DE USO GESTIONAR CITA

DIAGRAMA DE ACTIVIDADES COMPRA DE PRODUCTOS
IV. Crear la Matriz de proceso y requerimiento

En esta sección se identifican los casos de uso que soportan el
requerimiento identificado en la etapa anterior
MATRIZ DE REQUERIMIENTOS:
PROCESO
ACTIVIDAD DEL RESPONSABLE REQUERIMIENTO Y
DEL CASO DE USO ACTORES
NEGOCIO DEL NEGOCIO RESPONSABILIDAD
NEGOCIO
Gestionar Ventas
Buscar cliente
Registra la orden de Consultar orden de
Agregar, modificar y
compra. pedido
Proceso de Empleado de eliminar cliente.
Envía orden de compra Generar cotización Empleado de ventas
ventas ventas Agregar, modificar y
al empleado de almacén Registrar Orden de
eliminar orden de
Genera cotización Compra
compra
Gestionar cliente
Recibe orden de compra

Consulta de pedidos
Entrega de Envía productos Empleado de Registro de pedido Empleado de
Registro Pedido.
Pedidos solicitados al empleado Almacén Buscar productos Almacén
Gestionar despacho
de ventas

Generar Verificar orden de Empleado de Generar factura para el Emitir guía de Empleado de
comprantes compra Facturación cliente. remisión. Facturación
de pago Envía copia de factura al Generar guía de Emitir Factura
empleado de almacén remisión Emitir boleta de
Generar boleta de venta
ventas
Generar
Separar cita Empleado de Generar numero de cita Generar cita
Cita
Elegir día y horario Ventas Generar orden de cita
Empleado de Ventas
Emitir orden de cita
MATRIZ DE REQUERIMIENTOS ADICIONALES:

Paquete de Caso de
Requerimiento y Responsabilidad Caso de Uso Actores
Uso
Cliente Agregar, modificar y eliminar Gestionar cliente

Administrador del
Gestionar citas Sistema
Citas Agregar, modificar y eliminar
Empleado de
Pedido Agregar, modificar y eliminar Gestionar producto
ventas
Consultar ventas por cliente.
Buscar ventas por cliente.
Consultar producto más
Reportes Buscar producto más vendido. Cliente
vendido.
Buscar ventas del día
Consultar ventas del dia
Agregar, modificar y eliminar. Gestionar usuarios.
Asignar perfiles a usuarios. Asignar perfiles a usuarios.
Seguridad Agregar, modificar y eliminar. Gestionar accesos a perfiles Usuario
Buscar usuario Buscar usuario.
Ingresar/salir del sistema. Ingresar/salir del sistema

V. Requerimientos:
Integración de los casos de uso y actores
Desarrollar el modelo de casos de uso
Entregables:
 Diagrama general de casos de uso

Especificación de los casos de uso
1. ESPECIFICACIÓN DEL CASO DE USO GESTIONAR USUARIO:
2. Descripción breve:
Este caso de uso permite al administrador de sistema registrar un usuario al sistema por web.
El actor del caso de uso es el Administrador de Sistema.
3. Flujo Básico de eventos:

2.1. El caso de uso comienza cuando el Administrador de Sistema indica “Gestionar Usuario” del menú
principal del sistema.
2.2. El sistema muestra el formulario de Usuario.
2.3. El Administrador de Sistema ingresa los datos de Usuario.
2.4. El Administrador de Sistema indica “Guardar”.
2.5. El sistema valida los parámetros de ingreso.
2.6. El sistema genera un código de identificación y contraseña.
2.7. El sistema crea un nuevo usuario y le asigna el código de identificación generado y contraseña.
2.8. El caso de uso finaliza.
4. Flujos alternativos:
4.1. En el punto 2.3 si el administrador del sistema ingresa RUC de más o menos de 11 dígitos, mostrara
el mensaje de “Ingreso RUC incorrecto”.
4.2. En el punto 2.3 si el administrador del sistema ingresa un DNI de más o menos de 8 dígitos,
mostrara el mensaje de “Ingreso DNI incorrecto”.
4.3. En el punto 2.3 si el administrador del sistema ingresa un RUC o DNI ya registrado, el sistema
mostrara el mensaje de “Usuario ya Registrado”.
5. Sub Flujos:
5.1. Modificar Usuario:

5.1.1. El administrador de sistema buscara por DNI o por RUC al usuario a modificar.
5.1.2. Hará clic en “Modificar Usuario”
5.1.3. El sistema muestra todos los campos con sus datos del usuario a modificar.
5.1.4. El administrador de sistema modifica los campos y hará clic en “Modificar”.
5.1.5. El sistema muestra “Usuario modificado exitosamente”
5.2. Eliminar Usuario:

5.2.1. El administrador de sistema buscara por DNI o por RUC al usuario a eliminar.
5.2.2. Hará clic en “Eliminar Usuario”
5.2.3. El sistema mostrara un mensaje de confirmación al administrador de sistemas.
5.2.4. El administrador de sistemas acepta o rechaza.
5.2.5. El sistema muestra “Usuario eliminado satisfactoriamente”
6. Requerimientos especiales:
No hay requerimientos.
7. Precondición:
El usuario ha sido admitido con el rol de administrador de sistemas.
8. Post condición:
Se ha registrado Usuario.
9. Puntos de extensión:

Ninguno.
10. Información adicional:

Ninguno.
11. Prototipo
2. ESPECIFICACIÓN DE CASO DE USO GESTIONAR PRODUCTOS
1. Breve Descripción
El siguiente caso de uso permitirá al Administrador de Sistemas registrar, modificar y eliminar los
productos.
2. Flujo Básico de Eventos

2.1. El caso de uso se inicia cuando el administrador de sistemas ingresa a la opción “Gestionar
Productos” en la interfaz del menú principal.
2.2. El sistema muestra la interfaz “Gestionar Productos”; con las siguientes opciones: Registrar
productos, buscar productos, eliminar productos, guardar cambios y salir.
2.3. El administrador del sistema ingresa En la opción Registrar Producto
2.4. El administrador del sistema ingresa código, descripción, marca, precio, Stock
2.5. El sistema valida el registro del producto.
2.6. El administrador elige la opción guardar cambios.
2.7. Al administrador del sistema hace click en salir.
3. Subflujos
Modificar Producto
Se busca el producto requerido.
El sistema permitirá modificar los datos del producto.
El administrador guardará los cambios y actualizará la información.
Eliminar Producto
Al hacer click en buscar se muestra el producto a eliminar.
El administrador hace click en eliminar y actualiza la información del producto.
4. Flujos Alternativos
4.1. En el punto 2.4 del flujo básico, si el administrador del sistema no ingresa unos de los campos ya
sea código, descripción, marca, precio, stock el sistema mostrara el siguiente mensaje “uno de los
campos está vacío”
4.2. En el punto 2.4 del flujo básico, si el administrador del sistema no ingresa correctamente el código
de producto sistema mostrara el siguiente mensaje “ código de producto incorrecto “
5. Precondiciones
Administrador debe estar logueado al sistema
6. Post condiciones
Se ha registrado producto
7. Puntos de Extensión
Ninguno
8. Requerimientos Especiales
Ninguno.

9. Prototipos
3. ESPECIFICACIÓN DEL CASO DE USO: REALIZAR PEDIDO
Este caso de uso permite al cliente realizar un pedido, para que finalmente pueda obtener el envío del
producto solicitado.
El actor del caso de uso es el Cliente del Sistema.

2.1. El caso de uso comienza cuando el Cliente del Sistema elige un producto del menú principal del
sistema.
2.2. El sistema muestra la descripción del producto, marca, precio y si se encuentra disponible
2.3. El cliente dará clic en “Realizar Compra”.
2.4. El sistema solicitará si se desea boleta o factura
2.5. El cliente elegirá si desea boleta o factura
2.6. El sistema solicitará la confirmación de la compra
2.7. El sistema genera un número de orden de pedido y mostrara en la interfaz.
En el punto 2.2 el cliente digitara el producto a buscar, en caso no haya stock del producto el sistema
mostrara “Producto no disponible por el momento”.
En el punto 2.6 si el cliente no confirma la compra el caso de uso finaliza.
4. Sub Flujos:
a. Modificar Orden de pedido:
El Cliente buscara una orden de pedido por el número que le genero el sistema al momento de
registrar la orden.
Hará clic en “Modificar Orden”
El sistema muestra todos productos que ingreso a la orden de pedido.
El Cliente modifica la orden y hará clic en “Modificar”.
El sistema muestra “Orden de pedido modificado exitosamente”
6. Precondición:
El usuario ha sido admitido con el rol de cliente.
7. Post condición:
Orden de Pedido.
Ninguno.

4. ESPECIFICACIÓN DEL CASO DE USO: RESERVAR CITA
Este caso de uso permite al cliente reservar una cita, para que finalmente su mascota pueda ser
atendida.
El actor del caso de uso es el Cliente del Sistema.

2.1. El caso de uso comienza cuando el Cliente del Sistema “reservar cita” del menú principal del
sistema.
2.2. El sistema muestra las fechas y horarios de atención.
2.3. El cliente elegirá la fecha y horario.
2.4. El sistema solicitará la confirmación de la cita.
2.5. El cliente confirmará la cita
2.6. El cliente hará click en “generar número de cita”
2.7. El sistema genera un número de cita y mostrará en la interfaz el número de cita junto con la fecha y
horario elegido.
En el punto 2.2 el sistema puede mostrar “no hay fechas disponibles para citas”
En el punto 2.5 si el cliente no confirma la cita el caso de uso finaliza.
4. Sub Flujos:
b. Modificar Cita:
El Cliente hará clic en “Modificar Cita”
El sistema pedirá ingresar el número de cita.
El sistema mostrará la cita.
El Cliente modifica la cita y hará clic en “Modificar”.
El sistema muestra “Cita modificada exitosamente”
6. Precondición:
El usuario ha sido admitido con el rol de cliente.
7. Post condición:
Orden de Pedido.
Ninguno.

VI. Modelo de Análisis

Análisis de la Arquitectura
En este flujo de trabajo se organizan los casos de uso en paquetes, se
agrupan los casos de uso que ayuden a cumplir una misma meta. Se
agrupan los paquetes en dos capas:
Capa especifica, es la que tendrá los paquetes principales
Capa general, los paquetes que son reutilizables y de soporte.
Entregables:
 Diagrama de paquetes indicando las capas respectivas
Realización de los casos de uso

Se desarrolla y detalla cada caso de uso de acuerdo a la especificación
elaborada en el flujo anterior, representando los flujos básicos, sub
flujos y alternos.
Entregables:
 Diagrama de colaboración
VII. Modelo de Diseño
Base de Datos
Elaboración del Modelo Lógico
Se identifican todas las clases que conformaran una clase persistente en
el Modelo Físico, a través de un diagrama de clases; indicando las
relaciones entre las mismas, la multiplicidad, atributos (considera los
campos que tendrá cada tabla en el modelo físico).
Entregables:

Elaboración del modelo físico

Se refiere a la elaboración del modelo físico a partir del modelo lógico,
conteniendo las tablas que fueron consideradas como clases en el
modelo lógico.
Entregable:
 Diagrama del modelo físico
 Script
 Data
Elaboración del Diccionario de datos
Este contendrá la definición de cada clase persistente (tabla) que se
encuentre en el modelo físico.
Entregable:
 Diccionario de datos
Diseño de clase a nivel de implementación

Capas de Diseño
Elaboración de las capas del diseño, agrupando los subsistemas y la
GUI.
Identificación y definición de las capas de negocio y presentación.
Entregable:
 Capas
o Presentación o aplicación(Jsp)
o Negocio (Bean, interfaz, servlet, etc.)
Realización de los casos de uso de diseño

Elaboración del detalle de cada caso de uso a nivel de diseño.
Entregables:
 Diagrama de secuencia
VIII. Implementación
Modelo de implementación y despliegue
Entregables:
 Diagrama de componentes
 Diagrama de despliegue
Programación:
Entregables:
 Archivos. Dat (archivo)
 Librerías requeridas (archivo)
 Esquema de la base de datos (archivo)
 Checklist del Código Java

IX. Pruebas
Describimos los artefactos del flujo de pruebas.
Entregables:
 Pruebas unitarias
 Pruebas funcionales
 Pruebas de esfuerzo
X. Documentos finales:
 Conclusiones
 Recomendaciones
 Anexos
 Fuentes de consulta
XI. Anexos:
 Actas de reuniones
1.1. Análisis del Negocio
Especificación del Caso de Uso del Negocio
Descripción
En el siguiente caso de uso de negocio se describe el proceso ventas de los productos desde el
momento que el cliente ingresa a la página web.
Objetivo:
Reducir el tiempo en el proceso de ventas.
Flujo de Trabajo:
El cliente ingresa a la página web
El cliente elige el producto
El sistema verifica si el producto está disponible
El cliente agrega el producto al carrito de compras.
El empleado de ventas recibe y registra la orden de compra.
El empleado de ventas elabora la boleta o factura.
El empleado de ventas entrega el producto y factura al cliente.
El cliente realiza el pago.
El cliente recibe el producto solicitado.

Proyecto de Ingeniería de Software I

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proyecto de Ingeniería de Software I

Uploaded by

Copyright:

Available Formats

UIGV – FISCT Ingeniería de Software I

Proyecto de Ingeniería de Software I

SISTEMA DE VENTAS Y RECEPCION DE CITAS

FASES DE INICIO – ELABORACIÓN - CONSTRUCCIÓN - TRANSICIÓN

RIOS VIDAL, NADIA IRINA

0218979497, DÍAZ FLORES NATHALIE IRENE,

Semestre: 2015-I Página 1

Fecha Versio Description Autor

1.1 Objetivo ..................................... Error! Bookmark not defined.

2 VISTA GENERAL DEL PROYECTOERROR! BOOKMARK NOT DEFINED.

2.1 Propósito, alcance y objetivos..... Error! Bookmark not defined.

3 ORGANIZACIÓN DEL PROYECTOERROR! BOOKMARK NOT DEFINED.

3.1 Participantes en el proyecto ....... Error! Bookmark not defined.

4 GESTIÓN DEL PROCESO ..... ERROR! BOOKMARK NOT DEFINED.

4.1 Estimaciones del proyecto.......... Error! Bookmark not defined.

Semestre: 2015-I Página 3

El sistema será desarrollado en la metodología RUP (Rational Unified Process),

Este documento representa la descripción textual y gráfica de la arquitectura

VISTA GENERAL DEL PROYECTO

Semestre: 2015-I Página 4

Veterinaria Surco lleva a cabo la atención en medicina especializada para

Semestre: 2015-I Página 5

vendidos, cuadros estadísticos y comparativos, generar ordenes de compras,

El proyecto tiene como objetivo dar facilidad y rapidez al momento de consultar

 Tener en tiempo real los detalles de los productos y su precio.

2.2 Suposiciones, dependencias y restricciones

SU-01 El presupuesto a cargar estará calculado completamente de manera

SU-02 Se tiene contactos con la dirección de la empresa para poder acceder a

Semestre: 2015-I Página 6

SU-03 Se cuenta con el programador para la realización de modificaciones.

SU-04 Se dispone de los recursos económicos necesarios para ejecutar el

DE-01 Los servidores deben de funcionar las 24 horas del día.

DE-02 Los cambios en el sistema deben coordinarse con la Dirección del

DE-03 Se necesitará capacitar al personal para gestionar la atención vía web a

Semestre: 2015-I Página 7

DE-06 Disponibilidad de tiempo de los integrantes del equipo de proyecto

Semestre: 2015-I Página 8

Entregables del Proyecto:

Los artefactos que serán generados y utilizados por el proyecto y que

Evolución del Plan de Desarrollo del Software

El proyecto se inició el 5 de Enero y terminara el 05 de Mayo de 2014, y está

Semestre: 2015-I Página 9

ORGANIZACION DEL PROYECTO

Rol Asumido por Descripción y Origen

Semestre: 2015-I Página 10

GESTION DEL PROCESO

CALIDA ADMINISTRACI RRHH VENTA COMPR

Semestre: 2015-I PERSONAL Página 11

4.1 Estimaciones del proyecto

RECURSO INVOLUCRADO PORCENTAJE

4.2 Plan del Proyecto

FASE Nº DE ITERACIONES DURACIÓN

Semestre: 2015-I Página 12

 Diagrama del modelo físico

4.2.2 Calendario del Proyecto

4.3 Seguimiento y Control del Proyecto

4.4 Plan de Gestión de Riesgos

Riesgo Probabilidad Impacto Mitigación

Semestre: 2015-I Página 13

Riesgo Probabilidad Impacto Mitigación

Hay un corte en el 0.5% Leve Guardar constantemente los cambios que

II. Administración del Proyecto

III. Modelo de Negocio:

3.1. Modelo de Casos de Uso de Negocio.