Niversidad Eruana Nión: F I A E.P. I S

UNIVERSIDAD PERUANA UNIÓN
FACULTAD DE INGENIERÍA Y ARQUITECTURA

E.P. DE INGENIERÍA DE SISTEMAS
ENTREGABLE DE ANÁLISIS Y DISEÑO DE

SISTEMAS
<NOMBRE DEL PROYECTO>
DOCENTE:
ING. DIANA SANCHEZ TORPOCO
INTEGRANTES:
Huanca Namuche Andrés Alfonso
23/09/2020
<Nombre del Proyecto> Segundo Entregable
ÍNDICE
RESUMEN 3
INTRODUCCIÓN 4
1. ESTUDIO DE FACTIBILIDAD 5
1.1. LA VISIÓN DEL SISTEMA 5
2. MODELO DEL NEGOCIO 5
2.1. VISTA EXTERNA DEL MODELO DE NEGOCIO 5
2.1.1. Lista de los actores de negocio 5
2.1.2. Diagrama de casos de uso de negocio 5
2.2. VISTA INTERNA DEL MODELO DE NEGOCIO 5
2.2.1. Lista de trabajadores de negocio 5
2.2.2. Lista de entidades de negocio 5
2.3. REALIZACIÓN DE LOS CASOS DE USO DE NEGOCIO 6
2.3.1. <Nombre del caso de uso de negocio-1> 6
2.3.2. <Nombre del caso de uso de negocio-2> 6
2.3.3. <Nombre del caso de uso de negocio-N> 6
2.4. GLOSARIO DE TÉRMINOS 6
3. REQUERIMIENTOS 7
3.1. FUENTES DE OBTENCIÓN DE REQUERIMIENTOS 7
3.1.1. Informe de entrevistas 7
3.1.2. Benchmarking 7
3.1.3. Matriz de actividades y requerimientos 7
3.1.4. Especificación de Requerimientos Funcionales 7
3.2. PRIORIZACIÓN DE CASOS DE USO 7
3.3. LISTA DE CASOS DE USO PRIORIZADOS 7
3.4. REQUERIMIENTOS NO FUNCIONALES 8
3.5. REGLAS DE NEGOCIO 8
3.6. DIAGRAMAS DE CASO DE USO 8
4. ANÁLISIS Y DISEÑO 9
4.1. REALIZACIÓN DE LOS CASOS DE USO PARA EL ANÁLISIS 9
4.1.1. <Nombre del caso de uso 1> 9
4.1.2. <Nombre del caso de uso X > 9
4.2. MODELO CONCEPTUAL 9
4.3. REALIZACIÓN DE LOS CASOS DE USO PARA EL DISEÑO 9
4.3.1. <Nombre del caso de uso 1 del núcleo central – 1 Primera Iteración> 10
4.3.4. <Nombre del caso de uso del núcleo central – 2 Segunda Iteración > 12
4.4. DIAGRAMA DE TRANSICIÓN DE ESTADOS (DTE) 12
4.5. DIAGRAMA DE CLASES PERSISTENTES 12
4.6. BASE DE DATOS 12
4.6.1. Especificación de las características de la base de datos 12
4.6.2. Diagramas de la base de datos 13
5. PRUEBAS 14
5.1. INFORME DE LAS PRUEBAS FUNCIONALES 14
6. ADMINISTRACIÓN DEL PROYECTO 15
6.1. CRONOGRAMA DEL PROYECTO 15
Página 2
CONCLUSIONES 16
ANEXOS 17
Página 3
<La organización es la IIAP >

Resumen
El Instituto de Investigaciones de la Amazonía Peruana es una institución científica con
sede en la ciudad de Iquitos, en la región Loreto de Perú. IIAP es la organización peruana
más importante sobre estudios amazónicos en el mundo. El instituto fue creado en 1981
durante la Constitución Política del Perú del 1970
Página 4
Introducción
El instituto fue creado en 1981 durante la Constitución Política del Perú del 1970. IIAP
describe su misión como la creación de tecnologías innovadoras en favor de la
biodiversidad y poblaciones amazónicas.2 Realiza proyectos de investigación y desarrollo
científico y capacitación tecnológica con servicios de participación comunitaria. El sistema
de investigación del instituto está conformado por seis programas principales.
Las áreas de enfoque del IIAP incluyen negocios, biotecnología molecular, educación y
protección ambiental, turismo científico, estudios antropológicos y lingüísticos, tecnología
ambiental, así como la creación de aplicaciones de informática. 6 IIAP tiene significantes
alianzas con organizaciones internacionales alrededor del globo, incluyendo el Banco
Mundial, la Universidad de colorado.
Página 5
1. Estudio de factibilidad
El Instituto de Investigaciones de la Amazonía Peruana (IIAP) es una Institución de
investigación científica y tecnológica concebida para lograr el desarrollo sostenible de la
población amazónica, con énfasis en lo rural, especializada en la conservación y uso correcto de
los recursos naturales en la región amazónica.
QUE ES IIAP?
El instituto de Investigación de la Amazonia peruana es una institución científica como sede en
la ciudad de Iquitos ,en la región Loreto de Perú IIAP es la organización peruana más
importante sobre estudios amazónicos en el mundo .El instituto fue creado en 1981 durante la
constitución política de Perú del 1970.
MISIÓN:
Generar y proveer conocimientos sobre la diversidad biológica y socio-cultural de la amazonia
peruana, en beneficio de la población que sean pertinentes, eficientes y confiables.
VISIÓN: Generar e incorporar conocimientos, tecnologías innovadoras y el saber de las
sociedades y de los ecosistemas amazónicos.
VALORES:
Los directos del IIAP realizaran una gerencia estratégica, ejerciendo liderazgo participativo
promoviendo el trabajo en equipo y manteniendo la motivación del personal a su cargo
promoviendo el desarrollo de sus iniciativas y capacidad de crítica e iniciativa.
El liderazgo y participación en los equipos de trabajo exigen transparencia en la información la
misma que debe ser comunicada a todos los miembros de la organización como expresión de
respeto y confianza mutua.
El IIAP es una institución eminentemente científica y técnica con carácter autónomo e
independiente que garantiza una gestión eficiente y de calidad.
El conocimiento y la información deben transmitirse con calidad.
Con la mira en esta misión y visión el IIAP brindaba capacitaciones presenciales a la comunidad
para beneficiar a la población, actividad que se ha visto anulada por la crisis sanitaria por la que
atraviesa el Perú y el mundo. Bajo estas circunstancias y con la mira a expandirse y poder
brindar cursos al extranjero es que el IIAP se ve en la necesidad de impartir conocimientos a la
sociedad de la zona y en general, por lo que bajo la modalidad de cursos MOOC desea proveer
de los conocimientos necesarios para la preservación de la Amazonía, buscando alcanzar un
amplio número de participantes.
OBJETIVOS:
Desarrollar los sistemas de producción sostenible en base a los recursos de la diversidad
biológica amazónica utilizados por los productores.
Incrementar propuestas técnicas para la conservación y uso sostenible de la diversidad biológica
,recursos hidrobiológicos ,y bosques andi-amazónicos para uso de los órganos de desarrollo.
1.1. La visión del sistema

Introducción:
IIAC MOCS
1.2 OBJETIVOS:
El propósito del sistema es crear una plataforma de cursos masivos abiertos online totalmente
personalizada son con temas de amazonia, sus tejidos, artesanía y cultura. Teniendo como
opción obtener una certificación del curso que está llevando, la cual tiene un costo.
Los cursos son de capacitaciones ya grabadas emitidas en cierto horario durante cierto tiempo,
dirigida al público en general.
El público “El cliente” que desee participar de estos cursos debe previamente haberse registrado
en la plataforma, especificando sus datos básicos y como dato necesario el nivel académico
Página 6
(técnico, técnico superior, superior, posgrados para poder llevar un registro y estadísticas sobre
el público objetivo.
El cliente puede buscar entre los cursos disponibles, escoger y registrarse en el curso que desee
llevar, especificando si desea o no obtener la certificación correspondiente, dirigiéndose hacer
los pagos, opción que estará disponible en cualquier momento mientras se dicte el curso.
Tanto como para poder lograr la certificación o evaluar su aprendizaje en el curso que eligió
debe pasar una Evaluación Objetiva.
1.3 Alcance o campo de acción

En el marco de los Objetivos Estratégicos Institucionales se busca alcanzar
el objetivo: “Incrementar técnicas para la conservación y uso sostenible de
la diversidad biológica, recursos hidrobiológicos, y bosques andino-
amazónicos para uso de los órganos de desarrollo” mediante la acción
estratégica: “Transferencia de conocimientos y tecnologías integradas
sobre la conservación y uso sostenible de la diversidad biológica a los
órganos de desarrollo”. Mediante la implementación de la plataforma Mooc:
el Registro de Usuarios, Registro de Cursos, Evaluación Objetiva y
Personalización del Sistema.
No se planea alcanzar los procesos de investigación, estudios
especializados, ni los procesos de desarrollo de sistemas de producción o
las propuestas técnicas para la conservación y uso sostenible de toda la
Amazonia.
2. Posicionamiento del sistema

2.1Objeto de estudio
El Instituto de Investigaciones de la Amazonía Peruana (IIAP) es una institución de
investigación científica y tecnológica que tiene como objetivo lograr el desarrollo sostenible de
la población de la región amazónica, con un enfoque en las áreas rurales, dedicada a la
protección y uso adecuado de los recursos naturales de los pueblos amazónicos de la región. Su
valor añadido es un proyecto financiado por la Unión Europea, el Fondo Mundial para el Medio
Ambiente y el Banco Mundial.
2.2 Oportunidad de negocio

La oportunidad de negocio que se alcanza con la implementación de la
plataforma Mooc, es alcanzar a población extranjera que pueda participar
de los cursos, obteniendo aún más reconocimiento internacional, generando
conciencia sobre el uso responsable de los recursos naturales y su mejor
aprovechamiento.
2.3 Declaración del problema a resolver
Ante la crisis sanitaria que vivimos en Perú y a nivel mundial, y la
suspensión de actividades sociales para evitar más muertes a nivel nacional
y mundial, el IIAP se encontró con que no puede seguir impartiendo sus
capacitaciones de forma presencial.
El problema de No poder impartir capacitaciones

afecta a toda la población circundante
El impacto está Se pierde la oportunidad de brindar conocimientos
tan importantes a la comunidad
Una solución adecuada Se podrá impartir cursos de forma masiva,
Página 7
sería llegando a todos los rincones del Perú

Se podrá expandir a nivel internacional
[listar algunos beneficios clave de una solución
exitosa
2.4
1.1 Declaración del Posicionamiento del Producto
[Proporcionar una declaración total sumarizada y de alto nivel acerca de la
única posición que el producto desea alcanzar en el mercado. El siguiente
formato debe ser usado:
Para Comunidad
[nombre del cliente destino]
Quién Alcanzar a todas las comunidades del Perú
[declarar las necesidades u oportunidades que
busca el cliente destino]
El (producto)
Que
A diferencia de Miríada X que no cuenta con una opción de
Certificación pagada.
Coursera, no cuenta con una personalización de

temas, donde destaque la Amazonia
[mencionar alternativa de competencia principal]

Nuestro producto Es una plataforma web de cursos Mooc
Especialización en investigaciones y estudios de la

Amazonia.
Completa personalización de la plataforma
[declarar el beneficio clave; esto es, una razón
obligatoria para su compra.]
El propósito del sistema es crear una plataforma de cursos masivos

abiertos online totalmente personalizada con temas de amazonia,
sus tejidos, artesanía y cultura. Teniendo el público como opción
obtener una certificación del curso que está llevando, la cual tiene
un costo.
Los cursos son de estilo capacitaciones ya grabadas emitidas en
cierto horario durante cierto tiempo, dirigida al público en general.
Página 8
El público (en adelante “El cliente”)que desee participar de estos

cursos debe previamente haberse registrado en la plataforma,
especificando sus datos básicos y como dato necesario el nivel
académico (técnico, técnico superior, superior, posgrados)para
poder llevar un registro y estadísticas sobre el público objetivo.
El cliente puede buscar entre los cursos disponibles, escoger y
registrarse en el curso que desee llevar, especificando si desea o
no obtener la certificación correspondiente, dirigiéndose a la
pasarela de pagos, opción que estará disponible en cualquier
momento mientras se dicte el curso.
Tanto como para poder lograr la certificación o evaluar su
aprendizaje en el curso que eligió debe pasar una Evaluación
Objetiva.
2. Modelo del negocio

Se debe incluir aquí, una introducción del estudio del modelo de negocios en donde se describa
los alcances de los procesos que conforman el campo de acción del software por desarrollar. Es
conveniente incluir un gráfico de alto nivel de los procesos involucrados.
2.1. Vista externa del modelo de negocio

2.1.1. Lista de los actores de negocio
Para la lista de actores de negocio utilizar el siguiente cuadro:
Lista de actores de negocio
Nombre Descripción
2.1.2. Diagrama de casos de uso de negocio

Los diagramas de casos de uso del negocio pueden estar agrupados por paquete si el alcance, así
lo amerita.
Página 9
2.2. Vista interna del modelo de negocio

2.2.1. Lista de trabajadores de negocio
Para la lista de los trabajadores del negocio, utilizar el siguiente cuadro:
Lista de trabajadores de negocio
Nombre Descripción
2.2.2. Lista de entidades de negocio

Para la lista de las entidades de negocio utilizar el siguiente cuadro, donde: Origen: (I=Interna,
generada por el propio negocio, E=Externa, generada por o hacia los business actor); Tipo:
(P=Persistente, que almacena datos, F=Formulario o documento impreso).
Página 10
Lista de entidades de negocio
Nombre Descripción Origen Tipo
2.3. Realización de los casos de uso de negocio

Cada caso de uso estará numerado con el prefijo 2.3.x y sus contenidos serán los que se
presentan a continuación:
2.3.1. <Nombre del caso de uso de negocio-1>

Especificación de alto nivel
Para la especificación de alto nivel utilizar el siguiente formato:
Nombre BUC_01_xxxxxx
Descripción <Este caso de uso empieza cuando ….. (describir brevemente el
proceso) y termina cuando…..>
Actores de negocio <Poner los actores de negocio que intervienen en el proceso>
Entradas <Son los inputs del proceso que generalmente los proporciona el
actor de negocio>
Entregables <Son los resultados del proceso que benefician o afectan a ciertos
business actors>
Mejoras <Describir las mejoras que se propondrían a los procesos para
resolver algún problema o para hacer una innovación tecnológica.
Estas mejoras deben ser mediante la introducción de un sistema
automatizado>
Diagrama de objetos de negocio

Se hace uno para cada caso de uso del negocio
Diagrama de actividades
Los diagramas de Actividad deben reflejar procesos de negocios ideales (TO BE) e incluir
Swimlanes y conexiones con Objetos (Business Entities). Debe mostrarse de manera gráfica
(con colores o en negrita) aquellas actividades que se pueden automatizar. Se debe
confeccionar un diagrama de actividades por cada caso de uso. (Debe presentarse de manera que
se pueda leer).
2.3.2. <Nombre del caso de uso de negocio-2>
2.3.3. <Nombre del caso de uso de negocio-N>
2.4. Matriz de actividades
Página 11
2.5. Glosario de términos

Para el glosario de términos utilizar el siguiente formato:
Glosario de términos al XX%

Nombre Descripción
A
Asistencia Es el control del número de clases asistidas por el socio.
Autorización
B
Botiquín Es……
…….
Z
Página 12
3. Requerimientos
Se debe incluir un párrafo con la introducción del flujo de requerimientos. Esta introducción
debe describir los alcances del sistema para el primer entregable.
3.1. Fuentes de obtención de requerimientos

3.1.1. Informe de entrevistas
En este documento se presenta un recuento de los requerimientos y reglas de negocio obtenidas
como producto de las entrevistas al usuario. Se puede utilizar la plantilla 03-Informe de
entrevistas b.doc
3.1.2. Benchmarking
Para el benchmarking de productos similares al software a desarrollar en el proyecto se puede
utilizar el formato: 03-Benchmarking.xls
3.1.3. Matriz de actividades y requerimientos

Para la matriz de actividades y requerimientos utilizar el formato: 03-Matriz de
Requerimientos.xlsx
3.1.4. Especificación de Requerimientos Funcionales

Utilizar el formato: 03-Especificación Req Funcionales.xlsx
3.2. Priorización de Casos de Uso

Casos de 0.4 0.3 0.2 0.1
Uso Importanci Complejidad Riesgo Impacto de
a en el de desarrollo asociado requerimientos Clasificació
proceso del Total
no funcionales n
negocio
1-10 1-10 1-10 1-10
CUS01 Primario
CUS02 Primario
CUS03 Secundario
CUS04 Secundario
3.3. Lista de casos de uso priorizados

Para la lista de casos de uso priorizados utilizar el siguiente formato:
Lista de casos de uso priorizados al XX%

Iteración: 1 – Núcleo Central
Nombre del caso de uso Cursos de eventos programados Justificación
<Caso de uso 1>
Página 13
Iteración: 2
Nombre del caso de uso Cursos de eventos programados Justificación
3.4. Requerimientos No Funcionales

Para la especificación de los requerimientos No Funcionales utilizar el siguiente cuadro:
Requerimientos No Funcionales
Requerimientos de <Categoría de Requerimiento No funcional>
Código Descripción
RNF01 <Descripción del requerimiento no funcional 1>
RNF02 <Descripción del requerimiento no funcional 1>
Requerimientos de <Categoría de Requerimiento No funcional>

RNFxx <Descripción del requerimiento no funcional NN>
3.5. Reglas de negocio

Para las reglas de negocio utilizar el siguiente formato:
Reglas de negocio al XX%

Código Nombre Descripción Casos de uso
afectados
RN01 Bonificación Política de descuento en la atención de cliente C01-Registrar
que consiste en una rebaja del 10% por la venta
acumulación de 20 puntos.
RN02 Condición de Política de otorgamiento de crédito que consiste C02-Evaluar
otorgamiento en fijar características particulares requeridas crédito
de crédito para la calificación de un sujeto de crédito.
…….
3.6. Diagramas de caso de uso

Los diagramas de Casos de Uso deben estar organizados en paquetes y de forma tal que se
muestren las relaciones include y extend.
Página 14
4. Análisis y diseño
La introducción del análisis y diseño debe contener una breve descripción de cada uno de los
artefactos y las consideraciones y normas que se han tomado en cuenta para su elaboración.
4.1. Realización de los casos de uso para el análisis

Para cada caso de uso se efectuará:
4.1.1. <Nombre del caso de uso 1>

Para esta especificación utilizar la plantilla siguiente:
Nombre <Nombre del caso de uso>

Tipo <(Primario, Secundario, Opcional)>
Autor <Poner el nombre de la persona que efectuó la especificación>
Actores <Poner a los actores involucrados>
Iteración <Número de la iteración en donde será desarrollado>
Descripción <El caso de uso comienza cuando................ y termina con.................>
Referencias <Poner los requerimientos relacionados (se pueden usar códigos)>
Pre condiciones <Describir los requerimientos precedentes>
Post condiciones <Describir los efectos inmediatos en el sistema como consecuencia del
término del caso de uso (cambios efectuados, redactados en pasado)>
Diagrama de clases de análisis

Este diagrama se hacer para los casos de uso del núcleo central o de la primera iteración.
4.1.2. <Nombre del caso de uso X >

Para esta especificación utilizar la plantilla siguiente:
Nombre <Nombre del caso de uso>

Tipo <(Primario, Secundario, Opcional)>
Actores <Poner a los actores involucrados>
Descripción <El caso de uso comienza cuando................ y termina con.................>
Referencias <Poner los requerimientos relacionados (se pueden usar códigos)>
Pre condiciones <Describir los requerimientos precedentes>
Post condiciones <Describir los efectos inmediatos en el sistema como consecuencia del
término del caso de uso (cambios efectuados, redactados en pasado)>
Diagrama de clases de análisis

Este diagrama se hacer para los casos de uso del núcleo central o de la primera iteración.
4.2. Modelo Conceptual

Incorporar aquí el diagrama del modelo conceptual de clases.
Página 15
4.3. Realización de los casos de uso para el diseño

Se efectuará para el 100% de los casos de uso del núcleo central o iteración 1. Para cada caso de
uso se elaborarán los artefactos que a continuación se describen
4.3.1. <Nombre del caso de uso 1 del núcleo central – 1 Primera Iteración>
Especificación esencial
La especificación se hace en modo esencial y debe tener referencias a las interfaces (se citan en
los anexos) y a las reglas de negocio (se mencionan en el texto de los flujos de eventos) . Ver
anexo ejemplo de especificación proporcionado en clase y ajustar al siguiente formato:
Nombre <Nombre del Caso de uso>

Tipo Esencial y <Primario, Secundario u Opcional>
Versión <Poner aquí el número de la versión del caso de uso>
Actores <Poner a los actores involucrados
Descripción <El caso de uso comienza cuando ................y termina con.................>
Referencias <Poner los requerimientos relacionados>
Requerimientos <Poner los requerimientos no funcionales que impactan en la operatividad
especiales del caso de uso>
Precondiciones <Describir los requerimientos precedentes>
Post Condiciones <Efectos inmediatos en el sistema como consecuencia del término del
caso de uso (Cambios efectuados)
Flujo normal de eventos
Acción del actor Respuesta del sistema
1. 2.
3. 4.
5. 6.
7. 8.
Flujo alternativo de eventos <x>
1. 2.
3. 4.
5. 6.
1. 2.
3. 4.
Anexos
Prototipos del Caso de Uso
Diagrama de clases de diseño

Muestra todas las clases participantes en la realización de casos de uso con sus respectivas
visibilidades.
Página 16
Diagramas de interacción (DI) (secuencia y/o colaboración)

De preferencia realizar diagramas de interacción para cada operación identificada en el DSS.
Los diagramas deben ser orientados al diseño

9. 10.
11. 12.
13. 14.
15. 16.
7. 8.
9. 10.
11. 12.
5. 6.
7. 8.
Anexos
Página 17

visibilidades.


17. 18.
19. 20.
21. 22.
23. 24.
13. 14.
15. 16.
17. 18.
9. 10.
11. 12.
Anexos
Página 18

visibilidades.

4.3.4. <Nombre del caso de uso del núcleo central – 2 Segunda Iteración >
4.4. Diagrama de transición de estados (DTE)

Se efectúa para las clases entidades significativas, altamente transaccionales y que pasan por
varios estados.
4.5. Diagrama de clases persistentes

Muestra el diagrama de las clases entidad completo (atributos, multiplicidad y visibilidad).
4.6. Base de datos

4.6.1. Especificación de las características de la base de datos
Especificación del comportamiento de la BD (Triggers, Procedimientos Almacenados, etc.),
Dominios.
4.6.2. Diagramas de la base de datos

Son los diagramas lógico y físico de la base de datos. Se puede usar el diagrama de clases
persistentes del Rational.
4.7. Especificación de la arquitectura

Documento con la especificación de las capas utilizadas, subsistemas identificados, mecanismos
de diseño empleados (con asociación de requerimientos no funcionales), filosofía, etc. Utilizar
como referencia patrones, como los sugeridos por Java o por Microsoft para el diseño de la
arquitectura. Se puede utilizar el formato (06-Arquitectura) adicionando los diagramas de
componentes y de distribución
Página 19
5. Pruebas
Se debe incluir un párrafo introductorio que detalle el contenido de las pruebas.
5.1. Informe de las pruebas funcionales

En la versión alfa solamente se probará la consistencia de los controles, la navegación, el acceso
a los casos de uso del núcleo central y el registro de información básica en la base de datos
(correspondiente a cuatro casos de uso como mínimo por integrante). Ver 10-
Informe_de_prueba.docx.
Informe de prueba 01
Fase: CNT - CONSTRUCCIÒN
Actor Principal xxxxxxxxxx
Nro.: 01 Fecha: 25-oct-18 Avance % 90%
Tipo de Unidad: PCUS
Tester: xxxxxxxx
Unidad de Prueba: CUS-Registro de Clientes
<<Descripción del Caso de uso >>
Descripción de la Prueba:
E.g. En esta prueba se está validando adicionar, modificar y eliminar un cliente.
Aspecto de Prueba Nombre objeto Diag. Descripción

1) Inicio del caso de uso Frm-Menu ☺
2) Búsqueda de Clientes Frm- ☹ No se puede efectuar la búsqueda de
por iniciales del ListaClientes los clientes por las iniciales del
nombre nombre
3) Registro del cliente en T-Cliente ☺
la base de datos
4)
5)
6)
7)
8)
9)
10)
11)
Página 20
6. Administración del proyecto

Incluir un párrafo con las principales consideraciones de administración de proyecto.
6.1. Cronograma del proyecto

Este cronograma debe mostrar cada punto del entregable y el detalle de los casos de uso que han
sido escogidos para ser desarrollados hasta la programación. Debe incluir puntos de revisión y
actividades acordes con el plan de pruebas.
Página 21
Conclusiones
Las conclusiones se refieren a las lecciones aprendidas al elaborar el trabajo. Debe estar
numeradas con viñetas.
Página 22
Anexos
Deben incluirse como anexos las entrevistas efectuadas a los clientes del sistema y otros
documentos que se consideren importantes
Página 23

Niversidad Eruana Nión: F I A E.P. I S

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Niversidad Eruana Nión: F I A E.P. I S

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PERUANA UNIÓN

FACULTAD DE INGENIERÍA Y ARQUITECTURA

ENTREGABLE DE ANÁLISIS Y DISEÑO DE

Huanca Namuche Andrés Alfonso

<La organización es la IIAP >

1.1. La visión del sistema

1.3 Alcance o campo de acción

2. Posicionamiento del sistema

2.2 Oportunidad de negocio

El problema de No poder impartir capacitaciones

sería llegando a todos los rincones del Perú

Coursera, no cuenta con una personalización de

[mencionar alternativa de competencia principal]

Especialización en investigaciones y estudios de la

El propósito del sistema es crear una plataforma de cursos masivos

El público (en adelante “El cliente”)que desee participar de estos

2. Modelo del negocio

2.1. Vista externa del modelo de negocio

Lista de actores de negocio

2.1.2. Diagrama de casos de uso de negocio

2.2. Vista interna del modelo de negocio

Lista de trabajadores de negocio

2.2.2. Lista de entidades de negocio

Lista de entidades de negocio

Nombre Descripción Origen Tipo

2.3. Realización de los casos de uso de negocio

2.3.1. <Nombre del caso de uso de negocio-1>

Diagrama de objetos de negocio

2.3.2. <Nombre del caso de uso de negocio-2>

2.3.3. <Nombre del caso de uso de negocio-N>

2.4. Matriz de actividades

2.5. Glosario de términos

Glosario de términos al XX%

3.1. Fuentes de obtención de requerimientos

3.1.3. Matriz de actividades y requerimientos

3.1.4. Especificación de Requerimientos Funcionales

3.2. Priorización de Casos de Uso

3.3. Lista de casos de uso priorizados

Lista de casos de uso priorizados al XX%

3.4. Requerimientos No Funcionales

Requerimientos de <Categoría de Requerimiento No funcional>

3.5. Reglas de negocio

Reglas de negocio al XX%

3.6. Diagramas de caso de uso

4.1. Realización de los casos de uso para el análisis

4.1.1. <Nombre del caso de uso 1>

Nombre <Nombre del caso de uso>

Diagrama de clases de análisis

4.1.2. <Nombre del caso de uso X >

Nombre <Nombre del caso de uso>

Diagrama de clases de análisis

4.2. Modelo Conceptual

4.3. Realización de los casos de uso para el diseño

Nombre <Nombre del Caso de uso>

Prototipos del Caso de Uso

Diagrama de clases de diseño

Diagramas de interacción (DI) (secuencia y/o colaboración)

Nombre <Nombre del Caso de uso>

Prototipos del Caso de Uso

Diagrama de clases de diseño

Diagramas de interacción (DI) (secuencia y/o colaboración)

Nombre <Nombre del Caso de uso>

Prototipos del Caso de Uso