Desarrollo de Sistemas de Información

as
rrollo de Sistem
Anlisis y Desa
n.
de Informaci
i
c
a
Inform
o
ll
o
r
r
a
s
e
d
e
d
o
t
Procedimien
SENA
ADSI
Fase de Desarrollo
Ao 2013 - Edcin 01
Procedimiento de desarrollo
s
a
m
e
t
Sis DE
FAVA - Formacin en Ambientes Virtuales de Aprendizaje
SENA - Servicio Nacional de Aprendizaje
Procedimiento de desarrollo de Sistemas de informacin
Contenido
1.
Objetivo
2.
Alcance
3.
Fases
4.
Especificacin de cada fase
4.1. Fase de Definicin de los requerimientos
4.2. Fase de Anlisis
4.2.1.
Estudio del entorno tecnolgico
4.2.2.
Eleccin de la Arquitectura de Desarrollo
4.2.3.
Diagramas de Anlisis del Sistema
4.3. Fase de Diseo
4.3.1.
Diseo de la Base de Datos
4.3.2.
Diseo de Archivos (Diccionario de Datos)
4.3.3.
Diseo de Entradas y Salidas
4.3.4.
Diseo de Casos de Uso
4.3.5.
Diseo de Clases
4.3.6.
Diseo de Interface
4.3.7.
Diseo de Navegabilidad
4.3.8.
Diseo de Seguridad y Control
4.4. Fase de Construccin
4.4.1.
Relacin con el diseo
4.4.2.
Uso de convenciones durante la fase de construccin
4.4.2.1.
Convenciones en bases de datos
4.4.2.2.
Convenciones de Programacin
4.4.3.
Arquitectura o Programacin en 3 capas
4.4.3.1.
Capa de presentacin:
4.4.3.2.
Capa de negocio:
4.4.3.3.
Capa de datos:
3
3
3
4
4
10
10
11
16
19
19
20
21
21
22
23
24
24
25
25
25
26
28
39
40
40
41
Procedimiento de Desarrollo
1.
Objetivo
Establecer el procedimiento a seguir para el desarrollo de un nuevo
proyecto, identificando las principales etapas, actividades y
artefactos necesarios en cada una de ellas, con el fin de
proporcionar una gua til para el Analista y Desarrollador de
Sistemas de Informacin.
2.
Alcance
Este procedimiento aplica solo para proyectos nuevos e inicia con la
especificacin de los requerimientos del proyecto y termina con la
construccin del mismo.
3.
Fases
Las fases que se tendrn en cuenta son las siguientes:
a.
Definicin de los requerimientos
b.
Anlisis
c.
Diseo
d.
Construccin
Contrato pre desarrollo
Denicin de
requerimientos
Requerimientos
incompletos
Lnea base de requerimientos

SRS con casos de uso, rma del
Contrato de desarrollo
Anlisis
Anlisis incompleto
Documento de anlisis, eleccin de tecnologa

Diagramas de anlisis, estrategias
Diseo
Diseo incompleto
Requerimientos
No viables
Documento de diseo, diagramas

Construccin
Administracin de Requerimientos
4.
Especificacin de cada fase
4.1 Fase de Definicin de los requerimientos

Esta es una fase de vital importancia para los proyectos, su
intencin es tener absoluta claridad sobre los requisitos del mismo,
adems, en esta fase se debe estimar el precio, el tiempo y los
recursos necesarios para el desarrollo del proyecto; tambin es
posible que una vez finalizada esta fase, se decida no continuar con
el proyecto por restricciones o limitaciones que impidan su correcto
desarrollo.
Actividades en la fase de Definicin de Requerimientos:
Planeacin
Extraccin
Anlisis
Especificacin
Validacin
Durante la planeacin, el desarrollador debe identificar las principales

fuentes de informacin a tener en cuenta, as como las principales
tcnicas de recoleccin de informacin a emplear y el diseo de los
instrumentos necesarios para la recoleccin de la informacin.
De estas fuentes de informacin, se debe identificar al cliente lder quien
debe estar en capacidad de brindar informacin de alto nivel, como el
propsito del proyecto, sus objetivos y alcance.
Inicialmente, se debe realizar una entrevista con el cliente lder y recopilar
toda la informacin escrita posible que ayude al desarrollador a tener una
idea general sobre el proyecto. De estas fuentes de informacin, se
obtiene la visin del proyecto, de la cual se hace retroalimentacin con el
cliente lder y tras su aceptacin, el desarrollador debe planear las dems
fuentes de informacin a indagar y tcnicas de recoleccin de informacin
a emplear con sus respectivos instrumentos, realizando un proceso
iterativo que le permita en cada iteracin profundizar en temas puntuales
y aclarar dudas cada vez ms precisas.
Iteraciones en la recoleccin de informacin

Iteracin
Propsito
Conocer
la
idea
Fuente
principal
Tcnica
del Cliente lder,
proyecto, su alcance, sus objetivos y Informacin

propsito.
escrita
de
Entrevista
alto nivel
Comprender el funcionamiento actual Usuarios del
del
2
sistema,
necesidades,
principales
identificar
identificar
procesos y
cmo
llevan a cabo.
sus sistema
sus actual,
Varias
se formatos
empleados.
Determinar los datos relevantes del Cliente lder y

sistema, conocer cul informacin representante
3
debe contener.
de
los
usuarios,
formatos
4
5
Validacin de los requerimientos del Cliente lder

sistema
Retroalimentaciones permanentes
Cliente lder
Entrevista,
encuesta o
sesin
grupal
Entrevista
Prototipos
Durante la actividad de Extraccin, el analista y desarrollador

ejecuta las tcnicas de recoleccin de informacin planeadas
empleando los instrumentos diseados y dirigidas a las fuentes de
informacin seleccionadas. Es importante a la hora de ejecutar
estas tcnicas, tener en cuenta una serie de principios y emplear
tcnicas de modelado que ayuden a interpretar ms fcilmente la
informacin recolectada.
Luego de extraer la informacin de las diferentes fuentes, esta
informacin se debe Analizar, tratando en todo momento de
mantener coherencia entre las diferentes fuentes y entre los
diferentes requerimientos.
Algunas tcnicas de anlisis de
requerimientos que se pueden emplear son: Matriz de
Requerimientos, Matrices de trazabilidad, Matriz CRUD.
R1
R1
R2
R3
R4
R2
R3
R4
2
0
Una Matriz de requerimientos es

una
tcnica
de
anlisis
de
requerimientos
que
permite
confrontar
cada
requerimiento
frente a los dems, asignando un
cero (0) cuando los requerimientos
confrontados sean independientes,
un uno (1) cuando exista alguna
dependencia entre ellos y un dos
(2) cuando los requerimientos
confrontados sean ambiguos o
signifiquen lo mismo.
El objetivo
con esta tcnica es identificar
conflictos entre los requerimientos
y llegar a la independencia entre los
mismos.
Objetos
Casos de uso
Orden
Qumico
Solicitante
Proveedor
Ingresar orden
Cambiar orden
U,D
Gestionar
inventario
de
qumicos
C,U,D
Reporte de rdenes
Editar solicitantes
R
C,U,R
Una Matriz CRUD es una tcnica de anlisis de requerimientos que

permite verificar que todos los objetos que forman parte de una
aplicacin puedan ser Creados, Ledos, Actualizados y Eliminados
por los casos de uso identificados. Esta tcnica permite identificar
la necesidad de nuevos casos de uso en el sistema.
La especificacin de los requerimientos pretende crear un
documento con la lnea base de los requerimientos del sistema, este
documento es conocido como SRS (Software Requirements
Specification) Especificacin de los Requerimientos del Software, el
cual es considerado como el documento final de la fase de definicin
de los requerimientos. Este documento contempla principalmente
los requerimientos funcionales y no funcionales del sistema y puede
incluir anexos como diagramas de anlisis del sistema.
Table of Contents
Ambiente
Windows
Introduction............................................................................................................................4
1.1 Purpose...........................................................................................................................4
1.2 Document Conventions............................................................................................4
1.3 ProjectoScope...............................................................................................................4
1.4 References......................................................................................................................4
2 System Descriptios...........................................................................................................4
3 Functional Requirements..............................................................................................4
3.1 System Features...........................................................................................................5
3.1.1 System Feature 1...................................................................................................5
3.1.2 System Feature 2...................................................................................................5
3.2 Use Cases........................................................................................................................5
3.2.1 Use Cases Diagrams.............................................................................................5
3.2.2 Use Case 1................................................................................................................6
3.2.3 Use Case 2................................................................................................................6
3.3 Entity Relationship Diagrams...............................................................................6
3.4 Data Dictionary............................................................................................................6
3.4.1 Entity 1......................................................................................................................6
3.4.2 Entity 2......................................................................................................................6
4 External Interface Requirements..............................................................................6
5 Technical Requirements (Not functional).............................................................6
5.1 Performance.................................................................................................................6
5.2 Scalability.......................................................................................................................6
5.3 Security...........................................................................................................................6
5.4 Maintainbility...............................................................................................................6
5.5 Usability..........................................................................................................................6
5.6 Multi lingual Support................................................................................................6
5.7 Auditing and Logging................................................................................................6
5.8 Availability.....................................................................................................................6
6 Open Issues.........................................................................................................................7
Herramientas
Descripcin
Cundo seleccionarlo
emplear
Por ltimo en la fase de definicin de los

Recibe este nombre las Cuando la aplicacin va a
requerimientos, se debe realizar la validacin de
aplicaciones
en serrecolectada,
utilizada desdeeste
un solo
la basadas
informacin
es un proceso
se hace
con el clienteo lder,
en el cual se
formulariosque
o ventanas
y computador
desde
revisar
uno a uno
los requerimientos
controles solicita
tpicos como
pocos;
cuando
la
definidos y hacer sus sugerencias, este proceso
botones, cajas
de texto,
informacin
que gestiona
se realiza
hasta
que el cliente
lder se .NET
encuentre
mens. Las
aplicaciones de
la aplicacin
debe
(WinForms),
totalmente
acuerdo no
con
la ser
especificacin
final de
los compartida
requerimientos
en esteJava
en este ambiente
tienen
entre los yPcses Delphi,
momento donde se debe firmar el contrato de
que ser instaladas en que ejecuten la aplicacin; Swing
desarrollo, creando un compromiso donde el
cada computador
donde cuando
se requierea de
desarrollador
se compromete
realizar cada
uno de los requerimientos
y el
se desee utilizar.
buena velocidad yespecificados
buena
cliente se compromete
a no solicitar ningn otro
presentacin; muy til para
requisito que no est dentro de estos
el manejo
de grficos.
requerimientos
especificados.
Recibe este nombre las Cuando la aplicacin deba
aplicaciones
que
son ser accedida por varios
accedidas a travs de los usuarios desde diferentes PHP,

JSP,
navegadores Web. Este lugares; cuando los datos ASP.NET,
tipo de aplicaciones son de la aplicacin deban ser JavaScript,
Actividades en la fase de Definicin de los Requerimientos
Contrato Pre Desarrollo

Falta informacin
Planeacin
Extraccin
Cliente lder identificado,

Instrumentos diseados,
Citas concertadas.
Entrevista al
cliente lder
Informacin
incoherente
Requerimientos
no factibles
Usuarios del
sistema
Requerimientos de usuario
Propsito, objetivos y
alcance del proyecto
definido, usuarios y
procesos
identificados,
informacin escrita
de alto nivel.
Comportamiento
actual del distema,
procesos, necesidades
Anlisis
Informacin coherente,
requerimientos estables
Firma del
contrato de
desarrollo
Cliente lder conforme y

requerimientos factibles
Validacin
Cliente lder,
representate
usuarios
Datos necesarios,
informacin requerida
por el sistema.
Especificacin
Lnea base de requerimientos
Cliente lder no conforme
4.2 Fase de Anlisis

Luego de tener claramente establecidos los requerimientos del
sistema, de verificar su factibilidad y de firmar el contrato de
desarrollo, se inicia la fase de anlisis, en esta fase como su nombre
lo indica, el desarrollador debe analizar los requerimientos,
necesidades, objetivos, casos de uso y en s toda la informacin
recolectada en busca de plantear diferentes estrategias,
metodologas, arquitecturas y plataformas que puedan dar solucin
a las necesidades planteadas de la mejor manera.
En esta fase, tambin son tiles diferentes diagramas que adems
de ayudar a comprender mejor el sistema, sus procesos,
actividades e interrelaciones, ayuda tambin a ir esbozando la
solucin al mismo. Los diagramas a emplear son variables en cada
proyecto, pero se deben tomar como referencia los diagramas del
Lenguaje Unificado de Modelado UML.
Las actividades de la fase de Anlisis son:
1.
Estudio del entorno tecnolgico.
2.
Eleccin de la Arquitectura de Desarrollo.
3.
Diagramas de Anlisis del Sistema.
4.2.1 Estudio del entorno tecnolgico
Todo proyecto requiere para su correcto funcionamiento de ciertos
recursos que garanticen su desarrollo y ejecucin de manera
normal. Verificar que estos recursos se tienen antes de iniciar el
desarrollo de un proyecto recibe el nombre de estudios de viabilidad
o factibilidad, de esta manera podemos encontrar estudios de
viabilidad econmica, viabilidad operativa, viabilidad de fechas,
viabilidad tcnica, etc.
En este punto, ms que un estudio de viabilidad, se pretende es
realizar un inventario de la tecnologa con la que cuenta la
empresa y que servir de soporte para la ejecucin del proyecto.
Conocer esta tecnologa es importante para que el desarrollador
pueda tomar decisiones sobre la plataforma y arquitectura a
emplear o para realizar recomendaciones de adquisicin de
tecnologa necesaria para la ejecucin del proyecto.
10
Es de vital importancia entonces conocer las caractersticas de

Hardware, las redes, elementos de comunicacin y las licencias de
software que posee la empresa.
4.2.2 Eleccin de la Arquitectura de Desarrollo

Para el desarrollo de un proyecto de software, existen diferentes
alternativas referentes principalmente a la arquitectura a emplear.
Debemos elegir el ambiente (Web, Window, Consola, Mvil); el
sistema manejador de bases de datos (Robusto, Liviano, de
Servidor, de Escritorio, Libre, Gratuito, Comercial); el lenguaje de
programacin (Estructurado, Orientado a Objetos, Libre, Gratuito,
Comercial, Orientado a la Web, del lado del Cliente, del lado del
Servidor).
La arquitectura seleccionada, ser determinante para las dems
fases del desarrollo del proyecto, ya que esta orientar al
desarrollador sobre los diagramas a emplear, los diseos
necesarios, las pruebas a realizar, los requisitos de implantacin e
incluso el contenido de los contratos y licencias de uso.
11
Aspectos a tener en cuenta para la eleccin de la mejor alternativa.

Identificar el ambiente de ejecucin adecuado
Ambiente
Descripcin
Herramientas a
Cundo seleccionarlo
emplear
Recibe este nombre las Cuando la aplicacin va a

aplicaciones basadas en ser utilizada desde un solo
formularios o ventanas y computador
controles
tpicos
como pocos;
desde
cuando
la
botones, cajas de texto, informacin que gestiona .NET

Windows
mens. Las aplicaciones la aplicacin no debe ser (WinForms),

en este ambiente tienen compartida entre los Pcs Delphi,
Java
que ser instaladas en que ejecuten la aplicacin; Swing

cada computador donde cuando
se desee utilizar.
se
requiere
de
buena velocidad y buena

presentacin; muy til para
el manejo de grficos.
Recibe este nombre las Cuando la aplicacin deba

aplicaciones
que
son ser accedida por varios
accedidas a travs de los usuarios desde diferentes PHP,
JSP,
navegadores Web. Este lugares; cuando los datos ASP.NET,

Web
tipo de aplicaciones son de la aplicacin deban ser JavaScript,

alojadas en un Servidor compartidos
Web y para el acceso a usuarios;
por
cuando
los HTML,
CSS,
la HTML5
Ajax,
la aplicacin se requiere aplicacin no requiera de JQuery

que el equipo est en la velocidades de ejecucin
red del servidor.
extremas.
Recibe este nombre las Cuando se requiera de

aplicaciones
que
ejecutan
ambiente interaccin
en
se una
alta
D.O.S, que requieren de ambiente;

Consola
12
velocidad
con
el
cuando
la C, C++, QBasic,
mucha interaccin con el aplicacin sea empleada Turbo
Pascal,
teclado y que carecen de por pocas personas en .NET, Java

controles
prediseados pocos
computadores;
Web y para el acceso a usuarios;
cuando
la HTML5
Ajax,
la aplicacin
se requiere
aplicacin no
requiera de
JQuery
Procedimiento
de desarrollo
de Sistemas
de informacin
que el equipo est en la velocidades de ejecucin
red del servidor.
extremas.
Recibe este nombre las Cuando se requiera de

aplicaciones
que
ejecutan
ambiente interaccin
en
se una
alta
D.O.S, que requieren de ambiente;

Consola
velocidad
con
el
cuando
la C, C++, QBasic,
mucha interaccin con el aplicacin sea empleada Turbo
Pascal,
teclado y que carecen de por pocas personas en .NET, Java

controles
prediseados pocos
computadores;
como botones, cajas de cuando no se manejen

texto,
casillas
de grandes
volmenes
de
Estas aplicaciones se
caracterizan porque son
accedidas desde
dispositivos mviles
como celulares o PDAs,
SmartPhones o Tablets.
Mvil
En este ambiente, la
informacin puede residir
en el dispositivo mvil o
en un servidor y ser
accedida desde el
Cuando se requiera que la

aplicacin sea accedida a
travs
de
mviles;
dispositivos
cuando
los
procesos a ejecutar son

livianos;
requiera
cuando
acceso
informacin
se
a
la
sin
limitaciones del lugar o del
Java JME, .NET

Compact
Framework,
Windows
Phone, Android
WML, HTML5
puesto de trabajo.
dispositivo mvil.
13
Es importante aclarar que un proyecto puede tener una

combinacin de los diferentes tipos de ambientes vistos.
Para la seleccin del ambiente de ejecucin es importante tomar
como base la informacin obtenida en la fase de definicin de los
requerimientos, particularmente en el listado de requerimientos no
funcionales.
Al tener claro el ambiente de ejecucin, ya se pueden descartar
ciertas tecnologas y plataformas de desarrollo.
- Tener en cuenta las restricciones o limitaciones impuestas.
Durante la fase de definicin de los requerimientos, se debe
reconocer las restricciones impuestas por la empresa. Algunas de
estas restricciones pueden estar relacionadas con la tecnologa a
emplear, por ejemplo, es posible que la empresa haya invertido un
gran capital en la adquisicin de ciertas licencias de software y exija
el desarrollo del proyecto con esas tecnologas. En ese caso, se
debe evaluar la tecnologa y si esta es apta para el desarrollo del
proyecto, se debe verificar si se cuenta con la experiencia y
capacidad para el desarrollo del proyecto en dicha tecnologa, en
caso contrario, el desarrollo del proyecto puede sufrir un retraso
considerable.
Otra restriccin frecuente es la de tener que emplear tecnologas
libres o gratuitas para el desarrollo del proyecto, pues la empresa
se niega a tener que pagar altos costos de licenciamiento; en este
caso, se debe evaluar y elegir la tecnologa libre apta para el
desarrollo del proyecto en la que el desarrollador tenga ms
experiencia.
El Analistas y Desarrolladores en cualquiera de los casos puede
sugerir la tecnologa adecuada para el desarrollo del proyecto
siempre y cuando tenga la justificacin y argumentacin tcnica
suficiente para hacerlo.
14
- Evaluar las tecnologas candidatas.

Si el desarrollador es libre de elegir la plataforma de desarrollo, se
deben evaluar las caractersticas del proyecto, sus requerimientos
no funcionales e investigar las caractersticas de las diferentes
plataformas de desarrollo.
Es de gran importancia la eleccin del sistema manejador de bases
de datos porque este ser el responsable del almacenamiento y
administracin de toda la informacin del proyecto, de igual
manera, el lenguaje de programacin de alto nivel elegido es
importante, pues algunos poseen gran riqueza de funciones, otros
son orientados a objetos y permiten la reutilizacin de clases, otros
poseen mayores fortalezas de seguridad.
La experiencia es sin duda una razn de peso para la eleccin de la
plataforma de desarrollo, ya que esta permite avanzar rpidamente
en la construccin del proyecto y no se hace necesario invertir
tiempo valioso en el aprendizaje de una herramienta nueva, sin
embargo, si el desarrollador se basa exclusivamente en esta
premisa, ms temprano que tarde se dar cuenta que est
desarrollando en una herramienta obsoleta y el caos ser mayor.
En conclusin, ante limitaciones de tiempo, es recomendable
emplear una herramienta conocida y en la cual se tenga
experiencia, sin dejar de investigar y aprender nuevas tecnologas
que en el caso de proyectos no crticos y sin limitaciones de tiempo
se pueden poner en prctica.
15
Inicio
Identificar Ambiente de Ejecucin
No
Existen
restricciones
Si
Son aptas
para
No
Evaluar las tecnologas

candidatas
Si
Aumentar el tiempo de desarrollo

estimado
No
Se tiene la
experiencia
Si
Tecnologa Seleccionada
Fin
4.2.3 Diagramas de Anlisis del Sistema

En la fase de anlisis los diagramas deben estar enfocados en la
comprensin del sistema (actual y nuevo).
Cada diagrama
presenta una vista del sistema desde diferentes niveles de
abstraccin, por lo tanto, la eleccin de los diagramas requeridos
depende del aspecto del sistema en el que se desee concentrar la
atencin.
Los diagramas no son excluyentes ni dependen exclusivamente de
una metodologa o paradigma seleccionado, los diagramas son
expresiones grficas de algo que se desea observar en un sistema,
por esta razn, lo importante es pensar en qu se desea observar y
a partir de esto, elegir el diagrama que permita hacerlo de la
manera ms eficiente.
16
texto,
casillas
de grandes
volmenes
de
Diagrama
Qu representa
Cuando Hacerlo
La relacin entre el sistema de Siempre que se desee

estudio
Contexto
otros
sistemas presentar una imagen
externos. Permite identificar el del alcance el sistema

alcance del sistema.
y su relacin con otros

sistemas
El comportamiento del sistema. Cuando

Flujo de Datos
se
desee
Permite identificar los procesos, comprender

su interaccin y los principales cmo
almacenes de datos.
mejor
funciona
el
sistema actual.
Las principales funcionalidades

que tendr el nuevo sistema y
quines interactuarn con ellas.
Casos de Uso
Son un referente para todas las
Siempre
fases del desarrollo, desde la

definicin
de
requerimientos
hasta las pruebas.

Los datos requeridos por el Siempre
Entidad Relacin
que
el
sistema y la relacin entre ellos. proyecto requiera de

Este diagrama dar origen a la una Base de Datos.
Base de Datos.
Los objetos que formarn parte Siempre
del
Clases
sistema,
comportamiento.
sus
datos
que
y construccin
de
la
la
Se convierte aplicacin se realice
en un insumo importante para el Orientada a Objetos.

diseo y la construccin de la
aplicacin.
17
La interaccin entre diferentes Cuando existan casos

Secuencia /
Colaboracin
objetos para cumplir con una de uso sobre los que

funcionalidad del sistema.
Los se
desee
mensajes transmitidos entre los cules son los pasos

objetos para cumplir una funcin.
para llevarlos a cabo.

Cuando
objetos
Transicin de
estados
conocer
Los diferentes estados por los

que
pasa
un
objeto
en
sistema.
un
existan
dentro
del
sistema que cambien

de estado e interese
conocer
las
condiciones requeridas
para
pasar
de
un
estado a otro.
La secuencia de pasos lgicos Cuando
Actividades /
Flujo
existan
requeridos para cumplir con un procesos o funciones

propsito dentro del sistema.
que
se
deseen
describir paso a paso.
La tabla anterior presenta un listado de los diagramas ms

empleados dentro de la fase de anlisis, normalmente, el diseo de
un diagrama requiere de varias revisiones y correcciones hasta
llegar a su versin final, por esta razn es importante estimar un
tiempo adecuado para la fase de anlisis, con el fin de realizar los
diagramas de esta fase de la mejor manera posible ya que estos
sern insumos de vital importancia para el diseo del proyecto.
18
4.3 Fase de Diseo Presentar en un captulo aparte

La fase de diseo es determinante para el xito o fracaso del
proyecto, debido a que el diseo est directamente relacionado con
la calidad del software y ser la principal referencia a tener en
cuenta durante la fase de construccin.
Existen diferentes tipos de diseos, pensados cada uno en
presentar una solucin a un aspecto particular del proyecto, en esta
etapa, el desarrollador debe realizar aquellos que considere
necesarios para llegar a la fase de construccin con una gua que
oriente su trabajo, dejando poco a la imaginacin. A continuacin
se presentan algunos de los diseos ms significativos
4.3.1 Diseo de la Base de Datos
TRATAMIENTOS
TraNumero
TraFechaAsignado
TraDescripcion
TraFechaInicio
TraFechaFin
TraObservaciones
TraPaciente
1
PACIENTES
PacIdentificacion
1
PacNombres
PacApellidos
PacFechaNacimiento
PacSexo
CITAS
CitNumero
CitFecha
CitHora
CitPaciente
CitMedico
CitConsultorio
CitEstado
CitObservaciones
19
MEDICOS
MedIdentificacion
MedNombres
MedApellidos
CONSULTORIOS
ConNumero
ConNombre
A partir del diagrama Entidad Relacin creado durante la fase de

Anlisis, se debe generar el diseo de la base de datos o modelo de
tablas, en este deben quedar claramente definidas las tablas con
sus campos, sus llaves principales y llaves forneas, sus relaciones,
restricciones de integridad referencial y cardinalidad. Este diseo
ser la gua que tendr el desarrollador al momento de definir el
esquema de la base de datos en el sistema manejador de bases de
datos seleccionado.
4.3.2 Diccionario de Datos
DICCIONARIO DE DATOS
Tabla
Nombre
Id_cte
nomb_cte
Cliente
Tipo
Numrico
Carcter
Tamao
4
50
Not Null PK FK
X
X X
X
Default
Constraint
Descripcin
Identificador del cliente
Razn social de la empresa
Tabla
Nombre
Id_prod
nomb_prdo
cto_uni
Producto
Tipo
Numrico
Carcter
Numrico
Tamao
7
80
3
Not Null PK FK
X
X X
X
X
Default
Constraint
Descripcin
Identificador del producto
Nombre del medicamento
Valor de cada medicamento
Pasando ms al detalle, el diseo de archivos o diccionario de datos

toma cada uno de los campos presentes en las tablas (archivos) del
diseo de la base de datos y especifica su nombre, tipo de dato,
tamao y restricciones o constraints, por ejemplo si es llave
primaria, si acepta valores nulos, su valor por defecto, si es
requerido o si es llave fornea. Este diseo complementa el diseo
de la base de datos y es empleado durante la construccin de la
base de datos en el momento de definir las propiedades de cada
campo en el sistema manejador de bases de datos.
20
4.3.3 Diseo de Entradas y Salidas
ZONA DE TITULO
Zona de instrucciones para el usuario
Zona de
logotipo
Zona de entradas de usuario
Zona de movimiento de
registros
Zona de operaciones con

registros
Este diseo especifica los pantallazos,

ventanas, formularios o reportes requeridos
por la aplicacin para comunicarse con el
usuario, gracias a este diseo, es posible
conocer cules sern los datos solicitados al
usuario y cules sern los datos mostrados en
cada pantallazo, su ubicacin, tipo de control
empleado y las caractersticas o restricciones
de cada campo.
Para el desarrollo de este diseo se deben tener en cuenta ciertos

principios orientados a la ergonoma de la aplicacin, de igual
manera, se deben considerar las recomendaciones del usuario final,
ya que este ser quien ingrese los datos en las entradas y reciba la
informacin de las salidas. Es recomendable realizar el diseo de
entradas y salidas despus del diseo de la base de datos para
garantizar que los campos de la base de datos van a ser
alimentados a travs de las entradas y que las salidas diseadas
solo podrn presentar informacin calculada u obtenida de los
campos de la base de datos.
4.3.4 Diseo de Casos de Uso
Registrar Cliente
CDULA
NOMBRE
TELFONO
REGISTRAR
Registrar cliente
Validar usuario
Generar Factura
IDFACTURA
Generar factura
FECHA
VALOR
21
GENERAR
Fuente: Los autores
Los diagramas de casos de uso y la descripcin de casos de uso

realizada en la fase de anlisis junto a los diseos de entradas y
salidas se unen para generar el diseo de casos de uso, el cual
consiste en realizar un seguimiento de la interaccin entre el actor
y la aplicacin (descripciones de casos de uso) con las entradas y
salidas diseadas. Este diseo es importante porque mantiene la
trazabilidad del proyecto y valida que las entradas y salidas
diseadas son las suficientes para la ejecucin de cada caso de uso.
4.3.5 Diseo de Clases
TForm
TFAboutBox
+TFAboutBox(inout AOwuner:TComponent*)
+Datos(in producto:UnicodeString, in proyecto:UnicodeString,
in autor:UnicodeString,in version:UnicodeString)
TGrafica
-pb: TPaintBox*
-im: TImage*
-y: unsigned it [][]
-x: unsigned short
-habilitada: bool
+TGrafica(in pb:TPaintBox*,in im:TImage*)
+estado(in habilitada:bool)
+limpiar()
+aadir(in valores:unsigned short*)
-pintar(inout Sender:TObject*)
TActuador
-hLib: HINSTANCE
-oup32fp: oupfuncPtr
-habilitado: bool
-error: bool
-cadenaError: UnicodeString
+TActuador()
+~Tactuador()
+movimiento(in accion:AC_Accion_t,in giro:GI_Giro_t): bool
+habilitar(in activo:bool)
+inicializador(): bool
+estadoError(): bool
+textoError(): UnicodeString
-puerto(in const short:valor): bool
22
TFAboutBox
-con: TConexion*
-actuador: TActuador*
-grafica: TGrafica*
-conectado: bool
-continuar: bool
-manual: bool
-inicializarGiro: bool
-cargarPerfil: bool
-perfilCargado: bool
-ficheroPerfil: UnicodeString
-ficheroINI: UnicodeString
-imgCasco: unsigned short
-imgFlechasAB: unsigned short
-imgFlechasID: unsigned short
-VERSION: UnicodeString
-BUILD: UnicodeString
-FECHA_VERSION: UnicodeString
-NOMBRE: UnicodeString
-PROYECTO: UnicodeString
-AUTOR: UnicodeString
+TFMain(in Owner:TComponent*)
-registro(in ac:AC_Accion_t,in activoAB:bool,
in activoID:bool)
-estado(in ES_Estado_T:es)
-senal(in sn:SN_Senal_T)
-bateria(in carga:int,in maxima:int)
-fuerza(in fu:unsigned short)
-desviacion(in inc:short)
-entrenamiento(in fichero:UnicodeString,
in nivel:float)
-formulario()
-editsServidor(in activo bool)
-labelsTiempoConexion(in activo:bool)
-labelsFicheroPerfil(in activo:bool)
-accionManual(in ac:AC_Accion_tin gi:GI_Giro_t)
-imagenCasco(in estado_casco:bool,in contactos:int*)
-tiempoConexion(in tiempo:float)
El diagrama de clases realizado durante la fase de anlisis ahora es

refinado para convertirlo en el diseo de clases. Para lograr este
propsito se deben adicionar los tipos de datos y modificadores de
acceso a los atributos, se deben especificar los modificadores de
acceso, tipos de retorno, parmetros y tipos de parmetros de
entrada en los mtodos; se deben identificar clases abstractas e
interfaces requeridas, as como la necesidad de incluir otras clases
de terceros.
En el diseo de clases tambin es importante reconocer patrones
de diseo que puedan ser tiles para la aplicacin. Este diseo se
convertir en la base para la construccin del proyecto cuando se
emplee el paradigma Orientado a Objetos.
4.3.6 Diseo de Interface
Aspectos como el color
de fondo, color del
texto, tipo y tamao de
la
fuente,
textura,
logotipos,
conos
e
imgenes son tenidos
en cuenta en el diseo
de interface.
Este
diseo busca reducir
significativamente
el
tiempo invertido en la
fase de construccin
ofreciendo
a
los
programadores estos
aspectos ya definidos
desde el diseo.
23
4.3.7 Diseo de Navegabilidad
Este diseo es empleado principalmente para el desarrollo de sitios

o aplicaciones Web, su objetivo es visualizar los caminos que se
deben recorrer para llegar a cualquier pgina Web (navegar) desde
algn punto de la aplicacin. Realizar este diagrama es til para
identificar jerarquas y mens en los sitios Web.
4.3.8 Diseo de Seguridad y Control
El diseo de seguridad y control define el mecanismo de acceso a la

aplicacin por parte de los usuarios, especifica los recursos de la
aplicacin y los permisos sobre esos recursos que tendr cada uno
de los roles que interactuarn con la aplicacin y las dems
consideraciones especiales de seguridad y control que la aplicacin
debe tener en cuenta.
24
4.4 Fase de Construccin

Con la fase de diseo finalizada adecuadamente, se tienen las
garantas para iniciar la fase de construccin del proyecto con la
certeza de tener las bases suficientes para una construccin del
proyecto coherente y consistente con las fases previas y que dar
solucin a las necesidades planteadas.
En esta fase, generalmente se realizan las tareas de la construccin
de la Base de Datos (Back-End), la construccin de la Interface
Grfica de Usuario (Front-End) y la codificacin de los mdulos del
sistema.
4.4.1 Relacin con el diseo
El diseo de la base de datos y el diseo de archivos son los
insumos para crear la base de datos en el sistema manejador de
bases de datos seleccionado.
El diseo de entradas y salidas y el diseo de interface se toman
como referencia para la construccin de la interface grfica de
usuario.
El diseo de clases, de casos de uso, de navegabilidad y de
seguridad y control dirigen la codificacin de los mdulos del
sistema.
Para el desarrollo de los elementos que forman parte de la fase de
construccin, adems de tomar como referencia los diseos
anteriormente mencionados, se deben seguir otras pautas que
permitan llevar a cabo esta fase de una manera adecuada,
generando como resultado un proyecto eficiente y con facilidad de
mantenimiento.
4.4.2 Uso de convenciones durante la fase de construccin
Emplear convenciones facilita el mantenimiento del proyecto, la
correccin de errores, agiliza el proceso de construccin, promueve
la interoperabilidad del proyecto y la comunicacin con otros
proyectos, crea un ambiente de confianza en el equipo de desarrollo
e independiza el proyecto del desarrollador que lo realiz.
25
4.4.2.1 Convenciones en bases de datos

Al momento de definir el esquema de la base de datos, es
importante emplear convenciones para darle nombre a los objetos
de la misma. Existen unos parmetros universales elementales que
son idnticos a las reglas aplicables para definir variables, sin
embargo, al interior de cada empresa de desarrollo de software se
adoptan convenciones propias para facilitar el trabajo de sus
desarrolladores. Por ejemplo, algunas empresas o desarrolladores
suelen emplear el prefijo tbl para nombrar las tablas (tblAlumnos),
otros desarrolladores nombran las tablas en mayscula y plural.
Un ejemplo de convenciones para las bases de datos puede ser:
Tablas
- Todos los nombres de las tablas deben expresarse en plural y en
mayscula sostenida
- Tablas que sean referencias a entidades en el sistema. Ejemplo:
ALUMNOS, COMPUTADORES, HORARIOS, TURNOS.
- Los nombres de las tablas que se generen a partir de relaciones
entre entidades deben tener en lo posible un nombre significativo
para el sistema.
Ejemplo:
SOLICITUDES
podra ser el nombre de la tabla obtenida de la relacin entre
proyectos y recursos.
- Las tablas generadas a partir de relaciones donde no se encuentre
un nombre significativo dentro del sistema, se deben nombrar
empleando la combinacin de los nombres de las entidades
relacionadas.
Ejemplo:
INSTRUCURSOS
Podra ser el nombre de la tabla generada a partir de las entidades
Instructor y Curso.
26
Campos
- Los nombres de los campos deben emplear la convencin Pascal
Case, la cual indica que se debe empezar en mayscula la primera

letra de cada palabra.
Ejemplo: IdCurso, TipoIdentidad,
SalarioPromedio.
- Cada campo debe expresar en su nombre la tabla a la que
corresponde, esto lo hace empleando como prefijo las 4 primeras

letras de la tabla seguidas por guin bajo. Ejemplo:
EMPLEADOS
Empl_Cedula
Empl_Nombre
Empl_FechaContrato
Empl_SalarioPromedio
- Cuando se trate de tablas cuyo nombre es compuesto, el prefijo
debe contener parte de ambos nombres. Ejemplo:

INSTRUCURSOS
Incu_InstructorF
Incu_CursoF
Incu_FechaAsignacion
Tipo
de
- El (los) campo(s)
definido(s) como llave principal
debe(n) estar al
Convencin
Ejemplo
Elemento
inicio de la tabla.
Pascal
Casing
Empleado
- El (los) campo(s)
definido(s)
como llave(s)
fornea(s) debe(n)
estar al final de la tabla, su nombre debe hacer
alusin a la tabla de
MovimientoDeTransaccion
Empezar
con
mayscula
la
clase procede y debe terminar con la letra F. Ejemplo:
donde
primera letra de existe
cada palabra
y
Si en la tabla PRODUCTOS
un campo
forneo que hace
alusin al cdigo
la categora de la tabla CATEGORIAS, este
en de
singular
campo se debe nombrar as:
Interfaces
Igual que las clases pero debe IArticulo

iniciar con la letra I
Camel Casing
27
impuesto
Variables
Empezar con minscula y la
primerApellido
Prod_CategoriaF
donde:
Prod hace referencia a la tabla donde est el campo
Categoria indica que es un campo que hace alusin a la llave
principal de la tabla CATEGORIAS
F significa que es forneo.
4.4.2.2. Convenciones de Programacin
Para la codificacin del programa, es de vital importancia el manejo
de convenciones, pues gracias a ellas es posible reducir
significativamente el tiempo de desarrollo y los programas sern
ms claros y fciles de mantener.
-Convenciones para nombrar controles
Como regla general, para darle nombre a un control se debe
emplear un prefijo que indique el tipo de control, seguido de la
funcionalidad que este control debe realizar.
Ejemplo: para un men que permita salir de la aplicacin, el
nombre ms adecuado sera mnuSalir.
A continuacin, se ofrece una lista de algunos controles comunes
con su respectivo prefijo y ejemplo. Esta lista es de simple
ilustracin, se debe tener en cuenta que el prefijo a utilizar depende
directamente del nombre del control, por lo tanto, para controles
ausentes en la lista o controles personalizados, se debe emplear un
prefijo que describa claramente su tipo.
Sin
Identar
28
Control
Descripcin
Prefijo Ejemplo
Adodc
Datos ADO
ado
adoBiblio
Botn
de
Button
comando
btn
btnAceptar
Calendar
Vista de mes
mvw
mvwPeriodo
chk
chkSoloLectura
cbo
cboIngles
CommandButton comando
cmd
cmdSalir
CommonDialog
Datos comn
dlg
dlgAbrirArchivo
Data
Datos
dat
datBiblio
dtgrd
dtgrdResultadosConsulta
dblst
dblstTipoTrabajo
dir
dirSource
drv
drvDestino
dtp
dtpEditado
Casilla
CheckBox
de
verificacin
Cuadro
combinado,
cuadro de lista
ComboBox
desplegable
Botones
de
Cuadrcula
enlazada
DataGrid
datos
Cuadro de lista
enlazada
DataList
datos
Cuadro de lista
DirListBox
de directorios
Cuadro de lista
DriveListBox
de unidades
Selector
DTPiker
de
fecha
Cuadro de lista
29
FileListBox
de archivos
fil
filOrigen
Form
Formulario
frm
frmEntrada
Frame
Marco
fra
fraIdioma
Grid
Cuadrcula
grd
grdPrecios
Barra
de
desplazamiento
HScrollBar
horizontal
hsb
hsbVolumen
Image
Imagen
img
imgIcono
ImageList
Lista de imgenes ils
ilsTodosIconos
Label
Etiqueta
lbl
lblMensajeAyuda
ListBox
Cuadro de lista
lst
lstCodigos
ListView
Visor de lista
lvw
lvwEncabezados
MAPI
Sesin MAPI
mps
mpsSesion
Menu
Men
mnu
mnuAbrirArchivo
MSComm
Comunicaciones
com
comFax
MSHFlexGrid Flexgrid
flex
flexPedidos
OptionButton Botn de opcin
opt
optGenero
Panel
pan
panBotones
pic
picVGA
Hierarchical
Panel
Cuadro
PictureBox
imagen
ProgressBar
Barra de progreso prg
prgCargarArchivo
RichTextBox RichTextBox
rtf
rtfInforme
SatusBar
Barra de estado
sta
staFechaHora
Shape
Forma
shp
shpCirculo
Slider
Control deslizante sld
sldEscala
TabStrip
Fichas
tab
tabOpciones
TextBox
Cuadro de texto
txt
txtApellido
Timer
Cronmetro
tmr
tmrAlarma
Barra
de
ToolBar
herramientas
tlb
tlbAcciones
TreeView
Visor de rbol
tre
treOrganizacion
UpDown
UpDown
upd
updDireccion
vsb
vsbIndice
Barra
VScrollBar
30
de
desplazamiento
de
-Convenciones de Codificacin
Cada lenguaje de programacin sugiere el uso de ciertas
convenciones para nombrar los elementos que forman parte del
cdigo fuente de un programa como las clases, variables,
constantes y mtodos, por ejemplo, VB.Net emplea la convencin
PascalCase que inicia con mayscula el nombre de los mtodos y
Java emplea la convencin Camel Casing, la cual inicia con
minscula sus mtodos. El desarrollador puede de acuerdo con el
lenguaje emplear una convencin u otra o simplemente puede
adoptar
una
convencin
para
todos
sus
proyectos
independientemente del lenguaje de programacin utilizado.
Ejemplo:
Tipo
de
Convencin
Elemento
Ejemplo
Pascal Casing
clase
Empezar
con
Empleado
mayscula
la
MovimientoDeTransaccion
primera letra de cada palabra y

en singular
Interfaces
Igual que las clases pero debe IArticulo

iniciar con la letra I
Camel Casing
Variables
Locales,
Parmetros
Mtodos
Empezar con minscula y la

primera letra de las siguientes
y palabras con mayscula
impuesto
primerApellido
salarioTotal
calcularPrestaciones()
guardar()
consultarSaldoActual()
31
Parmetros
Mtodos
y palabras con mayscula
calcularPrestaciones()
guardar() de informacin
Procedimiento de desarrollo de Sistemas
consultarSaldoActual()
Variables
Igual que las variables locales gSaldo
Globales a nivel pero deben empezar con la letra gEdad

de
Archivo
o g
gPaisOrigen
Clase
Variables
Igual que las variables locales pUsuario
Globales a nivel pero deben empezar con la letra pCargoActual

de Aplicacin
p
Mayscula
Constantes
sostenida,
si
su PI
nombre es compuesto, se debe SALARIO_MINIMO

separar por guion bajo
IVA
-Indentacin
La indentacin facilita la lectura, comprensin del cdigo y el
seguimiento del flujo de un programa, es recomendado usar 3 o 4
espacios como indentacin entre cada bloque
Ejemplo en VB:
If (salario>salarioMinimo) Then
impueto=salario*0.1
End If
Ejemplo en C#
Sin
Identar
Identacin
estilo 1
32
Identacin
estilo 1
Identacin
estilo 2
En condiciones largas que combinen operadores lgicos, el cdigo

es difcil de leer y seguir cuando esta se realiza en una sola lnea.
If ((salario<=salarioMinimo) &&(edad<18) && (estrato<3) && (ma
{
descuento=matricula *0,5;
valorPagar=matricula-descuento;
}
En estos casos, es recomendable separar la condicin en varias

lneas. Ejemplo:
If ((salario <=salarioMinimo) &&
(edad<18) && (estrato<3 &&
(matricula>promedioMatricula))
{
descuento=matricula *0,5;
valorPagar=matricula-descuento;
}
Tambin es recomendado que aunque un bloque posea una sola

lnea de cdigo y por lo tanto se puedan omitir las llaves de apertura
y cierre, stas siempre se agreguen, pues dan mayor legibilidad al
cdigo y evitan posibles errores al modificar las acciones del bloque.
33
No recomendado:
While (cantAlumnos<alumnosTotales)
cantAlumnos++;
Sugerido:
While (cantAlumnos<alumnosTotales)
{
cantAlumnos++;
}
-Convenciones de los comentarios
Preferir los comentarios en lneas aparte que al final de una lnea
de cdigo.
Los comentarios deben estar en el mismo nivel de indentacin que
el segmento de cdigo a comentar.
Iniciar el texto del comentario con una letra mayscula.
Finalizar los comentarios con un punto.
Insertar un espacio entre el delimitador del comentario y el texto
del comentario.
Secciones de Comentarios
34
Encabezado
Empezar todos los programas o archivos con un encabezado
del Programa descriptivo.

o Archivo
/*---------------------------------------------------------* Programa o Archivo:
* Sistema:
<Nombre del Sistema>
* Versin:
<Nmero de la Versin actual>
* Autor:
Formato
del
Encabezado
<Identificador del Programa>
* Fecha:
<Nombre(s) del Autor(es)>

<dd/mmm/aaaa>
* Descripcin: <Descripcin del programa Funciones bsicas>
[* Historial de modificaciones:
* Fecha
Descripcin Modificacin
Autor ]
*---------------------------------------------------------*/
35
/* Mtodo:
Encabezado
de
mtodos,
funciones
procedimient
os
<Nombre del Mtodo>
* Descripcin:
<Descripcin de Funciones bsicas>
* Autor:
<Nombre del Asociado>
* Fecha:
<dd-mm-aaaa>
* Descripcin de Parmetros:
[* Historial de modificaciones:
* Fecha
Descripcin Modificacin
Autor
*---------------------------------------------------------]
*/
Secciones
Mayores
Antes de una seccin mayor de un programa, escribir un bloque de

comentarios que describan el procesamiento que es realizado en tal
seccin. Incluir comentario similar para la finalizacin del cdigo.
/*----* Proceso para el Calculo de la Desviacin Estandar
*-----
Ejemplo
Seccin
Mayor
*/
..
/*----* Fin de Programa
*-----*/
36
Identacin
estilo 2
Comentarios
de lnea
Ejemplo
Los comentarios de lnea deben explicar el propsito y el

comportamiento del cdigo
mal IF rsClientes > limit
comentario
/* Verifica si rsClientes es mayor que el lmite. */
Ejemplo buen IF rsClientes > limit

comentario
Espacios
Blanco
/* Verifica si todos los clientes se han mostrado */

Escribir los programas con suficiente espacio para que no se vean
en densos.
Separar cada construccin del programa con al menos un espacio.
-Otras recomendaciones para la codificacin de los programas

+Utilice la palabra clave With
Cuando se enfrente con una serie de llamadas a un objeto,
considere la posibilidad de utilizar la palabra clave With, esto har
el cdigo ms fcil de entender y modificar
+Evite el cdigo quemado
En las condiciones de una estructura de control de flujo, no se debe
realizar comparaciones con constantes sean estas numricas o de
texto, pues cualquier cambio en el comportamiento del sistema
generar gran esfuerzo en el mantenimiento de la aplicacin.
37
Cdigo Quemado
Cdigo
no
quemado
38
4.4.3 Arquitectura o Programacin en 3 capas

Al momento de realizar la codificacin de los mdulos de una
aplicacin Web, es posible tener en un mismo archivo (.php, .asp,
.aspx ) Todo el cdigo mezclado para llevar a cabo la funcionalidad
que se pretende desarrollar con una determinada pgina Web, este
archivo contendr entonces
Cdigo HTML con el que se le dar formato a la pgina
Cdigo PHP, ASP, ASP.NET , con el que se atender la lgica

de la pgina.
Cdigo JavaScript o VBScript con el que se realizarn

validaciones o se le dar dinamismo a la pgina.
Cdigo SQL con el que se acceder a la Base de Datos para

enviar o recibir informacin de ella.
El hecho de tener todos estos cdigos dentro de un mismo archivo
(Pgina Web), hace que el mantenimiento de la aplicacin sea muy
dispendioso y que algn cambio bien sea en el diseo de la pgina,
en la Base de Datos o en las reglas del negocio genere grandes
dificultades para volver a interrelacionar todos los cdigos
mencionados.
Por esta razn surge un estilo de programacin
conocido como Programacin por Capas.
1. Capa de presentacin
CLIENTES
39
2. Capa de negocio
SERVIDOR DE
NEOCIACIN
3. Capa de datos
SERVIDOR DE
BASE DE DATOS
Este estilo de programacin separa el desarrollo de la aplicacin en

3 capas: La Capa de Presentacin, La Capa de Negocio y la Capa de
Datos, dndole a cada capa una responsabilidad exclusiva y de esta
manera lograr la independencia de cada una de ellas con las dems,
obteniendo de esta forma las siguientes ventajas:
Proporciona escalabilidad, capacidad de administracin y
utilizacin de recursos mejorados.
Cada capa es un grupo de componentes que realiza una funcin
especfica.
Se puede actualizar una capa sin recompilar otras capas.
4.4.3.1 Capa de presentacin:
Es la encargada de mostrar al usuario la interface grfica con la que

interactuar para ingresar u obtener informacin del sistema. Esta
capa est conformada principalmente por los formularios y
controles que el usuario manipular.
Para mantener la
independencia entre las capas, es recomendable que esta no posea
ningn tipo de cdigo diferente al necesario para presentar la
interface grfica al usuario.
4.4.3.2 Capa de negocio:
40
Esta capa es la que contiene el cdigo necesario para que la

aplicacin cumpla con las reglas del negocio del sistema, estas
reglas son condiciones o caractersticas especiales del sistema que
se desarrolla como por ejemplo el asignar citas nicamente a los
mdicos que se encuentren disponibles y que tengan la especialidad
necesaria para atender a un determinado paciente.
Esta capa adems es la responsable de capturar la informacin que
el usuario ingresa en la capa de presentacin, procesar los eventos
generados y comunicarse con la capa de datos para enviar los datos
o recoger los datos que se mostrarn finalmente en la capa de
presentacin.
4.4.3.3 Capa de datos:
TRATAMIENTOS
TraNumero
TraFechaAsignado
TraDescripcion
TraFechaInicio
TraFechaFin
TraObservaciones
TraPaciente
PACIENTES
1
PacIdentificacion
PacNombres
PacApellidos
PacFechaNacimiento
PacSexo
CITAS
CitNumero
CitFecha
CitHora
CitPaciente
CitMedico
CitConsultorio
CitEstado
CitObservaciones
MEDICOS
MedIdentificacion
MedNombres
MedApellidos
CONSULTORIOS
ConNumero
ConNombre
La capa de datos est conformada por las clases que almacenan

informacin y por los componentes fsicos en los que esta
informacin se almacena como es el caso de las bases de datos.
Esta capa es la responsable de guardar los datos con los que el
sistema trabaja y de permitir el acceso a los mismos para ser
finalmente visualizados en la capa de presentacin.
En la actualidad existen dentro de las diferentes plataformas de
desarrollo frameworks que ayudan a programar utilizando la
arquitectura en tres capas y patrones de diseo como el MVC
(Modelo Vista Controlador) que al aplicarse en el desarrollo de un
software implcitamente implementa este tipo de arquitectura en
una aplicacin.
41
GLOSARIO
Artefacto: En el Lenguaje Unificado de Modelado (UML), un
artefacto es la especificacin de un componente fsico de
informacin que es usado o producido por un proceso de desarrollo
de software, o por el desarrollo y operacin de un sistema.
Back-end: En un aplicativo de software corresponde con la parte
que procesa los datos recibidos desde el front-end.
Constraint: Son restricciones que se definen desde el diseo de la
base de datos y permiten incorporar reglas a los datos.
10
CRUD:
es un acrnimo que se utiliza para denotar las cuatro
FAVA - a
Formacin
en Ambientes
Virtualeslos
de Aprendizaje
SENA - Servicio
Nacional de Aprendizaje
operaciones bsicas
desarrollar
sobre
datos Creacin
de datos
o insercin de los mismos (Create), lectura o consulta de datos
(Read), actualizacin de datos ( Update) y borrado o eliminacin de
los mismos (Delete)
Framework: Conjunto de librerias o utilidades para agilizar y

optimizar el desarrollo en un lenguaje de programacin
determinado.
Front-end: En un aplicativo de software corresponde con la parte
que interactan los usuarios del sistema.
Iterativo: Repeticiones sobre un conjunto de procesos.
42
BIBLIOGRAFA
Object Management Group (2013). UML.
disponible
http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/
43
en
CREDITOS
Control de documento
Construccin Objeto de Aprendizaje
Procedimiento de desarrollo de
Sistemas de informacin
Desarrollador de contenido
Andrs Julin Valencia
Experto temtico
44
Asesor pedaggico
Claudia Milena Hernndez Naranjo
Produccin multimedia
Carlos Alberto Espinosa Gmez
Lder expertos temticos
Ana Yaqueline Chavarro Parra
Lder lnea de produccin
Santiago Lozada Garcs

Desarrollo de Sistemas de Información

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desarrollo de Sistemas de Información

Uploaded by

Copyright:

Available Formats

as

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Lnea base de requerimientos

Documento de anlisis, eleccin de tecnologa

Documento de diseo, diagramas

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Especificacin de cada fase

4.1 Fase de Definicin de los requerimientos

Durante la planeacin, el desarrollador debe identificar las principales

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Iteraciones en la recoleccin de informacin

del Cliente lder,

proyecto, su alcance, sus objetivos y Informacin

Determinar los datos relevantes del Cliente lder y

Validacin de los requerimientos del Cliente lder

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Durante la actividad de Extraccin, el analista y desarrollador

Una Matriz de requerimientos es

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Una Matriz CRUD es una tcnica de anlisis de requerimientos que

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Por ltimo en la fase de definicin de los

son ser accedida por varios

accedidas a travs de los usuarios desde diferentes PHP,

SENA - Servicio Nacional de Aprendizaje

navegadores Web. Este lugares; cuando los datos ASP.NET,

tipo de aplicaciones son de la aplicacin deban ser JavaScript,

Procedimiento de desarrollo de Sistemas de informacin

Actividades en la fase de Definicin de los Requerimientos

Contrato Pre Desarrollo

Cliente lder identificado,

Cliente lder conforme y

Lnea base de requerimientos

Cliente lder no conforme

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

4.2 Fase de Anlisis

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Es de vital importancia entonces conocer las caractersticas de

4.2.2 Eleccin de la Arquitectura de Desarrollo

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de informacin

Aspectos a tener en cuenta para la eleccin de la mejor alternativa.