Teoría general de sistemas
 
Unidad 4. Desarrollo de sistemas de información
 

Propósito de El estudiante conocerá las características del desarrollo de siste-

la Unidad mas de información.
Unidad 4 Desarrollo de sistemas de información
4.4. Roles en el desarrollo de sistemas de información
Temas
4.5. Diseño de software para sistemas de información
 

 
Resumen

En esta semana abarcaremos dos importantes temas sobre el desarrollo de sistemas de

información. Para comenzar veremos los roles que se deberán de tomar en el desarrollo
de un sistema de información, su importancia y sus responsabilidades.

Para después analizar los diferentes tipos de diseño para el desarrollo de software para
sistemas de información. Siendo éste la base del correcto funcionamiento de los nuevos
sistemas de información.

De acuerdo con esto responderemos las siguientes preguntas:

• ¿Cuáles son los roles y las responsabilidades de un desarrollador de sistemas de

información?

• ¿Qué tipos de diseño existen para el desarrollo de software en cuestión de

sistemas de información?
 
 

Teoría general de sistemas UVM En Línea 1

 
  

4.4. Roles en el desarrollo de sistemas de información

Los proyectos de sistemas de información deben de considerar a las personas, procesos,

productos, tecnología y la existencia de:

Ø Expectativas realistas
Ø Un administrador del proyecto
Ø Políticas e indicadores definidos
Ø Planeación sistemática y controlada
Ø Gestión de riegos
Ø Control de calidad
Ø Convergencia con fotosistemas
Ø Negociación
Ø Recursos bien definidos y asignados
Ø Control automático de código fuente
Ø Esquemas de innovación y cambio

Para poder desarrollar un sistema de información, se necesita como hablamos anterior-

mente, de personal capacitado que en muchas ocasiones toma el papel de un consultor,
pero eso no es todo, para poder realmente desarrollar un sistema de información hay dos
papeles esenciales para tener éxito. Estos papeles son el de coordinador de desarrollo de
sistemas de información y el programador de desarrollo de sistemas de información. En
ocasiones si el sistema de información es sencillo, se puede prescindir del programador.

Los roles que deberán de seguir estas personas son los siguientes (Russo, 2000):

Teoría general de sistemas UVM En Línea 2

 
  

Para poder desarrollar un sistema de información, el coordinador tendrá que considerar

que existen diferentes sistemas de información relacionados y que cada uno de ellos es
elemental para la creación del nuevo sistema de información. Los sistemas de información
relacionados son los siguientes (Haag y Cummings, 2008):

Teoría general de sistemas UVM En Línea 3

 
  

Ahora bien, ya que definimos los roles que deben de existir en el desarrollo de sistemas
de información y los tipos de sistemas de informáticos relacionados, explicaremos más a
fondo el proceso y su interacción con los roles presentados.

Existen seis fases importantes en el desarrollo de un sistema de información, que se

describen en el siguiente esquema (Senn, 2002):

Teoría general de sistemas UVM En Línea 4

 
  

1. Investigación preliminar
• Búsqueda del problema
• Magnitud del problema
• Alternativas al problema
• Viabilidad de soluciones y costos

Teoría general de sistemas UVM En Línea 5

 
  
En esta primera etapa del desarrollo de sistemas de información, el coordinador
tiene la labor de liderar al equipo de trabajo para realizar una investigación sobre el
problema que tiene la organización y la mejor forma de resolverlo.

2. Análisis de requerimientos
• Conocer cuáles serán los usuarios primarios y secundarios
• Reconocer las necesidades de los usuarios
• Delimitar las fuentes primarias y secundarias de información
• Diseñar, desarrollar e implementar requerimientos para cumplir con las
necesidades de la organización

En esta etapa el coordinador deberá de delimitar los requerimientos junto con los
usuarios y los administradores de la organización, para que de esta forma queden
definidos y cumplan con los objetivos de la organización. El programador deberá
de considerar los requerimientos y analizar si es posible implementarlos en una
aplicación para el sistema de información.

3. Diseño de sistemas
• Entradas
• Procesamiento de información
• Salidas
• Almacenamiento
• Procedimientos
• Recursos humanos

En esta etapa es donde el programador tiene más trabajo, ya que deberá de

analizar junto con el coordinador, todo lo que el sistema requiere y diseñarlo de
acuerdo a las necesidades de la organización

4. Adquisiciones y otras consideraciones

• Compatibilidad
• Análisis costo – beneficio

Teoría general de sistemas UVM En Línea 6

 
  
• Estándares1 de desempeño
• Servicios postventa
• Configuraciones
• Portabilidad

En esta etapa el coordinador y el programador trabajarán junto con los usuarios,

para determinar los requerimientos en cuestión de equipos, de evaluación,
configuraciones y portabilidad necesaria para el correcto funcionamiento del
sistema de información.

5. Implementación e instalación
• Desarrollo de aplicaciones específicas
• Pruebas
• Corrección de errores
• Creación de manuales de uso y procedimientos de uso
• Orientación y capacitación de los usuarios

En esta etapa el coordinador y el programador implementarán el sistema de

información mientras van realizando correcciones o desarrollando aplicaciones
específicas para la adaptabilidad del sistema de información a toda la
organización.

6. Seguimiento y evaluación
• Mantenimiento del sistema
• Evaluación del desempeño
• Evaluación de cumplimiento de objetivos
• Actualización del sistema de información

En esta etapa el coordinador deberá de establecer cuáles serán las evaluaciones,

quién las realizará y con qué periodicidad. De igual manera deberá de dar los
requerimientos para la actualización del sistema en caso de ser requerido.

                                                                                                                       
1
Estándares: Modelo o patrón.
 

Teoría general de sistemas UVM En Línea 7

 
  
Al desarrollar un sistema de información el coordinador deberá de igual manera tomar
estos puntos a consideración que García Bravo (2000) dan:

Ø El medio ambiente en el que operan las instituciones

Ø La cultura y políticas de la organización
Ø El apoyo de los directivos
Ø El grupo de interés apoyado por el sistema
Ø Las tareas y decisiones a ser apoyadas
Ø Los planes de negocio y de operación
Ø La infraestructura tecnológica existente y factible para ser adquirida en la
organización

A continuación veremos metodologías para realizar el desarrollo de los sistemas de

información.

4.5. Diseño de software para sistemas de información

Existen diferentes tipos de diseño de Este método de diseño en un principio

software para sistemas de información
de los cuales algunos siguen en uso
mientras que otros han evolucionado. En
esta semana veremos tres tipos de
diseño de software de acuerdo con
Korpela (2002).
fue de gran utilidad pero el problema es
que para pasar de una etapa a la otra
había que terminar la primera, produ-
ciendo un gran problema si algún cambio
era requerido. La etapa de mantenimien-
to consumía la mayor parte del costo de
producción y/o modificación del software.
Una de las ventajas del modelo en cas-

Diseño de modelo de cada es que la documentación se produ-

ce en cada fase. Su principal problema
cascada
es su inflexibilidad al dividir el proyecto
en distintas etapas. El modelo en casca-

Teoría general de sistemas UVM En Línea 8

 
  
da sólo se debe utilizar cuando los reque- probable que cambien radicalmente du-
rimientos se comprendan bien y sea im- rante el desarrollo del sistema

Debido a los nuevos requerimientos en el Las fases que contempla el modelo de la

desarrollo de software, surgen otros mo- cascada son el análisis y especificación
delos que tratan de solucionar los pro- de requerimientos, diseño, codificación,
blemas existentes, que se basaron en el integración y pruebas, liberación y man-
modelo en Cascada. Sus características tenimiento.
principales son:
Ventajas
▪ Es lineal ▪ Impone la necesidad de mucha
▪ Las actividades están relaciona- disciplina planificación y adminis-
das secuencialmente tración, en el proceso de desa-
▪ Cada etapa tiene una entrada y rrollo de software, venciendo así
una salida la filosofía de los procesos de
▪ Es rígido2 y sistemático3: La codificar y probar.
entrada de una actividad es la ▪ Impone la necesidad de que la
salida de la etapa anterior, por lo realización del producto debe ser
cual no se puede dar inicio a la pospuesta hasta que los objeti-
siguiente fase vos sean bien entendidos.
▪ Es monolítico: Existe una única
fecha de entrega Desventajas
▪ La implementación se pospone ▪ Retrasa la detección de errores
hasta que no se comprendan los hasta el final por lo cual es muy
objetivos difícil realizar cambios cuando el
▪ Los documentos a entregar rigen proceso está en las últimas fa-
el proceso de software ses.
▪ Toma mucho tiempo ver los re-

                                                                                                                        sultados.
2
Rígido: Riguroso, severo.
3
Sistemático: Que sigue o se ajusta a un sistema
 

Teoría general de sistemas UVM En Línea 9

 
  
▪ Es difícil mantener la trazabilidad y el código final.
entre los requerimientos iniciales
▪ Cuando los requerimientos no están bien definidos, no es posible aplicar este
modelo, pues ello incrementaría los riesgos y retrasaría el proceso.
▪ Si los requerimientos del usuario cambian es muy difícil satisfacerlos si el proceso
se encuentra en las últimas fases.
 

Modelo espiral

Este modelo se presenta como una espiral, en donde en cada ciclo se representa una
fase del proceso de software. El proceso en espiral pasa por la secuencia: análisis de re-
querimientos/ diseño/ implementación/ pruebas; más de una vez, con el fin de eliminar
riesgos y construir una versión parcial preliminar del producto para mostrar al cliente y
obtener una retroalimentación.

Teoría general de sistemas UVM En Línea 10

 

Este modelo se ajusta al avance de los proyectos típicos; sin embargo, requiere una ad-
ministración mucho más cuidadosa que la sencilla cascada, ya que ha sido desarrollado
para cubrir las mejores características
tanto del ciclo de vida clásico, como de la
creación de prototipos, añadiendo al
mismo tiempo un nuevo elemento: el
análisis de riesgo. Este cuidado adicional
se debe a que la documentación debe
ser consistente siempre que el proceso
termina una iteración completa. El código
debe corresponder al diseño documenta-
do y debe satisfacer los requerimientos
documentados.
La meta del modelo espiral del proceso
de producción del software, es propor-
cionar un marco para diseñar tales pro-
cesos, dirigido por los niveles de riesgo
en el proyecto actual. En comparación
con los actuales modelos, el modelo es-
piral se puede ver como metamodelo,
porque puede acomodar cualquier mode-
lo de proceso del desarrollo. Usándolo
como referencia, se puede elegir el mo-
delo de desarrollo más apropiado (evolu-
tivo con la cascada).
Los riesgos son las circunstancias poten-
cialmente adversas que pueden deterio-
rar el proceso del desarrollo y la calidad
del producto. El modelo de espiral se
Teoría general de sistemas
enfoca en identificar y eliminar los pro-
blemas de alto riesgo con el diseño de
un proceso cuidadoso, más que tratar
problemas triviales4.
La característica principal del modelo
espiral es que es cíclico y no lineal como
el modelo de la cascada. Cada ciclo del
espiral consiste en cuatro etapas, y cada
etapa es representada por un cuadrante
del plano cartesiano. El radio del espiral
representa los costos acumulados hasta
ese momento en el proceso; la dimen-
sión angular representa el progreso en el
proceso. El modelo representado me-
diante la espiral define cuatro actividades
principales:
1. Planificación: determinación de obje-
tivos, alternativas y restricciones.
2. Análisis de riesgo: análisis de alter-
nativas e identificación/ resolución
de riesgos.
3. Ingeniería: desarrollo del producto
del "siguiente nivel".
4. Evaluación del cliente: valoración de
los resultados de la ingeniería.
4
Triviales: Que carece de importancia, interés o
novedad.
UVM En Línea 11

 
el enfoque más realista para el desarrollo
Durante la primera vuelta alrededor de la de software y de sistemas a gran escala.
espiral se definen los objetivos, las alter- Utiliza un enfoque evolutivo para la inge-
nativas y las restricciones, y se analizan niería de software, permitiendo al desa-
e identifican los riesgos. Si el análisis de rrollador y al cliente entender y reaccio-
riesgo indica que hay una incertidumbre nar a los riesgos en cada nivel evolutivo.
en los requisitos, se puede usar la crea- Utiliza la creación de prototipos como un
ción de prototipos en el cuadrante de mecanismo de reducción de riesgo, pero,
ingeniería para dar asistencia tanto al lo que es más importante permite a quien
encargado de desarrollo como al cliente. lo desarrolla aplicar el enfoque de crea-
El cliente evalúa el trabajo de ingeniería ción de prototipos en cualquier etapa de
(cuadrante de evaluación de cliente) y la evolución de prototipos.
sugiere modificaciones. Sobre la base de
los comentarios del cliente se produce la Modelo de prototipo
siguiente fase de planificación y de análi-
sis de riesgo. En cada bucle5 alrededor
En este modelo se recopilan requisitos,
de la espiral, la culminación del análisis se aplican los principios del análisis y se
de riesgo resulta en una decisión de "se- construye un modelo a desarrollar deno-
guir o no seguir".
minado prototipo, con el fin de que sea
valorado por el cliente y el desarrollador.
Con cada iteración alrededor de la espiral
El paradigma de creación de prototipos
(comenzando en el centro y siguiendo puede ser abierto o cerrado: Abierto o
hacia el exterior), se construyen sucesi-
prototipo evolutivo, emplea el prototipo
vas versiones del software, cada vez como primera parte de una actividad de
más completa y, al final, al propio siste-
análisis a la que seguirá el diseño y la
ma operacional. construcción. Antes de poder elegir un
enfoque abierto o cerrado, es necesario
El paradigma del modelo en espiral para determinar si se puede crear un prototipo
la ingeniería de software es actualmente del sistema a construir.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5
Bucle: Secuencia de instrucciones que se repite
mientras se cumpla una condición prescrita.

 

Teoría general de sistemas UVM En Línea 12

 

Este modelo se describe de la siguiente
manera: una alternativa de enfoque para
la definición de los requerimientos con-
siste en capturar un conjunto inicial de
necesidades e implementarlas rápida-
mente con la intención declarada de ex-
pandirlas y refinarlas iterativamente al ir
aumentando la compresión que del sis-
tema tienen los usuarios y quien lo desa-
rrolla.
Este tipo de enfoque se llama "de proto-
tipos". También se le conoce como mo-
delado del sistema o desarrollo heurísti-
co. Ofrece una alternativa atractiva y
practicable a los métodos de especifica-
ción para tratar mejor la incertidumbre, la
ambigüedad y la volubilidad de los pro-
yectos reales. Dentro del enfoque de
prototipos se pretende que el modelo sea
operante, es decir, una colección de pro-
gramas de computadora que simulan
algunas o todas las funciones que el
usuario desea.
Para lograr lo anterior se utilizan las si-
guientes herramientas de software:
• Un diccionario de datos integrado
• Un generador de pantallas
Teoría general de sistemas
• Un generador de reportes no
guiado por procedimientos
• Un lenguaje de programación de
cuarta generación
• Un lenguaje de consultas no
guiado por procedimientos
• Medios poderosos de administra-
ción de base de datos
El modelo de prototipos comienza con
una actividad de sondeo, de esto sigue
una determinación de sí el proyecto es
un buen candidato para un enfoque de
prototipos. Los buenos candidatos son
aquellos que tienen las siguientes carac-
terísticas:
• El usuario no puede o no está
dispuesto a examinar modelos
abstractos en papel, tales como
diagramas de flujo de datos.
• El usuario no puede o no está
dispuesto a articular sus requeri-
mientos de ninguna forma y sólo
se pueden determinar sus reque-
rimientos mediante un proceso de
tanteo, o ensayo y error.
• Se tiene la intención de que el sis-
tema sea en línea y con opera-
ción total por la pantalla, en con-
UVM En Línea 13

 
traposición con los sistemas de
edición, actualización y reportes
operados por lote6.
• El sistema no requiere la especifi-
cación de grandes cantidades de
detalles algorítmicos, ni de mu-
chas especificaciones de proce-
sos para describir los algoritmos
con los cuales se obtienen resul-
tados.

De acuerdo con Baltazan y Philipps

(2013), estos modelos predominan en el
mercado y marcan a su vez métodos
para el diseño de sistemas de informa-
ción.

Con esto concluimos esta semana rela-

cionada con el desarrollo de sistemas de
información.

                                                                                                                       
6
Lote: Conjunto de cosas con características
comunes.
 

Teoría general de sistemas UVM En Línea 14

 
  
 

 
Referencias Bibliográficas

Baltazan, P. & Philipps, A. (2013). Business driven information systems. USA: McGraw
Hill.

García Bravo, D. (2000). Sistemas de información en la empresa. Madrid: Pirámide.

Haag, S. & Cummings, M. (2008). Information systems essentials. USA: McGraw Hill.

Korpela, M. (2002). Information systems development as an activity. Netherlands. Kluwer

Academic Publishers. 2002

OBrien, J. & Maracas, G. (2012). Introduction to information systems. USA: McGraw Hill.

Russo, N.L. (2000): Expanding the horizons of information systems development. In R.

Senn, J. (2002). Análisis y diseño de sistemas de información. Segunda edición. México:

Graw Hill.

Teoría general de sistemas UVM En Línea 15