PLAN DE DESARROLLO

DE SOFTWARE

 INTEGRANTES:

1. MANAYAY CHAMAYA, Victor Augusto

2. HEREDIA RAMIREZ, miguel
3. SUCLUPE SANTISTEBAN, Ronald Andrés
4. CHINCHAY DIAZ, José

 DOCENTE:
DAVILA, Luis
 CURSO:
Ingeniería de software

 CICLO:
V ciclo – Ingeniería de Sistemas

Lambayeque, junio del 2019

 Sistema de Mesa de Ayuda
Plan de Desarrollo Software

Versión 1.0
 Plan de Desarrollo de Software

1. Introducción
Este Plan de Desarrollo del Software es una adopción de las tecnologías de la información en los
procesos diarios de las organizaciones, para continuar con las tareas diarias sin interferir en los
tiempos de entrega de los resultados por cualquier contingencia que surja, ya sea de orden humano;
falta de experiencia o capacitación del personal, o tecnológico, fallas en los equipos, etc.
El proyecto ha sido elaborado por estudiantes de la escuela de INGENIERIA DE SISTEMAS,
basado en un modelo “MVC” es un estilo de arquitectura de software que separa los datos de una
aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.
 El Modelo que contiene una representación de los datos que maneja el sistema, su
lógica de negocio, y sus mecanismos de persistencia.
 La Vista, o interfaz de usuario, que compone la información que se envía al cliente y
los mecanismos interacción con éste.
 El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando
el flujo de información entre ellos y las transformaciones para adaptar los datos a las
necesidades de cada uno.
Los objetivos medulares de toda empresa u organización que brinde servicios son: satisfacer al
100% las expectativas de los usuarios y dar el mismo con la mejor calidad y eficiencia posible.
En la actualidad los problemas más severos a nivel mundial en cuanto a este tópico se basan en
la poca planificación de las empresas en cuanto a recursos y tiempo, la incapacidad de
aprovechar al máximo las habilidades personales y la carencia de un ente especializado en
organizar y guiar el trabajo a realizar, además de la insuficiente utilización de buenas prácticas
que faciliten el trabajo en equipo. Todo lo antes expuesto trae como consecuencia resultados
ineficientes e incumplimiento de los objetivos perseguidos, produciendo finalmente la
insatisfacción del cliente. Debido a que no existen métodos o guías para el aseguramiento de la
calidad en el servicio brindado a los usuarios de la empresa por las MESAS DE AYUDA es que
se ha decidido llevar a cabo la presente investigación que se propone elaborar una metodología
que permita capacitar y servir de consulta obligatoria a los que realicen esta labor en nuestra
Dirección Territorial y en cualquiera de las demás Direcciones del país, todo esto con la
finalidad de dotar a las Mesas de Ayuda de un conjunto de soluciones a problemas que pueden
enfrentar en el soporte a diario.

1.1 Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para
controlar el proyecto. En él se describe el enfoque de desarrollo del software.
Los usuarios del Plan de Desarrollo del Software son:
 El jefe del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y para
realizar su seguimiento.
 Los miembros del equipo de desarrollo lo usan para entender lo qué deben hacer, cuándo
deben hacerlo y qué otras actividades dependen de ello.
1.2 Alcance
El Plan de Desarrollo del Software describe el plan global usado para el desarrollo de una “MESA
DE AYUDA”. El proyecto consiste en la implementación de la MESA DE AYUDA, que está
diseñado para empresas que ofrecen productos electrodomésticos .Esta implementación se llevará
a cabo en un plazo determinado, de los cuales la mesa de ayuda quedará operativa y será entregada
para la operación. El alcance general del proyecto, en su etapa de Implementación incluye las
actividades de puesta a punto de toda la infraestructura necesaria para la entrada en operación de
la Mesa de Ayuda, las pruebas operativas, de capacidad y disponibilidad, así como la transición
del servicio.
1.3 Resumen
Después de esta introducción, el resto del documento está organizado en las siguientes secciones:
Vista General del Proyecto — proporciona una descripción del propósito, alcance y objetivos del
proyecto, estableciendo los artefactos que serán producidos y utilizados durante el proyecto..
Organización del Proyecto — describe la estructura organizacional del equipo de desarrollo.
Gestión del Proceso — explica los costos y planificación estimada, define las fases e hitos del
proyecto y describe cómo se realizará su seguimiento.
Planes y Guías de aplicación — proporciona una vista global del proceso de desarrollo de
software, incluyendo métodos, herramientas y técnicas que serán utilizadas.

2. Vista general del proyecto.

2.1 Propósito alcance y objetivos.
Luego de realizar un estudio y ver el contexto para la práctica del proyecto, tenemos la información
suficiente para el comienzo del desarrollo de software.
La empresa en mención se dedica a la venta de productos electrónicos a nivel nacional. Teniendo frente
a ellos a un mercado muy competitivo, la empresa considera necesario la implementación de un sistema
de atención al cliente, debido a que los clientes mismos demandan una atención más rápida, eficiente y
segura.
El proyecto a realizar debe proporcionar una propuesta para el desarrollo de los subsistemas existentes,
los cuales son:
a) Gestión de clientes
b) Gestión de almacén
c) Gestión de productos
2.2 Entregables del proyecto.
Se mostrarán la lista de los entregables que serán generados y utilizados en el proyecto.
1) Plan de Desarrollo del Software
Es el presente documento.
2) Modelo de Casos de Uso del Negocio
Nos permite tener una mejor perspectiva desde el contexto del negocio y de los
componentes externos (clientes, otros sistemas, etc)
3) Modelo de Objetos del Negocio
Describe la realización delos casos de negocio. Se utilizan diagramas de cooperación.
4) Glosario
Define términos técnicos

5) Modelo de Casos de Uso

Representar funciones del sistema y los actores que hacen uso de ellas.
6) Visión
Define la versión del producto desde la perspectiva del cliente. Constituye una base para el
proyecto de acuerdo a los requisitos del sistema.
7) Especificaciones de Casos de Uso
No bastando con solo una descripción simple, luego del análisis se utiliza una plantilla para la
elaboración de la descripción de los casos de uso, usando también representaciones gráficas.
8) Especificaciones adicionales.
 Reúne todos los requisitos que no han sido incluidos anteriormente como parte de los casos de uso
y se refiere a requisitos no-funcionales globales. Ciertos requisitos pueden incluir estándares.
9) Prototipos de interfaces de usuario.
Se le familiariza al usuario con las interfaces que proveerá el sistema mediante prototipos, para
conseguir una retroalimentación de su parte de acuerdo a los requisitos y si estos cumples con sus
necesidades. Estos prototipos puedes estar presentados de diversas formas como dibujos a mano,
prototipos ejecutables, dibujos a computadora, etc. Y puedes ser desechados durante el proceso.
10) Modelo de análisis y diseño.
Camino de una fase de análisis a una de diseño, sin tocar la etapa de implementación. Representa
casos prácticos en clases.
11) Modelo de datos.
Ya que la información del sistema será soportada por una base de datos relacional, se describe la
representación lógica de los datos persistentes. Para expresar este modelo se puede utilizar
diagramas de clases.
12) Modelo de implementación.
Versión preliminar del sistema. Consiste en colocar sus componentes en los subsistemas
correspondientes, incluye toda clase de ficheros; ejecutables, de código fuente, etc.
13) Modelo de desplioegue.
Muestra en despliegue la configuración del sistema y sus nodos, dando así despliegue a los
componentes.
14) Casos de prueba.
Especificadas mediante documentos, una en cada uno. Se especifica las condiciones bajo las cuales
se hará la prueba, las entradas y los resultados esperados. Cada caso de prueba llevará un
procedimiento y dependiendo de la prueba, este procedimiento puede automatizarse.
15) Solicitud de cambio.
Mediante un documento se especifican los cambios. Aquí se realiza un seguimiento de todos los
errores y defectos que se puedan presentar y todos los cambios solicitados y/o necesarios. Así se
provee un registro de decisiones de cambios, de su evaluación e impacto, y se asegura que éstos
sean conocidos por el equipo de desarrollo.
16) Plan de iteración.
Se reúnen las actividades a realizar y las tareas, ordenándolas temporalmente, con todos los
recursos asignados a cada una de ellas, independientes entre ellas.
17) Evaluación de iteración.
Incluye los resultados obtenidos en cada iteración realizada anteriormente, el grado o nivel
conseguido en cada una, y cambios realizados.
18) Lista de riegos.
Se redacta los riegos conocidos y persistentes durante el proceso del proyecto, ordenados de manera
decreciente en cuando a su importancia y con acciones específicas de contingencia.
19) Manual de instalación.
Incluye las instrucciones para la instalación adecuada del producto final.
20) Manual de apoyo al usuario final.
Incluye un conjunto de documentos de facilidades para el uso del sistema. Contiene guías de todo
tipo, desde operación hasta mantenimiento.
21) Producto.
Todos los ficheros del producto agrupados con los mecanismos necesarios para facilitar su
instalación. Siendo el producto una secuencia de cada iteración, al final se obtiene la versión final.
2.4 Evolución del plan de desarrollo de software.
El plan será revisado siempre que sea necesario, no teniendo un intervalo definido y se redifinirá al
comienzo de cada iteración.

3. Organización del Proyecto

3.1 Participantes en el Proyecto
De momento no se incluye el personal que designará Mesa de Ayuda como Responsable del
Proyecto, Comité de Control y Seguimiento, otros participantes que se estimen convenientes para
proporcionar los requisitos y validar el sistema.
El resto del personal del proyecto (por la parte de la empresa adjudicataria), estará formado
por los siguientes puestos de trabajo y personal asociado:
Jefe de Proyecto. Labor de Victor Agusto Martín Manayay Chamaya, alumno del curso de
Ingeniería de Software de la carrera de Ingeniería de Sistemas en la Facultad de Ingeniería Civil,
Sistemas y Arquitectura de la Universidad Pedro Ruiz Gallo. Con una experiencia modesta en
metodologías de desarrollo, herramientas CASE y notaciones, en particular la notación UML y el
proceso de desarrollo RUP.
Analista de Sistemas. El perfil establecido es: Ingeniero de Sistemas con conocimientos de UML,
uno de ellos al menos con experiencia en sistemas afines a la línea del proyecto, labor que llevará
a cabo José Chinchay Díaz.
4 Analistas - Programadores. Con experiencia en el entorno de desarrollo del proyecto, con el
fin de que los prototipos puedan ser lo más cercanos posibles al producto final. Este trabajo ha
sido encomendado a Ronald Andrés Suclupe Santisteban, Diego Marcelo Odar Nicolás, Elías
Torres Ventura, Ángel Alberto Gonzáles Guevara.
Ingeniero de Software. El perfil establecido es: Ingeniero de Sistemas recién titulado que
participará realizando labores de gestión de requisitos, gestión de configuración, documentación
y diseño de datos. Encargado de las pruebas funcionales del sistema, realizará la labor de Tester
Miguel Ángel Heredia Ramírez.
Los Currículos Vitae del personal del proyecto que ya ha comprometido su participación se
adjuntan por separado.
3.2 Interfaces Externas
Mesa de Ayuda definirá los participantes del proyecto que proporcionarán los requisitos del
sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada
subsistema y según el plan establecido.
El equipo de desarrollo interactuará activamente con los participantes de Mesa de Ayuda para
especificación y validación de los artefactos generados.

3.3 Roles y Responsabilidades

A continuación, se describen las principales responsabilidades de cada uno de los puestos en el
equipo de desarrollo durante las primeras fases, de acuerdo con los roles que desempeñan en RUP.

Puesto Responsabilidad
El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las
interacciones con los clientes y usuarios, y mantiene al equipo del proyecto
enfocado en los objetivos. El jefe de proyecto también establece un conjunto
Jefe de Proyecto de prácticas que aseguran la integridad y calidad de los artefactos del proyecto.
Además, el jefe de proyecto se encargará de supervisar el establecimiento de
la arquitectura del sistema. Gestión de riesgos. Planificación y control del
proyecto.
 Captura, especificación y validación de requisitos, interactuando con el cliente
y los usuarios mediante entrevistas. Elaboración del Modelo de Análisis y
Analista de Sistemas
Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo
de datos.

Construcción de prototipos. Colaboración en la elaboración de las pruebas

Programador
funcionales, modelo de datos y en las validaciones con el usuario

Gestión de requisitos, gestión de configuración y cambios, elaboración del

Ingeniero de Software modelo de datos, preparación de las pruebas funcionales, elaboración de la
documentación. Elaborar modelos de implementación y despliegue.

4. Gestión del Proceso

4.1 Estimaciones del Proyecto

El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento

separado.

4.2 Plan del Proyecto

En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.

Plan de las Fases

El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas.
La siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada
fase (para las fases de Construcción y Transición es sólo una aproximación muy preliminar)

Nro.
Fase Duración
Iteraciones

Fase de Inicio 1 3 semanas

Fase de Elaboración 1 3 semanas

Fase de 2 8 semanas
Construcción

Fase de Transición - -

Los hitos que marcan el final de cada fase se describen en la siguiente tabla.

Descripción Hito
 Fase de Inicio En esta fase desarrollará los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el
artefacto Visión.

Fase de En esta fase se analizan los requisitos y se desarrolla un

Elaboración prototipo de arquitectura (incluyendo las partes más
relevantes y / o críticas del sistema). Al final de esta fase,
todos los casos de uso correspondientes a requisitos que
serán implementados en la primera release de la fase de
Construcción deben estar analizados y diseñados (en el
Modelo de Análisis / Diseño).

Fase de Durante la fase de construcción se terminan de analizar y

Construcción diseñar todos los casos de uso, refinando el Modelo de
Análisis / Diseño. El producto se construye en base a 2
iteraciones, cada una produciendo una release a la cual se le
aplican las pruebas y se valida con el cliente / usuario.

Fase de En esta fase se prepararán dos releases para distribución,

Transición asegurando una implantación y cambio del sistema previo de
manera adecuada, incluyendo el entrenamiento de los
usuarios. El hito que marca el fin de esta fase incluye, la
entrega de toda la documentación del proyecto con los
manuales de instalación y todo el material de apoyo al
usuario, la finalización del entrenamiento de los usuarios y el
empaquetamiento del producto.

Calendario del Proyecto

A continuación se presenta un calendario de las principales tareas del proyecto incluyendo

sólo las fases de Inicio y Elaboración. Como se ha comentado, el proceso iterativo e
incremental de RUP está caracterizado por la realización en paralelo de todas las disciplinas de
desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy
tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de acuerdo
a la fase e iteración del proyecto. La siguiente figura ilustra este enfoque, en ella lo
ensombrecido marca el énfasis de cada disciplina (workflow) en un momento determinado del
desarrollo.
 FASE DE INICIO:

Disciplinas / Artefactos generados o modificados

Comienzo Aprobación
durante la Fase de Inicio

Modelado del Negocio

Modelo de Casos de Uso del Negocio y Modelo de Semana 1 Semana 3

Objetos del Negocio 14/10 – 20/10 28/10 – 3/11

Requisitos

Semana 1 Semana 3
Glosario
14/10 – 20/10 28/10 – 3/11

Semana 2 Semana 3
Visión
21/10 – 27/10 28/10 – 3/11

Semana 3
Modelo de Casos de Uso siguiente fase
28/10 – 3/11

Semana 3
Especificación de Casos de Uso siguiente fase
28/10 – 3/11

Semana 3
Especificaciones Adicionales siguiente fase
28/10 – 3/11

Análisis / Diseño

Semana 2
Modelo de Análisis / Diseño siguiente fase
21/10 – 27/10

Semana 2
Modelo de Datos siguiente fase
21/10 – 27/10

Implementación

Semana 3
Prototipos de Interfaces de Usuario siguiente fase
28/10 – 3/11

Semana 3
Modelo de Implementación siguiente fase
28/10 – 3/11

Pruebas
 Semana 3
Casos de Pruebas Funcionales siguiente fase
28/10 – 3/11

Despliegue

Semana 3
Modelo de Despliegue siguiente fase
28/10 – 3/10

Gestión de Cambios y Configuración Durante todo el proyecto

Gestión del proyecto

Plan de Desarrollo del Software en su versión 1.0 y Semana 1 Semana 3

planes de las Iteraciones 14/10 – 20/10 28/10 – 3/11

Ambiente Durante todo el proyecto

FASE DE ELABORACION:

Disciplinas / Artefactos generados o modificados durante la

Comienzo Aprobación
Fase de Elaboración

Modelado del Negocio

Modelo de Casos de Uso del Negocio y Modelo de Objetos del Semana 1

Aprobado
Negocio 14/10 – 20/10

Requisitos

Semana 1
Glosario Aprobado
14/10 – 20/10

Semana 2
Visión Aprobado
21/10 – 27/10

Semana 3 Semana 5
Modelo de Casos de Uso
28/10 – 3/11 11/12 – 17/12

Semana 3 Semana 5
Especificación de Casos de Uso
28/10 – 3/11 11/12 – 17/12

Semana 3 Semana 5
Especificaciones Adicionales
28/10 – 3/11 11/12 – 17/12
Análisis / Diseño

Semana 2 Revisar en cada

Modelo de Análisis / Diseño
21/10 – 27/10 iteración

Semana 2 Revisar en cada

Modelo de Datos
21/10 – 27/10 iteración

Implementación

Semana 3 Revisar en cada

Prototipos de Interfaces de Usuario
28/10 – 3/11 iteración

Semana 3 Revisar en cada

Modelo de Implementación
28/10 – 3/11 iteración

Pruebas

Semana 3 Revisar en cada

Casos de Pruebas Funcionales
28/10 – 3/11 iteración

Despliegue

Semana 3 Revisar en cada

Modelo de Despliegue
28/10 – 3/11 iteración

Gestión de Cambios y Configuración Durante todo el proyecto

Gestión del proyecto

Plan de Desarrollo del Software en su versión 2.0 y planes de las Semana 4 Revisar en cada
Iteraciones 4/11 – 10/11 iteración

Ambiente Durante todo el proyecto

4.3 Seguimiento y Control del Proyecto

Gestión de Requisitos

Los requisitos del sistema son especificados en el artefacto Visión. Cada requisito tendrá una
serie de atributos tales como importancia, estado, iteración donde se implementa, etc. Estos
atributos permitirán realizar un efectivo seguimiento de cada requisito. Los cambios en los
requisitos serán gestionados mediante una Solicitud de Cambio, las cuales serán evaluadas y
distribuidas para asegurar la integridad del sistema y el correcto proceso de gestión de
configuración y cambios.

Control de Plazos

El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de proyecto
y por el Comité de Seguimiento y Control.

Control de Calidad

Los defectos detectados en las revisiones y formalizados también en una Solicitud de Cambio
tendrán un seguimiento para asegurar la conformidad respecto de la solución de dichas
deficiencias Para la revisión de cada artefacto y su correspondiente garantía de calidad se
utilizarán las guías de revisión y checklist (listas de verificación) incluidas en RUP.

Gestión de Riesgos

A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al proyecto y de las
acciones establecidas como estrategia para mitigarlos o acciones de contingencia. Esta lista
será evaluada al menos una vez en cada iteración.

Gestión de Configuración

Se realizará una gestión de configuración para llevar un registro de los artefactos generados y
sus versiones. También se incluirá la gestión de las Solicitudes de Cambio y de las
modificaciones que éstas produzcan, informando y publicando dichos cambios para que sean
accesibles a todos los participantes en el proyecto. Al final de cada iteración se establecerá una
baseline (un registro del estado de cada artefacto, estableciendo una versión), la cual podrá
ser modificada sólo por una Solicitud de Cambio aprobada.
CREAMOS EL PROYECTO
1. Crear un proyecto nuevo

a. Ubicar el proyecto en un espacio de trabajo

CREAMOS UN MODELO DE NEGOCIO

1. Crear un modelo de negocio

a. Identificar el modelo de negocio y opte por un paquete vacío.

b. Activar todas las capacidades

c. Cambiar el estereotipo por uno adecuado de Modelo de Negocio

2.
Crear los paquetes necesarios para el desarrollo del modelo de negocio.

a. Paquete de Objetivos
i. Debe tener su main de objetivos
b. Paquete de Casos de Uso de Negocio
i. Debe tener su main de casos de uso de negocio
 ii. Debe tener un diagrama que represente la correlación de casos de uso de negocio
con los objetivos

a. Paquete de Actores i. Debe tener su main de actores

b. Debe tener un Diagrama del tipo Freeform para graficar los casos de uso de negocio y
actores de negocio
 ’

CREANDO UN MODELO DE ANALISIS DE NEGOCIO

1. Crear un modelo de Análisis de negocio
a. Identificar el modelo de análisis de negocio y opte por un paquete vacío.

b. Activar todas las capacidades

c. Cambiar el estereotipo por uno adecuado de Modelo de análisis de Negocio

2. Crear los paquetes necesarios para el desarrollo del modelo de negocio

y generar las dependencias necesarias.

CONFORMACION DE
PAQUETES DE MODELO DE
ANALISIS DE NEGOCIO
a. Paquete de Entidades
i. Debe tener su main de entidades

ii. Cada entidad debe tener su propio diagrama de estado

ENTIDADES DE
NEGOCIO
PLANTEADOS
 DIAGRAMA DE ESTADO
POR CADA CASO DE USO

b. Paquete de Trabajadores de Negocio iii. Debe tener su main de Trabajadores

TRABAJADORES DE
NEGOCIOS PLANTEADOS
 c. Paquete de Realizaciones de Negocio
i. Debe tener su main de Realizaciones
ii. Se debe usar las clases especializadas de Colaboración
iii. Cada realización contiene: 1. Un diagrama de Actividades 2. Un diagrama de clases
de negocio

RELACIONES DE
NEGOCIO

DIAGRAMA DE ACTIVIDADES
 Especificación de caso de uso de negocio:
Inscripción de Socio

CREANDO UN MODELO DE CASOS DE USO

1. Crear un modelo de Casos de Uso

a. Identificar el modelo de requerimientos y opte por un paquete vacío.

b. Activar todas las capacidades

2. Crear los paquetes necesarios para el desarrollo del modelo de negocio y generar las
dependencias necesarias.

a. Paquete de Actores

i. Debe tener su main de actores

b. Paquete de Casos de Uso
ii. Debe tener su main de Caso de uso

iii. Dentro del paquete de casos de uso, los organizaremos por cada caso de uso
encontrado

iv. Se debe generar dos diagramas adicionales

DIAGRAMA GENERAL
ESTRUCTURADO
 ESPECIFICACIONES DE CASOS DE USO

NOMBRE DE CASO
GENERA INCIDENCIA
DE USO:
CLIENTE
ACTOR PRINCIPAL:
EL CASO DE USO TIENE POR OBJETIVO HACER LA REDACCION DE UNA
PROPOSITO:
INCIDENCIA
FLUJO DE EVENTOS
1. LA INTERFAZ MUESTRA EL LOGIN PARA QUE EL CLIENTE
INICIE SESION CON SU USUARIO Y CLAVE.
2. EL CLIENTE INICIA SESION.
3. EL CLIENTE PULSA LA OPCION PARA REPORTAR LA
INCIDENCIA.
FLUJO BASICO
4. LA INTERFAZ MUESTRA EL FORMULARIO CON LOS CAMPOS:
 ASUNTO DE LA INCIDENCIA.
 LA DESCRIPCION SOBRE SU PROBLEMA.
5. UNA VEZ LLENADO LOS CAMPOS EL CLIENTE PULSA ENVIAR
INCIDENCIA.
FLUJO DESCARTAR INCIDENCIA: EL SISTEMA BORRA LOS DATOS LLENADOS
ALTERNATIVO ANTERIORMENTE.
PRECONDICIONES: EL CLIENTE DEBE REGISTRARSE EN EL SISTEMA
POSTCONDICIONES: LA RECEPCIONISTA RECIBE LA INCIDENCIA PARA ENVIARLAS AL JEFE
PUNTOS DE
NO EXISTEN PUNTOS DE EXTENSION
EXTENSION:

NOMBRE DE CASO
REVISAR ESTADO DE INCIDENCIA
DE USO:
ACTOR PRINCIPAL: CLIENTE
EL CASO DE USO TIENE POR OBJETIVO HACER QUE EL CLIENTE PUEDA
PROPOSITO:
REVISAR EL PROCESO DE SU INCIDENCIA.
FLUJO DE EVENTOS
FLUJO BASICO 1.
FLUJO DESCARTAR INCIDENCIA: EL SISTEMA BORRA LOS DATOS LLENADOS
ALTERNATIVO ANTERIORMENTE.
PRECONDICIONES: EL CLIENTE DEBE REGISTRARSE EN EL SISTEMA
POSTCONDICIONES: LA RECEPCIONISTA RECIBE LA INCIDENCIA PARA ENVIARLAS AL JEFE
PUNTOS DE
NO EXISTEN PUNTOS DE EXTENSION
EXTENSION:
NOMBRE DE CASO
GENERA INCIDENCIA
DE USO:
CLIENTE
ACTOR PRINCIPAL:
EL CASO DE USO TIENE POR OBJETIVO HACER LA REDACCION DE UNA
PROPOSITO:
INCIDENCIA
FLUJO DE EVENTOS
6. LA INTERFAZ MUESTRA EL LOGIN PARA QUE EL CLIENTE
INICIE SESION CON SU USUARIO Y CLAVE.
7. EL CLIENTE INICIA SESION.
8. EL CLIENTE PULSA LA OPCION PARA REPORTAR LA
INCIDENCIA.
FLUJO BASICO
9. LA INTERFAZ MUESTRA EL FORMULARIO CON LOS CAMPOS:
 ASUNTO DE LA INCIDENCIA.
 LA DESCRIPCION SOBRE SU PROBLEMA.
10. UNA VEZ LLENADO LOS CAMPOS EL CLIENTE PULSA ENVIAR
INCIDENCIA.
FLUJO DESCARTAR INCIDENCIA: EL SISTEMA BORRA LOS DATOS LLENADOS
ALTERNATIVO ANTERIORMENTE.
PRECONDICIONES: EL CLIENTE DEBE REGISTRARSE EN EL SISTEMA
POSTCONDICIONES: LA RECEPCIONISTA RECIBE LA INCIDENCIA PARA ENVIARLAS AL JEFE
PUNTOS DE
NO EXISTEN PUNTOS DE EXTENSION
EXTENSION:

NOMBRE DE CASO
GENERA INCIDENCIA
DE USO:
CLIENTE
ACTOR PRINCIPAL:
EL CASO DE USO TIENE POR OBJETIVO HACER LA REDACCION DE UNA
PROPOSITO:
INCIDENCIA
FLUJO DE EVENTOS
11. LA INTERFAZ MUESTRA EL LOGIN PARA QUE EL CLIENTE
INICIE SESION CON SU USUARIO Y CLAVE.
12. EL CLIENTE INICIA SESION.
13. EL CLIENTE PULSA LA OPCION PARA REPORTAR LA
INCIDENCIA.
FLUJO BASICO
14. LA INTERFAZ MUESTRA EL FORMULARIO CON LOS CAMPOS:
 ASUNTO DE LA INCIDENCIA.
 LA DESCRIPCION SOBRE SU PROBLEMA.
15. UNA VEZ LLENADO LOS CAMPOS EL CLIENTE PULSA ENVIAR
INCIDENCIA.
FLUJO DESCARTAR INCIDENCIA: EL SISTEMA BORRA LOS DATOS LLENADOS
ALTERNATIVO ANTERIORMENTE.
PRECONDICIONES: EL CLIENTE DEBE REGISTRARSE EN EL SISTEMA
POSTCONDICIONES: LA RECEPCIONISTA RECIBE LA INCIDENCIA PARA ENVIARLAS AL JEFE
PUNTOS DE
NO EXISTEN PUNTOS DE EXTENSION
EXTENSION: