Planilla

Proyecto: xxxx
Versión Producto: x.x Cliente: xxxxx
DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE

Plantilla inspirada en el estándar IEEE 1016-2009 y adaptada a las necesidades del curso de Diseño
y Arquitectura de Software
Nombre del Documento: DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE SDD Versión: 1.1
Página: 1
Proyecto: xxxx
Tabla de contenido
1. INTRODUCCIÓN............................................................................................................................................... 3
1.1. OBJETIVO.......................................................................................................................................................... 3
1.2. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS...........................................................................................................3
1.3. AUDIENCIA.........................................................................................................................................................4
1.4. ALCANCE........................................................................................................................................................... 5
2. PRESENTACIÓN DEL PRODUCTO...................................................................................................................... 5
2.1. PROPÓSITO DEL SISTEMA......................................................................................................................................5
2.2.1. Planteamiento del problema........................................................................................................................5
2.2.2. Objetivo........................................................................................................................................................6
2.2.3. Alcance.........................................................................................................................................................6
2.2.4. El Sistema no contempla..............................................................................................................................7
2.2. RIESGOS............................................................................................................................................................ 7
3. DESCRIPCIÓN GENERAL................................................................................................................................... 8
3.1. CONTEXTO DEL PRODUCTO...................................................................................................................................8
3.2. PERSPECTIVAS FUTURAS DEL PRODUCTO...................................................................................................................9
3.3. REGLAS Y FUNCIONES DE NEGOCIO.........................................................................................................................9
4. REQUISITOS.................................................................................................................................................... 9
4.1. FUNCIONALES.....................................................................................................................................................9
4.2. NO FUNCIONALES..............................................................................................................................................10
4.2.1. Tamaño y rendimiento...............................................................................................................................11
4.2.2. Calidad........................................................................................................................................................11
4.2.3. Otros...........................................................................................................................................................11
5. ARQUITECTURA DEL PRODUCTO/SISTEMA..................................................................................................... 11
5.1. VISTA DE CASOS DE USO....................................................................................................................................11
5.1.1. Actores........................................................................................................................................................11
5.1.2. Modelo de casos de Uso.............................................................................................................................12
5.1.3. Lista de casos de Uso..................................................................................................................................13
5.1.4. Descripción de los Casos de Uso.................................................................................................................14
5.2. VISTA FUNCIONAL.............................................................................................................................................16
5.2.1. Modelo de Análisis......................................................................................................................................16
5.2.2. Interfaces con el usuario.............................................................................................................................18
5.3. VISTA LÓGICA...................................................................................................................................................19
5.3.1. Descripción.................................................................................................................................................19
5.3.2. Paquetes de Diseño Arquitectónicamente Significativos...........................................................................21
5.3.3. Vista de Implementación - Componentes...................................................................................................24
5.4. VISTA DE DESPLIEGUE - AMBIENTE FÍSICO..............................................................................................................25
5.5. VISTA DE DATOS...............................................................................................................................................26
5.5.1. Definiciones................................................................................................................................................26
5.5.2. Diseño de Base de Datos............................................................................................................................27
5.6. REQUISITOS DE SOFTWARE/HARDWARE................................................................................................................27
6. CALIDAD....................................................................................................................................................... 28
7. Observaciones...........................................................................................................................................................28
Página: 2
Proyecto: xxxx
1. Introducción
1.1. Objetivo
<Esta sección define el rol o propósito del Documento de Arquitectura, en el contexto de la
documentación general del proyecto, y describe brevemente la estructura del documento.
El texto sugerido es el que se describe a continuación, puede ser ampliado o modificado.>
El texto sugerido es el que se describe a continuación, el mismo puede ser ampliado o

modificado:
Este documento proporciona un resumen general sobre la arquitectura del producto,

utilizando las vistas necesarias de arquitectura para describir los diferentes aspectos del
sistema. Con esto se pretende documentar las decisiones de arquitectura más significativas
que han sido tomadas en cuenta en el proyecto
1.2. Definiciones, Acrónimos y Abreviaturas

<Esta sección debería proveer las definiciones de todos los términos, acrónimos, y
abreviaturas requeridas para interpretar adecuadamente el Documento de Arquitectura.
Se sugiere los siguientes términos, siempre y cuando se utilicen en el punto Audiencia>
<Se debe seguir el siguiente formato:>
Término Definición Alias Abrevia

tura
•
Ejemplo
Término Definición Alias Abrevia

tura
Proceso que permite que los profesores
ingresen las notas de los estudiantes. Se
Registro pueden presentar los siguientes casos: Registro de
de notas• -Nota no ingresada en el sistema notas
• -Nota registrada en el sistema difiere de la
nota de la hoja de resumen de notas.
• -Nota de la evaluación difiere de la hoja de
resumen de notas.
El registro extemporáneo de becas se da
cuando en el Departamento de becas no se
ha ingresado la beca de un estudiante, a
Registro pesar de que este ha cumplido con todos los Asignación de
de beca requisitos que se necesita para aplicar a una beca
beca.
La anulación académica se presenta cuando
Página: 3
Proyecto: xxxx
el estudiante presenta repeticiones en

Anulación determinadas asignaturas (3 en adelante);
académic en esta caso se realiza una autorización para
a hacer la anulación del periodo académico
en el que el estudiante reprobó la asignatura Anular
solicitada para anulación. Se debe tener asignatura
presente que en esta anulación no existe
devolución económica
Digitaliza Proceso por el cual se capturan los datos de Documento
ción un formato físico y se lo expresa datos en digital
forma digital.
Una persona o organización, interna o
externa, quienes tienen la responsabilidad
financiera del sistema. El cliente es el Estudiante
Cliente receptor de los productos desarrollados y sus
entregables. Ver también stakeholder
Una anormalidad dentro de un producto.
Ejemplos como: omisión e imperfecciones
encontradas durante fases tempranas del
ciclo de vida. Un defecto puede ser cualquier
tipo de novedad que se requiera registrar y
Defecto resolverla. Ver también Requerimiento de Error
cambios.
1.3. Audiencia
<Esta sección identifica la audiencia específica esperada para el Documento de
Arquitectura. Para cada uno de los participantes se debe indicar los niveles de
participación.>

Competencias
Criterios de técnicas/
Stakeholder Rol Responsa- Intereses éxito Preocupación Relación de
bilidad ambiente de
trabajo
Ejemplo:

Competencias
Criterios de técnicas/
Stakeholder Rol Responsa- Intereses éxito Preocupación Relación de
bilidad ambiente de
trabajo
Página: 4
Proyecto: xxxx
Rector -Sponsor Aprobar Construya Satisfacer Tiempo de N/A

-Usuario (proyecto) un sistema las construcción
indirecto de acuerdo necesidades de la
a las de los aplicación
normas de estudiantes
la
universidad
Coordinación -Usuario Aprobar Perfeccionar -Trámites - Liberación del
Académica directo proceso y validar los registrados Involucramien- producto.
-Product procesos en cada to de los
champion centro. actores que
-Cada actor intervienen en
realiza las el proceso.
actividades. -No se registre
- de forma
Satisfacción apropiada la
de los información
estudiantes
1.4. Alcance
<Una breve descripción del alcance de este Documento de Arquitectura; que proyecto (s)
están asociados, y cualquier otra cosa que es afectada o influenciada por este documento.
El texto sugerido es el que se describe a continuación, puede ser ampliado o modificado.>
Texto Sugerido:
El Documento de Arquitectura abarca la definición de la arquitectura del producto a través

de las vistas de casos de uso, lógica (análisis y diseño), despliegue e implementación,
también define los procedimientos del usuario a los que deberá dar soporte y el manejo que
se realizará a los datos.
2. Presentación del Producto

2.1. Propósito del Sistema
2.2.1. Planteamiento del problema

<En esta sección deberá indicar el problema existente en la empresa y que ha motivado
la contratación de su grupo de desarrollo de software.>
El problema de <Insertar el planteamiento del problema> afecta <nombre de las

personas afectadas, organización, o grupo de clientes>. El impacto de esto es
<nombre del impacto (por ejemplo, malas decisiones, los sobrecostos, información o
procesos erróneos, tiempo de respuesta lento a los clientes, etc)>.
Ejemplo
Página: 5
Proyecto: xxxx
El problema de la atención de trámites académicos y contables que generan los

estudiantes no tienen una adecuada atención, lo que genera excesiva demora en la
resolución de los mismos debido a que no existe un flujo definido para el envío-
recepción y a la falta de políticas para su ejecución.
Afecta a: Estudiantes, Rector, Director Administrativo Financiero, Coordinación
Académica UG, Decanos, Talento humano, Finanzas, Gestión de Procesos, Atención al
Estudiante y Secretarías.
Cuyo impacto es:
 El promedio de tiempo para resolver un trámite es alto.
 El estudiante requiere mucha gestión para obtener el resultado de su trámite,
causando malestar e insatisfacción.
 Se desperdicia tiempo, en tareas relacionadas a tratar de ubicar un trámite y
conseguir su estado.
 Algunos trámites causan congestión en el proceso de matriculación, pues, al no
poderse resolver ágilmente, los estudiantes deben regresar al centro
universitario varias veces entorpeciendo procesos de trabajo importantes
(Matrículas).
2.2.2. Objetivo
<En esta sección deberá indicar de manera general lo que se pretende lograr con el
desarrollo del sistema. No se incluyen puntos referentes al proyecto, sino especificar el
objetivo del producto a desarrollarse>
Puede hacer uso de la siguiente plantilla:
Para <Cliente objetivo> quien <declaración de la necesidad u oportunidad>, el

<nombre del producto> es un <categoría del producto> que <principales beneficios o
razones convincentes para comprar>.
Ejemplo
Para personal administrativo y estudiantes de la Universidad de Guayaquil, quienes

registran y resuelven los trámites que se generan en cada centro asociado el sistema de
automatización de trámites es una aplicación Web que registra las solicitudes de
trámites directamente en el sistema desde cualquier centro, define un flujo de
documentación desde los centros asociados a la sede central, notifica a las personas
involucradas en el trámite sobre las tareas que debe realizar y permite conocer sobre el
estado de un trámite en cualquier momento.
2.2.3. Alcance
<Se indica en términos generales las funciones que el sistema deberá realizar o los
módulos que contendrá. No se incluye puntos referentes al proyecto, si no especificar el
alcance del producto>
Página: 6
Proyecto: xxxx
Nuestra solución permitirá: <describir la solución>
Ejemplo
Una solución satisfactoria permitirá:

 Que la atención de los casos se realice mediante un sistema de fácil uso, de tal
forma de que se de solución a todos los trámites.
 Que las solicitudes de trámites sean registradas directamente en un sistema.
 Que las solicitudes de trámites fluyan electrónicamente hacia a las diferentes
personas que deban revisarlo antes de su resolución.
 Que la documentación relacionada al trámite esté asociada a éste de forma
digital de manera que pueda ser visualizada directamente en el sistema.
 Que se pueda conocer el estado en que se encuentra un trámite.
 Que se pueda disponer de estadísticas que permitan tomar decisiones para
optimizar los procesos relacionados.
 Que exista seguimiento adecuado de los trámites, estableciendo tiempos de
respuesta.
2.2.4. El Sistema no contempla

<Se indica aspectos funcionales o no funcionales y/o módulos que no estarán incluidos
en el producto. El objetivo de esta sección es dejar expresadas cuestiones que el
producto no cubrirá, al menos hasta el momento>
2.2. Riesgos
<Se indica cualquier aspecto que debe ser considerado para el desarrollo, que puede afectar
al cumplimiento de los requerimientos y que viene dado desde el ambiente del negocio o
acordado con anterioridad. Fundamentalmente se debe destacar cuestiones políticas o
legales del entorno de la organización que puede afectar el éxito del proyecto si no se le
brinda un adecuado tratamiento.>
Estrategia de
Factor de riesgo Probabilidad Impacto mitigación Responsable
Ejemplo:
Estrategia de
Factor de riesgo Probabilidad Impacto mitigación Responsable
Página: 7
Proyecto: xxxx
Falta de Media Alto Llevar a cabo un taller Juan Peralta

disponibilidad de visionamiento con el (Gerente
del rector para actual rector y crear proyecto)
aclarar el modelos de alcance en
alcance el taller.
No Media Alto Llevar a cabo una visita María Piguave
involucramiento (por ejemplo en el lugar (Analista).
del contratista de trabajo hacer el
seguimiento por un
medio día).
Llevar a cabo una
entrevista con el
contratista cada cierto
periodo de tiempo.
Poco interés de Media Bajo Realizar un taller para Juan Peralta
las secretarias indicar (Gerente
de los centros las bondades de un proyecto)
sistema automatizado.
Poco interés de Alto Alto Realizar reuniones Juan Peralta
las secretarias informativas sobre el (Gerente
de escuela nuevo proceso proyecto) y el
automatizado para sponsor del
resolver los trámites de proyecto.
los estudiantes.
3. Descripción General
3.1. Contexto del Producto
<Esta sección debería poner al producto en perspectiva con otros productos relacionados.
Si el producto es independiente y totalmente auto contenido, debería ser especificado aquí.
Si esta especificación de requerimientos define un producto que es un componente de un
sistema más grande, entonces deberían relacionarse los requerimientos de ese sistema
mayor con la funcionalidad de este software y deberían identificarse las interfaces de
comunicación entre el sistema y el software>.
A diferencia de <principal alternativa competitiva, sistema actual, o proceso manual

actual>, nuestro producto <declaración de las diferencias del producto primario>
Ejemplo:
A diferencia del proceso actual que requiere que los trámites existentes tienen que enviarse
de forma física a la universidad, no existe un flujo de actividades debidamente controlado
para cada trámite y tanto el estudiante como los involucrados en el trámite no conocen a
ciencia cierta sobre el estado del mismo.
Página: 8
Proyecto: xxxx
3.2. Perspectivas futuras del producto

<Esta sección identifica requerimientos que pueden demorarse hasta versiones futuras del
sistema>.
3.3. Reglas y Funciones de Negocio

<Se indica la lógica de funcionamiento del negocio mediante el mapeo as is-to be. Para ello,
deberéis adjuntar los diagramas de actividades de cada proceso involucrado en el sistema.
Por cada proceso se debe elaborar un diagrama que muestre tanto su situación actual (as
is) como la situación propuesta (to be)>.
Ejemplo:
Proceso de GESTIÓN DE FONDOS BIBLIOTECARIOS: Situación propuesta (TO BE)
4. REQUISITOS
4.1. Funcionales
<Los requerimientos funcionales definen las acciones fundamentales que realiza el software
al recibir información, procesarla y producir resultados. Normalmente se listan en
afirmaciones del tipo “el sistema debe...”.
En ellas se incluye:
o Comprobación de la validez de las entradas.
o Secuencia exacta de las operaciones.
o Respuesta a situaciones anormales (desbordamientos, comunicaciones,
recuperación de errores).
o Parámetros.
o Relaciones entre entradas y salidas, incluyendo:
 Secuencias de entradas y salidas.
Página: 9
Proyecto: xxxx
 Fórmulas para la conversión de información.
<Se debe mostrar la lista de los requisitos funcionales, describir el detalle necesario. Se debe
seguir el siguiente formato de ejemplo>
Número: RF-# <Ejemplo: RF-1>

Título: Ingreso de cursos
Texto: El sistema permitirá el ingreso de los datos requeridos del curso por parte
de la secretaria de cada facultad.
Tipo: Funcional - Datos
Detalles de El sistema debe mantener la siguiente información sobre los cursos:
requisitos y Título del curso (Ejemplo: SOF-3-IDR)
restricciones: Descripción del curso
Programa de estudios.
Secciones.
Prerrequisitos.
Etc ………….
Fecha de 2/5/2020
revisión y Versión1.0
versión:
Prioridad: <Alta, media o baja>
4.2. No funcionales
<La mayoría de los requerimientos no funcionales son registrados comúnmente en lenguaje

natural en esta sección de especificación. Los requerimientos identificados en esta parte del
documento son aplicables al producto en general. Para el caso de los requerimientos no
funcionales aplicables a un caso de uso en particular se debe aclarar a qué caso de uso se
refiere. Redactar teniendo en cuenta que el RNF pueda ser probado>
<La descripción debe seguir el siguiente formato>

Número: RN-# <Ejemplo: RN-1>
Título:
Texto: El sistema está preparado para ser operado a través de mou-
se y teclado.
Tipo:
Detalles de El sistema debe permitir el uso de:
requisitos y • 1 mouse
restricciones: • 1 teclado.
Fecha de 2/5/2020
Página: 10
Proyecto: xxxx
revisión y Versión1.0
versión:
Prioridad: <Alta, media o baja>
4.2.1. Tamaño y rendimiento

<En esta sección se describen las características volumétricas de definición
arquitectónica y de respuesta del sistema. La información presentada puede incluir: El
número de elementos clave que el sistema tendrá que manejar, Las medidas de
rendimiento clave del sistema, como el tiempo de respuesta medio para sucesos clave;
índices de rendimiento medio, máximo y mínimo, etc. utilización de memoria, disco
duro, etc.>
4.2.2. Calidad
<Contiene las dimensiones de calidad clave del sistema que forma la arquitectura. La
información presentada puede incluir: Requisitos de rendimiento operativo, como
tiempo medio entre anomalías (MTBF), Destinos de calidad, como "tiempo de
inactividad no planificado", Destinos ampliables, como "el software se podrá actualizar
mientras en sistema se esté ejecutando". Destinos con portabilidad, como plataformas
de hardware, sistemas operativos, lenguajes.>
4.2.3. Otros
<Describe como la arquitectura da soporte a cualquier otro requisito no funcional que
exista.>
5. Arquitectura del Producto/Sistema

5.1. Vista de Casos de Uso
5.1.1. Actores
<Se describen los roles, entidades, otros sistemas, dispositivos y cualquier otro “Actor”
con el que el sistema en desarrollo debería interactuar >.
Número: ACT-#
Actor: <nombre del Actor>
Descripción: <descripción del actor>
Responabilidades: • <Responsabilidad 1>

• <Responsabilidad 2>
Fuentes: <Stakeholders que identificaron y contribuyeron a

definir al actor>
Página: 11
Proyecto: xxxx
<Seguir el siguiente formato de ejemplo>
Número: ACT-1
Actor: Profesor
Descripción: Persona responsable de dictar la materia y de ad-
ministrar sus cursos. Es un actor primario.
Responabilidades: El profesor puede realizar lo siguiente:
• Publicar información del curso, tal como: anun-
cios, actividades, tareas, recursos, información ge-
neral, políticas del curso, políticas de calificacio-
nes, etc.
• Agregar o eliminar alumnos al curso y definir sus
ayudantes académicos.
• Publicar las calificaciones de sus estudiantes a tra-
vés de archivos existentes o mediante el ingreso di-
recto al sistema.
• Entre otros.
Fuentes: Gestoría de personal docente
5.1.2. Modelo de casos de Uso

<Se debe incluir aquí el diagrama o diagramas de casos de uso que muestran de
manera gráfica los alcances funcionales del producto>
<Las imágenes deben tener un tamaño que permitan al menos ser entendibles a la
vista del lector, sin mayor esfuerzo (zoom).>
<Se recomienda incluir diagramas por modulo y un diagrama general no extendido.>

Ejemplo:
Página: 12
Proyecto: xxxx
5.1.3. Lista de casos de Uso

<El listado de Casos de Uso contiene el número y nombre de cada caso de uso,
complejidad, prioridad del cliente, prioridad final.>
Ejemplo:
Id Caso de Uso Complejidad Prioridad Prioridad
del cliente Técnica
CU1 Carga de información de Media Alta Alta
medidores
CU2 Carga de información del Alta Alta Alta
CENACE
CU3 Carga de información Web Media Alta Alta
Services
CU4 Calcular diferencia de Alta Alta Media
mediciones
CU5 Calcular factor de participación Baja Media Alta
CU6 Calcular valor de contratos Media Alta Alta
CU7 Calcular energía de contratos Alta Media Media
CU8 Calcular liquidaciones Baja Alta Alta
Página: 13
Proyecto: xxxx
CU9 Ingresar al sistema Baja Baja Baja

CU10 Registrar Agentes Baja Alta
CU11 Registrar puntos de medición Baja Alta
CU12 Registrar novedades de Media Baja
mediciones
CU13 Registrar datos de contratos Baja Media
CU14 Registrar días feriados Baja Alta
CU15 Generar meses Baja Alta
5.1.4. Descripción de los Casos de Uso

<Detallar brevemente los casos de uso más relevantes. Recordar que en el curso de
Ingeniería de Requerimientos se llevó a cabo un detalle completo de cada caso de uso.
>
<Detallar todos los casos de uso confeccionados a través de la siguiente plantilla:>
IDENTIFICADOR CASO DE USO: NOMBRE:

CU-# <El # corresponde a un número <Nombre corto del caso de uso>
consecutivo para la diferenciación de los casos
de uso.>
COMPLEJIDAD: PRIORIDAD:
[Baja] - [Media] - [Alta] [Baja] - [Media] - [Alta]
REQUERIMIENTO FUNCIONAL ASOCIADO:
<Indicar claramente el requerimiento respetando el identificador asignado en el documento de
requerimientos.>
ACTORES:
<Indicar los actores del sistema que están asociados con el caso de uso>
CASOS DE USO ASOCIADOS:
<Indicar la asociación de este caso de uso con otros, teniendo en cuenta sus relaciones:
 No Aplica
 Se Extiende a [Caso de uso asociado (Incluyendo su ID]
 Se Extiende de [Caso de uso asociado]
 Incluye a [Caso de uso asociado]
 Incluido en [Caso de uso asociado]
>
DESCRIPCIÓN:
<Escribir un párrafo corto que explique en términos generales la descripción del caso de uso. En
el mismo se deben indicar las consideraciones necesarias para que se lleve a cabo el caso de uso>
NOTAS:
<Consideraciones necesarias para que se lleve a cabo el caso de uso.>
CRITERIOS DE ACEPTACIÓN: <Los criterios que debe ser cumplidos>
Ejemplo: El permiso de acceso al aplicativo es adicionado/modificado/eliminado exitosamente
del aplicativo.
ESCENARIOS:
Página: 14
Proyecto: xxxx

de uso.>
ES-#.id DESCRIPCIÓN: <Frase corta que describa claramente el escenario.>
SUPOSICIONES/ASUNCIONES: <listar aquellas condiciones que se dan por cumplidas
en el escenario a describir>
RESULTADOS: <listar aquellas condiciones que se dan por cumplidas en el escenario a
describir>
ES-#.id DESCRIPCIÓN: <Frase corta que describa claramente el escenario.>

SUPOSICIONES/ASUNCIONES: <listar aquellas condiciones que se dan por cumplidas
en el escenario a describir>
RESULTADOS: <listar aquellas condiciones que se dan por cumplidas en el escenario a
describir>
REQUERIMIENTOS ESPECIALES - REGLAS DEL NEGOCIO Y DEL SISTEMA:

<
 En esta sección incluir las reglas de negocio y del sistema aplicables a este caso de uso y que
se especificaron en la sección 3.3 del presente documento>
 Incluir también los requerimientos especiales y condiciones particulares del caso de uso.
Nota: Tener en cuenta la siguiente definición:

 Requerimiento especial: Condiciones particulares que han de cumplirse en el caso de uso:
Ejemplo: La forma de Calcular un dato de salida de un reporte.
Ejemplos:
1. Ver regla del negocio asociada: [ID Regla del Negocio]

2. Ver regla del sistema asociada: [ID Regla del Negocio]
3. Requerimiento Especial: Después de actualizar la información de la ejecución de compromiso

el sistema deberá realizar las siguientes actualizaciones de forma automática:
a. Actualizar estado de avance del compromiso de acuerdo al valor asignado al campo

de entrada 1: Si el porcentaje es igual 0% el estado es pendiente, si el porcentaje está
entre 1% y 99% el estado es En Proceso, si el porcentaje de avance es 100% el estado
es cumplida.
b. Actualizar porcentaje de avance de la recomendación: El porcentaje de avance de las

recomendaciones corresponde al promedio de los porcentajes de avance de los com-
promisos asociados a la recomendación. De igual forma se debe actualizar el estado
de la recomendación según el porcentaje a avance establecido (Aplican los mismos
rangos y estados de los compromisos)
c. Actualizar porcentaje de avance de los hallazgos: El porcentaje de avance de las reco-

mendaciones corresponde al promedio de los porcentajes de avance de los compromi-
sos asociados a todas las recomendaciones del hallazgo. De igual forma se debe ac-
Página: 15
Proyecto: xxxx

de uso.>
tualizar el estado de la recomendación según el porcentaje a avance establecido (Apli-
can los mismos rangos y estados de los compromisos). Adicionalmente actualizar la
fecha final de cumplimiento del hallazgo cuando el estado cambie a cumplido.
RIESGOS:
<Incluir los riesgos que puedan causar que la funcionalidad del caso de uso no se ejecute
correctamente.>
Ejemplo
 No se cuente con el usuario o permisos requeridos para el registro/actualización de la infor-
mación en el sistema.
 Si no existen riesgos asociados a la funcionalidad colocar “NO APLICA”
PROTOTIPO EXPLORATORIO
<Si el Storyboard se trabaja con pantallazos este es el espacio para colocarlo, si se realiza el
storyboard con html se coloca aquí el nombre del html y la forma de llegar a la funcionalidad que
se está describiendo.>
5.2. Vista Funcional
5.2.1. Modelo de Análisis
<Esta sección ilustra cómo trabaja realmente el software mostrando los diagramas de
colaboración y/o de secuencia y/o actividades de los casos de uso planteados en la
sección 5.1.4 y explicando cómo los elementos del modelo contribuyen a su
funcionalidad. Puede ser a través de casos de uso (o escenarios)>
<Las imágenes deben tener un tamaño que permitan al menos ser entendibles a la vista
del lector, sin mayor esfuerzo (zoom).>
<Referenciar cada diagrama con el caso de uso y escenario al que hace referencia
siguiendo el siguiente formato:>
ID Ref: DG-# donde # debe ser reemplazado por un nº
Descripción: <Título del caso de uso y escenario>
Reqs. asociados:
CU asociados:
Esc. Asociados:
Ejemplo
ID Ref: DG-1
Descripción: Reserva exitosa de una habitación de hotel.
Reqs. asociados: RF-1
CU asociados: CU-1
Esc. DOCUMENTO
Nombre del Documento: Asociados: DE DISEÑO
ES-1.1DETALLADO DE SOFTWARE SDD Versión: 1.1
Página: 16
Proyecto: xxxx
Diagrama de Colaboración
Diagrama de Secuencia
Página: 17
Proyecto: xxxx
Diagrama de Actividades
Diagrama de Estados
5.2.2. Interfaces con el usuario

<Define las características lógicas de cada interfaz entre el producto del software y sus
usuarios. Esto incluye las características de la configuración (por ejemplo, formatos de la
pantalla requeridos, página o esquemas de la ventana, los reportes o menús o
disponibilidad de llaves de la función programables) necesario para lograr los requisitos
del software>.
<Se debe Referenciar cada interfaz con el caso de uso y escenario al que hace referencia
siguiendo el siguiente formato:>
Página: 18
Proyecto: xxxx
ID Ref:
Descripción:
Reqs. asociados:
CU asociados:
Esc. Asociados:
Ejemplo:
ID Ref: UI-01
Descripción: Consulta de pagos atrasados
Reqs. asociados: RF-1, RN-3
CU asociados: CU-1
Esc. Asociados: ES-1.1
5.3. Vista Lógica

<Esta sección describe las partes del modelo de diseño significativas arquitectónicamente,
tales como su descomposición en subsistemas y paquetes. Y por cada paquete significativo
su descomposición en clases y utilidades de clases. Debería introducir las clases
significativas arquitectónicamente y describir sus Responsabilidades, así como también
unas pocas relaciones, operaciones y atributos muy importantes>
5.3.1. Descripción
<Esta sección describe la descomposición general del modelo de diseño en términos de
jerarquías de paquetes y capas. Se puede hacer referencia al diagrama UML si aplica>
Texto de ejemplo.
El diseño del sistema respeta el Modelo MVC (Model, View, Controller)
Página: 19
Proyecto: xxxx
Capa de Base de Datos (Model), se encarga de almacenar toda la información, y tenerla

disponible para cualquier aplicación.
Para esta capa se utilizará como motor de base de datos Oracle 10g. Y como modelo de
persistencia se utiliza….
Capa de Aplicaciones (View y Controller), Donde se instalan todas las aplicaciones, y son
publicadas tanto para los usuarios internos, como los usuarios que ingresan desde
Internet. Escucha requerimientos de los usuarios, y responde, con una página Web
sencilla, o con una aplicación que se conecta a la base de datos para consultas y/o
modificaciones.
Para esta capa se utilizará Oracle Aplication Server 10g donde se montarán los .jsp que
implementan tanto las interfaces de usuario como las lógicas de control necesarias. Para
la comunicación entre el servidor de aplicaciones y el motor base de datos se utilizará…
con la intención de tener un mejor manejo de las conexiones a la base de datos.
Capa de usuario o cliente (View), es un cliente liviano, No requiere equipos grandes,

únicamente requiere tener un explorador de Internet (Ver Requerimientos No
Funcionales), desde el cual se conecta al servidor de aplicaciones para hacer consultas y
transacciones a la BD mediante los sistemas desarrollados.
Para esta capa se utilizará JSP.
La ventaja de este tipo de arquitecturas es que las aplicaciones están en un sólo punto, lo
que permite que los administradores sólo hagan cambios en el servidor de aplicaciones y
no así en cada uno de los equipos clientes. Asegura la escalabilidad y alta disponibilidad.
Página: 20
Proyecto: xxxx
Vista lógica MVC (diseño de un sitio web de un club deportivo)
5.3.2. Paquetes de Diseño Arquitectónicamente Significativos
<Un paquete de clases es una forma de organizar un grupo de clases relacionadas. Un

paquete de clases funge como un contenedor de clases. Las clases en un paquete pueden
estar relacionadas a partir de diferentes criterios: aspecto del dominio del problema que
modelan, tipo de servicio que proporcionan, tipo de capa lógica donde se ubican, etc.>
<Un paquete (package en Java) representa un conjunto de clases correlacionadas. Es

posible definir una clase como perteneciente a un cierto package. Así como existe una
estrecha correspondencia entre clase y file, también existe una estrecha correspondencia
entre package y directorio. Por lo tanto, en general un package de nombre X es
representado por un directorio de nombre X, donde X es una cadena con todos los
caracteres en minúscula (por convención).>
<Ejemplo: >
Página: 21
Proyecto: xxxx
Diagrama de paquetes propuesto durante el diseño de un sistema Web de

reservaciones y ventas de vuelos y hotel
<Para cada paquete significativo, incluir una sección con su nombre, una breve
descripción, y un diagrama con todas las clases y paquetes significativas contenidos en el
paquete.>
<Para cada clase significativa del paquete, incluir su nombre, una breve descripción, y,
opcionalmente una descripción de sus responsabilidades principales, operaciones y
atributos>
Paquete <xxxxx 1>: Clases contenidas: Ver Diagrama de Clase <zzzzzz 1>.
Paquete <xxxxx 2>: Clases contenidas: Ver Diagrama de Clase <zzzzzz 2>.
Paquete <xxxxx ..>: Clases contenidas: Ver Diagrama de Clase <zzzzzz …>.
O Insertar el Diagrama de Clases.

Ejemplo:
Página: 22
Proyecto: xxxx
<Para cada diagrama de clases debéis indicar el posible orden de implementación de las
clases (e idealmente, hacer las pruebas de unidad completamente) desde la menos a la
más acoplada (ver siguiente Figura). Por ejemplo, las posibles primeras clases que
podríamos implementar son Pago o EspecificacionDelProducto; a continuación las clases
que sólo dependen de la implementación anterior —Catalogo-DeProductos o
LineaDeVenta>
Página: 23
Proyecto: xxxx
5.3.3. Vista de Implementación - Componentes

<Esta sección describe los componentes y los archivos que el sistema utiliza para
ensamblar y hacer disponible el sistema físico, la estructura completa, la descomposición
del software en capas y subsistemas en el modelo de implementación y cualquier
componente arquitectónicamente significativo. Se utiliza el diagrama de componentes
para reflejar la relación entre los mismos y los diagramas dinámicos para reflejar cómo
interactúan entre sí. Se puede hacer referencia a los diagramas UML correspondientes>
Referenciar o insertar el Diagrama de Componentes
Página: 24
Proyecto: xxxx
5.4. Vista de Despliegue - Ambiente Físico

<Esta sección describe una o más configuraciones físicas de red (hardware) sobre las cuales
el software es distribuido y ejecutado. Como mínimo para cada configuración indicar los
nodos físicos (computadoras, CPUs) que ejecutan el software, y sus interconexiones (bus,
LAN, punto a punto, etc.) También incluir un mapeo de los procesos desde la Vista de
Procesos en los nodos físicos.>
Referenciar o insertar el Diagrama de Despliegue
Página: 25
Proyecto: xxxx
5.5. Vista de Datos
5.5.1. Definiciones
<Describe todos los ítems de datos incluidos en el producto o sistema. Puede ser desde
una base de datos hasta archivos de datos como xml, etc. Para ello puedes hacer uso del
siguiente diccionario de datos:>
NOMBRE OBJETO: <nombre del objeto a crear>

DESCRIPCION: <descripción del propósito del objeto>
Página: 26
Proyecto: xxxx
Columnas:
PK Nombre Tipo No Nulo Único Longitud Precisión Escala Inicial Notas
Relaciones:
Columnas Asociación Notas
<Modelo de datos del sistema con sus respectivas entidades, relaciones y atributos>
5.5.2. Diseño de Base de Datos

<Especificar el diagrama general de toda la aplicación. Acá se especifican todos los
elementos, relaciones y diagramas de UML desde un punto de vista totalizador. Ejemplo:
diagrama de clases de toda la aplicación - DER>
Referenciar el diagrama entidad relación y/o el diccionario de datos
5.6. Requisitos de Software/Hardware

<Especifique las estimaciones de capacidad iniciales de recursos computacionales
críticos.>
Página: 27
Proyecto: xxxx
Equipamiento y Configuración:
Servidor de Aplicaciones
- Sistema Operativo Linux, tenemos el RedHat Enterprise Linux Server 5.4
- Servidor de Aplicaciones Jboss As 6.0.0.final
- JDK 1.6.0_23 o superior
- Intel Xeon x5570 de 2 procesadores
- Memoria 8 GB, 4 GB reservado
- Disco 30 GB]
6. Calidad
<Una descripción de como la arquitectura del software contribuye con todas las capacidades
del sistema (además de la funcionalidad): extensibilidad, confiabilidad, portabilidad, etc.>
Texto sugerido:
Dado a la estructura relativamente simple del sistema, principalmente son extraer e

ingresar entidades en la Base de Datos, este no debería presentar fallas al momento de
ejecutar de los diversos servicios que ofrece. La calidad del sistema dependería
principalmente de la funcionabilidad del servidor web, del manejador de Base de Datos y su
comunicación entre ellos.
7. Observaciones
<Esta sección permite incorporar cualquier información que se considera de importancia, que
no haya sido especificada con anterioridad>
Página: 28

Planilla

Cargado por

Información del documento

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

Planilla

Cargado por

Copyright:

Formatos disponibles

Proyecto: xxxx

Versión Producto: x.x Cliente: xxxxx

DOCUMENTO DE DISEÑO DETALLADO DE SOFTWARE

El texto sugerido es el que se describe a continuación, el mismo puede ser ampliado o

Este documento proporciona un resumen general sobre la arquitectura del producto,

1.2. Definiciones, Acrónimos y Abreviaturas

<Se debe seguir el siguiente formato:>

Término Definición Alias Abrevia

Término Definición Alias Abrevia

el estudiante presenta repeticiones en

<Se debe seguir el siguiente formato:>

Rector -Sponsor Aprobar Construya Satisfacer Tiempo de N/A

El Documento de Arquitectura abarca la definición de la arquitectura del producto a través

2. Presentación del Producto

2.2.1. Planteamiento del problema

El problema de <Insertar el planteamiento del problema> afecta <nombre de las

El problema de la atención de trámites académicos y contables que generan los

Puede hacer uso de la siguiente plantilla:

Para <Cliente objetivo> quien <declaración de la necesidad u oportunidad>, el

Para personal administrativo y estudiantes de la Universidad de Guayaquil, quienes

Puede hacer uso de la siguiente plantilla:

Nuestra solución permitirá: <describir la solución>

Una solución satisfactoria permitirá:

2.2.4. El Sistema no contempla

<Se debe seguir el siguiente formato:>

Falta de Media Alto Llevar a cabo un taller Juan Peralta

Puede hacer uso de la siguiente plantilla:

A diferencia de <principal alternativa competitiva, sistema actual, o proceso manual

3.2. Perspectivas futuras del producto

3.3. Reglas y Funciones de Negocio

 Fórmulas para la conversión de información.

Número: RF-# <Ejemplo: RF-1>

<La mayoría de los requerimientos no funcionales son registrados comúnmente en lenguaje

<La descripción debe seguir el siguiente formato>

4.2.1. Tamaño y rendimiento

5. Arquitectura del Producto/Sistema

Actor: <nombre del Actor>

Descripción: <descripción del actor>

Responabilidades: • <Responsabilidad 1>

Fuentes: <Stakeholders que identificaron y contribuyeron a

<Seguir el siguiente formato de ejemplo>

5.1.2. Modelo de casos de Uso

<Se recomienda incluir diagramas por modulo y un diagrama general no extendido.>

5.1.3. Lista de casos de Uso

CU9 Ingresar al sistema Baja Baja Baja

5.1.4. Descripción de los Casos de Uso

<Detallar todos los casos de uso confeccionados a través de la siguiente plantilla:>

IDENTIFICADOR CASO DE USO: NOMBRE:

IDENTIFICADOR CASO DE USO: NOMBRE:

ES-#.id DESCRIPCIÓN: <Frase corta que describa claramente el escenario.>

REQUERIMIENTOS ESPECIALES - REGLAS DEL NEGOCIO Y DEL SISTEMA:

Nota: Tener en cuenta la siguiente definición:

1. Ver regla del negocio asociada: [ID Regla del Negocio]

3. Requerimiento Especial: Después de actualizar la información de la ejecución de compromiso

a. Actualizar estado de avance del compromiso de acuerdo al valor asignado al campo

b. Actualizar porcentaje de avance de la recomendación: El porcentaje de avance de las

c. Actualizar porcentaje de avance de los hallazgos: El porcentaje de avance de las reco-

IDENTIFICADOR CASO DE USO: NOMBRE:

5.2. Vista Funcional

5.2.1. Modelo de Análisis

5.2.2. Interfaces con el usuario

5.3. Vista Lógica

Capa de Base de Datos (Model), se encarga de almacenar toda la información, y tenerla

Capa de usuario o cliente (View), es un cliente liviano, No requiere equipos grandes,