Junio de 2017 SDD Documento

de Diseo del
Sistema
Versin 1.0

Jose Alonso Oviedo Monroy, Mauro Andrs Reyes,

Edna Paola Osorio, Oscar Ivn Parra
GESICOM
Historial de cambios

Seccin
Versin Fecha Descripcin Responsables
modificada
Creacin de portada, tabla
0.1 8/05/2017 1
historial de cambios.
Descripcin Global de la
0.2 11/05/2017 1, 2
Arquitectura
0.3 12/05/2017 2 Adicin de nuevas secciones
Elaboracin del Plan de
0.4 15/05/2017 2 Jose Alonso Oviedo
Riesgos
Mauro Andrs Reyes
0.5 16/05/2017 2, 3 Adicin de nuevas secciones
Edna Paola Osorio
0.6 17/05/2017 3 Adicin de nuevas secciones
Oscar Ivn Parra
Adicin del Diagrama de
0.7 19/05/2017 4
Clases
Elaboracin de Diagramas de
0.8 16/06/2017 4
colaboracin
Elaboracin de Diagramas de
0.9 23/06/2017 5
Secuencia
1 Introduccin
1.1 Descripcin del sistema

En esta primera seccin se realiza una descripcin a nivel general de la arquitectura de la

herramienta, as como, de los usuarios objetivos para los cuales esta destinada.

La poblacin objetivo son los instructores y algunos administrativos del Centro de Comercio
y Servicios del SENA Regional Tolima, usuarios que deben tener conocimientos bsicos del
manejo de herramientas informticas. Los usuarios podrn hacer uso de la herramienta
tanto en sus computadores de escritorio como en dispositivos mviles con sistema
operativo Android. El sistema interacta con la base de datos alojada remotamente en el
servidor Gesicom del mismo centro.

El sistema est conformado por 2 grandes aplicativos, el primero desarrollado para

Windows en donde se realizar la administracin del sistema, y el segundo desarrollado
para web y dispositivos mviles Android que permita realizar los informes de acceso a los
ambientes de formacin del centro. Las restricciones generales para poder cumplir con los
requerimientos de esta arquitectura son descritas en la seccin 2.4 del documento SRS 1.0.

1.2 Mapa de diseo

En esta seccin se listan cules fueron los tipos de diagramas a travs de los cuales se defini
el diseo del sistema, de acuerdo a las categoras propuestas en la plantilla SDD de
IRONWORKS (Pontificia Universidad Javeriana, 2008), pero adaptada a las necesidades as:

Diseo de alto nivel

o Diagramas de actividad y de secuencia
Diseo de bajo nivel
o Diagrama de clases
o Diagrama Entidad Relacin
GUI
o rbol de navegabilidad

1.3 Referencias y documentos de apoyo

Pontificia Universidad Javeriana. (2008). Plantilla SDD.

Booch, G., Rumbaugh, J., & Jacobson, I. (2004). El lenguaje unificado de modelado. Prentice
Hall.

Arana, J. R., Villa, L. A., & Polanco, O. (2013). Implementacin del control de acceso
a la red mediante los protocolos de autenticacin, autorizacin y auditora.
 Arguello Fuentes, H. (2011). Sistemas de reconocimiento basados en la imagen
facial.

Kim, D., & Solomon, M. G. (2012). Fundamentals of Information Systems Security.

Rodrguez Uribe, J. C., Ruiz Marn, M., & Olivares Morales, J. C. (2009). Una mirada a
la biometra.

Institute of Electrical and Electronics Engineers. (1998). IEEE Recommended Practice

for Software Requirements Specificacitions.

1.4 Definiciones, acrnimos y abreviaturas

Trmino Descripcin
Software Design Document. Documento de
Diseo del Sistema. Documento donde se
explica desde diferentes niveles y desde
SDD diferentes entregables el diseo de la
aplicacin, sus componentes y la manera
en como las funcionalidades se llevan a
cabo.
Producto de software resultado de una
Artefacto
serie de actividades.
Definen el comportamiento interno del
software: clculos, detalles tcnicos,
manipulacin de datos y otras
Requerimientos funcionales
funcionalidades especficas que muestran
cmo los casos de uso sern llevados a la
prctica.
Especifican criterios que pueden usarse
Requerimientos no funcionales para juzgar la operacin de un sistema en
lugar de sus comportamientos especficos.
Todas aquellas personas u organizaciones
Stakeholders que afectan o son afectadas por el
proyecto.
Palabra utilizada para describir la situacin
Supuesto que se presentara si no se implementara
un requerimiento.
Papel que representa a las personas que
Usuario interactan en forma directa con el sistema
cuando realizan su trabajo.
2 Consideraciones de diseo
2.1 Suposiciones

En este apartado se describen las suposiciones y dependencias identificadas para la

elaboracin de un diseo consistente, completo y correcto del sistema. A continuacin, se
agrupan estas suposiciones en tres grupos generales:

Tabla 1. Suposiciones y Dependencias.

Grupo Suposiciones y dependencias
Se cuenta con un sensor biomtrico
multimodal lector de huellas digitales,
rostro y tarjetas RFID.
Se cuenta con las plataformas
Equipo de desarrollo
necesarias para el desarrollo de la
aplicacin y la realizacin de pruebas.
Se cuenta con el apoyo de
herramientas CASE.
Los equipos en los cuales se ejecutara
la aplicacin tienen el hardware
requerido, el cual se encuentra descrito
Equipos (computadores)
en la seccin 2.5 del documento SRS 1.0
Los equipos contarn con conexin a
internet.
No se realizarn modificaciones sobre
los requerimientos funcionales del
Cliente
sistema durante el desarrollo de la
aplicacin.

2.2 Restricciones

2.2.1 Restricciones generales

La aplicacin estar desarrollada nicamente en el idioma espaol.

La tolerancia a fallos en la herramienta no ser tenida en cuenta para esta versin.

2.2.2 Restricciones de usuario

Manejo bsico de un computador.

2.2.3 Restricciones de software

En la seccin 2.4 del SRS 1.0 estn descritas las restricciones de software necesarias para el
desarrollo y ejecucin de la aplicacin.

2.2.4 Restricciones de hardware

En la seccin 2.4 del SRS 1.0 estn descritas las restricciones de software necesarias para el
desarrollo y ejecucin de la aplicacin.

2.3 Entorno del sistema

A continuacin, se muestra una tabla con el resumen de las caractersticas tanto del
software como del hardware, las cuales son indispensables para el completo y correcto
funcionamiento de la aplicacin una vez instalada.

Tabla 2. Requerimiento de software y hardware.

Servidor
Hardware
Procesador Intel Xeon C3
Disco Duro 10GB libres
RAM 16GB
Software
Sistema Operativo Windows server 2012 R2 o superior
Cliente web
Hardware
Disco Duro 500MB libres
RAM 2GB
Software
Sistema Operativo Indiferente
Navegador Web Internet Explorer, Chrome, Mozilla
Cliente Mvil
Hardware
Disco Duro 50MB libres
RAM 512KB
Software
Sistema Operativo Android 4.4 o superior

Adems, cabe mencionar lo siguiente:

Como una observacin adicional, la herramienta ser alojada en Google Play Store.
 La aplicacin utilizara routers, hubs o switches, dependiendo de la infraestructura
de la red mediante la cual establezca conexin con internet

2.4 Metodologa de diseo

La arquitectura a utilizar para el desarrollo del prototipo es la de Stand-alone.

2.4.1 Modelo en cascada

Es un proceso secuencial, fcil de desarrollo en el que los pasos de desarrollo son vistos
hacia abajo (como en una cascada de agua) a travs de las fases de anlisis de las
necesidades, el diseo, implantacin, pruebas (validacin), la integracin, y mantenimiento.

Los principios bsicos del modelo de cascada son los siguientes:

El proyecto est dividido en fases secuenciales, con cierta superposicin aceptable

entre fases.
Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin
de todo un sistema de una sola vez.
Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin
de una amplia documentacin escrita, as como a travs de comentarios y
aprobacin por el usuario y la tecnologa de la informacin de gestin al final de la
mayora de las fases antes de comenzar la prxima fase.

2.4.2 Metodologa OMT (Tcnica de modelado de objetos)

Esta metodologa, propuesta por Booch, Rumbaugh, & Jacobson (2004), describe cuatro
pasos que llevan al diseo requerido para este tipo de aplicaciones:

1. Anlisis: Es la fase que se dedica a la comprensin y modelado de la aplicacin y del

dominio en el cual funciona. La entrada inicial de esta fase es una descripcin del
problema que hay que resolver. La salida del anlisis es un modelo formal que
captura los tres aspectos esenciales del sistema: Los objetos y sus relaciones, el flujo
dinmico de control, y la transformacin funcional de datos que estn sometidos a
restricciones.

2. Diseo del sistema: Es la fase en la cual se determina la arquitectura global del

sistema. Tambin se organiza el sistema en subsistemas utilizando el modelo de
objetos como gua. Se toman decisiones globales acerca de la comunicacin entre
procesos, almacenamiento de dato.
 3. Diseo de objetos: En esta fase se elaboran los modelos de anlisis, se refinan, y
despus se utilizan para producir un diseo practico a un nivel ms detallado. Se
determina la implementacin de cada asociacin y de cada atributo.

4. Implementacin: En esta fase las clases de objetos y las relaciones planteadas en

los diagramas, son trasladados finalmente a un lenguaje de programacin concreto.

2.5 Riesgos

Se ha realizado una tabla con los riesgos de diseo identificados, la cual se presenta a
continuacin.

Tabla 3. Riesgos de diseo identificados

ID Riesgo
R-01 Cambio de algn detalle en un diagrama del cual dependen otros diagramas
R-02 Prdida de los diagramas
R-03 Prdida de los cambios realizados en los diagramas
R-04 Ataque de virus en la informacin de los diagramas y su documentacin
R-05 Cambio de requerimientos que implique cambios de los diagramas
R-06 Incoherencia entre los diagramas y el prototipo
R-07 Encontrar errores en el diseo en el momento de la implementacin

La siguiente tabla clasifica los riesgos identificados anteriormente de acuerdo a su

probabilidad de ocurrencia, y a partir de la misma, el impacto generado en el proceso.

Tabla 4. Clasificacin del riesgo.

Rango Probabilidad Impacto
1 Muy baja Ninguno
2 Baja Bajo
3 Media Medio
4 Alta Severo
5 Muy alta Trgico

En la Tabla 5, se califica a cada uno de los riesgos identificados de acuerdo a los criterios
planteados en cuanto a probabilidad e impacto.
 Tabla 5. Criticidad de los Riesgos.
Riesgo Probabilidad Impacto Criticidad
R-01 4 4 8
R-02 2 5 7
R-03 3 3 6
R-04 1 4 5
R-05 3 3 6
R-06 4 4 8
R-07 3 3 6

A continuacin, se describen las acciones para la mitigacin de los riesgos, ya sea para
prevenirlos o para corregirlos.

Tabla 6. Plan de control de riesgos.

Riesgo Controles
Preventivos Correctivos
R-01 N. A. Hacer los respectivos
cambios en los diagramas
que cambian,
inmediatamente se
identifica el error a
corregir.
R-02 Definir mas de un sitio en Realizar nuevamente los
donde se guardaran los diagramas faltantes de
diagramas (localmente, en acuerdo a lo elaborado
la nube o en algu n medio anteriormente. Realizarlos
extrai ble). inmediatamente luego de
su perdida.
R-03 Realizar el correspondiente Realizar los cambios en
control de versiones de los todos los diagramas desde
diagramas en cada uno de la u ltima versio n aprobada.
los repositorios.
R-04 Igual control que con R-02, Identificar la ltima versin
adems de contar con limpia para continuar desde
licencia de antivirus. ese punto.
R-05 N. A. Realizar las modificaciones
pertinentes en los
diagramas de acuerdo a los
cambios surgidos en los
requerimientos.
R-06 Realizacin de un muy Modificacin del prototipo
buen diseo. segn los cambios
 realizados en los
diagramas.
R-07 Realizacin de un muy Correccin del diseo para
buen diseo. modificar el prototipo.
3 Arquitectura
3.1 Apreciacin global

Este documento presenta la arquitectura como una serie de vistas basadas en la

arquitectura de software del modelo 4+1 de Kruchten. Estas vistas son: la vista de
escenarios, la vista lgica, la vista de desarrollos, la vista fsica y la vista de procesos. No hay
ninguna vista separada de una misma implementacin, descrita en este documento. Estas
vistas estn hechas sobre Lenguaje de modelo unificado (UML) en su versin 2.0
desarrolladas StarUML versin 2.8.0.

3.2 Identificacin de los Stakeholders

Tabla 7. Identificacin de Stakeholders

Stakeholder Descripcin Vistas
Es la persona encargada de CU Autenticar usuario
la administracin del CU Sincronizar datos
Administrador sistema, esto es, ingresar, CU Administrar el sistema
editar y dar de baja a los
usuarios.
Es la persona que orienta CU Autenticar usuario
Instructor
procesos formativos.
Es la persona que recibe CU Autenticar usuario
Aprendiz formacin profesional
integral
Es la persona autorizada CU Generar informes
para ver y generar los
Consulta
reportes de acceso al
ambiente de formacin
Es la persona encargada de CU Autenticar usuario
Vigilante la seguridad del ambiente
de formacin
3.3 Diagrama de casos de uso

Figura 1. Diagrama de casos de uso del sistema.

Fuente: Los autores.

3.4 Diagrama de componentes

Figura 2. Diagrama de componentes del sistema.

Fuente: Los autores.

4 Diseo de alto nivel
4.1 Diagramas de comportamiento e interaccin

4.1.1 Diagramas de secuencia

Los siguientes son los diagramas de secuencia correspondientes a los casos de uso arriba
enunciados.

Figura 3 Diagrama de secuencia Autenticar Administrador.

Fuente: Los autores.

Figura 4. Diagrama de secuencia Registrar usuario.

Fuente: Los autores.

 Figura 5. Diagrama de secuencia Editar usuario.

Fuente: Los autores.

Figura 6. Diagrama de secuencia Eliminar usuario.

Fuente: Los autores.

Figura 7. Diagrama de secuencia Administrar el sistema.

Fuente: Los autores.

 Figura 8. Diagrama de secuencia Sincronizar datos.

Fuente: Los autores.

Figura 9. Diagrama de secuencia Generar informe.

Fuente: Los autores.

5 Diseo de bajo nivel
5.1 Diagrama de clases

Se ilustran tres diagramas de clases el primero, en la Figura 10, revela los estereotipos de
las clases para el aplicativo del servidor Windows y el segundo, en la Figura 11, ensea los
estereotipos para los aplicativos de consulta (web y mvil), el restante es el diagrama de
clases entidad con sus atributos.

Figura 10.Diagrama de anlisis para aplicativo de escritorio.

Figura 11. Diagrama de anlisis para aplicativos web y mvil.
 Figura 12. Diagrama de clases del sistema con atributos.

Fuente: Los autores.

5.1.1 Modelo Entidad Relacin de la base de datos

Figura 13. Diagrama de clases del sistema con atributos.

Fuente: Los autores.