UNIVERSIDAD PRIVADA DEL VALLE

GUÍA PARA LA EVALUACIÓN FINAL DE TALLER DE SISTEMAS III

La presente guía propone la estructuración exacta del documento a entregar, es una

propuesta con todos los aspectos que deben estar contenidos en el documento.
Esta guía abarca los la Modelación del Negocio, la Ingeniería de Requisitos, Análisis y
Diseño.
Debe ser presentada en formato digital (CD) e impresa para su revisión y defensa. La fecha
límite para la entrega es el viernes 3 de noviembre de 2010. El documento impreso debe ser
entregado en Secretaría de la Facultad de Informática y Electrónica.
Para la defensa del proyecto se debe presentar un conjunto de diapositivas que debe definir
los puntos más importantes del proyecto de Taller III de Sistemas. Las fechas para esta
defensa son: 7 y 9 de noviembre de 2010 en horario de clase. Cada estudiante tendrá 45
minutos para su defensa con las diapositivas, luego existirán preguntas del tribunal revisor.
Al final de la guía existe una lista de comprobación que ayudará a la evaluación final. Esta
lista, debe ser tomada en cuenta por cada estudiante y por el tribunal.

PREMISAS FUNDAMENTALES
 El documento debe escribirse con claridad y precisión, demostrando que el autor
posee dominio del idioma, capacidad explicativa y claridad de síntesis.
 Todos los gráficos, figuras y tablas que aparecen en el documento deben estar
enumerados y referenciados.
 Los diagramas deben aparecer con tamaños de letra legibles, en caso de no ser
así, no se procederá a su corrección considerándose como un acápite no incluido en
la documentación
 El perfil debe estar escrito con un interlineado de 1,5 líneas y en papel de formato
Carta.
 La letra utilizada debe ser Arial tamaño #12.
 El espacio de los márgenes serán:
 Izquierdo de 3cm
 Derecho de 2cm
 Superior de 2cm
 Inferior de 2cm

MsC. Ing. Roberto Zamuriano Sotés 1

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.
UNIVERSIDAD PRIVADA DEL VALLE

 Cada hoja utilizada debe estar numerada correctamente.

CARÁTULA
Institución a la que se presenta el trabajo (Universidad, Facultad y Carrera)
Título del trabajo.
Nombre del autor del trabajo
Nombre del tutor
Nombre del Responsable de la Institución
Evaluación Final de Taller de Sistemas III
Fecha de presentación

RESUMEN
ÍNDICE
1. INTRODUCCIÓN
Los puntos que se deben abordar en la introducción son el siguiente:
Fundamentos Teóricos y Justificación de la Herramientas.
Descripción del Negocio o Institución.
Descripción del Problema a Resolver
Hipótesis (Si fuera necesario)
Objetivo General y Objetivos Específicos.
Problema
Valor Práctico
La redacción de estos puntos de estar de acuerdo con el Perfil de Proyecto, no deben ir
como subtítulos, debe existir una redacción continua explicando todos los puntos.

2. Modelación del Negocio.

Modelo de Casos de Uso del Negocio
Definición de actores del negocio.

Actor del Descripción

negocio

MsC. Ing. Roberto Zamuriano Sotés 2

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.
UNIVERSIDAD PRIVADA DEL VALLE

Definición de trabajadores del negocio.

Trabajador del Descripción

negocio

Descripción de los Casos de uso del Negocio utilizando la plantilla estudiada en

clases.

Nombre del CU del

Negocio
Actores del Negocio
Propósito
Resumen

Descripción de los Casos de Uso del Negocio mediante Diagramas de Actividad

Realizar los diagramas de actividad para cada caso de uso del negocio

Diagrama de Casos de Uso del Negocio.

Realizar el diagrama incluyendo todos los casos de uso del negocio. Incluir relaciones
de inclusión, extensión o generalización entre los casos de uso del negocio, en caso de
existir. Incluir generalización entre actores en caso de existir.

2.3. Glosario de términos del Negocio

Especificar términos que puedan causar dudas o que signifiquen algo específico para la
entidad.

3. Modelo de Casos de Uso de la Aplicación

Descripción de Actores de la Aplicación

Actor Descripción

Diagrama de casos de uso de la aplicación

Realizar el diagrama incluyendo todos los casos de uso de la aplicación. Incluir relaciones
de inclusión, extensión o generalización entre los casos de uso en caso de existir. Incluir
generalización entre actores en caso de existir.

Priorizar los casos de uso.

MsC. Ing. Roberto Zamuriano Sotés 3

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.
UNIVERSIDAD PRIVADA DEL VALLE

Agruparlos según su nivel de prioridad en Primarios, Secundarios.

Especificación de los casos de uso.

Detallar dos (2) Casos de Uso de forma expandida de los identificados como de Primera
Prioridad.
(Utilizar la plantilla de casos de uso e incorporar la interfaz)
No se aceptan los Casos de Uso siguientes:
Autenticar
Cambiar Contraseña
Adicionar
Modificar
Eliminar
La descripción de un caso de uso debe contener por lo menos una sección.

4. Requisitos no funcionales

Tener en cuenta que existen requisitos no funcionales asociados a casos de uso en particular
(los cuales se incluyen en la especificación de esos casos de uso) y los que son generales a
todos los casos de uso, estos últimos son los que van incluidos en este punto.

5. Estimación basada en casos de uso.

Mediante el método de Puntos Función y Casos de uso hallar el esfuerzo, tiempo de

desarrollo y costo del proyecto.
Esfuerzo
Tiempo
Costo
Se debe realizar un nuevo cálculo del costo, ya que se cuenta con claridad las transacciones
de cada un de los casos de uso.

6. Etapa de Análisis.

Definir las Realizaciones de Análisis de los casos de uso que han sido detallados a través
de la plantilla de Casos de Uso en su forma expandida. Cada diagrama de realizaciones
debe tener un título que identifique el nombre del caso de uso y la sección o curso alterno.
Realizar el diagrama de colaboración de cada una de las realizaciones, utilizando los
estereotipos de Interfaz (Frontera), Control y Entidad. Cada diagrama de colaboración debe
tener un título que identifique el caso de uso la realización.

7. Etapa de de Diseño

7.1. Definición de la Arquitectura

7.1.1 Definición del Marco de Trabajo

MsC. Ing. Roberto Zamuriano Sotés 4

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.
UNIVERSIDAD PRIVADA DEL VALLE

Debe definirse la mini-arquitectura para la aplicación, además de la selección de las

tres capas se debe describir en forma completa la mini-arquitectura. Se puede utilizar el
diagrama de tres capas que propone el Racional Rose.
Cada una de las carpetas que conformen el marco de trabajo debe estar definida, es
decir que se debe explicar qué tipo de clases se alojarán.

7.1.2. Diagrama de los Subsistemas.

Debe definirse los subsistemas que tendrá la aplicación. No se debe olvidar que hay
dos formas para la selección de los subsistemas. Una es realizar por cercanía de
funcionalidad y otra es por los actores que participan en la aplicación.

7.1.3. Definición de la funcionalidad de los subsistemas.

Debe definirse las funcionalidades por cada subsistema que se ha definido en el
anterior subtitulo. Debe estar de acuerdo con los casos de uso la descripción de las
funcionalidades.
Nombre Subsistema: Nombre del Subsistema
Funcionalidad Descripción de la funcionalidad
1. Nombre Funcionalidad 1 Descripción de la funcionalidad 1

7.1.4. Definición de los Servicios Web.

Se debe definir los Servicios Web que se consideren necesarios para la aplicación.
Puede existir uno solo o varios. Se recomienda tener uno por subsistema definido

Nombre Servicio Web Descripción de los roles del SW

7.1.5. Definición de las Clases Persistentes mas significativas.

Se debe desarrollar el diagrama de clases de diseño de forma general, seleccionando a
las clases persistentes más significativas que participarán en la aplicación.

7.2. Definición de las realizaciones de diseño.

7.2.1 Diagrama de Realizaciones de Diseño.

Se debe definir las realizaciones de diseño de los dos casos de uso que se han
expandido. Estas realizaciones nacen de las realizaciones de análisis. Algunas veces,
las realización es de diseño pueden ser más de una. Es decir que por una realización de
análisis puede tenerse de una a muchas realizaciones de diseño.

7.2.2. Diagrama Mapa de Navegación

Se debe definir el Mapa de Navegación de la aplicación utilizando los estereotipos de
“Cliente Page” y LINK

7.2.3. Diagrama de Clases Web

Se debe realizar el Diagrama de Clases Web por cada realización de diseño. Se debe
utilizar los estereotipos de “Client Page”, “Server Page” y “http Form”, incluyendo los
mensajes entre cada una de las clases.

MsC. Ing. Roberto Zamuriano Sotés 5

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.
UNIVERSIDAD PRIVADA DEL VALLE

7.2.4. Diagrama de secuencia

Realizar el los diagramas de Secuencia por cada Realización de Diseño.
Debe cumplir lo siguiente:
- Estar con bastante detalle,
- Los nombre de las Clases deben seguir un estándar
- Los nombres de los métodos o servicios deben seguir un estándar
- Los nombres de los parámetros que envía un método deben estar claros y
entendible, no deben estar abreviados.
7.3. Definición del Diagrama de Componentes.
7.3.1. Descripción del entorno de desarrollo.
Realizar una breve descripción de las herramientas que se van a utilizar para el
desarrollo de la aplicación, como por ejemplo: Visual Studio 2010, Microsoft SQL
Server 2008 Developer, Photoshop, Desig 4, entre otros.
Adicionalmente, describir los componentes y tipos de archivos
7.3.2. Descripción del lenguaje de programación.
Realizar una breve descripción (Requisitos HW y SW) del lenguaje de programación
que se utilizará para el desarrollo de la aplicación
7.3.3. Descripción del entorno del Gestor de Base de Datos.
Realizar una breve descripción del gestor de base de datos que se va a utilizar durante
el desarrollo de la aplicación.
7.3.4. Diagrama de componentes.
Realizar el Diagrama de Componentes incluyendo las características descritas en
anteriores subtítulos.
7.4. Definición Diagrama de Despliegue.
Esta definición debe incluir los siguientes puntos.
7.4.1. Definición de las características de red para la aplicación.
Definir la topología y protocolos de red que serán utilizados por la aplicación en puesta
en producción.
7.4.2. Definición de los protocolos de comunicación.
Definir los protocolos de comunicación entre los servicios web y la aplicación (HTTP,
NET.TCP, NETPIPE, HTTPS).
7.4.3. Definición de los dispositivos a utilizar en la aplicación.
Definir los distintos dispositivos (Computadoras de cliente, PDA, Servidores,
distribuidores de red, red inalámbrica, router, entre otros)
7.4.4. Diagrama de Despliegue.
Definir el diagrama de despliegue, el cual debe reflejar las definiciones realizadas en
anteriores subtitulos.
8. Conclusiones

9. Recomendaciones

10. Referencias Bibliográficas

11. Bibliografía

12. Anexos

MsC. Ing. Roberto Zamuriano Sotés 6

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.
UNIVERSIDAD PRIVADA DEL VALLE

LISTA DE COMPROBACIÓN PARA LA EVALUACIÓN FINAL

1. ¿En todo el documento se sigue una correcta referencia bibliografía?
2. ¿La referencia bibliografía está de acuerdo con el estándar definido por la universidad?
3. ¿Existen más de diez referencias bibliografías en la fundamentación teórica y justificación
de herramientas?
4. ¿Existe un Índice correctamente elaborado?
5. ¿Los objetivos específicos están correctamente redactados?
6. ¿Existe una descripción completa del problema a resolver?
7. ¿Se describen correctamente los Actores del Negocio?
8. ¿Existe un Diagrama de Casos de Uso del Negocio?
9. ¿Existe por cada Caso de Uso del Negocio un Diagrama de Actividad?
10. ¿Existe un glosario de términos que ayuda a entender la modelación del negocio?
11. ¿Existe un diagrama de Casos de Uso de la Aplicación?
12. ¿Se utilizan correctamente los esteriotipos para el Caso de Uso de la Aplicación?
13. ¿Existe una priorización de casos de uso, donde se puede determinar los ciclos de
desarrollo?
14. ¿Existen dos Casos de Uso de la Aplicación correctamente definidos?
15. ¿Cada Caso de Uso de la aplicación sigue la Plantilla que ayuda a la descripción de estos?
16. ¿Cada Caso de Uso de la aplicación descrito tiene, por lo menos, una sección?
17. ¿Los cursos alternos de los casos de uso de la aplicación definidos, son entendibles y
tienen lo necesario para ser comprendidos por el usurario?
18. ¿Existe una descripción de los requisitos no funcionales que permita identificar el cómo
verificar que se ha cumplido?
19. ¿Existe en el documento el proceso de estimación de esfuerzo con Puntos de Casos de
Uso?
20. ¿En los diagramas de colaboración se puede identificar las interacciones descritas en los
casos de uso?
21. ¿Existe una definición completa del Marco de Trabajo en el documento?
22. ¿Existe un Mapa de Navegación en el documento?
23. ¿Son utilizados correctamente los esteriotipos para la modelación Web?
24. ¿Existe una definición de los Servicios Web que utilizará la aplicación?
25. ¿Están correctamente construidos los diagramas de Secuencia?
26. ¿Por cada Diagrama de Secuencia existe una Realización de Diseño?

MsC. Ing. Roberto Zamuriano Sotés 7

Taller III. Ingeniería de Sistemas Informáticos, UNIVALLE. Grupo de Desarrollo NETVALLE.