Organización de Sistemas Informáticos

Aspectos de Análisis, Planificación y Gestión de Proyectos

Introducción a las intranets

Juan José Jiménez Delgado

Departamento de Informática - Universidad de Jaén
 Prólogo

La Organización de Sistemas Informáticos es una disciplina muy amplia que

abarca aspectos de Análisis, Planificación y Gestión de Sistemas y Proyectos
Informáticos. Debido a la gran cantidad de contenidos que se podrían tratar y a
la titulación a la que va dirigida (Organización Industrial), en este libro se
intentará realizar una recopilación de esos aspectos. Esta recopilación no
profundizará en todos los temas tratados, pues cada uno de ellos sería objeto
de un libro específico debido a su importancia. Además, como ya digo, va
dirigido a profesionales no informáticos, por lo que no podemos suponer unos
conocimientos que sí se exigen en otras disciplinas informáticas. El objetivo
primordial de este libro es que sirva de base para la asignatura de Organización
de Sistemas Informáticos, como una colección de apuntes. No obstante, puede
servir de iniciación en otras asignaturas o bien para dar una visión general de
esta disciplina.

La idea del libro es la de proporcionar a profesionales no informáticos los

conocimientos necesarios para analizar, planificar y gestionar un proyecto
informático. No se espera que realicen labores de analistas de sistemas, sino
que ante un proyecto informático sean capaces de entender su terminología,
notaciones y en líneas generales puedan supervisar un proyecto de este tipo.
Además muchos de los conocimientos adquiridos, como la Planificación
pueden servir igualmente para el desarrollo de sistemas no informáticos.

Los primeros capítulos se dedican a la Ingeniería de Sistemas y a la

Planificación y Gestión de Proyectos. En los siguientes se introduce al lector
en los Sistemas de Gestión de Bases de Datos y en los Sistemas Distribuidos y
Redes, así como su impacto en una organización. Los últimos capítulos del
libro se han enfocado a la justificación y diseño de intranets en empresas,
como sistemas que pueden ayudar a las organizaciones en la toma de
decisiones.

Por último, se han añadido una serie de apéndices que complementan y

resumen ciertos aspectos del libro y que pueden servir para repaso o
clarificación de conceptos.

Organización de Sistemas Informáticos 1 2 Organización de Sistemas Informáticos


ÍNDICE:
Prólogo ......................................................................................................................................1
MÓDULO I. INGENIERÍA DE SISTEMAS
Capítulo 1. Los Sistemas de Información ................................................................................13
1. Introducción .................................................................................................................13
2. Concepto de Sistema....................................................................................................13
3. Concepto de información.............................................................................................14
4. Sistemas de Información..............................................................................................14
5. Elementos de los Sistemas de Información..................................................................15
6. Estructura de los S.I. ....................................................................................................16
7. Aplicación de las técnicas informáticas a los S.I. ........................................................17
8. Arquitectura de los S.I. ................................................................................................18
Capítulo 2. Ingeniería de Sistemas ..........................................................................................21
1. Introducción .................................................................................................................21
2. Principios para el desarrollo de sistemas .....................................................................21
3. El ciclo de Vida............................................................................................................23
4. Planificación de Sistemas ............................................................................................24
5. Análisis de sistemas .....................................................................................................26
6. Diseño de sistemas.......................................................................................................28
7. Implantación de sistemas .............................................................................................30
8. Soporte de sistemas......................................................................................................32
9. Actividades cruzadas del ciclo de vida ........................................................................34
Capítulo 3. La Ingeniería del Software....................................................................................37
1. El Producto...................................................................................................................37
1.1. Evolución del software .........................................................................................37
1.2. El Software............................................................................................................38
1.3. Tipos de aplicaciones software .............................................................................39
1.4. Problemas relacionados con el Software. .............................................................39
2. El Proceso: La ingeniería del Software........................................................................40
2.1. Paradigmas de la I.S..............................................................................................41
2.1.1. Paradigma del ciclo de vida clásico ...............................................................43
2.1.2. Paradigma del prototipo.................................................................................44
2.1.3. Prototipos de necesidades ..............................................................................45
2.2. Técnicas de cuarta generación (T4G) ...................................................................46
MÓDULO II. PLANIFICACIÓN Y GESTIÓN DE PROYECTOS
Capítulo 4. Conceptos sobre Gestión de Proyectos.................................................................49
1. El espectro de la gestión...............................................................................................49
1.1. Personal.................................................................................................................49
1.2. El Problema...........................................................................................................50
1.3. El Proceso .............................................................................................................51
2. Gestión de Personal......................................................................................................51
3. Identificación del Problema .........................................................................................54
4. Actividades y tareas de ingeniería de software ............................................................55
4.1. Maduración del problema y el proceso .................................................................55
4.2. Descomposición del proceso.................................................................................56
Organización de Sistemas Informáticos
Capítulo 5. Planificación de proyectos software y Gestión del Riesgo ...................................57
1. Objetivos de la planificación del proyecto...................................................................57
2. Ámbito del software.....................................................................................................58
3. Recursos.......................................................................................................................58
4. Estimación del proyecto software ................................................................................59
5. Desarrollo de una estrategia de solución......................................................................60
6. Análisis de Riesgo........................................................................................................60
6.1. Identificación del Riesgo ......................................................................................62
6.2. Proyección y evaluación del riesgo.......................................................................63
6.3. Reducción, supervisión y gestión del riesgo .........................................................63
7. Gestión de expectativas................................................................................................64
Capítulo 6. Estimación de Costes y Plazos..............................................................................67
1. Introducción .................................................................................................................67
2. Métodos de estimación de costes .................................................................................67
2.1. Juicio de Expertos .................................................................................................68
2.2. Estimación por analogía........................................................................................68
2.3. Estimación por descomposición ...........................................................................69
2.4. Modelos de estimación .........................................................................................69
3. El modelo COCOMO ..................................................................................................69
3.1. Definiciones y suposiciones previas .....................................................................70
3.1.1. Tipos de proyectos .........................................................................................70
3.1.2. Tamaño del Software .....................................................................................70
3.1.3. Otras suposiciones .........................................................................................71
3.2. El modelo básico...................................................................................................71
3.2.1. Esfuerzo requerido para el desarrollo ............................................................71
3.2.2. Tiempo de desarrollo. ....................................................................................72
3.2.3. Observaciones ................................................................................................72
3.2.4. Ejemplo ..........................................................................................................72
3.3. El modelo intermedio............................................................................................73
3.3.1. Ecuaciones del modelo ..................................................................................73
3.3.2. Atributos del modelo......................................................................................73
3.3.3. Ejemplo ..........................................................................................................76
4. Críticas a los modelos de coste ....................................................................................77
5. Beneficios del uso de modelos de coste.......................................................................78
Capítulo 7. Planificación Temporal y Seguimiento del Proyecto............................................79
1. Conceptos básicos........................................................................................................79
2. Acerca de los retrasos ..................................................................................................80
3. Distribución de esfuerzo ..............................................................................................80
4. Definición de tareas .....................................................................................................81
4.1. Red de tareas .........................................................................................................81
5. Planificación temporal .................................................................................................82
5.1. Gráficos de tiempo................................................................................................82
5.2. Seguimiento de la planificación temporal.............................................................83
6. El Plan de Proyecto ......................................................................................................84
3 4 Organización de Sistemas Informáticos

Capítulo 8. Técnicas de Planificación Temporal.....................................................................87
1. Diagrama de hitos ........................................................................................................87
2. Diagramas de Gantt......................................................................................................87
3. Redes de precedencia ...................................................................................................89
4. Técnica PERT ..............................................................................................................89
4.1. Representación de una red PERT..........................................................................90
4.2. Cálculo de los tiempos más próximos (early):......................................................93
4.3. Cálculo de los tiempos más lejanos (late).............................................................94
4.4. Holgura total de una actividad y camino crítico ...................................................95
4.5. El proceso de trabajo con PERT ...........................................................................96
4.6. Valoración del método PERT ...............................................................................97
Capítulo 9. Control de calidad del Software y Gestión de la Configuración..........................99
1. Introducción .................................................................................................................99
2. Conceptos de calidad ...................................................................................................99
2.1. Calidad ..................................................................................................................99
2.2. Control de calidad ...............................................................................................100
2.3. Garantía de calidad..............................................................................................100
3. Garantía (aseguramiento) de calidad del software .....................................................100
3.1. Actividades de SQA............................................................................................101
4. Revisiones del software .............................................................................................101
5. Revisiones técnicas formales .....................................................................................101
6. Los estándares de calidad ISO-9000 ..........................................................................102
6.1. El estándar ISO-9001 ..........................................................................................102
7. Gestión de configuración software ............................................................................102
MÓDULO III. SISTEMAS DE BASES DE DATOS
Capítulo 10. Introducción a los SGBD ..................................................................................105
1. Propósito de los Sistemas de Bases de Datos ............................................................105
2. Visión de los datos .....................................................................................................106
2.1. Abstracción de Datos ..........................................................................................107
2.2. Instancias y Esquemas.........................................................................................107
2.3. Independencia de Datos ......................................................................................108
3. Modelos de Datos ......................................................................................................108
3.1. Modelos lógicos basados en objetos ...................................................................108
3.1.1. Modelo entidad-relación ..............................................................................108
3.1.2. Modelo orientado a objetos..........................................................................110
3.2. Modelos lógicos basados en registros.................................................................110
3.2.1. Modelo relacional ........................................................................................110
3.2.2. Modelo de red ..............................................................................................111
3.2.3. Modelo jerárquico........................................................................................112
3.3. Modelo de datos físico ........................................................................................112
4. Lenguajes de Bases de Datos .....................................................................................112
4.1. Lenguaje de definición de datos..........................................................................112
4.2. Lenguaje de manipulación de datos ....................................................................113
5. Gestión de transacciones............................................................................................113
6. Administrador de la Base de Datos............................................................................114
7. Usuarios de la Base de Datos.....................................................................................114
Organización de Sistemas Informáticos 5 6
Capítulo 11. Sistemas de BD en las Organizaciones.............................................................115
1. Compartir datos y bases de datos ...............................................................................115
1.1. Compartir datos entre unidades funcionales .......................................................115
1.2. Compartir datos entre diferentes niveles de usuarios..........................................115
1.3. Compartir datos entre diferentes localidades ......................................................117
2. Planificación estratégica de bases de datos................................................................117
2.1. El proyecto de planificación de la base de datos.................................................118
2.2. El ciclo de vida del desarrollo de la base de datos..............................................118
3. Bases de datos y gestión de control............................................................................119
3.1. Diseño de bases de datos.....................................................................................119
3.2. Formación del usuario.........................................................................................119
3.3. Seguridad e integridad de los datos.....................................................................120
3.4. Rendimiento del sistema de base de datos ..........................................................120
4. Riesgos y costos de las bases de datos .......................................................................120
4.1. Conflictos en las organizaciones.........................................................................120
4.2. Fracasos en el desarrollo de proyectos................................................................121
4.3. Malfuncionamiento del sistema ..........................................................................121
4.4. Costes imprevistos ..............................................................................................121
5. Desarrollo de la base de datos....................................................................................122
5.1. Planificación preliminar......................................................................................122
5.2. Estudio de viabilidad...........................................................................................122
5.3. Definición de requisitos ......................................................................................122
5.4. Diseño conceptual ...............................................................................................123
5.5. Implementación...................................................................................................123
5.6. Evaluación y perfeccionamiento del esquema de la BD .....................................123
MÓDULO IV. SISTEMAS DISTRIBUIDOS Y REDES
Capítulo 12. Comunicación de datos y redes de ordenadores...............................................127
1. Introducción ...............................................................................................................127
1.1. Redes y sistemas distribuidos .............................................................................127
1.2. Un modelo para las comunicaciones...................................................................128
2. Usos de las redes de computadoras............................................................................130
2.1. Redes para compañías.........................................................................................130
2.2. Redes para la gente .............................................................................................131
3. Hardware de red .........................................................................................................131
3.1. Redes de área local..............................................................................................132
3.2. Redes de área metropolitana ...............................................................................133
3.3. Redes de área amplia...........................................................................................133
3.4. Interredes.............................................................................................................134
Capítulo 13. Ingeniería del Software Cliente/Servidor..........................................................135
1. Estructura de los sistemas cliente/servidor ................................................................135
2. Componentes de software para sistemas C/S.............................................................136
3. Distribución de componentes de software .................................................................137
4. Líneas generales para distribuir componentes de aplicaciones..................................137
Organización de Sistemas Informáticos

MÓDULO V. SISTEMAS DE AYUDA A LA TOMA DE DECISIONES
Capítulo 14. Ingeniería del Software asistida por computadora...........................................141
1. Definición de CASE ..................................................................................................141
2. Niveles de integración CASE ....................................................................................141
3. Taxonomía de herramientas CASE............................................................................143
4. Entornos CASE integrados ........................................................................................147
5. La arquitectura de integración....................................................................................148
6. El depósito CASE ......................................................................................................150
6.1. El papel del depósito en I-CASE ........................................................................150
Capítulo 15. Internet e intranet..............................................................................................153
1. Un poco de Historia de Internet .................................................................................153
2. Cómo funciona Internet .............................................................................................153
3. Aplicaciones en Internet.............................................................................................154
4. La World Wide Web..................................................................................................154
5. El correo electrónico ..................................................................................................155
6. Dónde comienza intranet ...........................................................................................155
7. Intranet frente al trabajo en grupo tradicional............................................................156
7.1. Diferencias principales........................................................................................156
7.2. Homogeneidad de los PC’s .................................................................................157
7.3. Información corporativa estática básica..............................................................157
7.4. Datos corporativos ..............................................................................................157
7.5. Comunicación .....................................................................................................158
7.6. Gestión de documentos .......................................................................................158
Capítulo 16. Beneficios de intranet........................................................................................161
1. Introducción ...............................................................................................................161
1.1. Aumento de la eficiencia.....................................................................................161
1.2. Aumento de la efectividad ..................................................................................162
2. Niveles de uso y de impacto ......................................................................................162
2.1. Nivel uno: visualización de información general ...............................................162
2.2. Nivel dos: compartir los datos del negocio.........................................................163
2.3. Nivel tres: comunicaciones interactivas..............................................................164
3. Ventajas de intranet....................................................................................................165
3.1. Acceso a la información......................................................................................165
3.1.1. Las webs unen datos y documentos .............................................................166
3.1.2. Sistemas con aspecto y funcionamiento comunes .......................................166
3.2. Procesos empresariales .......................................................................................167
4. Los costes de intranet.................................................................................................167
4.1. El coste de mantener el contenido de intranet.....................................................168
4.2. Coste de mantenimiento de software intranet .....................................................168
4.3. La seguridad........................................................................................................168
Capítulo 17. Intranets en acción............................................................................................171
1. El contenido es la clave..............................................................................................171
2. ¿Es intranet la respuesta? ...........................................................................................171
3. Descubrir las necesidades ..........................................................................................172
4. Metas de una intranet .................................................................................................173
5. Comenzando con intranet ..........................................................................................175
6. Planificación de intranet ............................................................................................175
Organización de Sistemas Informáticos 7 8
APÉNDICES
Apéndice I. Análisis Estructurado de Sistemas .....................................................................179
1. Conceptos básicos......................................................................................................179
2. Diagramas de Flujo de Datos. ....................................................................................181
2.1. Pasos para realizar Diagramas de Flujo de Datos. ..............................................181
3. Componentes de los DFD ..........................................................................................183
3.1. Procesos. .............................................................................................................183
3.2. Almacenes de datos.............................................................................................183
3.3. Entidades externas. .............................................................................................184
3.4. Flujos de datos. ...................................................................................................184
4. Desarrollo de niveles de abstracción en los DFD. .....................................................184
5. Verificación y Validación de los DFD.......................................................................186
6. Diccionario de Datos..................................................................................................186
7. Descripción de Procesos ............................................................................................188
8. El proceso de obtención de modelos..........................................................................188
8.1. Modelo físico actual............................................................................................189
8.2. Modelo lógico actual...........................................................................................189
8.3. Modelo lógico nuevo ..........................................................................................190
8.4. Modelo físico nuevo ...........................................................................................191
Apéndice II. Técnicas de Obtención de Información.............................................................193
1. Introducción ...............................................................................................................193
2. Clasificación ..............................................................................................................193
3. Muestreo de documentación, formularios y archivos existentes ...............................194
4. Investigación y vistas a instalaciones.........................................................................194
5. Observación del entorno de trabajo ...........................................................................195
6. La Entrevista ..............................................................................................................196
6.1. Clasificación .......................................................................................................197
6.2. Plan de entrevistas...............................................................................................198
6.3. Estrategia de entrevista .......................................................................................199
6.3.1. Preparación ..................................................................................................199
6.3.2. La entrevista.................................................................................................201
6.3.3. Postentrevista ...............................................................................................202
7. Cuestionarios..............................................................................................................202
8. Diseño conjunto de aplicaciones................................................................................204
8.1. Definición del proyecto.......................................................................................205
8.2. Dirección de una investigación general previa ...................................................205
8.3. Planificar la sesión DCA.....................................................................................206
8.4. Dirección de la sesión .........................................................................................206
8.5. Presentar los resultados.......................................................................................206
Apéndice III. Tareas a realizar en la fase de definición de un proyecto...............................207
1. Análisis del sistema....................................................................................................207
1.1. Identificación de necesidades..............................................................................207
1.2. Estudio de viabilidad...........................................................................................208
1.3. Análisis económico.............................................................................................209
1.4. Análisis técnico...................................................................................................209
Tareas .........................................................................................................................210
2. Aspectos de Gestión del proyecto ..............................................................................211
Organización de Sistemas Informáticos
 Tareas .........................................................................................................................211
3. Planificación del proyecto..........................................................................................212
Tareas .........................................................................................................................212
4. Análisis de requisitos .................................................................................................214
Tareas .........................................................................................................................214
Apéndice IV. Formatos de Documento .................................................................................217
1. Entrevistas..................................................................................................................217
2. Análisis del Sistema y Planificación..........................................................................219
3. Plan de Proyecto Software .........................................................................................220
4. Estudio de Viabilidad.................................................................................................221
5. Especificación de Requerimientos del Software........................................................222
6. Identificación de la Documentación...........................................................................224
7. Manual de Usuario.....................................................................................................225
Apéndice V. Listas de Inspección..........................................................................................227
1. Revisiones ..................................................................................................................227
2. Especificación del Sistema ........................................................................................228
3. Planificación del Proyecto .........................................................................................229
4. Análisis de requerimientos del software ....................................................................230
5. Diseño ........................................................................................................................231
6. Codificación...............................................................................................................232
7. Prueba ........................................................................................................................233
Apéndice VI. Glosario de Términos ......................................................................................235
1. Los Sistemas de Información .....................................................................................235
2. Ingeniería de Sistemas ...............................................................................................236
3. La Ingeniería del Software .........................................................................................242
4. Conceptos sobre gestión de proyectos .......................................................................244
5. Planificación de proyectos software y gestión del riesgo...........................................247
6. Estimación de costes y plazos....................................................................................249
7. Planificación temporal y seguimiento del proyecto ...................................................251
8. Técnicas de planificación temporal............................................................................253
9. Control de calidad del software y gestión de la configuración ..................................255
10. Introducción a los Sistemas de Gestión de Bases de Datos .....................................257
11. Sistemas de Bases de Datos en las organizaciones ..................................................262
12. Comunicación de datos y redes de ordenadores ......................................................263
13. Ingeniería del software Cliente/Servidor .................................................................266
14. Ingeniería del Software asistida por computadora ...................................................268
15. Internet e intranet .....................................................................................................270
16. Beneficios de intranet...............................................................................................272
17. Intranets en acción ...................................................................................................274
Bibliografía.............................................................................................................................275

Organización de Sistemas Informáticos 9 10 Organización de Sistemas Informáticos

 Módulo I
INGENIERÍA DE SISTEMAS

Organización de Sistemas Informáticos 11 12 Organización de Sistemas Informáticos


Capítulo 1
Los Sistemas de Información
1. Introducción
Actualmente las empresas se enfrentan a un entorno comercial que se va haciendo más
complejo y difícil. Esto se debe a que el mercado requiere respuestas más rápidas. Nos
encontramos en un ámbito en el que los cambios resultan impredecibles. La eficacia de una
empresa depende de su capacidad para conseguir que sus elementos funcionen de manera
coordinada para la consecución de los objetivos fijados. Para esto debemos contar con la
información más adecuada para poder actuar y tomar las mejores decisiones.
2. Concepto de Sistema
Un sistema es un conjunto de elementos que interaccionan entre si, orientados a la
consecución de un objetivo común.
Para nuestros propósitos consideramos que un sistema suele estar situado en un entorno o
ambiente con el cual interactúa, recibe entradas y produce salidas. Un sistema puede formar
parte de otro sistema más general, sería un subsistema de ese sistema.
Elementos principales de un sistema.:
• Componentes del sistema
• Relaciones entre componentes = estructura del sistema.
• Objetivo del sistema
Otros elementos de un sistema (que nos ayudan a entender como son y funcionan los
sistemas)
• El entorno del sistema: que es aquello que lo rodea y dentro del cual está ubicado.
• Los limites del sistema: nos marcan la frontera entre el sistema y el entorno.
Usaremos un enfoque sistémico. Se denomina enfoque sistémico a la manera de estudiar o
analizar sistemas adoptando una visión global de los mismos, la cual se va refinando
progresivamente.
Organización de Sistemas Informáticos
3. Concepto de información
Un dato está constituido por los registros de los hechos, acontecimientos, transacciones, etc.
La información implica que los datos estén procesados de tal manera que resulten útiles o
significativos para el receptor de los mismos.
En cierto modo, los datos se pueden considerar como la materia prima para obtener
información. Más que la cantidad de información, importa la calidad de la información.
Podemos definir la calidad de la información como el conjunto de cualidades que además
de la capacidad de disminuir la incertidumbre, ayudan al receptor a tomar la decisión más
ventajosa.
Podemos considerar las siguientes cualidades para la información:
- Es relevante para el propósito de la decisión o el problema considerado.
- Es lo suficientemente precisa, es decir, exacta con la realidad, para que podamos
confiar en ella.
- Es lo suficientemente completa para el problema.
- Se comunica a la persona adecuada para la decisión.
- Se comunica a tiempo para que pueda ser útil para la decisión.
- Alcanza el nivel de detalle más adecuado.
- Es comprensible para el receptor.
4. Sistemas de Información
Toda empresa necesita una infraestructura para desarrollar sus actividades. Esto se deriva en
una serie de funciones a desarrollar, como:
1. Controlar y gestionar el empleo de los recursos financieros mediante la gestión
contable y la gestión económica.
2. Comercializar de manera óptima los productos o servicios, esta sería la actividad
comercial y de ventas.
3. Fabricar productos o crear servicios que vender en el mercado, sería la actividad del
departamento de producción.
Para que estas actividades se puedan realizar eficientemente deben coordinarse entre sí, para
ello las organizaciones poseen una infraestructura. Este sistema es el denominado Sistema de
Información de la empresa.
Podemos definir un Sistema de Información como:
“Un conjunto formal de procesos que, operando sobre una colección de datos estructurada
según las necesidades de la empresa, recopilan, elaboran y distribuyen la información (o
parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de
13 14 Organización de Sistemas Informáticos
dirección y control correspondientes, es decir las decisiones, para desempeñar su actividad de
acuerdo a su estrategia de negocio”.
6. Estructura de los S.I.
En líneas generales podemos representarlo mediante una pirámide de niveles:
El objetivo de un Sistema de Información es:

“Ayudar al desempeño de las actividades en todos los niveles de la organización mediante el

suministro de la información adecuada, con la calidad suficiente, dirigida a la persona
adecuada, en el momento y lugar oportuno y con el formato más adecuado para el receptor”.

5. Elementos de los Sistemas de Información

Procedimientos y las prácticas habituales de trabajo:
Los técnicos y directivos marcan unas pautas básicas para coordinar los distintos
elementos de la compañía. El Sistema de Información existe para dar soporte a la
gestión de la información.

Información:
Fig. 1-2. Estructura piramidal del S.I. de la empresa
Debe adaptarse a las personas que manejan el equipo disponible y a los
procedimientos de trabajo de la empresa.
Operaciones y transacciones:
Personas o usuarios: Procesamiento de actividades diarias (transacciones), acontecimientos rutinarios que
Individuos o unidades de la organización que introducen, manejan o usan la afectan a la organización (facturación, pagos, entrega de productos, ...)
información para realizar sus actividades.
Nivel operativo:
Equipo de soporte: Se realiza un análisis de los resultados, sobre todo de recursos consumidos en
Realiza la comunicación, el procesamiento y almacenamiento de la información. (un transacciones, para poder tomar decisiones a corto plazo y de consecuencias limitadas.
papel, lápiz, archivador, máquina de escribir, ordenador, ...)
Nivel táctico de la dirección:
Se ocupa de la asignación efectiva de recursos a medio plazo, con el fin de mejorar el
rendimiento de la empresa.
Objetivos
Nivel estratégico:
Trabaja a largo plazo y decide las líneas maestras que debe seguir la empresa en el
futuro. La información que se maneja es proporcionada en formatos resumidos y
variados, las decisiones tienen un alto componente subjetivo.
Procedimientos y
prácticas de trabajo En la empresa se dan dos tipos de flujos de información:

Horizontal: Se da entre personas del mismo nivel de autoridad y tiene el propósito

de coordinar responsabilidades compartidas. Se le suele llamar
información de coordinación.
INFORMACIÓN PERSONAL EQUIPO
Vertical: Se da entre distintos niveles en la jerarquía. Hay un flujo ascendente,
que consiste en informes de carácter histórico. Y un flujo descendente,
Fig. 1-1. Elementos de los Sistemas de Información que contiene órdenes, o solicitudes de información específica.

Organización de Sistemas Informáticos 15 16 Organización de Sistemas Informáticos

7. Aplicación de las técnicas informáticas a los S.I. 8. Arquitectura de los S.I.
Para mejorar el rendimiento de un S.I. se suelen incorporar medios informáticos. De esta En líneas generales los S.I. están formados por una serie de subsistemas:
forma tendremos distintos subsistemas, algunos de los cuales serán S.I. automatizados y otros
manuales. Subsistema de recursos humanos: (Tabla 1-1)

Encargado de la gestión completa del personal, habilitación, etc.

Organización o Empresa Las actividades relacionadas con el personal de las organizaciones podemos
clasificarlos en dos grupos:
Sistema de Información
- Gestión de personal
Sistema de Información - Gestión de nómina
automatizado
Subsistema de gestión comercial: (Tabla 1-2)
Sistema Informático
de Soporte
Encargado de la cartera de clientes, y por tanto, de la gestión de ventas.
Las actividades están orientadas a dos áreas:

- Gestión de ventas: conlleva la gestión de pedidos, admisión de pedidos,

facturación, envío, entrega, etc.
- Gestión de la comercialización: todo lo relacionado con los pasos previos a
la venta del producto y los pasos posteriores.
Fig. 1-3. El sistema de información automatizado en el contexto de la empresa

Subsistema de gestión contable y financiera:

En un S.I. automatizado podemos encontrar distintos niveles de sistemas:
Encargado del control interno o auditoria de la organización, pagos, ingresos, etc.
Primer nivel:
Las actividades son:
Es el más bajo. Se incluyen en este nivel los subsistemas informáticos que pueden dar - Control de activos fijos de la organización y del inventario como parte de los
soporte a un procesamiento de transacciones. Se le suele llamar también operacional mismos.
o transaccional. - Gestión de cobros y pagos.
- Pago de nóminas y otros pagos a empleados.
Segundo nivel: - Generación de informes contables y financieros que le sean requeridos.

Formado por los sistemas de información para la gestión. Ayudan a los usuarios de Subsistema de control de almacén: (Tabla 1-3)
mayor nivel de la empresa a tomar decisiones sobre asuntos de cierta regularidad,
moviéndose en los niveles operativo, táctico y estratégico de dirección. Encargado de la gestión de almacén, compras e inventario de existencias (stock)

Tercer nivel:

Constituido por los sistemas para el soporte de decisiones. Dan soporte y ayuda a
decisiones poco estructuradas en las que no hay métodos claros para tomarlas.

La automatización de un S.I. debe contemplar la elección del hardware y la configuración

más adecuada de software de base, así como la consecución de las aplicaciones software que
permitan cubrir las necesidades de información que marcan la estructura del S.I.

Organización de Sistemas Informáticos 17 18 Organización de Sistemas Informáticos

 Tabla 1-1. Subsistema de recursos humanos
Mantenimiento de la información histórica laboral, profesional y personal de los empleados.
Inventario de los puestos de trabajo existentes en la empresa y de las características más
adecuadas para su desempeño.
Evaluación de los empleados en función de los informes producidos por sus superiores.
Nivel
Generación de informes oficiales que son necesarios remitir a la administración pública (los
operativo
correspondientes Ministerios/Delegaciones de trabajo, hacienda y seguridad social).
Todo lo relacionado con la gestión de nuevas contrataciones de personal.
Generación de la información necesaria para que el subsistema de gestión económica lleve a cabo
el pago de las nóminas, retenciones, etc.
Estudio y planificación de las características profesionales para ocupar cada uno de los puestos de
trabajo existentes en el organigrama de la organización.
Planificación de las necesidades de recursos humanos en base a la consecución de los objetivos
Nivel táctico
de la empresa a corto y medio plazo.
Planificación del perfeccionamiento y formación de los empleados de la empresa, en paralelo con
los planes de incentivación del personal de la misma.
Nivel Realización de las tareas del nivel táctico bajo una perspectiva de medio y largo plazo.
estratégico

Tabla 1-2. Subsistema de gestión comercial

Gestión de la cartera de clientes, con la correspondiente captación de nuevos clientes y
mantenimiento de los existentes, mediante la programación de visitas, preferencias e historial de
los mismos con la empresa, e información económica y de crédito sobre los mismos.
Nivel
Consultas sobre las características y disponibilidad de los productos de la organización.
operativo
La gestión de la distribución y venta de los productos, es decir, los pedidos, envíos, entregas,
recepciones, etc., así como la gestión de los documentos que generan estas actividades y su
remisión a los departamentos correspondientes.
El estudio de toda la información recogida sobre los pedidos, ventas en firme y posibles ventas
realizadas, así como el resultado de estas ventas sobre los clientes, de forma que puedan
planificarse las siguientes campañas u operaciones comerciales de la organización.
Nivel táctico El estudio y gestión de las campañas o actividades de preventa, realizando las campañas de
publicidad y promoción de los productos, así como el estudio del mercado y posibles
competidores.
El estudio de los precios de los productos y las vías de distribución y venta de los mismos.
En este nivel, trabajando a años vista, se realizan estudios y planificaciones de marketing y
Nivel
distribución de los productos, estudiando el mercado y los diferentes sectores dentro del mismo
estratégico
sobre los que se pueda actuar, realizando predicciones de nuevos productos y sus posibles ventas.

Tabla 1-3. Subsistema de control de almacén

Las compras de materias primas y, por tanto, la gestión de pedidos a proveedores en función de
las existencias.
La recepción de las materias primas, verificación con respecto a los pedidos, control del estado
Nivel
de los envíos y actualización de existencias en el almacén.
operativo
Suministro de los productos a los departamentos de producción y ventas, para su remisión a los
clientes de los mismos (en base a pedidos) y fabricación, con las correspondientes actualizaciones
de las existencias en el almacén.
La toma de decisiones para obtener una gestión óptima del almacén en base a un volumen de
almacén que, a gasto mínimo, no afecte a los demás departamentos. En este sentido se tienen que
Nivel táctico
prever las cantidades mínimas de stock que permiten no interrumpir los procesos de ventas y
producción.
A este nivel no influye demasiado el subsistema de almacén debido a que el inventario de los
Nivel productos o, mejor dicho, el mantenimiento del mismo no es una actividad que influya en gran
estratégico medida sobre las previsiones a largo plazo. En este sentido, el subsistema de almacén se ve
influido por las estrategias o políticas generales de la empresa sobre otros subsistemas.

Organización de Sistemas Informáticos 19 20 Organización de Sistemas Informáticos


Capítulo 2
Ingeniería de Sistemas
1. Introducción
La estructura básica para el diseño de los sistemas de información viene dada por el
denominado ciclo de vida del desarrollo de sistemas. Un sistema de información debe
elaborarse cuidadosamente, para implantar un buen sistema de información es necesario
aplicar una serie de principios básicos esenciales que veremos a continuación. Aplicando este
método aumentaremos las posibilidades de conseguir el éxito en nuestro cometido.
A continuación definimos el ciclo de vida del desarrollo de sistemas como un proceso por el
que los analistas de sistemas, los ingenieros de software, los programadores y los usuarios
finales elaboran sistemas de información y aplicaciones informáticas.
Estamos ante una herramienta de gestión de proyectos aplicada a proyectos de desarrollo de
sistemas. Esta herramienta se rige por una serie de principios generales que deberían aplicarse
al desarrollo de sistemas, veámoslos a continuación.
2. Principios para el desarrollo de sistemas
Principio 1. Implicar al usuario:
Debemos implicar al usuario desde el comienzo de un proyecto, de manera que se reflejen sus
necesidades y no caigamos en la elaboración de un sistema que puede no resultar práctico, o
que realmente no es el sistema solicitado. Además es necesaria una buena comunicación entre
el equipo de desarrollo y los usuarios finales, de manera que no se produzcan equívocos, o
por lo menos traten de minimizarse. Para ello puede utilizarse una política de formación de
los usuarios, de manera que estos se familiaricen a su vez con el nuevo sistema (informático)
y éstos no sean reticentes al cambio que se les avecina.
Principio 2. Aplicar un método de resolución de problemas:
El ciclo de vida del desarrollo de sistemas en si un método de resolución de problemas para
fabricar sistemas. El analista de sistemas debe emprender todos los proyectos por medio de la
aplicación de algún tipo de método de resolución de problemas.
Organización de Sistemas Informáticos 21
Principio 3. Definir fases y actividades:
La mayor parte de los ciclos de vida se dividen en fases. Básicamente constan de:
planificación de sistemas, análisis de sistemas, diseño de sistemas, implantación de sistemas y
soporte de sistemas. Cada una de estas fases representa una inversión considerable de tiempo
y de trabajo, con lo que se subdividen en distintas tareas que pueden manejarse con mayor
facilidad.
Principio 4. Establecer normas de desarrollo y documentación:
En una organización dedicada al desarrollo de sistemas no sería deseable que cada trabajador
o grupo adoptara su propio ciclo de vida y normas para el desarrollo de un sistema particular,
sino que la organización adoptara unas normas generales y ciclos concretos adaptados a cada
tipo de proyecto, de manera que se asegure una consistencia a la hora del desarrollo de
distintos sistemas.
Además es necesario extender esta política a las normas de documentación. La
documentación es un tema que siempre se descuida o que se realiza a posteriori, debemos dar
la importancia que merece, como producto que sirve para la comunicación de nuestro trabajo.
Principio 5. Justificar los sistemas como inversiones de capital:
Al considerarlo de esta forma, debemos tener en cuenta dos aspectos. El primero nos indica
que ante un problema debemos buscar diferentes soluciones alternativas. El segundo que ante
cada solución debemos evaluar la viabilidad de cada una, sobre todo la económica.
Principio 6. Revisión del proyecto:
Al dividir un proyecto en distintas fases obtenemos la oportunidad de reevaluar su viabilidad
en cada una de ellas. Por medio de un método de control progresivo, pueden definirse
múltiples puntos de comprobación de la viabilidad a lo largo del ciclo de vida. En cualquier
punto de control de la viabilidad, todos los costes se consideran perdidos e irrelevantes para la
toma de decisiones.
En cada punto de control, el analista debería considerar:
1. La cancelación del proyecto si ha dejado de ser viable.
2. La reevaluación de los costes y los plazos si se ha ampliado el ámbito del proyecto.
3. El recorte de dicho ámbito si se ha congelado el presupuesto y el calendario.
Principio 7. Divide y vencerás:
Todos los sistemas forman parte de sistemas mayores. El analista debe ser consciente de que
el sistema en el que trabaja forma parte de un sistema mayor con el que interacciona. Si
conoce el funcionamiento de este sistema mayor, será capaz de valorar mejor los costes y el
tiempo para construir el nuevo sistema. Si cada sistema es subdividido en subsistemas, más
fáciles de comprender, más manejables, podemos construir sistemas mayores.
22 Organización de Sistemas Informáticos
Principio 8. Diseñar sistemas cambiantes:

Suele darse la situación de que se diseñen sistemas que satisfacen las necesidades de los
usuarios “para hoy”. Esta práctica resulta casi siempre un fracaso, pues los sistemas se
deterioran, surgen errores ocultos que llevan al “parcheado” de los programas, nuevos
requisitos o requisitos no contemplados que implican el nuevo diseño del sistema. Esto no
tiene que ser así, pues existen técnicas y herramientas que hacen posible el diseño de sistemas
capaces de crecer y cambiar cuando lo hagan las necesidades que los originaron.

3. El ciclo de Vida
Veamos el ciclo de vida de desarrollo de sistemas moderno, en primer lugar a grandes rasgos,
para a continuación ir profundizando en cada una de sus fases.

1. Planificación de sistemas: El ámbito de la planificación de sistemas puede ser toda la

empresa, una división de la misma o cualquier otro tipo de sus unidades organizativas.
Su propósito es identificar y establecer las prioridades sobre aquellas aplicaciones de
los sistemas de información cuyo desarrollo reporte máximos beneficios para la
empresa considerada en su conjunto. Esta fase indica la relativa madurez del
funcionamiento de los sistemas de información.

2. Análisis de sistemas: El dominio cubierto por el análisis de sistemas es una única Fig. 2-1. Fases del Ciclo de Vida
aplicación de sistemas de información. Su propósito es analizar el problema o la
situación de empresa de que se trate y, entonces, definir las necesidades de la empresa
con respecto a la creación o el perfeccionamiento de un sistema de información. Las 4. Planificación de Sistemas
necesidades de empresa no implican obligatoriamente una solución de tipo
informático. La función planificación de sistemas del ciclo de vida pretende señalar y establecer
prioridades sobre aquellas tecnologías y aplicaciones que producirán un beneficio máximo
3. Diseño de sistemas: El dominio que cubre el diseño de sistemas sigue siendo la para la empresa.
aplicación de sistemas de información única de que hablábamos en el análisis de
sistemas. Su propósito es diseñar una solución técnica, de tipo informático, que La planificación de sistemas es un proceso permanente. Debe repetirse regularmente para
satisfaga las necesidades de empresa según han sido especificadas durante el análisis asegurar:
de sistemas.
1. Que los sistemas de información se desarrollan conforme el plan.
4. Implantación de sistemas: El dominio que cubre la implantación de sistemas está 2. Que las decisiones de los directivos o los factores externos no han cambiado el plan.
definido por los componentes de tipo tecnológico de la aplicación de sistemas de
información que se diseñaron en la fase anterior. Su propósito es construir y/o Esta fase podemos dividirla en tres tareas:
ensamblar los componentes técnicos y poner en funcionamiento el sistema de
información nuevo o mejorado. 1. Estudio del cometido de la empresa

5. Soporte de sistemas: El dominio que cubre el soporte de sistemas es el sistema de Consiste en estudiar la misión de la empresa. Idealmente, el ámbito de la fase de
información puesto en producción mediante la implantación de sistemas. El propósito planificación debería ser toda la empresa, pero este ámbito debe reducirse a un
del soporte de sistemas es sostener y mantener el sistema durante el resto de su vida nivel manejable.
útil.

Organización de Sistemas Informáticos 23 24 Organización de Sistemas Informáticos

 - Una arquitectura de Tecnología que identifique las tecnologías de
Los analistas de planificación son profesionales dotados de una formación información que deberían utilizarse en las aplicaciones, y posiblemente en
especial, que deben pensar en la empresa incluso más que los analistas de sistemas el desarrollo de aplicaciones.
normales. Han de conocer la metodología de planificación que debe usarse y los
resultados que van a obtenerse. Se requiere que dispongan de una combinación 3. Análisis de áreas de empresa
muy especial de habilidades y experiencias, entre las que se incluyen la gestión de
empresas, el análisis y diseño de sistemas, la gestión de datos y el diseño de redes. Consiste en evaluar las áreas de empresa que han de identificarse y establecer
prioridades sobre proyectos de desarrollo específicos.
La misión de la empresa es la entrada a esta fase, tal y como se “descubre” en las
entrevistas y las reuniones en grupo con los propietarios de sistemas. El cometido
de la empresa se define normalmente en términos de:

- clientes
- productos y servicios
- recursos materiales
- recursos humanos
- lugares geográficos de operación
- estructuras y filosofía de gestión
- metas y objetivos corporativos
- restricciones de empresa
- factores críticos de éxito de la empresa
- otros criterios propios de la gestión

El producto obtenido son los planes de empresa. En el mejor de los casos, estos
planes ya existen, y esta fase tan sólo los traduce a términos o formatos útiles para
los propietarios de sistemas y analistas de planificación en posteriores fases de la
planificación.

2. Definir una arquitectura de información

Una arquitectura de información es un plan de selección de la tecnología de

información y el desarrollo de los sistemas de información necesarios para apoyar Fig. 2-2. Fases de Planificación del Sistema
el cometido de la empresa.

Las entradas a esta fase sirven para construir la arquitectura de información,
formada por:
- Una arquitectura de Datos que identifique y establezca prioridades acerca
de las bases de datos que han de desarrollarse.
- Una arquitectura de Redes que identifique y establezca prioridades acerca
de las redes informáticas que han de desarrollarse.
- Una arquitectura de Actividades o Aplicaciones que identifique y
establezca prioridades acerca de las áreas de empresa para las cuales deben
rediseñarse procesos de empresa y/o sistemas de información.
- Una arquitectura de Personas necesaria para desarrollar y apoyar la
gestión de bases de datos, redes y aplicaciones.
5. Análisis de sistemas
El Análisis de Sistemas es el estudio de un sistema actual de empresa y de información, y la
definición de las necesidades y las prioridades manifestadas por los usuarios para la
construcción de un nuevo sistema de información.
Veamos las fases en las que podemos dividir el Análisis de Sistemas:
1. Estudio de viabilidad del proyecto
Consiste en determinar si “merece la pena el proyecto”. Para poder hacerlo es
necesario definir previamente el ámbito o envergadura del proyecto. El ámbito del
proyecto incluye:

Organización de Sistemas Informáticos 25 26 Organización de Sistemas Informáticos

 - La identificación de usuarios, gestores y patrocinadores
- La detección de los problemas, las oportunidades y las normas que se
perciben.
- La identificación de cualquier tipo de restricción técnica o de empresa y las
soluciones o expectativas posibles o percibidas

Una vez dada esta información, el analista evaluará la viabilidad inicial del ámbito
del proyecto.

A raíz de este estudio puede llegarse a una de las siguientes decisiones:

- Aprobar el proyecto y continuar.

- Cambiar el ámbito del proyecto y continuar con la fase siguiente.
- Rechazar el proyecto en su totalidad.
- Retrasar el proyecto a favor de otros proyectos.

2. Estudio y análisis del sistema actual

Esta fase proporciona al analista de sistemas una comprensión más profunda de

los problemas, oportunidades y/o normas que impulsan los proyectos. En la
práctica, el analista descubre con frecuencia nuevos problemas y oportunidades. Fig. 2-3. Fases de análisis de sistemas.
Durante el estudio es necesario descubrir las causas y efectos de los problemas, las
oportunidades y las normas.
6. Diseño de sistemas
Si el proyecto prosigue a la siguiente fase, el analista debería definir los nuevos
Una vez conseguido un conocimiento razonable de las necesidades de los usuarios, los
objetivos del sistema que han de transmitirse a la fase siguiente.
analistas de sistemas pueden centrar su atención en el diseño de sistemas. Es durante el diseño
de sistemas cuando los analistas de sistemas empiezan finalmente a estudiar las cuestiones y
3. Definir las necesidades de los usuarios y establecer prioridades
los detalles tecnológicos; en otras palabras, en “cómo” se implantará el sistema.
También denominada fase de definición. En ella el analista se acerca a los
El diseño de sistemas evalúa las soluciones alternativas y especifica la solución detallada de
usuarios para informarse de lo que necesitan o buscan en el nuevo sistema. Lo
tipo informático. También recibe el nombre de diseño físico.
principal es especificar estas necesidades sin expresar alternativas informáticas y
detalles de tecnología, definiendo el “qué” y no el “cómo”.
A su vez esta en esta fase podemos distinguir distintas etapas:
Estas necesidades, recogidas mediante diversas técnicas, como entrevistas, deben
1. Elegir una propuesta de diseño
ser traducidas a un modelo que represente el sistema. Este método se denomina
modelización y consiste en elaborar una o más representaciones gráficas de un
La primera fase del diseño de sistemas tiene la finalidad de elegir una propuesta de
sistema. La imagen resultante representa las necesidades planteadas por los
diseño viable. Implícita en esta fase está la necesidad de identificar en primer lugar
usuarios en tanto a datos, procesos y redes, desde el punto de vista de la empresa.
las soluciones de diseño candidatas.
Después de definir las soluciones candidatas, se evaluará cada una de ellas de
Otro método para traducir y validar las necesidades es el diseño de prototipos.
acuerdo a los siguientes criterios:
Este es el acto de construir un modelo de trabajo representativo a escala reducida
de las necesidades de los usuarios con el fin de descubrir o comprobar dichas
- Viabilidad técnica.
necesidades.
¿Es práctica la solución desde un punto de vista técnico? ¿Tienen las
personas que participan los conocimientos técnicos suficientes para diseñar
y llevar a término esta solución?

Organización de Sistemas Informáticos 27 28 Organización de Sistemas Informáticos

 - Viabilidad operativa.
¿Satisfará la solución las necesidades de los usuarios? ¿En qué medida?
¿Cómo hará cambiar la solución el entorno de trabajo del usuario? ¿Qué
opinan los usuarios de la solución?

- Viabilidad económica.
¿Es rentable la solución en lo que se refiere a costes?

- Viabilidad de fechas.
¿Puede la solución diseñarse e implantarse en un plazo aceptable de
tiempo?

El producto clave obtenido durante esta fase es la propuesta de sistema formal que
se presenta a los propietarios del sistema, quienes normalmente toman la decisión
final.

Las siguientes fases dependen de esa decisión, y se realizará una combinación de

las siguientes acciones:

- Adquirir el hardware y/o software necesario.

Fig. 2-4. Fases de diseño del sistema
- Diseñar un sistema y su software.

2. Adquirir el hardware y el software necesarios 7. Implantación de sistemas

Puede ser necesario adquirir software o hardware adicional al que ya tenemos. Se
ha incluido esta fase pues el aprovisionamiento de estos elementos requiere
tiempo, que transcurre en gran medida entre el pedido y la entrega.
3. Diseño e integración del nuevo sistema
Una vez aprobada la solución viable de la fase de selección, podrá finalmente
diseñarse e integrase el nuevo sistema. Se conocerán “cuáles” son las necesidades,
gracias a la fase de definición, y “cómo” se piensan satisfacer dichas necesidades,
gracias a la fase de selección. El producto final obtenido es una relación de diseño
técnico que se divide frecuentemente en dos partes: diseño general y diseño
detallado.
- El diseño general actúa como un esquema del diseño global
- El diseño detallado se centra en las especificaciones detalladas de los
componentes de dicho esquema.
La implantación de sistemas es la construcción del nuevo sistema y el paso de dicho sistema
a “producción”.
Hemos dividido esta fase en 4 tareas:
1. Construir y probar las redes y bases de datos
No siempre es necesaria esta fase, si la nueva aplicación requiere la elaboración de
redes y bases de datos nuevas o mejoradas, éstas deben implantarse antes de
escribir o instalar los programas informáticos. Esto se debe a que los programas de
aplicación utilizan dichas redes y bases de datos.
2. Construir y probar los programas
Esta fase es sólo aplicable a los componentes de software que se haya decidido
escribir, no comprar. Por otra parte, puede ser necesario también escribir
programas mejorados que amplíen un paquete de software comprado.

Las pruebas de unidad aseguran que los programas de aplicación funcionen de

forma adecuada cuando se prueban de forma aislada con respecto a otros
programas de aplicación.

Organización de Sistemas Informáticos 29 30 Organización de Sistemas Informáticos

 3. Instalar y probar el nuevo sistema
8. Soporte de sistemas
El soporte de sistemas es el mantenimiento continuado de un sistema después de que haya
No es raro que programas que funcionen correctamente por sí solos fallen cuando
sido puesto en funcionamiento. Ello incluye el mantenimiento de programas y las mejoras del
se combinan con otros programas relacionados. Por este motivo es necesario, tras
sistema.
instalar los programas, realizar las llamadas pruebas de sistema.
Las actividades de soporte no se llevan a cabo secuencialmente. Podemos verlas a
Las pruebas de sistema aseguran que los programas de aplicación escritos de
continuación:
forma aislada funcionen adecuadamente cuando se integran en el sistema global.
1. Corrección de errores
En esta fase también se instalan los paquetes de software comprados o alquilados.
Estos paquetes deberían ser probados para asegurar su correcta interacción con
Una vez puesto en funcionamiento el sistema, es inevitable que falle de cuando en
otros programas y paquetes.
cuando debido a errores de software o a defectos de uso. En consecuencia, una de
las actividades continuadas del soporte de sistemas es corregir errores.
4. Entrega del sistema
2. Recuperación del sistema
Debe procurarse una transición suave entre el antiguo sistema y el nuevo, para ello
el analista debe ayudar a los usuarios a resolver diversos problemas, como el
Un fallo del sistema puede provocar la mala terminación de un programa o la
arranque del sistema, a formarlos, proporcionarle manuales y el modo de cargar
pérdida de datos. Este hecho puede deberse a un error humano o a un fallo del
los archivos y bases de datos.
hardware o del software. Los usuarios notifican al analista la caída del sistema. El
analista de sistemas puede entonces ser instado a recuperar el sistema, esto es, a
restaurar sus archivos y bases de datos y volverlo a poner en funcionamiento.

3. Asistencia a los usuarios del sistema

Consiste en una asistencia adicional a los usuarios, cuando surjan problemas no

previstos, cuando se incorporen nuevos usuarios al sistema, etc. Además el
analista vigila el sistema y el trabajo de los usuarios.

4. Adaptación del sistema a nuevas necesidades

El mantenimiento de las adaptaciones obliga al analista a estudiar las situaciones

que se presenta y volver a las fases de análisis, diseño e implantación adecuadas.
Si la necesidad de mejoras se debe a nuevos problemas o requisitos, el analista
debe volver a las fases de análisis del sistema. Si se debe al uso de nuevas
tecnologías o problemas técnicos, el analista ha de volver a las fases de diseño
apropiadas. Si simplemente se perfecciona el sistema, el analista enviará
directamente los cambios de perfeccionamiento a las fases de implantación del
sistema.

Fig. 2-5. Fases de Implantación del sistema

Organización de Sistemas Informáticos 31 32 Organización de Sistemas Informáticos

 9. Actividades cruzadas del ciclo de vida
Las actividades cruzadas del ciclo de vida son actividades que se solapan en muchas o todas
las fases de todo el ciclo de vida; en realidad, normalmente se llevan a cabo de forma
conjunta durante varias fases del ciclo de vida.

Estas actividades incluyen la investigación de hechos, la documentación y las presentaciones,

las estimaciones y medidas, el análisis de viabilidad, la gestión de proyectos y las gestión de
procesos. Examinaremos brevemente cada una de estas actividades a continuación.

Investigación de hechos:

Es el proceso formal que emplea encuestas, entrevistas, reuniones, cuestionarios, muestreos y

otras técnicas para recoger la información de los sistemas, las necesidades y las preferencias.

La investigación de hechos es crucial en las fases de planificación de sistemas y análisis de

sistemas. Ello se debe a que es durante estas fases cuando el analista aprende el vocabulario
de la empresa y de sus sistemas, así como los problemas, las oportunidades, las restricciones,
las necesidades y las prioridades que se le asocian.

Documentación y presentaciones:

Las técnicas de comunicación son esenciales para terminar con éxito un proyecto. Existen dos
formas habituales de comunicación durante los proyectos de desarrollo de sistemas:
documentación y presentaciones:

- La documentación es una actividad consistente en registrar los hechos y las

especificaciones de un sistema.
- Las presentaciones son actividades relacionadas consistentes en el envío formal de la
documentación para su revisión por los usuarios y los directivos interesados.

El control de versiones de la documentación consiste en el almacenamiento y seguimiento de

Fig. 2-6. Fases de Soporte del sistema
múltiples versiones de la documentación de un sistema.

Estimación y medida:

Normalmente se realizan actividades de estimación y medida para estudiar la calidad y la

productividad de los sistemas, sobre todo debido a que los sistemas de información suponen
importantes inversiones de capital.

La estimación es la actividad encargada de calcular el tiempo, el esfuerzo, los costes y las

ventajas del desarrollo de un sistema.

La medida es la actividad consistente en medir y analizar la productividad y la calidad (y a

veces los costes) de las personas que desarrollan el sistema.

Organización de Sistemas Informáticos 33 34 Organización de Sistemas Informáticos

Análisis de viabilidad:

La viabilidad es la medida de las ventajas que el desarrollo de un sistema de información

podría proporcionar a una organización.

El análisis de viabilidad es la actividad por la cual se mida la viabilidad.

Un proyecto es viable en un momento determinado del desarrollo de sistemas y puede hacerse

menos viable o inviable en una etapa posterior. Por este motivo, se realiza un control
progresivo para reevaluar la viabilidad por medio de puntos de control adecuados.

Gestión de proyectos y procesos

Los proyectos de desarrollo de sistemas pueden implicar a un equipo de analistas,

programadores, usuarios y otros profesionales de los sistemas de información que han de
trabajar conjuntamente.

La gestión de proyectos es la actividad continuada por la cual el analista planea, delega,

dirige y controla el avance de los proyectos para desarrollar un sistema acorde con los plazos
y presupuestos asignados.

La gestión de procesos es una actividad continuada que establece normas para las
actividades, los métodos, las herramientas y los resultados del ciclo de vida.

Organización de Sistemas Informáticos 35 36 Organización de Sistemas Informáticos

 Tercera era: - Sistemas distribuidos
- Hardware de bajo coste (microprocesadores y PC’s).

Capítulo 3
- Impacto en el consumo.

Cuarta era: - Sistemas personales potentes.

- Entornos descentralizados, cliente/servidor.
La Ingeniería del Software - Redes de computadoras.
- Computación en paralelo.
- Sistemas expertos.

1.2. El Software
1. El Producto Definición informal: el software es:

Hoy en día el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehículo
para hacer entrega de un producto.
- Como producto: es un transformador de información: produce, gestiona, adquiere, modifica,
muestra o transmite información.
1. Instrucciones (programa) que cuando se ejecutan proporcionan la función y el
rendimiento deseados.
2. Estructuras de datos que permiten a los programas manipular adecuadamente la
información.
3. Documentos que describen la operación y el uso de programas.

- Como vehículo: es utilizado para hacer entrega del producto, el software actúa como la base
de control del ordenador (S.O.), la comunicación de información (Redes), y
la creación y control de otros programas (herramientas software y entornos).
El software hace entrega de un producto muy importante, la información.
1.1. Evolución del software
Características del Software:
Cuando se construye hardware (u otro producto), el proceso creativo humano (análisis,
diseño, construcción, prueba) se traduce finalmente en una forma física.
El software es un elemento del sistema que es lógico y tiene unas características
particulares:

- El software se desarrolla, no se fabrica en un sentido clásico.

Segunda era Cuarta era Los costes del software se encuentran en la ingeniería.
Primera era Tercera era
- El software no se estropea. No es susceptible a los males del entorno que hace que
el hardware se estropee.
1950 1960 1970 1980 1990 2000
Fig. 3-1. Gráfico temporal de la evolución del software

Primera era: - El software era un “arte”, para su desarrollo había pocos métodos
sistemáticos.
- No existía una planificación.
- El software como producto (a ser vendido y distribuido) estaba en la infancia.
- El análisis, diseño, codificación, depuración y ejecución estaba centralizado
en una sola persona.

Segunda era: - Surge la multiprogramación y los sistemas multiusuario.

- Se desarrolla el software de tiempo real. Fig. 3-2. Curvas del índice de fallos del hardware y del software
- Surge la primera generación de sistemas de gestión de Bases de Datos.
- Establecimiento del software como producto.

Organización de Sistemas Informáticos 37 38 Organización de Sistemas Informáticos

 · El software se deteriora. El software sufre cambios (mantenimiento), se
introducen nuevos fallos.
· El mantenimiento del software es más complejo que el del hardware. Si
un componente hardware se estropea se reemplaza. Pero no hay piezas de
repuesto para el software.
- La mayoría del software se construye a medida, en vez de ensamblar componentes
existentes. Los programas son una unidad completa.
1.3. Tipos de aplicaciones software
- Software de sistemas: programas escritos para servir a otros programas.
Compiladores, editores, utilidades de gestión de archivos, S.O.
Se caracterizan por su fuerte interacción con el hardware.
- Software de tiempo real: mide / analiza / controla sucesos del mundo real conforme
ocurren.
- Software de gestión: procesa información comercial; sistemas de nóminas, cuentas de
haberes/débitos, inventarios. Estas aplicaciones reestructuran los datos existentes para
facilitar las operaciones comerciales o gestionar la toma de decisiones.
- Software de ingeniería y científico: utilizan algoritmos complejos de tratamiento
numérico.
- Software empotrado: reside en memoria de sólo lectura y se utiliza para controlar
productos y sistemas de los mercados industriales y de consumo.
- Software de computadoras personales: procesamiento de texto, hojas de cálculo,
multimedia, juegos, gestión de B.D., aplicaciones de negocios y personales, etc.
- Software de Inteligencia Artificial: hace uso de algoritmos no numéricos para resolver
problemas complejos para los que no son adecuados el cálculo o el análisis directo.
El área más activa de la I.A. es la de los sistemas expertos.
1.4. Problemas relacionados con el Software.
- La construcción de programas no alcanza a la demanda.
- Dependencia de la operación fiable del software.
- Construcción de software fiable y de alta calidad.
Para resolver estos y otros problemas, surge la ingeniería del Software.
Organización de Sistemas Informáticos 39
2. El Proceso: La ingeniería del Software.
Definición previa de Ingeniería del Software (I.S.):
“Una disciplina tecnológica y administrativa dedicada a la producción sistemática de
productos de programación, que son desarrollados y modificados a tiempo, y dentro de un
presupuesto definido”.
De esta definición se pueden extraer los siguientes objetivos de la I.S.:
- Construir software de calidad.
- Aumentar la productividad del proceso de desarrollo.
- Mejorar la satisfacción personal de las personas implicadas.
- Disminuir los costes de producción.
- Disminuir los costes de mantenimiento.
La I.S. es una disciplina que tiene en cuenta tanto los aspectos técnicos como los
administrativos del proceso de desarrollo de software, no es solo programación, esta es una
tarea más dentro del proceso.
Definición de Ingeniería del Software:
“El establecimiento y uso de principios de ingeniería robustos, orientados a obtener
económicamente software que sea fiable y que funcione efectivamente sobre máquinas
reales”.
La I.S. incluye o está formada por tres elementos que se interrelacionan entre sí:
- Métodos: Suministran información para conocer como construir el software.
Abarcan actividades de planificación, análisis, diseño, etc.
- Herramientas: Sirven de soporte al proceso de producción, proporcionando
elementos para la ejecución de los métodos.
- Procedimientos: Son el nexo de unión entre los métodos y las herramientas.
Definen la secuencia en la que se deben aplicar los métodos, la
información que se requiere, las verificaciones o controles que
ayudan a asegurar la calidad del software y coordinan los
cambios y modificaciones sobre el mismo y las guías para
establecer su desarrollo.
40 Organización de Sistemas Informáticos
 - Análisis de requisitos: se realiza una descripción detallada de:
2.1. Paradigmas de la I.S.
· El ámbito del software,
Son modelos para el proceso de desarrollo del software. El gestor del proyecto elige el más · De la información requerida,
adecuado basándose en la naturaleza del proyecto a desarrollar. · De su procesamiento, y
· Del objetivo buscado.
Cualquiera que sea el paradigma o combinación de ellos utilizado, el desarrollo de software
comprende tres etapas genéricas, cada una compuesta de una serie de actividades: - Fase de Desarrollo: se centra en el cómo:

· Diseñar las estructuras de datos.

· Diseñar la estructura y arquitectura del software.
· Traducir la especificación con un lenguaje de programación.
· Verificar el producto construido.

Actividades:

- Diseño de software: Traducir las especificaciones del análisis de requisitos a

un conjunto de representaciones que describan la estructura de los
datos, la arquitectura, el procedimiento algorítmico y las
características de la interfaz.

- Codificación: Se traducen las especificaciones del diseño a una

Fig. 3-3. Etapas genéricas del desarrollo de software especificación entendible por la computadora.

- Fase de definición: se centra en el qué; intenta identificar: - Prueba: La especificación máquina obtenida debe ser probada para intentar
descubrir los defectos tanto de funcionalidad, como en la lógica y
· La información que ha de ser procesada. en la implementación.
· La función y el rendimiento deseado.
· Las interfaces. - Fase de mantenimiento: Se centra en el cambio asociado a la corrección de errores
· Las restricciones de diseño. detectados en las pruebas o mediante el uso de ese software, así como debido a las
· Los criterios de validación para definir un sistema software correcto. adaptaciones requeridas por la evolución del entorno del software o por cambios en
los requisitos.
Se realizan tres actividades genéricas:
Actividades:
- Análisis del Sistema: se define el papel de cada elemento de un sistema
informático, asignando finalmente al software el papel a desempeñar. - Corrección: Se procede a la corrección de los errores detectados en el
software.
- Planificación del proyecto: se realiza:
- Adaptación: Modificación del software para adaptarlo a los nuevos
· Una vez establecido el ámbito del proyecto, un análisis de riesgo. requisitos, o a un nuevo entorno.
· Asignación de recursos.
· Estimación de costes. - Mejora: Se amplía y mejora el software más allá de sus requisitos originales.
· Definición de tareas a desarrollar.
· Planificación del trabajo. Cada una de las fases se complementa con un conjunto de actividades cuyo objetivo es
garantizar la calidad del producto y del propio proceso de desarrollo.

Organización de Sistemas Informáticos 41 42 Organización de Sistemas Informáticos

2.1.1. Paradigma del ciclo de vida clásico
También denominado “modelo en cascada”, considera que las fases llevadas a cabo para la
construcción del software se realizan de forma secuencial.
Fig. 3-4. Ciclo de vida clásico del desarrollo de sistemas
- Ingeniería y análisis del sistema:
· Se estudia el sistema global en el cual se encuentra y se va a encontrar el software a
desarrollar.
· Se extraen los requisitos globales a nivel de sistema y se estudia el subsistema
software a un nivel de abstracción elevado.
- Análisis de requisitos software:
· Se procede a la recogida de información sobre el software a construir o problema a
solucionar.
· Se trata de comprender el dominio de información que manejará el software, así
como su procesamiento, rendimiento e interfaces para esos procedimientos.
· Los requisitos deben ser documentados y luego revisados con el cliente/usuario para
su validación.
- Diseño:
· Se traducen los requisitos recogidos en la fase anterior en una especificación formal
que pueda ser verificada y validada como paso previo a la construcción o codificación.
- Codificación:
· Se traduce la especificación formal a una especificación entendible por el ordenador.
- Prueba:
Organización de Sistemas Informáticos 43
· Se verifica el producto software.
· Se pretende asegurar que cada uno de los componentes software del producto
funcionan correctamente, asegurándose que todas las partes del software se han
probado y que cada una de ellas produce la salida esperada en base a una entrada
definida.
- Mantenimiento:
· Se introducen cambios en el software, bien debido a errores, o a cambios en los
requisitos.
Inconvenientes del paradigma de ciclo de vida clásico:
- Los proyectos raramente son secuenciales, se producen iteraciones.
- Los requisitos no se completan hasta fases posteriores. Los cambios en fases finales
originan graves problemas.
- Es posible que no se detecten los errores hasta que tengamos el producto. La
reparación de esos errores nos pueden ocasionar grandes retrasos y aumento de costes
debido a cambios en fases anteriores.
2.1.2. Paradigma del prototipo
El diseño de prototipos es una técnica de ingeniería utilizada para desarrollar modelos a
escala (o simulados) de un producto o de sus componentes. Cuando se aplica al desarrollo de
sistemas de información, el diseño de prototipos implica la creación de un modelo o modelos
iterativos de trabajo de un sistema o un subsistema.
La técnica de prototipos puede utilizarse en varias fases del ciclo de vida. Existen cuatro tipos
de prototipos de sistemas de información:
Prototipos de viabilidad:
Se utilizan para probar la viabilidad de una tecnología específica aplicable a un
sistema de información.
Prototipos de necesidades:
Se utilizan para “descubrir” las necesidades de los usuarios con respecto a la empresa.
Pretenden simular la forma de pensar de los usuarios. Su base es sencilla, los usuarios
reconocerán sus necesidades cuando las vean. Posteriormente veremos en detalle este
tipo de prototipo.
Prototipos de diseño:
44 Organización de Sistemas Informáticos

Se utilizan para simular el diseño del sistema de información final. Mientras que los
prototipos de necesidades se centraban sólo en el contenido, los prototipos de diseño
lo hacen en la forma y funcionamiento del sistema deseado. Cuando un analista crea
un prototipo de diseño, espera que los usuarios evalúen dicho prototipo como si
formara parte del sistema final. Así, los usuarios deberían evaluar la facilidad de
aprendizaje y de manejo del sistema, así como el aspecto de las pantallas y los
informes y los procedimientos requeridos para utilizar el sistema. Estos prototipos
pueden servir como especificaciones parciales de diseño o evolucionar hacia
prototipos de implantación.
Prototipos de implantación:
Constituyen una extensión de los prototipos de diseño donde el prototipo evoluciona
directamente hacia el sistema de producción. En principio, los prototipos de
implantación omiten normalmente detalles como la edición de datos, las seguridades y
los mensajes de ayuda.
2.1.3. Prototipos de necesidades
Fig. 3-5. Ciclo de vida del prototipo de necesidades
Es un proceso que facilita la creación de un modelo del producto a construir.
Este modelo puede ser:
- Un prototipo en papel que describa la interacción hombre-máquina de forma que
facilite al usuario la comprensión de cómo se producirá la misma.
- Un prototipo operativo el cual implementa algunos subconjuntos de las funciones
requeridas.
- Un programa existente que incorpore parte o toda la función deseada,
pero que tenga otras características a mejorar en el nuevo trabajo de
desarrollo.
Las actividades son:
Organización de Sistemas Informáticos 45
- Recolección de requisitos: se identifican los requisitos (no se exige que sean todos)
y se perfilan las áreas donde será necesario profundizar más tarde en el análisis.
- Diseño rápido: enfocado a la representación de los aspectos del software visibles
para el usuario del producto.
- Se realiza un prototipo de alguna de las formas expuestas. El prototipo es utilizado
para refinar o ampliar las especificaciones iniciales, realizar o modificar el diseño y
construir un nuevo prototipo.
- Una vez refinados y validados los requisitos podemos:
· Tomar el último prototipo como producto final.
· Destruir el prototipo total o parcialmente y, con toda la información obtenida
y el prototipo como muestra, construir un producto final en base al paradigma
clásico.
Ventajas: (respecto al paradigma clásico)
- Considera una participación activa del cliente en el desarrollo.
- El cliente ve un producto desde el primer momento.
- Los productos se adaptan mejor a los subsistemas de las organizaciones donde se
van a instalar, lo que garantiza un mejor uso de los mismos.
Inconvenientes:
- El cliente quiere comenzar a trabajar desde el primer momento con el prototipo para
solucionar el problema de la empresa.
- Los algoritmos pueden no estar optimizados en el prototipo, si este no se destruye y
se utiliza como producto final pueden darse problemas durante su uso y
mantenimiento.
2.2. Técnicas de cuarta generación (T4G)
Abarca un amplio espectro de herramientas de software que facilitan la especificación de
algunas características del software de alto nivel, la herramienta genera automáticamente el
código fuente basándose en la especificación.
El paradigma T4G para la ingeniería del software se orienta hacia la posibilidad de
especificar el software usando formas de lenguaje especializado o notaciones gráficas que
describan el problema a resolver en términos que los entienda el cliente.
46 Organización de Sistemas Informáticos
 Módulo II
PLANIFICACIÓN Y GESTIÓN
DE PROYECTOS

Organización de Sistemas Informáticos 47 48 Organización de Sistemas Informáticos

 ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su
capacidad de desarrollo de software.

Capítulo 4 Este modelo define las siguientes áreas prácticas clave para el personal que desarrolla
software:

Conceptos sobre - Reclutamiento

- Selección
Gestión de Proyectos - Gestión de rendimiento
- Entrenamiento
- Retribución
- Desarrollo de la carrera
- Diseño de la organización y del trabajo
- Desarrollo cultural y de espíritu de equipo
Vamos a estudiar los conceptos básicos que llevan a una gestión efectiva de proyectos
software. En los siguientes capítulos completaremos estos conceptos con actividades que nos Una organización que alcance una buena madurez en el área de gestión de personal tiene una
llevarán a la correcta supervisión del proyecto; estudiaremos técnicas para estimar los costes, mayor probabilidad de desarrollar eficazmente su trabajo.
métodos de planificación y técnicas para asegurar la calidad conforme se dirige un proyecto.
1.2. El Problema
1. El espectro de la gestión
Antes de realizar la planificación de un proyecto:
La gestión de proyectos es el proceso por el cual se planifica, dirige y controla el desarrollo
de un sistema aceptable con un coste mínimo y dentro de un período de tiempo específico. - se deben establecer sus objetivos y su ámbito,
- se deben considerar soluciones alternativas, e
Aunque las herramientas y técnicas del análisis y diseño de sistemas desempeñan un papel - identificar las dificultades técnicas y de gestión.
fundamental en obtener sistemas que funcionen, estos métodos no son suficientes por sí
mismos. Una mala gestión de proyectos puede dar al traste con los mejores métodos de Sin esta información, es imposible:
análisis y diseño de proyectos, o hacerlos ineficaces.
- definir unas estimaciones razonables del costo,
La gestión eficaz de un proyecto software se centra en tres aspectos fundamentales: - una valoración efectiva del riesgo,
- una subdivisión realista de las tareas del proyecto, o
- El personal, - una planificación del proyecto asequible.
- El problema, y
- El proceso. El equipo de desarrollo de software y el cliente deben reunirse para definir los objetivos del
proyecto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de
El gestor no debe olvidar que el trabajo de ingeniería es un esfuerzo humano intenso. Si no se ingeniería de sistema y continúa como el primer paso en el análisis de requisitos del
fomenta la comunicación con el cliente, puede que al final no construyamos el producto que software.
se requiere. Y si no se presta atención al proceso se corre el riesgo de no utilizar métodos y
herramientas que nos facilitasen el trabajo de desarrollo del proyecto software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se
conseguirán.
1.1. Personal
El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan el
problema, y más importante, intenta abordar estas características de una manera cuantitativa.
Debido a su importancia, el Instituto de Ingeniería del Software ha desarrollado un Modelo
de madurez de la capacidad de gestión de personal para aumentar la preparación de las
Una vez que se han entendido los objetivos y el ámbito del proyecto, se consideran las
organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones
soluciones alternativas. Las alternativas permiten seleccionar el mejor enfoque, dadas las

Organización de Sistemas Informáticos 49 50 Organización de Sistemas Informáticos


limitaciones impuestas por la fecha límite de entrega, restricciones de presupuesto,
disponibilidad de personal y otros muchos factores.
1.3. El Proceso
Un proceso de software proporciona la estructura desde la que se puede establecer un plan
detallado para el desarrollo del software.
Existe un pequeño número de actividades estructurales que se pueden aplicar a todos los
proyectos de software, sin tener en cuenta su tamaño o su complejidad.
Diferentes conjuntos de tareas (tareas, hitos, entregas), permiten a las actividades
estructurales adaptarse a las características del proyecto software y al equipo de proyecto.
Finalmente, las actividades protectoras, tales como garantía de calidad del software,
gestión de la configuración del software y medición, cubren el modelo de proceso. Estas
actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del
proceso.
2. Gestión de Personal
El proceso de software lo componen participantes que pueden clasificarse en una de cinco
categorías:
1. Gestores superiores: definen los aspectos de negocios que a menudo tienen una
influencia significativa en el proyecto.
2. Gestores técnicos del proyecto: deben planificar, motivar, organizar y controlar
a los profesionales que realizan el trabajo de software.
3. Profesionales: proporcionan las capacidades técnicas necesarias para la
ingeniería de un producto o aplicación.
4. Clientes: especifican los requisitos para la ingeniería del software.
5. Usuarios finales: interaccionan con el software una vez que se ha entregado.
Qué es lo que buscamos cuando seleccionamos a alguien para dirigir un proyecto de software:
- Resolución del problema: un gestor eficiente de un proyecto de software puede
diagnosticar los aspectos técnicos y de organización más relevantes, estructurar una
solución sistemáticamente o motivar apropiadamente a otros profesionales para que
desarrollen la solución.
Organización de Sistemas Informáticos 51
- Dotes de gestión: un buen gestor de proyecto debe tener confianza para asumir el
control cuando sea necesario.
- Incentivo de los logros: Para optimizar la productividad de un equipo, debe
recompensar la iniciativa y los logros, y demostrar a través de sus acciones que no se
penalizará si se corren riesgos controlados.
- Influencia y construcción de espíritu de equipo.
La mejor estructura de equipo depende del estilo de gestión de una organización, del número
de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del
problema.
Mantei sugiere tres formas de equipo genéricos:
1- Descentralizado democrático (DD):
· No tiene un jefe permanente, se nombran coordinadores de tareas a corto
plazo que se sustituyen por otros para tareas diferentes.
· Las decisiones sobre problemas y los enfoques se hacen por consenso del
grupo.
· La comunicación entre los miembros del equipo es horizontal.
2- Descentralizado controlado (DC):
· Tiene un jefe definido que coordina tareas específicas y jefes secundarios que
tienen responsabilidades sobre subtareas.
· La resolución de problemas es una actividad del grupo, pero la
implementación de soluciones se reparte entre los subgrupos por el jefe de
equipo.
· La comunicación entre subgrupos e individuos es horizontal.
· También hay comunicación vertical a lo largo de la jerarquía de control.
3- Centralizado controlado (CC):
· El jefe del equipo se encarga de la resolución de problemas a alto nivel y la
coordinación interna del equipo.
· La comunicación entre el jefe y los miembros del equipo es vertical.
52 Organización de Sistemas Informáticos

Constantine sugiere cuatro paradigmas de organización para equipos de I.S.:
1. Paradigma cerrado:
· Estructura a un equipo con una jerarquía tradicional de autoridad (similar a la
del equipo CC).
· Estos equipos trabajan bien cuando producen software similar a otros
anteriores, pero probablemente sean menos innovadores.
2. Paradigma aleatorio:
· Estructura al equipo libremente y depende de la iniciativa individual de los
miembros del equipo.
· Cuando se requiere innovación o avances tecnológicos, son excelentes.
Pueden chocar cuando se requiere un rendimiento ordenado.
3. Paradigma abierto:
· Intenta estructurar a un equipo de manera que consiga algunos de los
controles asociados con el paradigma cerrado, pero también mucha de la
innovación asociada al paradigma aleatorio.
· El trabajo se desarrolla en colaboración, con mucha comunicación y toma de
decisiones consensuadas.
· Es adecuado para la resolución de problemas complejos, pero su rendimiento
puede ser menos eficiente.
4. Paradigma sincronizado:
· Se basa en la división natural de un problema.
· Organiza los miembros del equipo para trabajar en partes del problema con
poca comunicación activa entre ellos.
Organización de Sistemas Informáticos 53
3. Identificación del Problema
El gestor de un proyecto software se enfrenta a un dilema al inicio de un proyecto. Se
requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de
información sólida. Un análisis detallado de los requisitos del software proporcionaría la
información necesaria para las estimaciones, pero el análisis a menudo lleva semanas o
meses. Aún peor, los requisitos pueden ser fluidos, cambiando regularmente a medida que
progresa el proyecto. Y aún así necesitar un plan de inmediato. Debemos examinar el
problema justo al inicio del proyecto, por lo menos se debe establecer el ámbito del problema
y delimitarlo.
El ámbito se define respondiendo a las siguientes cuestiones:
Contexto:
¿Cómo encaja el software a construir en un sistema, producto o contexto de
negocio mayor y qué limitaciones se imponen como resultado del contexto?
Objetivos de información:
¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué
objetos de datos son requeridos de entrada?
Función y rendimiento:
¿Qué función realiza el software para transformar la información de entrada en
información de salida? ¿Hay características de rendimiento especiales que
abordar?
La descomposición del problema, es una actividad basada en el análisis de requisitos del
software. Durante la exposición del ámbito no se descompone el problema totalmente, sino
que se aplica a dos áreas principales:
· La funcionalidad que debe entregarse, y
· El proceso que se empleará para entregarlo.
Suele aplicarse la estrategia de “divide y vencerás” que sirve para afrontar problemas
complejos. Para nuestro propósito, esta estrategia consiste en dividir el problema en
problemas más pequeños (que resultan más manejables).
Las funciones del software, descritas en la exposición del ámbito, se evalúan y refinan para
proporcionar más detalle antes del comienzo de la estimación.
54 Organización de Sistemas Informáticos
4. Actividades y tareas de ingeniería de software
Las fases genéricas que caracterizan el proceso de software (definición, desarrollo y
mantenimiento), son aplicables a todo el software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniería del software que debe aplicar el equipo del proyecto.

El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para el
proyecto, después debe definir un plan preliminar basado en un conjunto de actividades
estructurales válidas para cualquier proyecto. Una vez establecido el plan preliminar, empieza
la descomposición del proceso. Es decir, se debe crear un plan completo reflejando las tareas
requeridas a las personas para cubrir las actividades estructurales.

4.1. Maduración del problema y el proceso

Todas las funciones que se deben tratar dentro de un proceso de ingeniería por el equipo de
software deben pasar por el conjunto de actividades estructurales que se han definido para
una organización de software.
Un ejemplo de actividades estructurales asumidas por una organización podría ser:
· Comunicación con el cliente: tareas requeridas para establecer una comunicación
eficiente entre el desarrollador y el cliente.
· Planificación: tareas requeridas para definir los recursos, la planificación temporal
del proyecto y cualquier información relativa a él.
· Análisis de riesgo: tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería: tareas requeridas para construir una o más representaciones de la
aplicación.
· Construcción y entrega: tareas requeridas para construir, probar, instalar y
proporcionar asistencia al usuario.
· Evaluación del cliente: tareas requeridas para obtener información de la opinión del
cliente basadas en la evaluación de las representaciones de software creadas durante la
fase de ingeniería e implementadas en la fase de instalación.
Fig. 4-1. Tabla que relaciona tareas con actividades estructurales
Los miembros del equipo que trabajan en cada función aplicarán todas las actividades
estructurales. Se crea una matriz en la que cada función principal del problema se presenta
en cada fila, y las actividades estructurales por columnas. El trabajo del gestor del proyecto
es estimar los requisitos de recursos para cada celda de la matriz resultante, poner fechas de
inicio y finalización para las tareas asociadas con cada celda y establecer los productos que
surgirán en cada una de ellas.
4.2. Descomposición del proceso
Una vez elegido el modelo de proceso, las actividades estructurales se adaptan a él. Esta
estructura común de proceso es invariable y sirve como base para todo el trabajo de
software realizado por una organización.
Lo que varían son las tareas de trabajo reales. La descomposición de proceso comienza
cuando se plantea cómo se va a realizar una determinada actividad estructural.
Para un proyecto pequeño, una empresa determinada, podría sugerir las siguientes tareas para
la actividad “Comunicación con el cliente”:
1. Desarrollar una lista de aspectos a clarificar.
2. Reunirse con el cliente para resolver los aspectos que se han de clarificar.
3. Desarrollar conjuntamente una exposición del ámbito del proyecto.
4. Revisar el alcance del proyecto con todos los implicados.
5. Modificar el alcance del proyecto cuando se requiera.

Organización de Sistemas Informáticos 55 56 Organización de Sistemas Informáticos

 2. Ámbito del software
Capítulo 5 La primera actividad de la planificación del proyecto de software es determinar el ámbito del
software. Se deben evaluar la función y rendimiento que se asignaron al software durante la
Planificación de proyectos software y ingeniería de sistemas de computadora para establecer un ámbito de proyecto que no sea
ambiguo, ni incomprensible para directivos y técnicos.
Gestión del Riesgo El ámbito del software describe:

- La función: Se evalúan las funciones descritas en el enunciado del ámbito, y

en algunos casos se refinan para dar más detalles antes del
comienzo de la estimación.
La estimación de recursos, costes, y la planificación temporal de un esfuerzo de desarrollo - El rendimiento: Abarca los requisitos de tiempo de respuesta y de
software requiere experiencia, acceder a una buena información histórica y la confianza en procesamiento.
medidas cuantitativas cuando todo lo que existe son datos cualitativos.
- Las restricciones: Identifican los límites del software originados por el hardware
La estimación conlleva un riesgo inherente, y es este riesgo el que lleva a la incertidumbre: externo, por la memoria disponible y por otros sistemas
existentes.
- La complejidad del proyecto tiene un gran efecto en la incertidumbre. Sin embargo
la complejidad es una medida relativa que se ve afectada por la familiaridad con La técnica utilizada con más frecuencia para acercar al cliente y al desarrollador, y para hacer
esfuerzos anteriores. que comience el proceso de comunicación es establecer una reunión o entrevista preliminar.
- El tamaño del proyecto es otro factor importante que puede afectar a la precisión de
las estimaciones. 3. Recursos
- La disponibilidad de información histórica determina el riesgo de la estimación. La segunda tarea de la planificación es la estimación de los recursos requeridos para
“Aquellos que no pueden recordar el pasado están condenados a repetirlo”. acometer el esfuerzo de desarrollo de software.

El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas Estos recursos son:
por recursos, coste y planificación temporal.
* Recursos humanos:
Si no se entiende bien el ámbito del proyecto o los requisitos del proyecto están sujetos a
cambios, la incertidumbre y el riesgo son peligrosamente altos. El planificador de software Dado el ámbito, y una vez seleccionadas las habilidades técnicas que se
debería solicitar definiciones completas de rendimiento y de interfaz. Cualquier cambio en los requieren para llevar a cabo el desarrollo, se selecciona al personal adecuado
requisitos software significa inestabilidad en el coste y en la planificación temporal. para desarrollar cada una de las tareas.

Se debe especificar la posición dentro de la organización y la especialidad.

1. Objetivos de la planificación del proyecto
El número de personas requerido para un proyecto software sólo puede ser
El objetivo consiste en proporcionar un marco de trabajo que permita al gestor hacer determinado después de hacer una estimación del esfuerzo de desarrollo.
estimaciones razonables de recursos, coste y planificación temporal.

Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un

proyecto, y deben actualizarse a medida que avanza el proyecto. Además, las estimaciones
deberían definir los escenarios del mejor y peor caso de forma que los resultados del proyecto
puedan limitarse.
Organización de Sistemas Informáticos 57 58 Organización de Sistemas Informáticos
 * Recursos hardware:
· El sistema de desarrollo, o sistema anfitrión, consistente en la computadora
y periféricos asociados que se utilizarán durante la fase de desarrollo.
· El sistema de explotación, el sistema informático que se requerirá para la
explotación y uso del software una vez se haya desarrollado.
· Otros elementos, todos aquellos elementos hardware que sean necesarios
para el proceso de desarrollo y explotación.
* Recursos software: el software que se utiliza durante el proceso de desarrollo
(incluso para la explotación) del producto que se desea construir:
· Herramientas orientadas al código: compiladores, editores, enlazadores,...
· Herramientas de metodología: dan soporte a la planificación, diseño,
prueba y gestión de la configuración y mantenimiento (p.e. Developer 2000)
· Herramientas de cuarta generación: permiten especificar problemas
utilizando lenguajes especiales y técnicas no procedimientales. (p.e. Oracle)
4. Estimación del proyecto software
La estimación del coste y del esfuerzo del software nunca será una ciencia exacta. Son
demasiadas variables (humanas, técnicas, de entorno, políticas) que pueden afectar al coste
final del software y al esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de coste y esfuerzo tenemos varias opciones posibles:
1. Dejar la estimación para más adelante.
2. Basar las estimaciones en proyectos similares ya terminados.
3. Utilizar técnicas de descomposición relativamente sencillas para generar estas
estimaciones.
4. Desarrollar un modelo empírico para el cálculo de costes y esfuerzos del software.
La primera opción no es muy práctica. La segunda puede funcionar razonablemente bien si el
proyecto es bastante similar a los esfuerzos pasados y para proyectos similares. Las opciones
restantes son más viables.
La técnica de descomposición utiliza el enfoque “divide y vencerás”, descomponiendo el
proyecto en sus funciones principales y en las tareas que correspondan.
Organización de Sistemas Informáticos 59
5. Desarrollo de una estrategia de solución
La tendencia que tienen los ingenieros de software es la de utilizar la primera solución que
aparece en el proceso de planificación. Para evitarlo hay que desarrollar una estrategia de
solución, es decir, un enunciado general sobre la naturaleza de las posibles soluciones.
Se debe considerar varias estrategias de solución antes de decidirse por una, aunque los
planificadores deben escoger una o más para poder realizar el estudio de la posibilidad o
análisis de riesgo.
6. Análisis de Riesgo
La estrategia de riesgo reactiva, en el mejor de los casos, supervisa el proyecto en previsión
de posibles riesgos. Pero lo más frecuente es que el equipo no haga nada respecto a los
riesgos hasta que algo va mal. Después el equipo, apresuradamente trata de corregir el
problema. Cuando falla, la gestión de crisis entra en acción y el proyecto se encuentra en
peligro real.
La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se
identifican los riesgos potenciales, se valora su probabilidad y se establece una prioridad
según su importancia. Después el equipo de desarrollo establece un plan para controlar el
riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos,
el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una
manera eficaz y controlada.
El riesgo siempre implica dos características:
· Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no ocurrir
· Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no
deseadas o pérdidas.
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado
de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de
riesgos:
· Los riesgos del proyecto amenazan el plan de proyecto. Si los riesgos de proyecto se
hacen realidad, es probable que la planificación temporal del proyecto se retrase y que
los costos aumenten.
Los riesgos de proyecto identifican problemas potenciales de:
- presupuesto,
- planificación temporal,
- personal,
- recursos y
- requisitos.
60 Organización de Sistemas Informáticos
 6.1. Identificación del Riesgo
· Los riesgos técnicos amenazan la calidad y la planificación temporal del software La identificación del riesgo es un intento sistemático para especificar las amenazas al plan de
que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación proyecto (estimaciones, planificación temporal, carga de recursos, etc.). Identificando los
puede llegar a ser difícil o imposible. riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos
cuando sea posible y controlarlos cuando sea necesario.
Los riesgos técnicos identifican problemas potenciales de:
Existen dos tipos diferenciados de riesgos para cada categoría:
- diseño,
- implementación, · Riesgos genéricos: son una amenaza potencial para todos los proyectos de software.
- interfaz,
- verificación y
· Riesgos específicos de producto: sólo pueden identificarse una vez que se tiene una
- mantenimiento.
visión clara de la tecnología, personal y entorno específico del proyecto en cuestión.
· Los riesgos de negocio amenazan la viabilidad del software a construir. A menudo Un método para identificar riesgos es crear una lista de comprobación de elementos de
ponen en peligro el proyecto o el producto. riesgo. Se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes
subcategorías genéricas:
Estos riesgos pueden ser:
- Tamaño del producto: riesgos asociados con el tamaño general del software a
- Riesgo de mercado: construir un producto o sistema excelente que no quiere
construir o a modificar.
nadie en realidad.
- Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la
- Riesgo estratégico: construir un producto que no encaja en la estrategia
gestión o por el mercado.
comercial general de la compañía.
- Características del cliente: riesgos asociados con la sofisticación del cliente y la
- Construir un producto que el departamento de ventas no puede vender.
habilidad del desarrollador para comunicarse con el cliente.
- Riesgo de dirección: perder el apoyo de una gestión experta debido a
- Definición del proceso: riesgos asociados con el grado de definición del proceso del
cambios de enfoque o a cambios de personal.
software y su seguimiento por la organización de desarrollo.
- Riesgos de presupuesto: perder presupuesto o personal asignado.
- Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las
herramientas que se van a emplear en la construcción del producto.
Charrette propone otra categorización de riesgos, los divide en:
- Tecnología a construir: riesgos asociados con la complejidad del sistema a
· Riesgos conocidos: son todos aquellos que se pueden descubrir después de una
construir y la tecnología punta que contiene el sistema.
cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que
se desarrolla el proyecto y otras fuentes de información fiables.
- Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica
y de proyectos de los ingenieros del software que van a realizar el trabajo.
· Riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (p.e.
cambio de personal, mala comunicación con el cliente,...)
Las respuestas a estas preguntas permiten al planificador del proyecto estimar el impacto del
riesgo.
· Riesgos impredecibles: pueden ocurrir, pero son extremadamente difíciles de
identificar por adelantado.

Organización de Sistemas Informáticos 61 62 Organización de Sistemas Informáticos


6.2. Proyección y evaluación del riesgo
La proyección o estimación del riesgo intenta evaluar dos aspectos de cada uno de los
riesgos:
1. La posibilidad de que el riesgo sea real.
2. Las consecuencias asociadas con el riesgo, suponiendo que aparecerá el problema
que lo genera.
En la evaluación del riesgo se cuenta con un conjunto de ternas de la forma:
riesgo = {ri, pi, ci}
donde ri identifica al riesgo i, pi es la probabilidad de que se produzca el problema que
genera el riesgo i, y ci es el coste del riesgo.
Para que la evaluación sea útil, es necesario definir un nivel de referencia para el riesgo.
Para la mayoría de los proyectos software el coste, la temporización y el rendimiento son los
tres niveles de referencia para el riesgo.
Cuando se alcanza uno de estos niveles de referencia decimos que se ha alcanzado un punto
de ruptura, en el cual los gestores del proyecto deben tomar la decisión de seguir o parar el
desarrollo del mismo.
6.3. Reducción, supervisión y gestión del riesgo
Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo:
ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una
estrategia eficaz debe considerar tres aspectos:
- Evitar el riesgo
- Supervisar el riesgo
- Gestión del riesgo y planes de contingencia
Si un equipo de software adopta un enfoque proactivo frente al riesgo, evitarlo es siempre la
mejor estrategia. Esto se consigue desarrollando un plan de reducción del riesgo.
A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo. El
jefe del proyecto supervisa factores que pueden proporcionar una indicación de si el riesgo se
está haciendo más o menos probable.
La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción
han fracasado y que el riesgo se ha convertido en una realidad.
Organización de Sistemas Informáticos 63
Tabla 5-1. Actividades de la planificación del proyecto software
Desarrollar un enunciado definitivo del problema a resolver orientado al cliente.
Incluir una descripción de la situación actual, restricciones del problema y de las metas que se
lograrán.
Definición Justificar una estrategia de solución para el problema.
del Identificar las funciones a realizar, las restricciones y los subsistemas hardware, software y de
problema personal.
Determinar los objetivos y requisitos a nivel de sistema para el proceso de desarrollo y el
producto final.
Establecer los criterios de alto nivel para la validación del producto.
Esbozar varias estrategias de solución sin considerar las restricciones innatas al sistema,
Desarrollo
organización o a las propias estrategias.
de una
Realizar un estudio de la factibilidad para cada estrategia.
estrategia
Recomendar una estrategia de solución indicando por qué se rechazan las demás.
de solución
Desarrollar una lista de prioridades para las características del producto.
Definir un modelo de desarrollo y estructura organizativa del proyecto.
Planear las actividades de administración de la configuración, control de calidad y validación.
Determinar las herramientas por fase, técnicas y notación a utilizar.
Establecer estimaciones preliminares del coste de desarrollo.
Proceso de Establecer un programa preliminar para el desarrollo.
desarrollo Establecer estimaciones preliminares del personal necesario.
Desarrollar estimaciones preliminares de los recursos de cómputo necesario para operar y
mantener el sistema.
Preparar un glosario de términos.
Identificar las fuentes de información y referirse a ellas a lo largo del plan de proyecto.
7. Gestión de expectativas
Los directores de proyectos con experiencia a menudo se quejan de que gestionar las
expectativas de los proyectos es más difícil que gestionar el coste, los plazos, los equipos o la
calidad. Vamos a utilizar una herramienta sencilla que hará uso de una matriz de gestión de
expectativas para ayudar a los directores de proyectos a resolver este problema.
Todos los proyectos tienen metas y limitaciones sobre el coste, los plazos, el ámbito de
aplicación y la calidad. En un mundo ideal, podría conseguirse optimizar todos estos
parámetros. La dirección de las empresas tiene a menudo una serie de expectativas. Sin
embargo, la realidad sugiere que no suele ser posible optimizar todos los parámetros, y que es
preciso enfrentarse a lo que es factible y lo que es aceptable dentro de la gestión. Éste es el
propósito de la matriz de gestión de expectativas.
Una matriz de gestión de expectativas es una herramienta basada en conjuntos de
reglas cuya misión es ayudar a los directores de proyectos a valorar los posibles
cambios en los parámetros de un proyecto. Entre los parámetros se incluyen el coste,
el calendario, el campo de aplicación y la calidad.
La matriz básica, consta de tres filas y tres columnas (además de los encabezamientos). Las
filas corresponden a las medidas de éxito de un proyecto: coste, plazos y ámbito de aplicación
y/o calidad. Las columnas corresponden a las prioridades: primera, segunda y tercera. Para
establecer claramente las expectativas, asignaremos nombres a las prioridades, del modo
siguiente:
64 Organización de Sistemas Informáticos
 - Maximizar o minimizar. La más importante de las tres medidas en un proyecto
dado.

- Limitación. La segunda prioridad más importante de las tres medidas de un

proyecto.

- Aceptación. La menos importante de las tres medidas de un proyecto.

Prioridades
Máx. o mín. Limitación Aceptación
Medidas de éxito
Coste X
Estimado 20.000 millones de dólares
Calendario X
Plazo límite = 31 diciembre de 1969
Ámbito y/o calidad
1. Llevar un hombre a la Luna X
2. Traerlo de nuevo sano y salvo
Tabla 5-2. Matriz de gestión de expectativas. Ejemplo de gestión para el proyecto de alunizaje de EEUU

Estas tres medidas tienden a equilibrarse entre sí de una manera natural. Por ejemplo, si se
amplía el ámbito de un proyecto o los requisitos de calidad, se necesitará más tiempo y/o más
dinero. Por el contrario, si se intenta hacer un trabajo más deprisa, por lo general se reducirán
el ámbito del proyecto o los requisitos de calidad, o bien se invertirá más dinero para
compensarlo. La matriz de gestión de expectativas ayuda a la dirección a conocer estas tres
sencillas reglas:

- En cualquier proyecto, deben ponerse tres signos X repartidos en las nueve celdas
disponibles.

- Ninguna fila debe contener más de una X. En otras palabras, cada medida de éxito
debe tener una y sólo una prioridad.

- Ninguna columna puede contener más de una X. En otras palabras, debe hacer
prioridades de primer, segundo y tercer nivel.

Organización de Sistemas Informáticos 65 66 Organización de Sistemas Informáticos


Capítulo 6
Estimación de Costes y Plazos
1. Introducción
Los valores obtenidos en las estimaciones no van a ser medidos en unidades monetarias. Las
estimaciones suelen ser valoraciones, con un cierto error, del esfuerzo esperado para el
desarrollo del proyecto y de los plazos de tiempo requeridos para completarlo.
El coste de producción de software viene dado por los gastos de personal. Por este motivo,
el coste del proyecto suele medirse en personas-mes.
La estimación de proyectos software es compleja pues es normal desarrollar un producto
distinto cada vez y usar distintas técnicas y herramientas.
Suele hacerse más de una estimación de coste a lo largo del proyecto:
· Estimación preliminar en el estudio de viabilidad en la planificación.
· Esta estimación es revisada y modificada al finalizar la especificación de requisitos.
· Nuevamente, la estimación es modificada en la revisión del diseño.
2. Métodos de estimación de costes
Veremos los principales métodos que nos ayudarán a realizar la estimación:
1. Juicio de expertos: “adivinación basada en la experiencia”
2. Estimación por analogía: Se compara el proyecto que se va a desarrollar con uno o más
proyectos terminados de los que se disponen datos. En función de las similitudes y
diferencias con dichos proyectos se deduce el coste del nuevo desarrollo.
3. Descomposición: Se descompone el producto en sus componentes (o el proyecto en
tareas sencillas) hasta conseguir un nivel de detalle tal que se pueda estimar
directamente el coste de cada una de sus unidades elementales.
4. Ecuaciones o modelos de estimación: En general, son fórmulas matemáticas que
relacionan diversos parámetros del proyecto (tamaño del software, condiciones del
entorno del proyecto, etc) con el coste o esfuerzo requerido.
Organización de Sistemas Informáticos 67
2.1. Juicio de Expertos
Existen técnicas específicas que intentan sistematizar y mejorar la opinión de las distintas
personas involucradas en la estimación. Se suele emplear la opinión de más de un experto
para obtener una mayor fiabilidad en la estimación. En algunos casos, simplemente se calcula
la media de los valores ofrecidos por las distintas personas. También se puede efectuar una
reunión tan larga como sea necesaria hasta llegar a un consenso.
La técnica más conocida es la técnica Delphi. La mecánica es la siguiente:
1. Un coordinador proporciona a cada experto una documentación con la definición del
sistema y una papeleta para que escriba su estimación y las razones de su estimación.
2. Cada experto estudia la definición y determina su estimación de forma anónima, pudiendo
consultar al coordinador pero no con los otros expertos.
3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo
cualquier razonamiento extraño efectuado por alguno de los expertos.
4. Los expertos realizan una segunda ronda de estimaciones (anónima), utilizando los
resultados de la ronda anterior. En los casos en que una estimación difiera mucho de las
demás, se podrá solicitar que, de forma anónima, ésta sea justificada.
5. El proceso se repite tantas veces como se juzgue necesario impidiendo una discusión del
grupo durante el proceso.
Es posible que después de una serie de rondas no se llegue a un acuerdo, en tal caso, el
coordinador deberá analizar los aspectos problemáticos con cada experto para determinar las
causas de tales discrepancias y, en su caso, recabar información adicional y presentarla a los
expertos a fin de resolver las discrepancias.
2.2. Estimación por analogía
Las personas involucradas no sólo trabajan con su experiencia acumulada, sino que disponen
también de datos de proyectos acabados relativamente similares al que hay que estimar. Así,
por comparación, se pueden evaluar las diferencias entre el nuevo proyecto y los antiguos
para extrapolar su coste.
· Los ajustes de coste, esfuerzo o tamaño del nuevo proyecto pueden realizarse de forma
lineal, es decir, se mantiene aproximadamente la proporcionalidad.
· Los plazos de tiempo no guardan una relación lineal con el esfuerzo o tamaño del proyecto
(un 10% menos de tiempo para acabar el proyecto no implica un 10% más de coste, sino
aproximadamente un 52% de incremento).
Ventaja: Está basada en la experiencia real de los proyectos.
68 Organización de Sistemas Informáticos
Inconveniente: Dificultad a la hora de conocer realmente el grado de similitud con otro
proyecto.
2.3. Estimación por descomposición
El responsable de cada componente del software a construir estima el coste de su desarrollo.
La estimación para el proyecto completo se calcula mediante la suma de las cantidades
parciales. Para aplicar esta técnica hay que tener un diagrama de descomposición del
producto.
Ventajas:
- Obliga a comprender mejor la tarea a desarrollar.
- Permite a cada componente del equipo de desarrollo a planear su trabajo, asegurando
el compromiso personal de cada uno con la estimación obtenida.
Inconvenientes:
- Suele haber actividades relacionadas con el proyecto que no suelen incluirse en la
definición del mismo (leer código, revisar, reunirse, ...) (40% del tiempo).
- Suele haber también actividades no relacionadas con el proyecto que consumen
tiempo (formación, asuntos personales, ...) (30% del tiempo).
2.4. Modelos de estimación
Bárbara Kitchenham distingue dos tipos de modelos:
- Modelos de costes: proporciona estimaciones directas del esfuerzo o de la duración. La
mayoría son modelos de factores empíricos que cuentan con una parte principal
(habitualmente una media del tamaño del producto) y un cierto número de factores de ajuste.
P.e. el modelo COCOMO.
- Modelos de restricciones: muestran las relaciones en el tiempo entre dos o más parámetros
de coste (p.e. esfuerzo, duración y nivel de plantilla). P.e. el modelo SLIM de Putnam.
3. El modelo COCOMO
El modelo Constructivo de Costo (COCOMO) descrito por Boehm en 1981 es uno de los
modelos para la estimación costos del software mejor documentados.
Se basa en el estudio realizado sobre 63 proyectos de software que cubrían varios lenguajes y
varias áreas de aplicación, existiendo tres versiones del mismo: una básica, una intermedia y
otra detallada.
Organización de Sistemas Informáticos 69
3.1. Definiciones y suposiciones previas
El modelo COCOMO utiliza como base para la estimación de costos el tipo de desarrollo del
software y el tamaño estimado del producto de programación, y supone una serie de
cuestiones que deben considerarse para aplicarlo correctamente.
3.1.1. Tipos de proyectos
Las fórmulas que usa el modelo COCOMO para la estimación distinguen tres clases o tipos
de proyectos de software:
a) Proyectos orgánicos:
- Son aquellos en los que existen pequeños equipos que trabajan en un entorno
familiar desarrollando aplicaciones con las que están familiarizados.
- Las comunicaciones formales son escasas y cada miembro del equipo conoce quién
puede hacer un determinado tipo de trabajo.
b) Proyectos semi-separados:
- Este tipo de proyectos representa un estado intermedio entre el tipo orgánico y el
tipo empotrado que se describirá posteriormente.
- El equipo de proyecto puede estar formado por personal con o sin experiencia.
- Los miembros del equipo tienen una experiencia limitada relacionada con los
sistemas y pueden ser extraños a algunos de los aspectos, no todos, del sistema que se
va a desarrollar.
c) Proyectos empotrados:
- Deben operar con grandes restricciones.
- El sistema de software se encontrará fuertemente acoplado con el hardware, reglas y
procedimientos operativos.
- No es usual que los miembros del equipo de proyecto lleguen a alcanzar una gran
experiencia en la aplicación particular que se desarrolla.
3.1.2. Tamaño del Software
El tamaño estimado para el software se mide en miles de instrucciones fuente entregadas.
70 Organización de Sistemas Informáticos
Se considera instrucción fuente entregada a una línea de código, entendiendo por tal 3.2.2. Tiempo de desarrollo.
cualquier código que haya en una línea que termine con un carácter de fin de línea.
El tiempo de desarrollo será el tiempo requerido en meses para completar el proyecto
Normalmente se excluye el software de soporte no entregado, salvo en el caso de que el suponiendo la disponibilidad de suficiente personal.
desarrollo de este software se efectúe con el mismo cuidado que el software entregado.
Las ecuaciones de estimación de tiempo para los diferentes tipos de proyecto son:
Las líneas de comentarios no se contabilizan.
- Tipo Orgánico: TDES = 2.5 * (PM ^ 0.38)
3.1.3. Otras suposiciones
- Tipo Semi-separado: TDES = 2.5 * (PM ^ 0.35)
La estimación de costos en el modelo COCOMO se obtiene a través del esfuerzo requerido
para el desarrollo del producto. - Tipo Empotrado: TDES = 2.5 * (PM ^ 0.32)

Este esfuerzo se mide utilizando el número total de personas-mes necesarias para su
desarrollo, considerando que el modelo COCOMO una persona-mes consiste en 152 horas de
trabajo, realizadas en 19 días, promediando a lo largo de 12 meses.
El modelo supone también que:
3.2.3. Observaciones
- El modelo supone una estimación implícita de la productividad en el desarrollo del
proyecto, obteniéndose como cociente entre el número de instrucciones fuente entregadas
(IFE) y el esfuerzo estimado (PM). Es decir:

- La especificación de requisitos del software no cambiará significativamente después Productividad = IFE / PM

de la planificación y análisis de requisitos del producto.
- El proyecto tendrá una buena administración, tanto por parte del cliente como por
parte del responsable del desarrollo del software.
- El período cubierto por la estimación de costos comienza con la fase de diseño del
producto y termina con el final de la fase de integración y prueba.
3.2. El modelo básico
- Permite conocer el número medio de personas requeridas para completar el proyecto (N).
Para ello se divide el esfuerzo entre el tiempo estimado.
N = PM / TDES
- El tiempo requerido para completar el proyecto es una función que depende del esfuerzo
total requerido para el proyecto y no del número de ingenieros de software que trabajen en el
mismo.

3.2.1. Esfuerzo requerido para el desarrollo - El modelo COCOMO (básico) no aporta gran ayuda en la estimación de tiempo cuando el
personal disponible está limitado y, por el contrario, el tiempo de entrega es flexible.
En el modelo COCOMO básico, las fórmulas para calcular los costos o, más exactamente, el
esfuerzo requerido en el desarrollo de software son las siguientes: 3.2.4. Ejemplo

- Tipo Orgánico: PM = 2.4 * (MIFE ^ 1.05) Suponer un proyecto de software de tipo orgánico cuyo tamaño se estima en 32000
instrucciones fuente entregadas. Para dicho proyecto se obtienen los siguientes valores:
- Tipo Semi-separado: PM = 3.0 * (MIFE ^ 1.12)
PM = 2.4 * (32 ^ 1.05) = 91 personas-mes
- Tipo Empotrado: PM = 3.6 * (MIFE ^ 1.20)
TDES = 2.5 * (91 ^ 0.38) = 14 meses
Observaciones:
Productividad = 32000 / 91 = 352 ife/p-m (alrededor de 18 instrucc. por persona-día)
- PM representa el número de personas-mes requerido para el desarrollo del proyecto.
- MIFE es el número de miles de instrucciones fuente entregadas. N = 91 / 14 = 6.5 personas
- Los coeficientes y exponentes crecen del tipo orgánico al tipo empotrado.

Organización de Sistemas Informáticos 71 72 Organización de Sistemas Informáticos

3.3. El modelo intermedio Atributo MB B N A MA EA
F1 RELY 0.75 0.88 1.00 1.15 1.40 --
3.3.1. Ecuaciones del modelo F2 DATA -- 0.94 1.00 1.08 1.16 --
F3 CPLX 0.70 0.85 1.00 1.15 1.30 1.65
El modelo COCOMO intermedio utiliza para sus estimaciones: F4 TIME -- -- 1.00 1.11 1.30 1.66
F5 STOR -- -- 1.00 1.06 1.21 1.56
- Ecuaciones de esfuerzo nominal similares a las del COCOMO básico. F6 VIRT -- 0.87 1.00 1.15 1.30 --
- Las mismas ecuaciones de estimación de tiempo que en el modelo básico. F7 TURN -- 0.87 1.00 1.07 1.15 --
- Quince multiplicadores de esfuerzo divididos en cuatro categorías: F8 ACAP 1.46 1.19 1.00 0.86 0.71 --
· Atributos del producto F9 AEXP 1.29 1.13 1.00 0.91 0.82 --
· Atributos de la computadora F10 PCAP 1.42 1.17 1.00 0.86 0.70 --
· Atributos del personal F11 VEXP 1.21 1.10 1.00 0.90 -- --
· Atributos del proyecto F12 LEXP 1.14 1.07 1.00 0.95 -- --
F13 MODP 1.24 1.10 1.00 0.91 0.82 --
Las ecuaciones de esfuerzo nominal, o normal, en el modelo COCOMO intermedio son las F14 TOOL 1.24 1.10 1.00 0.91 0.83 --
siguientes: F15 SCED 1.23 1.08 1.00 1.04 1.10 --
*Estos valores se pueden interpolar, pero no extrapolar
- Tipo orgánico: EN = 3.2 * (MIFE ^ 1.05) Tabla 6-1. Valores de los atributos del modelo COCOMO intermedio.

- Tipo semi-separado: EN = 3.0 * (MIFE ^ 1.12) Descripción de los atributos:

- Tipo empotrado: EN = 2.8 * (MIFE ^ 1.20) A continuación se describen los quince multiplicadores de esfuerzo divididos en cuatro
categorías: atributos del producto, atributos de la computadora, atributos de personal y
La ecuación general de esfuerzo en el modelo COCOMO intermedio se puede establecer del atributos del proyecto.
siguiente modo para los tres tipos de proyectos:
Los atributos del producto
PM = EN * F1 * F2 * F3 * ... * F15
· RELY: Fiabilidad requerida del software:
Observaciones:
Toma valores en una escala que va desde muy bajo cuando un fallo en el software sólo
· EN es el esfuerzo nominal calculado según el tipo de proyecto. causa pequeños inconvenientes, hasta normal cuando un fallo genera unas pérdidas
· F1 hasta F15 representan a cada uno de los quince multiplicadores considerados en moderadas recuperables, o muy alto cuando un fallo conlleva riesgos para la vida
el modelo COCOMO intermedio. humana.

3.3.2. Atributos del modelo · DATA: Tamaño de la base de datos:

A continuación se expone una tabla en la que aparece cada atributo y sus correspondientes Varía desde bajo cuando el tamaño de la base de datos medido en bytes es menor que
valores en una línea, teniendo en cuenta que MB significa muy bajo, B significa bajo, N es 10 veces el número de IFEs, hasta normal cuando el tamaño de la base de datos está
nominal o normal, A representa un valor alto, MA es muy alto y EA significa entre 10 y 100 veces el tamaño del sistema, o muy alto cuando el tamaño de la base de
extremadamente alto: datos es más de 1000 veces mayor que el programa.

· CPLX: Complejidad del producto:

Se mide en una escala desde muy bajo hasta extremadamente alto. Un código de
complejidad baja utiliza operaciones simples de entrada/salida, estructuras de datos
simples y codificación estructurada con predicados sencillos. La complejidad normal

Organización de Sistemas Informáticos 73 74 Organización de Sistemas Informáticos


implica algún procesamiento de entrada/salida, múltiples ficheros de entrada, el uso
de bibliotecas de rutinas matemáticas y estadísticas, y alguna comunicación entre
módulos. La complejidad alta y extremadamente alta supone la posibilidad de
reutilización de código reentrante o recursivo, tratamiento de ficheros complejo,
procesamiento paralelo, administración de datos compleja, etc.
Los atributos de la computadora
Se deben a restricciones del hardware tales como velocidad y espacio que afectan a la
productividad del software. Los cuatro factores incluidos son:
· TIME: Restricciones en tiempo de ejecución:
Varía desde normal a extremadamente alto. Un valor normal significa que se utiliza
menos del 50% del tiempo de ejecución disponible y extremadamente alto sería que se
debe utilizar el 95% del tiempo disponible.
· STOR: Restricciones de memoria:
Se mide de la misma forma que TIME, un valor normal significa que se utiliza menos
de la mitad de la memoria disponible y extremadamente alto sería cuando usase el
95% de la memoria disponible.
· VIRT: Volatilidad de la máquina virtual:
Se entiende por máquina virtual el conjunto del hardware y del software en el que se
encuentra incluido el producto software. Un valor bajo para este factor significa que
sólo ocasionalmente ocurren grandes cambios en la máquina virtual. Un valor normal
implica cambios importantes cada seis meses y un valor muy alto sugiere que la
máquina virtual cambia una vez cada dos semanas.
· TURN: Tiempo de respuesta de la computadora:
Representa el tiempo transcurrido para la obtención de resultados. Un valor bajo
implica un sistema de desarrollo interactivo, mientras que un valor muy alto significa
que pasarán más de 12 horas hasta la obtención de resultados.
Los atributos del personal
Reflejan la experiencia y capacidad del equipo de desarrollo del proyecto. Todos ellos van
desde muy bajo, lo que significa poca o ninguna experiencia, hasta normal, lo que implica al
menos un año de experiencia, o muy alto, en el caso de tener más de tres años de experiencia.
Dichos atributos son:
Organización de Sistemas Informáticos 75
· ACAP: Capacidad de los analistas.
· AEXP: Experiencia en aplicaciones.
· PCAP: Capacidad de los programadores.
· VEXP: Experiencia en la máquina virtual.
· LEXP: Experiencia en lenguajes de programación.
Los atributos del proyecto
Hacen referencia al uso de herramientas de software, el tiempo de desarrollo del proyecto y la
utilización de técnicas de programación modernas. El presentar estos factores como
miembros de la misma categoría obedece más bien al intento de limitar su efecto aislado. Son
las siguientes:
· MODP: Uso de técnicas de programación modernas:
Boehm considera como técnicas de programación modernas el uso de diseño
descendente, revisiones de diseño y código, la programación estructurada y la
utilización de bibliotecas de soporte de programa, entre otras técnicas. Este factor
toma valores en una escala que va desde muy bajo cuando no se utilizan tales técnicas,
hasta normal cuando se usan algunas, o muy alto en el caso de que los miembros del
equipo utilicen las técnicas modernas de forma rutinaria.
· TOOL: Disponibilidad de herramientas software:
Este atributo puede tener un efecto significativo en el esfuerzo requerido para
desarrollar un sistema de software. Un valor muy bajo asignado a este atributo
significa que sólo se dispone de herramientas muy básicas tales como un ensamblador.
Un valor normal significa tener un conjunto más completo de herramientas para la
implementación, pruebas y depuración, y un valor muy alto implica que se dispone de
herramientas que soportan todas las fases del ciclo de vida del software.
· SCED: Tiempo de desarrollo requerido:
Este atributo indica en un tipo determinado de proyecto la variación de tiempo de
desarrollo respecto a la estimación nominal, obtenida utilizando la ecuación de
esfuerzo nominal y la ecuación de estimación de tiempo dada en el modelo COCOMO
básico. Un valor muy bajo para este atributo significa la necesidad de acelerar el
tiempo de desarrollo, mientras que un valor alto implica la dilatación de dicho tiempo.
Ambos valores causan un efecto similar aumentando el esfuerzo requerido para el
desarrollo del producto.
3.3.3. Ejemplo
La ayuda que presta el modelo a la toma de decisiones se puede apreciar en el ejemplo
seleccionado del libro de Sommerville del año 1985 que se expone a continuación.
76 Organización de Sistemas Informáticos

Se supone una situación de partida en la que el modelo COCOMO intermedio predice un
esfuerzo normal de 45 personas-mes para desarrollar un sistema de software empotrado en el
hardware de una microcomputadora. También se supone que los costos por cada persona-mes
del equipo de desarrollo son 6000$.
Caso 1: Supongamos que:
- El hardware está constituido por un procesador de 16 bits que trabaja a 4 MHz y con
64 Kbytes de memoria principal.
- Los modelos pierden precisión al utilizarse en entornos distintos de aquellos en los que se
crearon.
- Los factores de coste son difíciles de cuantificar y se consideran independientes aunque no
necesariamente lo son.
- Los modelos tienen un margen de error que puede ser más o menos aceptable.
- El modelo COCOMO intermedio no considera atributos tales como el tipo de aplicación
que se va a desarrollar, la documentación requerida, la continuidad del personal o la
calidad de la interfaz, entre otros.
- Estos modelos asumen pequeños cambios en los requisitos del producto pero requieren
que la administración del proyecto sea de alta calidad.

- Todos los multiplicadores de esfuerzo para el modelo COCOMO intermedio tienen

un valor normal, salvo los siguientes:
5. Beneficios del uso de modelos de coste
- Proporciona una base cuantitativa para la toma de decisiones administrativas.
RELY = 1.15 (A) STOR = 1.21 (MA) TIME = 1.11 (A) TOOL = 1.10 (B)
- El uso consistente de un modelo de estimación de coste, dentro de cualquier organización
debería preferirse a la improvisación de estimaciones de coste del software.
Utilizando el modelo COCOMO intermedio se obtiene la siguiente estimación para el
- Es posible realizar estimaciones para cada actividad del desarrollo del producto de
esfuerzo de desarrollo:
programación (en el modelo COCOMO puede hacerse una estimación para cada
actividad).
PM = 45 * 1.15 * 1.21 * 1.11 * 1.10 = 76 p-m

El costo total de desarrollo de este proyecto sería:

C = 76 * 6000 = 456000$

Caso 2: Supongamos que se tuviera el propósito de utilizar un procesador compatible a 8

MHz y con 128 Kbytes de memoria.

- En este caso, se requeriría el desarrollo de una interfaz especial con un costo

adicional de hardware de 30000$

- El atributo TOOL tendría un valor muy bajo en lugar de bajo, no viéndose afectados
los atributos de personal, TIME y STOR podrían reducirse a sus valores normales.

PM = 45 * 1.15 * 1.24 = 64 p-m

C = 64 * 6000 = 384000$

En consecuencia, se podría disponer de 42000$ para investigar en la mejora del

hardware si se desea.

4. Críticas a los modelos de coste

A pesar de que parecen totalmente eficaces, hay que matizar esta impresión.

- Los modelos dependen de LDC, pero este parámetro hay que estimarlo.
- Los modelos han surgido del análisis estadístico de datos de proyectos. La cantidad y
representatividad de los proyectos no es tan amplia como sería deseable.

Organización de Sistemas Informáticos 77 78 Organización de Sistemas Informáticos

 - Responsabilidades definidas: asignan cada tarea a un miembro específico.

Capítulo 7 - Resultados definidos: cada tarea debería tener un resultado definido.

- Hitos definidos: todas las tareas deben asociarse con un hito del proyecto. Se
consigue un hito cuando se ha revisado la calidad de uno o más
Planificación Temporal y productos y se han aceptado.

Seguimiento del Proyecto 2. Acerca de los retrasos

Hay muchas razones por las que el software se entrega tarde, la mayoría pertenece a una o
más de las siguientes causas:

1. Conceptos básicos - Fecha límite de entrega poco realista.

La planificación temporal de un proyecto software es una actividad que distribuye el
esfuerzo estimado a lo largo de la duración prevista del proyecto, asignando el esfuerzo a las
tareas específicas de la ingeniería de software.
La planificación temporal evoluciona con el tiempo, desde una visión macroscópica a una
detallada.
- Cambios en los requisitos que no se reflejan en la P.T.
- Subestimación honesta del esfuerzo y recursos requeridos.
- Errores predecibles y no predecibles considerados cuando comenzó el proyecto.
- Dificultades técnicas o humanas que no fueron prevista.
- Falta de comunicación entre la plantilla del proyecto.
- Falta de reconocimiento por parte de la gestión del proyecto de su retraso y falta de
medios para corregir el problema.

La planificación temporal del proyecto puede verse desde dos perspectivas diferentes: Hay un mito común: “si se retrasa el proyecto, siempre podemos añadir más gente y recuperar
el ritmo más adelante en el proyecto”. Sin embargo esto provoca más retraso. El personal
- La fecha de lanzamiento del producto está establecida sin posibilidad de cambio. agregado debe aprenderse el sistema, aumentan las vías de comunicación y la complejidad de
- Existe un margen de holgura que es ajustado por el equipo de gestión del software. la comunicación a lo largo del proyecto.

La planificación de un proyecto de desarrollo comprende varias tareas importantes: 3. Distribución de esfuerzo

- Definir un modelo de ciclo de vida. Una distribución recomendada de esfuerzo en las fases de definición y desarrollo se le conoce
- Ajustar el conjunto de tareas a un calendario. normalmente con el nombre de regla 40-20-40:
- Asignar los recursos adecuados y a tiempo a esas tareas.
- Establecer hitos o puntos de control en el calendario previsto. 40% o más Análisis y diseño
20% Codificación
Podemos guiarnos en la planificación temporal por un conjunto de principios básicos: 40% Prueba y depuración
- Partición: El proyecto debe dividirse en un número de actividades y tareas Esto es una directriz, estos porcentajes dependen del proyecto considerado.
manejables. Se descompone tanto el producto como el proceso.
Planificación 2-3%
- Interdependencia: Determinar la interdependencia de cada actividad o tarea. Análisis de requisitos 10-25%
Diseño de software 20-25%
- Asignación de tiempo: Asignar a cada tarea un cierto número de unidades de Revisión de diseño 5-10%
trabajo, así como una fecha de inicio y fin. Codificación 15-20%
Prueba y depuración 30-40%
- Validación del esfuerzo: Comprobar que los recursos asignados no sobrepasan a los
que se tienen.

Organización de Sistemas Informáticos 79 80 Organización de Sistemas Informáticos


4. Definición de tareas
Se debe definir una colección de conjuntos de tareas, cada una para satisfacer las necesidades
de distintos tipos de proyectos. El conjunto de tareas a elegir debe proporcionar suficiente
disciplina para alcanzar alta calidad para el software.
Los conjuntos de tareas se diseñan para acomodar diferentes tipos de proyectos y diferentes
grados de rigor: Podemos considerar los siguientes tipos de proyectos:
- Proyectos de desarrollo de concepto: que se inician para explorar algún nuevo
concepto de negocio o aplicación de alguna nueva tecnología.
- Proyectos de desarrollo de una nueva aplicación: que se aceptan como
consecuencia del encargo de un cliente específico.
- Proyectos de mejora de aplicaciones que corrigen, adaptan o amplían un software
existente de maneras que pueden no ser obvias de forma inmediata para el usuario
final.
- Proyectos de reingeniería: que se lleva a cabo con la intención de reconstruir un
sistema existente en su totalidad o en parte.
4.1. Red de tareas
· Existen interdependencias entre tareas, basadas en la secuencia.
· Se pueden llevar a cabo además tareas en paralelo.
· Las tareas concurrentes deben coordinarse, de forma que finalicen cuando tareas
posteriores requieran sus resultados.
Una red de tareas es una representación gráfica del flujo de tareas de un proyecto. En su
forma más sencilla muestra las tareas principales de ingeniería del software.
Fig. 7-1. Red de tareas para un proyecto
Organización de Sistemas Informáticos 81
El planificador debe determinar las dependencias internas de las tareas para garantizar un
progreso continuo hasta su finalización. Además el gestor del proyecto debería estar al tanto
de las tareas que pertenecen al camino crítico, es decir, tareas que deben finalizarse según la
planificación temporal si se quiere que el proyecto en general se termine a tiempo.
5. Planificación temporal
Se pueden aplicar herramientas de planificación temporal de proyectos y técnicas generales
al software con pocas modificaciones:
- Técnicas de evaluación y revisión de programas (PERT)
- Método del camino crítico (CPM)
Ambas técnicas son dirigidas por la información ya desarrollada en actividades anteriores de
la planificación del proyecto:
- Estimaciones de esfuerzo.
- Una descomposición de la función del producto.
- La selección del modelo de proceso adecuado.
- La selección del tipo de proyecto y del conjunto de tareas.
Las interdependencias entre las tareas deben definirse empleando una red de tareas.
Tanto PERT como CPM proporcionan herramientas cuantitativas que permiten al
planificador de software:
- Determinar el camino crítico: cadenas de tareas que determina la duración del
proyecto.
- Establecer las dimensiones de tiempo más probables para las tareas individuales
aplicando modelos estadísticos.
- Calcular las limitaciones de tiempo que definen una “ventana” de tiempo de una
tarea determinada.
5.1. Gráficos de tiempo
Una vez definidas las tareas, se define el esfuerzo, duración y fecha de inicio de cada tarea.
Además se asigna cada tarea a individuos específicos.
Como consecuencia de cada entrada (tarea) se genera un gráfico de tiempo también
denominado Gráfico Gantt.
Las tareas se colocan en la columna de la izquierda. Se indica la duración de cada tarea
mediante barras horizontales. Si aparecen múltiples barras al mismo tiempo hay concurrencia
de tareas. Los rombos indican hitos.
82 Organización de Sistemas Informáticos
 6. El Plan de Proyecto
Es un documento que se produce a la culminación de las tareas de planificación. Proporciona
información básica de costes y planificación temporal que será empleada a lo largo del
proceso de I.S.

El Plan de Proyecto es un documento breve dirigido a una audiencia diversa. Debe:

- Comunicar el ámbito y recursos a los gestores de software, personal técnico y al

cliente.
- Definir los riesgos y sugerir técnicas de aversión de riesgos.
- Definir los costes y planificación temporal para la revisión de la gestión.
- Proporcionar un enfoque general del desarrollo del software para todo el personal
relacionado con el proyecto.
- Describir cómo se garantizará la calidad y se gestionan los cambios.

Fig. 7-2. Ejemplo de diagrama de Gantt

5.2. Seguimiento de la planificación temporal

Si se ha desarrollado apropiadamente, define las tareas e hitos que deben conseguirse y
controlarse a medida que progresa el proyecto.

El seguimiento puede hacerse:

- Realizando reuniones periódicas del estado del proyecto en las que todos los
miembros del equipo informan del progreso y de los problemas.

- Evaluando los resultados de todas las revisiones realizadas a lo largo del proceso de
ingeniería del software.

- Determinando si se han conseguido los hitos formales del proyecto en la fecha

programada.

- Comprobando la fecha real de inicio con las previstas para cada tarea del proyecto.

- Reuniéndose informalmente con los profesionales del software para obtener sus
valoraciones subjetivas del progreso hasta la fecha y los problemas que se avecinan.

Organización de Sistemas Informáticos 83 84 Organización de Sistemas Informáticos

Documento de Plan de Proyecto Software

I. Introducción
A. Ámbito del proyecto y Objetivos.
1. Declaración del Ámbito.
2. Funciones principales.
3. Aspectos de rendimiento.
4. Restricciones técnicas y de gestión.
B. Modelo de ciclo de vida utilizado.
C. Definición de los estándares de documentación.
II. Estimaciones del proyecto
A. Datos históricos usados para las estimaciones.
B. Técnicas de estimación.
C. Estimaciones de esfuerzo, coste y duración.
III. Riesgos del proyecto
A. Análisis del riesgo.
1. Identificación.
2. Estimación del riesgo.
3. Evaluación.
B. Gestión del riesgo.
IV. Planificación Temporal.
A. Estructura de descomposición del trabajo del proyecto.
B. Red de tareas (red Pert).
C. Gráfico de Tiempo (gráfico Gantt)
V. Recursos del Proyecto.
A. Personal.
B. Hardware y Software.
C. Tabla de Recursos (enlazados al gráfico de tiempo)
VI. Organización del Personal.
A. Estructura de equipo (si procede).
VII. Mecanismos de seguimiento y de control.
A. Garantía de calidad y control.
B. Gestión y control de cambios.
VII. Apéndices.
A. Glosario de términos.
B. Bibliografía.
...

Organización de Sistemas Informáticos 85 86 Organización de Sistemas Informáticos

 Unidades de tiempo

Capítulo 8 tareas
fase 1
1.1
1 2 3 4 5 6 7 8 9 10

Técnicas de 1.2
1.3
Planificación Temporal fase 2
2.1
2.2
2.3

Fig. 8-1. Diagrama de Gantt

Vamos a contemplar varias técnicas que se pueden utilizar en la realización del calendario. Dentro del diagrama se pueden incluir fases que engloben diferentes tareas y se representan
Algunas son muy sencillas y no muestran la interrelación entre las actividades, como son el los tiempos de la fase como los de cada tarea en particular.
diagrama de hitos y los diagramas de Gantt. Para mostrar dicha interrelación, se hace
necesario el análisis de las redes de precedencia por medio de la técnica PERT. Los diagramas de Gantt pueden utilizarse para mostrar el avance de los proyectos, en virtud
de que pueden comparar de forma conveniente la planificación original con el desarrollo real.
1. Diagrama de hitos Para informar del avance del proyecto, hemos de ampliar las convenciones utilizadas. Si una
tarea ha sido completada, su barra correspondiente aparecerá más oscura. Si ha sido
completada sólo parcialmente, la parte proporcional de la barra estará más oscura. El
El diagrama de hitos es el método más simple para determinar el calendario. Es un cuadro o
porcentaje de la barra oscurecida debería corresponder al porcentaje de tarea completa. Las
tabla formado por dos columnas; en la primera se señalan las actividades y en la segunda se
barras más claras simbolizan tareas que no has sido empezadas. A continuación se trazará una
indican sus fechas de finalización.
línea vertical perpendicular la eje horizontal y que cortará a éste en la fecha del día. Así
podemos evaluar el alcance de nuestro proyecto.
Las ventajas de esta técnica son la facilidad de uso y el mínimo coste de preparación. Las
desventajas son la incertidumbre existente sobre las fechas de comienzo de las actividades y
Unidades de tiempo
la imposibilidad de reflejar las interrelaciones entre ellas.
tareas 1 2 3 4 5 6 7 8 9 10
Esta técnica también se utiliza para resumir calendarios complejos que contienen muchas fase 1
tareas. 1.1
1.2
1.3
2. Diagramas de Gantt fase 2
2.1
El diagrama de Gantt se utiliza frecuentemente en proyectos pequeños y supera algunos de
2.2
los inconvenientes de los diagramas de hitos. Este tipo de calendario es seguramente el más
2.3
utilizado, quizás porque muchas personas lo encuentran más comprensible que las redes de
precedencia.
hoy
Aunque con estos diagramas no es posible representar las dependencias entre actividades, es Fig. 8-2. Avance del proyecto con diagramas de Gantt
más fácil representar sus posibles solapamientos que en una red PERT. En muchos casos, las
redes PERT se trasladan a un diagrama de Gantt. El diagrama de Gantt se puede utilizar para
estimar los recursos y el presupuesto en función del tiempo.

El diagrama de Gantt es un diagrama de barras en forma de tabla donde se hace una

referencia cruzada entre las tareas (filas) y los tiempos de duración de las mismas (columnas).

Organización de Sistemas Informáticos 87 88 Organización de Sistemas Informáticos

 A
3. Redes de precedencia 1 2
Hay dos técnicas principales basadas en grafos para la planificación de proyectos. Estas son
PERT y CPM.
Fig. 8-3. Representación actividad y suceso en PERT

Es conveniente utilizar estas técnicas cuando un proyecto:

- Tiene todas sus actividades bien definidas.
- Las actividades se pueden comenzar, interrumpir y realizar de forma separada dentro
de una secuencia dada.
- Las actividades están ordenadas de forma que se pueda conseguir una secuencia.
- Una vez comenzada una actividad, debe continuar sin interrupción hasta su
finalización.
La red es un modelo gráfico que señala las relaciones secuenciales entre los sucesos claves de
un proyecto. PERT puede mostrar el camino crítico, que es la secuencia más larga de
actividades conectadas a través de la red y que determina la duración total del proyecto.
4.1. Representación de una red PERT
El problema que se plantea es el de encontrar el camino más largo a través de una red, y se
puede solucionar con la técnica de administración PERT. Se emplea una red de proyectos
para visualizar gráficamente las interrelaciones entre sus elementos, mostrando todas las
relaciones de precedencia respecto al orden en que se deben realizar las actividades.
Un proyecto se divide en actividades independientes bien definidas y sucesos importantes.
Cada actividad requiere cierto tiempo y las actividades están ordenadas.

Este camino crítico es la base para la planificación y el control de un proyecto. Para

disminuir el tiempo total, hay que reducir los tiempos de las actividades que están dentro del
camino crítico, teniendo en cuenta que esa disminución suele conllevar un aumento del coste
de la actividad.

Esta técnica también permite visualizar las tareas que no son críticas. Si aparecen retrasos
inevitables durante el proyecto, el director de proyecto puede retrasar estas actividades, si lo
desea, para reducir la demanda de recursos.

4. Técnica PERT
La técnica PERT sirve de ayuda en proyectos complejos y que requieren una cuidadosa
planificación, programación y coordinación de diferentes actividades interrelacionadas.

La técnica PERT parte de la descomposición de un proyecto en actividades. Para su

realización se consumen unos recursos determinados (humanos, hardware, etc.) Las
actividades ocurren entre dos sucesos (que llamaremos suceso inicial y suceso final),
entendiendo como suceso un acontecimiento o punto temporal que no consume recursos.
La representación se realiza por medio de un grafo en donde las actividades se reflejan
mediante arcos dirigidos y los sucesos mediante nodos. En la figura, el nodo 1 representa el
suceso inicio de la actividad A, y el nodo 2 el suceso final de la actividad. La longitud del
arco no tiene relación alguna con la duración de la actividad.
Fig. 8-4. Relación entre actividades.
El siguiente paso es la determinación de las relaciones entre las actividades. Por lo tanto, hay
que estudiar para cada actividad las relaciones de precedencia, es decir, las actividades que
deben estar finalizadas justamente antes del comienzo de la actividad dada. En la siguiente
tabla se pueden ver los tipos de relaciones de precedencia: lineales, de convergencia y de
divergencia. Es obvio que se pueden dar combinaciones de cada tipo simultáneamente (por
ejemplo, de convergencia y divergencia).
El método PERT exige que la red de proyecto sea acíclica y que dos nodos no estén
conectados directamente por más de un arco.

Organización de Sistemas Informáticos 89 90 Organización de Sistemas Informáticos

Existen casos en los que, para determinadas combinaciones, existen conflictos. Por ejemplo, ·A precede a B, C y D
supongamos que tenemos las siguientes relaciones: ·B precede a E
·C precede a F
· Las actividades A y B preceden a la actividad D ·D precede a G
· Las actividades A, B y C preceden a la actividad E · E, F precede a H

Según estas relaciones se podría representar el siguiente grafo:
Vamos a recoger este conjunto de relaciones mediante la matriz de encaminamientos. La
matriz de encaminamientos es una matriz cuya dimensión coincide con el número de
actividades en las que se descompone el proyecto. Sea Mij un elemento de la matriz, si Mij =
X, entonces, para poder iniciar la actividad i, es necesario que haya finalizado la actividad j.
En nuestro caso, la matriz quedará de la siguiente manera:

A B C D E F G H
A
B X
C X
D X
E X
Fig. 8-5. Grafo de relaciones entre actividades
F X
G X
Observamos que en el grafo se cumple la segunda regla, pero no la primera, ya que es
H X X
necesario que finalice también la actividad C para comenzar la actividad D.
Fig. 8-7. Matriz de encaminamientos

Para resolver el problema se añade una actividad ficticia F, de duración cero. En este punto se construye el grafo:

Fig. 8-6. Grafo de relaciones entre actividades con actividad ficticia

Una vez vistos los aspectos en los que se basa la representación de actividades, vamos a ver la
realización del grafo PERT mediante un ejemplo.
Fig. 8-8. Grafo que relaciona las actividades del ejemplo

Supongamos que tenemos que realizar un proyecto que tiene las siguientes actividades A, B, A continuación, estudiamos las asignaciones de los tiempos de cada actividad. PERT
C, D, E, F y G. Las relaciones entre actividades son las siguientes:
considera que la duración de las actividades es una variable aleatoria de la que conocemos
su ley de distribución. Para ello consideramos tres tiempos:

Organización de Sistemas Informáticos 91 92 Organización de Sistemas Informáticos

 donde TEi es el tiempo early del suceso i y Tij es la duración de la actividad que comienza en
· Estimación de tiempo pesimista (tp): representa el tiempo máximo en el que podría el suceso i y finaliza en el suceso j. Es decir, se calcula sumando los tiempos early de los
finalizarse la actividad si aparecen todas las circunstancias negativas que pueden darse sucesos en los que nace una actividad que finaliza en el suceso j, la duración de la actividad y
durante su ejecución. cogiendo el mayor.

· Estimación de tiempo más probable (tn): representa el tiempo normal de duración Volviendo al ejemplo, supongamos que tenemos calculados los tiempos PERT de cada una de
de la actividad considerando que hay problemas durante las actividades, pero no las actividades y que son los siguientes:
aparecen en su totalidad.
Actividad A B C D E F G H
· Estimación de tiempo optimista (to): representa el tiempo mínimo si no aparece Duración 8 5 6 5 6 7 9 3
ningún problema durante la ejecución de la actividad.
Por ejemplo, para calcular el TE6, estudiamos los sucesos iniciales de las actividades E y F:
µ como:
En base a estas estimaciones, se calcula el tiempo PERT Tµ TE6 = máx [14+7, 13+6] = 21, y para TE7 = máx.[13+9, 21+3] = 24. Se procede de la misma
forma para el resto de los sucesos, con los que queda la red como se ve a continuación. El
µ = (tp + 4tn + to) / 6
Tµ suceso inicial siempre tiene un TEi = 0.

y la varianza:

σ = SQRT ( ((tp – to) / 6)2)

El siguiente paso es el cálculo de los tiempos early (tiempo más temprano posible) y last
(tiempo más tardío posible) de cada suceso descrito en el grafo. Para ello, nos basaremos en
la representación de la figura:

Fig. 8-10. Cálculo de los tiempos más próximos en una red Pert

El proceso para obtener los tiempos más próximos es el siguiente:

Fig. 8-9. Representación gráfica de tiempos de una actividad
4.2. Cálculo de los tiempos más próximos (early):
El tiempo más próximo para un suceso es el tiempo estimado en el que ocurrirá el suceso si
las actividades que lo preceden comienzan lo más pronto posible.
El tiempo early del suceso j, que representamos por TEj será igual a:
TEj = máx. [ TEi + Tij], ∀j
- Se efectúa un paso hacia delante a través de la red.
- Se calcula sucesivamente el tiempo en el que ocurrirá cada suceso si el precedente
inmediato ocurre en su tiempo más próximo y cada actividad que interviene
consume exactamente su tiempo estimado.
- La iniciación del proyecto se debe etiquetar como el tiempo 0.
4.3. Cálculo de los tiempos más lejanos (late).
El tiempo más lejano para un suceso es el último momento estimado en el que puede ocurrir
un suceso sin retrasar la terminación del proyecto más allá de su tiempo más próximo.

Organización de Sistemas Informáticos 93 94 Organización de Sistemas Informáticos

El tiempo late del último suceso coincide con su tiempo early. El resto de los tiempos late se
calculan:
TLi = min. [TLj – Tij], ∀j
donde TLj es el tiempo last del suceso j y Tij la duración de la actividad que comienza por el
suceso i y finaliza en el suceso j. Es decir, se calcula restando a los tiempos last de los sucesos
en los que finalizan actividades que nacen en el suceso i, la duración de las actividades y
cogiendo el menor.
Fig. 8-11. Cálculo de los tiempos más lejanos en una red Pert
El proceso de obtención de los tiempos más lejanos consiste en:
- Efectuar un paso hacia atrás a través de la red.
- Calcular el tiempo final en el que puede ocurrir un suceso de manera que los que le
siguen ocurran en su tiempo más lejano si cada actividad involucrada consume
exactamente su tiempo estimado.
4.4. Holgura total de una actividad y camino crítico
Antes de definir el concepto de holgura total de una actividad, hay que definir el concepto de
holgura de un suceso. Se define la holgura de un suceso i como la diferencia entre su tiempo
más lejano y su tiempo más próximo:
Hi = TLi – TEi
La holgura de un suceso nos indica el número de unidades de tiempo en las que se puede
retrasar su realización de forma que no se aumente la duración total del proyecto.
Se dice que un suceso es crítico si Hi = 0. En el ejemplo vemos que son críticos los sucesos:
1, 2, 4, 6 y 7.
Organización de Sistemas Informáticos 95
La holgura total de una actividad que une el suceso i con el suceso j se define como:
HTij = TLj – TEi - Tij
Representa el número de unidades de tiempo que puede retrasarse la realización de la
actividad con respecto al tiempo PERT previsto sin que aumente la duración del proyecto.
Si la actividad H aumenta dos unidades de tiempo, el tiempo final del proyecto se verá
afectado de igual modo: TEi = TEj = 26. Sin embargo, la actividad E tiene una holgura total
Ht36 = 21 – 13 – 6 = 2, luego podemos retrasar esta actividad como máximo 2 unidades de
tiempo más sin que se retrase la finalización del proyecto.
Las holguras se relacionan con posibles retrasos de la siguiente forma:
- Para un suceso, representa cuánto retraso se puede admitir para llegar a ese suceso
sin retrasar la terminación del proyecto.
- Para una actividad, indica lo mismo respecto a un retraso en la terminación de esa
actividad.
Un aspecto que hay que considerar es que si una actividad consume parte de la totalidad de su
holgura total, se puede producir una disminución de la holgura total de la siguiente actividad.
Las actividades que tienen una holgura total igual a cero se denominan actividades críticas.
En el ejemplo podemos ver que la actividad H es crítica: HT67 = 24 – 21 – 3 = 0.
Uniendo todas las actividades críticas se forma un camino desde el suceso inicial al suceso
final del proyecto, que recibe el nombre de camino crítico (que se representa por una línea
gruesa). Cualquier retraso que sufra alguna de las actividades del camino crítico implicará un
retraso en el proyecto.
El director de proyecto no debe sólo prestar atención a las actividades críticas, sino también a
las que no lo son, ya que si una actividad no crítica consume el total de su holgura, se
convierte en crítica, y aparecería un nuevo camino crítico.
4.5. El proceso de trabajo con PERT
Podemos resumir el proceso de trabajo visto, para ello podemos ver una serie de etapas:
1. Identificar todas las actividades asociadas con el proyecto.
2. Identificar las relaciones de precedencia inmediata para todas las actividades.
3. Dibujar la red básica para el proyecto, mostrando todas las relaciones de
precedencia.
96 Organización de Sistemas Informáticos
 4. Estimar el tiempo esperado de duración para cada actividad.

5. Empleando una revisión hacia delante de la red, calcular el tiempo más próximo
para cada suceso.

6. Utilizando el tiempo esperado de terminación del proyecto, calculando en la

revisión hacia delante de la red, usar el procedimiento de revisión hacia atrás para
calcular el tiempo más lejano para cada suceso.

7. Calcular el tiempo de holgura asociado con cada suceso y cada actividad.

8. Identificar la ruta crítica para la red. Las actividades críticas son las que tienen un
tiempo de holgura cero.

4.6. Valoración del método PERT

· El objetivo de los sistemas tipo PERT consiste en ayudar en la planificación y el control,
por lo que no implica que sea un método de optimización en si.

· Algunas veces el objetivo primario es determinar la probabilidad de cumplir con fechas de

entrega específicas.

· Se identifican aquellas actividades que es más probable que se conviertan en cuellos de

botella.

· Otro objetivo es evaluar el efecto de los cambios en el programa.

· Además, se pueden evaluar otros cambios entre recursos y desempeño, y se puede evaluar el
efecto de desviarse de lo programado.

· El método PERT es apropiado cuando se maneja mucha incertidumbre al predecir los

tiempos de las actividades y cuando es importante controlar de manera efectiva la
programación del proyecto.

Organización de Sistemas Informáticos 97 98 Organización de Sistemas Informáticos


Capítulo 9
Control de calidad del Software y
Gestión de la Configuración
1. Introducción
La garantía de calidad del software (SQA, Software Quality Assurance) es una actividad de
protección que se aplica a lo largo de todo el proceso de ingeniería del software.
La SQA engloba:
· Un enfoque de gestión de calidad.
· Tecnología de ingeniería del software efectiva (métodos y herramientas)
· Revisiones técnicas formales que se aplican durante el proceso del software.
· Una estrategia de prueba multiescalada.
· El control de la documentación del software y de los cambios realizados.
· Un procedimiento que asegure un ajuste a los estándares de desarrollo del software
(cuando sea posible).
· Mecanismos de medición y de generación de informes.
2. Conceptos de calidad
2.1. Calidad
Cuando se examina un artículo según sus características mensurables, se pueden encontrar
dos tipos de calidad: calidad del diseño y calidad de concordancia.
La calidad del diseño se refiere a las características que especifican los ingenieros de
software para un artículo. El grado de materiales, tolerancias, y especificaciones del
rendimiento, todos contribuyen a la calidad del diseño. Cuando se utilizan materiales de alto
grado y se especifican tolerancias más estrictas y niveles más altos de rendimiento, la calidad
de diseño de un producto aumenta, si el producto se fabrica de acuerdo con las
especificaciones.
Organización de Sistemas Informáticos 99
La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño
durante su realización. Una vez más, cuanto mayor sea el grado de cumplimiento, más alto
será el nivel de calidad de concordancia.
En el desarrollo de software, la calidad de diseño acompaña a los requisitos, especificaciones
y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la
implementación. Si la implementación sigue el diseño, y el sistema resultante cumple los
objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
2.2. Control de calidad
El control de calidad es una serie de inspecciones, revisiones, y pruebas utilizados a lo largo
del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han
sido asignados.
2.3. Garantía de calidad
La garantía de calidad consiste en la auditoría y las funciones de información de la gestión.
El objetivo de la garantía de calidad es proporcionar la gestión para informar de los datos
necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más
profunda y segura de que la calidad del producto está cumpliendo sus objetivos.
3. Garantía (aseguramiento) de calidad del software
La calidad del software se define como:
“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos,
con los estándares de desarrollo explícitamente documentados, y con las características
implícitas que se espera de todo software desarrollado profesionalmente”.
La definición anterior sirve para hacer hincapié en tres puntos importantes:
1. Los requisitos del software son las base de las medidas de calidad. La falta de
concordancia con los requisitos es una falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la
forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi
siempre habrá falta de calidad.
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (p.e. el deseo
de un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en
alcanzar los requisitos implícitos, la calidad del software se queda en entredicho.
100 Organización de Sistemas Informáticos

3.1. Actividades de SQA
La garantía de calidad del software comprende una gran variedad de tareas, asociadas con
dos componentes diferentes:
- Los ingenieros de software que realizan trabajo técnico, y
- Un grupo de SQA que tiene la responsabilidad de la planificación de garantía de
calidad, supervisión, mantenimiento de registros, análisis e informes.
4. Revisiones del software
Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:
1. Señalar la necesidad de mejoras en el producto de una sola persona o un equipo.
2. Confirmar las partes de un producto en las que no es necesaria o no es deseable una
mejora.
3. Conseguir un trabajo técnico de una calidad más uniforme, o al menos más predecible,
que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el
trabajo técnico.
5. Revisiones técnicas formales
Una revisión técnica formal (RTF) es una actividad de garantía de calidad del software que
es llevada a cabo por los ingenieros del software. Los objetivos de la RTF son:
1. Descubrir errores en la función, la lógica o la implementación de cualquier
representación del software.
2. Verificar que el software bajo revisión alcanza sus requisitos.
3. Garantizar que el software ha sido representado de acuerdo con ciertos estándares
predefinidos.
4. Conseguir un software desarrollado de forma uniforme.
5. Hacer que los proyectos sean más manejables.
Organización de Sistemas Informáticos 101
6. Los estándares de calidad ISO-9000
Un sistema de garantía de calidad se puede definir como la estructura organizativa,
responsabilidades, procedimientos, procesos y recursos para implementar gestión de calidad.
ISO 9000 describe los elementos de garantía de calidad en términos genéricos que pueden
aplicarse a cualquier negocio con independencia de los productos o servicios ofrecidos.
6.1. El estándar ISO-9001
ISO 9001 es el estándar de garantía de calidad que se aplica a la ingeniería del software. El
estándar contiene 20 requisitos que deben estar presentes en un sistema de garantía de calidad
efectiva.
7. Gestión de configuración software
La gestión de configuración del software (GCS) es una actividad de autoprotección que se
aplica a lo largo del proceso de ingeniería del software. Como el cambio se puede producir en
cualquier momento, las actividades de GCS sirven para:
1. Identificar el cambio.
2. Controlar el cambio.
3. Garantizar que el cambio se implementa adecuadamente.
4. Informar del cambio a todos aquellos a los que le interese.
El resultado del proceso de ingeniería del software es una información que se puede dividir en
tres amplias categorías:
1. Programas de computadora (tanto en forma de código fuente, como ejecutable)
2. Documentos que describen los programas de computadora (tantos técnicos como de
usuario).
3. Datos (contenidos en el programa o externos a él).
Los elementos que componen toda la información producida como parte del proceso de
ingeniería del software se denomina colectivamente configuración del software.
102 Organización de Sistemas Informáticos
 Módulo III
SISTEMAS DE BASES DE DATOS

Organización de Sistemas Informáticos 103 104 Organización de Sistemas Informáticos


Capítulo 10
Introducción a los SGBD
Un sistema de gestión de bases de datos (SGBD) consiste en una colección de datos
interrelacionados y un conjunto de programas para acceder y manipular dichos datos.
La colección de datos, normalmente denominada base de datos, contiene información acerca
de una empresa particular.
El primer objetivo de un SGBD es proporcionar un entorno que sea tanto práctico como
eficiente de usar en la recuperación y el almacenamiento de la información de la base de
datos.
Los sistemas de bases de datos deben proporcionar la fiabilidad de la información
almacenada, a pesar de las caídas del sistema o los intentos de acceso sin autorización. Si los
datos van a ser compartidos entre diversos usuarios, el sistema debe evitar posibles resultados
anómalos.
1. Propósito de los Sistemas de Bases de Datos
Considérese parte de una empresa de cajas de ahorro que mantiene información acerca de
todos los consumidores y cuentas de ahorro. Una manera de mantener la información en una
computadora es almacenarla en archivos del sistema permanentes. Para permitir a los usuarios
manipular la información, el sistema tiene un número de programas de aplicación que
manipula los archivos, incluyendo:
· Un programa para efectuar cargos o abonos en una cuenta.
· Un programa para añadir una cuenta nueva.
· Un programa para calcular el saldo de una cuenta.
· Un programa para generar las operaciones mensuales.
Si las necesidades se incrementan, se añaden nuevos programas de aplicación al sistema.
El sistema de procesamiento de archivos típico que se acaba de describir se mantiene
mediante un sistema operativo convencional.
Mantener la información de la organización en un sistema de procesamiento de archivos tiene
una serie de inconvenientes importantes:
Organización de Sistemas Informáticos 105
· Redundancia e inconsistencia de datos. La misma información puede estar
duplicada en diferentes lugares (archivos). Esta redundancia conduce a un
almacenamiento y coste de acceso más altos. Además, puede conducir a
inconsistencia de datos, es decir, las diversas copias de los mismos datos pueden no
coincidir.
· Dificultad en el acceso a los datos. El entorno de procesamiento de archivos
convencional no permite que los datos necesarios sean obtenidos de una forma
práctica y eficiente.
· Aislamiento de datos. Debido a que los datos están dispersos en varios archivos, y
los archivos pueden estar en diferentes formatos, es difícil escribir nuevos programas
de aplicación para recuperar los datos apropiados.
· Problemas de integridad. Los valores de los datos almacenados en la base de datos
deben satisfacer ciertos tipos de ligaduras de consistencia. Los desarrolladores hacen
cumplir esas ligaduras en el sistema añadiendo el código apropiado en los diversos
programas de aplicación. Sin embargo, cuando se añaden nuevas ligaduras, es difícil
cambiar los programas para hacer que se cumplan.
· Problemas de atomicidad. Un sistema de una computadora, como cualquier otro
dispositivo mecánico o eléctrico, está sujeto a fallo. En muchas aplicaciones es crucial
asegurar que una vez que un fallo ha ocurrido y se ha detectado, los datos se restauran
al estado de consistencia que existía antes del fallo. Las operaciones deben ser
atómicas, es decir, cada operación debe ocurrir por completo o no ocurrir en absoluto.
Es difícil asegurar esta propiedad en un sistema de procesamiento de archivos
convencional.
· Anomalías en el acceso concurrente. Muchos sistemas han ido permitiendo a
múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un entorno
de interacción de actualizaciones concurrentes puede dar lugar a datos inconsistentes.
· Problemas de seguridad. No todos los usuarios de un sistema de bases de datos
deberían poder acceder a todos los datos. Como los programas de aplicación se
añaden al sistema de una forma ad hoc, es difícil garantizar tales ligaduras de
seguridad.
Estas dificultades, entre otras, han dado comienzo al desarrollo de SGBD.
2. Visión de los datos
El propósito principal de un sistema de bases de datos es proporcionar a los usuarios una
visión abstracta de los datos. El sistema esconde ciertos detalles de cómo se almacenan y
mantienen los datos.
106 Organización de Sistemas Informáticos

2.1. Abstracción de Datos
Para que el sistema sea útil, debe recuperar los datos eficientemente. Esta preocupación ha
conducido al diseño de estructuras de datos complejas para la representación de los datos en
la base de datos. Como muchos usuarios de sistemas de bases de datos no están
familiarizados con computadoras, los desarrolladores esconden la complejidad a los usuarios
a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el
sistema:
· Nivel físico. El nivel más bajo de abstracción describe cómo se almacenan realmente
los datos. En el nivel físico se describen en detalle las estructuras de datos complejas
de bajo nivel.
· Nivel lógico. El siguiente nivel más alto de abstracción describe qué datos se
almacenan en la base de datos y qué relaciones existen entre esos datos. Los
administradores de bases de datos, que deben decidir la información que se mantiene
en la base de datos, usan el nivel lógico de abstracción.
· Nivel de vistas. El nivel más alto de abstracción describe sólo parte de la base de
datos completa. A pesar del uso de estructuras más simples en el nivel lógico, queda
algo de complejidad, debido al gran tamaño de la base de datos. Para que la
interacción con el sistema se simplifique, se define la abstracción del nivel de vistas.
El sistema puede proporcionar nuevas vistas para la misma base de datos.
Fig. 10-1. Niveles de abstracción de datos
2.2. Instancias y Esquemas
La colección de información almacenada en la base de datos en un momento particular se
llama una instancia de la base de datos.
El diseño completo de la base de datos se llama el esquema de la base de datos.
Organización de Sistemas Informáticos 107
Los sistemas de bases de datos tienen varios esquemas divididos, de acuerdo a los niveles de
abstracción que se han visto. En el nivel más bajo está el esquema físico; en el nivel
intermedio está el esquema lógico, y en el nivel más alto está el subesquema.
2.3. Independencia de Datos
La capacidad para modificar una definición de esquema en un nivel sin que afecte a una
definición de esquema en el siguiente nivel superior se llama independencia de datos. Hay
dos niveles de independencia de datos:
· Independencia física de datos. Es la capacidad para modificar el esquema físico sin
provocar que los programas de aplicación tengan que reescribirse.
· Independencia lógica de datos. Es la capacidad para modificar el esquema lógico
sin causar que los programas de aplicación tengan que reescribirse.
La independencia de datos lógica es más difícil de proporcionar que la independencia de
datos física, ya que los programas de aplicación son fuertemente dependientes de la estructura
lógica de los datos a los que ellos acceden.
3. Modelos de Datos
La parte esencial de la estructura de base de datos es el modelo de datos: una colección de
herramientas conceptuales para describir los datos, las relaciones de datos, la semántica de
los datos y las ligaduras de consistencia.
3.1. Modelos lógicos basados en objetos
Los modelos lógicos basados en objetos se usan para describir datos en los niveles lógico y de
vistas. Se caracterizan por el hecho de que proporcionan capacidades estructurales muy
flexibles y permiten que las ligaduras de datos sean especificadas explícitamente.
Varios de los modelos más ampliamente conocidos son:
· El modelo de entidad-relación.
· El modelo orientado a objetos.
· El modelo de datos semántico.
· El modelo de datos funcional.
3.1.1. Modelo entidad-relación
El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real
que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre
estos objetos.
108 Organización de Sistemas Informáticos

Una entidad es un objeto del mundo real que es distinguible de otros objetos. Por ejemplo,
cada persona es una entidad, y una cuenta bancaria puede ser considerada una entidad.
Las entidades se describen en una base de datos mediante un conjunto de atributos. Por
ejemplo, los atributos numero-cuenta y saldo describen una cuenta particular de un banco.
Una relación es una asociación entre varias entidades. Por ejemplo, una relación impositor
asocia un cliente con cada cuenta que tiene.
El conjunto de todas las entidades del mismo tipo y el conjunto de todas las relaciones del
mismo tipo se denominan conjunto de entidades y conjunto de relaciones,
respectivamente.
Además de entidades y relaciones, el modelo E-R representa ciertas ligaduras que los
contenidos de la base de datos deben cumplir. Una ligadura importante es la
correspondencia de cardinalidades, que expresa el número de entidades con las que otra
entidad se puede asociar a través de un conjunto de relaciones.
La totalidad de estructuras lógicas de una base de datos se pueden expresar gráficamente
mediante un diagrama E-R, que consta de los siguientes componentes:
· Rectángulos, que representan conjuntos de entidades.
· Elipses, que representan atributos.
· Rombos, que representan relaciones entre conjuntos de entidades.
· Líneas, que unen los atributos con los conjuntos de entidades y los conjuntos de
entidades con las relaciones.
Fig. 10-2. Diagrama entidad-relación
Organización de Sistemas Informáticos 109
3.1.2. Modelo orientado a objetos
Como el modelo E-R, el modelo orientado a objetos está basado en una colección de
objetos. Un objeto contiene valores almacenados en variables de instancia dentro de ese
objeto. Un objeto también contiene fragmentos de código que operan en el objeto. Estos
fragmentos de código se llaman métodos.
Los objetos que contienen los mismos tipos de valores y los mismos métodos se agrupan
juntos en clases.
La única manera de que un objeto pueda acceder a los datos de otro objeto es mediante la
invocación de un método de ese otro objeto. Esta acción se llama paso de mensaje al otro
objeto. Así, la interfaz de llamada de los métodos de un objeto define la parte visible
externamente del objeto. La parte interna del objeto (las variables de instancia y el código de
los métodos) no son visibles externamente. El resultado es obtener dos niveles de abstracción
de datos.
3.2. Modelos lógicos basados en registros
Los modelos lógicos basados en registros se usan para describir datos en los niveles lógico y
de vistas. En contraste con los modelos de datos basados en objetos, se usan tanto para
especificar la estructura lógica completa de la base de datos como para proporcionar una
descripción de alto nivel de la implementación.
Los modelos basados en registros se llaman así debido a que la base de datos se estructura
en registros de formato fijo de diferentes tipos. En cada tipo de registro se define un número
fijo de campos o atributos, y cada campo tiene normalmente una longitud fija.
Los tres modelos basados en registros más ampliamente aceptados son los que vamos a ver a
continuación.
3.2.1. Modelo relacional
En el modelo relacional se usa una colección de tablas para representar tanto los datos como
las relaciones entre esos datos. Cada tabla tiene varias columnas, y cada columna tiene un
nombre único. Podemos ver en el ejemplo una base de datos relacional consistente en dos
tablas: una muestra los clientes de un banco y la otra muestra las cuentas que pertenecen a
esos clientes.
110 Organización de Sistemas Informáticos
 3.2.3. Modelo jerárquico

El modelo jerárquico es similar al modelo de redes, en el sentido en que los datos y las
relaciones entre los datos se representan mediante registros y enlaces, respectivamente. Éste
se diferencia del modelo de redes en que los registros se organizan como colecciones de
árboles en lugar de grafos dirigidos.

Fig. 10-3. Ejemplo de base de datos relacional

3.2.2. Modelo de red

Los datos en el modelo de red se representan mediante colecciones de registros y las

Fig. 10-5. Ejemplo de base de datos jerárquica
relaciones entre los datos se representan mediante enlaces, que se pueden ver como punteros.
Los registros en la base de datos se organizan como colecciones de grafos dirigidos.

3.3. Modelo de datos físico

El modelo de datos físico se usa para describir datos en un nivel más bajo. En contraste con
el modelo de datos lógico, hay pocos modelos de datos físicos en uso.

4. Lenguajes de Bases de Datos

Un sistema de bases de datos proporciona dos tipos de lenguajes diferentes: uno para
especificar el esquema de base de datos y el otro para expresar las consultas y actualizaciones
de la base de datos.

4.1. Lenguaje de definición de datos

Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas
Fig. 10-4. Ejemplo de base de datos en red mediante un lenguaje especial llamado lenguaje de definición de datos (LDD). El resultado
de la compilación de las instrucciones del LDD es un conjunto de tablas que se almacenan en
un archivo especial llamado diccionario de datos o directorio de datos.

Organización de Sistemas Informáticos 111 112 Organización de Sistemas Informáticos


Un diccionario de datos es un archivo que contiene metadatos; es decir, datos acerca de los
datos. Este archivo se consulta antes de leer o modificar los datos reales del sistema de base
de datos.
4.2. Lenguaje de manipulación de datos
Los niveles de abstracción se aplican no sólo a la definición o estructuración de los datos,
sino también a la manipulación de los datos. Por manipulación de datos se quiere decir:
· La recuperación de información almacenada en la base de datos.
· La inserción de información nueva en la base de datos.
· El borrado de información de la base de datos.
· La modificación de información almacenada en la base de datos.
En el nivel físico se deben definir algoritmos que permitan un acceso eficiente a los datos. En
los niveles más altos de abstracción se enfatiza la facilidad de uso.
Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios
acceder o manipular los datos organizados mediante el modelo de datos apropiado. Hay dos
tipos básicamente:
· LMD procedimientales. Requieren que el usuario especifique qué datos se
necesitan y cómo obtener esos datos.
· LMD no procedimientales. Requieren que el usuario especifique qué datos se
necesitan, sin especificar cómo obtener esos datos.
Una consulta es una instrucción de solicitud para recuperar información. La parte de un LMD
que implica la recuperación de información se llama lenguaje de consultas.
5. Gestión de transacciones
Varias operaciones sobre la base de datos forman a menudo una única unidad lógica de
trabajo.
Una transacción es una colección de operaciones que se lleva a cabo como una función
lógica simple en una aplicación de bases de datos. Cada transacción es una unidad de
atomicidad y consistencia.
Así se requiere que las transacciones no violen ninguna ligadura de consistencia de base de
datos. Es decir, si la base de datos era consistente cuando la transacción comenzó, la base de
datos debe ser consistente cuando la transacción termine con éxito.
Asegurar las propiedades de atomicidad y durabilidad es responsabilidad del propio sistema
de bases de datos. Si se asegura la propiedad de atomicidad, una transacción que falle no
Organización de Sistemas Informáticos 113
debe tener efecto en el estado de la base de datos. Así, la base de datos se restaura al estado en
que estaba antes de que la transacción en cuestión comenzara su ejecución.
Finalmente, cuando varias transacciones actualizan la base de datos concurrentemente, la
consistencia de los datos puede no ser preservada, incluso aunque cada transacción
individualmente sea correcta. Es responsabilidad del gestor de control de concurrencia
controlar la interacción entre las transacciones concurrentes para asegurar la consistencia de
la base de datos.
6. Administrador de la Base de Datos
Una de las principales razones para usar SGBD es tener un control centralizado tanto de los
datos como de los programas que acceden a esos datos. La persona que tiene ese control
central sobre el sistema se llama administrador de la base de datos (ABD).
Las funciones del ABD incluyen las siguientes:
· Definición del esquema.
· Estructura de almacenamiento y definición del método de acceso.
· Esquema y modificación de la organización física.
· Concesión de la autorización para el acceso a los datos.
· Especificación de las ligaduras de integridad.
7. Usuarios de la Base de Datos
Hay cuatro tipos diferentes de usuarios de un sistema de base de datos, diferenciados por la
forma en que ellos esperan interactuar con el sistema.
· Programadores de aplicaciones. Son profesionales informáticos que interactúan
con el sistema a través de llamadas al LMD, que están incluidas en un programa
escrito en un lenguaje anfitrión. Estos programas comúnmente se llaman programas
de aplicación.
· Los usuarios sofisticados interactúan con el sistema sin programas escritos. En su
lugar, ellos forman sus consultas en un lenguaje de consulta de bases de datos.
· Usuarios especializados. Son usuarios sofisticados que escriben aplicaciones de
bases de datos especializadas que no son adecuadas en el marco de procesamiento de
datos tradicional. Entre estas aplicaciones están los sistemas de diseño asistido por
computadora, sistemas de bases de conocimientos y expertos.
· Usuarios normales. Son usuarios no sofisticados que interactúan con el sistema
mediante la invocación de alguno de los programas de aplicación permanentes que se
han escrito previamente.
114 Organización de Sistemas Informáticos
 Estos niveles corresponden con los tres diferentes tipos de automatización de los sistemas de
negocios que han evolucionado durante las tres últimas décadas:

Capítulo 11 - Procesamiento electrónico de datos (PED)

- Sistemas de información de gestión (MIS)
- Sistemas de apoyo a la toma de decisiones (STD)
Sistemas de BD en las
Organizaciones Ejecutivo
Sistema de
soporte a la Informes Estratégicos
Consultas
toma de
decisiones Análisis

Sistema de
Informes de dirección
Dirigente
1. Compartir datos y bases de datos intermedio
información de
gestión
por áreas funcionales

Quizás la diferencia más significativa entre un sistema basado en archivos y un sistema de

base de datos es que los datos se comparten. Esto requiere un cambio importante en la
mentalidad de los usuarios, que están acostumbrados a sentirse “dueños” de los datos Sistema de Transacciones
Operativos procesamiento Mantenimiento archivos
resultantes de sus actividades cotidianas. Compartir los datos también requiere un cambio
electrónico de datos Procesamiento informes de control
importante en la forma en que se manejan y administran los datos dentro de la organización.

Se consideran tres formas de compartir los datos: Fig. 11-1. Niveles y compartición de datos entre unidades funcionales

- Entre unidades funcionales.
- Entre los niveles de dirección.
- Entre localidades que están geográficamente dispersas.
1.1. Compartir datos entre unidades funcionales
El término compartir datos sugiere que personas en áreas funcionales diferentes compartan
un grupo común de datos, cada cual para sus propias aplicaciones.
El efecto de combinar los datos en una base de datos produce sinergia, es decir, los datos
combinados tienen más valor que la suma de los datos en los archivos por separado.
Los PED se aplicaron por primera vez a los niveles operacionales más bajos de la
organización para automatizar el trabajo en papel. Sus características básicas incluyen:
· Foco de atención en el nivel operativo del almacenamiento, el procesamiento y el
flujo de datos.
· Procesamiento eficiente de transacciones.
· Informes resúmenes para los dirigentes.
El enfoque de los MIS elevan el foco de atención a las actividades de los sistemas de
información, con un énfasis adicional en la integración y planificación de la función de los
sistemas de información. En la práctica, estas características de los MIS incluyen:

A este fenómeno de combinar los datos para un uso común se le llama integración de datos. · Foco en la información orientada a los mandos intermedios.
· Una integración de las tareas de PED por sus funciones en los negocios, tales como
1.2. Compartir datos entre diferentes niveles de usuarios MIS de producción, MIS de marketing, MIS de personal, etc.
· Generación de encuestas e informes, usualmente como una base de datos.
Diferentes niveles de usuarios necesitan compartir datos. Normalmente se distinguen tres
Un STD se centra en un nivel aún más alto dentro de la organización, con énfasis en las
niveles de usuarios:
características siguientes:
- Personal
- Mandos intermedios
- Ejecutivos

Organización de Sistemas Informáticos 115 116 Organización de Sistemas Informáticos


· Interés centrado en la decisión, orientado a dirigentes de alto nivel y ejecutivos que
toman decisiones.
· Énfasis en la flexibilidad, adaptabilidad y la respuesta rápida.
· Apoyo a los estilos personales de toma de decisión de los dirigentes.
Estos niveles de usuarios y sistemas requieren naturalmente de tres tipos diferentes de datos.
El usuario en el nivel operacional necesita datos para los procesos de transacciones. Estos
datos detallados podrían luego resumirse para la información que se necesita en niveles más
altos. Los ejecutivos en el nivel más alto usan los sistemas de apoyo a la decisión para
descubrir las tendencias a largo plazo que se pueden aplicar a su propia corporación, así
como para identificar el entorno económico, social y político en el que deben operar.
1.3. Compartir datos entre diferentes localidades
Una base de datos centralizada es una base de datos que está físicamente situada en un
único lugar, controlado por una sola computadora. La mayoría de las funciones para las que
se crean las bases de datos se llevan a cabo más fácilmente si la base de datos está
centralizada. Es decir, es más fácil actualizar, hacer copias de seguridad, consultar y
controlar el acceso a una base de datos, si sabemos exactamente donde está y cuál es el
software que la controla.
Un sistema de base de datos distribuida está compuesto de varios sistemas de bases de
datos operando en los sitios locales y conectados por líneas de comunicación.
Los sistemas de bases de datos distribuidas son atractivos porque hacen posible la ubicación
local de los datos: Los datos residirán en los lugares donde se necesitan con más frecuencia.
Cuando una empresa comienza a distribuirse por distintas localidades, el tener una base de
datos centralizada, puede aumentar el tiempo de elaboración de informes ante la demanda que
aumenta. Mediante un sistema distribuido, podemos almacenar los datos que necesitamos con
mayor frecuencia localmente y acelerar el tiempo en obtener esos datos.
2. Planificación estratégica de bases de datos
Moverse de una situación en la que los datos son privados y fragmentados a una en la que los
datos son compartidos es más fácil decirlo que hacerlo. Para tener éxito, los datos se deben
ver como recurso colectivo y por lo tanto otros recursos colectivos se deben destinar a su
desarrollo, su realización y su utilización en una o varias bases de datos.
Un elemento esencial en este proceso es la planificación de la base de datos. La planificación
de la base de datos es un esfuerzo colectivo estratégico para determinar las necesidades de la
organización para un extenso período de tiempo en el futuro.
Organización de Sistemas Informáticos 117
2.1. El proyecto de planificación de la base de datos
La planificación estratégica de la base de datos empieza por la directiva de mayor rango.
Ellos asignan los recursos, e identifican el personal que participará en el proyecto.
El equipo de proyecto debe tener una amplia experiencia en sistemas de información y en
otras áreas funcionales de la compañía. Se recomienda un grupo de cuatro miembros a
tiempo completo, dos de sistemas de información y dos que estén familiarizados con la
mayoría de las áreas de la compañía. Todos los miembros del equipo deben ser empleados
cualificados y capaces, puesto que su trabajo tendrá un gran impacto en la organización para
muchos años.
Durante el proyecto, tal equipo interactúa con los directivos de mayor nivel de cada una de las
áreas primarias de usuarios. Los usuarios finales de mayor nivel identifican los procesos
principales, las actividades y las entidades que se usan en el procesamiento manual o
automatizado de la información. El equipo de proyecto sintetiza estos datos en un modelo de
información corporativa que se incluye como parte de un comprensivo plan de base de datos.
Para que el proyecto cumpla sus objetivos dentro de la organización, éste no debería
demorarse más de seis meses. Al cabo de ese tiempo, se debería entregar al director general
un informe que cubra al menos los próximos cinco años. Este informe debe incluir el análisis
de lo siguiente:
· Necesidades de información de las áreas funcionales.
· Necesidades de información de los diferentes niveles de dirección.
· Necesidades de información de las localidades geográficas.
· Un modelo de estas necesidades de información.
· Volúmenes anticipados de datos por localidad geográfica para el período bajo
estudio.
· Una estimación preliminar de los costos asociados a las actualizaciones del sistema.
· Recomendaciones para un desarrollo detallado de las nuevas o mejoradas bases de
datos junto con sus planes.
El equipo de proyecto no debe hacer un modelo de información detallado en este plan. Los
modelos detallados se deben desarrollar en los proyectos subsiguientes de diseño de la base
de datos. En lugar de esto, el equipo del proyecto debería identificar los elementos estables
de la estructura de la información de la organización, elementos que no se alteren con
cambios organizacionales.
2.2. El ciclo de vida del desarrollo de la base de datos
El ciclo de vida del desarrollo de la base de datos incluye:
· Información recolectada para determinar las necesidades de los usuarios.
· El diseño del esquema de la base de datos (estructura lógica) para satisfacer esas
necesidades.
118 Organización de Sistemas Informáticos
 · La selección de un SGBD para dar soporte al uso de la base de datos.
· El desarrollo de programas para utilizar la base de datos.
· Una revisión de las necesidades de información de los usuarios en el contexto de la
base de datos desarrollada.
3. Bases de datos y gestión de control
Al ser un recurso de la compañía que es de un valor significativo, la base de datos requiere de
protección y control. Esta responsabilidad usualmente se le asigna al administrador de la
base de datos (ABD).
Las funciones del ABD incluyen:
· Diseño de la base de datos.
· Formación del usuario.
· Seguridad e integridad de la base de datos.
· Rendimiento de la base de datos.
3.1. Diseño de bases de datos
El diseño conceptual de la base de datos consiste primariamente en la definición de los
elementos de datos que se van a incluir en la base de datos, las interrelaciones que existen
entre ellos y las restricciones que se aplican a los valores de los datos.
El ABD ocupa un lugar estratégico en la definición y establecimiento de los estándares de la
compañía. Puesto que el diseño de la base de datos se controla centralmente, el ABD puede
definir estándares sobre cómo se deben poner los nombres; sobre los formatos de los datos;
sobre los formatos de las pantallas, de los informes y de los archivos. Esto simplifica la
documentación y los requisitos de entrenamiento y facilita la integración de los sistemas
dentro de la compañía.
Las decisiones de diseño se documentan en el diccionario de datos. El ABD controla el
contenido de este diccionario de datos y registra en éste como metadatos los nombres de los
elementos de datos, los archivos, las pantallas, las formas de los informes y otros.
3.2. Formación del usuario
Muchas de las ventajas resultantes de compartir los datos sólo pueden manifestarse en la
práctica si los usuarios entienden cómo usar las facilidades del SGBD. El ABD es
responsable de educar a los usuarios en la estructura de la base de datos y en su acceso a
través del SGBD.
Organización de Sistemas Informáticos 119
3.3. Seguridad e integridad de los datos
El concepto de combinar los datos en una organización en un lugar común accesible a todos
tiene sus ventajas y sus desventajas. La ventaja obvia de compartir los datos puede
desplazarse por la desventaja de que los datos se pueden trastocar o dañar por usuarios que
no tengan una responsabilidad o autoridad sobre los mismos.
El ABD asigna la propiedad de los datos en una vista de la base de datos al grupo que lo
originó. El grupo propietario puede entonces otorgar el acceso a los datos en la vista a otros
miembros dentro de la organización. Este acceso se puede restringir a porciones de los datos,
permitir el acceso sólo para la recuperación, o permitir acceso y actualización. La
información que tiene que ver con los derechos de acceso a los datos es mantenida por el
ABD en el diccionario de datos.
La integridad de los datos tiene que ver con el problema de mantener la precisión y
consistencia de los valores de los datos. Los mecanismos de seguridad, tales como las
contraseñas y las vistas de los datos, protegen la integridad de los datos. Adicionalmente se
pueden mantener en el diccionario de datos restricciones sobre los valores.
3.4. Rendimiento del sistema de base de datos
Un sistema de base de datos al que accedan simultáneamente muchos usuarios puede
responder a veces muy lentamente debido a que los problemas físicos asociados a los usuarios
que están compitiendo por los recursos no son triviales.
El equipo de ABD debe diagnosticar y resolver los problemas de tiempo de respuesta del
sistema. La solución del problema puede implicar la compra de hardware, la construcción de
índices para el acceso rápido a grandes volúmenes de datos, etc.
4. Riesgos y costos de las bases de datos
El efecto sinérgico de las bases de datos, la estandarización del diseño de los datos, los
procedimientos de manipulación, los beneficios de seguridad, el poder de los lenguajes de
manipulación de datos y la amplitud de funciones de sistema que brindan los SGBD son
todos beneficios positivos.
Sin embargo, los sistemas de bases de datos tienen también sus inconvenientes.
4.1. Conflictos en las organizaciones
Poner los datos en una base de datos común puede que no sea políticamente factible en
algunas organizaciones. Ciertos grupos de usuarios pueden no estar de acuerdo en ceder el
control de los datos, lo cual es necesario para extender la integración de los mismos. Es más,
el riesgo que implica compartir datos (por ejemplo, un grupo puede dañar los datos de otro
120 Organización de Sistemas Informáticos
grupo) y los problemas potenciales del sistema que pueden limitar los accesos de un grupo a
sus propios datos pueden ser vistos más como un contratiempo que como un beneficio.
4.2. Fracasos en el desarrollo de proyectos
Los proyectos a desarrollar en un sistema de base de datos puede fracasar por varias razones.
En ocasiones son los dirigentes los que no están en primer lugar convencidos del valor del
sistema de base de datos. Un proyecto de base de datos que parezca muy largo pudiera ser
cancelado.
Un proyecto muy grande en alcance puede ser imposible de completarse en un tiempo
razonable. En este caso, los dirigentes y los usuarios comienzan a desencantarse y el proyecto
fracasa.. En este caso una mejor estrategia podría ser dividir el proyecto de base de datos en
varios proyectos para desarrollar varias bases de datos o una base de datos en varias etapas.
Finalmente, durante el transcurso del desarrollo del proyecto, el personal clave puede
abandonar inesperadamente la compañía. Si no puede encontrarse personal para
reemplazarlo, entonces el proyecto pudiera no terminarse con éxito.
4.3. Malfuncionamiento del sistema
Cuando el sistema de cómputo no esté operativo, todos los usuarios directamente implicados
en el acceso a la base de datos deben esperar a que el sistema vuelva a estar de nuevo en
funcionamiento. Si el sistema o el software de aplicación falla, esto pudiera ocasionar un
daño permanente en la base de datos.
Un sistema de base de datos distribuida también reduce el riesgo de averías de hardware en
un sistema de base de datos centralizado, ya que el sistema distribuido funciona sobre varias
computadoras. Si una computadora del sistema falla, el sistema puede continuar operando en
los otros computadores.
4.4. Costes imprevistos
El enfoque de desarrollar y usar una base de datos puede requerir de inversiones tanto en
hardware como en software. El hardware para correr un gran SGBD debe ser eficiente y
puede requerir generalmente de más memoria principal y almacenamiento en disco que un
simple sistema basado en archivos.
El SGBD usualmente incluye muchas facilidades, algunas de las cuales pueden no
necesitarse en una organización en particular. No obstante, estos recursos pueden costar
dinero y usar disco y memoria del sistema.
El SGBD puede también aumentar los costos de operación, ya que requiere mayor tiempo de
ejecución.
Organización de Sistemas Informáticos 121
5. Desarrollo de la base de datos
Esta sección se centrará en el procedimiento de desarrollo del esquema conceptual de la
base de datos, identificando los datos que se incluirán en la base de datos y desarrollando
los programas para actualizar y procesar los datos. Este proceso se denomina ciclo de
vida del desarrollo de la base de datos.
5.1. Planificación preliminar
La planificación preliminar de un sistema de base de datos específico tiene lugar durante el
proyecto de planificación estratégica de la base de datos. Durante este proceso, la firma
recoge información para responder a las preguntas siguientes:
· ¿Cuántos programas de aplicación están en uso y qué funciones realizan?
· ¿Qué archivos están asociados con cada una de las aplicaciones?
· ¿Qué nuevas aplicaciones y archivos están bajo desarrollo?
También ayuda a identificar futuros requisitos del sistema y para apreciar los beneficios
económicos de un sistema de base de datos. Esto se documenta en un modelo conceptual de
datos generalizado.
5.2. Estudio de viabilidad
Un estudio de viabilidad implica la preparación de un informe con las características
siguientes:
· Viabilidad tecnológica. ¿Hay tecnología adecuada disponible para dar soporte al
desarrollo de la base de datos?
· Viabilidad operacional. ¿Tiene la compañía personal, presupuesto y experiencia
interna para hacer que un sistema de base de datos tenga éxito?
· Viabilidad económica. ¿Se pueden identificar los beneficios? ¿Los beneficios
costearían el sistema que se desea? ¿Se pueden medir los costos y los beneficios?
5.3. Definición de requisitos
La definición de los requisitos involucra a la definición del alcance de la base de datos, la
identificación de requisitos de información de las áreas funcionales y administrativas y la
determinación de los requisitos de software y el hardware.
Los requisitos de información se determinan por las respuestas a cuestionarios, entrevistas
con los directivos y usuarios de oficina y los informes y formularios que están en uso
actualmente.
El modelo de información general que se crea durante la planificación de la base de datos se
expande a modelos para cada una de las áreas funcionales. Estas son las bases para el
diseño detallado de la base de datos que se llevará a cabo en la etapa siguiente.
122 Organización de Sistemas Informáticos
5.4. Diseño conceptual
La etapa de diseño conceptual crea el esquema conceptual de la base de datos. Se
desarrollan las especificaciones hasta el punto en que puede comenzar la implementación.
Durante esta etapa se crean modelos detallados de las vistas de los usuarios y se integran en
un modelo conceptual de datos que registra todos los elementos colectivos que se deben
mantener en la base de datos.

5.5. Implementación
Durante la implementación de la base de datos se selecciona y adquiere un SGBD. Luego el
modelo conceptual detallado se convierte al modelo de implementación del SGBD, se
construye el diccionario de datos, se puebla la base de datos, se desarrollan los programas de
aplicación y se entrenan los usuarios.

5.6. Evaluación y perfeccionamiento del esquema de la BD

La evaluación implica entrevistas con los usuarios para determinar si se han omitido algunos
datos necesarios. Se hacen cambios que se necesiten. Con el tiempo el sistema se mantiene,
introduciéndole mejoras y añadiéndole nuevos programas y elementos de datos en la medida
que cambian y se amplían las necesidades del negocio.

Organización de Sistemas Informáticos 123 124 Organización de Sistemas Informáticos

 Módulo IV
SISTEMAS DISTRIBUIDOS
Y REDES

Organización de Sistemas Informáticos 125 126 Organización de Sistemas Informáticos

 1.2. Un modelo para las comunicaciones

Capítulo 12
Comunicación de datos y
redes de ordenadores

1. Introducción
1.1. Redes y sistemas distribuidos
Usaremos el término red de computadoras para referirnos a una colección interconectada de
computadoras autónomas.
Fig. 12-1. Modelo de comunicaciones
Se dice que dos computadoras están interconectadas si son capaces de intercambiar
información.
El objetivo principal de todo sistema de comunicaciones es intercambiar información entre
dos entidades. En la figura podemos ver un ejemplo particular de comunicación entre una
Al indicar que las computadoras son autónomas, queremos excluir de nuestra definición a los
estación de trabajo y un servidor a través de una red telefónica pública. Otro posible ejemplo
sistemas en los que existe una clara relación amo-esclavo. Si una computadora puede
es el intercambio de señales de voz entre dos teléfonos a través de la misma red anterior. Los
arrancar, parar o controlar otra a voluntad, las computadoras no son autónomas. Un sistema
elementos clave en este modelo son los siguientes:
con una unidad de control y muchos esclavos no es una red; tampoco lo es una computadora
grande con impresoras y terminales remotas.
· La fuente. Este dispositivo genera los datos a transmitir; por ejemplo teléfonos o
computadores personales.
Existe considerable confusión entre la red de computadoras y un sistema distribuido. La
diferencia radica en que en el sistema distribuido la existencia de múltiples computadoras
autónomas es transparente para el usuario. El usuario puede teclear una orden para ejecutar un · El transmisor. Normalmente los datos generados por la fuente no se transmiten
programa y éste se ejecutará. La tarea de seleccionar el mejor procesador, encontrar y directamente como son generados. Al contrario, el transmisor transforma y codifica la
transportar todos los archivos de entrada al procesador y poner los resultados en el lugar información produciendo señales electromagnéticas susceptibles de ser transmitidas a
apropiado, corresponde al sistema operativo. través de algún sistema de transmisión. Por ejemplo, un modem convierte las cadenas
de bits generadas por un computador personal y los transforma en señales analógicas
que pueden ser transmitidas a través de la red telefónica.
En una red, el usuario debe ingresar de forma explícita en una máquina, enviar los trabajos
remotos explícitamente, mover explícitamente los archivos y en general, llevar a cabo de
manera personal el manejo de la red. En un sistema distribuido nada se tiene que hacer de · El sistema de transmisión, que puede ser desde una simple línea de transmisión
forma explícita; el sistema lo hace todo automáticamente sin que el usuario tenga hasta una compleja red que conecte la fuente con el destino.
conocimiento de ello.
· El receptor, que acepta la señal proveniente del sistema de transmisión y la
En efecto, un sistema distribuido es un sistema de software construido encima de una red, a convierte de tal manera que pueda ser manejada por el dispositivo destino. Por
la que el software confiere un alto grado de cohesión y transparencia. Así, la distinción entre ejemplo, un modem aceptará la señal analógica de la red o línea de transmisión y la
una red y un sistema distribuido tiene que ver con el software más que con el hardware convertirá en una cadena de bits.
(especialmente el sistema operativo).
· El destino, que toma los datos del receptor.

Organización de Sistemas Informáticos 127 128 Organización de Sistemas Informáticos

Para que un dispositivo pueda transmitir tendrá que hacerlo a través de la interfaz con el
medio de transmisión. Una vez que la interfaz está establecida, se necesitará la generación
de la señal. Las características de la señal, es decir, la forma y la intensidad, deben ser tales
que permitan 1) interpretar la señal y 2) ser interpretada en el receptor como datos.
Las señales se deben generar no solamente considerando que deben cumplir los requisitos del
sistema de transmisión y del receptor, sino que deben permitir alguna forma de sincronizar el
receptor y el emisor. El receptor debe ser capaz de determinar cuando comienza y cuando
acaba la señal recibida. Igualmente deberá conocer la duración de cada elemento de la señal.
Además de las cuestiones básicas referentes a la naturaleza y temporización de las señales, se
necesitará un conjunto de requisitos que se deben verificar y que se pueden englobar bajo el
término gestión de intercambio. Si se necesita intercambiar datos durante un periodo de
tiempo, las dos partes deben cooperar. En los dispositivos para el procesamiento de datos, se
necesitarán ciertas convenciones además del simple hecho de establecer la conexión. Por
ejemplo se deberá establecer si ambos dispositivos pueden transmitir simultáneamente o
deben guardar turnos, se deberá decidir la cantidad y el formato de los datos que se transmiten
cada vez.
En los sistemas de comunicaciones es posible que aparezcan errores; es decir, la señal
transmitida se distorsiona de alguna manera antes de alcanzar su destino. Por tanto, en
circunstancias donde no se puedan tolerar errores, se necesitarán procedimientos para la
detección y corrección de errores.
Para evitar que la fuente no sature al destino transmitiendo datos más rápidamente de lo que
el receptor pueda procesar y absorber, se necesitan una serie de procedimientos denominados
control de flujo.
Conceptos relacionados pero distintos a los anteriores son el direccionamiento y el
encaminamiento. Cuando cierto recurso se comparte por más de dos dispositivos, el sistema
fuente deberá de alguna manera indicar a dicho recurso compartido la identidad del destino.
El sistema de transmisión deberá garantizar que ese y sólo ese destino reciba los datos. Es
más, el sistema de transmisión puede ser una red donde haya la posibilidad de más de un
camino para alcanzar el destino; en este caso se necesitará por tanto la elección de una de
entre las posibles rutas.
La recuperación es un concepto distinto a la corrección de errores. En ciertas situaciones en
las que el intercambio de información, por ejemplo una transacción de una base de datos o la
transferencia de un fichero, se vea interrumpida por algún fallo, se necesitará un mecanismo
de recuperación. El objetivo será pues, o bien ser capaz de continuar transmitiendo desde
donde se produjo la interrupción, o al menos recuperar el estado donde se encontraban los
sistemas involucrados antes de comenzar el intercambio.
El formato de mensajes está relacionado con la conformidad que debe existir entre las dos
partes en lo que se refiere al formato de los datos intercambiados. Por ejemplo, ambos lados
deben coincidir en el uso del mismo código binario para representar los caracteres.
Organización de Sistemas Informáticos 129
Además, frecuentemente es necesario dotar al sistema de algunas medidas de seguridad. El
emisor debe asegurarse de que sólo el destino deseado reciba los datos. Igualmente, el
receptor querrá estar seguro de que los datos recibidos no se han alterado en la transmisión y
que dichos datos realmente provienen del supuesto emisor.
2. Usos de las redes de computadoras
2.1. Redes para compañías
Muchas organizaciones tienen una cantidad importante de computadoras en operación, con
frecuencia alejadas entre sí. Por ejemplo, una compañía con muchas fábricas puede tener una
computadora en cada localidad para llevar el control de los inventarios, vigilar la
productividad y pagar la nómina local. Inicialmente, cada una de estas computadoras puede
haber trabajado aislada de las otras, pero en algún momento la gerencia decidió conectarlas
para poder extraer y correlacionar información acerca de toda la compañía.
La cuestión aquí es compartir los recursos y la meta es hacer que todos los programas, el
equipo y especialmente los datos estén disponibles para cualquiera en la red, sin importar la
localización física de los recursos y de los usuarios.
Una segunda meta es lograr una alta confiabilidad al contar con fuentes alternativas de
suministro. Por ejemplo, todos los archivos podrían replicarse en dos o tres máquinas; así, si
una de ellas no está disponible, podrán usarse las otras copias.
Otra meta es ahorrar dinero. Las computadoras pequeñas tienen una relación
precio/rendimiento mucho mejor que las grandes. Las mainframes son aproximadamente 10
veces más rápidas que las computadoras personales, pero cuestan 1000 veces más. Este
desequilibrio ha ocasionado que muchos diseñadores construyan sistemas compuestos por
computadoras personales, una por usuario, con los datos guardados en una o más máquinas
servidoras de archivos compartidas. En este modelo, los usuarios se denominan clientes, y
el conjunto completo se llama modelo cliente-servidor.
Otra meta al establecer redes es la escalabilidad: la capacidad para incrementar el
rendimiento del sistema gradualmente cuando la carga de trabajo crece, añadiendo solamente
más procesadores.
Un objetivo más del establecimiento de una red de computadoras tiene poco que ver con la
tecnología. Una red de computadoras puede proporcionar un potente medio de comunicación
entre empleados que están muy distantes. Al usar una red, es fácil para dos o más personas
que viven lejos escribir un informe juntas.
A largo plazo, el uso de redes para mejorar la comunicación entre las personas probablemente
resultará más importante que las metas técnicas tales como la mejora de la confiabilidad.
130 Organización de Sistemas Informáticos
2.2. Redes para la gente
Al iniciar la década de 1990, las redes de computadoras comenzaron a prestar servicios a
particulares en su hogar. Estos servicios y la motivación para usarlos son muy diferentes del
modelo de “eficiencia corporativa” descrito en la sección anterior. A continuación
esbozaremos tres de los más estimulantes aspectos de esta evolución:
· Acceso a información remota.
· Comunicación persona a persona.
· Entretenimientos interactivos.
El acceso a información remota vendrá de muchas formas. Un área en la cual ya está
sucediendo es el acceso a las instituciones financieras. Mucha gente paga sus facturas,
administra sus cuentas bancarias y maneja sus inversiones en forma electrónica.
Los periódicos se publicarán en línea y serán personalizados.
3.1. Redes de área local
Las redes de área local, generalmente llamadas LAN (local area network), son redes de
propiedad privada dentro de un solo edificio o campus de hasta unos cuantos kilómetros de
extensión. Se usan ampliamente para conectar computadoras personales y estaciones de
trabajo en oficinas de compañías y fábricas con objeto de compartir recursos (por ejemplo
impresoras) e intercambiar información. Las LAN se distinguen de otro tipo de redes por tres
características: Su tamaño, su tecnología de transmisión y su topología.
Las LAN están restringidas en tamaño, lo cual significa que el tiempo de transmisión del
peor caso está limitado y se conoce de antemano. Conocer este límite hace posible usar
ciertos tipos de diseños que de otra manera no serían prácticos, y también simplifica la
administración de la red.
Las LAN a menudo usan una tecnología de transmisión que consiste en un cable sencillo al
cual están conectadas todas las máquinas.

Otra aplicación en ésta categoría es el acceso a sistemas de información como la actual red Las LAN de transmisión pueden tener diversas topologías; la figura muestra dos de ellas.
mundial (World Wide Web), la cual contiene información sobre arte, negocios, cocina,
gobierno, salud, historia, aficiones, recreación, ciencia, deportes, viajes y muchos otros temas.

Millones de personas utilizan ya el correo electrónico o email para comunicarse.

Los grupos de noticias a nivel mundial, con discusiones sobre todos los temas concebibles
son ya comunices entre un grupo de personas.

La tercera categoría es el entretenimiento, juegos de simulación en tiempo real

multipersonales, simuladores de vuelo en los que los jugadores de un equipo tratan de
derribar a los del equipo contrario, ...
Fig. 12-3. Topología de redes. a) Bus. b) En anillo
3. Hardware de red
En una red de bus (esto es, un cable lineal), en cualquier instante una computadora es la
Vamos a ver una clasificación de las redes en función de su escala. máquina maestra y puede transmitir; se pide a las otras máquinas que se abstengan de enviar
mensajes. Es necesario un mecanismo de arbitraje para resolver conflictos cuando dos o más
Distancia entre Ubicación
Ejemplo máquinas quieren transmitir simultáneamente.
procesadores procesadores
0,1 m Tarjeta de circuitos Procesador paralelo
Un segundo tipo de sistema de difusión es el anillo. En un anillo, cada bit se propaga por sí
1m Sistema Multicomputadora
10 m Cuarto mismo, sin esperar al resto del paquete al cual pertenece. Típicamente, cada bit recorre el
100 m Edificio Red de área local anillo entero en el tiempo que toma transmitir unos pocos bits, a veces antes de que el paquete
1 km Campus entero se haya transmitido. Como en todos los sistemas de difusión, se necesitan reglas para
10 km Ciudad Red de área metropolitana arbitrar el acceso simultáneo al anillo.
100 km País
Red de área amplia
1.000 km Continente
10.000 km Planeta Internet

Fig. 12-2. Clasificación de redes según su escala

Organización de Sistemas Informáticos 131 132 Organización de Sistemas Informáticos


3.2. Redes de área metropolitana
Una red de área metropolitana o MAN (metropolitan area network) es básicamente una
versión más grande de una LAN y normalmente se basa en una tecnología similar. Podría
abarcar un grupo de oficinas corporativas cercanas o una ciudad y podría ser privada o
pública. Una MAN sólo tiene uno o dos cables y no contiene elementos de conmutación, lo
cuales desvían los paquetes por una de varias líneas de salida potenciales. Al no tener que
conmutar se simplifica el diseño.
Cuando se envía un paquete de un enrutador a otro a través de uno o más enrutadores
intermedios, el paquete se recibe completo en cada enrutador intermedio, se almacena hasta
que la línea de salida requerida está libre, y a continuación se reenvía. Una subred basada en
este principio se llama de punto a punto.
Cuando se usa una subred punto a punto, una consideración de diseño importante es la
topología de interconexión del enrutador. Podemos ver algunas a continuación:

3.3. Redes de área amplia

Una red de área amplia o WAN (wide area network), se extiende sobre un área geográfica
extensa, a veces un país o un continente; contiene una colección de máquinas dedicadas a
ejecutar programas de usuario. Seguiremos el uso tradicional y llamaremos a estas máquinas
hosts. Los hosts están conectados por una subred de comunicación, o simplemente subred.
El trabajo de la subred es conducir mensajes de un host a otro. La separación entre los
aspectos exclusivamente de comunicación de la red y los aspectos de aplicación, simplifica
enormemente el diseño total de la red.

En muchas redes de área amplia, la subred tiene dos componentes distintos: las líneas de
transmisión y los elementos de conmutación.

Las líneas de transmisión (también llamadas circuitos o canales) mueven bits de una
máquina a otra.

Los elementos de conmutación son computadoras especializadas que conectan dos o más
líneas de transmisión. Cuando los datos llegan por una línea de entrada, el elemento de Fig. 12-5. Topologías de interconexión de enrutadores. a) Estrella. b) Anillo. c) Árbol. d) Totalmente
conmutación debe escoger una línea de salida para reenviarlos. Para las computadoras de conectada. e) Doble anillo. f) Irregular
conmutación usaremos la palabra enrutador.
3.4. Interredes
Existen muchas redes en el mundo, a veces con diferente hardware y software. La gente
conectada a una red a menudo quiere conectarse con gente conectada a una red distinta. Esto
requiere conectar redes diferentes y con frecuencia incompatibles, algunas veces usando
máquinas llamadas pasarelas para hacer la conexión y realizar la traducción necesaria, ambas
en términos de hardware y software. Una colección de redes interconectadas se llama
interred.

Fig. 12-4. Interconexión en una red de área amplia

Organización de Sistemas Informáticos 133 134 Organización de Sistemas Informáticos


Capítulo 13
Ingeniería del Software
Cliente/Servidor
1. Estructura de los sistemas cliente/servidor
Las tecnologías de hardware, de software, de bases de datos y de redes contribuyen todas ellas
a las arquitecturas de computadoras distribuidas y cooperativas. En su forma más
general, una arquitectura de computadora distribuida y cooperativa se ilustra en la siguiente
figura:
Fig. 13-1. Arquitectura de ordenadores distribuida en una corporación
Un sistema raíz, que típicamente será una gran computadora, actúa como depósito de los
datos corporativos. El sistema raíz está conectado con servidores y que poseen un doble
papel. Los servidores actúan para actualizar y solicitar datos corporativos mantenidos por el
sistema raíz. Además mantienen sistemas departamentales locales y desempeñan un papel
clave al poner en red los PC del nivel de usuario a través de una red de área local (LAN).
En una estructura C/S la computadora que reside por encima de otra computadora se
denomina servidor, y las computadoras de nivel inferior se denominan clientes. Los clientes
solicitan servicios, y el servidor se los proporciona. En el contexto de la arquitectura
presentada se pueden llevar a cabo un cierto número de implementaciones distintas:
Organización de Sistemas Informáticos
· Servidores de archivos. El cliente solicita registros específicos de un archivo. El
servidor transmite estos registros al cliente a través de la red.
· Servidores de bases de datos. El cliente envía solicitudes en lenguaje de consulta
estructurado (SQL) al servidor. Éstas se transmiten como mensajes a través de la red.
El servidor procesa la solicitud SQL y halla la información solicitada, pasando
únicamente los resultados al cliente.
· Servidores de transacciones. El cliente envía una solicitud que invoca
procedimientos remotos en el centro servidor. Los procedimientos remotos pueden ser
un conjunto de sentencias SQL. Se produce una transacción cuando una solicitud da
lugar a la ejecución de procedimientos remotos y a la transmisión del resultado al
cliente.
· Servidores de grupos de trabajo. Cuando el servidor proporciona un conjunto de
aplicaciones que hacen posible la comunicación entre clientes (y las personas que los
usan) mediante el uso de texto, imágenes, boletines electrónicos, video y otras
representaciones, existe una arquitectura de grupos de trabajo.
2. Componentes de software para sistemas C/S
El software que es adecuado para una arquitectura cliente/servidor posee varios componentes
distintos que se pueden asociar al cliente o al servidor, o se pueden distribuir entre ambas
máquinas:
· Componente de interacción con el usuario y presentación. Este componente
implementa todas las funciones que típicamente se asocian a una interfaz gráfica de
usuario (IGU).
· Componente de aplicación. Este componente implementa los requisitos definidos
por la aplicación en el contexto del dominio en el cual funciona la aplicación. El
software de aplicación se puede descomponer de tal modo que alguno de los
componentes residan en el cliente y otros residan en el servidor.
· Gestión de bases de datos. Este componente lleva a cabo la manipulación y gestión
de datos requerida por una aplicación. La manipulación y gestión de datos puede ser
tan sencilla como la transferencia de un registro, o tan compleja como el
procesamiento de sofisticadas transacciones SQL.
Además de estos componentes, existe otro bloque de construcción del software, que suele
denominarse software intermedio en todos los sistemas C/S. El software intermedio consta
de elementos de software que existen tanto en el cliente como en el servidor, e incluye
elementos de sistemas operativos en red así como un software de aplicación especializado
que presta su apoyo a las aplicaciones específicas de bases de datos, a estándares de
distribución de solicitudes de objetos, a tecnologías de trabajo en grupo, a gestión de
comunicaciones, y a otras características que facilitan la conexión cliente/servidor.
135 136 Organización de Sistemas Informáticos
3. Distribución de componentes de software
Una vez que se han determinado los requisitos básicos de una aplicación cliente/servidor,
debe decidirse la forma en que se distribuirán los componentes de software entre el cliente y
el servidor.

Cuando la mayor parte de la funcionalidad asociada a cada uno de los tres componentes se le
asocia al servidor, se ha creado un diseño de servidor principal. A la inversa, cuando el
cliente implementa la mayor parte de los componentes de interacción/presentación con el
usuario, de aplicación y de bases de datos, se tiene un diseño de cliente principal.

Los clientes principales suelen encontrarse cuando se implementan arquitecturas de servidor

de archivo y de servidor de base de datos. En este caso, el servidor proporciona apoyo para la
gestión de datos, pero todo el software de aplicación y de IGU reside en el cliente.

Los servidores principales son los que suelen diseñarse cuando se implementan sistemas de
transacciones y de trabajo en grupo. El servidor proporciona el apoyo de la aplicación
necesario para responder a transacciones y comunicaciones que provengan de los clientes. El
software de cliente se centra en la gestión de IGU y de comunicaciones.

4. Líneas generales para distribuir componentes de

aplicaciones
Aún cuando no existen reglas absolutas que describan la distribución de componentes de
aplicaciones entre el cliente y el servidor, suelen seguirse las siguientes líneas generales:

· El componente de presentación/interacción suele ubicarse en el cliente. La

disponibilidad de entornos basados en ventanas y de la potencia de cómputo necesaria
para una interfaz gráfica de usuario hace que este enfoque sea eficiente en términos de
coste.

· Si es necesario compartir la base de datos entre múltiples usuarios conectados a

través de la LAN, entonces la base de datos suele ubicarse en el servidor. El sistema
de gestión de la base de datos y la capacidad de acceso a la base de datos también se
asignan al servidor, junto con la base de datos física.

· Los datos estáticos que se utilicen como referencia deberían de asignarse al cliente.
Esto sitúa los datos más próximos al usuario que tiene necesidad de ellos, y minimiza
un tráfico de red innecesario y la carga del servidor.

El resto de los componentes de aplicación se distribuye entre cliente y servidor basándose en

la distribución que optimice las configuraciones de cliente y servidor y de la red que los
conecta.

Organización de Sistemas Informáticos 137 138 Organización de Sistemas Informáticos

 Módulo V
SISTEMAS DE AYUDA A LA
TOMA DE DECISIONES

Organización de Sistemas Informáticos 139 140 Organización de Sistemas Informáticos


Capítulo 14
Ingeniería del Software
asistida por computadora
1. Definición de CASE
El mejor taller de un artesano (sea mecánico, carpintero o ingeniero del software) tiene tres
características fundamentales:
- Una colección de herramientas útiles que le ayudarán en todos los pasos de la
construcción de un producto.
- Una disposición organizada que permite hallar rápidamente las herramientas y
permite utilizarlas con eficiencia.
- Un artesano muy capaz que comprenda la forma de utilizar las herramientas de
manera efectiva.
El taller de la ingeniería del software se denomina entorno de apoyo de proyectos
integrados, y el conjunto de herramientas que llena ese taller se denomina ingeniería del
software asistida por computadora (CASE).
Las herramientas CASE son un complemento de la caja de herramientas del ingeniero del
software. CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales
y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y
de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas, las
herramientas CASE ayudan a asegurar que la calidad sea algo diseñado antes de llegar a
construir el producto.
2. Niveles de integración CASE
Algunas herramientas CASE siguen siendo “soluciones puntuales”, es decir, se utiliza una
herramienta que preste su apoyo en una actividad de ingeniería del software concreta (p.e.
análisis y modelado), pero esta herramienta no se comunica directamente con otras, no está
unida a una base de datos del proyecto, y no forma parte de un entorno integrado CASE (I-
Organización de Sistemas Informáticos 141
CASE). Aún cuando esta situación no es ideal, se puede utilizar una herramienta CASE
eficientemente, aunque se trate de una solución puntual.
Los niveles relativos de integración CASE se muestran en la siguiente figura:
Fig. 14-1. Niveles relativos de integración CASE
En el extremo inferior del espectro de integración se encuentra la herramienta individual
(solución puntual).
Cuando las herramientas individuales proporcionan capacidades adecuadas para el
intercambio de datos (tal como hace la mayoría), el nivel de integración mejora ligeramente.
Estas herramientas producen su salida en un formato estándar que debería de resultar
compatible con otras herramientas que sean capaces de leer ese formato.
En algunos casos, los constructores de herramientas CASE complementarias trabajan a la vez
para formar un puente entre herramientas (p.e. una herramienta de análisis y diseño que se
enlaza con un generador de código). Mediante el uso de este enfoque, la sinergia entre
herramientas puede producir unos resultados finales que sería difícil crear empleando cada
una de las herramientas por separado.
La integración de fuente única se produce cuando un único vendedor de herramientas
CASE integra un cierto número de herramientas distintas y las vende en forma de paquete.
Aún cuando este enfoque es bastante eficiente, la arquitectura cerrada de la mayoría de los
entornos de fuente única evita una adición sencilla de herramientas procedentes de otros
fabricantes.
En el extremo superior del espectro de integración se encuentra el entorno de apoyo de
proyectos integrado (EAPI). Se crean estándares para cada uno de los bloques de
142 Organización de Sistemas Informáticos

construcción descritos anteriormente. Los fabricantes de herramientas CASE utilizan estos
estándares EAPI para construir herramientas que sean compatibles con el EAPI, y que por
tanto sean compatibles entre sí.
3. Taxonomía de herramientas CASE
Las herramientas CASE se pueden clasificar por su función, por su papel como instrumentos
para administradores, por su utilización en los distintos pasos del proceso de ingeniería del
software. La taxonomía presentada utiliza como criterio principal la función.
· Herramientas de ingeniería de la información.
Al modelar los requisitos de información estratégica de una organización, las
herramientas de la ingeniería de la información proporcionan un metamodelo del cual
se derivan sistemas de información específicos.
El objetivo primordial de las herramientas de esta categoría consiste en representar
objetos de datos de negocios, sus relaciones, y la forma en que fluyen estos objetos de
datos entre distintas zonas de negocio en el seno de la compañía.
· Modelado de procesos y herramientas de administración.
Si una organización intenta mejorar un proceso de negocios (o de software) lo primero
que debe hacer es entenderlo. Las herramientas de modelado de procesos se utilizan
para representar los elementos clave del proceso de modo que sea posible entenderlo
mejor.
· Herramientas de planificación de proyectos.
Se concentran en dos áreas primordiales: estimación de esfuerzos de proyecto y de
costes de software, y planificación de proyectos.
Las herramientas de estimación calculan el esfuerzo estimado, la duración del
proyecto y el número recomendado de personas.
Las herramientas de planificación de proyectos capacitan al administrador para
definir todas las tareas del proyecto (la estructura de desglose de tareas), para crear
una red de tareas (normalmente empleando una entrada gráfica), para representar las
interdependencias entre tareas y para modelar la cantidad de paralelismo que sea
posible para ese proyecto.
Organización de Sistemas Informáticos 143
· Herramientas de análisis de riesgos.
La identificación de riesgos potenciales y el desarrollo de un plan para mitigar,
monitorizar y administrar esos riesgos tiene una importancia fundamental en los
grandes proyectos. Estas herramientas suelen construir una tabla de riesgos y
proporcionan una guía detallada en la identificación y análisis de riesgos.
· Herramientas de administración de proyectos.
La planificación del proyecto y el plan del proyecto deben seguirse y monitorizarse de
forma continua. Además, el gestor deberá utilizar las herramientas que recojan
métricas que en última instancia proporcionen una indicación de loa calidad del
producto de software. Las herramientas de esta categoría suelen ser extensiones de
herramientas de planificación de proyectos.
· Herramientas de seguimiento de requisitos.
Cuando se desarrollan grandes sistemas, el sistema proporcionado suele no satisfacer
los requisitos especificados por el cliente. El objetivo de las herramientas de
seguimiento de requisitos es proporcionar un enfoque sistemático para el aislamiento
de requisitos, comenzando por la solicitud del cliente de una propuesta o
especificación. Las herramientas de trazado de requisitos típicas combinan una
evaluación de textos por interacción humana, con un sistema de gestión de bases de
datos que almacena y categoriza todos y cada uno de los requisitos del sistema que se
“analizan” a partir de la especificación original.
· Herramientas de métricas y gestión.
Las métricas de software mejoran la capacidad del administrador para controlar y
coordinar el proceso del software y la capacidad del ingeniero para mejorar la calidad
del software que produce. Las métricas y herramientas de medida actuales se centran
en procesos, proyectos y características del producto.
Basándose en características de proyectos y de productos proporcionados por el
usuario, estas herramientas “califican” los valores locales frente a los valores medios
de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar
a mejoras.
· Herramientas de documentación.
Las herramientas de producción de documentos y de autoedición prestan su apoyo a
casi todos los aspectos de la ingeniería del software, y representan una importante
oportunidad de “aprovechamiento” para todos los desarrolladores de software.
144 Organización de Sistemas Informáticos
· Herramientas de control de calidad.
La mayor parte de las herramientas CASE que afirman que tienen como principal
interés el control de calidad son en realidad herramientas métricas que hacen una
auditoría del código fuente para determinar si se ajusta o no a ciertos estándares del
lenguaje.
· Herramientas de gestión de bases de datos.
El software de gestión de bases de datos sirve como fundamento para establecer una
base de datos CASE, que también se denominará base de datos del proyecto.
· Herramientas de gestión de configuración de software.
La gestión de configuración de software (GCS) se encuentra en el núcleo de todos los
entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas
principales de GCS: identificación, control de versiones, control de cambios,
auditoría y contabilidad de estados.
· Herramientas de análisis y diseño.
Las herramientas de análisis y diseño capacitan al ingeniero del software para crear
modelos del sistema que haya que construir. Los modelos contienen una
representación de los datos, de la función y del comportamiento (en el nivel de
análisis), así como caracterizaciones del diseño de datos, arquitectura, procedimientos
e interfaz.
· Herramientas PRO/SIM.
Las herramientas PRO/SIM (de prototipos y simulación) proporcionan al ingeniero
del software la capacidad de predecir el comportamiento de un sistema en tiempo real
antes de llegar a construirlo.
Además, capacitan al ingeniero del software para desarrollar simulaciones del sistema
de tiempo real que permitirán al cliente obtener ideas acerca de su funcionamiento,
comportamiento, y respuesta antes de la verdadera implementación.
· Herramientas de desarrollo y diseño de interfaz.
Las herramientas de desarrollo y diseño de interfaz son en realidad un conjunto de
primitivas de componente de programas tales como menús, botones, estructuras de
ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivo, etc.
Organización de Sistemas Informáticos 145
· Herramientas de generación de prototipos.
Se pueden utilizar toda una gama de herramientas de generación de prototipos. Los
generadores de pantallas permiten al ingeniero de software definir rápidamente la
disposición de la pantalla para aplicaciones interactivas.
Otras herramientas de prototipos CASE más sofisticadas permiten la creación de un
diseño de datos, acoplado con las disposiciones de la pantalla y de los informes
simultáneamente.
· Herramientas de programación.
La categoría de herramientas de programación abarca los compiladores, editores y
depuradores que están disponibles para prestar su apoyo en la mayoría de los
lenguajes de programación convencionales.
Además, los entornos de programación orientados a objetos, los lenguajes de cuarta
generación, los entornos de programación gráfica, los generadores de aplicaciones, y
los lenguajes de consulta de bases de datos residen también en esta categoría.
· Herramientas de análisis estático.
Las herramientas de análisis estático prestan su asistencia al ingeniero de software a
efectos de derivar casos de prueba prácticos.
Las herramientas de comprobación basadas en código admiten un código fuente
como entrada, y efectúan un cierto número de análisis que dan lugar a la generación
de casos de prueba.
Los lenguajes de comprobación especializados capacitan al ingeniero del software
para escribir detalladas especificaciones de comprobación que describirán todos los
casos de prueba y la logística de su ejecución.
Las herramientas de comprobación basadas en requisitos aíslan requisitos específicos
del usuario y sugieren casos de prueba que ejerciten estos requisitos.
· Herramientas de análisis dinámico.
Las herramientas de análisis dinámico interactúan con un programa que se esté
ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del
valor de variables específicas y en general instrumentan el flujo de ejecución del
programa.
146 Organización de Sistemas Informáticos

· Herramientas de comprobación cliente/servidor.
El entorno C/S exige unas herramientas de comprobación especializadas que ejerciten
la interfaz gráfica de usuario y los requisitos de comunicaciones en red para el cliente
y el servidor.
· Herramientas de reingeniería.
Esta categoría puede subdividirse en las funciones siguientes:
· Herramientas de ingeniería inversa para producir especificaciones.
Se toma el código fuente como entrada y se generan modelos gráficos de análisis y
diseño estructurados, listas de utilización y otras informaciones de diseño.
· Herramientas de reestructuración y análisis de código.
Se analiza la sintaxis del programa, se genera una gráfica de control de flujo y se
genera automáticamente un programa estructurado.
· Herramientas de reingeniería para sistemas en línea.
Se utilizan para modificar sistemas de bases de datos en línea (p.e. para convertir
archivos IDMS o DB2 traduciéndolos a un formato de entidades y relaciones).
4. Entornos CASE integrados
Aun cuando se pueden obtener beneficios a partir de herramientas CASE individuales que
abarquen actividades de ingeniería del software por separado, la verdadera potencia de CASE
solamente se puede lograr mediante la integración.
Los beneficios del CASE integrado (I-CASE) incluyen:
- Una transferencia suave de información (modelos, programas, documentos, datos)
entre una herramienta y otra, y entre un paso de ingeniería y el siguiente.
- Una reducción del esfuerzo necesario para efectuar actividades globales tales como
la administración de configuración de software, el control de calidad y la producción
de documentos.
- Un aumento del control del proyecto que se logra mediante una mejor planificación,
monitorización y comunicación.
- Una mejor coordinación entre los miembros del personal que estén trabajando en
grandes proyectos de software.
Organización de Sistemas Informáticos 147
Para definir la integración en el contexto del proceso de software, es necesario establecer un
conjunto de requisitos para I-CASE. Un entorno CASE integrado debería de:
- Proporcionar un mecanismo para compartir la información de ingeniería del software
entre todas las herramientas que estén contenidas en el entorno.
- Hacer posible que un cambio de un elemento de información se siga hasta los demás
elementos de información relacionados.
- Proporcionar un control de versiones y una gestión de configuración general para
toda la información de la ingeniería del software.
- Permitir un acceso directo y no secuencial a cualquiera de las herramientas
contenidas en el entorno.
- Establecer un apoyo automatizado para un contexto de procedimientos para el
trabajo de la ingeniería del software que integra las herramientas y los datos en una
estructura de desglose de trabajo estandarizada.
- Capacitar a los usuarios de cada una de las herramientas para experimentar una
utilización consistente en la interfaz hombre-máquina.
- Permitir la comunicación entre ingenieros del software.
- Recoger métricas tanto de gestión como técnicas que se puedan utilizar para mejorar
el proceso y el producto.
5. La arquitectura de integración
Un equipo de ingeniería del software utiliza herramientas CASE, los métodos
correspondientes y un marco de referencia de proceso con objeto de crear un conjunto de
informaciones de ingeniería del software.
El marco de referencia de integración facilita la transferencia de información desde y hacia
ese conjunto de informaciones. Para lograr esto, deben existir los siguientes componentes de
arquitectura:
- Una base de datos para almacenar la información.
- Un sistema de administración de objetos que gestione los cambios efectuados en
la información.
- Un mecanismos de control de herramientas que coordine la utilización de
herramientas CASE.
- Una interfaz de usuario que proporcione una ruta consistente entre las acciones
efectuadas por el usuario y las herramientas contenidas en el entorno.
148 Organización de Sistemas Informáticos

La mayoría de los modelos del marco de referencia de integración representan a estos
componentes como si fueran capas. Se puede ver en la figura un modelo sencillo del marco de
referencia que representa únicamente los componentes indicados arriba.
Fig. 14-2. Modelo de arquitectura para el marco de referencia de la integración
La capa de interfaz de usuario incorpora un conjunto de herramientas de interfaz
estandarizado, con un protocolo de presentación común.
El kit de herramientas de interfaz contiene software para la gestión de la interacción
hombre-máquina, y una biblioteca de objetos de visualización. Ambos proporcionan
un mecanismo consistente para la comunicación entre la interfaz y las herramientas
CASE individuales.
El protocolo de presentación es el conjunto de líneas generales que proporciona a
todas las herramientas CASE un mismo aspecto. Las convenciones de distribución de
pantalla, los nombres de menú y la organización, los iconos, los nombres de los
objetos, la utilización del teclado y el ratón, y el mecanismo para acceder a las
herramientas se definen todos ellos como parte del protocolo de presentación.
Organización de Sistemas Informáticos
La capa de herramientas contiene un conjunto de servicios de gestión de herramientas con
las herramientas CASE en sí. Los servicios de gestión de herramientas (TMS) controlan el
comportamiento de las herramientas dentro del entorno. Si se emplea multitarea durante la
ejecución de una o más herramientas, TMS efectúa la sincronización y comunicación
multitarea, coordina el flujo de información desde el depósito y sistema de gestión de objetos
a las herramientas, realiza funciones de seguridad y auditoría y recoge métricas acerca de la
utilización de herramientas.
La capa de gestión de objetos (OML) lleva a cabo las funciones de gestión de configuración.
En esencia, el software de esta capa proporciona el mecanismo para la integración de
herramientas. Cada herramienta CASE se “enchufa” en la capa de gestión de objetos.
Funcionando en conjunción con el depósito CASE, la OML proporciona los servicios
de integración, un conjunto de módulos estándar que acoplan las herramientas con el
depósito.
Además, la OML proporciona los servicios de gestión de configuración haciendo
posible la identificación de todos los objetos de configuración, llevando a cabo el
control de versiones, y proporcionando apoyo para el control de cambios, las
auditorías y la contabilidad de estados.
La capa de depósito compartido es la base de datos CASE y las funciones de control de
acceso que hacen posible que la capa de gestión de objetos interactúe con la base de datos. La
integración de datos se logra mediante las capas de gestión de objetos y de depósito
compartido.
6. El depósito CASE
Estamos utilizando un determinado número de términos distintos para hacer alusión al lugar
de almacenamiento de la información de la ingeniería del software: base de datos CASE, base
de datos del proyecto, base de datos de entorno de apoyo de proyecto integrado, diccionario
de datos y depósito. Aún cuando existen sutiles diferencias entre algunos de estos términos,
todos ellos se refieren al centro de acumulación y almacenamiento.
6.1. El papel del depósito en I-CASE
El depósito de un entorno I-CASE es el conjunto de mecanismos y estructuras de datos que
consiguen la integración de datos y herramientas y entre datos y datos. Proporciona las
funciones y herramientas de un sistema de gestión de bases de datos, pero además, el depósito
lleva a cabo las funciones siguientes:
· Integridad de datos:
Incluye funciones para validar las entradas efectuadas en el depósito, para asegurar la
consistencia entre objetos relacionados, y para efectuar automáticamente
149 150 Organización de Sistemas Informáticos
 modificaciones “en cascada” cuando un cambio efectuado en un objeto exige algún
cambio en otros objetos relacionados con él.

· Información compartida:

Proporciona un mecanismo para compartir información entre múltiples

desarrolladores y entre múltiples herramientas, gestiona el control multiusuario a los
datos, y bloquea/desbloquea objetos para que los cambios no se superpongan
inadvertidamente.

· Integración datos-herramientas:

Establece un modelo de datos al que pueden acceder todas las herramientas del
entorno I-CASE, controla el acceso a los datos, y lleva a cabo las funciones de gestión
de configuración adecuadas.

· Integración datos-datos:

El sistema de gestión de bases de datos relaciona los objetos de datos de tal modo que
se puedan llevar a cabo las demás funciones.

· Imposición de la metodología:

El modelo E-R de datos almacenado en el depósito puede implicar un paradigma

específico de ingeniería del software, como mínimo, las relaciones y los objetos
definen un conjunto de pasos que será preciso realizar para construir el contenido del
depósito.

· Estandarización de documentos:

La definición de objetos de la base de datos da lugar directamente a un enfoque

estándar para la creación de documentos de ingeniería del software.

Organización de Sistemas Informáticos 151 152 Organización de Sistemas Informáticos


Capítulo 15
Internet e intranet
1. Un poco de Historia de Internet
La colección mundial de redes, ahora llamada “Internet”, comenzó hace más de 20 años
como un proyecto conjunto entre las fuerzas armadas de los Estados Unidos y algunos de los
principales centros de investigación. Habiendo recibido el encargo de diseñar un medio
“capaz de sobrevivir” a las austeras condiciones impuestas por un ataque nuclear, los
investigadores de la Defense Advanced Research Project Agency (DARPA) y de la
Universidad de California/Berkcley, M.I.T. y otras instituciones desarrollaron un nuevo
conjunto de estándares de comunicaciones. La característica diferenciadora de estos
estándares, conocidos colectivamente como protocolos entrerredes, consistía en permitir a
computadores separados por grandes distancias ponerse en comunicación e intercambiar
información, sin necesidad de confiar en un conjunto determinado de cables. Después de
todo, nunca se sabe qué postes telefónicos van a quedar en pie después de una guerra nuclear.
Así surgió el protocolo TCP/IP, que es el que usa Internet. Con todo esto, montaron una red
denominada ARPANET, que interconectaba centros académicos y de investigación. Pero se
fueron conectando progresivamente redes de otros ámbitos geográficos, hasta alcanzar un
ámbito mundial
2. Cómo funciona Internet
Un ordenador se prepara para enviar un mensaje Internet envolviéndolo en un sobre dirigido
llamado paquete. La localización de todos los computadores en Internet queda expresamente
especificada por medio de una dirección IP, un conjunto de cuatro números separados por
puntos (por ejemplo, 159.74.20.254). Ya que los seres humanos tienden a recordar nombres
mejor que números se puede asignar a las direcciones IP un mnemónico, formalmente un
Fully Qualified Domain Name (FQDN). Por ejemplo, el nombre mcp.com.
Determinados sitios Internet mantienen computadores de referencia pública que listan cada
dirección IP registrada y su nombre de dominio correspondiente. Esta información es
suficiente para direccionar los datos de forma fiable desde un computador a otro.
Una máquina está en Internet si opera con los protocolos de TCP/IP, tiene una dirección IP y
es capaz de enviar paquetes IP a todas las demás máquinas de Internet.
Organización de Sistemas Informáticos 153
3. Aplicaciones en Internet
Tradicionalmente, Internet ha tenido cuatro aplicaciones principales, que son las siguientes:
· Correo electrónico. La capacidad de redactar, enviar y recibir correo electrónico ha
estado disponible desde los primeros días de ARPANET y es enormemente popular.
Mucha gente recibe docenas de mensajes al día y lo considera su forma primaria de
interactuar con el mundo externo, dejando muy atrás al teléfono y al correo ordinario.
En estos días, los programas de correo electrónico están disponibles virtualmente en
todo tipo de ordenadores.
· Noticias. Los grupos de noticias son foros especializados en los que usuarios con un
interés común pueden intercambiar mensajes. Existe miles de grupos de noticias, con
temas técnicos y no técnicos.
· Sesión remota. Mediante el uso de Telnet, Rlogin u otros programas, los usuarios en
cualquier lugar de Internet pueden ingresar en cualquier otra máquina en la que tengan
una cuenta autorizada.
· Transferencia de archivos. Con el programa FTP, es posible copiar archivos de una
máquina en Internet a otra. De esta forma está disponible una vasta cantidad de
artículos, bases de datos y otra información.
Hasta casi finales de la década de los 90, Internet se poblaba en gran medida de
investigadores académicos, del gobierno y de la industria. Una aplicación nueva, la WWW
(world wide web, red mundial) cambió esto y atrajo a millones de nuevos usuarios no
académicos a la red. Esta aplicación no cambió ninguno de los recursos subyacentes pero los
hizo más fáciles de usar. Junto con el visor de Mosaic, la WWW hizo posible que una
localidad estableciera varias páginas de información conteniendo texto, dibujos, sonido y
hasta vídeo con enlaces intercalados a otras páginas. Al accionar el ratón en un enlace, el
usuario se ve transportado de inmediato a la página a la que apunta ese enlace.
4. La World Wide Web
En 1992, Tim Berners-Lee y sus colaboradores estaban buscando una forma de hacer circular
borradores de artículos de investigación para su revisión entre otros investigadores. Las
publicaciones científicas se encuentran entre los documentos más complejos, debido a que
mezclan textos, ecuaciones y figuras detalladas en cada página. El desafío consistía en cómo
mover estos documentos por Internet en un formato que requiriera una mínima amplitud de
banda de red y no necesitara que los destinatarios cargaran software especializado de
procesamiento de textos en sus ordenadores.
Berners-Lee resolvió el problema de intercambio de documentos independiente de
plataformas con tres tecnologías. Definió un lenguaje, HTML, que permite la intercalación
en texto normal de la estructura de documentos, así como los enlaces a otros recursos
Internet. El lenguaje HTML elimina la necesidad de que cada usuario tenga software
154 Organización de Sistemas Informáticos

especializado de tratamiento de textos. Entonces especificó un software de cliente llamado un
navegador, que permite a un usuario navegar y visualizar documentos HTML. Finalmente,
propuso un nuevo protocolo Internet llamado HTTP (HyperText Transport Protocol). El
llamó a la interconexión sin barreras de servidores http y navegadores HTML la World Wide
Web.
Esta tecnología es tan atractiva por la forma como combina las virtudes de Internet con una
sencilla interfaz de usuario basada en documentos.
5. El correo electrónico
El envío de mensajes por un cable es tan antiguo como el telégrafo. Lo único que el correo
electrónico, o e-mail, añade realmente a este paradigma es su eficacia.
Un sistema de correo electrónico permite a las personas en una red enviarse mensajes entre
sí. Si está conectado a Internet y yo supiera su dirección de red, podría enviarle un mensaje
incluso aunque no tuviera idea alguna de su localización geográfica. Otra característica que el
correo electrónico aporta a la comunicación es que no es necesario estar conectado a la red
para recibir un correo. Este es almacenado y enviado cuando el destinatario se conecte a la
red.
6. Dónde comienza intranet
Una intranet es una red interna y autosuficiente que enlaza múltiples usuarios usando la
tecnología Internet. Las intranets ponen un límite alrededor del ilimitado territorio de
Internet, estableciendo sectores de acceso controlado dentro de los que los usuarios pueden
comunicarse e interactuar libremente.
Los ordenadores en una intranet pueden ser visibles o no fuera de ésta. De serlo, sus
nombres y direcciones quedarán inscritos con una DNS pública, en caso contrario, sólo es
necesario que queden registrados en un sistema interno.
La diferencia entre Internet e intranet no es tecnológica. La verdadera diferencia estriba en:
• El nivel de acceso.
• La forma como se utilizan las tecnologías para el establecimiento de
comunicaciones.
• Los objetivos de las partes en comunicación.
Internet tiene un alcance global. Por el contrario el alcance de una intranet está
estrictamente limitado: puede conectar a un grupo de trabajo, un departamento o a toda una
corporación, pero sirve a una comunidad de usuarios bien definida y limitada.
Internet resuelve un número de espinosos problemas de trabajo en red que son relevantes
para las comunicaciones tanto privadas como públicas. Junto con los estándares desarrollados
Organización de Sistemas Informáticos 155
para la World Wide Web, la tecnología Internet resuelve unos requisitos de la informática
empresarial, que estaban pendientes de resolver desde hace mucho tiempo, mediante la
provisión de un medio de distribución de documentos y proceso de formularios
independiente de plataformas.
7. Intranet frente al trabajo en grupo tradicional
El establecimiento de una intranet puede ayudar a proporcionar un acceso fácil a la
información y la comunicación dentro de una organización. Aunque las plataformas
tradicionales de trabajo en grupo ya instaladas también ofrecen estos beneficios, una intranet
expande la capacidad de una organización de acceder a la información y hacerlo utilizando
estándares abiertos y software cliente flexible e intercambiable. Una intranet ofrece una
arquitectura más abierta para construir y personalizar el software y las interfaces y preparar
una mayor compatibilidad futura.
La plataforma tradicional de trabajo en grupo está diseñada para usuarios que estén
trabajando en un área geográfica delimitada, como pueda ser una oficina. Uno de los primeros
usos del trabajo en grupo fue el de usuarios que necesitaban controlar dispositivos, como
impresoras, módems o escáneres compartidos. Hoy en día, los sistemas de trabajo en grupo
heredados son empleados para llevar a cabo una amplia serie de funciones de comunicación e
intercambio de datos y están ofreciendo lentamente su utilidad también a usuarios remotos.
Una intranet, por otro lado, sirve para usuarios que se encuentren diseminados en áreas
geográficas muy diversas y desean controlar información dispersa a lo largo de diferentes
oficinas o domicilios, o incluso en pleno viaje de los empleados. Una intranet puede ser
utilizada incluso para dotar a clientes, proveedores u otros usuarios externos de un acceso
rápido y sencillo a la información apropiada.
El objetivo del trabajo en grupo (groupware) es “permitir a las personas trabajar
conjuntamente mediante la comunicación, la colaboración y la coordinación”. Definido de
esta forma, el software de trabajo en grupo tiene mucho en común con la tecnología web.
Pero posee una serie de diferencias significativas.
7.1. Diferencias principales
Un sistema tradicional de trabajo en grupo requiere que todos los ordenadores de la red
ejecuten, generalmente, el mismo software o una similar. Además, una gran parte de la
aplicación reside en cada PC, para que se puedan intercambiar los datos.
Groupware pone su énfasis en el trabajo en equipo, mientras que las webs consideran a los
usuarios independientes como su audiencia principal.
Los productos software de trabajo en grupo como, por ejemplo, Lotus Notes o Novell
Groupwise, están construidos en base a componentes propios de mensajería y bases de
datos. Las webs están basadas en tecnologías de dominio público como, por ejemplo, SMTP
y HTTP, que son estándares flexibles y abiertos.
156 Organización de Sistemas Informáticos
Los productos actuales de software de trabajo en grupo acostumbran a tener un mayor nivel
de seguridad integral y mejor administración de datos distribuidos que las aplicaciones
basadas en la web.
7.2. Homogeneidad de los PC’s
Con los sistemas de trabajo en grupo, gran parte del trabajo computacional es realizado por el
PC individual. Así, debe existir un grupo de PC’s razonablemente homogéneo en la red.
Deben resultar todos parecidos, ejecutar el mismo software, y comunicarse de la misma
manera.
Los sistemas tradicionales de trabajo en grupo se centran en el PC, lo cual es estupendo si se
dispone de un entorno controlado, como por ejemplo una oficina en la que alguien se
responsabiliza de que tanto el software como el hardware de los PC funcione correctamente.
Sin embargo, cuando los ordenadores de los usuarios se encuentran en sus hogares, o los
usuarios trabajan en múltiples oficinas, esta tarea es a menudo complicada, cuando no
imposible.
Con una intranet, el servidor lleva a cabo casi todas las funciones, y la interfaz del PC es
meramente un terminal. En una intranet, los usuarios de cualquier tipo de plataforma, desde
cualquier lugar, pueden acceder a la información con la ayuda de una interfaz cliente
simple, flexible y que no requiere gran cantidad de recursos del sistema (como el navegador
Netscape).
7.3. Información corporativa estática básica
Para implementar una “biblioteca de red” de publicaciones y documentos internos, una
organización sólo necesita la adquisición de un servidor Web, y un navegador, para todas las
estaciones de trabajo que formen parte de la intranet.
Los administradores de la intranet crean páginas WWW en HTML para el manual del
empleado, las políticas corporativas, o para cualquier otra información estática, y la almacena
en el servidor Web. Ahora la información está disponible en la intranet para todo el mundo y,
en cualquier momento, sin costes de reproducción o almacenamiento.
7.4. Datos corporativos
Algunas grandes empresas utilizan bases de datos distribuidas u otras clases de bases de
datos compartidas sobre una red, como puedan ser listas de precios, listas de proveedores y
datos financieros. Oracle y Sybase fabrican estas grandes bases de datos para redes. Estas
firmas también construyen aplicaciones software para acceder a la información de sus bases
de datos. Sin embargo, cada ordenador de la red debe ejecutar el software de acceso a la base
de datos; y cada cliente software debe hablar con la base de datos exactamente de la misma
manera, usando una arquitectura cerrada.
Organización de Sistemas Informáticos 157
En contraste con una intranet, las bases de datos pueden ser accedidas de cualquier modo.
Es posible comunicarse con un servidor Web, que a su vez podría contactar con la base de
datos, extraer información en cualquier formato y mostrar la información de cualquier manera
que se pida. Mediante este sistema, no sólo es posible acceder a los datos con cualquier tipo
de ordenador, sino que éste puede ser personalizado para manipular la información, por lo
que los usuarios que posean cualquier clase de máquina cliente podrán consultar y actualizar
la base de datos.
Otro inconveniente de este sistema es que la herramienta desarrollada para acceder a la
base de datos sólo sirve para este cometido. Sin embargo, con una intranet, su navegador
Web es útil para consultar información corporativa, buscar datos públicos o, simplemente,
comunicarse.
7.5. Comunicación
Existen muchos medios de comunicación diferentes dentro de un sistema existente de trabajo
en grupo. Uno de los inconvenientes es que se necesitan distintas piezas software para cada
función requerida, por ejemplo, para una videoconferencia. Además, la comunicación básica
con usuarios externos a la red no es una tarea fácil.
Una intranet proporciona un enlace e-mail tanto interno (a nivel de oficina) como externo (a
nivel mundial), poniendo a disposición de los empleados recursos globales. La sociedad
Netscape-Collabra, que combina el navegador Web más popular con un sistema de trabajo
en grupo, es un ejemplo de sistema intranet que proporciona comunicaciones tanto a nivel de
oficina como nivel mundial.
Por ejemplo, si una organización desea proporcionar soporte técnico a los clientes o quisiera
obtener realimentación de los consumidores sobre las últimas innovaciones de sus productos,
podría abrir uno de sus tablones de mensajes a usuarios externos a la red. Con el trabajo en
grupo tradicional esto no es una opción, pero si en una intranet.
7.6. Gestión de documentos
La gestión de documentos presenta cuatro dimensiones esenciales:
• Búsqueda/recuperación. La capacidad de encontrar lo que se está buscando.
• Seguridad. Control del acceso de escritura/lectura a los documentos.
• Control de versión. Mantener un seguimiento de las modificaciones de los
originales.
• Archivo. Conseguir la disponibilidad de datos históricos.
158 Organización de Sistemas Informáticos
Los sistemas de gestión de documentos pueden hacer estas cuatro cosas. Las intranets sólo
la Búsqueda/recuperación. Por otra parte, el establecimiento de un completo sistema de
gestión de documentos podría costar millones, en comparación al bajo precio de una web
interna.

Si no requiere gestión automática de documentos, la elección es sencilla: necesita una

intranet. Si las cuatro funciones son básicas en su organización, la elección es un sistema de
gestión de documentos. Pero entre los dos extremos, la elección es más difícil.

Organización de Sistemas Informáticos 159 160 Organización de Sistemas Informáticos


Capítulo 16
Beneficios de intranet
1. Introducción
Las intranets ofrecen un amplio rango de beneficios que entran dentro de dos grandes
categorías: eficiencia y efectividad. En este contexto, la eficiencia significa la mejora de los
mecanismos de intercambio de información, superando los obstáculos logísticos que existen
para recolectar y diseminar la información necesaria de una manera precisa. La efectividad se
refiere al impacto organizativo del perfeccionamiento de la colaboración y la toma de
decisiones.
1.1. Aumento de la eficiencia
Las mejoras de eficiencia se pueden identificar con facilidad y permitirnos hacer mediciones
cuantitativas. Por ejemplo, muchos patrocinadores de intranet informan sobre ahorros
significativos en gastos extra (tales como correo en horario nocturno, gastos postales o de
llamadas telefónicas de larga distancia). Otros ahorros se derivan de la disminución de la
dependencia de los documentos “impresos”, como puedan ser manuales de empresa,
catálogos de productos o relaciones de materiales de clientes, que se pueden distribuir
electrónicamente en vez de ser impresos y enviados por correo.
Oculto dentro de la ecuación de eficiencia está el ahorro en horas de trabajo personal. Una
intranet a pleno funcionamiento puede reducir drásticamente la factura telefónica,
intercambiando múltiples borradores de documentos, y reduciendo el tiempo empleado en
coordinar la recopilación de información.
La fuerza de ventas de una empresa utiliza su intranet exclusivamente como un medio de
relación con el cliente. Los representantes de ventas pueden acceder a una información on-
line complementaria sobre los productos desde las oficinas de los clientes en vez de acarrear
con un montón de catálogos o folletos.
Una multinacional comercial utiliza su intranet para, entre otras cosas, organizar una
compleja planificación de citas. En cualquier momento dado, la organización estará
preparando simposiums técnicos, encuentros de equipos especiales y conferencias de
negocios; además de sus reuniones plenarias semestrales y anuales, que generalmente atraen a
cientos de participantes de todo el mundo.
Organización de Sistemas Informáticos 161
Cada una de estas reuniones tendrá su propia lista de participantes, agenda, instrucciones,
gestión de locales, consideraciones logísticas y resultados esperados.
1.2. Aumento de la efectividad
Las intranets, virtualmente por definición, estimulan el intercambio de información por
encima de los límites tradicionales, tanto organizativos como geográficos. Si se gestionan
propiamente, tal aumento del intercambio se convierte en trampolín para la colaboración
sustantiva entre sectores de la organización patrocinadora previamente fragmentados. El
uso creativo de una intranet puede acelerar la evolución de una organización desde un modelo
jerárquico, a una estructura más ágil e interdisciplinar, promoviendo la interacción
coordinada.
Una firma internacional de abogados, por ejemplo, emplea su intranet para fortalecer su
práctica ambiental. La intranet permitió que los especialistas en medio ambiente de la firma
intercambiaran (en un entorno seguro) información acerca de casos y de las nuevas
regulaciones y tendencias legales que les afectaban y solicitar el consejo de sus colegas,
rápida y privadamente.
2. Niveles de uso y de impacto
Al evaluar el uso y beneficio potencial de utilizar una intranet, resulta útil considerar tres
grandes niveles de funcionalidad:
· Nivel uno: visualización de información general.
· Nivel dos: compartición de datos del negocio.
· Nivel tres: comunicaciones interactivas.
La inherente flexibilidad de las intranets permite que las organizaciones empiecen por un
nivel relativamente simple e incrementen su capacidad según sus necesidades y a su propio
ritmo. Muchos patrocinadores de intranet utilizan este medio solamente para diseminar
información a través de toda la organización. Sea por propia elección o debido a obstáculos
organizativos, no progresan más allá del nivel uno. Otros patrocinadores más ambiciosos
apuntan hacia la colaboración (nivel tres) desde el principio. Para estas organizaciones, los
niveles uno y dos ofrecen más un medio para alcanzar un fin que un fin en sí mismo.
2.1. Nivel uno: visualización de información general
Desde la comunidad de usuarios más pequeña hasta la multinacional comercial de mayor
tamaño, toda organización genera alguna forma común de información, tanto para sus
propios miembros o constituyentes como para el mundo exterior. Sea formal o informal, esta
información ayuda a mantener la cohesión de la organización, estableciendo una
comprensión general de su misión, metas, recursos, políticas y novedades.
162 Organización de Sistemas Informáticos

A su nivel más básico, una intranet funciona como almacén privado de la información del
patrocinador, accesible para aquellos que la organización reconoce como su capital humano.
Puede tratarse de empleados, voluntarios, miembros asociados, líderes de la comunidad,
clientes, accionistas y cualquier otro grupo involucrado en la organización.
La gran cantidad de información disponible para este público puede adoptar muchas formas,
pudiéndose adaptar casi todas al entorno intranet. El contenido de una intranet puede ser
actualizado instantáneamente y de manera on-line, lo que se traduce en ahorro de dinero y
tiempo.
Por ejemplo, los directorios de empleados, manuales y procedimientos operativos estándar
(que en muchas empresas están sufriendo constantemente un proceso de revisión), pueden ser
publicados en una intranet y leídos sólo por usuarios autorizados. La intranet también puede
ser utilizada para la diseminación de documentos de lectura obligada, registrando el acceso
de los usuarios y evitando el mucho más monótono método de “leer y firmar”, obligado
tradicionalmente por cumplimiento legal.
Muchas empresas utilizan sus intranets para visualizar el rendimiento histórico de los fondos
de pensiones de los empleados o planes de almacenamiento.
Otras organizaciones muestran gráficos de rendimientos de ventas por divisiones o por
regiones, actualizados y comparados mensualmente.
La información sobre los productos es una categoría de contenidos muy popular de las
intranets, cuyos patrocinadores ven este medio como una manera de mejorar el servicio a los
clientes.
Las intranets ofrecen la oportunidad de avisar a los clientes de la existencia de un nuevo
producto rápidamente, así como proporcionar unas especificaciones del producto e
instrucciones de uso fáciles de entender asegurando la consistencia de la información.
2.2. Nivel dos: compartir los datos del negocio
Además de la publicación de información relativamente estática o histórica, como informes
anuales, cada organización mantiene los datos que están cambiando constantemente. Estos
datos pueden cuantificar la producción semestral, las ventas semanales, o el inventario de
productos; también pueden documentar niveles de pertenencia de miembros o contribuciones;
o pueden reflejar cambios en la contabilidad general. Además, muchas organizaciones
generan datos de perspectivas (por ejemplo, en forma de proyecciones de ventas), previsiones
presupuestarias, o informes sobre el progreso de los nuevos proyectos.
En el nivel dos, las intranet pueden ayudar a las organizaciones a gestionar los datos que son
frecuentemente modificados (a menudo datos propietarios) haciéndolos residir en potentes
bases de datos tales como Oracle. Estas bases de datos proporcionan una capacidad máxima
Organización de Sistemas Informáticos 163
para facilitar la realización rápida de cambios de los contenidos de un servidor intranet, a
menudo por medios automatizados.
Por ejemplo, muchos grandes almacenes informáticos con cadenas en muchas ciudades o en
una región utilizan bases de datos compartidas para hacer un seguimiento del inventario y de
las ventas.
El empleo de intranet de nivel de dos estimula el intercambio selectivo de información y la
revisión de trabajos en progreso. Una firma de ingeniería y construcción utiliza un sector de
su intranet como enlace de los directores de los principales proyectos de construcción
esparcidos por el mundo. Ya que muchos de estos proyectos (plantas hidroeléctricas, por
ejemplo) comparten un diseño común y unos requisitos de recursos similares, la capacidad de
intercambiar informes de progreso, especificaciones técnicas, gráficos y cualquier otra
información permite a cada director beneficiarse de la experiencia de otros.
2.3. Nivel tres: comunicaciones interactivas
En su perfil más dinámico, las intranets ofrecen un medio de colaborar en tiempo real,
creando plataformas seguras para las comunicaciones interactivas intraorganizativas.
Una compañía aeroespacial comprometida en un extenso programa de investigación y
desarrollo utiliza su intranet para estimular la cooperación entre los técnicos de diferentes
divisiones. Históricamente, estos especialistas habían trabajado en aislamiento, cada uno
centrándose en un único componente de un prototipo de avión comercial. Con el tiempo, la
alta dirección tuvo que reconocer que este patrón de trabajo creaba barreras a la productividad
y promovía los conflictos entre divisiones y directores de departamentos, en vez de una
competencia saludable. La dirección necesitaba un modo de derribar estas barreras,
estableciendo una visión común y restaurando un sentimiento funcional de metas comunes, en
este caso, la construcción de un nuevo avión.
La intranet de esta empresa proporcionaba los medios para alcanzar este fin. Pero, en primer
lugar, la alta dirección tuvo que aclarar que la empresa hacía negocio cambiando sus
procedimientos, y no sólo daba soporte sino que requería una colaboración tangible entre las
distintas divisiones. Se vio claro que con sólo proporcionar la intranet no era suficiente;
convertirla en vital y dinámica hacía necesario un fuerte trabajo de base por adelantado,
recibiendo informes tanto de los jefes de división como de los expertos técnicos.
La intranet de nivel tres de la empresa está dividida en sectores, cada uno de los cuales
representa un proyecto individual, aunque son fácilmente conectables con el resto. Cada
proyecto tiene asignado un equipo I+D cuyos miembros están dentro de un grupo de usuarios
de intranet definido con acceso a toda la información del proyecto. La reacción inicial de los
usuarios fue cauta y escéptica (los viejos hábitos nunca mueren), y los directores de división
recibieron instrucciones para estimular el uso del servidor organizando reuniones on-line y
publicando la información más actual.
En este caso triunfó la curiosidad técnica, dirigida por los ingenieros de software de la
empresa. Su interés en la tecnología subyacente bajo intranet y sus aplicaciones potenciales
164 Organización de Sistemas Informáticos

les empujaron a explotarla y utilizarla. Cuantos más y más usuarios se integraban en el
sistema, el servidor se hacía muchos más sofisticado, reflejando su uso e ideas. El software
interactivo permite a los usuarios consultar y modificar diseños técnicos, moderar
conferencias en tiempo real y generar simulaciones animadas de diversas características del
avión bajo desarrollo. La alta dirección dio crédito a la intranet no sólo para mejorar la
productividad, sino también para mejorar la capacidad de la empresa de atraer y motivar el
talento técnico final.
Las aplicaciones intranet ayudaron a facilitar la colaboración necesaria para la
simplificación drástica del proceso. La tecnología disponible actualmente permite a los
usuarios de intranet intercambiar, almacenar y modificar información en formato texto,
audio y vídeo. Esto significa que un grupo de usuarios puede revisar, editar y crear un
amplio conjunto de materiales de manera on-line, en vez de los métodos de colaboración
más tradicionales como puedan ser reuniones y conferencias. Además, una intranet posibilita
preservar y archivar las deliberaciones del grupo.
3. Ventajas de intranet
3.1. Acceso a la información
En una empresa, la calidad de las decisiones se traduce directamente en un éxito o en un
fracaso. Incluso en un entorno no comercial, la calidad de las decisiones determina el grado
de eficacia de la organización. Pero sólo se pueden tomar decisiones tan buenas como lo
permite la información con la que cuentan quienes deciden. Los sistemas de información son
valiosos ya que la eficiencia de la organización está en función de la calidad de la
información a la que las personas tienen acceso.
La tecnología de la web interna aporta claras ventajas de acceso a la información. Estas
ventajas se dividen en tres categorías.
1. Una plataforma universal. Las webs proporcionan una plataforma común para
encontrar, recuperar, visualizar y actualizar una variedad de activos informativos,
incluyendo datos numéricos y bases de datos relacionales y documentos
compuestos de texto estructurado, imágenes e incluso objetos multimedia como,
por ejemplo, audio e imágenes en movimiento.
2. Una visión unificada. Las webs ayudan a organizar información presentando
diversos tipos de datos en un estilo estándar. En un navegador web, la gama de
comunicaciones e informes empresariales, artículos, memorándums y tablas
tradicionales adoptan un aspecto y manejo común. Además de soportar una rápida
toma de decisiones, los estándares familiares pueden facilitar el aprendizaje de
nuevas aplicaciones.
3. Un lenguaje común. La tecnología web se construye sobre estándares flexibles y
de aceptación universal. En consecuencia las intranets pueden acceder a
Organización de Sistemas Informáticos 165
información residente en sistemas ya existentes sin necesidad de costosas labores
de programación.
3.1.1. Las webs unen datos y documentos
Tradicionalmente, el software informático ha lidiado con la diversidad de información
mediante la utilización de una estrategia del tipo divide y vencerás. El texto normal se
manipula mediante un programa, como por ejemplo Windows Notepad. Otro programa,
maneja el texto muy formateado, como Microsoft Word. Los gráficos son diferentes y se
visualizan mejor utilizando un programa distinto, editado con otro y catalogado, tal vez como
imágenes en miniatura, con un tercer programa. Los datos orientados a registros son pasto del
software de gestión de base de datos. Y así se organiza todo los demás.
El problema de este enfoque es que fragmenta los datos de una organización de forma poco
natural. Para resolverlo surge la informática centrada en documentos. Estos son los
familiares espacios de trabajo que contienen texto e imágenes con los que tratamos
habitualmente. En lugar de forzarnos a utilizar un conjunto de programas aislados para
visualizar datos relacionados, pero con formatos muy diversos, el paradigma documental
muestra esta información en la misma forma como estamos acostumbrados a verla: dispuesta
en una página.
La tecnología web aporta dos cosas a la informática centrada en documentos. Primero,
consagra a los documentos HTML como el estándar universal a través del cual se accede a
toda la información. Mediante un navegador web se pueden presentar datos procedentes de
fuentes variadas, manteniendo al mismo tiempo un aspecto y manejo bastante coherentes de
una plataforma a otra. Segundo, la tecnología web es independiente de plataformas. Las
páginas presentan un aspecto y comportamiento muy similares, independientemente del
hardware y sistema operativo subyacentes.
3.1.2. Sistemas con aspecto y funcionamiento comunes
Hay muchos factores que determinan la utilidad del software. Uno de los más importantes es
la coherencia en el modo de operar a lo largo de todo el producto o, mejor aún, a lo largo de
una familia de productos.
¿Qué determina la “consistencia en el modo de operar”? Dos cosas: el aspecto de una
aplicación y su comportamiento.
Es más fácil formar a los usuarios en el uso de un nuevo programa de aspecto y
comportamiento parecidos a uno que ya conozcan que en el de un programa con una
presentación totalmente diferente. La colocación coherente de controles y mensajes dentro de
programas es también importante para ayudar a los usuarios a permanecer orientados cuando
cambien de tarea.
La tecnología web impone un aspecto y manejo coherente en la información. Hay tan sólo
unos cuantos elementos básicos de diseño en HTML. Las cabeceras, listas, tablas y formatos
166 Organización de Sistemas Informáticos
tienen un aspecto muy similar en la web, al margen del navegador utilizado para
visualizarlos.
3.2. Procesos empresariales
El uso de la información para la toma de decisiones constituye una faceta esencial del
rendimiento de las organizaciones. Pero, una vez se adopta una decisión, el nivel de
rendimiento depende de la acción. La tecnología intranet también ofrece ventajas a este
respecto.
El trabajo del día a día de cualquier organización consiste en un conjunto de actividades
estándares, cuestiones como la planificación, marketing, emisión de informes, facturación,
etc. Un proceso empresarial describe las rutinas utilizadas por una organización para
desempeñar dichas actividades. La sustitución de algunos o todos los pasos manuales en un
proceso empresarial con transferencias electrónicas recibe a menudo el nombre de
automatización del flujo de trabajo.
La tecnología intranet es extremadamente eficaz como un medio de reunir información de los
usuarios de la web y de aportar información a estos mismos usuarios.
Una intranet puede aumentar o sustituir flujos de trabajo al mismo tiempo que genera una
pista de auditoría.
La capacidad de creación de formularios se añadió al estándar HTML a partir de la versión
2.0. Los formularios elevan la tecnología intranet desde una distribución estática de datos a
una automatización interactiva.
Los formularios HTML hacen posible que las páginas web actúen como puerta de acceso a
sofisticadas aplicaciones. Las aplicaciones de consulta de base de datos, por ejemplo,
pueden construirse rápidamente utilizando sólo HTML, secuencias de software gratuito para
proceso de formularios, software gratuito de conexión para SQL, y una secuencia que
formatea el resultado en forma de tabla HTML.
Hay una ventaja que se obtiene gratis cuando las personas utilizan una intranet: su actividad
puede quedar registrada por el servidor web, asegurando así el establecimiento de una pista
de auditoría.
4. Los costes de intranet
Una intranet es un inversión en tecnología de la información (IT). Al igual que cualquier
inversión en IT, incurre en costes en cada punto de su ciclo de vida. Los desembolsos
relativos a su adquisición, instalación, uso y mantenimiento se cargan a la inversión a partir
del momento en que alguien propone la idea de instituir una intranet. El coste añadido que
supone el sistema sólo compensará si los beneficios que genera su empleo superan la suma de
estos costes.
Organización de Sistemas Informáticos 167
4.1. El coste de mantener el contenido de intranet
El posicionamiento de contenido en una web, tanto si es nueva o reciclada en base a
documentos heredados, incurre en los tipos de costes siguientes:
• Conversión: Los costes de conversión son aquellos asociados con las
herramientas, mano de obra y estándares requeridos para convertir los formatos
ya existentes a HTML.
• Coordinación: Otro coste es la necesidad de coordinar proveedores de contenido
en departamentos de forma que sus contribuciones “se ajusten” a los estándares
de aspecto y uso de la intranet.
• Indexación: Finalmente, es necesario indexar periódicamente las páginas web a
fin de permitir a las personas encontrar agujas de valor en el pajar de la
información.
4.2. Coste de mantenimiento de software intranet
El mantenimiento de una intranet cuesta dinero tanto si los usuarios la utilizan para
intercambiar datos como si no. Estos desembolsos son los costes de infraestructura. Es de
esperar que el mantenimiento de una intranet afecte a su presupuesto en cuatro partidas
diferentes:
· En el servidor
· En la unidad de sobremesa (el navegador)
· En el software de aplicaciones
· En la red
4.3. La seguridad
Un documento confidencial residente en disco en el servidor requiere protección contra el
robo físico, la corrupción o el borrado, contra un fallo de disco o el acceso no autorizado.
Las personas acostumbradas a navegar por la WWW pueden llegar a considerar las autopistas
de la información como propiedad pública y además, de pleno derecho, libre de honorarios de
paso. Una intranet es diferente. El hecho de que su propósito consista en proporcionar acceso
libre a información corporativa no significa que cualquiera pueda acceder a cualquier cosa
en cualquier momento.
Puede que resulte necesario proteger de miradas extrañas información sensible que viaje
por la red como, por ejemplo, registros legales o secretos comerciales, incluso dentro de la
misma organización. La tecnología básica para hacerlo es la encriptación.
168 Organización de Sistemas Informáticos
La encriptación funciona transcribiendo el texto de un mensaje con una clave que no es otra
cosa que un número muy largo.

Los servidores seguros web como Netscape Commerce Server utilizan tecnología de claves
públicas para prestar servicios de encriptación, autentificación y firma digital. En un
sistema de clave pública cada persona tiene un par exclusivo de claves. Una de ellas se
denomina la clave pública y se distribuye libremente a cualquier persona que desee una copia.
La otra, llamada la clave privada, se mantiene en secreto.

Bajo este sistema, una persona que necesite enviar un mensaje a un destinatario cifra el
mensaje con la clave pública del recipiente. Una vez cifrado, el mensaje sólo podrá ser leído
descifrándolo con la clave privada del destinatario. Es esta forma, cualquiera puede enviar un
mensaje seguro, pero sólo su destinatario podrá leerlo.

Organización de Sistemas Informáticos 169 170 Organización de Sistemas Informáticos


Capítulo 17
Intranets en acción
1. El contenido es la clave
Cualquier intranet de éxito proporciona un contenido (información) al que los usuarios dan
valor. Por supuesto, la naturaleza de este contenido varía considerablemente, dependiendo de
los grupos individuales de usuarios y sus prioridades. Sin embargo, se aplican unos cuantos
principios básicos a cualquier consideración sobre contenido, y los patrocinadores y usuarios
de intranet deben estar de acuerdo en que la información del servidor incluya características
como las siguientes:
• Relevancia: este concepto lo ve el usuario, no el patrocinador.
• Oportunidad: los “atascos de tráfico” en las intranet desaniman a los usuarios;
éstos vuelven rápidamente a los medios de comunicación convencionales cuando
sus tablones de mensajes y su correo electrónico son lentos y poco fiables.
• Actualizaciones frecuentes: muchos servidores web, públicos y privados,
adolecen de contenidos estáticos, por lo que su interés y su utilización decaen
rápidamente. Las intranets ofrecen capacidad que debería ser explotada
completamente por medio de la automatización y otras funcionalidades.
• Accesibilidad: el mejor servidor del mundo es de escaso valor si los usuarios no
pueden llegar a él rápida y fácilmente. El cometido de la intranet es hacer
disponible la información y el diseño del servidor debe aprovechar los motores de
búsqueda y otras funcionalidades que mejoren el acceso de los usuarios.
Al considerar las cuestiones de contenido, es importante tener en mente que las intranets
están dirigidas únicamente al usuario y que las necesidades y preferencias del mismo deben
ser factorizadas en el diseño e ingeniería iniciales del servidor.
2. ¿Es intranet la respuesta?
La clave determinante del valor de intranet reside en las necesidades de información de su
organización. Como regla muy general, las intranet son las más útiles para las organizaciones
que:
Organización de Sistemas Informáticos 171
· Tienen gran dispersión geográfica.
· Comparten objetivos comerciales comunes.
· Tienen necesidades de información comunes.
· Se benefician de la colaboración.
Para que una intranet sea verdaderamente útil, debe reflejar un núcleo central, lo más
frecuente es un negocio común u objetivo organizativo, compartido por diversos individuos o
grupos.
Es importante tener en cuenta que no todas las organizaciones necesitan una intranet. Por
ejemplo, una pequeña empresa, que opere desde un único emplazamiento, puede intercambiar
información de forma más apropiada a través de memorias, reuniones o en la máquina de
café. Una organización de este tipo bien puede usar Internet como recurso para la recolección
de información, pero probablemente no necesite añadir el poder y eficacia de una intranet.
En contraste, una empresa que dispone de múltiples oficinas de venta o divisiones operativas
en emplazamientos diferentes, o una asociación comercial o grupo sin afán de lucro que
tienen numerosos miembros, pueden beneficiarse significativamente implementando su
propia intranet. Las organizaciones de este tipo luchan constantemente para compensar las
necesidades de información concisa y oportuna de sus directivos; están sobrecargadas por
desafíos logísticos que surgen de múltiples zonas horarias, sistemas informáticos
incompatibles y de un errático servicio telefónico local.
Como resultado de estas y otras barreras, es posible que las decisiones críticas no se
beneficien de una colaboración total entre los participantes claves, o de una información
concisa del entorno, disponible de forma equivalente para todos los que participan en la toma
de decisiones. Pueden existir graves inconsistencias entre oficinas en términos de su
capacidad para diseminar información entre los miembros del personal.
A su máximo rendimiento, las intranets ayudan a crear y profundizar una visión común entre
componentes dispares de la organización potenciando lo individual. Para muchas
corporaciones, este concepto es, en si mismo, revolucionario: alcanzar una influencia común
distribuyendo (no centralizando) el poder.
3. Descubrir las necesidades
Las intranets están, por definición, dirigidas al usuario, y su diseño debe reflejar las
necesidades del usuario. Así mismo, una buena manera de comenzar es identificar esas
necesidades dentro de la organización que espera que intranet le ayude a satisfacer.
La organización patrocinadora debe hacerse a sí misma algunas preguntas muy básicas antes
de embarcarse en un proyecto de esta clase:
172 Organización de Sistemas Informáticos
 · ¿Qué es lo que se quiere conseguir?
· ¿Qué es lo que queremos que la intranet satisfaga?
· ¿Cómo esperamos cumplir nuestras metas? Esta pregunta ayuda a establecer un
marco de trabajo para la planificación del proyecto, incluyendo la asignación de
responsabilidades, especificaciones técnicas, requerimientos de recursos, un
calendario y patrones de personal.
· ¿Cuánto costará? Una descripción real de los costes de intranet debería incluir
estimaciones del desembolso a corto plazo como del ahorro esperado a largo plazo.
· ¿Cómo monitorizaremos los progresos?
· ¿Cómo determinaremos el grado de éxito? Como con cualquier otro tipo de
iniciativa, la eficacia de intranet se determina de forma definitiva por medio del
análisis coste/beneficio.
· ¿Quiénes son a priori los posibles usuarios de la intranet? El universo de
usuarios potenciales puede ser tan amplio o tan restringido como necesite la
organización.
· ¿Cómo esperamos que use la intranet la audiencia objetivo? Para cada grupo de
usuarios, la organización debe definir utilidades y beneficios específicos para
asegurar que el diseño del servidor satisfaga las necesidades y expectativas de cada
grupo.
· ¿Qué necesita la audiencia para utilizarla? Evaluar qué es lo que ya existe en
términos de capacidad de computación, conectividad y experiencia.
4. Metas de una intranet
Estructura: la comprensión de la estructura de la organización ayuda a determinar la utilidad
de la intranet en general, así como qué funciones específicas pueden resultar más valiosas.
1. ¿Posee la organización múltiples oficinas en diferentes emplazamientos?
2. ¿Existen diversas funciones de personal (tales como I+D, ventas, recursos humanos,
asesoría jurídica, ingeniería) residentes en más de un sitio?
3. ¿Se trata de una organización esencialmente jerárquica? ¿Es distribuida? ¿Es
centralizada? ¿Es descentralizada?
Comunicaciones internas / intercambio de información: la comprensión de cómo la
organización intercambia rutinariamente la información interna ayuda a revelar los huecos y
barreras que una intranet puede solventar.
Organización de Sistemas Informáticos 173
1. ¿Cuáles son las fuentes primarias de información, dentro y fuera de la organización?
2. ¿Cuál es la forma habitual de entregar la información comercial? (por correo
electrónico, entrega especial, teléfono, reuniones o cualquier otro medio)
3. ¿Cómo se toman generalmente las decisiones?
4. ¿Cómo se dirige y comparte la investigación?
Comunicaciones externas: la comprensión de cómo interactúa la organización con sus
componentes primarios ayuda a sugerir oportunidades de uso de la intranet para un mejor
cumplimiento de sus necesidades.
1. ¿Existen grupos de usuarios externos a la organización (como puedan ser clientes,
accionistas, voluntarios) con los que se interactúa de forma rutinaria?
2. ¿Cómo les mantiene informados la organización?
3. ¿Qué información necesitan?
4. ¿Cómo recibe y procesa la organización la información que proviene de estos
grupos?
Barreras: una revisión objetiva de las barreras que impiden una comunicación eficaz ayuda a
identificar las debilidades de la organización y a asignar prioridades para el desarrollo de
intranet.
1. ¿Cuáles son los obstáculos primarios que se encuentra el intercambio eficaz de
información?
2. ¿Se tratan de barreras mecánicas? ¿Logísticas? ¿Culturales?
3. ¿Cuál es el impacto de estas barreras?
Recursos: la evaluación de los recursos disponibles ayuda a establecer un punto de partida
realista para el diseño e implementación de una intranet.
1. ¿Cuál es el nivel actual de informatización de la organización?
2. ¿Qué recursos (personal y contratista) se requieren para construir y gestionar la
intranet?
3. ¿Qué recursos (financieros, técnicos, etc.) están actualmente disponibles?
174 Organización de Sistemas Informáticos
 Cuando determine el ámbito de su primera intranet, incluya el grupo más pequeño que pueda
5. Comenzando con intranet beneficiarse de la nueva web y céntrese en satisfacer los requisitos de dicho grupo.

Un proyecto intranet de éxito necesita:
· El beneplácito de la alta dirección
· Un director de proyecto nombrado con un mandato explícito.
· Las herramientas y el dinero necesarios para realizar el trabajo.
Cuando llegue el momento de crecer, amplíe las webs internas alrededor de grupos de
trabajo o centros departamentales de valor.
Implique en el mayor grado posible a los usuarios desde un principio en la experiencia
intranet, a partir de su planificación conceptual.

Además, en cuanto el liderazgo y la contabilidad estén claros, un proyecto de esta clase se Divida los costes en dos categorías: costes iniciales y no repetitivos como, por ejemplo,
beneficia enormemente de una aproximación de equipo multidisciplinar, lo que ayuda a compras de hardware, y costes recurrentes como, por ejemplo, el correspondiente a los
asegurar que la organización como un todo recoja el máximo beneficio de su inversión. contratos de mantenimiento del software.

Construir un equipo de proyecto que comprenda a un amplio rango de usuarios potenciales de Divida los objetivos relativos a beneficios en dos categorías: reducción de los costes de
la organización para que los ingenieros software dispongan de los beneficios de las gestión de la empresa y una mayor capacidad de generación de ingresos.
necesidades de los usuarios mientras desarrollan las especificaciones de la intranet.

La consecución de las ventajas de una intranet depende de su personal, estilo de gestión y

base tecnológica ya existente.

1. Para que las personas puedan beneficiarse al máximo de una intranet es necesario que
compartan objetivos empresariales claves. Esto, más la confianza necesaria para
permitir el flujo de información (en lugar de reservársela), es el componente esencial
al tipo de trabajo distribuido que las intranets hacen posible.

2. Los gestores pueden contribuir al éxito de la intranet coordinando recursos sin

impedir un intercambio libre de ideas.

3. Para preparar su entorno actual de software para la tecnología web, asigne

desarrolladores que aporten su propia disciplina a la codificación, ya que todavía no
existen métodos formales para intranets. La centralización de pruebas y del
establecimiento de estándares le ayudará a tratar con la dudosa ventaja de contar con
versiones 1.0 de software.

4. Puede sobreponerse la tecnología intranet en la mayoría de las redes privadas de

trabajo. Es posible que su personal de red tuviera que aprender la gestión de
direcciones TCP/IP, pero su experiencia favorecerá el óptimo despliegue de las webs
internas.

6. Planificación de intranet
El coste de la operación y el mantenimiento de una red informática crece exponencialmente
con el número de usuarios conectados, mientras que el valor de la red aumenta con mayor
lentitud. Las intranets no constituyen una excepción.

Organización de Sistemas Informáticos 175 176 Organización de Sistemas Informáticos

 APÉNDICES

Organización de Sistemas Informáticos 177 178 Organización de Sistemas Informáticos

 La metodología SSA utiliza estas herramientas para construir una especificación estructurada.
SSA propone un procedimiento de trabajo y un ciclo de vida:

Apéndice I
Análisis Estructurado de Sistemas

1. Conceptos básicos.
El análisis estructurado de sistemas (Structured System Analysis) es un método clásico de
especificación de los requerimientos del software, propuesto en la segunda mitad de los años
70. Se verá la versión de DeMarco.

Junto al diseño estructurado de sistemas (Structured System Design) constituye toda una Fig. I-1. Ciclo de vida del Software en SSA
metodología de desarrollo de software, que también contempla labores de Ingeniería de
Sistemas.

El método SSA pretende alcanzar los siguientes objetivos:

- Disponer de un modelo lógico (independiente de la implementación) del sistema,

inteligible para el usuario, y gráfico en la medida de los posible, antes de proceder a
implementarlo.

- Emplear un método efectivo de descomposición funcional durante el análisis.

- Dar cuenta de las características tanto lógicas como físicas de los sistemas,
distinguiéndolas adecuadamente.

- Obtener un documento de especificación modificable, que pueda cambiarse o

mantenerse.

Para ello hace uso de una serie de herramientas: Fig. I-2. Estructura de la fase de Análisis

- Diagrama de flujo de datos (DFD)

- Diccionario de datos (DD)

- Otras: lenguaje natural estructurado, tablas de decisión, especificación algebraica, ...

En el documento de especificación deben figurar DFDs, DD y las especificaciones de las

primitivas funcionales.

Organización de Sistemas Informáticos 179 180 Organización de Sistemas Informáticos


2. Diagramas de Flujo de Datos.
Un Diagrama de Flujo de Datos es una representación en forma de red que refleja el flujo de
la información y las transformaciones que se aplican sobre ella al moverse desde la entrada
hasta la salida del sistema.
Se utiliza para modelar las funciones del sistema y los datos que fluyen entre ellas a
distintos niveles de abstracción. Por tanto, el sistema se modela mediante un conjunto de
DFD nivelados, donde los niveles superiores definen las funciones del sistema de forma
general, y los niveles inferiores lo hacen de manera más detallada.
Los componentes de un DFD son los siguientes:
- Procesos: son los componentes funcionales del sistema.
- Almacenes: representan datos almacenados o en reposo.
- Entidades externas: representan la fuente y/o el destino de la información que fluye
por el sistema.
- Flujos de datos: representan los datos que fluyen entre las funciones.
Y su representación:
Proceso Entidad Externa
Nbre.
Proceso Nombre entidad
Almacén Flujo de datos
Nombre flujo
Nombre del
fichero
Fig. I-3. Representación de elementos en un DFD
2.1. Pasos para realizar Diagramas de Flujo de Datos.
1. Identificar los flujos de entrada y salida. Dibujarlos en la periferia del diagrama.
2. Intentar conectar las entradas con las salidas, y las salidas con las entradas,
dejándose guiar por la información procedente del usuario, intentando reflejar el flujo
de información tal como es más que preguntarse porqué es así. Iremos:
- Reflejando los flujos de información que aparezcan en el sistema.
- Situando procesos (sin darles nombre en un principio) donde sea necesario
procesar información para conectar unos flujos con otros.
- Introduciendo los almacenes de información que existan en el sistema.
Organización de Sistemas Informáticos
3. Seguir el camino de la información, de las entradas a las salida, de las salidas a
las entradas, y del centro a la periferia.
* Examinando los flujos y su contenido, preguntándonos:
- Qué necesito para elaborar este contenido.
- De dónde proceden sus componentes.
- ¿Puedo elaborar (con un proceso) la información de algún otro flujo para
obtener la de este?
* Examinando los procesos (sin nombre aún), preguntándonos:
- Si es necesaria la información de algún otro flujo para obtener las salidas del
proceso a partir de las entradas.
- Podremos ir dando nombre, en términos de sus entradas y salidas, a los
procesos.
Estos recorridos nos llevarán a modificar el diagrama convenientemente.
4. Nombrar con cuidado todos los flujos:
- Sobre todo los flujos de datos de la interface.
- Dar a los flujos nombres significativos, que reflejen su contenido en
información, y si es relevante, el estado de la misma. Por ejemplo,
numero_de_cuenta refleja el contenido de información, pero
numero_de_cuenta_validado no solo refleja el contenido, sino una
información relevante.
- El estilo de denominación a base de frases con palabras delimitadas es más
conveniente que el uso de abreviaturas.
- A veces, en ficheros simples, sólo existe un flujo de entrada y/u otro de
salida, con el mismo contenido que los items del fichero. En este caso basta
con dar nombre al fichero, sin nombrar los dos flujos, a los que se les supone
el mismo nombre.
5. Ignorar la inicialización y la terminación. Basta con que los DFD reflejen el
comportamiento de los sistemas cuando están en un régimen estacionario.
6. Omitir los detalles de los caminos de error triviales (por ahora).
7. No incluir flujos de control o información de control.
8. Comenzar de nuevo. Puede ser que:
- Exista algún flujo de entrada desconectado del resto del diagrama (lo
eliminamos sin más).
- Exista alguna zona en el centro del diagrama desconectada del resto del
mismo (si no es una zona de interés la eliminaríamos)
181 182 Organización de Sistemas Informáticos

3. Componentes de los DFD
3.1. Procesos.
Este componente representa una función que transforma los flujos de datos de entrada en
uno o varios flujos de datos de salida. El término proceso a veces puede dar lugar a
confusión, puesto que no hay que considerarlo como un programa en ejecución, sino como
una función que tiene que realizar el sistema.
El proceso debe ser capaz de generar los flujos de datos de salida a partir de los flujos de
datos de entrada más una información (constante o variable) del proceso, lo que se conoce
como "la regla de conservación de los datos". Cuando al proceso no le llegan todos los datos
necesarios para obtener datos de salida diremos que hay un error de conservación de datos.
Esto implica que por lo menos se ha olvidado incluir ciertos datos de entrada. También puede
ocurrir el caso contrario, que sería aquel en el que el flujo de datos o algún componente suyo
"muere" dentro del proceso, es decir, no se utiliza para generar flujo de salida, lo que se
denomina "pérdida de información".
Los procesos deben ir numerados y nominados, debiendo cumplir las siguientes
características:
* Ser lo más representativo posible de la función que especifica. Siendo un nombre
que englobe a toda la función y no sólo a parte de ella.
* Ser breve, normalmente está formado por un verbo seguido de un sustantivo, como
por ejemplo: Analizar paquete.
* El nombre y número del proceso deben ser únicos en el conjunto de los DFD que
representan el sistema.
Cuando se realizan los DFD lógicos, los procesos deben estar desligados de cualquier
connotación física, como por ejemplo: lugar donde se realiza el proceso, personas o
dispositivos que realizan el proceso, etc. Cuando se realizan los DFD físicos se pueden
incluir este tipo de connotaciones.
3.2. Almacenes de datos.
Representan información del sistema almacenada de forma temporal, representando datos
que se encuentran "en reposo". Se trata de dispositivos lógicos de almacenamiento y, por
tanto, pueden representar a cualquier dato temporalmente almacenado, independientemente
del dispositivo utilizado. Por ello, pueden representar a un cajón con papeles, un archivador
manual, un fichero o una base de datos.
Organización de Sistemas Informáticos 183
3.3. Entidades externas.
Representan un generador o consumidor de información del sistema y que no pertenece al
mismo. Puede representar un subsistema, una persona, departamento, organización, etc, que
proporcione datos al sistema o que los reciba de él.
3.4. Flujos de datos.
Se pueden definir como "un camino a través del cual viajan datos de composición conocida
de una parte del sistema a otra".
Se representan por arcos dirigidos, en donde se indica la dirección del flujo.
La conexión directa entre dos procesos mediante un flujo de datos es posible siempre y
cuando la información sea síncrona, es decir, que el proceso destino comience en el momento
en el que el proceso origen finaliza su función. Si no ocurre, es necesario que exista un
almacén temporal que guarde los datos del proceso origen, y el proceso destino capturará
estos datos cuando los necesite.
4. Desarrollo de niveles de abstracción en los DFD.
Para representar un modelo de un sistema grande es conveniente hacerlo por capas,
realizando una aproximación descendente (top-down) en el que cada nivel proporciona una
aproximación más detallada de una parte definida en el nivel anterior.
Un conjunto de DFD queda definido por:
* Un diagrama de contexto, que es único y está en la parte superior de la jerarquía.
También se le conoce como diagrama de nivel 0. El objetivo de este diagrama es
delimitar la frontera del sistema con el mundo exterior y definir sus interfaces, es
decir, los flujos de datos de entrada y salida del sistema con el entorno o, lo que es lo
mismo, el contexto.
* Diagramas de niveles, en los que se representan las funciones principales que debe
realizar el sistema, así como las relaciones entre ellas. Es interesante que las funciones
de estos diagramas sean conceptualmente independientes entre sí, lo que facilita la
descomposición de cada una de ellas por analistas diferentes para construir los
diagramas de niveles medios.
* Procesos primitivos, son aquellos procesos de un DFD que ya no se descomponen
en más diagramas de nivel inferior. Es importante recalcar que para cada proceso
primitivo habrá una especificación que la describa.
184 Organización de Sistemas Informáticos
Es necesario comprobar la consistencia entre los distintos niveles del DFD, es decir, que la
5. Verificación y Validación de los DFD
información que entra y sale de un proceso representado en un DFD de nivel N, sea
Aspectos a verificar:
consistente con la información que entra y sale del DFD en el que se descompone.
* Denominaciones:
Un fichero sólo puede aparecer en un diagrama. Podemos plantearnos en qué nivel debe
aparecer el fichero, la solución consiste en ponerlo en el primer nivel en que interaccione con
- Que todos los flujos tengan un nombre asignado.
más de un proceso.
- Que todos los flujos tengan un contenido conocido.
- Que los nombres de los procesos hagan referencia a sus entradas y salidas, y
No debe indicarse, sobre los diagramas, la procedencia o destino de los flujos exteriores. Esto
guarden relación con el contenido de los subdiagramas que dependan de ellos.
puede averiguarse mirando en el correspondiente diagrama de nivel superior.
* Consistencia:
La numeración de los DFD se realiza de la forma siguiente:
- Balanceo de flujos.
* Cada diagrama recibe el número y nombre del proceso del que proviene (proceso
- Que un mismo proceso no aparezca más de una vez.
padre).
- Que cada proceso pueda elaborar los flujos de salida contando sólo con la
* El diagrama de contexto se numera como 0.
información de los flujos de entrada (conservación de los datos)
* Los diagramas de nivel 1, se numeran desde 1 hasta el N. En los restantes niveles los
números de los procesos están formados por la concatenación del número del
* Ficheros:
diagrama en el que están, más un punto, más un número entero único para
identificarlo dentro del diagrama.
- Que no aparezcan ficheros que sólo reciben información (sumideros).
Recomendaciones:
* Legibilidad:
- En los diagramas, el número de procesos no debe ser ni muy bajo, lo que multiplicaría el
- Que las interfaces sean sencillas.
número de diagramas, ni muy alto (un número mayor de siete comienza a ser problemático).
- Que los nombres de los procesos sean significativos (p.e. Procesar_salida no
lo es)
- Las interfaces, como consecuencia de una división en subdiagramas apropiada, no deben
- Que la descomposición funcional sea uniforme (que la jerarquía de
ser muy complejas, y deben guardar una cierta relación con el problema.
diagramas esté equilibrada).
- Los diagramas deben ser legibles.

- Cuando los procesos que contenga un diagrama se puedan describir con facilidad, es el
momento de dejar de descomponer el diagrama. (Hay quién entiende que esto requiere que
sólo se presente un flujo de entrada y otro de salida).
- No es necesario marcar de ninguna forma especial los diagramas terminales.
6. Diccionario de Datos.
El diccionario de datos se puede definir como: "una lista organizada de los datos utilizados
por el sistema y que gráficamente se encuentran presentes en los flujos de datos, entidades
externas y los almacenes del conjunto de DFD"

- Por último, decir que en la realización de los DFD hay que tratar de evitar una partición
desigual, siendo la partición o descomposición ideal aquella que genera partes de igual
tamaño.
El DD se crea a la vez que los DFD durante el análisis del sistema. Las entradas son
realizadas cada vez que se identifica un elemento, pudiendo ser de cuatro tipos: flujo de dato,
almacén, dato elemental y entidades externas, debiendo ser únicas para cada componente
del DFD. (Muchos autores incluyen en el DD la especificación de Procesos, pero para la
realización de las prácticas no las incluiremos en el mismo.)

Organización de Sistemas Informáticos 185 186 Organización de Sistemas Informáticos

La definición de los flujos de datos sigue una aproximación top-down, es decir, los
7. Descripción de Procesos
componentes son definidos a su vez mediante componentes más detallados, y se procede de
Como vimos en la descripción de los elementos del DD, cualquier herramienta de
esta forma hasta obtener partes indivisibles, es decir datos elementales.
especificación puede ser válida para describir los procesos: expresiones regulares, lenguaje
natural estructurado, notaciones de estados, tablas de decisión, especificación algebraica, etc.
Un flujo de datos se puede definir teóricamente mediante la inclusión, selección e iteración
de sus componentes, además de incluir otros símbolos que aportan más significado a cada
Recomendaciones:
entrada en el DD. Cualquier herramienta de especificación puede ser válida para describir
los items del diccionario: expresiones regulares, lenguaje natural estructurado, notaciones de
- Incluir una entrada Nivel.Proceso (como se ha visto en la Numeración de DFD), para
estados, tablas de decisión, especificación algebraica, etc.
referenciar su posición en el diagrama.
- No indicar los flujos de entrada y de salida
Las definiciones en el DD, irán ordenadas alfabéticamente. Se recomienda que
- Una buena descripción del proceso podría hacerse utilizando el lenguaje natural
cada componente incluya:
estructurado, pero pueden usarse otras herramientas, como ya hemos visto.
- Flujos de datos:
- Nombre del flujo.
- Sinónimos. 8. El proceso de obtención de modelos.
- Composición en BNF.
- Notas o comentarios. La metodología SSA propone un proceso de obtención de modelos sucesivos, en los que
aparecen los aspectos lógicos y físicos del sistema. Proporciona además procedimientos de
- Datos elementales: análisis y diseño a nivel de sistema, así como de los requerimientos del software.
- Nombre.
- Sinónimos. SSA propone la obtención de 4 modelos del sistema:
- Valores de los datos y su significado. - Modelo físico actual
- Notas. - Modelo lógico actual
- Modelo lógico nuevo
- Ficheros: - Modelo físico nuevo
- Nombre.
- Sinónimos. Podemos definir aspectos físicos aquellos que dependen de la implementación, y aspectos
- Composición. lógicos los que no dependen de ella.
- Organización.
- Notas. El término implementación no debe entenderse como relativo a código (implementación
- Componentes de datos: (igual que en los Flujos de datos) software), sino como el resultado de la asignación de funciones a los elementos de que pueda
constar un sistema.
- Entidades externas:
- Nombre Los siguientes son aspectos físicos que podrían darse en un DFD:
- Descripción
- Referencias a nombres de departamentos.
En un DD se presentan "alias" cuando al modelar un sistema hay datos que se nombran de - Referencias a lugares concretos.
distinta manera y que en realidad representan el mismo dato. Su utilización no es muy - Nombres de personas.
conveniente ya que se crean redundancias en la especificación estructurada. - Ficheros físicos.
- Detalles procedimentales.
- Dispositivos.
- Sistemas informáticos ya existentes.

Organización de Sistemas Informáticos 187 188 Organización de Sistemas Informáticos


8.1. Modelo físico actual
El modelo físico actual se obtiene plasmando el flujo de información que observemos en el
sistema en su configuración actual. Aunque procuremos evitar reflejar aspectos físicos, el
carácter físico de este primer modelo es inevitable:
- Aún no poseemos un grado de conocimiento del sistema (de sus aspectos esenciales,
de qué) como para abstraer todos los detalles físicos (lo accidental, el cómo).
- La ausencia total de referencias físicas podría dificultar la comunicación con los
usuarios, justo en la fase en que más necesitamos obtener información de ellos.
8.2. Modelo lógico actual
Se trata de eliminar los aspectos físicos del modelo del sistema actual. Para ello:
1. Reestructurar la jerarquía de DFD:
Construir DFD expandidos en los que eliminaremos duplicidades, y volveremos a
agrupar los procesos, en diagramas, con arreglo a criterios lógicos. Cuando un DFD
contiene referencias físicas es fácil que un mismo procesamiento (desde el punto de
vista lógico) aparezca duplicado en el conjunto de diagramas, porque se realice en
varios departamentos, o en varios lugares, por distintas personas. Al unir los
diagramas pueden detectarse estas duplicidades y ser eliminadas.
También puede suceder que el mero hecho de la dispersión geográfica de un
procesamiento genere necesidades de procesamiento que desaparecen en cuanto se
elimina la dispersión.
2. Obtener un equivalente lógico a la estructura de ficheros:
Se trataría de estudiar en conjunto los ficheros del sistema y obtener una estructura
equivalente, con la misma información, pero una estructura más adecuada.
Básicamente se trata de descomponer las estructuras complejas en estructuras simples,
tipo tuplas relacionales, y normalizar la estructura resultante. Esta normalización es
útil de cara a la obtención del modelo lógico, aún cuando no se piense hacer uso de un
SGBD.
DeMarco propone una técnica que partiendo de los ficheros permite obtener una
estructura de tablas en tercera forma normal.
Otros proponen obtener un diagrama entidad-relación equivalente, a la estructura de
ficheros, y realizar un diseño convencional a partir de éste.
Organización de Sistemas Informáticos 189
3. Revisar la estructura resultante, eliminando detalles físicos residuales:
No está de más hacernos acompañar de los usuarios en alguno de estos recorridos;
rememorando las características físicas eliminadas; para asegurarnos de la completitud
del modelo; y familiarizarnos con el nuevo modelo lógico.
8.3. Modelo lógico nuevo
El proceso a seguir es el siguiente:
1. Identificar los cambios a introducir.
Releer el estudio de viabilidad, donde se indican las mejoras a introducir en el
sistema.
2. Identificar el dominio del cambio.
Recorrer la jerarquía de DFD detectando las partes del sistema que se verán afectadas
por los cambios. Es interesante sustituir esas zonas por macro-procesos, ya que
conseguiremos delimitar visualmente los dominios del cambio y determinar el
intercambio de información a través de la interface entre esas zonas y el resto del
sistema.
3. Redefinir el dominio del cambio.
Ahora el analista tiene las manos libres para modificar convenientemente,
drásticamente si es necesario, las zona del cambio. Esto, por supuesto, a nivel lógico,
introduciendo nuevos flujo y procesos, sin anticipar detalles físicos de la nueva
implementación del sistema.
Esta labor debe hacerse poniendo en práctica todas las indicaciones dadas (buena
descomposición funcional, completitud y coherencia del DD).
4. Verificación y validación.
Los diagramas deben someterse al proceso de verificación y validación expuestos
anteriormente.
190 Organización de Sistemas Informáticos
8.4. Modelo físico nuevo
Se trata de seguir el proceso inverso, revistiendo de detalles físicos el modelo lógico nuevo
para obtener una nueva implementación del sistema. Esta fase, como la anterior son creativas,
no de análisis, sino de diseño (a nivel de sistema, no de diseño de subsistemas software).

La estrategia recomendada es la de proponer varias opciones, labor creativa, a la que

sucederá una labor destructiva de evaluación de opciones y de selección de la más adecuada,
o de proponer nuevas opciones si ninguna de las disponibles se considera viable.

En todo el proceso la participación de los usuarios debe ser activa, y en la selección decisiva.

Los aspectos a decidir van desde:

- La distribución geográfica del sistema.

- y el nivel de automatización a implantar, pasando
- por los requerimientos hardware, y la configuración de las interfaces hombre-
máquina.

También pueden plantearse nuevas formas de organización y funcionamiento, a nivel de

sistema.

Por último habrán de delimitarse las restricciones de costo y tiempo de ejecución de los
distintos subproyectos a emprender, y de los productos y servicios a contratar.

Para ilustrar estos aspectos será necesario elaborar algunos DFD físicos que: no serán tan
detallados como los DFD lógicos; no están llamados a sustituirlos, sino a ilustrar las
decisiones de diseño físico.

No será necesario en cambio modificar el DD, todo lo más habrá que añadir algún término al
glosario del proyecto.

Por lo que respecta a los subsistemas software, lo que más nos atañe ahora, lo que aporta el
modelo físico es:
- La selección de los subsistemas a automatizar.
- Las restricciones de costo-tiempo (elementos de planificación).
- Los requerimientos no funcionales de los subsistemas software.

La especificación de los requerimientos funcionales queda cubierta con los productos del
diseño lógico.

Organización de Sistemas Informáticos 191 192 Organización de Sistemas Informáticos


Apéndice II
Técnicas de Obtención de Información
1. Introducción
Disponer de técnicas eficaces de obtención de información es vital en el desarrollo de
proyectos de sistemas. Estas técnicas son utilizadas durante todas las fases del ciclo de vida
del desarrollo de sistemas.
Las técnicas de obtención de información son procesos formales que utilizan procedimientos
de búsqueda, entrevistas, cuestionarios, muestreo y otras técnicas para recoger toda la
información disponible sobre los sistemas, sus necesidades y las preferencias de los usuarios.
Existen muchas ocasiones para obtener información durante el ciclo de vida del desarrollo de
sistemas. Sin embargo, la obtención de información es de vital importancia principalmente
durante las fases de la planificación y análisis de sistemas. Es durante estas fases cuando el
analista aprende el vocabulario de la empresa y del sistema, así como sus problemas,
oportunidades, limitaciones, necesidades y prioridades.
La obtención de información es necesaria también durante las fases de diseño y soporte, pero
en menor medida. Durante el diseño de sistemas intenta incrementar sus conocimientos sobre
la tecnología elegida para el nuevo sistema. Durante la fase de soporte de sistemas, la
obtención de información adquiere importancia para determinar en qué medida alcanza el
sistema el punto a partir del cual ha de plantearse desarrollarlo de nuevo.
2. Clasificación
Una vez justificada la necesidad de conocer técnicas de obtención de información pasamos a
discutir las técnicas más utilizadas para el desarrollo de sistemas. Para obtener el éxito en éste
cometido es necesario tener un conocimiento de todas estas técnicas. Normalmente, los
analistas aplican varias de ellas a lo largo de cada proyecto de sistemas. Para poder elegir la
más adecuada en una situación dada, habrán de conocerse las ventajas y los inconvenientes de
cada una de estas técnicas:
Organización de Sistemas Informáticos 193
• Muestreo de documentación, formularios y archivos existentes
• Investigación y visitas a instalaciones
•
•
•
Observación del entorno de trabajo.
Entrevistas
Cuestionarios
• Diseño conjunto de aplicaciones
3. Muestreo de documentación, formularios y archivos
existentes
Cuando se estudia un sistema existente, puede conseguirse una buena comprensión del mismo
si se analizan la documentación, los formularios y los archivos existentes. Un buen analista
deduce los hechos antes de la documentación existente que de las personas.
¿Qué clase de documentos pueden informarnos sobre la naturaleza de un sistema? El primer
documento que debería buscar el analista es el esquema de la organización. A continuación,
el analista tal vez quiera trazar los hechos que condujeron al planteamiento del proyecto. Para
lograrlo, el analista puede querer reunir y revisar los documentos que describan el problema
existente.
Además de los documentos que describen el problema, existen normalmente documentos que
describen la función de empresa en fase de estudio o de diseño. Además, no ha de olvidarse
de verificar la documentación de los estudios y diseños previos sobre los sistemas llevados a
cabo por consultores y analistas de sistemas.
En cuanto a archivos, programas y formularios, como no sería práctico estudiar todas las
presencias de cada uno de los formularios y archivos existentes, los analistas suelen aplicar
técnicas de muestreo para obtener una idea general de lo que está sucediendo en el sistema.
4. Investigación y vistas a instalaciones
Una segunda técnica de obtención de información consiste en llevar a cabo una detenida
investigación de la aplicación y el problema. Buenas fuentes de información son las
publicaciones informáticas disponibles comercialmente, así como las revistas que leen
típicamente los usuarios finales. De esta forma, será posible aprender el modo en que
actuaron otros para resolver problemas similares. También puede saberse así si existen o no
paquetes de software que puedan resolver nuestro problema.
Una forma similar de investigación consiste en visitar otras empresas o departamentos que
hayan vivido problemas similares. Los miembros de las sociedades profesionales pueden
suministrarnos interesantes contactos.
194 Organización de Sistemas Informáticos

5. Observación del entorno de trabajo
La observación es una de las técnicas más eficaces para reunión de datos que nos ayuden a
conseguir comprender un sistema.
La observación es una técnica de obtención de información durante la cual los analistas o
bien participan activamente o bien actúan como espectadores de las actividades llevadas a
cabo por una persona para conocer mejor un sistema.
Esta técnica se utiliza con frecuencia cuando no se está seguro de la validez de los datos
recogidos por otros medios o cuando la complejidad de ciertos aspectos del sistema impide
que las explicaciones de los usuarios finales estén claras.
Incluso aunque disponga de un plan de observación bien concebido, el analista de sistemas no
tendrá la seguridad de lograr sus objetivos. Por ello, deberá tener en cuanta los pros y los
contras de la técnica de observación:
Ventajas
1. Los datos recogidos por observación pueden ser muy fiables.
2. El analista de sistemas puede ver exactamente lo que se hace. Además puede obtener
los datos que describen el entorno físico de la tarea.
3. La observación es relativamente barata en comparación con otras técnicas.
4. La observación permite al analista de sistemas hacer medidas del trabajo.
Inconvenientes
1. Como las personas suelen sentirse incómodas cuando son objeto de observación,
pueden hacer las cosas de forma diferente sin darse cuenta.
2. En el momento de la observación, el trabajo puede no tener el nivel de dificultad o de
carga experimentado normalmente.
3. Algunas actividades de los sistemas pueden tener lugar de cuando en cuando, lo que
provocará inconvenientes de planificación al analista de sistemas.
4. Las tareas que se observan están sujetas a diversos tipos de interrupciones.
5. Algunas tareas pueden no llevarse a cabo siempre de la misma forma en que son
observadas por el analista de sistemas.
6. Si las personas han estado llevando a cabo sus tareas en formas que incumplen los
procedimientos operativos estándar, pueden proceder temporalmente de forma
correcta mientras están siendo observadas.
Directrices para la observación
La observación debería hacerse primero cuando la carga de trabajo es normal. Más adelante,
pueden llevarse a cabo observaciones durante los periodos de máximo trabajo para reunir
información que mida los efectos causados por un mayor volumen de trabajo. El analista de
Organización de Sistemas Informáticos 195
sistemas podría obtener también muestras de los documentos o formularios empleados por las
personas que observa.
Con una planificación adecuada completa, puede iniciarse la observación real. Una
observación eficaz es difícil de llevar a cabo. El mejor profesor es la experiencia; sin
embargo, las directrices que se proponen seguidamente pueden servir de ayuda para
desarrollar buenas técnicas de observación:
1. Determinar el quién, el qué, el dónde, el cuándo, el porqué y el cómo de la
observación.
2. Obtener autorización de los directivos o supervisores adecuados.
3. Informar a quienes serán observados del propósito de la observación.
4. Tratar de pasar inadvertido.
5. Tomar notas durante la observación o inmediatamente después de la misma.
6. Revisar las notas de la observación con las personas adecuadas.
7. No interrumpir a las personas observadas en su trabajo.
8. No centrarse demasiado en actividades triviales.
9. No tener prejuicios.
6. La Entrevista
Nos interesa definir la entrevista dentro de la ingeniería del software con la finalidad de
demarcarla de otras técnicas de obtención de información.
Esta definición podría ser:
Técnica de obtención de información mediante el diálogo mantenido en un encuentro
formal y planeado, entre una o más personas fuente y una o más destino, en el que se
transforma y sistematiza la información conocida por aquellas, de forma que sea un
elemento útil para el desarrollo de un proyecto de software.
Aclararemos algunos de los términos que han sido utilizados en la anterior definición:
Formal: Lo utilizamos para referirnos a que los encuentros deben ser concertados y
realizados según ciertas reglas del entorno ( considerar las reglas de cada
entorno). Como ejemplos podríamos citar el cursar una solicitud para que
pueda establecerse la entrevista o etiquetar cada una de las entrevistas que se
lleven a cabo.
Planeado: Tanto las pautas a seguir en las entrevistas como los guiones de éstas deberán
ser estudiadas previamente.
Fuente: Serán los usuarios para los cuales se intenta desarrollar la aplicación.
Destino: En este término englobamos a los ingenieros de sistemas y analistas
encargados de realizar el proyecto.
196 Organización de Sistemas Informáticos
 En general las ventajas e inconvenientes de las entrevistas en relación a otras técnicas de
6.1. Clasificación obtención de información son las siguientes:

El criterio que seguiremos para clasificar las entrevistas se basará en el modo de realización
de éstas y su contenido (forma de encauzar la entrevista por parte del entrevistador).
Clasificamos las entrevistas en tres tipos:
1. Estructuradas:
Consiste en realizar preguntas estudiadas y bien definidas, cuyas respuestas pueden
ser:
a) Respuestas abiertas: El entrevistado responde libremente a las preguntas realizadas
por el entrevistador.
b) Respuestas cerradas: El entrevistado elige entre una serie predefinida de respuestas.
2. No estructuradas:
Donde tanto las preguntas como las respuestas son libres.
Ventajas
1. Las entrevistas dan al analista la oportunidad de animar al entrevistado a responder
con libertad y espíritu abierto a las preguntas. Al establecerse una compenetración, el
analista de sistemas puede inducir en el entrevistado un sentimiento de contribución
activa al proyecto de sistemas.
2. Las entrevistas permiten al analista de sistemas obtener mayor información del
entrevistado.
3. Permiten además adaptar o replantear las preguntas para cada persona.
4. Dan la oportunidad de observar la comunicación no verbal del entrevistado.
Inconvenientes
1. Hacer entrevistas lleva mucho tiempo y es, por tanto, un método costoso.
2. El éxito de las entrevistas depende fuertemente de las dotes de comunicación del
analista de sistemas.
3. Las entrevistas pueden perder utilidad debido a la posición de los entrevistados.

3. Mixta:
Agrupamos preguntas tanto del primer tipo como del segundo.
Las ventajas (V) e inconvenientes (I) que podríamos encontrarnos al utilizar el primero o el
segundo tipo de entrevista quedan reflejadas en la siguiente tabla.
6.2. Plan de entrevistas
Es conveniente elaborar un plan de entrevistas ya que la finalidad de éstas es recoger la mayor
información posible sin ambigüedades ni información no relevante para el proyecto. Para ello
se pueden seguir los siguientes pasos:

Característica Estructurada No estructurada 1. Realizar una toma de contacto inicial que permita:
Costo de preparación I V
Flexibilidad en preguntas I V
- Conocer los objetivos generales del sistema.
Flexibilidad en áreas de información a explorar. I V
Sesgo personal del entrevistador V Depende del entrevistador
- Conocer la estructura jerárquica de los diferentes usuarios
Preparación del entrevistador V I - Determinar qué informaciones adicionales deben ser recogidas de fuentes externas
Evaluación objetiva de preguntas y respuestas V I al sistema: legales, bibliográficas, etc.
Comodidad de los entrevistados Depende del
Depende del entrevistador
entrevistado Podemos citar los siguientes ejemplos:
Duración V I
Rendimiento de la entrevista (información/tiempo) V Depende del entrevistador
- Sistema experto: teoría del sistema experto, conocimientos del área...
Administración y evaluación V I
Uniformidad entre entrevistados V Depende del entrevistador - Biblioteca: normativas bibliográficas, catálogos ...

Tabla II-1. Ventajas e inconvenientes de utilizar entrevistas estructuradas o no estructuradas 2. Identificar jerarquías de usuarios e identificar usuarios clave (aquellos que pueden
proporcionar mejor información )
Conclusión: El tipo mixto podría resolver los problemas de ambos. En el punto siguiente
veremos lo apropiado de adaptarse en cada caso a las necesidades de recogida 3. Elaborar un plan de entrevistas:
de información.
- En la especificación del sistema y del software es cuando la entrevista tiene mayor
valor como técnica.

Organización de Sistemas Informáticos 197 198 Organización de Sistemas Informáticos


- Se debe elaborar un plan y un calendario de entrevistas para realizar esta
definición, que puede formar parte de la planificación de la especificación del
sistema.
- El plan necesitará ser modificado conforme se desarrolle el estudio y el que sea
más o menos estricto depende del sistema concreto.
El tipo de entrevista dependerá de la fase en que nos encontremos ya que parece razonable
comenzar por entrevistas no estructuradas evolucionando, posteriormente, conforme se
entrevistan a los distintos niveles de usuarios, hacia una mayor estructuración. Incluso puede
llegar el momento en el que se concierten entrevistas para resolver problemas específicos
perfectamente delimitados.
6.3. Estrategia de entrevista
6.3.1. Preparación
Una entrevista no debe improvisarse, debe prepararse seriamente. Esta preparación implica la
realización de los siguientes puntos:
Identificación del (los) interlocutor (es).
• Si viene impuesto debemos conocer:
- Su posición dentro del sistema
- Su grado de conocimiento del tema o de aspectos particulares de éste.
- Su deseo de cooperación
• Si podemos escogerlo, debe:
- Conocer los problemas bajo todos sus aspectos (prácticos y generales).
(Generalmente los cargos intermedios son los que mejor conocen los problemas).
- Elegir una persona cooperante antes que una eminencia poco cooperadora.
• En cualquier caso las normas generales son:
- Los superiores jerárquicos (si los hay) deben dar su conformidad para entrar en
contacto con ellos. En muchos casos son estos mismos superiores los que nos
ponen en manos del personal más informado.
- En empresas pequeñas, con las que hay un grado de contacto personal intenso,
puede ser conveniente perder algo de tiempo entrevistando a todo el mundo,
previo consentimiento de la jerarquía, por varios motivos:
o Favorecer la buena disponibilidad del personal de cara al producto que se
elabora (hacer que se sientan implicados).
Organización de Sistemas Informáticos 199
o Conocer parcelas de actividad sórdidas o intrascendentes, pero que puedan ser
fundamentales para el sistema.
o Conocer las actitudes de todos los usuarios, sus problemas y cómo los puede
aliviar el nuevo sistema (o empeorar).
- Cuidado con los presuntos conocedores de la informática: respetar sus opiniones,
jamás despreciar su trabajo, ser siempre críticos.
• Evidentemente conocer a las personas supone haber entrado en contacto con ellas, se
pueden aprovechar las primeras entrevistas para establecer estos contactos.
Contactos previos a la entrevista.
• Existen diversos motivos para establecer los primeros contactos con el entrevistado:
- Uno de éstos motivos es que se incluya la entrevista en su debido tiempo, ya que
el realizarla "a salto de mata" puede ser contraproducente si el interlocutor no se
centra rápidamente en el tema. Hay usuarios que se prestan bien a esto y otros a
los que no hay otra forma de abordar.
- Otro motivo es que un contacto con antelación da visos de formalidad.
- El último es que el entrevistado conozca el motivo de la entrevista y pueda
preparárselo.
• Se suele recomendar que la entrevista se realice en el lugar de trabajo del entrevistado
aunque esto no es siempre lo mejor, depende del caso particular.
• Si se considera oportuno puede mandarse un orden del día.
Preparación propiamente dicha.
• Hay que establecer una estrategia para abordar los problemas. Generalmente se
recomienda descender de lo general a lo particular para entrar paulatinamente en los
detalles que más nos interesan.
Esto se podría realizar de dos formas:
1. Llevando cada punto hasta el final, es decir, desarrollar un punto en
concreto hasta el final antes de pasar a otro.
2. Descendiendo en paralelo con todos los puntos.
• El entrevistador debe familiarizarse con el tema de la entrevista y preparar un
conjunto adecuado de cuestiones que deben abordarse en la entrevista. ( ver formato
de preparación de entrevista )
200 Organización de Sistemas Informáticos

6.3.2. La entrevista
Expondremos observaciones prácticas para una entrevista muy formal en la que se supone
que conocemos escasamente al interlocutor:
- Procurar ser puntual y presentarse bien vestido.
- Al principio de la entrevista tendremos que:
ƒ Presentarnos.
ƒ Preguntar con cortesía el tiempo que su interlocutor le puede dedicar.
ƒ Precisar que desearía tomar notas durante la entrevista, e indicar que la
memoria, o el resumen, que se va a redactar le será enviado a su interlocutor
en primer lugar y que no será difundido si éste no da su conformidad.
• En la entrevista propiamente dicha tendremos que:
- Recordar el objeto de esta entrevista y precisar su contexto. Enumerar las
principales razones que nos han movido a solicitarla.
- Formular las preguntas generales con el fin de estimular el diálogo y establecer el
marco de desarrollo de la entrevista.
- Durante la entrevista debemos:
ƒ No hacer nunca preguntas duras. Para obtener determinadas informaciones
conflictivas se pueden utilizar preferentemente preguntas indirectas, cuyas
respuestas, estudiadas, permitirán deducir las informaciones deseadas.
ƒ Evitar que el interlocutor se salga del tema, pero no interrumpiéndole jamás.
Tampoco es malo charlar unos instantes sobre temas diferentes a los que
justifican la entrevista.
ƒ Incluso si el interlocutor se sale del tema, hay que ser, o al menos parecer, muy
atento: su interlocutor le quedará muy agradecido.
ƒ Demostrar interés en los trabajos que realiza su interlocutor. Preguntarle qué
dificultades tiene: esto le dará ocasión para informarle de sus tareas, sus
responsabilidades, sus métodos de trabajo, etc. (Es decir, debemos dejar que se
queje).
ƒ Dirigir la entrevista, pero de forma muy flexible; por ejemplo, no contestar
nunca por su interlocutor haciendo auténticas preguntas-respuestas (en
entrevistas libres).
ƒ Si se presenta la ocasión, no dudemos en aliviar la atmósfera concediendo algo
de importancia a acontecimientos anodinos: alguien que abre la puerta del
despacho, cigarrillos, etc.
ƒ Hacer, periódicamente, el balance mental de los problemas evocados.
ƒ No utilizar jamás términos técnicos, o explicarlos en términos sencillos y
comprensibles.
ƒ No olvidar tomar notas discretamente para evitar distraer al entrevistado.
ƒ Procurar no superar el límite de tiempo que su interlocutor le ha concedido. En
cualquier caso este ha de ser menor de una hora.
Organización de Sistemas Informáticos 201
ƒ Cuando se hayan discutido todos los temas, realizar preguntas que se crea que
se deben discutir.
• Al final de la entrevista hay que preparar las posibles continuaciones de ésta: nueva
cita, reunión con la participación de otras personas, etc. También habría que
determinar, si es posible, los períodos, o mejor las fechas de estas entrevistas.
Hay que recordar que se va a enviar una memoria o un informe de esta entrevista a su
interlocutor: precisar en qué plazos. Seguidamente habría que fijar el plazo para que el
interlocutor nos haga llegar sus observaciones y sus sugerencias sobre dicha memoria.
Por último hay que dar las gracias a su interlocutor por haberle recibido, recordándole
discretamente que ha prometido mandarle determinados documentos.
6.3.3. Postentrevista
El procedimiento a seguir tras la entrevista puede ser el siguiente:
• Completar las notas que se han tomado durante la entrevista y resumir la información
recabada.
• Respetar el plazo de envío de la memoria o informe.
• Enviar los documentos prometidos en los plazos fijados.
• Dar las gracias al superior jerárquico por la calidad de la entrevista que el interlocutor
le ha concedido y hacerle llegar un ejemplar de la memoria o informe ya revisado por
el interlocutor.
7. Cuestionarios
Un cuestionario es un conjunto de preguntas que deben ser contestadas por escrito por una
determinada población, generalmente esta población es amplia. Según el contenido de los
cuestionarios podemos clasificarlos en los siguientes tipos:
- Abiertos:
Las respuestas no están delimitadas, esto permite mayor libertad de expresión.
- Cerrados:
Se fuerza a respuestas concretas. Un mismo tipo de pregunta puede formularse para
obtener diferente rango de respuestas:
ƒ Elección exclusiva (respuestas del tipo si/no). Por ejemplo: ¿Cree que
existen muchos circuitos integrados defectuosos?.
ƒ Escala cualitativa (acuerdo/desacuerdo). Por ejemplo: Existen muchos
circuitos integrados defectuosos. Las posibles respuestas son: de acuerdo,
202 Organización de Sistemas Informáticos

totalmente de acuerdo, no estoy seguro, en desacuerdo, totalmente en
desacuerdo.
ƒ Cantidad, es decir, la pregunta requiere como respuesta una determinada
cantidad. Por ejemplo: De cada 100 circuitos integrados ¿cuántos son
defectuosos?
ƒ Rango o escala cuantitativa, donde la respuesta es un rango de valores.
Por ejemplo: De cada 100 circuitos integrados son defectuosos (0-5, 6-10,
>50,etc.)
ƒ Selección de respuestas limitadas. Por ejemplo: Las causas más
frecuentes de circuitos integrados defectuosos son:
a) Fallo en la impresión de la pista.
b) Fallo en la conexión de las patillas.
c) Fallo en el encapsulado de plástico.
- Mixtos: una combinación de los anteriores
Los buenos cuestionarios no solo se escriben sino que se diseñan. Una buena elaboración
acompañada de una prueba previa, tanto del formato como de las preguntas, son la base de
una recopilación de datos significativa a través del cuestionario. Introduciremos una serie de
pautas que ayudarán en la formulación de un cuestionario:
1. Determinar qué datos necesitan recabarse y qué personas son las más calificadas
para proporcionarlos. Si hay otros grupos que pueden proporcionar datos variantes
y mayor visión también se identificarán.
2. Seleccionar el tipo de cuestionario a utilizar (abierto, cerrado o mixto).
3. Desarrollar un grupo de preguntas para incluirlas en el cuestionario. Las preguntas
extras que son intencionalmente redundantes, pueden ser útiles al asegurar
respuestas consistentes por parte de quien responda.
4. Examinar el cuestionario para encontrarle fallos y defectos, como:
a. Interrogantes innecesarias.
b. Preguntas que pueden ser mal interpretadas debido a su enfoque o
forma de escritura.
c. Preguntas que el sujeto posiblemente no pueda responder, dado que
desconoce la respuesta.
d. Preguntas que están escritas de forma que se escogerá la respuesta
preferida.
e. Preguntas que se interpretarán de forma diferente dependiendo del
marco de referencia de cada entrevistado.
f. Preguntas que no proporcionan opciones adecuadas de respuesta.
g. Un ordenamiento no adecuado de las preguntas o respuestas.
5. Probar previamente el cuestionario en un grupo pequeño de personas, para detectar
otros problemas posibles. Así no solamente se describen los problemas en cuanto a
Organización de Sistemas Informáticos 203
su escritura, espaciado, ortografía, y métodos de registro de respuestas, sino
también proporciona una indicación del tipo de respuestas que se recopilarán en un
grupo mayor. Si existen muchas respuestas inesperadas, se captarán durante la
prueba previa. Hay que asegurar que la muestra de prueba sea comparable al grupo
mayor que recibirá el cuestionario.
6. Analizar las respuestas del grupo de prueba para asegurar que el análisis de los
datos que se busca puede llevarse a cabo con el tipo de datos recopilados. Si estos
datos no revelan algo que los analistas no reconocen y no necesitan verificar, el
cuestionario puede no ser necesario en su forma actual.
7. Realizar cambios finales de edición, correcciones de mecanografía y ajustes en la
forma; entonces imprimir el cuestionario en una forma limpia y legible.
8. Distribuir el cuestionario. Cuando sea posible, anotar el nombre de cada persona.
Ventajas
1. En su mayoría, los cuestionarios pueden ser contestados con rapidez. Los encuestados
pueden completar y remitir los cuestionarios cuando mejor les convenga.
2. Los cuestionarios ofrecen un medio relativamente económico para recoger datos de un
amplio número de personas.
3. Los cuestionarios permiten a las personas mantener el anonimato. Por consiguiente, es
más probable que éstas informen de los hechos reales, en vez de decir lo que piensan
que su jefe aprobaría que dijera.
4. Las respuestas pueden incluirse en tablas y analizarse rápidamente.
Inconvenientes
1. El número de encuestados es, a menudo, insuficiente.
2. No existe garantía de que los encuestados respondan o expliquen todas las preguntas.
3. Los cuestionarios suelen ser poco flexibles. Impiden que el analista de sistemas
obtenga información voluntaria de las personas o replantee preguntas que puedan
haber sido malinterpretadas.
4. El analista de sistemas no tiene la posibilidad de observar y analizar el lenguaje
corporal del encuestado.
5. No existe una oportunidad inmediata para aclarar respuestas vagas o incompletas a
una pregunta.
6. Los buenos cuestionarios son difíciles de preparar.
8. Diseño conjunto de aplicaciones
La técnica clásica de elaboración de entrevistas puede plantear diversos problemas debido a
que las mismas por separado, a menudo dan como conclusiones hechos, opiniones y
prioridades en conflicto. Como resultado hay que hacer numerosas entrevistas de seguimiento
y reuniones de grupo. Por este motivo, muchos centros de información están haciendo uso de
sesiones de trabajo en grupo como sustitutas de las entrevistas.
204 Organización de Sistemas Informáticos

El diseño conjunto de aplicaciones (DCA) es un proceso por el cual se llevan a cabo
reuniones en grupo altamente estructuradas que convocan en una misma sala a los usuarios
del sistema, los propietarios del sistema y los analistas durante un amplio periodo de tiempo.
Los objetivos de esta técnica son esencialmente los mismos que los de las entrevistas, con la
salvedad de que se necesitan más analistas para llevarlos a cabo. Uno de estos analistas
actuará como coordinador o moderador. Otro, al que nos referiremos como escribiente,
anotará los hechos y cuestiones que requieran acciones o entrevistas posteriores.
La dirección de una sesión de diseño conjunto de aplicaciones requiere una fuerte
preparación, y seguir una serie de etapas: definición del proyecto, dirección de una
investigación general previa, planificación de la sesión, dirección de la sesión y presentación
de resultados.
8.1. Definición del proyecto
El analista debe entrevistar a los propietarios del sistema para determinar la panorámica
general de requisitos y expectativas. En estas entrevistas, el analista debe desempeñar las
siguientes funciones:
1. Pedir a los propietarios del sistema que señalen a los usuarios que participarán en la
sesión de DCA.
2. Proponer o solicitar fechas para las cuales deban llevarse a cabo las sesiones DCA.
3. Obtener su autorización para permitir a los usuarios del sistema tomar parte durante
toda la sesión.
4. Resumir y revisar la definición del proyecto.
5. Seleccionar el coordinador (o moderador) y el escribiente de la sesión DCA.
6. Seleccionar el lugar para celebrar la o las sesiones DCA.
8.2. Dirección de una investigación general previa
En el ámbito de definición del proyecto, el analista puede tener una idea muy general sobre
las funciones de dicho proyecto, pero saber muy poco sobre el sistema o sistemas actualmente
en funcionamiento. Por tanto, antes de las sesiones DCA, el analista puede tener que llevar a
cabo entrevistas con algunos usuarios seleccionados para mejorar su conocimiento del
sistema actual.
Una vez completado este esfuerzo de investigación, el analista revisará el sistema actual y las
expectativas del DCA con el moderador y el escribiente. Por último, el analista completará
una agenda para la sesión DCA.
Organización de Sistemas Informáticos 205
8.3. Planificar la sesión DCA
La siguiente etapa consiste en la planificación de la sesión DCA
• Si fuera necesario, se dará la formación adecuada al moderador y al escribiente de la
sesión.
• Se distribuirá entre los participantes adecuados la agenda de la misma y la
documentación anteriormente reunida.
• Se programará el lugar donde se llevará a cabo la sesión.
• Se desarrollará un guión que deberá seguirse durante la sesión DCA (el guión es
normalmente una ampliación en detalle de la agenda que usará el moderador).
• Se prepararán soportes de transparencias u otros medios de exposición con apoyo de
equipos audiovisuales.
Hacer una planificación correcta es fundamental para el éxito de una sesión DCA. Una vez
completa la planificación, puede darse paso al inicio de la sesión DCA.
8.4. Dirección de la sesión
La sesión DCA comienza con los comentarios de apertura, la introducción y un breve repaso
de la agenda y los objetivos de la sesión DCA. El moderador dirigirá la sesión conforme al
guión preparado. Para dirigir con éxito la sesión, el moderador deberá seguir las directrices
que se proponen a continuación:
• No desviarse excesivamente de la agenda propuesta.
• Vigilar la programación.
• Asegurar que el escribiente puede tomar notas.
• Evitar el uso de argot técnico.
• Aplicar técnicas de resolución de conflictos.
• Permitir grandes pausas.
• Estimular el consenso del grupo.
• Estimular la participación de todos los usuarios impidiendo que unos dominen sobre
otros.
8.5. Presentar los resultados
El producto final de una sesión DCA es típicamente un documento escrito formal. Este
documento es esencial para confirmar que todos los participantes en la o las sesiones están de
acuerdo con las especificaciones. El contenido y la organización de las especificaciones
dependerá evidentemente de los objetivos de la sesión DCA.
206 Organización de Sistemas Informáticos
 - Una vez identificadas las metas globales, se evalúa la información suplementaria:

Apéndice III
- ¿Existe la tecnología para construir el sistema?
- ¿Qué recursos especiales de desarrollo y fabricación serán necesarios?
- ¿Qué límites se han puesto al presupuesto y planificación temporal?

Tareas a realizar en la fase de definición - Si el nuevo sistema es un producto a vender a muchos clientes, se plantean a su
vez las siguientes cuestiones:
de un proyecto - ¿Cuál es el mercado potencial del producto?
- ¿Cómo es comparativamente este producto con los de la competencia?
- ¿Qué posición ocupa este producto en la línea general de producción de la
compañía?

1. Análisis del sistema.

Esta actividad es la encargada del estudio del sistema global en el cual se encuentra (si existe)
y se va a encontrar el software que se intenta desarrollar. El estudio previo del sistema, de los
subsistemas integrantes y de las interrelaciones entre ellos es esencial en el análisis de los
problemas.
El software como un subsistema más mantiene relaciones con otros subsistemas de la
organización (otro software, personas, hardware, etc.) los cuales es necesario conocer. En esta
fase se extraen los requisitos globales a nivel de sistema y se estudia el subsistema software a
un nivel de abstracción elevado.
Se lleva a cabo con los siguientes objetivos:
- Identificar las necesidades del cliente.
- Evaluar el concepto del sistema para establecer la viabilidad.
- Realizar un análisis técnico y económico.
- Asignar funciones al hardware, software, personal, B.D. y otros elementos del
sistema.
- Establecer las restricciones de presupuesto y planificación temporal.
- Crear una definición de sistema que forme el fundamento de todo el trabajo de
ingeniería subsiguiente.
1.2. Estudio de viabilidad
“Todos los proyectos son posibles ¡si se tienen infinitos recursos y tiempo!”. Sin embargo, es
muy probable que el desarrollo de un proyecto esté plagado de escasez de recursos y de
fechas de entrega muy ajustadas. Para evitar pérdidas de esfuerzo es necesario un estudio de
viabilidad lo antes posible.
La viabilidad y el análisis de riesgo están relacionados: “Si el riesgo del proyecto es alto, la
viabilidad de producir software de calidad se reduce.”
Durante la ingeniería de productos centramos nuestro interés en las siguientes áreas:
- Viabilidad económica: evaluación del coste de desarrollo sopesado con los
ingresos netos o beneficios obtenidos.
- Viabilidad técnica: un estudio de función, rendimiento y restricciones que pueden
afectar a la consecución de un sistema aceptable.
- Viabilidad legal: determinar cualquier infracción, violación o responsabilidad
legal en que se podría incurrir por el desarrollo del sistema.
- Alternativas: Evaluación de enfoques alternativos al desarrollo del producto.

No es necesario un estudio de viabilidad para sistemas en que la justificación económica es

1.1. Identificación de necesidades
El analista se reúne con el cliente y el usuario final. El cliente puede ser el representante de
una compañía, el departamento de marketing de la compañía del analista, u otro departamento
técnico (para el desarrollo de un producto interno).
La intención es entender los objetivos del producto y definir las metas necesarias para
alcanzar esos objetivos.
obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe ninguna
alternativa razonable.
La justificación económica es generalmente la consideración fundamental para la mayoría de
los sistemas. La justificación económica incluye una amplia gama de aspectos a tener en
cuenta como son el análisis de costes/beneficios, las estrategias de ingresos de la empresa a
largo plazo, el impacto en otros productos o centros de beneficios, coste de recursos
necesarios para su desarrollo y crecimiento potencial del mercado.

Organización de Sistemas Informáticos 207 208 Organización de Sistemas Informáticos

 Tecnología:
La viabilidad tecnológica es frecuentemente el área más difícil de valorar en la etapa del ·¿Ha progresado la tecnología respectiva hasta el punto que sea capaz de soportar el
proceso de ingeniería del producto. Como los objetivos, funciones y rendimiento son poco sistema?
claros, cualquier cosa parece posible si se hacen las suposiciones correctas. ·¿Qué tecnologías se requieren para lograr el funcionamiento y rendimiento del
sistema?
La viabilidad legal comprende una gama muy amplia de aspectos que incluyen contratos, ·¿Cómo afectan estos aspectos tecnológicos a los costes?
responsabilidades legales, infracciones y un montón de trampas frecuentemente desconocidas
para el personal técnico. Tareas
El grado con el que se consideran las alternativas está a menudo limitado por restricciones de
• Identificar elementos del sistema actual: software, hardware, personas, B.D.,
tiempo y costes; sin embargo, no debería despreciarse una alternativa legítima por no estar
documentación, procedimientos.
subvencionada.
• Identificar los distintos subsistemas.
• Identificar la información: ingeniería de la información.
El estudio de viabilidad es revisado:
• Identificar el producto: ingeniería del producto.
- Primero por el jefe del proyecto: para valorar la fiabilidad del contenido. • Identificar las necesidades del cliente.
- Por la dirección: para valorar el estado del proyecto. o Establecer los objetivos.
o Establecer las restricciones.
El estudio debería concluir en una decisión adelante/abandonamos. o Obtener funcionalidad del producto.
o Obtener rendimiento del producto.
o Obtener la fiabilidad del producto.
o Establecer la interfaz del producto
1.3. Análisis económico • Establecer la viabilidad.
o Viabilidad económica.
Es una de las informaciones más importantes de un estudio de viabilidad: el llamado análisis o Viabilidad técnica.
coste / beneficio (una valoración de la justificación económica para un proyecto) o Viabilidad legal.
o Alternativas
Determina los costes para el desarrollo del proyecto y los pondera con los beneficios ƒ Configuraciones alternativas.
tangibles (medibles directamente en dinero) e intangibles del sistema. ƒ Criterios empleados en la selección de la configuración.
ƒ Configuración elegida y motivos.
o Análisis económico: coste/beneficio
1.4. Análisis técnico o Análisis técnico.
ƒ Riesgo de desarrollo.
Se evalúan los principios técnicos del sistema al mismo tiempo que se recoge información ƒ Disponibilidad de recursos.
adicional sobre el rendimiento, la fiabilidad, las características de mantenimiento y la ƒ Tecnología.
productividad o Revisión del estudio de viabilidad.
o Decisión de continuar.
Se suele comenzar con una valoración de la viabilidad técnica del sistema propuesto: • Considerar características de mantenimiento.
• Descripción funcional y de los datos
Riesgo de desarrollo: o Diagrama de contexto.
·¿Puede desarrollarse el elemento del sistema de manera que se consigan la función y o Diagramas de niveles o de subsistemas.
rendimiento necesario dentro de las restricciones descubiertas durante el análisis? o Asignación de elementos del sistema.
o Diccionario de datos.
Disponibilidad de recursos: o Descripción de los procesos.
·¿Tenemos disponible una plantilla cualificada para desarrollar el elemento del • Asignar funciones al hardware, software, personal, B.D. y otros elementos del sistema.
sistema en cuestión? • Establecer restricciones de presupuesto y planificación temporal.
·¿Tenemos disponibles otros recursos necesarios (hardware y software) para construir
el sistema?

Organización de Sistemas Informáticos 209 210 Organización de Sistemas Informáticos

 3. Planificación del proyecto
2. Aspectos de Gestión del proyecto
En esta fase se realiza el análisis del riesgo una vez establecido el ámbito del proyecto,
Tareas asignando los recursos, estimándose los costes, definiendo cada una de las tareas a desarrollar
y planificando el trabajo.
• Identificar los participantes en el proyecto (Gestores superiores, gestores técnicos,
profesionales, clientes y usuarios finales) Un producto software se comprende mejor según se va desarrollando el análisis, diseño, y
• Especificar el tipo de equipo de desarrollo (DD, DC, CC; cerrado, aleatorio, abierto, codificación del mismo. Sin embargo, el proyecto no debe estar supeditado a la disponibilidad
sincronizado) de información suficiente para iniciar la planificación preliminar, aunque se debe tener en
• Establecer el ámbito: cuenta que esta planificación preliminar está sujeta a cambios que se producirán a lo largo de
o Contexto la vida del proyecto a medida que se conozca más información sobre el mismo.
o Objetivos de información
o Función y rendimiento Tareas
o Restricciones (técnicas y de gestión)
• Seleccionar el modelo de proceso (paradigma de ingeniería) • Establecer el ámbito:
• Definir el tipo de aplicación software a desarrollar (de sistemas, de tiempo real, de o Contexto
gestión, de ingeniería, científico, empotrado, de computadoras personales, de I.A., etc.) o Objetivos de información
• Definir los elementos de ingeniería del software o Función y rendimiento
o Definir los métodos (actividades de planificación, análisis, diseño, etc.) o Restricciones (técnicas y de gestión)
o Definir las herramientas a utilizar. • Seleccionar el modelo de proceso (paradigma de ingeniería)
o Definir los procedimientos: • Definir los estándares de documentación.
ƒ Secuencia de aplicación de los métodos • Estimar esfuerzo de desarrollo (o coste)
ƒ Información necesaria. o Elegir método de estimación.
ƒ Controles de calidad. o Cobertura del método
ƒ Gestión de cambios. o Datos históricos utilizados en la estimación
ƒ Guías de desarrollo. o Datos del proyecto utilizados en la estimación
o Definir el paradigma de I.S. a utilizar. o Estimación según el método elegido
ƒ Identificar las etapas o Resultados obtenidos (esfuerzo, coste $ y duración)
ƒ Identificar los hitos o Margen de error
ƒ Identificar productos de cada etapa • Estimar recursos:
• Definir las actividades estructurales o Humanos
• Descomponer la funcionalidad del producto ƒ Estructura del equipo
• Estimar recursos para cada par (función-actividad estructural) o Hardware
• Establecer fechas de inicio-fin para cada par. ƒ Sistema de desarrollo
• Establecer los productos que surgirán como consecuencia de cada par. ƒ Sistema de explotación
• Descomponer el proceso (tareas para cada actividad estructural). ƒ Otros elementos
o Software
ƒ Herramientas orientadas al código
ƒ Herramientas de metodología
ƒ Herramientas de cuarta generación
• Desarrollar una estrategia de solución
o Posibles soluciones
o Solución elegida

Organización de Sistemas Informáticos 211 212 Organización de Sistemas Informáticos

 • Análisis de riesgo. 4. Análisis de requisitos
o Elaborar lista de comprobación de elementos de riesgo
ƒ Riesgos genéricos
En esta fase se procede a la recogida de toda la información posible sobre el software que se
ƒ Riesgos específicos de producto
pretende construir, y sobre el problema que se pretende solucionar. Es decir, en esta fase el
o Proyección y evaluación del riesgo riesgo = {probabilidad + coste}
analista tiene el cometido de comprender el dominio de la información que manejará el
o Definir un nivel de referencia para el riesgo (temporización, coste o
software, el procesamiento a que debe someterse esa información, el rendimiento de este
rendimiento).
procesamiento, así como las interfaces tanto en la entrada, como en la salida de la
o Supervisión del riesgo
información para estos procedimientos.
o Gestión del riesgo y planes de contingencia.
• Planificación temporal.
El objetivo de esta etapa es el especificar total, concisa, consistentemente y sin ambigüedades
o Definir modelo de ciclo de vida.
los requisitos técnicos del producto, empleándose para ello una notación formal.
o Definir las tareas a realizar en función del tipo de proyecto.
ƒ Descomponer el producto
La ERS se basa en el documento de análisis del sistema, y en esta fase se detallan los
ƒ Descomponer el proceso
requisitos que se especificaron a un alto nivel de abstracción en la fase de planificación inicial
o Determinar las interdependencias entre tareas
con el fin de definir las características que el producto de programación deberá tener.
ƒ Red de tareas
o Establecer duración de las tareas
o Realizar análisis PERT
ƒ Representar gráfico con dependencias de tareas. Tareas
ƒ Asignar duración de las tareas
ƒ Calcular tiempos PERT - Entrevistas con el cliente o cualquier otra técnica de recogida de información que
ƒ Calcular tiempos más próximos y más lejanos para cada suceso. nos aporte una visión detallada del sistema a desarrollar.
ƒ Calcular holguras y camino crítico
o Ajustar las tareas a un calendario - Resumen del producto y del objetivo del mismo, así como los ambientes de
ƒ Establecer fecha de finalización (fija o con holgura) desarrollo, operación y mantenimiento. Esta información ha sido previamente
ƒ Gráfico de tiempo (Gráfico Gantt) registrada en el plan de proyecto software, y aquí se vuelve a reflejar como una
o Asignar los recursos a las tareas. introducción al documento.
o Validar el esfuerzo (comprobar que los recursos asignados no sobrepasan a los
que se tienen) - Especificación de los requerimientos funcionales del software utilizando un
o Definir los resultados de cada tarea. método de especificación (en nuestro caso podemos utilizar la metodología SSA).
o Establecer hitos o puntos de control Independientemente del método utilizado debe especificarse:
o Determinar el seguimiento del proyecto
o Establecer cómo se garantizará la calidad 1. El dominio de la información, tanto el dominio de los datos como de las
ƒ Configurar el equipo de gestión de calidad funciones. Contiene tres visiones diferentes de los datos que son procesados
ƒ Establecer calendario de revisiones por las funciones:
ƒ Establecer requisitos a comprobar en cada revisión
o Establecer la gestión de los cambios (gestión de la configuración) - El flujo de la información, es decir, cómo la información se mueve a
ƒ Determinar la configuración del software través de la arquitectura del sistema.
• Programas
• Documentos - El contenido de la información, es decir, qué información se mueve
• Datos a través del sistema y qué significa esa información en el dominio del
ƒ Cómo identificar el cambio problema.
ƒ Cómo controlar el cambio
ƒ Cómo informar del cambio a las personas implicadas. - La estructura de la información, es decir, cómo esa información se
encuentra estructurada, qué forma tiene dentro de la estructura del
sistema.

Organización de Sistemas Informáticos 213 214 Organización de Sistemas Informáticos

 2. La partición o descomposición del problema. El problema debe
subdividirse de forma que se descubran los detalles de una forma progresiva o
jerárquica.

3. Representaciones lógicas y físicas, la visión lógica de los requisitos del

software presenta las funciones que se han de realizar y la información que se
debe procesar con independencia de los detalles de implementación. La visión
física presenta una manifestación del mundo de las funciones y de
procesamiento y las estructuras de información. Esta visión indica la
asignación existente o propuesta para todos los elementos del sistema.

- Especificación de requerimientos no funcionales del software, requisitos de

operación, software, personal, recursos, etc.

- Si el proyecto lo requiere, puede realizarse un prototipo para determinar los

requerimientos.

- Realizar una descripción de las interfaces del Software con otros elementos del
sistema. No basta documentar los requisitos que debe cumplir el software, sino que
también es necesario definir las propiedades que deben satisfacer para obtener una
interacción eficaz con otros elementos u otras aplicaciones software.

- Especificar criterios de validación que nos guiarán a la hora de aceptar o rechazar

el sistema. Esta guía deberá contemplar cada uno de los requisitos expuestos en otras
secciones.

- Revisión de la especificación de requerimientos. Esta revisión debe ser llevada a

cabo tanto por el desarrollador del software como por el cliente. Los revisores intentan
asegurarse de que la especificación está completa, es consistente y exacta. (Al final
del guión se presentan algunas cuestiones a revisar).

Organización de Sistemas Informáticos 215 216 Organización de Sistemas Informáticos

 II. Resultado.

Apéndice IV
A. Identificación de la entrevista:
1. Identificativo de la preparación.
2. Lugar.
3. Fecha.
Formatos de Documento 4. Hora.
5. Duración.
B. Incidencias sobre los participantes: Modificaciones sobre las previsiones
realizadas.
C. Cuerpo de la entrevista: Anotaciones para cada punto y/o preguntas del
cuestionario.
1. Entrevistas D. Informe final sobre la entrevista:
1. Información obtenida.
2. Información pendiente:
Introduciremos dos vertientes de esta propuesta de formato de documento, una
a. Documentos que los entrevistados deben entregar.
respecto a los elementos necesarios para un documento de preparación de entrevista y otra
b. Documentos que los entrevistadores deben entregar.
respecto a los elementos necesarios para un documento de resultado de las entrevistas.
c. Información olvidada en la entrevista.
3. Grado de cobertura de los objetivos.
I. Preparación.
4. Grado de participación y colaboración de los entrevistados.
A. Identificación de la entrevista:
5. Notas y recomendaciones especiales.
1. Identificativo único.
2. Preparada por: nombre(s) y cargo(s).
3. Fecha de preparación.
4. Fase en la que se encuadra.
5. Documento(s) al que se hace referencia. (Si se hace referencia a alguno y
modo en que hace referencia).
6. Tiempo necesitado para la preparación.
B. Identificación de los participantes previstos:
1. Entrevistado(s): nombre(s) y cargo(s).
2. Entrevistador(es): nombre(s) y cargo(s).
C. Objetivos : Se identificarán mediante numeración, caracteres alfabéticos, ...
D. Descripción de los puntos a tratar y/o cuestionario: que también serán
identificados.
E. Previsiones respecto a la entrevista:
1. Lugar.
2. Fecha.
3. Hora.
4. Duración prevista.
F. Recomendaciones a los entrevistadores:
1. Información previa a recabar.
2. Documentación a revisar.
3. Informaciones pendientes de entrevistas anteriores.
4. Consideraciones especiales sobre los participantes.
5. Otras cuestiones.

Organización de Sistemas Informáticos 217 218 Organización de Sistemas Informáticos

 3. Plan de Proyecto Software
2. Análisis del Sistema y Planificación
I. Introducción
FORMATO 1. Pressman, R.S. A. Ámbito del proyecto y Objetivos.
1. Declaración del Ámbito.
I. Introducción. 2. Funciones principales.
A. Ámbito y propósito del documento. 3. Aspectos de rendimiento.
B. Visión general. 4. Restricciones técnicas y de gestión.
1. Objetivos. B. Modelo de ciclo de vida utilizado.
2. Restricciones. C. Definición de los estándares de documentación.
II. Descripción funcional y de los datos. II. Estimaciones del proyecto
A. Arquitectura del sistema. A. Datos históricos usados para las estimaciones.
1. Diagrama de contexto B. Técnicas de estimación.
2. Descripción del diagrama de contexto C. Estimaciones de esfuerzo, coste y duración.
III. Descripción de los subsistemas. III. Riesgos del proyecto
A. Especificación del diagrama para el subsistema n. A. Análisis del riesgo.
1. Diagrama de flujo de datos. 1. Identificación.
2. Descripción del DFD. 2. Estimación del riesgo.
3. Aspectos de rendimiento. 3. Evaluación.
4. Restricciones. B. Gestión del riesgo.
5 Asignación de componentes del sistema. IV. Planificación Temporal.
B. Diccionario de Datos. A. Estructura de descomposición del trabajo del proyecto.
C. Descripción de los Procesos. B. Red de tareas (red Pert).
IV. Asignación de funciones a los recursos. C. Gráfico de Tiempo (gráfico Gantt)
V. Coste y Planificación. (puede referenciarse al Plan de Proyecto). V. Recursos del Proyecto.
VI. Apéndices. A. Personal.
B. Hardware y Software.
FORMATO 2. Fairley, R.E. C. Tabla de Recursos (enlazados al gráfico de tiempo)
VI. Organización del Personal.
I. Definición del problema. A. Estructura de equipo (si procede).
II. Justificación del Sistema. VII. Apéndices.
III. Metas del sistema y del proyecto. A. Glosario de términos.
IV. Restricciones del sistema y del proyecto. B. Bibliografía.
V. Asignación de funciones a los elementos del sistema. (se puede usar SSA) ...
VI. Características del usuario.
VII. Ambientes de desarrollo/operación/mantenimiento.
VIII. Estrategia de Solución. Estudio de viabilidad.
IX. Prioridades para las características del sistema.
X. Criterios de aceptación del sistema.
XI. Fuentes de Información.
XII. Glosario de términos.

Organización de Sistemas Informáticos 219 220 Organización de Sistemas Informáticos

 5. Especificación de Requerimientos del Software
4. Estudio de Viabilidad
FORMATO 1. (Aconsejable)
I. Introducción.
A. Declaración del problema. I. Introducción.
B. Entorno de implementación. Descripción de los fines y objetivos del software en el contexto de un sistema basado
C. Restricciones. en computadora. Debe contener una breve descripción del software, de sus objetivos y
II. Resumen de gestión y recomendaciones. de las principales restricciones del proyecto software.
A. Objetivos importantes. II. Descripción de las interfaces del software con otros elementos del sistema.
B. Comentarios. Se describen las interfaces con el hardware, personas y bases de datos. En ocasiones
C. Recomendaciones. es necesario describir las interfaces con otro software existente o que debe diseñarse.
D. Impacto. Es importante la descripción del tipo de interface de usuario que se utilizará (puede
III. Alternativas. ayudar el manual preliminar de usuario).
A. Configuraciones alternativas del sistema. III. Descripción del dominio de la información.
B. Criterios empleados en la selección del enfoque final. A. Descripción del flujo de información
IV. Descripción del sistema. B. Descripción del contenido de la información.
A. Exposición abreviada del ámbito. C. Descripción de la estructura de la información (para ello se puede utilizar un
B. Viabilidad de los elementos asignados. modelo de especificación de Bases de Datos, como el modelo Entidad-Relación).
V. Análisis de coste/beneficio. IV. Descripción del dominio funcional.
VI. Evaluación del riesgo técnico. A. Partición funcional.
VII. Consideraciones legales. B. Descripción funcional.
VIII. Otros temas específicos del proyecto. 1. Texto explicativo del proceso.
2. Restricciones.
3. Requerimientos no funcionales.
4. Diagramas de soporte.
V. Criterios de validación.
Esta sección, a la que generalmente no se presta ningún interés, es una de las más
importantes. En ella se establecen que requerimientos funcionales y no funcionales
deberán ser probados y cuales son los límites para cada una de las pruebas.
A. Requerimientos de validación.
Se especifican los requerimientos que formarán la base de las pruebas de
validación.
B. Pruebas de validación.
Discusión de los tipos de pruebas a realizar.
C. Recursos.
Recursos que serán necesarios para las pruebas de validación.
VI. Glosario de términos.
VII. Apéndices.

La descripción de los puntos III y IV suele realizarse en el contexto de un método de

especificación (como puede ser SSA, si este es el caso, tener en cuenta que el método sólo
especifica requerimientos funcionales, habrá que tener en cuenta los requisitos no
funcionales).

Organización de Sistemas Informáticos 221 222 Organización de Sistemas Informáticos

FORMATO 2. Pressman, R.S.
6. Identificación de la Documentación
Los documentos realizados se identificarán adecuadamente. A continuación figura un
I. Introducción.
ejemplo. Nosotros podemos usarlo como base o definir nuestros propios convenios de
A. Referencia del sistema.
identificación.
B. Descripción general.
C. Restricciones del proyecto de software.
XXX-Z-V-F
II. Descripción de la información.
A. Representación de la información.
donde:
B. Representación del flujo de la información.
1. Flujo de datos.
XXX identificador del proyecto
2. Flujo de control.
III. Descripción funcional.
Z es un identificador del tipo de documento:
A. Partición funcional.
si Z = P es el plan de proyecto.
B. Descripción funcional.
si Z = R es la especificación de requisitos.
1. Descripción del procesamiento.
si Z = D es el diseño.
2. Restricciones / limitaciones.
si Z = C es el código fuente.
3. Requisitos de rendimiento.
si Z = T es la prueba.
4. Restricciones de diseño.
si Z = U es el manual de usuario.
5. Diagramas de soporte.
si Z = I es la guía de instalación.
C. Descripción del control.
si Z = M es el manual de mantenimiento.
1. Especificación del control.
2. Restricciones de diseño.
V versión
IV. Descripción del comportamiento.
A. Estados del sistema.
F Fecha
B. Eventos y acciones.
V. Criterios de validación.
Ejemplo: SPC-P-0-3/95
A. Límites de rendimiento.
Computador de propósito especial; documento de plan de proyecto;
B. Clases de pruebas.
versión 0; pasó un control de cambios en marzo de 1995
C. Respuesta esperada del Software.
D. Consideraciones especiales.
VI. Bibliografía.
VII. Apéndice.

Organización de Sistemas Informáticos 223 224 Organización de Sistemas Informáticos

7. Manual de Usuario
I. Introducción.
A. Panorama y exposición del producto.
B. Terminología y características básicas.
C. Resumen de informes.
D. Bosquejo del manual.
II. Pasos previos.
A. Arranque.
B. Funcionamiento de la Ayuda.
C. Ejemplo de ejecución.
III. Funcionamiento.
A. Modos de Operación.
B. Comandos / diálogos / informes.
IV. Características especializadas.
V. Sintaxis de comandos y opciones del sistema.

Organización de Sistemas Informáticos 225 226 Organización de Sistemas Informáticos


Apéndice V
Listas de Inspección
1. Revisiones
Los productos obtenidos durante la especificación de requerimientos del software deben ser
revisados profundamente antes de seguir el proceso de desarrollo. La revisión debe realizarse
cuidadosamente por varios motivos:
- El software diseñado y producido se atendrá a las especificaciones contenidas en
estos documentos. La especificación se convierte en un contrato para el que desarrolla
el software. Los cambios introducidos con posterioridad pueden incrementar el coste
y/o retrasar la entrega del producto.
- La especificación se convierte en el producto de referencia para evaluar las
características del producto final. La validación de éste se realizará en base a lo
especificado.
Durante la revisión se evalúan el Documento de Especificación de Requerimientos y el
Manual Preliminar de Usuario intentado responder a una serie de preguntas.
La revisión de la especificación de requerimientos es una de las más importantes de las
revisiones del ciclo de vida, por lo ya comentado. Si los productos obtenidos la pasan con
éxito se iniciará el diseño del software.
En general en cada una de las fase del ciclo de vida clásica, podemos plantear una lista de
inspección o cuestiones a responder para comprobar que estamos realizando el trabajo de
desarrollo de una manera correcta, sin olvidarnos de ningún aspecto. A continuación se
muestra una lista de inspección por fases del ciclo de vida.
Organización de Sistemas Informáticos 227
2. Especificación del Sistema
1. ¿Se define con claridad y sin ambigüedad el objetivo del sistema?
2. ¿Se definen las interfaces con otros elementos hardware/software?
3. ¿Se ha realizado un estudio acerca de la necesidad del sistema a desarrollar?
4. ¿Se ha realizado un estudio acerca de la viabilidad del proyecto?
5. ¿Se han identificado los costes/beneficios del sistema?
6. ¿Se ha establecido el riesgo de desarrollo del producto?
7. ¿Se han determinado los recursos de desarrollo?
8. ¿Están disponibles los recursos?
9. ¿Es tecnológicamente posible abordar el proyecto?
10. ¿Se han considerado diferentes alternativas de configuración del sistema?
11. ¿Se han establecido los criterios de rendimiento?
12. ¿Se han establecido los criterios de fiabilidad?
13. ¿Se han establecido los criterios de portabilidad?
14. ¿Se establecen adecuadamente los límites del proyecto?
15. ¿Se ha pensado en el impacto humano del sistema?
16. ¿Se ha documentado suficientemente esta fase?
17. ¿Se han utilizado técnicas de obtención de información adecuadas?
18. ¿Se ha realizado una investigación de otros sistemas con las mismas prestaciones?
19. ¿Se ha hecho una estimación del tiempo necesario de desarrollo?
20. ¿Hay una descripción de cada función del sistema?
21. ¿Se ha asignado cada función al elemento del sistema apropiado?
22. ¿Ha tenido lugar una comunicación con el cliente adecuada?
23. ¿Se han tenido en cuenta las observaciones del cliente?
24. ¿Las funciones han sido asignadas con el suficiente detalle?
25. ¿Se considera la facilidad de mantenimiento?
26. ¿Se ha elaborado y distribuido el documento de especificación del sistema?
27. ¿Se ha establecido un mecanismo para la verificación y la validación?
228 Organización de Sistemas Informáticos

3. Planificación del Proyecto
1. ¿Se han determinado los recursos humanos, hardware y software necesarios?
2. ¿Y los recursos disponibles?
3. ¿Se utilizan métricas para la estimación de costos?
4. ¿Se usan tales métricas de la forma adecuada?
5. ¿Se usa información histórica para las estimaciones?
6. ¿Es razonable la estimación de costos?
7. ¿Es realista el presupuesto?
8. ¿Es realista la fecha de finalización?
9. ¿Se han ajustado el presupuesto y la fecha de finalización?
10. ¿Se ha desarrollado una planificación temporal?
11. ¿Están todas las tareas en la agenda?
12. ¿Hay un paralelismo adecuado entre las tareas?
13. ¿Son las asignaciones de esfuerzo a cada tarea razonables?
14. ¿Se utiliza un método de planificación estandarizado?
15. ¿Se usan diagramas que faciliten la comprensión de la planificación?
16. ¿Se ha documentado suficientemente esta fase?
17. ¿Se ha elaborado y distribuido el documento de Plan de Proyecto?
Organización de Sistemas Informáticos
4. Análisis de requerimientos del software
1. ¿Se utiliza algún método de análisis de los requerimientos del software?
2. ¿El método utilizado para el A.R.S. es el adecuado?
3. ¿Se establece adecuadamente el dominio de información referente al flujo de
información, a su contenido y su estructura?
4. ¿Se realiza la partición del problema con el suficiente nivel de detalle? ¿Es completa?
5. ¿Hay una correspondencia de tareas entre la partición del problema y la especificación
del sistema?
6. ¿Hay una división entre visión física y lógica del modelo?
7. ¿La información es “anidada” de forma que se puede descender al nivel de detalle
deseado?
8. ¿Se establece adecuadamente el dominio de información referente a la interfaz?
9. ¿Se realiza una descripción funcional adecuada?
10. ¿Son comprensibles los diagramas?
11. ¿Son los nombres de los diagramas significativos?
12. ¿Se han numerado los diagramas de flujo de datos adecuadamente?
13. ¿Están todas las definiciones en el diccionario de datos?
14. ¿Se corresponden las definiciones del diccionario de datos con los diagramas?
15. ¿Se han definido los ficheros de datos?
16. ¿Hay información redundante?
17. ¿Hay procedimientos que no realicen ninguna tarea?
18. ¿La información para cada nodo es la requerida?
19. ¿Se han nombrado todos los elementos de los diagramas?
20. ¿Se han establecido los criterios de validación?
21. ¿Se ha elaborado el manual de usuario preliminar?
22. ¿Ha tenido lugar la comunicación con el cliente?
23. ¿Ha dado opinión el usuario sobre el manual de usuario preliminar?
24. ¿Se ha elaborado y distribuido el documento de especificación de requerimientos?
25. ¿Se ha revisado el plan de proyecto?
26. ¿Es consistente el A.R.S. con el plan de proyecto?
27. ¿Es consistente la especificación?
28. ¿Es completa la especificación?
29. ¿Se ha pensado en el mantenimiento?
30. ¿El documento está bien organizado?
229 230 Organización de Sistemas Informáticos
 6. Codificación
5. Diseño
1. ¿Se ha elegido el lenguaje adecuado para la implementación?
1. ¿Ha tenido lugar una división entre diseño preliminar y diseño detallado?
2. ¿Se aprovechan los recursos del lenguaje de programación?
2. ¿El grado de cohesión es adecuado (suficientemente alto)?
3. ¿Se considera la portabilidad del código?
3. ¿El grado de acoplamiento es adecuado (suficientemente bajo)?
4. ¿Se dispone de las herramientas adecuadas para el desarrollo?
4. ¿Se ha hecho una descomposición modular adecuada?
5. ¿Se ha considerado la facilidad de mantenimiento?
5. ¿Se explica adecuadamente la función de cada módulo con alguna herramienta?
6. ¿Se ha elegido adecuadamente los nombres de los identificadores?
6. ¿Se describe la interfaz de cada módulo?
7. ¿Se utilizan comentarios que aclaren la estructura del código y de los datos?
7. ¿Se establece bien la estructura modular (presumiblemente jerárquica)?
8. ¿Se hace una descripción de la interfaz de cada módulo?
8. ¿Se ha realizado y distribuido el documento de Especificación del diseño?
9. ¿Existen comentarios de prólogo?
9. ¿Se han establecido las estructuras de datos adecuadas al problema?
10. ¿Es el código legible?¿Con la identación adecuada?¿Buen estilo de codificación?
10. ¿La descomposición realizada y su funcionalidad se ajustan a la especificación de los
11. ¿Es comprensible el código?
requerimientos del software?
12. ¿Se utilizan características estándar en la implementación?
11. ¿Se contemplan todas las funciones?
13. ¿Se produce una validación de datos adecuada?
12. ¿Están adecuadamente separadas las representaciones de datos y procedimientos?
14. ¿Es el programa robusto?
13. ¿Se corresponden los algoritmos de diseño detallado con la estructura dada en el
diseño preliminar? 15. ¿Hay un tratamiento de errores adecuado?
14. ¿Se ha especificado el tratamiento de errores? 16. ¿Es el código eficiente?
15. ¿Es adecuado el nivel de detalle del algoritmo con el lenguaje destino de la 17. ¿Se utiliza adecuadamente el espacio en memoria?
implementación? 18. ¿Se usan suficientemente los dispositivos de E/S?
16. ¿Se ha tenido en cuenta la facilidad de mantenimiento? 19. ¿Se corresponde el código con el diseño?
17. ¿La funcionalidad del algoritmo es la adecuada? 20. ¿Se ha revisado la planificación?
18. ¿Ha tenido lugar una revisión de la planificación?
19. ¿Se han nombrado los componentes de los diagramas adecuadamente?
20. ¿Hay un diccionario de datos del diseño?
21. ¿Se han descrito las bases de datos?
22. ¿Faltan/sobran elementos de la especificación de requerimientos?
23. ¿El alcance de control es adecuado?
24. ¿El alcance de efecto es adecuado?
25. ¿Se ha elaborado el manual de usuario?
26. ¿El manual de usuario ha sido supervisado por el usuario?

Organización de Sistemas Informáticos 231 232 Organización de Sistemas Informáticos

7. Prueba
1. ¿Ha tenido lugar un diseño de casos de prueba de unidad para cada módulo?
2. ¿Es completo el conjunto de caminos independientes de prueba?
3. ¿Se han probado todos?
4. ¿Se han diseñado pruebas de bucles?
5. ¿Se ha diseñado un procedimiento de prueba de integración?
6. ¿Se ha especificado un conjunto de casos de prueba para la integración?
7. ¿Se ha diseñado la prueba de validación?
8. ¿Se ha diseñado la prueba del sistema?
9. ¿Se ha diseñado la prueba de recuperación?
10. ¿Se ha diseñado la prueba de seguridad?
11. ¿Se ha diseñado la prueba de resistencia?
12. ¿Se ha diseñado la prueba de rendimiento?

Organización de Sistemas Informáticos 233 234 Organización de Sistemas Informáticos

 ¾ Automatización de un sistema de información

Apéndice VI
Elección de hardware, configuración adecuada de software de base y aplicaciones que
permitan cubrir las necesidades de información que marcan la estructura del Sistema de
Información.

Glosario de Términos 2. Ingeniería de Sistemas

¾ Ingeniería de sistemas basados en computadora

Es un tipo de ingeniería que no se concentra únicamente en el software, sino que se

1. Los Sistemas de Información concentra en una variedad de elementos, analizando, diseñando y organizando esos
elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la
¾ Sistema transformación de información o control de información.

Conjunto de elementos que interaccionan entre sí, que busca conseguir los objetivos
prefijados por la empresa. Un sistema forma parte de un entorno con el cual interactúa.
¾ Información
La información está construida a partir de un conjunto de datos que mantienen una
estructura y que además resulten útiles o significativos. Darse cuenta de que es mejor
calidad de la información que cantidad.
¾ Ingeniería de la información
Es el proceso de ingeniería del software cuando el contexto del trabajo de ingeniería se
enfoca a una empresa; esta ingeniería trabaja para asignar un papel al software de
computadora y para establecer los enlaces que unen al software con un servicio
determinado.
¾ Ingeniería de producto

¾ Calidad de la información
Grado de adecuación de la información a nuestro sistema evitando ambigüedades.
Conjunto de cualidades que además de la capacidad de disminuir la incertidumbre,
ayudan al receptor a tomar la decisión más ventajosa.
Es el proceso de ingeniería del software cuando hay que construir un producto; esta
ingeniería trabaja para asignar un papel al software de computadora y para establecer los
enlaces que unen al software con el producto.
¾ Sistema basado en computadora

¾ Sistema de información
Conjunto formal de procesos que, operando sobre una colección de datos estructurada
según las necesidades de la empresa, recopilan, elaboran y distribuyen la información
necesaria para las operaciones de dicha empresa y para las actividades de dirección y
control correspondientes, es decir, las decisiones, para desempeñar su actividad de
acuerdo a su estrategia de negocio.
¾ Flujo de información
Conjunto de elementos que están organizados para realizar un objetivo predefinido
procesando información, como puede ser:
• Soportar alguna función de negocio.
• Desarrollar un producto que pueda venderse para generar beneficios.
• Un sistema basado en computadora hace uso de: software, hardware, personas, bases
de datos, documentación y procedimientos.

Caudal de información que se transmite de un lugar a otro. Hay dos tipos, vertical y ¾ La jerarquía de la ingeniería de SBC
horizontal.
La jerarquía de sistemas de computadora comprende una colección de métodos para
¾ Dato navegar de arriba abajo y de abajo arriba en la jerarquía. El proceso de la ingeniería de
sistemas de computadora empieza normalmente con una vista global. Es decir, se
Registro de hechos, acontecimientos, transacciones, etc. Materia prima con la que examina el dominio entero de negocio o tecnológico apropiado. La visión global se refina
construimos la información. para enfocarse totalmente en un dominio de interés específico. Dentro de un dominio

Organización de Sistemas Informáticos 235 236 Organización de Sistemas Informáticos


específico, se analiza la necesidad de elementos del sistema (p. e.: información, software,
hardware, personas). Finalmente se inicia el análisis, diseño y construcción del elemento
del sistema deseado. En la parte alta de la jerarquía se establece un contexto muy amplio y
en la parte baja se llevan a cabo actividades técnicas detalladas, realizadas por la
disciplina de ingeniería correspondiente(p. e.: ingeniería hardware o software).
¾ Ingeniería de la información
Persigue definir arquitecturas que permitan a las empresas emplear la información
eficazmente. Se deben analizar y diseñar tres arquitecturas diferentes dentro del contexto
de objetivos y metas de negocio:
• Arquitectura de datos: proporciona una estructura para las necesidades de
información de un negocio o de una función de negocio.
• Arquitectura de aplicaciones: comprende aquellos elementos de un sistema que
transforman objetos dentro de la arquitectura de datos por algún propósito del
negocio.
• Infraestructura de la tecnología: proporciona el fundamento de las arquitecturas de
datos y de aplicaciones. La infraestructura comprende el hardware y el software
empleados para dar soporte a las aplicaciones y datos. Esto incluye computadoras y
redes de computadoras, enlaces de telecomunicaciones, tecnologías de
almacenamiento y la arquitectura diseñada para implementar esta tecnología.
¾ Ingeniería de productos
Consiste en traducir el deseo de un cliente, de un conjunto de capacidades definidas, en
un producto operativo. Para conseguir esta meta se debe crear una arquitectura y una
infraestructura. La arquitectura comprende cuatro componentes de sistema distintos:
software, hardware, personas y datos. La infraestructura de soporte incluye la tecnología
requerida para unir los componentes y la información (documentos, CD ROM, video) que
se emplea para dar soporte a los componentes.
¾ Ciclo de vida del desarrollo de sistemas
Proceso por el que los analistas de sistemas, los ingenieros de software, los
programadores y los usuarios finales elaboran sistemas de información y aplicaciones
informáticas.
¾ Planificación de sistemas
El ámbito de la planificación de sistemas puede ser toda la empresa, una división de la
misma o cualquier otro tipo de sus unidades organizativas. Su propósito es identificar y
establecer las prioridades sobre aquellas aplicaciones de los sistemas de información cuyo
Organización de Sistemas Informáticos 237
desarrollo reporte máximos beneficios para la empresa considerada en su conjunto. Esta
fase indica la relativa madurez del funcionamiento de los sistemas de información.
¾ Analistas de planificación
Profesionales dotados de una formación especial, que deben pensar en la empresa incluso
más que los analistas de sistemas normales. Han de conocer la metodología de
planificación que debe usarse y los resultados que van a obtenerse. Se requiere que
dispongan de una combinación muy especial de habilidades y experiencias, entre las que
se incluyen la gestión de empresas, el análisis y diseño de sistemas, la gestión de datos y
el diseño de redes.
¾ Estudio del cometido de la empresa
Consiste en estudiar la misión de la empresa. Idealmente, el ámbito de la fase de
planificación debería ser toda la empresa, pero este ámbito debe reducirse a un nivel
manejable.
¾ Arquitectura de información
Plan de selección de la tecnología de información y el desarrollo de los sistemas de
información necesarios para apoyar el cometido de la empresa.
¾ Análisis de áreas de empresa
Consiste en evaluar las áreas de empresa que han de identificarse y establecer prioridades
sobre proyectos de desarrollo específicos.
¾ Análisis del sistema
Es un procedimiento necesario para el desarrollo del producto en la ingeniería del
producto que proporciona una visión global. Tiene como finalidad establecer los
requisitos generales del producto y una vez que se conocen estos requisitos asignar
funcionalidad y comportamiento a cada uno de los cuatro componentes software,
hardware, datos y personas. Incluye las siguientes etapas: identificar las necesidades del
cliente; evaluar el concepto del sistema para establecer la viabilidad; realizar un análisis
técnico y económico; asignar funciones al hardware, software, personal, B.D. y otros
elementos del sistema; establecer las restricciones de presupuesto y planificación
temporal y crear una definición de sistema que forme el fundamento de todo el trabajo de
ingeniería subsiguiente.
¾ Identificación de necesidades del cliente
En esta etapa el analista se reúne con el cliente y el usuario final (si es otro distinto al
cliente) con la intención de definir los objetivos del producto y definir las metas
necesarias para alcanzar esos objetivos. Una vez identificadas las metas globales, el
analista evalúa la información suplementaria como puede ser la existencia de tecnología
238 Organización de Sistemas Informáticos

para construir el sistema, que recursos especiales de desarrollo y fabricación serán
necesarios..... En el caso de que el nuevo sistema sea un producto a vender a muchos
clientes, se plantean además otras cuestiones como: ¿Cuál es el mercado potencial del
producto?, ¿cómo es comparativamente este producto con los de la competencia?, ¿qué
posición ocupa este producto en la línea general de producción de la compañía?.
¾ Estudio de viabilidad
Esta etapa es necesaria ya que el desarrollo de un sistema o producto basado en
computadora puede estar plagado de escasez de recursos y de fechas de entrega difíciles.
Por tanto es necesario evaluar la necesidad de un proyecto cuanto antes. Desde el punto
de vista de la viabilidad hay que tener en cuenta: la viabilidad económica, la viabilidad
técnica u operativa, la viabilidad de fechas, la viabilidad legal y las alternativas. Este
estudio de viabilidad debe ser revisado por el jefe de proyecto y por la dirección.
¾ Análisis económico
Determina los costes para el desarrollo del proyecto y los pondera con los beneficios
tangibles e intangibles del sistema.
¾ Análisis técnico
Durante este el analista evalúa los principios técnicos del sistema al mismo tiempo que
recoge información adicional sobre el rendimiento, fiabilidad, características de
mantenimiento y productividad. Este etapa comienza con una viabilidad técnica del
sistema.
¾ Modelización
Consiste en elaborar una o más representaciones gráficas de un sistema. La imagen
resultante representa las necesidades planteadas por los usuarios en tanto a datos, procesos
y redes, desde el punto de vista de la empresa.
¾ Diseño de prototipos.
Acto de construir un modelo de trabajo representativo a escala reducida de las
necesidades de los usuarios con el fin de descubrir o comprobar dichas necesidades.
¾ Especificación del sistema
La especificación del sistema es un documento que sirve como fundamento para la
ingeniería hardware, software, de bases de datos y humana. Describe la función y el
rendimiento de un sistema basado en computadora y las restricciones que gobernarán su
desarrollo.
Organización de Sistemas Informáticos 239
¾ Diseño de sistemas
El dominio que cubre el diseño de sistemas sigue siendo la aplicación de sistemas de
información única de que hablábamos en el análisis de sistemas. Su propósito es diseñar
una solución técnica, de tipo informático, que satisfaga las necesidades de empresa según
han sido especificadas durante el análisis de sistemas.
¾ Implantación de sistemas
El dominio que cubre la implantación de sistemas está definido por los componentes de
tipo tecnológico de la aplicación de sistemas de información que se diseñaron en la fase
anterior. Su propósito es construir y/o ensamblar los componentes técnicos y poner en
funcionamiento el sistema de información nuevo o mejorado.
¾ Pruebas de unidad
Aseguran que los programas de aplicación funcionen de forma adecuada cuando se
prueban de forma aislada con respecto a otros programas de aplicación.
¾ Pruebas de sistema
Aseguran que los programas de aplicación escritos de forma aislada funcionen
adecuadamente cuando se integran en el sistema global.
¾ Soporte de sistemas
El dominio que cubre el soporte de sistemas es el sistema de información puesto en
producción mediante la implantación de sistemas. El propósito del soporte de sistemas es
sostener y mantener el sistema durante el resto de su vida útil.
¾ Ingeniería de los componentes
Es un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de
los componentes del sistema: la ingeniería del software, ingeniería hardware, ingeniería
humana e ingeniería de bases de datos. Cada una de estas disciplinas de ingeniería tomo
una vista de dominio específica, pero es importante resaltar que las disciplinas de
ingeniería deben establecer y mantener una comunicación activa entre ellas. Parte del
papel del análisis de sistemas es establecer los mecanismos de interfaz que permitirán que
esto suceda.
¾ Software
Programas, estructuras de datos y documentación que hacen efectivo el método lógico,
procedimiento o control requerido.
240 Organización de Sistemas Informáticos
 3. La Ingeniería del Software
¾ Hardware
¾ Software
Dispositivos electrónicos que proporcionan capacidad de cálculo y dispositivos
Llamamos software al conjunto de programas, estructuras de datos (que permiten a los
electromecánicos (por ejemplo sensores, motores y bombas) que proporcionan una
programas manipular adecuadamente la información) y documentos (que describen la
función externa.
operación y el uso de programas).
¾ Bases de Datos
¾ Software de sistemas
Colección de información organizada a la que se accede a través del software.
Conjunto de programas que han sido escritos para servir a otros programas (compiladores,
editores, ...)
¾ Documentación
¾ Software de gestión
Manuales, formularios e información descriptiva del empleo y operación del sistema.
Es el software en sistemas de información de gestión (SIG) que acceden a una o más
¾ Actividades cruzadas del ciclo de vida
bases de datos grandes que contienen información comercial (por ejemplo,
procesamiento de transacciones en puntos de venta).
Actividades que se solapan en muchas o todas las fases de todo el ciclo de vida; en
realidad, normalmente se llevan a cabo de forma conjunta durante varias fases del ciclo de
¾ Software de ingeniería y científico
vida.
Es el que utiliza algoritmos complejos de tratamientos numéricos. Otros: CAD,
¾ Investigación de hechos
simulación de sistemas, astronomía, biología molecular, ...
Es el proceso formal que emplea encuestas, entrevistas, reuniones, cuestionarios,
¾ Software empotrado
muestreos y otras técnicas para recoger la información de los sistemas, las necesidades y
las preferencias.
Es el que reside en memoria de sólo lectura y se utiliza para controlar productos y
sistemas de mercados industriales y de consumo.
¾ Estimación
¾ Software de computadores personales
Actividad encargada de calcular el tiempo, el esfuerzo, los costes y las ventajas del
desarrollo de un sistema.
Es el software más común utilizado en los ordenadores personales (procesamiento de
texto, hojas de cálculo, entretenimiento, ...)
¾ Medida
¾ Software de Inteligencia Artificial
Actividad consistente en medir y analizar la productividad y la calidad (y a veces los
costes) de las personas que desarrollan el sistema.
Está basado en el uso de algoritmos no numéricos para resolver problemas complejos para
los que no son adecuados el cálculo o el análisis directo.
¾ Gestión de proyectos
¾ Software de tiempo real
Actividad continuada por la cual el analista planea, delega, dirige y controla el avance de
los proyectos para desarrollar un sistema acorde con los plazos y presupuestos asignados.
Mide, analiza y controla sucesos del mundo real conforme ocurren (por ejemplo:
componentes de adquisición de datos).
¾ Gestión de procesos

Actividad continuada que establece normas para las actividades, los métodos, las
herramientas y los resultados del ciclo de vida.

Organización de Sistemas Informáticos 241 242 Organización de Sistemas Informáticos

 4. Conceptos sobre gestión de proyectos
¾ Ingeniería del software
¾ Modelo de madurez de la capacidad
Disciplina tecnológica y administrativa dedicada a la producción sistemática de productos
Es un modelo desarrollado por el Instituto de Ingeniería del Software, para mejorar en las
de programación, que son desarrollados y modificados a tiempo, y dentro de un
organizaciones su capacidad de desarrollo de software.
presupuesto definido. Es el establecimiento y uso de principios de ingeniería robustos,
orientados a obtener económicamente software que sea fiable y que funcione
¾ Objetivos
efectivamente sobre máquinas reales.
Identifican las metas generales del proyecto sin considerar cómo se conseguirán.
¾ Paradigma de la I.S.
¾ Ámbito
Es un modelo para el proceso de desarrollo del software. Acompaña al proceso, métodos,
herramientas y fases para resolver un problema real.
Identifica los datos primarios, funciones y comportamientos que caracterizan el problema
e intenta abordar estas características de una manera cuantitativa.
¾ Paradigma del prototipo
¾ Soluciones alternativas
Es un proceso que facilita la creación de un modelo del producto a construir.
Una vez identificados los objetivos y el ámbito, se consideran las soluciones alternativas
¾ Ciclo de vida clásico
que permiten a los gestores y a los profesionales seleccionar el mejor enfoque, teniendo
en cuenta todos los factores.
Modelo estructurado en etapas que define los pasos que se han de seguir para la
realización de un proyecto
¾ Tareas estructurales
¾ Técnicas de cuarta generación
Son las que se pueden aplicar a todos los proyectos de software, sin tener en cuenta su
tamaño o complejidad.
Son una serie de herramientas de software que facilitan la especificación. Se orienta hacia
la posibilidad de especificar el software usando formas de lenguaje especializado o
¾ Conjunto de tareas
notaciones gráficas que describan el problema que hay que resolver en términos que los
entienda el cliente. Estas generan el código fuente de forma automática.
Tareas, hitos, entregas, etc., que permiten a las actividades estructurales adaptarse a las
características del proyecto.
¾ Método
¾ Actividades protectoras
Elemento de la I.S. que suministra información para conocer como construir el software.
Abarcan actividades de planificación, análisis, diseño, etc.
Tales como garantía de calidad del software, gestión de la configuración del software y
medición, cubren el modelo de proceso. Son independientes de las estructurales y tienen
¾ Herramienta
lugar a lo largo del proceso.
Componente de la I.S. que sirve de soporte al proceso de producción, proporcionando
¾ Gestores superiores
elementos para la ejecución de los métodos.
Definen los aspectos de negocios que a menudo tienen una significativa influencia en el
¾ Procedimiento
proyecto.
Nexo de unión entre los métodos y las herramientas. Definen la secuencia en la que se
¾ Gestores técnicos del proyecto
deben aplicar los métodos, la información que se requiere, las verificaciones o controles
que ayudan a asegurar la calidad del software y coordinan los cambios y modificaciones
Deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo
sobre el mismo y las guías para establecer su desarrollo.
de software.

Organización de Sistemas Informáticos 243 244 Organización de Sistemas Informáticos

¾ Profesionales
Proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o
aplicación.
¾ Clientes
Especifican los requisitos para la ingeniería del software.
¾ Usuarios finales
Interaccionan con el software una vez que se ha entregado para la producción.
¾ Equipo Descentralizado democrático (DD)
En este tipo de equipos no hay un jefe, sino coordinadores de tareas a corto plazo, las
decisiones se toman por consenso, y la comunicación es horizontal entre los miembros del
equipo.
¾ Equipo Descentralizado concentrado (DC)
Equipo de ingeniería del software que tiene un jefe definido que coordina tareas
específicas y jefes secundarios que tienen responsabilidades sobre subtareas. La
resolución de problemas sigue siendo una actividad del grupo, pero la implementación de
soluciones se reparte entre subgrupos por el jefe de equipo. La comunicación entre
subgrupos e individuos es horizontal. También hay comunicación vertical a lo largo de la
jerarquía de control.
¾ Equipo Centralizado controlado (CC)
Hay un jefe del equipo que soluciona los problemas a alto nivel y que se encarga de la
coordinación interna del equipo, la comunicación es vertical.
¾ Paradigma cerrado
Paradigma de organización de ingeniería del software que estructura a un equipo con una
jerarquía tradicional de autoridad (similar a la del equipo CC). Estos equipos trabajan bien
cuando producen software similar a otros anteriores, pero probablemente sean menos
innovadores.
¾ Paradigma aleatorio
Paradigma de organización de ingeniería del software que estructura al equipo libremente
y depende de la iniciativa individual de los miembros del equipo. Cuando se requiere
innovación o avances tecnológicos, son excelentes. Pueden chocar cuando se requiere un
rendimiento ordenado.
Organización de Sistemas Informáticos 245
¾ Paradigma abierto
Paradigma de organización de ingeniería del software que intenta estructurar a un equipo
de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero
también mucha de la innovación asociada al paradigma aleatorio. El trabajo se desarrolla
en colaboración, con mucha comunicación y toma de decisiones consensuadas. Es
adecuado para la resolución de problemas complejos, pero su rendimiento puede ser
menos eficiente.
¾ Paradigma sincronizado
Paradigma de organización de ingeniería del software que se basa en la división natural de
un problema. Organiza los miembros del equipo para trabajar en partes del problema con
poca comunicación activa entre ellos.
¾ Ámbito del problema
Es la primera actividad de gestión de un proyecto de software, y se define estableciendo el
contexto, los objetivos de información y la función y rendimiento.
¾ Descomposición del problema
Es una actividad que trata de dividir el problema para solucionarlo mejor (divide y
vencerás). Esta descomposición del problema se hace en dos áreas principales:
funcionalidad a entregar y proceso para entregar el producto.
¾ Maduración del problema y el proceso
Se trata de seleccionar el conjunto de actividades estructurales adecuado como por
ejemplo: comunicación con el cliente, planificación, análisis de riesgo, ingeniería,
construcción y entrega, evaluación del cliente.
¾ Modelo de madurez de la capacidad de gestión de personal
Para aumentar la preparación de organizaciones de software para llevar a cabo las cada
vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y
retener el talento necesario para mejorar su capacidad de desarrollo de software.
¾ Conjunto de actividades estructurales
Son aquellas actividades básicas por las que deben pasar todas las funciones que se deben
tratar dentro de un proceso de ingeniería por el equipo de software.
246 Organización de Sistemas Informáticos
5. Planificación de proyectos software y gestión del riesgo ¾ Riesgos de presupuesto

¾ Planificación del proyecto Perder presupuesto o personal asignado.

Conjunto de actividades que conjuntamente forman el proceso de gestión del proyecto ¾ Estrategia de riesgo reactiva
software.
El equipo no hace nada respecto a los riesgos hasta que algo va mal. Después el equipo,
¾ Ámbito del software apresuradamente trata de corregir el problema.

Describe la función, rendimiento, las restricciones, las interfaces y la fiabilidad que deben ¾ Estrategia de riesgo proactiva
conseguir el software a desarrollar.
Se identifican los riesgos potenciales, se valora su probabilidad y se establece una
¾ Riesgos del software prioridad según su importancia. Después el equipo de desarrollo establece un plan para
controlar el riesgo.
El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas
establecidas por recursos, coste y planificación temporal. ¾ Análisis de riesgo

¾ Riesgos técnicos Es una actividad de garantía de calidad del software que se centra en la identificación y
evolución de los riesgos potenciales que puedan producir un impacto negativo en el
Son aquellos que amenazan la calidad y la planificación temporal del software. Identifican software y hacer que falle el sistema completo. Si se pueden identificar pronto los riesgos
problemas potenciales de: diseño, implementación, interfaz, verificación y en el proceso de ingeniería del software podrán especificarse las características de diseño
mantenimiento. del software que permitan eliminar o controlar los riesgos potenciales.

¾ Riesgo de negocio ¾ Riesgos genéricos

Amenazan la viabilidad del software a construir. A menudo ponen en peligro el proyecto Son una amenaza potencial para todos los proyectos de software.
o el producto.
¾ Riesgos específicos de producto
¾ Identificación del riesgo
Sólo pueden identificarse una vez que se tiene una visión clara de la tecnología, personal
Es un intento sistemático para especificar las amenazas al plan de proyecto (estimaciones, y entorno específico del proyecto en cuestión.
planificación temporal, carga de recursos, etc.)

¾ Riesgo de mercado

Construir un producto o sistema excelente que no quiere nadie en realidad.

¾ Riesgo estratégico

Construir un producto que no encaja en la estrategia comercial general de la compañía.

¾ Riesgo de dirección

Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de

personal.

Organización de Sistemas Informáticos 247 248 Organización de Sistemas Informáticos

6. Estimación de costes y plazos ¾ Atributo

¾ Estimación de costes y plazos Cada una de las características que definen el modelo y que estarán ponderadas, esto es,
afectarán a los resultados en más o menos medida, según el modelo.
Consiste en la predicción del coste de un proyecto, así como prever su plazo de
realización. ¾ Proyecto Orgánico

¾ Estimación de expertos Tipo de desarrollo del modelo COCOMO en el que hay pequeños equipos de trabajo que
trabajan en un entorno familiar, desarrollando aplicaciones que ya habían hecho antes. La
Basándose en la experiencia, averiguar cual va a ser el coste del proyecto. Una de las más comunicación es escasa e informal.
utilizadas es la técnica Delphi.
¾ Proyecto Semiseparado
¾ Estimación por analogía
Tipo de desarrollo del modelo COCOMO en el que podemos tener personal con o sin
En función de las similitudes y diferencias con otros proyectos vamos a deducir el coste experiencia, en general los miembros del equipo van a tener una experiencia limitada
de un desarrollo nuevo. relacionada con los sistemas y pueden ser extraños a algunos de los aspectos, no todos,
del sistema que se va a desarrollar.
¾ Estimación por descomposición
¾ Proyecto empotrado
Se descompone el producto en sus componentes o incluso el proyecto en tareas más
sencillas hasta conseguir un nivel de detalle en el que podemos estimar directamente el Tipo de desarrollo del modelo COCOMO en el que se deben operar con grandes
coste de cada una de las subpartes. restricciones. El sistema de software se encontrará fuertemente acoplado con el hardware,
reglas y procedimientos operativos. No es usual que los miembros del equipo de proyecto
¾ Estimación por ecuaciones o modelos de estimación lleguen a alcanzar una gran experiencia en la aplicación particular que se desarrolla.

Fórmulas matemáticas que nos van a relacionar diversos parámetros del proyecto y
algunas condiciones del entorno del proyecto con el coste o el esfuerzo requerido.

¾ Modelos de coste

Proporciona estimaciones directas del esfuerzo o de la duración. La mayoría son modelos

de factores empíricos que cuentan con una parte principal (habitualmente una media del
tamaño del producto) y un cierto número de factores de ajuste. P.e. el modelo COCOMO.

¾ Modelos de restricciones

Muestran las relaciones en el tiempo entre dos o más parámetros de coste (p.e. esfuerzo,
duración y nivel de plantilla). P.e. el modelo SLIM de Putnam.

¾ Modelo COCOMO

Descrito por Boehm. Es un modelo de restricciones que utiliza para sus estimaciones el
tipo de desarrollo y el tamaño del producto para realizar sus estimaciones. Dando lugar a
tres tipos de submodelos: el básico, el intermedio y el detallado.

Organización de Sistemas Informáticos 249 250 Organización de Sistemas Informáticos

 dimensiones de tiempo más probables para las tareas individuales aplicando modelos
7. Planificación temporal y seguimiento del proyecto estadísticos y calcular las limitaciones de tiempo del proyecto.

¾ Planificación temporal ¾ Distribución de esfuerzo

Es una actividad que distribuye el esfuerzo estimado de realización de un proyecto a lo Consiste en la asignación, de forma relativa, de los recursos y tiempo a las distintas fases
largo de la duración de éste asignando el esfuerzo a las tareas de ingeniería del software, del proyecto.
esto es, consiste en planear cuando y como acometer las tareas de un proyecto, haciendo a
su vez una asignación de recursos adecuada para cumplir los objetivos ¾ Conjunto de tareas

¾ Partición Colección de actividades, cuya misión es la de satisfacer las necesidades de los distintos
tipos de proyectos. Han de ser lo más acertadas posible (cumplir su papel de la forma más
Es la división del proyecto en un número de actividades y tareas manejables, brillante) y así alcanzar una calidad alta.
descomponiéndose tanto el producta como el proceso.
¾ Hito
¾ Asignación de tiempos
Punto en el tiempo en el que comprobamos si estamos cumpliendo con ciertos objetivos.
Consiste en asignar a cada tarea un cierto número de actividades y tareas manejables,
descomponiéndose tanto el producto como el proceso.

¾ Red de tareas

Es una representación gráfica del flujo tareas de un proyecto, mostrando en su manera

más simple las principales tareas principales de ingeniería del software

¾ Camino crítico

Son el flujo o cadena de tareas que deben finalizarse según la planificación temporal si se
quiere que el proyecto en general se termine a tiempo y que por tanto determine la
duración del proyecto.

¾ Gráfico Gantt

Es un gráfico de tiempos donde las tareas se colocan en una columna a la izquierda y se

indica la duración de cada tarea mediante barras horizontales.

¾ Plan de proyecto

Es un documento que se produce a la culminación de las tareas de planificación temporal

que proporcionando información básica de coste y planificación temporal que será
empleada a lo largo del proceso de ingeniería del software.

¾ PERT

Técnica de evaluación y revisión de programas. Es una herramienta cuantitativa que

permite al planificador de software determinar el camino crítico, establecer las

Organización de Sistemas Informáticos 251 252 Organización de Sistemas Informáticos

8. Técnicas de planificación temporal ¾ Tiempo pesimista

¾ Diagrama de hitos
El diagrama de hitos es el método más simple para determinar el calendario y es un
cuadro o tabla formado por dos columnas: en la primera se muestran las actividades y en
la segunda se determinan las fechas de finalización.
¾ Diagrama de Gantt
Representa el tiempo máximo en que podría finalizarse la actividad si se dan todas las
circunstancias negativas que podrían darse durante su ejecución.
¾ Tiempo más probable
Representa el tiempo normal de la duración de la actividad suponiendo que hay problemas
en las actividades, pero no aparecen en su totalidad.

El diagrama de Gantt es un diagrama de columnas en forma de barras donde se hace una ¾ Tiempo optimista
referencia cruzada entre las tareas (filas) y los tiempos de duración de cada una de ellas
(columnas). El diagrama de Gantt se puede utilizar para estimar los recursos y el Representa el tiempo mínimo si no aparece ningún problema durante la realización de la
presupuesto en función del tiempo. actividad.

¾ Red de precedencia ¾ Tiempo más próximo

La red es un modelo gráfico que señala las relaciones secuenciales entre los sucesos clave Es el tiempo estimado en que ocurrirá un suceso si las actividades que lo preceden
de un proyecto. comienzan lo más pronto posible.

¾ Actividad ficticia ¾ Tiempo más lejano

Consiste en añadir una actividad de duración cero en una red de precedencia en la que no Es el último momento estimado en que puede ocurrir un suceso sin retrasar la finalización
se cumplen las relaciones de precedencia lineales. Es un pequeño truco para poder realizar del proyecto más allá de su tiempo próximo.
correctamente procesos lineales convergentes.
¾ Holgura de un suceso
¾ Holgura de una actividad
Es la diferencia entre su tiempo más lejano y su tiempo más próximo.
Representa el número de unidades de tiempo que puede atrasarse la realización de la
actividad con respecto al tiempo PERT previsto, sin que aumente la duración del
proyecto.

¾ Técnica PERT

La técnica es un procedimiento que sirve de ayuda en proyectos complejos y que

requieren una cuidadosa planificación, programación y coordinación de diferentes
actividades interrelacionadas.

¾ Matriz de encaminamientos

La matriz de encaminamientos es una matriz cuya dimensión coincide con el número de

actividades en las que se descompone el proyecto.
Sea un elemento Mij entonces, para poder iniciar la actividad i, es necesario que haya
finalizado la actividad j.

Organización de Sistemas Informáticos 253 254 Organización de Sistemas Informáticos

9. Control de calidad del software y gestión de la ¾ Revisión técnica formal

configuración Una revisión técnica formal es una actividad de la garantía de calidad de del software que
es llevada a cabo por los ingenieros del software. Pretende descubrir errores, verificar que
¾ Garantía de calidad del software: el software alcanza sus requisitos, que sigue unos estándares, que sea uniforme y controlar
para que los proyectos sean más manejables.
La garantía de calidad del software es una actividad de protección que se aplica a lo largo
de todo el proceso de la Ingeniería del Software. ¾ Sistema de garantía de calidad

¾ Calidad Un sistema de garantía de la calidad se puede definir como la estructura organizativa,

responsabilidades, procedimientos, procesos y recursos para implementar gestión de la
Conjunto de características de un producto, proceso o servicio que le confieren su aptitud calidad.
para satisfacer las necesidades del usuario.
¾ Sistema de garantía de calidad ISO-9000
¾ Calidad del diseño
ISO-9000 describe los elementos de garantía de calidad en términos genéricos que pueden
Se refiere a las características que especifican los ingenieros del software para un aplicarse a cualquier negocio con independencia de los productos o servicios ofrecidos.
producto.
¾ Sistema de garantía de calidad ISO-9001
¾ Calidad de concordancia
Es el estándar de garantía de calidad que se aplica a la ingeniería del software. El estándar
Es el grado de cumplimiento de las especificaciones de diseño durante su realización. contiene 20 requisitos que deben estar presentes en un sistema de garantía de calidad
Cuanto mayor sea el grado de cumplimiento, más alto será el nivel de calidad de efectiva.
concordancia.
¾ Gestión de la configuración del software
¾ Calidad del software
La gestión de configuración del software es una actividad de autoprotección que se aplica
Concordancia con los requisitos funcionales y de rendimiento explícitamente definidos, a lo largo del proceso de la ingeniería del software, cuya misión es identificar y controlar
con los estándares de desarrollo explícitamente documentados y con las características el cambio, de garantizar que el cambio se implemente adecuadamente y de informar del
implícitas que de todo software desarrollado profesionalmente se espera. cambio a todos aquellos a los que le interese.

¾ Control de calidad ¾ Configuración del software

Conjunto de inspecciones, revisiones y pruebas utilizados a lo largo del ciclo de Se llama así a todos los elementos que componen toda la información producida como
desarrollo para asegurar que cada producto cumple con los requisitos que le han sido parte del proceso de ingeniería del software.
asignados.

¾ Revisiones del software

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

Señalar la necesidad de mejoras en el producto, personas o equipos.
Confirmar las partes del producto en las que no es necesaria una revisión.
Conseguir un producto de una calidad más uniforme.

Organización de Sistemas Informáticos 255 256 Organización de Sistemas Informáticos

 ¾ Nivel de abstracción de datos de vistas
10. Introducción a los Sistemas de Gestión de Bases de
Es el nivel más alto de abstracción y describe sólo parte de la base de datos completa. A
Datos pesar del uso de estructuras más simples en el nivel lógico, queda algo de complejidad,
debido al gran tamaño de la base de datos. Para que la interacción con el sistema se
¾ Sistema de gestión de bases de datos (SGBD) simplifique, se define la abstracción del nivel de vistas. El sistema puede proporcionar
nuevas vistas para la misma base de datos.
Colección de datos interrelacionados y un conjunto de programas para acceder y
manipular dichos datos. ¾ Instancia de una base de datos

¾ Redundancia de datos Colección de información almacenada en la base de datos en un momento particular.

Cuando una misma información está duplicada en diferente lugar. ¾ Esquema de la base de datos

¾ Inconsistencia de datos Diseño completo de la base de datos. Los sistemas de bases de datos tienen varios
esquemas divididos, de acuerdo a los niveles de abstracción que se han visto. En el nivel
Cuando los datos redundantes no coinciden en su valor. más bajo está el esquema físico; en el nivel intermedio está el esquema lógico, y en el
nivel más alto está el subesquema.
¾ Aislamiento de datos
¾ Independencia de datos
Datos dispersos en varios archivos, incluso con distintos formatos.
Es la capacidad para modificar una definición de esquema en un nivel sin que afecte a una
¾ Ligadura de consistencia definición de esquema en el siguiente nivel superior.

Restricción que se le impone a los datos. ¾ Independencia física de datos

¾ Integridad de datos Es la capacidad para modificar el esquema físico sin provocar que los programas de
aplicación tengan que reescribirse.
Cuando los datos no cumplen alguna de las ligaduras de consistencia.
¾ Independencia lógica de datos
¾ Atomicidad
Es la capacidad para modificar el esquema lógico sin causar que los programas de
Propiedad que nos dice que una operación debe realizarse íntegramente o no realizarse. aplicación tengan que reescribirse.
No permite estados intermedios.
¾ Modelo de datos
¾ Acceso concurrente a datos
Colección de herramientas conceptuales para describir los datos, las relaciones de datos,
Cuando varias aplicaciones pueden acceder simultáneamente a los datos. la semántica de los datos y las ligaduras de consistencia.

¾ Nivel físico de abstracción de datos ¾ Modelos lógicos basados en objetos

Es el nivel más bajo de abstracción y describe cómo se almacenan realmente los datos. En Se usan para describir datos en los niveles lógico y de vistas. Se caracterizan por el hecho
el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel. de que proporcionan capacidades estructurales muy flexibles y permiten que las ligaduras
de datos sean especificadas explícitamente.
¾ Nivel lógico de abstracción de datos

Es el segundo nivel más alto de abstracción y describe qué datos se almacenan en la base
de datos y qué relaciones existen entre esos datos.
Organización de Sistemas Informáticos 257 258 Organización de Sistemas Informáticos
¾ Modelo de datos entidad-relación (E-R) ¾ Modelo jerárquico

Está basado en una percepción del mundo real que consta de una colección de objetos Es similar al modelo de redes, en el sentido en que los datos y las relaciones entre los
básicos, llamados entidades, y de relaciones entre estos objetos. datos se representan mediante registros y enlaces, respectivamente. Éste se diferencia del
modelo de redes en que los registros se organizan como colecciones de árboles en lugar
¾ Entidad de grafos dirigidos.

Objeto del mundo real que es distinguible de otros objetos. Las entidades se describen en ¾ Lenguaje de definición de Datos (LDD)
una base de datos mediante un conjunto de atributos.
Lenguaje utilizado para definir el esquema de una base de datos.
¾ Relación
¾ Diccionario de datos
Asociación entre varias entidades.
Archivo que contiene metadatos, es decir, datos acerca de los datos.
¾ Diagrama entidad-relación
¾ Lenguaje de manipulación de datos (LMD)
Diagrama gráfico que se utiliza para expresar la totalidad de estructuras lógicas de una
base de datos. Lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante
el modelo de datos apropiado
¾ Modelo orientado a objetos
¾ LMD procedimientales
Está basado en una colección de objetos. Un objeto contiene valores almacenados en
variables de instancia dentro de ese objeto. Un objeto también contiene fragmentos de Requieren que el usuario especifique qué datos se necesitan y cómo obtener esos datos.
código que operan en el objeto. Estos fragmentos de código se llaman métodos. Los
objetos que contienen los mismos tipos de valores y los mismos métodos se agrupan ¾ LMD no procedimientales
juntos en clases.
Requieren que el usuario especifique qué datos se necesitan, sin especificar cómo obtener
¾ Modelo basado en registros esos datos.

La base de datos se estructura en registros de formato fijo de diferentes tipos. En cada tipo ¾ Consulta
de registro se define un número fijo de campos o atributos, y cada campo tiene
normalmente una longitud fija. Instrucción de solicitud para recuperar información.

¾ Modelo relacional ¾ Lenguaje de consultas

Usa una colección de tablas para representar tanto los datos como las relaciones entre esos Parte de un LMD para la recuperación de información.
datos. Cada tabla tiene varias columnas, y cada columna tiene un nombre único.
¾ Transacción
¾ Modelo de red
Colección de operaciones que se lleva a cabo como una función lógica simple en una
Los datos se representan mediante colecciones de registros y las relaciones entre los datos aplicación de bases de datos. Cada transacción es una unidad de atomicidad y
se representan mediante enlaces, que se pueden ver como punteros. Los registros en la consistencia.
base de datos se organizan como colecciones de grafos dirigidos.

Organización de Sistemas Informáticos 259 260 Organización de Sistemas Informáticos

 11. Sistemas de Bases de Datos en las organizaciones
¾ Administrador de la base de datos
¾ Compartir datos entre unidades funcionales
Persona que se encarga del control centralizado de los datos y de los programas que
Cuando personas en áreas funcionales diferentes comparten un grupo común de datos,
acceden a los datos.
cada cual para sus propias aplicaciones.
¾ Programador de aplicaciones
¾ Sinergia de datos
Son profesionales informáticos que interactúan con el sistema a través de llamadas al
Los datos combinados tiñen más valor que la suma de los datos en archivos por separado.
LMD, que están incluidas en un programa escrito en un lenguaje anfitrión. Estos
programas comúnmente se llaman programas de aplicación.
¾ Base de datos centralizada
¾ Usuarios sofisticados
Bases de datos que está físicamente situada en un único lugar, controlado por una sola
computadora.
Interactúan con el sistema sin programas escritos. En su lugar, ellos forman sus consultas
en un lenguaje de consulta de bases de datos.
¾ Sistema de base de datos distribuida
¾ Usuarios especializados
Está compuesto de varios sistemas de bases de datos operando en los sitios locales y
conectados por líneas de comunicación. Hacen posible la ubicación local de los datos, es
Son usuarios sofisticados que escriben aplicaciones de bases de datos especializadas que
decir, los datos residen en los lugares donde se necesitan con mayor frecuencia.
no son adecuadas en el marco de procesamiento de datos tradicional. Entre estas
aplicaciones están los sistemas de diseño asistido por computadora, sistemas de bases de
¾ Planificación de la base de datos
conocimientos y expertos.
Esfuerzo colectivo estratégico para determinar las necesidades de la organización para un
¾ Usuarios normales
extenso período de tiempo en el futuro.
Son usuarios no sofisticados que interactúan con el sistema mediante la invocación de
¾ Ciclo de vida del desarrollo de base de datos
alguno de los programas de aplicación permanentes que se han escrito previamente.
Incluye:
· Información recolectada para determinar las necesidades de los usuarios.
· El diseño del esquema de la base de datos (estructura lógica) para satisfacer esas
necesidades.
· La selección de un SGBD para dar soporte al uso de la base de datos.
· El desarrollo de programas para utilizar la base de datos.
· Una revisión de las necesidades de información de los usuarios en el contexto de la
base de datos desarrollada.

Organización de Sistemas Informáticos 261 262 Organización de Sistemas Informáticos

12. Comunicación de datos y redes de ordenadores ¾ Detección y corrección de errores

¾ Red de computadoras Capacidad en un sistema de comunicación para detectar y posiblemente corregir los
errores producidos en la transmisión de un mensaje.
Colección interconectada de computadoras autónomas
¾ Control de flujo
¾ Sistema distribuido
Procedimientos que evitan la saturación del destino ante gran cantidad de información
La diferencia con una red de computadoras consiste en que la existencia de múltiples recibida.
computadoras autónomas es transparente al usuario. Es un sistema software construido
sobre una red. ¾ Direccionamiento

¾ Fuente Método para indicar el destinatario de un mensaje. El sistema de transmisión debe

garantizar que ese y sólo ese destino reciba el mensaje.
Dispositivo que genera los datos a transmitir.
¾ Encaminamiento
¾ Transmisor
El sistema de transmisión se encargará de elegir una de las posibles rutas para enviar el
Elemento que transforma y codifica la información produciendo señales mensaje a su destino.
electromagnéticas susceptibles de ser transmitidas a través de algún sistema de
transmisión. ¾ Recuperación

¾ Sistema de transmisión Propiedad del sistema que permite volver a un estado anterior estable ante un fallo en la
transmisión de un mensaje.
Medio por el que se transmite la información entre transmisor y receptor.
¾ Formato de mensajes
¾ Receptor
Conformidad entre fuente y destino en cuanto al formato de los datos intercambiados.
Elemento que acepta la señal que proviene del sistema de transmisión y la convierte de
manera que pueda ser entendida y manejada por el dispositivo destino. ¾ Seguridad

¾ Destino El receptor debe asegurarse que sólo el destino reciba los datos. El destino debe
asegurarse a su vez que los datos proceden del receptor.
Dispositivo que recibe los datos del receptor.
¾ Escalabilidad
¾ Sincronización
Capacidad para incrementar el rendimiento del sistema gradualmente cuando la carga de
Se produce entre receptor y emisor. El receptor debe ser capaz de determinar cuando trabajo crece, añadiendo más procesadores.
comienza y cuando acaba la señal recibida, así como la duración de cada elemento de la
señal. ¾ Red de área local (LAN)

¾ Gestión de intercambio Redes de propiedad privada dentro de un solo edificio o campus de hasta unos cuantos
kilómetros de extensión. Se usan ampliamente para conectar computadoras personales y
Cooperación entre dispositivos. Convenciones en la comunicación. estaciones de trabajo en oficinas de compañías y fábricas con objeto de compartir recursos
(por ejemplo impresoras) e intercambiar información. Las LAN se distinguen de otro tipo
de redes por tres características: Su tamaño, su tecnología de transmisión y su topología.

Organización de Sistemas Informáticos 263 264 Organización de Sistemas Informáticos

 13. Ingeniería del software Cliente/Servidor
¾ Red de área metropolitana (MAN)
¾ Sistema raíz
Es básicamente una versión más grande de una LAN y normalmente se basa en una
Ordenador que actúa como depósito de los datos corporativos en un sistema
tecnología similar. Podría abarcar un grupo de oficinas corporativas cercanas o una ciudad
Cliente/Servidor.
y podría ser privada o pública. Una MAN sólo tiene uno o dos cables y no contiene
elementos de conmutación, lo cuales desvían los paquetes por una de varias líneas de
¾ Sistema Cliente/Servidor
salida potenciales. Al no tener que conmutar se simplifica el diseño.
Sistema en el que ordenadores interconectados actúan como clientes y servidores de
¾ Red de área amplia (WAN)
servicios. Los clientes solicitan servicios que se los proporciona el servidor.
Se extiende sobre un área geográfica extensa, a veces un país o un continente; contiene
¾ Servidor de archivos
una colección de máquinas dedicadas a ejecutar programas de usuario.
El cliente solicita registros específicos de un archivo. El servidor transmite estos registros
¾ Host
al cliente a través de la red.
Cada una de las máquinas que componen una WAN.
¾ Servidor de bases de datos
¾ Subred de comunicación
El cliente envía solicitudes en lenguaje de consulta estructurado (SQL) al servidor. Éstas
se transmiten como mensajes a través de la red. El servidor procesa la solicitud SQL y
Red que interconecta los Hosts.
halla la información solicitada, pasando únicamente los resultados al cliente.
¾ Elementos de conmutación
¾ Servidor de transacciones
Computadoras especializadas que conectan dos o más líneas de transmisión en una
El cliente envía una solicitud que invoca procedimientos remotos en el centro servidor.
subred. También llamados enrutadores.
Los procedimientos remotos pueden ser un conjunto de sentencias SQL. Se produce una
transacción cuando una solicitud da lugar a la ejecución de procedimientos remotos y a la
¾ Subred punto a punto
transmisión del resultado al cliente.
Subred en la que cuando se envía un paquete de un enrutador a otro a través de uno o más
¾ Servidor de grupos de trabajo
enrutadores intermedios, el paquete se recibe completo en cada enrutador intermedio, se
almacena hasta que la línea de salida requerida está libre, y a continuación se reenvía.
Cuando el servidor proporciona un conjunto de aplicaciones que hacen posible la
comunicación entre clientes (y las personas que los usan) mediante el uso de texto,
¾ Interred
imágenes, boletines electrónicos, video y otras representaciones, existe una arquitectura
de grupos de trabajo.
Colección de redes interconectadas
¾ Componente de interacción con el usuario y presentación
¾ Pasarela
Este componente implementa todas las funciones que típicamente se asocian a una
Computador que se encarga de comunicar y traducir los mensajes entre dos redes distintas
interfaz gráfica de usuario (IGU).
de una interred.
¾ Componente de aplicación

Este componente implementa los requisitos definidos por la aplicación en el contexto del
dominio en el cual funciona la aplicación. El software de aplicación se puede

Organización de Sistemas Informáticos 265 266 Organización de Sistemas Informáticos

 descomponer de tal modo que alguno de los componentes residan en el cliente y otros
14. Ingeniería del Software asistida por computadora
residan en el servidor.
¾ Herramienta CASE
¾ Gestión de bases de datos.
Aplicación de tecnología informática a las actividades, las técnicas y las metodologías
propias del desarrollo de sistemas. Son programas que automatizan o apoyan una o más
Este componente lleva a cabo la manipulación y gestión de datos requerida por una
fases del ciclo de vida del desarrollo de sistemas.
aplicación. La manipulación y gestión de datos puede ser tan sencilla como la
transferencia de un registro, o tan compleja como el procesamiento de sofisticadas
¾ CASE de alto nivel
transacciones SQL.
Herramientas que automatizan o apoyan las fases iniciales o superiores del ciclo de vida
¾ Software intermedio
del desarrollo de sistemas (planificación, análisis y diseño)
Consta de elementos de software que existen tanto en el cliente como en el servidor, e
¾ CASE de bajo nivel
incluye elementos de sistemas operativos en red así como un software de aplicación
especializado que presta su apoyo a las aplicaciones específicas de bases de datos, a
Herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida
estándares de distribución de solicitudes de objetos, a tecnologías de trabajo en grupo, a
(diseño detallado de sistemas, implantación y soporte de sistemas).
gestión de comunicaciones, y a otras características que facilitan la conexión
cliente/servidor.
¾ CASE cruzado del ciclo de vida
¾ Diseño de servidor principal
Herramientas que apoyan las actividades que tienen lugar a lo largo de todo el ciclo de
vida, como la gestión de proyectos y la estimación.
Cuando la mayor parte de la funcionalidad se asocia al servidor
¾ Integración CASE
¾ Diseño de cliente principal
Unión de herramientas CASE con el fin de conseguir la máxima automatización del ciclo
Cuando el cliente implementa la mayor parte de los componentes de
de vida del desarrollo de sistemas. No es la simple suma de herramientas, deben cumplir
interacción/presentación con el usuario, de aplicación y de base de datos.
una serie de propiedades específicas.

¾ Entorno de apoyo de proyectos integrados (EAPI)

Distintos fabricantes utilizan una serie de estándares EAPI para construir herramientas
CASE compatibles entre sí.

¾ Capa de interfaz de usuario

Conjunto de herramientas de interfaz estandarizado, con un protocolo de presentación

común.

¾ Kit de herramientas de la interfaz

Software para la gestión de la interacción hombre-máquina, con una biblioteca de objetos

de visualización. Estos proporcionan un mecanismo consistente para la comunicación
entre la interfaz y las herramientas CASE individuales.

Organización de Sistemas Informáticos 267 268 Organización de Sistemas Informáticos

 15. Internet e intranet
¾ Protocolo de presentación
¾ Internet
Conjunto de líneas generales que proporcionan a todas las herramientas CASE un mismo
Colección mundial de redes.
aspecto.
¾ Protocolo TCP/IP
¾ Capa de herramientas
Protocolo de comunicaciones utilizado en Internet.
Contiene un conjunto de servicios de gestión de herramientas, así como las propias
herramientas CASE.
¾ Paquete de datos
¾ Capa de Gestión de objetos (OML)
Unidad de información utilizada por Internet para enviar mensajes a través de la red.
Lleva a cabo las funciones de gestión de la configuración. Proporciona el mecanismo para
¾ Dirección IP
la integración de las herramientas.
Conjunto de cuatro números comprendidos entre 0 y 255 y separados por puntos que son
¾ Capa de depósito compartido
utilizados para direccionar los ordenadores que se encuentran en una red.
Base de datos CASE junto a funciones de control de acceso que permite la interacción de
¾ Correo electrónico
la capa de gestión de objetos con la base de datos.
Medio de comunicación en el que a través de Internet pueden mandarse mensajes a
¾ Depósito CASE
distintos usuarios conectados a la red.
También llamada Base de datos CASE, base de datos del proyecto, diccionario de datos,
¾ Grupos de noticias
etc. Hace referencia al centro donde se almacena la información de CASE.
Foro especializado en el que usuarios con interés común pueden intercambiar mensajes en
Internet.

¾ Sesión remota

Conexión a un ordenador de una red, de manera que pueden ejecutarse aplicaciones en

dichos ordenadores, a través del envío de órdenes por la red. El acceso a estos
ordenadores se realiza a través de cuentas de usuario y contraseñas. Telnet y rlogin son
programas que nos permiten realizar esta tarea.

¾ Transferencia de archivos (FTP)

Aplicación que permite enviar ficheros a través de una red de ordenadores.

¾ World Wide Web

Parte de Internet en la que se consulta información a través de páginas de hipertexto.

Utiliza el lenguaje HTML para producir contenidos y el protocolo http para las
comunicaciones.

Organización de Sistemas Informáticos 269 270 Organización de Sistemas Informáticos

¾ HTML
16. Beneficios de intranet
¾ Eficiencia
Lenguaje que permite el intercambio de documentos independiente de plataformas.
Permite intercalar textos, imágenes, ecuaciones, e hipervínculos a otras páginas de una
Mejora en los mecanismos de intercambio de información, mediante la superación de los
manera sencilla.
obstáculos logísticos que existen para recolectar y diseminar la información necesaria de
una forma precisa con la ayuda de una Intranet.
¾ HTTP
¾ Efectividad
Protocolo de Internet que permite el intercambio de documentos independiente de
plataformas.
Se refiere al impacto organizativo como consecuencia del perfeccionamiento de la
colaboración y la toma de decisiones con la ayuda de una Intranet.
¾ Navegador
¾ Niveles de uso e impacto
Programa que interpreta el lenguaje HTML y visualiza páginas de hipertexto recibidas
mediante el protocolo http. Actualmente poseen múltiples capacidades, como envío de e-
Son una medida de la utilización y beneficios obtenidos con el uso de una Intranet en una
mail, transferencia de ficheros, etc.
empresa.
¾ Intranet
¾ Fragmentación de datos
Red interna y autosuficiente que enlaza múltiples usuarios usando la tecnología Internet.
Cada tipo de dato o cada tipo de información necesita de una aplicación (programa) para
poder consultar o manipularlo.
¾ DNS
¾ Plataforma
Lugar donde se hace una correspondencia de direcciones físicas IP en direcciones lógicas.
Hardware más software específico.
¾ Trabajo en grupo (Groupware)
¾ Coherencia en la operatoria
Es el software necesario para que diversas personas trabajen conjuntamente mediante la
comunicación, la colaboración y la coordinación, de manera que este software (o parte del
Indica que el aspecto y el comportamiento de una aplicación es similar a una familia de
mismo) esté en cada una de las máquinas conectadas a la red.
productos (software).
¾ Información corporativa estática
¾ Automatización del flujo de trabajo
Información estática de una organización. Es la información que cambia con menor
Sustitución de algunos o todos los pasos manuales en un proceso empresarial mediante el
frecuencia y que suele distribuirse en masa por la organización.
uso de transferencias electrónicas.
¾ Datos corporativos
¾ Pista de auditoría
Información de trabajo de una organización. Esta es la base del funcionamiento de la
Información sobre el flujo de trabajo de una empresa que queda registrada (en nuestro
misma y va cambiando y fluyendo de manera continua.
caso mediante medios electrónicos).
¾ Sistema de gestión de documentos
¾ Formularios HTML
Sistema destinado a la gestión documental. Abarca los aspectos de búsqueda/recuperación
Permiten la introducción de datos a través de páginas Web. Es un añadido a la simple
de información, seguridad, control de versión y archivo de información.
visualización de información y nos proporcionan el nivel 2 de uso de una Intranet.

Organización de Sistemas Informáticos 271 272 Organización de Sistemas Informáticos

 17. Intranets en acción
¾ Costes de conversión
¾ Relevancia
Son aquellos asociados con las herramientas, mano de obra y estándares requeridos para
Importancia.
convertir los formatos de información ya existentes a HTML.
¾ Oportunidad
¾ Costes de coordinación
Hace referencia a que si no funciona adecuadamente una Intranet, los usuarios volverán
Son los costes asociados a la coordinación de contenidos de diversos departamentos de
rápidamente a los métodos tradicionales de intercambio de información.
manera que se ajusten a los estándares de aspecto y uso de la Intranet de la empresa.
¾ Actualización
¾ Costes de indexación
La información en una Intranet debe estar actualizada de manera frecuente.
Costes asociados a la indexación periódica de las páginas Web.
¾ Accesibilidad
¾ Seguridad
La información de una Intranet debe ser fácilmente accesible, y de manera rápida.
Protección contra el robo físico, la corrupción o el borrado de información, contra un fallo
del soporte de la información o al acceso no autorizado a la misma.
¾ Barreras
¾ Encriptación
Impedimentos de diversa índole que limitan el acceso a la información de una Intranet, o
que limitan las comunicaciones a través de la misma.
Mecanismo de seguridad que cifra la información para que solo aquellos que posean
cierta clave puedan acceder a la misma.
¾ Comunicaciones internas
¾ Claves públicas
Comunicación entre usuarios que están dentro de la misma Intranet.
Mecanismo de encriptación en la que la información se cifra con una clave pública y se
¾ Comunicaciones externas
descifra con una clave privada.
Comunicación de usuarios que están dentro de una Intranet con usuarios que no lo están.
¾ Autentificación

Mecanismo de seguridad que me permite asegurar que estoy recibiendo o enviando

información al destinatario deseado.

¾ Firma digital

Mecanismo de seguridad que permite asegurar al destinatario la identidad del emisor.

Organización de Sistemas Informáticos 273 274 Organización de Sistemas Informáticos

 Módulo III. Sistemas de Bases de Datos
Bibliografía [Hansen97] Hansen, Gary W.
"Diseño y administración de Bases de Datos"

[Silbers] Silberschatz, A.
“Fundamentos de Bases de Datos”
Ed. McGrawHill

Módulo I. Ingeniería de Sistemas Módulo IV. Sistemas distribuidos y redes

[Stalin97] Stalings, William
[Press98] Pressman, Roger S.
"Comunicaciones y Redes de Computadores"
"Ingeniería del Software. Un enfoque práctico".
Ed. Prentice Hall, 5ª Edición, 1997
Ed. McGraw-Hill. 4ª Edición, 1998
[Tanen] Tanenbaum, A.S.
[Luque99] Luque Ruiz, Irene
“Redes de Computadoras”
"Ingeniería del Software. Fundamentos para el desarrollo de sistemas
Ed.Prentice Hall, 3ª Edición
informáticos".
Ed. Servicio de publicaciones. Universidad de Córdoba, 1999
[Press98] Pressman, Roger S.
"Ingeniería del Software. Un enfoque práctico".
[Whitten96] Whitten, Jeffrey L., et al.
Ed. McGraw-Hill. 4ª Edición, 1998
“Análisis y diseño de sistemas de información”
Ed. IRWIN, 1996
Módulo V. Sistemas de ayuda a la toma de decisiones
Módulo II. Planificación y Gestión de Proyectos [Press98] Pressman, Roger S.
"Ingeniería del Software. Un enfoque práctico".
[Press98] Pressman, Roger S.
Ed. McGraw-Hill. 4ª Edición, 1998
"Ingeniería del Software. Un enfoque práctico".
Ed. McGraw-Hill. 4ª Edición, 1998
[Garret] Garret, D.
“Intranets al descubierto”
[Piatt96] Piattini, M.G.
Ed. PrenticeHall
“Análisis y diseño detallado de aplicaciones informáticas de
gestión”,Ed. Ra-ma, 1996
[Benett] Benett, G.
“Introducción a las Intranets”
[Luque99] Luque Ruiz, Irene
Ed. PrenticeHall
"Ingeniería del Software. Fundamentos para el desarrollo de sistemas
informáticos".
[Tanen] Tanenbaum, A.S.
Ed. Servicio de publicaciones. Universidad de Córdoba, 1999
“Redes de Computadoras”
Ed.Prentice Hall, 3ª Edición

Organización de Sistemas Informáticos 275 276 Organización de Sistemas Informáticos

Bibliografía complementaria:
[Sommer97] Sommerville, Ian
"Software Engineering".
Ed. Addison-Wesley, 5ª Edición, 1997

[Senn92] Senn, James A.

“Análisis y diseño de sistemas de información”
Ed. McGrawHill, 2ª Edición, 1992

[Rivera] Rivera, A.J.

“Redes de Computadores”
Colección de apuntes. Universidad de Jaén

Organización de Sistemas Informáticos 277