AP07 PDF GuiDesSisInf PDF

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

Guía para el desarrollo de Sistemas de Información
ESTRUCTURA DE CONTENIDOS
Pág.
Introducción...................................................................................................................... 3
1. Objetivo.......................................................................................................................... 4
2. Alcance.......................................................................................................................... 4
3. Fases............................................................................................................................. 4
4. Especificación de cada fase......................................................................................... 4
4.1. Fase de Definición de los requerimientos.................................................................. 4
4.2. Fase de Análisis.......................................................................................................... 8
4.2.1. Estudio del entorno tecnológico............................................................................... 8
4.2.2. Elección de la Arquitectura de desarrollo................................................................ 9
4.2.3. Diagramas de Análisis del Sistema.........................................................................13
4.3. Fase de Diseño..........................................................................................................14
4.3.1. Diseño de la Base de Datos....................................................................................15
4.3.2. Diseño de Archivos (Diccionario de Datos).............................................................16
4.3.3. Diseño de Entradas y Salidas.................................................................................16
4.3.4. Diseño de Casos de Uso........................................................................................17
4.3.5. Diseño de Clases....................................................................................................18
4.3.6. Diseño de Interface.................................................................................................19
4.3.7. Diseño de Navegabilidad........................................................................................19
4.3.8. Diseño de Seguridad y Control................................................................................20
4.4. Fase de Construcción...............................................................................................20
4.4.1. Relación con el diseño............................................................................................20
4.4.2. Uso de convenciones durante la fase de construcción..........................................21
4.4.2.1. Convenciones en bases de datos........................................................................21
4.4.2.2. Convenciones de Programación.........................................................................23
4.4.3. Arquitectura o Programación en 3 capas...............................................................30
4.4.3.1. Capa de presentación..........................................................................................31
4.4.3.2. Capa de negocio..................................................................................................32
4.4.3.3. Capa de datos......................................................................................................32
Glosario............................................................................................................................34
Bibliografía.......................................................................................................................35
Control del documento.....................................................................................................36
FAVA - Formación en Ambientes Virtuales de Aprendizaje.
SENA - Servicio Nacional de Aprendizaje. 2

INTRODUCCIÓN
La presente guía de desarrollo de sistemas de información permite establecer el

procedimiento a seguir en la ejecución 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 aprendiz en formación.
Este procedimiento aplica especialmente para proyectos nuevos e inicia con la
especificación de los requerimientos del proyecto y termina con la construcción del mismo.

DESARROLLO DE CONTENIDOS
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.
2. Alcance
Este procedimiento aplica 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.
Documento de análisis,
Contrato Línea base de requerimientos elección de tecnología Documento de
SRS con casos de uso, firma diagramas de análisis,
pre desarrollo del contrato de desarrollo estrategias
diseño, diagramas
Definición de
Análisis Diseño Construcción
requerimientos
Requerimientos Análisis Diseño

incompletos incompleto incompleto
Administración de requerimientos
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, se debe estimar el precio, el tiempo y
los recursos necesarios para el desarrollo del proyecto, es posible que una vez finalizada
la definición de requerimientos, se decida no continuar con el proyecto por restricciones o
limitaciones que impidan su correcto desarrollo, como por ejemplo limitaciones como los
términos de tiempo y disponibilidad de recursos.

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 o usuario líder quien

debe estar en capacidad de brindar información de alto nivel (es decir información más
detallada), 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 realimentació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.

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
(Diagramas UML, casos de uso, diagramas de proceso, entre otras) 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.
Una matriz de requerimientos es una técnica de análisis de requerimientos que permite

confrontar cada requerimiento frente a los demás, 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 técnica es identificar conflictos
entre los requerimientos y llegar a la independencia entre los mismos.
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.
Por último en la fase de definición de los requerimientos (VALIDACIÓN), se debe realizar

la validación de la información recolectada, este es un proceso que se hace con el cliente
líder, en el cual se solicita revisar uno a uno los requerimientos definidos y hacer sus
sugerencias, este proceso se realiza hasta que el cliente líder se encuentre totalmente
de acuerdo con la especificación final de los requerimientos y es en este momento donde
se debe firmar el contrato de desarrollo, creando un compromiso donde el desarrollador
se compromete a realizar cada uno de los requerimientos especificados, y el cliente se
compromete a no solicitar ningún otro requisito que no esté dentro de estos requerimientos
especificados. En caso de solicitar algún requerimiento adicional, se debe de evaluar su
impacto en Tiempo, Alcance y Costo.
Figura 5. Actividades en la fase de Definición de los Requerimientos.

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.
Actividades de la fase de Análisis
- Estudio del entorno tecnológico.

- Elección de la Arquitectura de Desarrollo.
- 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, otros.
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.
Figura 6. Ejemplo de entorno tecnológico de
una empresa.
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.
Se debe elegir el ambiente (Web, Windows, 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
Ambiente Descripción Cuándo seleccionarlo
a emplear
Recibe este nombre
las aplicaciones Cuando la aplicación va a
basadas en ser utilizada desde un solo
formularios o computador o desde pocos;
ventanas y controles cuando la información que
.NET
típicos como botones, gestiona la aplicación no debe
(WinForms),
Windows cajas de texto, menús. ser compartida entre los Pc’s
Delphi, Java
Las aplicaciones en que ejecuten la aplicación;
Swing…
este ambiente tienen cuando se requiere de
que ser instaladas buena velocidad y buena
en cada computador presentación; muy útil para
donde se desee el manejo de gráficos.
utilizar.

Recibe este nombre

las aplicaciones que
Cuando la aplicación deba
son accedidas a través
ser accedida por varios
de los navegadores PHP, JSP,
usuarios desde diferentes
Web. Este tipo ASP.NET,
lugares; cuando los datos
de aplicaciones JavaScript,
Web de la aplicación deban ser
son alojadas en HTML, CSS,
compartidos por los usuarios;
un Servidor Web y HTML5 Ajax,
cuando la aplicación no
para el acceso a la JQuery
requiera de velocidades de
aplicación se requiere
ejecución extremas.
que el equipo esté en
la red del servidor.
Recibe este nombre
las aplicaciones
Cuando se requiera de una
que se ejecutan en
alta velocidad o interacción
ambiente D.O.S,
con el ambiente; cuando la
que requieren de
aplicación sea empleada por
mucha interacción
pocas personas en pocos
con el teclado y que C, C++,
computadores; cuando no se
carecen de controles QBasic, Turbo
Consola manejen grandes volúmenes
prediseñados como Pascal, .NET,
de información; cuando con
botones, cajas de Java
poca información se deban
texto, casillas de
realizar grandes cálculos
selección; estas
en poco tiempo, para
aplicaciones se
aplicaciones que se ejecuten
deben instalar en
en tiempo real.
cada equipo donde se
desee ejecutar.
Estas aplicaciones se
caracterizan porque
son accedidas desde Cuando se requiera que
dispositivos móviles la aplicación sea accedida
Java JME,
como celulares o a través de dispositivos
.NET Compact
PDA’s, SmartPhones móviles; cuando los
Framework,
Móvil o Tablets. procesos a ejecutar son
Windows
En este ambiente, la livianos; cuando se requiera
Phone, Android
información puede acceso a la información sin
WML, HTML5
residir en el dispositivo limitaciones del lugar o del
móvil o en un servidor puesto de trabajo.
y ser accedida desde
el dispositivo móvil.
Figura 7. Identificación del ambiente de ejecución.

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 analista y desarrollador 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 todos los casos es buena práctica hacer juicio de expertos que consiste en consultar
a expertos acerca de las alternativas de la solución y sus ventajas y desventajas, 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.
Figuro 8. Diagrama de flujo. Identificación del ambiente de ejecución.

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.
Ejemplo:
Diagrama Qué representa Cuando Hacerlo
La relación entre el sistema Siempre que se desee

de estudio y otros sistemas presentar una imagen del
Contexto
externos. Permite identificar alcance el sistema y su
el alcance del sistema. relación con otros sistemas.
El comportamiento del
sistema. Permite identificar Cuando se desee
Flujo de datos los procesos, su interacción comprender mejor cómo
y los principales almacenes funciona el sistema actual.
de datos.
Las principales
funcionalidades que tendrá
el nuevo sistema y quiénes
interactuarán con ellas.
Casos de uso Son un referente para todas Siempre.
las fases del desarrollo,
desde la definición de
requerimientos hasta las
pruebas.
Los datos requeridos por el
Siempre que el proyecto
sistema y la relación entre
Entidad relación requiera de una Base de
ellos. Este diagrama dará
Datos.
origen a la Base de Datos.

Los objetos que formarán

parte del sistema, sus
datos y comportamiento. Siempre que la construcción
Clases Se convierte en un insumo de la aplicación se realice
importante para el diseño Orientada a Objetos.
y la construcción de la
aplicación.
La interacción entre
diferentes objetos
Cuando existan casos de
para cumplir con una
uso sobre los que se desee
Secuencia / Colaboración funcionalidad del sistema.
conocer cuáles son los
Los mensajes transmitidos
pasos para llevarlos a cabo.
entre los objetos para
cumplir una función.
Cuando existan objetos
dentro del sistema que
Los diferentes estados por cambien de estado y
Transición de estados los que pasa un objeto en le interese conocer las
un sistema. condiciones requeridas
para pasar de un estado a
otro.
La secuencia de pasos
Cuando existan procesos
lógicos requeridos para
Actividades / Flujo o funciones que se deseen
cumplir con un propósito
describir paso a paso.
dentro del sistema.
Figura 9. Tipos de diagramas de análisis.
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
y con el mayor nivel de detalle ya que estos serán insumos de vital importancia para el
diseño del proyecto.
4.3. Fase de Diseño
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
Figura 10. Ejemplo de diseño de una base de datos.
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. Diseño de Archivos (Diccionario de Datos)
Figura 11. Diccionario de datos.

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
Este diseño especifica los pantallazos,

ventanas, formularios o reportes requeridos
por la aplicación para comunicarse con el
usuario, gracias a este diseño, es posible
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 de cada campo.
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, en lo posible obtener el visto
bueno del usuario final en la aprobación del diseño. 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 Registrar
TELÉFONO cliente
GENERAR
Validar usuario
Generar factura
IDFACTURA
Generar
FECHA factura
VALOR
GENERAR
Figura 13. Ejemplo de diseño de casos de uso.
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
Figura 14. Ejemplo de diseño de clases.
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.
Ingresa el teléfono del Ingresa la contraseña de usuario.Campo

domicilio del funcionario.No texto. Tamaño máximo 20. Aplicar
admitir letras. Campo texto formato especial para no observar la
Tamaño máximo 20. información ingresada.
Figura 15. Diseño de Interface.
4.3.7. Diseño de Navegabilidad
Figura 16. 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
Figura 17. Ejemplo de 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
El uso de convenciones hace parte del aseguramiento de calidad del proyecto, además
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 guion bajo.
Ejemplo:
Cuando se trate de tablas cuyo nombre es compuesto, el prefijo debe contener parte de
ambos nombres. Ejemplo:
El (los) campo(s) definido(s) como llave principal debe(n) estar al inicio de la tabla.
El (los) campo(s) definido(s) como llave(s) foránea(s) debe(n) estar al final de la tabla,
su nombre debe hacer alusión a la tabla de donde procede y debe terminar con la letra
F. Ejemplo: si en la tabla “PRODUCTOS” existe un campo foráneo que hace alusión al
código de la categoría de la tabla “CATEGORIAS”, este campo se debe nombrar así:
Prod_CategoriaF
Donde:
Prod hace referencia a la tabla donde está el campo Categoria donde indica que es un campo
que hace alusión a la llave principal de la tabla CATEGORIAS F y 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.
Control Descripción Prefijo Ejemplo

Adodc Datos ADO ado adoBiblio
Button Botón de comando btn btnAceptar
Calendar Vista de mes mvw mvwPeriodo
Casilla de
CheckBox chk chkSoloLectura
verificación
Cuadro combinado,
ComboBox cuadro de lista cbo cboIngles
desplegable
Botones de
CommandButton cmd cmdSalir
comando
CommonDialog Datos común dlg dlgAbrirArchivo
Data Datos dat datBiblio
Cuadrícula
DataGrid dtgrd dtgrdResultadosConsulta
enlazada a datos
Cuadro de lista
DataList dblst dblstTipoTrabajo
enlazada a datos
Cuadro de lista de
DirListBox dir dirSource
directorios
Cuadro de lista de
DriveListBox drv drvDestino
unidades

DTPiker Selector de fecha dtp dtpEditado

Cuadro de lista de
FileListBox fil filOrigen
archivos
Form Formulario frm frmEntrada
Frame Marco fra fraIdioma
Grid Cuadrícula grd grdPrecios
Barra de
HScrollBar desplazamiento hsb hsbVolumen
horizontal
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
MSHFlexGrid Hierarchical Flexgrid flex flexPedidos
OptionButton Botón de opción opt optGenero
Panel Panel pan panBotones
PictureBox Cuadro de 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 tlb tlbAcciones
herramientas
TreeView Visor de árbol tre treOrganizacion
UpDown UpDown upd updDireccion
Barra de
VScrollBar desplazamiento vsb vsbIndice
vertical
Figura 18. Lista de controles comunes.

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.
Tipo de Elemento Convención Ejemplo

Pascal Casing
Empezar con mayúscula Empleado
clase
la primera letra de cada MovimientoDeTransaccion
palabra y en singular.
Igual que las clases pero
Interfaces IArticulo
debe iniciar con la letra I.
impuesto
Camel Casing
primerApellido
Empezar con minúscula
Variables Locales, salarioTotal
y la primera letra de las
Parámetros y Métodos calcularPrestaciones()
siguientes palabras con
guardar()
mayúscula.
consultarSaldoActual()
Igual que las variables gSaldo
Variables Globales a nivel
locales pero deben empezar gEdad
de Archivo o Clase
con la letra g. gPaisOrigen
Igual que las variables
Variables Globales a nivel pUsuario
locales pero deben empezar
de Aplicación pCargoActual
con la letra p.
Mayúscula sostenida, si
PI
su nombre es compuesto,
Constantes SALARIO_MINIMO
se debe separar por guion
IVA
bajo.
Figura 19. Convenciones de codificación.
Indentación
La indentación facilita la lectura, comprensión del código, el seguimiento del flujo de
un programa y su mantenimiento posterior, es recomendado usar 3 o 4 espacios como
indentación entre cada bloque.

Ejemplo en VB:
If (salario>salarioMinimo) Then
impuesto=salario*0.1
End If
Ejemplo en C#
Sin Identar
Identación estilo 1
Figura 20. Ejemplo 1 de Identación.
Identación estilo 2
Figura 21. Ejemplo 2 de Identación.
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.

En estos casos, es recomendable separar la condición en varias líneas. Ejemplo:
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, porque
dan mayor legibilidad al código y evitan posibles errores al modificar las acciones del
bloque.
No recomendado:
Sugerido:
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 del Programa Empezar todos los programas o archivos con un

o Archivo encabezado descriptivo.
/*--------------------------------------------------
* 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)>
* Fecha: <dd/mmm/aaaa>
Formato del 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>
* Fecha: <dd-mm-aaaa>
Encabezado de métodos,
* Descripción de Parámetros:
funciones o procedimientos
[* Historial de modificaciones:
* Fecha Descripción Modificación Autor
*------------------------------------------------]
*/
Antes de una sección mayor de un programa, escribir un
bloque de comentarios que describan el procesamiento
Secciones Mayores
que es realizado en tal sección. Incluir comentario similar
para la finalización del código.
/*-----
* Proceso para el Cálculo de la Desviación Estándar
*-----
*/
..
Ejemplo Sección Mayor
/*-----
* Fin de Programa
*------
*/
Los comentarios de línea deben explicar el propósito y el

Comentarios de línea
comportamiento del código.

IF rsClientes > limit

Ejemplo mal comentario
/* Verifica si rsClientes es mayor que el límite. */
IF rsClientes > limit
Ejemplo buen comentario
/* Verifica si todos los clientes se han mostrado */
• Escribir los programas con suficiente espacio para que
no se vean densos.
Espacios en Blanco
• Separar cada construcción del programa con al menos
un espacio.
Figura 22. Lista de convenciones de los comentarios.
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
Figura 23. Ejemplo de código quemado.

Código no quemado
Figura 24. Ejemplo de 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.
Figura 24. Ejemplo de programación por capas.


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 y la posibilidad de reutilizar el
código en otros proyectos.
4.4.3.1 Capa de presentación
Figura 25. Ejemplo de 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
Figura 26. Ejemplo código 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
Figura 27. Ejemplo de capa de datos.
La capa de datos está conformada por las clases que almacenan información y realizan
la conexión al motor de bases de datos y las operaciones con la misma (Consultas,
inserción, actualización y eliminación de registros). 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: es un acrónimo que se utiliza para denotar las cuatro operaciones básicas a
desarrollar sobre los datos, creación de datos 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 librerías 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). OMG unified Modeling Language (OMG
UML) Superstructure. Recuperado de http://www.omg.org/spec/UML/2.1.2/
Superstructure/PDF/

CONTROL DEL DOCUMENTO
GUÍA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN
Centro Industrial de Mantenimiento Integral - CIMI

Regional Santander
Líder línea de producción: Santiago Lozada Garcés

Rosa Elvia Quintero Guasca
Asesores pedagógicos:
Claudia Milena Hernández Naranjo
Líder expertos temáticos: Rita Rubiela Rincón Badillo

Experto temático: Andrés Julián Valencia -V1
Rita Rubiela Rincón Badillo -V2
Diseño multimedia: Oscar Julian Marquez Sanabria
Programador: Francisco José Lizcano Reyes
Este material puede ser distribuido, copiado y exhibido por terceros si se

muestra en los créditos. No se puede obtener ningún beneficio comercial
y las obras derivadas tienen que estar bajo los mismos términos de la
licencia que el trabajo original.

AP07 PDF GuiDesSisInf PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

AP07 PDF GuiDesSisInf PDF

Cargado por

Copyright:

Formatos disponibles

FAVA - Formación en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje.

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 2

La presente guía de desarrollo de sistemas de información permite establecer el

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 3

Requerimientos Análisis Diseño

4. Especificación de cada fase

4.1. Fase de Definición de los requerimientos

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 4

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

De estas fuentes de información, se debe identificar al cliente o usuario líder quien

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 5

Durante la actividad de EXTRACCIÓN, el analista y desarrollador ejecuta las técnicas

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

Una matriz de requerimientos es una técnica de análisis de requerimientos que permite

La ESPECIFICACIÓN de los requerimientos pretende crear un documento con la línea

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 6

sistema y puede incluir anexos como diagramas de análisis del sistema.

Por último en la fase de definición de los requerimientos (VALIDACIÓN), se debe realizar

Figura 5. Actividades en la fase de Definición de los Requerimientos.

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 7

4.2. Fase de Análisis

Luego de tener claramente establecidos los requerimientos del sistema, de verificar su

Actividades de la fase de Análisis

- Estudio del entorno tecnológico.

4.2.1. Estudio del entorno tecnológico

En este punto, más que un estudio de

Conocer esta tecnología es importante para

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 8

4.2.2. Elección de la Arquitectura de Desarrollo

Para el desarrollo de un proyecto de software, existen diferentes alternativas referentes

Se debe elegir el ambiente (Web, Windows, Consola, Móvil); el sistema manejador de

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

• Identificar el ambiente de ejecución adecuado.

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 9

Recibe este nombre

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 10

Al tener claro el ambiente de ejecución, ya se pueden descartar ciertas tecnologías y

• Tener en cuenta las restricciones o limitaciones impuestas

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

El analista y desarrollador en cualquiera de los casos puede sugerir la tecnología adecuada

• Evaluar las tecnologías candidatas

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

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

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

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 11

desarrollo, ya que esta permite avanzar rápidamente en la construcción del proyecto y

Figuro 8. Diagrama de flujo. Identificación del ambiente de ejecución.

FAVA - Formación en Ambientes Virtuales de Aprendizaje.

SENA - Servicio Nacional de Aprendizaje. 12