Guia

as
rrollo de Sistem
Análisis y Desa
e m a s
n.
t
de Informació
Sis DE
Inform a c i ón
Procedimiento de desarrollo
o d e d e s a r r o ll o
Procedimien t
Año 2013 - Edción 01
Fase de Desarrollo
ADSI
SENA
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Procedimiento de desarrollo de Sistemas de información
Contenido
1. Objetivo 3
2. Alcance 3
3. Fases 3
4. Especificación de cada fase 4
4.1. Fase de Definición de los requerimientos 4
4.2. Fase de Análisis 10
4.2.1. Estudio del entorno tecnológico 10
4.2.2. Elección de la Arquitectura de Desarrollo 11
4.2.3. Diagramas de Análisis del Sistema 16
4.3. Fase de Diseño 19
4.3.1. Diseño de la Base de Datos 19
4.3.2. Diseño de Archivos (Diccionario de Datos) 20
4.3.3. Diseño de Entradas y Salidas 21
4.3.4. Diseño de Casos de Uso 21
4.3.5. Diseño de Clases 22
4.3.6. Diseño de Interface 23
4.3.7. Diseño de Navegabilidad 24
4.3.8. Diseño de Seguridad y Control 24
4.4. Fase de Construcción 25
4.4.1. Relación con el diseño 25
4.4.2. Uso de convenciones durante la fase de construcción 25
4.4.2.1. Convenciones en bases de datos 26
4.4.2.2. Convenciones de Programación 28
4.4.3. Arquitectura o Programación en 3 capas 39
4.4.3.1. Capa de presentación: 40
4.4.3.2. Capa de negocio: 40
4.4.3.3. Capa de datos: 41
2 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

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 guía útil para el Analista y Desarrollador de
Sistemas de Información.
2. Alcance
Este procedimiento aplica solo para proyectos nuevos e inicia con la
especificación de los requerimientos del proyecto y termina con la
construcción del mismo.
3. Fases
Las fases que se tendrán en cuenta son las siguientes:
a. Definición de los requerimientos
b. Análisis
c. Diseño
d. Construcción
Contrato pre desarrollo
Línea base de requerimientos

Deﬁnición de SRS con casos de uso, ﬁrma del
requerimientos Contrato de desarrollo
Requerimientos Documento de análisis, elección de tecnología

incompletos Análisis Diagramas de análisis, estrategias
Análisis incompleto Diseño

Documento de diseño, diagramas
Diseño incompleto
Construcción
Requerimientos Administración de Requerimientos

No viables

4. Especificación de cada fase
4.1 Fase de Definición de los requerimientos
Esta es una fase de vital importancia para los proyectos, su

intención es tener absoluta claridad sobre los requisitos del mismo,
además, en esta fase se debe estimar el precio, el tiempo y los
recursos necesarios para el desarrollo del proyecto; también 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 Definición de Requerimientos:
• Planeación
• Extracción
• Análisis
• Especificación
• Validación
Durante la planeación, el desarrollador debe identificar las principales

fuentes de información a tener en cuenta, así como las principales
técnicas de recolección de información a emplear y el diseño de los
instrumentos necesarios para la recolección de la información.
De estas fuentes de información, se debe identificar al cliente líder quien
debe estar en capacidad de brindar información de alto nivel, como el
propósito del proyecto, sus objetivos y alcance.
Inicialmente, se debe realizar una entrevista con el cliente líder y recopilar

toda la información escrita posible que ayude al desarrollador a tener una
idea general sobre el proyecto. De estas fuentes de información, se
obtiene la visión del proyecto, de la cual se hace retroalimentación con el
cliente líder y tras su aceptación, el desarrollador debe planear las demás
fuentes de información a indagar y técnicas de recolección de información
a emplear con sus respectivos instrumentos, realizando un proceso
iterativo que le permita en cada iteración profundizar en temas puntuales
y aclarar dudas cada vez más precisas.

Iteraciones en la recolección de información
Iteración Propósito Fuente Técnica

Conocer la idea principal del Cliente líder,
proyecto, su alcance, sus objetivos y Información
1 Entrevista
propósito. escrita de
alto nivel
Comprender el funcionamiento actual Usuarios del
del sistema, identificar sus sistema
2 necesidades, identificar sus actual, Varias
principales procesos y cómo se formatos
llevan a cabo. empleados.
Determinar los datos relevantes del Cliente líder y
Entrevista,
sistema, conocer cuál información representante
encuesta o
3 debe contener. de los
sesión
usuarios,
grupal
formatos
Validación de los requerimientos del Cliente líder
4 Entrevista
sistema
5 Retroalimentaciones permanentes Cliente líder Prototipos

Durante la actividad de Extracción, el analista y desarrollador

ejecuta las técnicas de recolección de información planeadas
empleando los instrumentos diseñados y dirigidas a las fuentes de
información seleccionadas. Es importante a la hora de ejecutar
estas técnicas, tener en cuenta una serie de principios y emplear
técnicas de modelado que ayuden a interpretar más fácilmente la
información recolectada.
Luego de extraer la información de las diferentes fuentes, esta

información se debe Analizar, tratando en todo momento de
mantener coherencia entre las diferentes fuentes y entre los
diferentes requerimientos. Algunas técnicas de análisis de
requerimientos que se pueden emplear son: Matriz de
Requerimientos, Matrices de trazabilidad, Matriz CRUD.
R1 R2 R3 R4 Una Matriz de requerimientos es

una técnica de análisis de
requerimientos que permite
R1 1 2 0 confrontar cada requerimiento
frente a los demás, asignando un
R2 1 0 0 cero (0) cuando los requerimientos
confrontados sean independientes,
un uno (1) cuando exista alguna
R3 2 0 2 dependencia entre ellos y un dos
(2) cuando los requerimientos
R4 0 0 2 confrontados sean ambiguos o
signifiquen lo mismo. El objetivo
con esta técnica es identificar
conflictos entre los requerimientos
y llegar a la independencia entre los
mismos.

Objetos
Casos de uso Orden Químico Solicitante Proveedor
Ingresar orden C R R R
Cambiar orden U,D R R
Gestionar inventario de
químicos C,U,D
Reporte de órdenes R R R
Editar solicitantes C,U,R
Una Matriz CRUD es una técnica de análisis de requerimientos que

permite verificar que todos los objetos que forman parte de una
aplicación puedan ser Creados, Leídos, Actualizados y Eliminados
por los casos de uso identificados. Esta técnica permite identificar
la necesidad de nuevos casos de uso en el sistema.
La especificación de los requerimientos pretende crear un

documento con la línea base de los requerimientos del sistema, este
documento es conocido como SRS (Software Requirements
Specification) Especificación de los Requerimientos del Software, el
cual es considerado como el documento final de la fase de definición
de los requerimientos. Este documento contempla principalmente
los requerimientos funcionales y no funcionales del sistema y puede
incluir anexos como diagramas de análisis del sistema.

Table of Contents
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
Herramientas
6 Open Issues.........................................................................................................................7 a
Ambiente Descripción Cuándo seleccionarlo
emplear
Por último en la fase de definición de los
Recibe este nombre las Cuando la aplicación va a
requerimientos, se debe realizar la validación de
aplicaciones
la basadas en serrecolectada,
información utilizada desdeeste
un solo
es un proceso
formulariosque se hace
o ventanas con el clienteo líder,
y computador en el cual se
desde
controles solicita revisar
típicos como uno a uno
pocos; cuandolos requerimientos
la
definidos y hacer sus sugerencias, este proceso
botones, cajas de texto,
se realiza información
hasta que gestiona
que el cliente líder se .NET
encuentre
menús. Las totalmente
aplicaciones de acuerdo no
la aplicación con debela ser
especificación
(WinForms),
Windows
final de
en este ambiente los compartida
tienen requerimientos
entre los yPc’ses Delphi,
en esteJava
momento donde se debe firmar el contrato de
que ser instaladas en que ejecuten la aplicación; Swing …
desarrollo, creando un compromiso donde el
cada computador donde cuando
desarrollador se requierea de
se compromete realizar cada
uno de los requerimientos
se desee utilizar. buena velocidad yespecificados
buena y el
cliente se compromete a no solicitar ningún otro
presentación; muy útil para
requisito que no esté dentro de estos
requerimientos el manejo de gráficos.
especificados.
Recibe este nombre las Cuando la aplicación deba
aplicaciones que son ser accedida por varios
accedidas a través de los usuarios desde diferentes PHP, JSP,
navegadores Web. Este lugares; cuando los datos ASP.NET,
tipo de aplicaciones son de la aplicación deban ser JavaScript,
Actividades en la fase de Definición de los Requerimientos
Contrato Pre Desarrollo
Falta información
Propósito, objetivos y
Planeación Extracción alcance del proyecto
definido, usuarios y
Cliente líder identificado, procesos
Instrumentos diseñados, Entrevista al identificados,
Citas concertadas. cliente líder información escrita
de alto nivel.
Información
incoherente Usuarios del
Comportamiento
sistema
actual del distema,
procesos, necesidades
Requerimientos Requerimientos de usuario
no factibles
Análisis
Información coherente,
Firma del requerimientos estables
contrato de
desarrollo Cliente líder,
representate
usuarios
Cliente líder conforme y Datos necesarios,
requerimientos factibles información requerida
por el sistema.
Validación Especificación
Línea base de requerimientos
Cliente líder no conforme

4.2 Fase de Análisis
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 análisis, en esta fase como su nombre
lo indica, el desarrollador debe analizar los requerimientos,
necesidades, objetivos, casos de uso y en sí toda la información
recolectada en busca de plantear diferentes estrategias,
metodologías, arquitecturas y plataformas que puedan dar solución
a las necesidades planteadas de la mejor manera.
En esta fase, también son útiles diferentes diagramas que además

de ayudar a comprender mejor el sistema, sus procesos,
actividades e interrelaciones, ayuda también a ir esbozando la
solución 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 Análisis son:

1. Estudio del entorno tecnológico.
2. Elección de la Arquitectura de Desarrollo.
3. Diagramas de Análisis del Sistema.
4.2.1 Estudio del entorno tecnológico
Todo proyecto requiere para su correcto funcionamiento de ciertos

recursos que garanticen su desarrollo y ejecución 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 económica, viabilidad operativa, viabilidad de fechas,
viabilidad técnica, etc.
En este punto, más que un estudio de viabilidad, se pretende es

realizar un “inventario” de la tecnología con la que cuenta la
empresa y que servirá de soporte para la ejecución del proyecto.
Conocer esta tecnología es importante para que el desarrollador
pueda tomar decisiones sobre la plataforma y arquitectura a
emplear o para realizar recomendaciones de adquisición de
tecnología necesaria para la ejecución del proyecto.

Es de vital importancia entonces conocer las características de

Hardware, las redes, elementos de comunicación y las licencias de
software que posee la empresa.
4.2.2 Elección 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, Móvil); el
sistema manejador de bases de datos (Robusto, Liviano, de
Servidor, de Escritorio, Libre, Gratuito, Comercial); el lenguaje de
programación (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 demás

fases del desarrollo del proyecto, ya que esta orientará al
desarrollador sobre los diagramas a emplear, los diseños
necesarios, las pruebas a realizar, los requisitos de implantación e
incluso el contenido de los contratos y licencias de uso.

Aspectos a tener en cuenta para la elección de la mejor alternativa.
Identificar el ambiente de ejecución adecuado
Herramientas a
Ambiente Descripción Cuándo seleccionarlo
emplear
Recibe este nombre las Cuando la aplicación va a
aplicaciones basadas en ser utilizada desde un solo
formularios o ventanas y computador o desde
controles típicos como pocos; cuando la
botones, cajas de texto, información que gestiona .NET
menús. Las aplicaciones la aplicación no debe ser (WinForms),
Windows
en este ambiente tienen compartida entre los Pc’s Delphi, Java
que ser instaladas en que ejecuten la aplicación; Swing …
cada computador donde cuando se requiere de
se desee utilizar. buena velocidad y buena
presentación; muy útil para
el manejo de gráficos.
Recibe este nombre las Cuando la aplicación deba
aplicaciones que son ser accedida por varios
accedidas a través de los usuarios desde diferentes PHP, JSP,
navegadores Web. Este lugares; cuando los datos ASP.NET,
tipo de aplicaciones son de la aplicación deban ser JavaScript,
Web
alojadas en un Servidor compartidos por los HTML, CSS,
Web y para el acceso a usuarios; cuando la HTML5 Ajax,
la aplicación se requiere aplicación no requiera de JQuery
que el equipo esté en la velocidades de ejecución
red del servidor. extremas.
Recibe este nombre las Cuando se requiera de
aplicaciones que se una alta velocidad o
ejecutan en ambiente interacción con el
D.O.S, que requieren de ambiente; cuando la C, C++, QBasic,
Consola mucha interacción con el aplicación sea empleada Turbo Pascal,
teclado y que carecen de por pocas personas en .NET, Java…
controles prediseñados pocos computadores;
Web y para el acceso a usuarios; cuando la HTML5 Ajax,
la aplicación se requiere
Procedimiento aplicación no
de desarrollo requiera de
de Sistemas JQuery
de información
que el equipo esté en la velocidades de ejecución
red del servidor. extremas.
Recibe este nombre las Cuando se requiera de
aplicaciones que se una alta velocidad o
ejecutan en ambiente interacción con el
D.O.S, que requieren de ambiente; cuando la C, C++, QBasic,
Consola mucha interacción con el aplicación sea empleada Turbo Pascal,
teclado y que carecen de por pocas personas en .NET, Java…
controles prediseñados pocos computadores;
como botones, cajas de cuando no se manejen
texto, casillas de grandes volúmenes de
Estas aplicaciones se
caracterizan porque son
Cuando se requiera que la
accedidas desde
aplicación sea accedida a
dispositivos móviles Java JME, .NET
través de dispositivos
como celulares o PDA’s, Compact
móviles; cuando los
SmartPhones o Tablets. Framework,
procesos a ejecutar son
Móvil Windows
livianos; cuando se
En este ambiente, la Phone, Android
requiera acceso a la
información puede residir
información sin
en el dispositivo móvil o WML, HTML5
limitaciones del lugar o del
en un servidor y ser
puesto de trabajo.
accedida desde el
dispositivo móvil.

Es importante aclarar que un proyecto puede tener una

combinación de los diferentes tipos de ambientes vistos.
Para la selección del ambiente de ejecución es importante tomar
como base la información obtenida en la fase de definición de los
requerimientos, particularmente en el listado de requerimientos no
funcionales.
Al tener claro el ambiente de ejecución, ya se pueden descartar

ciertas tecnologías y plataformas de desarrollo.
- Tener en cuenta las restricciones o limitaciones impuestas.
Durante la fase de definición de los requerimientos, se debe

reconocer las restricciones impuestas por la empresa. Algunas de
estas restricciones pueden estar relacionadas con la tecnología a
emplear, por ejemplo, es posible que la empresa haya invertido un
gran capital en la adquisición de ciertas licencias de software y exija
el desarrollo del proyecto con esas tecnologías. En ese caso, se
debe evaluar la tecnología 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 tecnología, en
caso contrario, el desarrollo del proyecto puede sufrir un retraso
considerable.
Otra restricción frecuente es la de tener que emplear tecnologías

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 tecnología libre apta para el
desarrollo del proyecto en la que el desarrollador tenga más
experiencia.
El Analistas y Desarrolladores en cualquiera de los casos puede

sugerir la tecnología adecuada para el desarrollo del proyecto
siempre y cuando tenga la justificación y argumentación técnica
suficiente para hacerlo.

- Evaluar las tecnologías candidatas.
Si el desarrollador es libre de elegir la plataforma de desarrollo, se

deben evaluar las características del proyecto, sus requerimientos
no funcionales e investigar las características de las diferentes
plataformas de desarrollo.
Es de gran importancia la elección del sistema manejador de bases

de datos porque este será el responsable del almacenamiento y
administración de toda la información del proyecto, de igual
manera, el lenguaje de programación de alto nivel elegido es
importante, pues algunos poseen gran riqueza de funciones, otros
son orientados a objetos y permiten la reutilización de clases, otros
poseen mayores fortalezas de seguridad.
La experiencia es sin duda una razón de peso para la elección de la

plataforma de desarrollo, ya que esta permite avanzar rápidamente
en la construcción 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, más temprano que tarde se dará cuenta que está
desarrollando en una herramienta obsoleta y el caos será mayor.
En conclusión, ante limitaciones de tiempo, es recomendable

emplear una herramienta conocida y en la cual se tenga
experiencia, sin dejar de investigar y aprender nuevas tecnologías
que en el caso de proyectos no críticos y sin limitaciones de tiempo
se pueden poner en práctica.

Inicio
Identificar Ambiente de Ejecución
Existen No
restricciones
Si
Son aptas No Evaluar las tecnologías

para candidatas
Si
Aumentar el tiempo de desarrollo No Se tiene la

estimado experiencia
Si
Tecnología Seleccionada
Fin
4.2.3 Diagramas de Análisis del Sistema
En la fase de análisis los diagramas deben estar enfocados en la

comprensión del sistema (actual y nuevo). Cada diagrama
presenta una vista del sistema desde diferentes niveles de
abstracción, por lo tanto, la elección de los diagramas requeridos
depende del aspecto del sistema en el que se desee concentrar la
atención.
Los diagramas no son excluyentes ni dependen exclusivamente de

una metodología o paradigma seleccionado, los diagramas son
expresiones gráficas de algo que se desea observar en un sistema,
por esta razón, lo importante es pensar en qué se desea observar y
a partir de esto, elegir el diagrama que permita hacerlo de la
manera más eficiente.

texto, casillas de grandes volúmenes de
Diagrama Qué representa Cuando Hacerlo
La relación entre el sistema de Siempre que se desee

estudio y otros sistemas presentar una imagen
Contexto externos. Permite identificar el del alcance el sistema
alcance del sistema. y su relación con otros
sistemas
El comportamiento del sistema. Cuando se desee

Permite identificar los procesos, comprender mejor
Flujo de Datos
su interacción y los principales cómo funciona el
almacenes de datos. sistema actual.
Las principales funcionalidades

que tendrá el nuevo sistema y
quiénes interactuarán con ellas.
Casos de Uso Son un referente para todas las Siempre
fases del desarrollo, desde la
definición de requerimientos
hasta las pruebas.
Los datos requeridos por el Siempre que el

sistema y la relación entre ellos. proyecto requiera de
Entidad Relación
Este diagrama dará origen a la una Base de Datos.
Base de Datos.
Los objetos que formarán parte Siempre que la

del sistema, sus datos y construcción de la
comportamiento. Se convierte aplicación se realice
Clases
en un insumo importante para el Orientada a Objetos.
diseño y la construcción de la
aplicación.

La interacción entre diferentes Cuando existan casos

objetos para cumplir con una de uso sobre los que
Secuencia /
funcionalidad del sistema. Los se desee conocer
Colaboración
mensajes transmitidos entre los cuáles son los pasos
objetos para cumplir una función. para llevarlos a cabo.
Cuando existan
objetos dentro del
sistema que cambien
Los diferentes estados por los
Transición de de estado e interese
que pasa un objeto en un
estados conocer las
sistema.
condiciones requeridas
para pasar de un
estado a otro.
La secuencia de pasos lógicos Cuando existan

Actividades / requeridos para cumplir con un procesos o funciones
Flujo propósito dentro del sistema. que se deseen
describir paso a paso.
La tabla anterior presenta un listado de los diagramas más

empleados dentro de la fase de análisis, normalmente, el diseño de
un diagrama requiere de varias revisiones y correcciones hasta
llegar a su versión final, por esta razón es importante estimar un
tiempo adecuado para la fase de análisis, con el fin de realizar los
diagramas de esta fase de la mejor manera posible ya que estos
serán insumos de vital importancia para el diseño del proyecto.

4.3 Fase de Diseño Presentar en un capítulo aparte
La fase de diseño es determinante para el éxito o fracaso del

proyecto, debido a que el diseño está directamente relacionado con
la calidad del software y será la principal referencia a tener en
cuenta durante la fase de construcción.
Existen diferentes tipos de diseños, pensados cada uno en
presentar una solución a un aspecto particular del proyecto, en esta
etapa, el desarrollador debe realizar aquellos que considere
necesarios para llegar a la fase de construcción con una guía que
oriente su trabajo, dejando poco a la imaginación. A continuación
se presentan algunos de los diseños más significativos
4.3.1 Diseño de la Base de Datos
TRATAMIENTOS
TraNumero
TraFechaAsignado
TraDescripcion
TraFechaInicio
TraFechaFin
TraObservaciones
TraPaciente
MEDICOS
1 MedIdentificacion
MedNombres
CITAS MedApellidos
CitNumero
CitFecha
PACIENTES CitHora
PacIdentificacion CitPaciente
1
PacNombres CitMedico
1 PacApellidos CitConsultorio
PacFechaNacimiento CitEstado
PacSexo CitObservaciones
CONSULTORIOS
1 ConNumero
ConNombre

A partir del diagrama Entidad Relación creado durante la fase de

Análisis, se debe generar el diseño 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 foráneas, sus relaciones,
restricciones de integridad referencial y cardinalidad. Este diseño
será la guía 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 Cliente
Nombre Tipo Tamaño Not Null PK FK Default Constraint Descripción
Id_cte Numérico 4 X X X Identificador del cliente
nomb_cte Carácter 50 X Razón social de la empresa
Tabla Producto
Nombre Tipo Tamaño Not Null PK FK Default Constraint Descripción
Id_prod Numérico 7 X X X Identificador del producto
nomb_prdo Carácter 80 X Nombre del medicamento
cto_uni Numérico 3 X Valor de cada medicamento
Pasando más al detalle, el diseño de archivos o diccionario de datos

toma cada uno de los campos presentes en las tablas (archivos) del
diseño de la base de datos y especifica su nombre, tipo de dato,
tamaño 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 foránea. Este diseño complementa el diseño
de la base de datos y es empleado durante la construcción de la
base de datos en el momento de definir las propiedades de cada
campo en el sistema manejador de bases de datos.

4.3.3 Diseño de Entradas y Salidas
ZONA DE TITULO x Este diseño especifica los pantallazos,

Zona de instrucciones para el usuario
Zona de ventanas, formularios o reportes requeridos
logotipo
por la aplicación para comunicarse con el
usuario, gracias a este diseño, es posible
Zona de entradas de usuario
conocer cuáles serán los datos solicitados al
usuario y cuáles serán los datos mostrados en
cada pantallazo, su ubicación, tipo de control
empleado y las características o restricciones
Zona de movimiento de Zona de operaciones con de cada campo.
registros registros
Para el desarrollo de este diseño se deben tener en cuenta ciertos

principios orientados a la ergonomía de la aplicación, 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
información de las salidas. Es recomendable realizar el diseño de
entradas y salidas después del diseño de la base de datos para
garantizar que los campos de la base de datos van a ser
alimentados a través de las entradas y que las salidas diseñadas
solo podrán presentar información calculada u obtenida de los
campos de la base de datos.
4.3.4 Diseño de Casos de Uso
Registrar Cliente
CÉDULA
NOMBRE
TELÉFONO
REGISTRAR Registrar cliente
Generar Factura Validar usuario
IDFACTURA
FECHA Generar factura
VALOR
GENERAR
Fuente: Los autores

Los diagramas de casos de uso y la descripción de casos de uso

realizada en la fase de análisis junto a los diseños de entradas y
salidas se unen para generar el diseño de casos de uso, el cual
consiste en realizar un seguimiento de la interacción entre el actor
y la aplicación (descripciones de casos de uso) con las entradas y
salidas diseñadas. Este diseño es importante porque mantiene la
trazabilidad del proyecto y valida que las entradas y salidas
diseñadas son las suficientes para la ejecución de cada caso de uso.
4.3.5 Diseño de Clases
TForm
TFAboutBox TFAboutBox
+TFAboutBox(inout AOwuner:TComponent*) -con: TConexion*

+Datos(in producto:UnicodeString, in proyecto:UnicodeString, -actuador: TActuador*
in autor:UnicodeString,in version:UnicodeString) -grafica: TGrafica*
-conectado: bool
-continuar: bool
-manual: bool
TGrafica -inicializarGiro: bool
-cargarPerfil: bool
-pb: TPaintBox* -perfilCargado: bool
-im: TImage* -ficheroPerfil: UnicodeString
-y: unsigned it [][] -ficheroINI: UnicodeString
-x: unsigned short -imgCasco: unsigned short
-habilitada: bool -imgFlechasAB: unsigned short
-imgFlechasID: unsigned short
+TGrafica(in pb:TPaintBox*,in im:TImage*)
-VERSION: UnicodeString
+estado(in habilitada:bool)
-BUILD: UnicodeString
+limpiar()
-FECHA_VERSION: UnicodeString
+añadir(in valores:unsigned short*)
-NOMBRE: UnicodeString
-pintar(inout Sender:TObject*)
-PROYECTO: UnicodeString
-AUTOR: UnicodeString
+TFMain(in Owner:TComponent*)
TActuador -registro(in ac:AC_Accion_t,in activoAB:bool,
in activoID:bool)
-hLib: HINSTANCE -estado(in ES_Estado_T:es)
-oup32fp: oupfuncPtr -senal(in sn:SN_Senal_T)
-habilitado: bool -bateria(in carga:int,in maxima:int)
-error: bool -fuerza(in fu:unsigned short)
-cadenaError: UnicodeString -desviacion(in inc:short)
-entrenamiento(in fichero:UnicodeString,
+TActuador() in nivel:float)
+~Tactuador() -formulario()
+movimiento(in accion:AC_Accion_t,in giro:GI_Giro_t): bool -editsServidor(in activo bool)
+habilitar(in activo:bool) -labelsTiempoConexion(in activo:bool)
+inicializador(): bool -labelsFicheroPerfil(in activo:bool)
+estadoError(): bool -accionManual(in ac:AC_Accion_tin gi:GI_Giro_t)
+textoError(): UnicodeString -imagenCasco(in estado_casco:bool,in contactos:int*)
-puerto(in const short:valor): bool -tiempoConexion(in tiempo:float)

El diagrama de clases realizado durante la fase de análisis ahora es

refinado para convertirlo en el diseño de clases. Para lograr este
propósito se deben adicionar los tipos de datos y modificadores de
acceso a los atributos, se deben especificar los modificadores de
acceso, tipos de retorno, parámetros y tipos de parámetros de
entrada en los métodos; se deben identificar clases abstractas e
interfaces requeridas, así como la necesidad de incluir otras clases
de terceros.
En el diseño de clases también es importante reconocer patrones

de diseño que puedan ser útiles para la aplicación. Este diseño se
convertirá en la base para la construcción del proyecto cuando se
emplee el paradigma Orientado a Objetos.
4.3.6 Diseño de Interface
Aspectos como el color

de fondo, color del
texto, tipo y tamaño de
la fuente, textura,
logotipos, íconos e
imágenes son tenidos
en cuenta en el diseño
de interface. Este
diseño busca reducir
significativamente el
tiempo invertido en la
fase de construcción
ofreciendo a los
programadores estos
aspectos ya definidos
desde el diseño.

4.3.7 Diseño de Navegabilidad
Este diseño 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 página Web (navegar) desde
algún punto de la aplicación. Realizar este diagrama es útil para
identificar jerarquías y menús en los sitios Web.
4.3.8 Diseño de Seguridad y Control
El diseño de seguridad y control define el mecanismo de acceso a la

aplicación por parte de los usuarios, especifica los recursos de la
aplicación y los permisos sobre esos recursos que tendrá cada uno
de los roles que interactuarán con la aplicación y las demás
consideraciones especiales de seguridad y control que la aplicación
debe tener en cuenta.

4.4 Fase de Construcción
Con la fase de diseño finalizada adecuadamente, se tienen las

garantías para iniciar la fase de construcción del proyecto con la
certeza de tener las bases suficientes para una construcción del
proyecto coherente y consistente con las fases previas y que dará
solución a las necesidades planteadas.
En esta fase, generalmente se realizan las tareas de la construcción

de la Base de Datos (Back-End), la construcción de la Interface
Gráfica de Usuario (Front-End) y la codificación de los módulos del
sistema.
4.4.1 Relación con el diseño
El diseño de la base de datos y el diseño de archivos son los

insumos para crear la base de datos en el sistema manejador de
bases de datos seleccionado.
El diseño de entradas y salidas y el diseño de interface se toman

como referencia para la construcción de la interface gráfica de
usuario.
El diseño de clases, de casos de uso, de navegabilidad y de

seguridad y control dirigen la codificación de los módulos del
sistema.
Para el desarrollo de los elementos que forman parte de la fase de

construcción, además de tomar como referencia los diseños
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 construcción
Emplear convenciones facilita el mantenimiento del proyecto, la

corrección de errores, agiliza el proceso de construcción, promueve
la interoperabilidad del proyecto y la comunicación con otros
proyectos, crea un ambiente de confianza en el equipo de desarrollo
e independiza el proyecto del desarrollador que lo realizó.

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 parámetros universales elementales que
son idénticos 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 mayúscula 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

mayúscula 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
podría ser el nombre de la tabla obtenida de la relación 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 combinación de los nombres de las entidades
relacionadas.
Ejemplo:
INSTRUCURSOS
Podría ser el nombre de la tabla generada a partir de las entidades
Instructor y Curso.

Campos
- Los nombres de los campos deben emplear la convención Pascal

Case, la cual indica que se debe empezar en mayúscula 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 guión 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
Convención debe(n) estar al
Ejemplo
Elemento
inicio de la tabla.
- El (los) campo(s) Pascal Casing

definido(s) como llave(s) Empleado
foránea(s) debe(n)
estar al final de la tabla, su nombre debe hacer alusión a la tabla de
MovimientoDeTransaccion
donde Empezar con mayúscula la
clase procede y debe terminar con la letra F. Ejemplo:
Si en la tabla PRODUCTOS
primera letra de existe un campo
cada palabra y foráneo que hace
alusión al código
en de la categoría de la tabla CATEGORIAS, este
singular
campo se debe nombrar así:
Igual que las clases pero debe IArticulo
Interfaces
iniciar con la letra I
27
Camel Casing impuesto SENA - Servicio Nacional de Aprendizaje
FAVA - Formación en Ambientes Virtuales de Aprendizaje
Variables primerApellido
Empezar con minúscula y la
Prod_CategoriaF
donde:
Prod hace referencia a la tabla donde está el campo
Categoria indica que es un campo que hace alusión a la llave
principal de la tabla CATEGORIAS
F significa que es foráneo.
4.4.2.2. Convenciones de Programación
Para la codificación 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 serán
más claros y fáciles 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 aplicación, el

nombre más adecuado sería mnuSalir.
A continuación, se ofrece una lista de algunos controles comunes

con su respectivo prefijo y ejemplo. Esta lista es de simple
ilustración, 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

Control Descripción Prefijo Ejemplo

Adodc Datos ADO ado adoBiblio
Botón de
Button comando btn btnAceptar
Calendar Vista de mes mvw mvwPeriodo
Casilla de
CheckBox verificación chk chkSoloLectura
Cuadro
combinado,
cuadro de lista
ComboBox desplegable cbo cboIngles
Botones de
CommandButton comando cmd cmdSalir
CommonDialog Datos común dlg dlgAbrirArchivo
Data Datos dat datBiblio
Cuadrícula
enlazada a
DataGrid datos dtgrd dtgrdResultadosConsulta
Cuadro de lista
enlazada a
DataList datos dblst dblstTipoTrabajo
Cuadro de lista
DirListBox de directorios dir dirSource
Cuadro de lista
DriveListBox de unidades drv drvDestino
Selector de
DTPiker fecha dtp dtpEditado
Cuadro de lista
FileListBox de archivos fil filOrigen
Form Formulario frm frmEntrada
Frame Marco fra fraIdioma
Grid Cuadrícula grd grdPrecios

Barra de
desplazamiento
HScrollBar horizontal hsb hsbVolumen
Image Imagen img imgIcono
ImageList Lista de imágenes ils ilsTodosIconos
Label Etiqueta lbl lblMensajeAyuda
ListBox Cuadro de lista lst lstCodigos
ListView Visor de lista lvw lvwEncabezados
MAPI Sesión MAPI mps mpsSesion
Menu Menú mnu mnuAbrirArchivo
MSComm Comunicaciones com comFax
Hierarchical
MSHFlexGrid Flexgrid flex flexPedidos
OptionButton Botón de opción opt optGenero
Panel Panel pan panBotones
Cuadro de
PictureBox imagen pic picVGA
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 Cronómetro tmr tmrAlarma
Barra de
ToolBar herramientas tlb tlbAcciones
TreeView Visor de árbol tre treOrganizacion
UpDown UpDown upd updDireccion
Barra de
VScrollBar desplazamiento vsb vsbIndice

-Convenciones de Codificación
Cada lenguaje de programación sugiere el uso de ciertas

convenciones para nombrar los elementos que forman parte del
código fuente de un programa como las clases, variables,
constantes y métodos, por ejemplo, VB.Net emplea la convención
PascalCase que inicia con mayúscula el nombre de los métodos y
Java emplea la convención Camel Casing, la cual inicia con
minúscula sus métodos. El desarrollador puede de acuerdo con el
lenguaje emplear una convención u otra o simplemente puede
adoptar una convención para todos sus proyectos
independientemente del lenguaje de programación utilizado.
Ejemplo:
Tipo de
Elemento Convención Ejemplo
Pascal Casing Empleado

MovimientoDeTransaccion
clase Empezar con mayúscula la
primera letra de cada palabra y
en singular
Igual que las clases pero debe IArticulo

Interfaces
iniciar con la letra I
Camel Casing impuesto
Variables primerApellido
Empezar con minúscula y la
Locales, salarioTotal
primera letra de las siguientes
Parámetros y palabras con mayúscula calcularPrestaciones()
Métodos guardar()
consultarSaldoActual()

Parámetros y palabras con mayúscula calcularPrestaciones()
Métodos guardar() de información
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 Aplicación p
Mayúscula sostenida, si su PI
Constantes nombre es compuesto, se debe SALARIO_MINIMO
separar por guion bajo IVA
-Indentación
La indentación facilita la lectura, comprensión del código y el

seguimiento del flujo de un programa, es recomendado usar 3 o 4
espacios como indentación entre cada bloque
Ejemplo en VB:
If (salario>salarioMinimo) Then
impueto=salario*0.1
End If
Ejemplo en C#
Sin
Identar
Identación
estilo 1

Identación
estilo 1
Identación
estilo 2
En condiciones largas que combinen operadores lógicos, el código

es difícil de leer y seguir cuando esta se realiza en una sola línea.
If ((salario<=salarioMinimo) &&(edad<18) && (estrato<3) && (ma

{
descuento=matricula *0,5;
valorPagar=matricula-descuento;
}
En estos casos, es recomendable separar la condición en varias

líneas. Ejemplo:
If ((salario <=salarioMinimo) &&

(edad<18) && (estrato<3 &&
(matricula>promedioMatricula))
{
descuento=matricula *0,5;
valorPagar=matricula-descuento;
}
También es recomendado que aunque un bloque posea una sola

línea de código y por lo tanto se puedan omitir las llaves de apertura
y cierre, éstas siempre se agreguen, pues dan mayor legibilidad al
código y evitan posibles errores al modificar las acciones del bloque.

No recomendado:
While (cantAlumnos<alumnosTotales)
cantAlumnos++;
Sugerido:
While (cantAlumnos<alumnosTotales)
{
cantAlumnos++;
}
-Convenciones de los comentarios
•Preferir los comentarios en líneas aparte que al final de una línea

de código.
•Los comentarios deben estar en el mismo nivel de indentación que
el segmento de código a comentar.
•Iniciar el texto del comentario con una letra mayúscula.
•Finalizar los comentarios con un punto.
•Insertar un espacio entre el delimitador del comentario y el texto
del comentario.
Secciones de Comentarios

Encabezado Empezar todos los programas o archivos con un encabezado

del Programa descriptivo.
o Archivo
/*----------------------------------------------------------
* Programa o Archivo: <Identificador del Programa>
* Sistema: <Nombre del Sistema>
* Versión: <Número de la Versión actual>
* Autor: <Nombre(s) del Autor(es)>
Formato del * Fecha: <dd/mmm/aaaa>
Encabezado * Descripción: <Descripción del programa Funciones básicas>
[* Historial de modificaciones:
* Fecha Descripción Modificación Autor ]
*----------------------------------------------------------
*/

/* Método: <Nombre del Método>
* Descripción: <Descripción de Funciones básicas>
* Autor: <Nombre del Asociado>

Encabezado
de métodos, * Fecha: <dd-mm-aaaa>
funciones o * Descripción de Parámetros:

procedimient
os [* Historial de modificaciones:
* Fecha Descripción Modificación Autor
*---------------------------------------------------------]
*/
Antes de una sección mayor de un programa, escribir un bloque de
Secciones
comentarios que describan el procesamiento que es realizado en tal
Mayores
sección. Incluir comentario similar para la finalización del código.
/*-----
* Proceso para el Calculo de la Desviación Estandar
*-----
*/
Ejemplo
Sección ..
Mayor /*-----
* Fin de Programa
*------
*/

Identación
estilo 2
Comentarios Los comentarios de línea deben explicar el propósito y el
de línea comportamiento del código
Ejemplo mal IF rsClientes > limit

comentario /* Verifica si rsClientes es mayor que el límite. */
Ejemplo buen IF rsClientes > limit

comentario /* Verifica si todos los clientes se han mostrado */
• Escribir los programas con suficiente espacio para que no se vean

Espacios en densos.
Blanco
• Separar cada construcción del programa con al menos un espacio.
-Otras recomendaciones para la codificación 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 código más fácil de entender y modificar
+Evite el código quemado
En las condiciones de una estructura de control de flujo, no se debe

realizar comparaciones con constantes sean estas numéricas o de
texto, pues cualquier cambio en el comportamiento del sistema
generará gran esfuerzo en el mantenimiento de la aplicación.

Código Quemado
Código no
quemado

4.4.3 Arquitectura o Programación en 3 capas
Al momento de realizar la codificación de los módulos de una

aplicación Web, es posible tener en un mismo archivo (.php, .asp,
.aspx …) Todo el código mezclado para llevar a cabo la funcionalidad
que se pretende desarrollar con una determinada página Web, este
archivo contendrá entonces
• Código HTML con el que se le dará formato a la página

• Código PHP, ASP, ASP.NET …, con el que se atenderá la lógica
de la página.
• Código JavaScript o VBScript con el que se realizarán
validaciones o se le dará dinamismo a la página.
• Código SQL con el que se accederá a la Base de Datos para
enviar o recibir información de ella.
El hecho de tener todos estos códigos dentro de un mismo archivo

(Página Web), hace que el mantenimiento de la aplicación sea muy
dispendioso y que algún cambio bien sea en el diseño de la página,
en la Base de Datos o en las reglas del negocio genere grandes
dificultades para volver a interrelacionar todos los códigos
mencionados. Por esta razón surge un estilo de programación
conocido como Programación por Capas.
1. Capa de presentación 2. Capa de negocio 3. Capa de datos
SERVIDOR DE SERVIDOR DE
CLIENTES NEOCIACIÓN BASE DE DATOS

Este estilo de programación separa el desarrollo de la aplicación en

3 capas: La Capa de Presentación, La Capa de Negocio y la Capa de
Datos, dándole a cada capa una responsabilidad exclusiva y de esta
manera lograr la independencia de cada una de ellas con las demás,
obteniendo de esta forma las siguientes ventajas:
• Proporciona escalabilidad, capacidad de administración y

utilización de recursos mejorados.
• Cada capa es un grupo de componentes que realiza una función
específica.
• Se puede actualizar una capa sin recompilar otras capas.
4.4.3.1 Capa de presentación:
Es la encargada de mostrar al usuario la interface gráfica con la que

interactuará para ingresar u obtener información 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
ningún tipo de código diferente al necesario para presentar la
interface gráfica al usuario.
4.4.3.2 Capa de negocio:

Esta capa es la que contiene el código necesario para que la

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

información y por los componentes físicos en los que esta
información 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 presentación.
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 diseño como el MVC
(Modelo Vista Controlador) que al aplicarse en el desarrollo de un
software implícitamente implementa este tipo de arquitectura en
una aplicación.

GLOSARIO
Artefacto: En el Lenguaje Unificado de Modelado (UML), un

artefacto es la especificación de un componente físico de
información que es usado o producido por un proceso de desarrollo
de software, o por el desarrollo y operación 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 diseño de la

base de datos y permiten incorporar reglas a los datos.
CRUD:
10 es un acrónimo que se utiliza para denotar las cuatro
operaciones básicas
FAVA - a desarrollar
Formación sobre
en Ambientes Virtualeslos datos Creación
de Aprendizaje de datos
SENA - Servicio Nacional de Aprendizaje
o inserción de los mismos (Create), lectura o consulta de datos
(Read), actualización de datos ( Update) y borrado o eliminación de
los mismos (Delete)
Framework: Conjunto de librerias o utilidades para agilizar y

optimizar el desarrollo en un lenguaje de programación
determinado.
Front-end: En un aplicativo de software corresponde con la parte

que interactúan los usuarios del sistema.
Iterativo: Repeticiones sobre un conjunto de procesos.

BIBLIOGRAFÍA
Object Management Group (2013). UML. disponible en

http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

CREDITOS
Control de documento
Construcción Objeto de Aprendizaje
Procedimiento de desarrollo de
Sistemas de información
Desarrollador de contenido
Experto temático Andrés Julián Valencia
Asesor pedagógico Claudia Milena Hernández Naranjo
Producción multimedia Carlos Alberto Espinosa Gómez
Líder expertos temáticos Ana Yaqueline Chavarro Parra
Líder línea de producción Santiago Lozada Garcés

Guia

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Guia

Hochgeladen von

Copyright:

Verfügbare Formate

as

FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

2 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Línea base de requerimientos

Requerimientos Documento de análisis, elección de tecnología

Análisis incompleto Diseño

Requerimientos Administración de Requerimientos

3 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

4. Especificación de cada fase

4.1 Fase de Definición de los requerimientos

Esta es una fase de vital importancia para los proyectos, su

Actividades en la fase de Definición de Requerimientos:

Durante la planeación, el desarrollador debe identificar las principales

Inicialmente, se debe realizar una entrevista con el cliente líder y recopilar

4 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Iteraciones en la recolección de información

Iteración Propósito Fuente Técnica

5 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Durante la actividad de Extracción, el analista y desarrollador

Luego de extraer la información de las diferentes fuentes, esta

R1 R2 R3 R4 Una Matriz de requerimientos es

6 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Casos de uso Orden Químico Solicitante Proveedor

Cambiar orden U,D R R

Editar solicitantes C,U,R

Una Matriz CRUD es una técnica de análisis de requerimientos que

La especificación de los requerimientos pretende crear un

7 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Actividades en la fase de Definición de los Requerimientos

Contrato Pre Desarrollo

Cliente líder no conforme

9 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

4.2 Fase de Análisis

Luego de tener claramente establecidos los requerimientos del

En esta fase, también son útiles diferentes diagramas que además

Las actividades de la fase de Análisis son:

4.2.1 Estudio del entorno tecnológico

Todo proyecto requiere para su correcto funcionamiento de ciertos

En este punto, más que un estudio de viabilidad, se pretende es

10 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Es de vital importancia entonces conocer las características de

4.2.2 Elección de la Arquitectura de Desarrollo

Para el desarrollo de un proyecto de software, existen diferentes

La arquitectura seleccionada, será determinante para las demás

11 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Aspectos a tener en cuenta para la elección de la mejor alternativa.

Identificar el ambiente de ejecución adecuado

13 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Es importante aclarar que un proyecto puede tener una

Al tener claro el ambiente de ejecución, ya se pueden descartar

- Tener en cuenta las restricciones o limitaciones impuestas.

Durante la fase de definición de los requerimientos, se debe

Otra restricción frecuente es la de tener que emplear tecnologías

El Analistas y Desarrolladores en cualquiera de los casos puede

14 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

- Evaluar las tecnologías candidatas.

Si el desarrollador es libre de elegir la plataforma de desarrollo, se

Es de gran importancia la elección del sistema manejador de bases

La experiencia es sin duda una razón de peso para la elección de la

En conclusión, ante limitaciones de tiempo, es recomendable

15 FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Identificar Ambiente de Ejecución

Son aptas No Evaluar las tecnologías

Aumentar el tiempo de desarrollo No Se tiene la

+TFAboutBox(inout AOwuner:TComponent) -con: TConexion