Analisis y Diseño de Sistemas

Organizacin de Sistemas Informticos
Aspectos de Anlisis, Planificacin y Gestin de Proyectos

Introduccin a las intranets

Juan Jos Jimnez Delgado
Departamento de Informtica - Universidad de Jan

Organizacin de Sistemas Informticos 1
Prlogo

La Organizacin de Sistemas Informticos es una disciplina muy amplia que
abarca aspectos de Anlisis, Planificacin y Gestin de Sistemas y Proyectos
Informticos. Debido a la gran cantidad de contenidos que se podran tratar y a
la titulacin a la que va dirigida (Organizacin Industrial), en este libro se
intentar realizar una recopilacin de esos aspectos. Esta recopilacin no
profundizar en todos los temas tratados, pues cada uno de ellos sera objeto
de un libro especfico debido a su importancia. Adems, como ya digo, va
dirigido a profesionales no informticos, por lo que no podemos suponer unos
conocimientos que s se exigen en otras disciplinas informticas. El objetivo
primordial de este libro es que sirva de base para la asignatura de Organizacin
de Sistemas Informticos, como una coleccin de apuntes. No obstante, puede
servir de iniciacin en otras asignaturas o bien para dar una visin general de
esta disciplina.

La idea del libro es la de proporcionar a profesionales no informticos los
conocimientos necesarios para analizar, planificar y gestionar un proyecto
informtico. No se espera que realicen labores de analistas de sistemas, sino
que ante un proyecto informtico sean capaces de entender su terminologa,
notaciones y en lneas generales puedan supervisar un proyecto de este tipo.
Adems muchos de los conocimientos adquiridos, como la Planificacin
pueden servir igualmente para el desarrollo de sistemas no informticos.

Los primeros captulos se dedican a la Ingeniera de Sistemas y a la
Planificacin y Gestin de Proyectos. En los siguientes se introduce al lector
en los Sistemas de Gestin de Bases de Datos y en los Sistemas Distribuidos y
Redes, as como su impacto en una organizacin. Los ltimos captulos del
libro se han enfocado a la justificacin y diseo de intranets en empresas,
como sistemas que pueden ayudar a las organizaciones en la toma de
decisiones.

Por ltimo, se han aadido una serie de apndices que complementan y
resumen ciertos aspectos del libro y que pueden servir para repaso o
clarificacin de conceptos.

2 Organizacin de Sistemas Informticos

NDICE:

Prlogo ......................................................................................................................................1
MDULO I. INGENIERA DE SISTEMAS
Captulo 1. Los Sistemas de Informacin ................................................................................13
1. Introduccin .................................................................................................................13
2. Concepto de Sistema....................................................................................................13
3. Concepto de informacin.............................................................................................14
4. Sistemas de Informacin..............................................................................................14
5. Elementos de los Sistemas de Informacin..................................................................15
6. Estructura de los S.I. ....................................................................................................16
7. Aplicacin de las tcnicas informticas a los S.I. ........................................................17
8. Arquitectura de los S.I. ................................................................................................18
Captulo 2. Ingeniera de Sistemas ..........................................................................................21
1. Introduccin .................................................................................................................21
2. Principios para el desarrollo de sistemas .....................................................................21
3. El ciclo de Vida............................................................................................................23
4. Planificacin de Sistemas ............................................................................................24
5. Anlisis de sistemas .....................................................................................................26
6. Diseo de sistemas.......................................................................................................28
7. Implantacin de sistemas .............................................................................................30
8. Soporte de sistemas......................................................................................................32
9. Actividades cruzadas del ciclo de vida ........................................................................34
Captulo 3. La Ingeniera del Software....................................................................................37
1. El Producto...................................................................................................................37
1.1. Evolucin 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 ingeniera del Software. .......................................................................40
2.1. Paradigmas de la I.S..............................................................................................41
2.1.1. Paradigma del ciclo de vida clsico ...............................................................43
2.1.2. Paradigma del prototipo.................................................................................44
2.1.3. Prototipos de necesidades ..............................................................................45
2.2. Tcnicas de cuarta generacin (T4G) ...................................................................46
MDULO II. PLANIFICACIN Y GESTIN DE PROYECTOS
Captulo 4. Conceptos sobre Gestin de Proyectos.................................................................49
1. El espectro de la gestin...............................................................................................49
1.1. Personal.................................................................................................................49
1.2. El Problema...........................................................................................................50
1.3. El Proceso .............................................................................................................51
2. Gestin de Personal......................................................................................................51
3. Identificacin del Problema .........................................................................................54
4. Actividades y tareas de ingeniera de software ............................................................55
4.1. Maduracin del problema y el proceso.................................................................55
4.2. Descomposicin del proceso.................................................................................56

Captulo 5. Planificacin de proyectos software y Gestin del Riesgo ...................................57
1. Objetivos de la planificacin del proyecto...................................................................57
2. mbito del software.....................................................................................................58
3. Recursos.......................................................................................................................58
4. Estimacin del proyecto software ................................................................................59
5. Desarrollo de una estrategia de solucin......................................................................60
6. Anlisis de Riesgo........................................................................................................60
6.1. Identificacin del Riesgo ......................................................................................62
6.2. Proyeccin y evaluacin del riesgo.......................................................................63
6.3. Reduccin, supervisin y gestin del riesgo.........................................................63
7. Gestin de expectativas................................................................................................64
Captulo 6. Estimacin de Costes y Plazos..............................................................................67
1. Introduccin .................................................................................................................67
2. Mtodos de estimacin de costes.................................................................................67
2.1. Juicio de Expertos.................................................................................................68
2.2. Estimacin por analoga........................................................................................68
2.3. Estimacin por descomposicin ...........................................................................69
2.4. Modelos de estimacin .........................................................................................69
3. El modelo COCOMO ..................................................................................................69
3.1. Definiciones y suposiciones previas .....................................................................70
3.1.1. Tipos de proyectos .........................................................................................70
3.1.2. Tamao del Software .....................................................................................70
3.1.3. Otras suposiciones .........................................................................................71
3.2. El modelo bsico...................................................................................................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. Crticas a los modelos de coste ....................................................................................77
5. Beneficios del uso de modelos de coste.......................................................................78
Captulo 7. Planificacin Temporal y Seguimiento del Proyecto............................................79
1. Conceptos bsicos........................................................................................................79
2. Acerca de los retrasos ..................................................................................................80
3. Distribucin de esfuerzo ..............................................................................................80
4. Definicin de tareas .....................................................................................................81
4.1. Red de tareas .........................................................................................................81
5. Planificacin temporal .................................................................................................82
5.1. Grficos de tiempo................................................................................................82
5.2. Seguimiento de la planificacin temporal.............................................................83
6. El Plan de Proyecto......................................................................................................84

Captulo 8. Tcnicas de Planificacin Temporal.....................................................................87
1. Diagrama de hitos ........................................................................................................87
2. Diagramas de Gantt......................................................................................................87
3. Redes de precedencia...................................................................................................89
4. Tcnica PERT..............................................................................................................89
4.1. Representacin de una red PERT..........................................................................90
4.2. Clculo de los tiempos ms prximos (early):......................................................93
4.3. Clculo de los tiempos ms lejanos (late).............................................................94
4.4. Holgura total de una actividad y camino crtico ...................................................95
4.5. El proceso de trabajo con PERT...........................................................................96
4.6. Valoracin del mtodo PERT...............................................................................97
Captulo 9. Control de calidad del Software y Gestin de la Configuracin..........................99
1. Introduccin .................................................................................................................99
2. Conceptos de calidad ...................................................................................................99
2.1. Calidad..................................................................................................................99
2.2. Control de calidad...............................................................................................100
2.3. Garanta de calidad..............................................................................................100
3. Garanta (aseguramiento) de calidad del software.....................................................100
3.1. Actividades de SQA............................................................................................101
4. Revisiones del software .............................................................................................101
5. Revisiones tcnicas formales .....................................................................................101
6. Los estndares de calidad ISO-9000..........................................................................102
6.1. El estndar ISO-9001..........................................................................................102
7. Gestin de configuracin software ............................................................................102
MDULO III. SISTEMAS DE BASES DE DATOS
Captulo 10. Introduccin a los SGBD..................................................................................105
1. Propsito de los Sistemas de Bases de Datos ............................................................105
2. Visin de los datos.....................................................................................................106
2.1. Abstraccin de Datos ..........................................................................................107
2.2. Instancias y Esquemas.........................................................................................107
2.3. Independencia de Datos ......................................................................................108
3. Modelos de Datos ......................................................................................................108
3.1. Modelos lgicos basados en objetos ...................................................................108
3.1.1. Modelo entidad-relacin ..............................................................................108
3.1.2. Modelo orientado a objetos..........................................................................110
3.2. Modelos lgicos basados en registros.................................................................110
3.2.1. Modelo relacional ........................................................................................110
3.2.2. Modelo de red ..............................................................................................111
3.2.3. Modelo jerrquico........................................................................................112
3.3. Modelo de datos fsico........................................................................................112
4. Lenguajes de Bases de Datos .....................................................................................112
4.1. Lenguaje de definicin de datos..........................................................................112
4.2. Lenguaje de manipulacin de datos ....................................................................113
5. Gestin de transacciones............................................................................................113
6. Administrador de la Base de Datos............................................................................114
7. Usuarios de la Base de Datos.....................................................................................114

Captulo 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. Planificacin estratgica de bases de datos................................................................117
2.1. El proyecto de planificacin 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 gestin de control............................................................................119
3.1. Diseo de bases de datos.....................................................................................119
3.2. Formacin 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. Planificacin preliminar......................................................................................122
5.2. Estudio de viabilidad...........................................................................................122
5.3. Definicin de requisitos ......................................................................................122
5.4. Diseo conceptual ...............................................................................................123
5.5. Implementacin...................................................................................................123
5.6. Evaluacin y perfeccionamiento del esquema de la BD.....................................123
MDULO IV. SISTEMAS DISTRIBUIDOS Y REDES
Captulo 12. Comunicacin de datos y redes de ordenadores...............................................127
1. Introduccin ...............................................................................................................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 compaas.........................................................................................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
Captulo 13. Ingeniera del Software Cliente/Servidor..........................................................135
1. Estructura de los sistemas cliente/servidor ................................................................135
2. Componentes de software para sistemas C/S.............................................................136
3. Distribucin de componentes de software .................................................................137
4. Lneas generales para distribuir componentes de aplicaciones..................................137

MDULO V. SISTEMAS DE AYUDA A LA TOMA DE DECISIONES
Captulo 14. Ingeniera del Software asistida por computadora...........................................141
1. Definicin de CASE ..................................................................................................141
2. Niveles de integracin CASE ....................................................................................141
3. Taxonoma de herramientas CASE............................................................................143
4. Entornos CASE integrados ........................................................................................147
5. La arquitectura de integracin....................................................................................148
6. El depsito CASE......................................................................................................150
6.1. El papel del depsito en I-CASE ........................................................................150
Captulo 15. Internet e intranet..............................................................................................153
1. Un poco de Historia de Internet .................................................................................153
2. Cmo funciona Internet .............................................................................................153
3. Aplicaciones en Internet.............................................................................................154
4. La World Wide Web..................................................................................................154
5. El correo electrnico..................................................................................................155
6. Dnde comienza intranet ...........................................................................................155
7. Intranet frente al trabajo en grupo tradicional............................................................156
7.1. Diferencias principales........................................................................................156
7.2. Homogeneidad de los PCs.................................................................................157
7.3. Informacin corporativa esttica bsica..............................................................157
7.4. Datos corporativos ..............................................................................................157
7.5. Comunicacin .....................................................................................................158
7.6. Gestin de documentos .......................................................................................158
Captulo 16. Beneficios de intranet........................................................................................161
1. Introduccin ...............................................................................................................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: visualizacin de informacin 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 informacin......................................................................................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
Captulo 17. Intranets en accin............................................................................................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. Planificacin de intranet ............................................................................................175

APNDICES
Apndice I. Anlisis Estructurado de Sistemas .....................................................................179
1. Conceptos bsicos. .....................................................................................................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 abstraccin en los DFD. .....................................................184
5. Verificacin y Validacin de los DFD.......................................................................186
6. Diccionario de Datos..................................................................................................186
7. Descripcin de Procesos ............................................................................................188
8. El proceso de obtencin de modelos..........................................................................188
8.1. Modelo fsico actual............................................................................................189
8.2. Modelo lgico actual...........................................................................................189
8.3. Modelo lgico nuevo ..........................................................................................190
8.4. Modelo fsico nuevo ...........................................................................................191
Apndice II. Tcnicas de Obtencin de Informacin.............................................................193
1. Introduccin ...............................................................................................................193
2. Clasificacin ..............................................................................................................193
3. Muestreo de documentacin, formularios y archivos existentes ...............................194
4. Investigacin y vistas a instalaciones.........................................................................194
5. Observacin del entorno de trabajo ...........................................................................195
6. La Entrevista ..............................................................................................................196
6.1. Clasificacin .......................................................................................................197
6.2. Plan de entrevistas...............................................................................................198
6.3. Estrategia de entrevista .......................................................................................199
6.3.1. Preparacin ..................................................................................................199
6.3.2. La entrevista.................................................................................................201
6.3.3. Postentrevista ...............................................................................................202
7. Cuestionarios..............................................................................................................202
8. Diseo conjunto de aplicaciones................................................................................204
8.1. Definicin del proyecto.......................................................................................205
8.2. Direccin de una investigacin general previa ...................................................205
8.3. Planificar la sesin DCA.....................................................................................206
8.4. Direccin de la sesin .........................................................................................206
8.5. Presentar los resultados.......................................................................................206
Apndice III. Tareas a realizar en la fase de definicin de un proyecto...............................207
1. Anlisis del sistema....................................................................................................207
1.1. Identificacin de necesidades..............................................................................207
1.2. Estudio de viabilidad...........................................................................................208
1.3. Anlisis econmico.............................................................................................209
1.4. Anlisis tcnico...................................................................................................209
Tareas.........................................................................................................................210
2. Aspectos de Gestin del proyecto..............................................................................211

Tareas.........................................................................................................................211
3. Planificacin del proyecto..........................................................................................212
Tareas.........................................................................................................................212
4. Anlisis de requisitos .................................................................................................214
Tareas.........................................................................................................................214
Apndice IV. Formatos de Documento .................................................................................217
1. Entrevistas..................................................................................................................217
2. Anlisis del Sistema y Planificacin..........................................................................219
3. Plan de Proyecto Software .........................................................................................220
4. Estudio de Viabilidad.................................................................................................221
5. Especificacin de Requerimientos del Software........................................................222
6. Identificacin de la Documentacin...........................................................................224
7. Manual de Usuario.....................................................................................................225
Apndice V. Listas de Inspeccin..........................................................................................227
1. Revisiones..................................................................................................................227
2. Especificacin del Sistema ........................................................................................228
3. Planificacin del Proyecto .........................................................................................229
4. Anlisis de requerimientos del software ....................................................................230
5. Diseo ........................................................................................................................231
6. Codificacin...............................................................................................................232
7. Prueba ........................................................................................................................233
Apndice VI. Glosario de Trminos ......................................................................................235
1. Los Sistemas de Informacin.....................................................................................235
2. Ingeniera de Sistemas ...............................................................................................236
3. La Ingeniera del Software .........................................................................................242
4. Conceptos sobre gestin de proyectos .......................................................................244
5. Planificacin de proyectos software y gestin del riesgo...........................................247
6. Estimacin de costes y plazos....................................................................................249
7. Planificacin temporal y seguimiento del proyecto ...................................................251
8. Tcnicas de planificacin temporal............................................................................253
9. Control de calidad del software y gestin de la configuracin ..................................255
10. Introduccin a los Sistemas de Gestin de Bases de Datos .....................................257
11. Sistemas de Bases de Datos en las organizaciones ..................................................262
12. Comunicacin de datos y redes de ordenadores ......................................................263
13. Ingeniera del software Cliente/Servidor .................................................................266
14. Ingeniera del Software asistida por computadora...................................................268
15. Internet e intranet .....................................................................................................270
16. Beneficios de intranet...............................................................................................272
17. Intranets en accin ...................................................................................................274
Bibliografa.............................................................................................................................275



Mdulo I
INGENIERA DE SISTEMAS


Captulo 1
Los Sistemas de Informacin

1. Introduccin

Actualmente las empresas se enfrentan a un entorno comercial que se va haciendo ms
complejo y difcil. Esto se debe a que el mercado requiere respuestas ms rpidas. 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 consecucin de los objetivos fijados. Para esto debemos contar con la
informacin ms 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
consecucin de un objetivo comn.

Para nuestros propsitos consideramos que un sistema suele estar situado en un entorno o
ambiente con el cual interacta, recibe entradas y produce salidas. Un sistema puede formar
parte de otro sistema ms general, sera 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 sistmico. Se denomina enfoque sistmico a la manera de estudiar o
analizar sistemas adoptando una visin global de los mismos, la cual se va refinando
progresivamente.

3. Concepto de informacin

Un dato est constituido por los registros de los hechos, acontecimientos, transacciones, etc.

La informacin implica que los datos estn 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
informacin. Ms que la cantidad de informacin, importa la calidad de la informacin.

Podemos definir la calidad de la informacin como el conjunto de cualidades que adems
de la capacidad de disminuir la incertidumbre, ayudan al receptor a tomar la decisin ms
ventajosa.

Podemos considerar las siguientes cualidades para la informacin:

- Es relevante para el propsito de la decisin 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 decisin.
- Se comunica a tiempo para que pueda ser til para la decisin.
- Alcanza el nivel de detalle ms adecuado.
- Es comprensible para el receptor.

4. Sistemas de Informacin

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 gestin
contable y la gestin econmica.
2. Comercializar de manera ptima los productos o servicios, esta sera la actividad
comercial y de ventas.
3. Fabricar productos o crear servicios que vender en el mercado, sera la actividad del
departamento de produccin.

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
Informacin de la empresa.

Podemos definir un Sistema de Informacin como:

Un conjunto formal de procesos que, operando sobre una coleccin de datos estructurada
segn las necesidades de la empresa, recopilan, elaboran y distribuyen la informacin (o
parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de

direccin y control correspondientes, es decir las decisiones, para desempear su actividad de
acuerdo a su estrategia de negocio.

El objetivo de un Sistema de Informacin es:

Ayudar al desempeo de las actividades en todos los niveles de la organizacin mediante el
suministro de la informacin adecuada, con la calidad suficiente, dirigida a la persona
adecuada, en el momento y lugar oportuno y con el formato ms adecuado para el receptor.

5. Elementos de los Sistemas de Informacin

Procedimientos y las prcticas habituales de trabajo:
Los tcnicos y directivos marcan unas pautas bsicas para coordinar los distintos
elementos de la compaa. El Sistema de Informacin existe para dar soporte a la
gestin de la informacin.

Informacin:
Debe adaptarse a las personas que manejan el equipo disponible y a los
procedimientos de trabajo de la empresa.

Personas o usuarios:
Individuos o unidades de la organizacin que introducen, manejan o usan la
informacin para realizar sus actividades.

Equipo de soporte:
Realiza la comunicacin, el procesamiento y almacenamiento de la informacin. (un
papel, lpiz, archivador, mquina de escribir, ordenador, ...)

Fig. 1-1. Elementos de los Sistemas de Informacin
INFORMACIN PERSONAL
Procedimientos y
prcticas de trabajo
EQUIPO
Objetivos


6. Estructura de los S.I.

En lneas generales podemos representarlo mediante una pirmide de niveles:
Fig. 1-2. Estructura piramidal del S.I. de la empresa

Operaciones y transacciones:
Procesamiento de actividades diarias (transacciones), acontecimientos rutinarios que
afectan a la organizacin (facturacin, pagos, entrega de productos, ...)

Nivel operativo:
Se realiza un anlisis de los resultados, sobre todo de recursos consumidos en
transacciones, para poder tomar decisiones a corto plazo y de consecuencias limitadas.

Nivel tctico de la direccin:
Se ocupa de la asignacin efectiva de recursos a medio plazo, con el fin de mejorar el
rendimiento de la empresa.

Nivel estratgico:
Trabaja a largo plazo y decide las lneas maestras que debe seguir la empresa en el
futuro. La informacin que se maneja es proporcionada en formatos resumidos y
variados, las decisiones tienen un alto componente subjetivo.

En la empresa se dan dos tipos de flujos de informacin:

Horizontal: Se da entre personas del mismo nivel de autoridad y tiene el propsito
de coordinar responsabilidades compartidas. Se le suele llamar
informacin de coordinacin.

Vertical: Se da entre distintos niveles en la jerarqua. Hay un flujo ascendente,
que consiste en informes de carcter histrico. Y un flujo descendente,
que contiene rdenes, o solicitudes de informacin especfica.

7. Aplicacin de las tcnicas informticas a los S.I.

Para mejorar el rendimiento de un S.I. se suelen incorporar medios informticos. De esta
forma tendremos distintos subsistemas, algunos de los cuales sern S.I. automatizados y otros
manuales.

Fig. 1-3. El sistema de informacin automatizado en el contexto de la empresa

En un S.I. automatizado podemos encontrar distintos niveles de sistemas:

Primer nivel:

Es el ms bajo. Se incluyen en este nivel los subsistemas informticos que pueden dar
soporte a un procesamiento de transacciones. Se le suele llamar tambin operacional
o transaccional.

Segundo nivel:

Formado por los sistemas de informacin para la gestin. Ayudan a los usuarios de
mayor nivel de la empresa a tomar decisiones sobre asuntos de cierta regularidad,
movindose en los niveles operativo, tctico y estratgico de direccin.

Tercer nivel:

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

La automatizacin de un S.I. debe contemplar la eleccin del hardware y la configuracin
ms adecuada de software de base, as como la consecucin de las aplicaciones software que
permitan cubrir las necesidades de informacin que marcan la estructura del S.I.
Organizacin o Empresa
Sistema de Informacin
Sistema de Informacin
automatizado
Sistema Informtico
de Soporte


8. Arquitectura de los S.I.

En lneas generales los S.I. estn formados por una serie de subsistemas:

Subsistema de recursos humanos: (Tabla 1-1)

Encargado de la gestin completa del personal, habilitacin, etc.
Las actividades relacionadas con el personal de las organizaciones podemos
clasificarlos en dos grupos:

- Gestin de personal
- Gestin de nmina

Subsistema de gestin comercial: (Tabla 1-2)

Encargado de la cartera de clientes, y por tanto, de la gestin de ventas.
Las actividades estn orientadas a dos reas:

- Gestin de ventas: conlleva la gestin de pedidos, admisin de pedidos,
facturacin, envo, entrega, etc.
- Gestin de la comercializacin: todo lo relacionado con los pasos previos a
la venta del producto y los pasos posteriores.

Subsistema de gestin contable y financiera:

Encargado del control interno o auditoria de la organizacin, pagos, ingresos, etc.
Las actividades son:

- Control de activos fijos de la organizacin y del inventario como parte de los
mismos.
- Gestin de cobros y pagos.
- Pago de nminas y otros pagos a empleados.
- Generacin de informes contables y financieros que le sean requeridos.

Subsistema de control de almacn: (Tabla 1-3)

Encargado de la gestin de almacn, compras e inventario de existencias (stock)


Tabla 1-1. Subsistema de recursos humanos
Nivel
operativo
Mantenimiento de la informacin histrica laboral, profesional y personal de los empleados.
Inventario de los puestos de trabajo existentes en la empresa y de las caractersticas ms
adecuadas para su desempeo.
Evaluacin de los empleados en funcin de los informes producidos por sus superiores.
Generacin de informes oficiales que son necesarios remitir a la administracin pblica (los
correspondientes Ministerios/Delegaciones de trabajo, hacienda y seguridad social).
Todo lo relacionado con la gestin de nuevas contrataciones de personal.
Generacin de la informacin necesaria para que el subsistema de gestin econmica lleve a cabo
el pago de las nminas, retenciones, etc.
Nivel tctico
Estudio y planificacin de las caractersticas profesionales para ocupar cada uno de los puestos de
trabajo existentes en el organigrama de la organizacin.
Planificacin de las necesidades de recursos humanos en base a la consecucin de los objetivos
de la empresa a corto y medio plazo.
Planificacin del perfeccionamiento y formacin de los empleados de la empresa, en paralelo con
los planes de incentivacin del personal de la misma.
Nivel
estratgico
Realizacin de las tareas del nivel tctico bajo una perspectiva de medio y largo plazo.

Tabla 1-2. Subsistema de gestin comercial
Nivel
operativo
Gestin de la cartera de clientes, con la correspondiente captacin de nuevos clientes y
mantenimiento de los existentes, mediante la programacin de visitas, preferencias e historial de
los mismos con la empresa, e informacin econmica y de crdito sobre los mismos.
Consultas sobre las caractersticas y disponibilidad de los productos de la organizacin.
La gestin de la distribucin y venta de los productos, es decir, los pedidos, envos, entregas,
recepciones, etc., as como la gestin de los documentos que generan estas actividades y su
remisin a los departamentos correspondientes.
Nivel tctico
El estudio de toda la informacin 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 campaas u operaciones comerciales de la organizacin.
El estudio y gestin de las campaas o actividades de preventa, realizando las campaas de
publicidad y promocin de los productos, as como el estudio del mercado y posibles
competidores.
El estudio de los precios de los productos y las vas de distribucin y venta de los mismos.
Nivel
estratgico
En este nivel, trabajando a aos vista, se realizan estudios y planificaciones de marketing y
distribucin de los productos, estudiando el mercado y los diferentes sectores dentro del mismo
sobre los que se pueda actuar, realizando predicciones de nuevos productos y sus posibles ventas.

Tabla 1-3. Subsistema de control de almacn
Nivel
operativo
Las compras de materias primas y, por tanto, la gestin de pedidos a proveedores en funcin de
las existencias.
La recepcin de las materias primas, verificacin con respecto a los pedidos, control del estado
de los envos y actualizacin de existencias en el almacn.
Suministro de los productos a los departamentos de produccin y ventas, para su remisin a los
clientes de los mismos (en base a pedidos) y fabricacin, con las correspondientes actualizaciones
de las existencias en el almacn.
Nivel tctico
La toma de decisiones para obtener una gestin ptima del almacn en base a un volumen de
almacn que, a gasto mnimo, no afecte a los dems departamentos. En este sentido se tienen que
prever las cantidades mnimas de stock que permiten no interrumpir los procesos de ventas y
produccin.
Nivel
estratgico
A este nivel no influye demasiado el subsistema de almacn debido a que el inventario de los
productos o, mejor dicho, el mantenimiento del mismo no es una actividad que influya en gran
medida sobre las previsiones a largo plazo. En este sentido, el subsistema de almacn se ve
influido por las estrategias o polticas generales de la empresa sobre otros subsistemas.


Captulo 2
Ingeniera de Sistemas

1. Introduccin

La estructura bsica para el diseo de los sistemas de informacin viene dada por el
denominado ciclo de vida del desarrollo de sistemas. Un sistema de informacin debe
elaborarse cuidadosamente, para implantar un buen sistema de informacin es necesario
aplicar una serie de principios bsicos esenciales que veremos a continuacin. Aplicando este
mtodo aumentaremos las posibilidades de conseguir el xito en nuestro cometido.

A continuacin 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 informacin y aplicaciones informticas.

Estamos ante una herramienta de gestin de proyectos aplicada a proyectos de desarrollo de
sistemas. Esta herramienta se rige por una serie de principios generales que deberan aplicarse
al desarrollo de sistemas, vemoslos a continuacin.

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 elaboracin de un sistema que puede no resultar prctico, o
que realmente no es el sistema solicitado. Adems es necesaria una buena comunicacin entre
el equipo de desarrollo y los usuarios finales, de manera que no se produzcan equvocos, o
por lo menos traten de minimizarse. Para ello puede utilizarse una poltica de formacin de
los usuarios, de manera que estos se familiaricen a su vez con el nuevo sistema (informtico)
y stos no sean reticentes al cambio que se les avecina.

Principio 2. Aplicar un mtodo de resolucin de problemas:

El ciclo de vida del desarrollo de sistemas en si un mtodo de resolucin de problemas para
fabricar sistemas. El analista de sistemas debe emprender todos los proyectos por medio de la
aplicacin de algn tipo de mtodo de resolucin de problemas.

Principio 3. Definir fases y actividades:

La mayor parte de los ciclos de vida se dividen en fases. Bsicamente constan de:
planificacin de sistemas, anlisis de sistemas, diseo de sistemas, implantacin de sistemas y
soporte de sistemas. Cada una de estas fases representa una inversin 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 documentacin:

En una organizacin dedicada al desarrollo de sistemas no sera deseable que cada trabajador
o grupo adoptara su propio ciclo de vida y normas para el desarrollo de un sistema particular,
sino que la organizacin 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.

Adems es necesario extender esta poltica a las normas de documentacin. La
documentacin 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 comunicacin 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 solucin debemos evaluar la viabilidad de cada una, sobre todo la econmica.

Principio 6. Revisin 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 mtodo de control progresivo, pueden definirse
mltiples puntos de comprobacin 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 debera considerar:

1. La cancelacin del proyecto si ha dejado de ser viable.
2. La reevaluacin 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 vencers:

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, ms
fciles de comprender, ms manejables, podemos construir sistemas mayores.


Principio 8. Disear sistemas cambiantes:

Suele darse la situacin de que se diseen sistemas que satisfacen las necesidades de los
usuarios para hoy. Esta prctica 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 diseo del sistema. Esto no
tiene que ser as, pues existen tcnicas y herramientas que hacen posible el diseo 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 continuacin ir profundizando en cada una de sus fases.

1. Planificacin de sistemas: El mbito de la planificacin de sistemas puede ser toda la
empresa, una divisin de la misma o cualquier otro tipo de sus unidades organizativas.
Su propsito es identificar y establecer las prioridades sobre aquellas aplicaciones de
los sistemas de informacin cuyo desarrollo reporte mximos beneficios para la
empresa considerada en su conjunto. Esta fase indica la relativa madurez del
funcionamiento de los sistemas de informacin.

2. Anlisis de sistemas: El dominio cubierto por el anlisis de sistemas es una nica
aplicacin de sistemas de informacin. Su propsito es analizar el problema o la
situacin de empresa de que se trate y, entonces, definir las necesidades de la empresa
con respecto a la creacin o el perfeccionamiento de un sistema de informacin. Las
necesidades de empresa no implican obligatoriamente una solucin de tipo
informtico.

3. Diseo de sistemas: El dominio que cubre el diseo de sistemas sigue siendo la
aplicacin de sistemas de informacin nica de que hablbamos en el anlisis de
sistemas. Su propsito es disear una solucin tcnica, de tipo informtico, que
satisfaga las necesidades de empresa segn han sido especificadas durante el anlisis
de sistemas.

4. Implantacin de sistemas: El dominio que cubre la implantacin de sistemas est
definido por los componentes de tipo tecnolgico de la aplicacin de sistemas de
informacin que se disearon en la fase anterior. Su propsito es construir y/o
ensamblar los componentes tcnicos y poner en funcionamiento el sistema de
informacin nuevo o mejorado.

5. Soporte de sistemas: El dominio que cubre el soporte de sistemas es el sistema de
informacin puesto en produccin mediante la implantacin de sistemas. El propsito
del soporte de sistemas es sostener y mantener el sistema durante el resto de su vida
til.


Fig. 2-1. Fases del Ciclo de Vida

4. Planificacin de Sistemas

La funcin planificacin de sistemas del ciclo de vida pretende sealar y establecer
prioridades sobre aquellas tecnologas y aplicaciones que producirn un beneficio mximo
para la empresa.

La planificacin de sistemas es un proceso permanente. Debe repetirse regularmente para
asegurar:

1. Que los sistemas de informacin se desarrollan conforme el plan.
2. Que las decisiones de los directivos o los factores externos no han cambiado el plan.

Esta fase podemos dividirla en tres tareas:

1. Estudio del cometido de la empresa

Consiste en estudiar la misin de la empresa. Idealmente, el mbito de la fase de
planificacin debera ser toda la empresa, pero este mbito debe reducirse a un
nivel manejable.

Los analistas de planificacin son profesionales dotados de una formacin
especial, que deben pensar en la empresa incluso ms que los analistas de sistemas
normales. Han de conocer la metodologa de planificacin que debe usarse y los
resultados que van a obtenerse. Se requiere que dispongan de una combinacin
muy especial de habilidades y experiencias, entre las que se incluyen la gestin de
empresas, el anlisis y diseo de sistemas, la gestin de datos y el diseo de redes.

La misin 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 trminos de:

- clientes
- productos y servicios
- recursos materiales
- recursos humanos
- lugares geogrficos de operacin
- estructuras y filosofa de gestin
- metas y objetivos corporativos
- restricciones de empresa
- factores crticos de xito de la empresa
- otros criterios propios de la gestin

El producto obtenido son los planes de empresa. En el mejor de los casos, estos
planes ya existen, y esta fase tan slo los traduce a trminos o formatos tiles para
los propietarios de sistemas y analistas de planificacin en posteriores fases de la
planificacin.

2. Definir una arquitectura de informacin

Una arquitectura de informacin es un plan de seleccin de la tecnologa de
informacin y el desarrollo de los sistemas de informacin necesarios para apoyar
el cometido de la empresa.

Las entradas a esta fase sirven para construir la arquitectura de informacin,
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 informticas 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
redisearse procesos de empresa y/o sistemas de informacin.
- Una arquitectura de Personas necesaria para desarrollar y apoyar la
gestin de bases de datos, redes y aplicaciones.

- Una arquitectura de Tecnologa que identifique las tecnologas de
informacin que deberan utilizarse en las aplicaciones, y posiblemente en
el desarrollo de aplicaciones.

3. Anlisis de reas de empresa

Consiste en evaluar las reas de empresa que han de identificarse y establecer
prioridades sobre proyectos de desarrollo especficos.

Fig. 2-2. Fases de Planificacin del Sistema

5. Anlisis de sistemas

El Anlisis de Sistemas es el estudio de un sistema actual de empresa y de informacin, y la
definicin de las necesidades y las prioridades manifestadas por los usuarios para la
construccin de un nuevo sistema de informacin.

Veamos las fases en las que podemos dividir el Anlisis 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:

- La identificacin de usuarios, gestores y patrocinadores
- La deteccin de los problemas, las oportunidades y las normas que se
perciben.
- La identificacin de cualquier tipo de restriccin tcnica o de empresa y las
soluciones o expectativas posibles o percibidas

Una vez dada esta informacin, el analista evaluar la viabilidad inicial del mbito
del proyecto.

A raz 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 anlisis del sistema actual

Esta fase proporciona al analista de sistemas una comprensin ms profunda de
los problemas, oportunidades y/o normas que impulsan los proyectos. En la
prctica, el analista descubre con frecuencia nuevos problemas y oportunidades.
Durante el estudio es necesario descubrir las causas y efectos de los problemas, las
oportunidades y las normas.

Si el proyecto prosigue a la siguiente fase, el analista debera definir los nuevos
objetivos del sistema que han de transmitirse a la fase siguiente.

3. Definir las necesidades de los usuarios y establecer prioridades

Tambin denominada fase de definicin. En ella el analista se acerca a los
usuarios para informarse de lo que necesitan o buscan en el nuevo sistema. Lo
principal es especificar estas necesidades sin expresar alternativas informticas y
detalles de tecnologa, definiendo el qu y no el cmo.

Estas necesidades, recogidas mediante diversas tcnicas, como entrevistas, deben
ser traducidas a un modelo que represente el sistema. Este mtodo se denomina
modelizacin y consiste en elaborar una o ms representaciones grficas 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.

Otro mtodo para traducir y validar las necesidades es el diseo de prototipos.
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
necesidades.


Fig. 2-3. Fases de anlisis de sistemas.

6. Diseo de sistemas

Una vez conseguido un conocimiento razonable de las necesidades de los usuarios, los
analistas de sistemas pueden centrar su atencin en el diseo de sistemas. Es durante el diseo
de sistemas cuando los analistas de sistemas empiezan finalmente a estudiar las cuestiones y
los detalles tecnolgicos; en otras palabras, en cmo se implantar el sistema.

El diseo de sistemas evala las soluciones alternativas y especifica la solucin detallada de
tipo informtico. Tambin recibe el nombre de diseo fsico.

A su vez esta en esta fase podemos distinguir distintas etapas:

1. Elegir una propuesta de diseo

La primera fase del diseo de sistemas tiene la finalidad de elegir una propuesta de
diseo viable. Implcita en esta fase est la necesidad de identificar en primer lugar
las soluciones de diseo candidatas.
Despus de definir las soluciones candidatas, se evaluar cada una de ellas de
acuerdo a los siguientes criterios:

- Viabilidad tcnica.
Es prctica la solucin desde un punto de vista tcnico? Tienen las
personas que participan los conocimientos tcnicos suficientes para disear
y llevar a trmino esta solucin?


- Viabilidad operativa.
Satisfar la solucin las necesidades de los usuarios? En qu medida?
Cmo har cambiar la solucin el entorno de trabajo del usuario? Qu
opinan los usuarios de la solucin?

- Viabilidad econmica.
Es rentable la solucin en lo que se refiere a costes?

- Viabilidad de fechas.
Puede la solucin disearse 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 decisin
final.

Las siguientes fases dependen de esa decisin, y se realizar una combinacin de
las siguientes acciones:

- Adquirir el hardware y/o software necesario.
- Disear un sistema y su software.

2. Adquirir el hardware y el software necesarios

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. Diseo e integracin del nuevo sistema

Una vez aprobada la solucin viable de la fase de seleccin, podr finalmente
disearse e integrase el nuevo sistema. Se conocern cules son las necesidades,
gracias a la fase de definicin, y cmo se piensan satisfacer dichas necesidades,
gracias a la fase de seleccin. El producto final obtenido es una relacin de diseo
tcnico que se divide frecuentemente en dos partes: diseo general y diseo
detallado.

- El diseo general acta como un esquema del diseo global
- El diseo detallado se centra en las especificaciones detalladas de los
componentes de dicho esquema.


Fig. 2-4. Fases de diseo del sistema

7. Implantacin de sistemas

La implantacin de sistemas es la construccin del nuevo sistema y el paso de dicho sistema
a produccin.

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 aplicacin requiere la elaboracin de
redes y bases de datos nuevas o mejoradas, stas deben implantarse antes de
escribir o instalar los programas informticos. Esto se debe a que los programas de
aplicacin utilizan dichas redes y bases de datos.

2. Construir y probar los programas

Esta fase es slo aplicable a los componentes de software que se haya decidido
escribir, no comprar. Por otra parte, puede ser necesario tambin escribir
programas mejorados que amplen un paquete de software comprado.

Las pruebas de unidad aseguran que los programas de aplicacin funcionen de
forma adecuada cuando se prueban de forma aislada con respecto a otros
programas de aplicacin.

3. Instalar y probar el nuevo sistema

No es raro que programas que funcionen correctamente por s solos fallen cuando
se combinan con otros programas relacionados. Por este motivo es necesario, tras
instalar los programas, realizar las llamadas pruebas de sistema.

Las pruebas de sistema aseguran que los programas de aplicacin escritos de
forma aislada funcionen adecuadamente cuando se integran en el sistema global.

En esta fase tambin se instalan los paquetes de software comprados o alquilados.
Estos paquetes deberan ser probados para asegurar su correcta interaccin con
otros programas y paquetes.

4. Entrega del sistema

Debe procurarse una transicin suave entre el antiguo sistema y el nuevo, para ello
el analista debe ayudar a los usuarios a resolver diversos problemas, como el
arranque del sistema, a formarlos, proporcionarle manuales y el modo de cargar
los archivos y bases de datos.

Fig. 2-5. Fases de Implantacin del sistema

8. Soporte de sistemas

El soporte de sistemas es el mantenimiento continuado de un sistema despus de que haya
sido puesto en funcionamiento. Ello incluye el mantenimiento de programas y las mejoras del
sistema.

Las actividades de soporte no se llevan a cabo secuencialmente. Podemos verlas a
continuacin:

1. Correccin de errores

Una vez puesto en funcionamiento el sistema, es inevitable que falle de cuando en
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.

2. Recuperacin del sistema

Un fallo del sistema puede provocar la mala terminacin de un programa o la
prdida de datos. Este hecho puede deberse a un error humano o a un fallo del
hardware o del software. Los usuarios notifican al analista la cada 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. Adems el
analista vigila el sistema y el trabajo de los usuarios.

4. Adaptacin 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 anlisis, diseo e implantacin adecuadas.
Si la necesidad de mejoras se debe a nuevos problemas o requisitos, el analista
debe volver a las fases de anlisis del sistema. Si se debe al uso de nuevas
tecnologas o problemas tcnicos, el analista ha de volver a las fases de diseo
apropiadas. Si simplemente se perfecciona el sistema, el analista enviar
directamente los cambios de perfeccionamiento a las fases de implantacin del
sistema.


Fig. 2-6. Fases de Soporte del sistema


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 investigacin de hechos, la documentacin y las presentaciones,
las estimaciones y medidas, el anlisis de viabilidad, la gestin de proyectos y las gestin de
procesos. Examinaremos brevemente cada una de estas actividades a continuacin.

Investigacin de hechos:

Es el proceso formal que emplea encuestas, entrevistas, reuniones, cuestionarios, muestreos y
otras tcnicas para recoger la informacin de los sistemas, las necesidades y las preferencias.

La investigacin de hechos es crucial en las fases de planificacin de sistemas y anlisis 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.

Documentacin y presentaciones:

Las tcnicas de comunicacin son esenciales para terminar con xito un proyecto. Existen dos
formas habituales de comunicacin durante los proyectos de desarrollo de sistemas:
documentacin y presentaciones:

- La documentacin es una actividad consistente en registrar los hechos y las
especificaciones de un sistema.
- Las presentaciones son actividades relacionadas consistentes en el envo formal de la
documentacin para su revisin por los usuarios y los directivos interesados.

El control de versiones de la documentacin consiste en el almacenamiento y seguimiento de
mltiples versiones de la documentacin de un sistema.

Estimacin y medida:

Normalmente se realizan actividades de estimacin y medida para estudiar la calidad y la
productividad de los sistemas, sobre todo debido a que los sistemas de informacin suponen
importantes inversiones de capital.

La estimacin 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.

Anlisis de viabilidad:

La viabilidad es la medida de las ventajas que el desarrollo de un sistema de informacin
podra proporcionar a una organizacin.

El anlisis 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.

Gestin 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 informacin que han de
trabajar conjuntamente.

La gestin 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 gestin de procesos es una actividad continuada que establece normas para las
actividades, los mtodos, las herramientas y los resultados del ciclo de vida.


Captulo 3
La Ingeniera del Software

1. El Producto

Hoy en da el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehculo
para hacer entrega de un producto.

- Como producto: es un transformador de informacin: produce, gestiona, adquiere, modifica,
muestra o transmite informacin.

- Como vehculo: es utilizado para hacer entrega del producto, el software acta como la base
de control del ordenador (S.O.), la comunicacin de informacin (Redes), y
la creacin y control de otros programas (herramientas software y entornos).

El software hace entrega de un producto muy importante, la informacin.

1.1. Evolucin del software

Fig. 3-1. Grfico temporal de la evolucin del software

Primera era: - El software era un arte, para su desarrollo haba pocos mtodos
sistemticos.
- No exista una planificacin.
- El software como producto (a ser vendido y distribuido) estaba en la infancia.
- El anlisis, diseo, codificacin, depuracin y ejecucin estaba centralizado
en una sola persona.

Segunda era: - Surge la multiprogramacin y los sistemas multiusuario.
- Se desarrolla el software de tiempo real.
- Surge la primera generacin de sistemas de gestin de Bases de Datos.
- Establecimiento del software como producto.
Primera era
Segunda era
Tercera era
Cuarta era
1950 1960 1970 1980 1990 2000

Tercera era: - Sistemas distribuidos
- Hardware de bajo coste (microprocesadores y PCs).
- Impacto en el consumo.

Cuarta era: - Sistemas personales potentes.
- Entornos descentralizados, cliente/servidor.
- Redes de computadoras.
- Computacin en paralelo.
- Sistemas expertos.

1.2. El Software

Definicin informal: el software es:

1. Instrucciones (programa) que cuando se ejecutan proporcionan la funcin y el
rendimiento deseados.
2. Estructuras de datos que permiten a los programas manipular adecuadamente la
informacin.
3. Documentos que describen la operacin y el uso de programas.

Caractersticas del Software:

Cuando se construye hardware (u otro producto), el proceso creativo humano (anlisis,
diseo, construccin, prueba) se traduce finalmente en una forma fsica.

El software es un elemento del sistema que es lgico y tiene unas caractersticas
particulares:

- El software se desarrolla, no se fabrica en un sentido clsico.
Los costes del software se encuentran en la ingeniera.

- El software no se estropea. No es susceptible a los males del entorno que hace que
el hardware se estropee.

Fig. 3-2. Curvas del ndice de fallos del hardware y del software

El software se deteriora. El software sufre cambios (mantenimiento), se
introducen nuevos fallos.

El mantenimiento del software es ms complejo que el del hardware. Si
un componente hardware se estropea se reemplaza. Pero no hay piezas de
repuesto para el software.

- La mayora 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 gestin de archivos, S.O.
Se caracterizan por su fuerte interaccin con el hardware.

- Software de tiempo real: mide / analiza / controla sucesos del mundo real conforme
ocurren.

- Software de gestin: procesa informacin comercial; sistemas de nminas, cuentas de
haberes/dbitos, inventarios. Estas aplicaciones reestructuran los datos existentes para
facilitar las operaciones comerciales o gestionar la toma de decisiones.

- Software de ingeniera y cientfico: utilizan algoritmos complejos de tratamiento
numrico.

- Software empotrado: reside en memoria de slo 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 clculo,
multimedia, juegos, gestin de B.D., aplicaciones de negocios y personales, etc.

- Software de Inteligencia Artificial: hace uso de algoritmos no numricos para resolver
problemas complejos para los que no son adecuados el clculo o el anlisis directo.
El rea ms activa de la I.A. es la de los sistemas expertos.

1.4. Problemas relacionados con el Software.

- La construccin de programas no alcanza a la demanda.
- Dependencia de la operacin fiable del software.
- Construccin de software fiable y de alta calidad.

Para resolver estos y otros problemas, surge la ingeniera del Software.


2. El Proceso: La ingeniera del Software.

Definicin previa de Ingeniera del Software (I.S.):

Una disciplina tecnolgica y administrativa dedicada a la produccin sistemtica de
productos de programacin, que son desarrollados y modificados a tiempo, y dentro de un
presupuesto definido.

De esta definicin se pueden extraer los siguientes objetivos de la I.S.:

- Construir software de calidad.
- Aumentar la productividad del proceso de desarrollo.
- Mejorar la satisfaccin personal de las personas implicadas.
- Disminuir los costes de produccin.
- Disminuir los costes de mantenimiento.

La I.S. es una disciplina que tiene en cuenta tanto los aspectos tcnicos como los
administrativos del proceso de desarrollo de software, no es solo programacin, esta es una
tarea ms dentro del proceso.

Definicin de Ingeniera del Software:

El establecimiento y uso de principios de ingeniera robustos, orientados a obtener
econmicamente software que sea fiable y que funcione efectivamente sobre mquinas
reales.

La I.S. incluye o est formada por tres elementos que se interrelacionan entre s:

- Mtodos: Suministran informacin para conocer como construir el software.
Abarcan actividades de planificacin, anlisis, diseo, etc.

- Herramientas: Sirven de soporte al proceso de produccin, proporcionando
elementos para la ejecucin de los mtodos.

- Procedimientos: Son el nexo de unin entre los mtodos y las herramientas.
Definen la secuencia en la que se deben aplicar los mtodos, la
informacin 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 guas para
establecer su desarrollo.


2.1. Paradigmas de la I.S.

Son modelos para el proceso de desarrollo del software. El gestor del proyecto elige el ms
adecuado basndose en la naturaleza del proyecto a desarrollar.

Cualquiera que sea el paradigma o combinacin de ellos utilizado, el desarrollo de software
comprende tres etapas genricas, cada una compuesta de una serie de actividades:

Fig. 3-3. Etapas genricas del desarrollo de software

- Fase de definicin: se centra en el qu; intenta identificar:

La informacin que ha de ser procesada.
La funcin y el rendimiento deseado.
Las interfaces.
Las restricciones de diseo.
Los criterios de validacin para definir un sistema software correcto.

Se realizan tres actividades genricas:

- Anlisis del Sistema: se define el papel de cada elemento de un sistema
informtico, asignando finalmente al software el papel a desempear.

- Planificacin del proyecto: se realiza:

Una vez establecido el mbito del proyecto, un anlisis de riesgo.
Asignacin de recursos.
Estimacin de costes.
Definicin de tareas a desarrollar.
Planificacin del trabajo.


- Anlisis de requisitos: se realiza una descripcin detallada de:

El mbito del software,
De la informacin requerida,
De su procesamiento, y
Del objetivo buscado.

- Fase de Desarrollo: se centra en el cmo:

Disear las estructuras de datos.
Disear la estructura y arquitectura del software.
Traducir la especificacin con un lenguaje de programacin.
Verificar el producto construido.

Actividades:

- Diseo de software: Traducir las especificaciones del anlisis de requisitos a
un conjunto de representaciones que describan la estructura de los
datos, la arquitectura, el procedimiento algortmico y las
caractersticas de la interfaz.

- Codificacin: Se traducen las especificaciones del diseo a una
especificacin entendible por la computadora.

- Prueba: La especificacin mquina obtenida debe ser probada para intentar
descubrir los defectos tanto de funcionalidad, como en la lgica y
en la implementacin.

- Fase de mantenimiento: Se centra en el cambio asociado a la correccin de errores
detectados en las pruebas o mediante el uso de ese software, as como debido a las
adaptaciones requeridas por la evolucin del entorno del software o por cambios en
los requisitos.

Actividades:

- Correccin: Se procede a la correccin de los errores detectados en el
software.

- Adaptacin: Modificacin del software para adaptarlo a los nuevos
requisitos, o a un nuevo entorno.

- Mejora: Se ampla y mejora el software ms all de sus requisitos originales.

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.

2.1.1. Paradigma del ciclo de vida clsico

Tambin denominado modelo en cascada, considera que las fases llevadas a cabo para la
construccin del software se realizan de forma secuencial.
Fig. 3-4. Ciclo de vida clsico del desarrollo de sistemas

- Ingeniera y anlisis 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 abstraccin elevado.

- Anlisis de requisitos software:

Se procede a la recogida de informacin sobre el software a construir o problema a
solucionar.

Se trata de comprender el dominio de informacin 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 validacin.

- Diseo:

Se traducen los requisitos recogidos en la fase anterior en una especificacin formal
que pueda ser verificada y validada como paso previo a la construccin o codificacin.

- Codificacin:

Se traduce la especificacin formal a una especificacin entendible por el ordenador.
- Prueba:


Se verifica el producto software.

Se pretende asegurar que cada uno de los componentes software del producto
funcionan correctamente, asegurndose 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 clsico:

- 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
reparacin 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 diseo de prototipos es una tcnica de ingeniera utilizada para desarrollar modelos a
escala (o simulados) de un producto o de sus componentes. Cuando se aplica al desarrollo de
sistemas de informacin, el diseo de prototipos implica la creacin de un modelo o modelos
iterativos de trabajo de un sistema o un subsistema.

La tcnica de prototipos puede utilizarse en varias fases del ciclo de vida. Existen cuatro tipos
de prototipos de sistemas de informacin:

Prototipos de viabilidad:

Se utilizan para probar la viabilidad de una tecnologa especfica aplicable a un
sistema de informacin.

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
reconocern sus necesidades cuando las vean. Posteriormente veremos en detalle este
tipo de prototipo.

Prototipos de diseo:


Se utilizan para simular el diseo del sistema de informacin final. Mientras que los
prototipos de necesidades se centraban slo en el contenido, los prototipos de diseo
lo hacen en la forma y funcionamiento del sistema deseado. Cuando un analista crea
un prototipo de diseo, espera que los usuarios evalen dicho prototipo como si
formara parte del sistema final. As, los usuarios deberan 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 diseo o evolucionar hacia
prototipos de implantacin.

Prototipos de implantacin:

Constituyen una extensin de los prototipos de diseo donde el prototipo evoluciona
directamente hacia el sistema de produccin. En principio, los prototipos de
implantacin omiten normalmente detalles como la edicin 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 creacin de un modelo del producto a construir.

Este modelo puede ser:

- Un prototipo en papel que describa la interaccin hombre-mquina de forma que
facilite al usuario la comprensin de cmo 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 funcin deseada,
pero que tenga otras caractersticas a mejorar en el nuevo trabajo de
desarrollo.
Las actividades son:


- Recoleccin de requisitos: se identifican los requisitos (no se exige que sean todos)
y se perfilan las reas donde ser necesario profundizar ms tarde en el anlisis.

- Diseo rpido: enfocado a la representacin 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 diseo 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 informacin obtenida
y el prototipo como muestra, construir un producto final en base al paradigma
clsico.

Ventajas: (respecto al paradigma clsico)

- Considera una participacin 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. Tcnicas de cuarta generacin (T4G)

Abarca un amplio espectro de herramientas de software que facilitan la especificacin de
algunas caractersticas del software de alto nivel, la herramienta genera automticamente el
cdigo fuente basndose en la especificacin.

El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de
especificar el software usando formas de lenguaje especializado o notaciones grficas que
describan el problema a resolver en trminos que los entienda el cliente.


Mdulo II
PLANIFICACIN Y GESTIN
DE PROYECTOS


Captulo 4
Conceptos sobre
Gestin de Proyectos

Vamos a estudiar los conceptos bsicos que llevan a una gestin efectiva de proyectos
software. En los siguientes captulos completaremos estos conceptos con actividades que nos
llevarn a la correcta supervisin del proyecto; estudiaremos tcnicas para estimar los costes,
mtodos de planificacin y tcnicas para asegurar la calidad conforme se dirige un proyecto.

1. El espectro de la gestin

La gestin de proyectos es el proceso por el cual se planifica, dirige y controla el desarrollo
de un sistema aceptable con un coste mnimo y dentro de un perodo de tiempo especfico.

Aunque las herramientas y tcnicas del anlisis y diseo de sistemas desempean un papel
fundamental en obtener sistemas que funcionen, estos mtodos no son suficientes por s
mismos. Una mala gestin de proyectos puede dar al traste con los mejores mtodos de
anlisis y diseo de proyectos, o hacerlos ineficaces.

La gestin eficaz de un proyecto software se centra en tres aspectos fundamentales:

- El personal,
- El problema, y
- El proceso.

El gestor no debe olvidar que el trabajo de ingeniera es un esfuerzo humano intenso. Si no se
fomenta la comunicacin con el cliente, puede que al final no construyamos el producto que
se requiere. Y si no se presta atencin al proceso se corre el riesgo de no utilizar mtodos y
herramientas que nos facilitasen el trabajo de desarrollo del proyecto software.

1.1. Personal

Debido a su importancia, el Instituto de Ingeniera del Software ha desarrollado un Modelo
de madurez de la capacidad de gestin de personal para aumentar la preparacin de las
organizaciones del software para llevar a cabo las cada vez ms complicadas aplicaciones

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

Este modelo define las siguientes reas prcticas clave para el personal que desarrolla
software:

- Reclutamiento
- Seleccin
- Gestin de rendimiento
- Entrenamiento
- Retribucin
- Desarrollo de la carrera
- Diseo de la organizacin y del trabajo
- Desarrollo cultural y de espritu de equipo

Una organizacin que alcance una buena madurez en el rea de gestin de personal tiene una
mayor probabilidad de desarrollar eficazmente su trabajo.

1.2. El Problema

Antes de realizar la planificacin de un proyecto:

- se deben establecer sus objetivos y su mbito,
- se deben considerar soluciones alternativas, e
- identificar las dificultades tcnicas y de gestin.

Sin esta informacin, es imposible:

- definir unas estimaciones razonables del costo,
- una valoracin efectiva del riesgo,
- una subdivisin realista de las tareas del proyecto, o
- una planificacin del proyecto asequible.

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
ingeniera de sistema y contina como el primer paso en el anlisis de requisitos del
software.

Los objetivos identifican las metas generales del proyecto sin considerar cmo se
conseguirn.

El mbito identifica los datos primarios, funciones y comportamientos que caracterizan el
problema, y ms importante, intenta abordar estas caractersticas de una manera cuantitativa.

Una vez que se han entendido los objetivos y el mbito del proyecto, se consideran las
soluciones alternativas. Las alternativas permiten seleccionar el mejor enfoque, dadas las

limitaciones impuestas por la fecha lmite 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 pequeo nmero de actividades estructurales que se pueden aplicar a todos los
proyectos de software, sin tener en cuenta su tamao o su complejidad.

Diferentes conjuntos de tareas (tareas, hitos, entregas), permiten a las actividades
estructurales adaptarse a las caractersticas del proyecto software y al equipo de proyecto.

Finalmente, las actividades protectoras, tales como garanta de calidad del software,
gestin de la configuracin del software y medicin, cubren el modelo de proceso. Estas
actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del
proceso.

2. Gestin de Personal

El proceso de software lo componen participantes que pueden clasificarse en una de cinco
categoras:

1. Gestores superiores: definen los aspectos de negocios que a menudo tienen una
influencia significativa en el proyecto.

2. Gestores tcnicos del proyecto: deben planificar, motivar, organizar y controlar
a los profesionales que realizan el trabajo de software.

3. Profesionales: proporcionan las capacidades tcnicas necesarias para la
ingeniera de un producto o aplicacin.

4. Clientes: especifican los requisitos para la ingeniera 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:

- Resolucin del problema: un gestor eficiente de un proyecto de software puede
diagnosticar los aspectos tcnicos y de organizacin ms relevantes, estructurar una
solucin sistemticamente o motivar apropiadamente a otros profesionales para que
desarrollen la solucin.

- Dotes de gestin: 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 travs de sus acciones que no se
penalizar si se corren riesgos controlados.

- Influencia y construccin de espritu de equipo.

La mejor estructura de equipo depende del estilo de gestin de una organizacin, del nmero
de personas que compondr el equipo, sus niveles de preparacin y la dificultad general del
problema.

Mantei sugiere tres formas de equipo genricos:

1- Descentralizado democrtico (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 comunicacin entre los miembros del equipo es horizontal.

2- Descentralizado controlado (DC):

Tiene un jefe definido que coordina tareas especficas y jefes secundarios que
tienen responsabilidades sobre subtareas.

La resolucin de problemas es una actividad del grupo, pero la
implementacin de soluciones se reparte entre los subgrupos por el jefe de
equipo.

La comunicacin entre subgrupos e individuos es horizontal.

Tambin hay comunicacin vertical a lo largo de la jerarqua de control.

3- Centralizado controlado (CC):

El jefe del equipo se encarga de la resolucin de problemas a alto nivel y la
coordinacin interna del equipo.

La comunicacin entre el jefe y los miembros del equipo es vertical.


Constantine sugiere cuatro paradigmas de organizacin para equipos de I.S.:

1. Paradigma cerrado:

Estructura a un equipo con una jerarqua 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 innovacin o avances tecnolgicos, 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 tambin mucha de la
innovacin asociada al paradigma aleatorio.

El trabajo se desarrolla en colaboracin, con mucha comunicacin y toma de
decisiones consensuadas.

Es adecuado para la resolucin de problemas complejos, pero su rendimiento
puede ser menos eficiente.

4. Paradigma sincronizado:

Se basa en la divisin natural de un problema.

Organiza los miembros del equipo para trabajar en partes del problema con
poca comunicacin activa entre ellos.

3. Identificacin 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
informacin slida. Un anlisis detallado de los requisitos del software proporcionara la
informacin necesaria para las estimaciones, pero el anlisis a menudo lleva semanas o
meses. An peor, los requisitos pueden ser fluidos, cambiando regularmente a medida que
progresa el proyecto. Y an 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:

Cmo 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 informacin:

Qu objetos de datos visibles al cliente se obtienen del software? Qu
objetos de datos son requeridos de entrada?

Funcin y rendimiento:

Qu funcin realiza el software para transformar la informacin de entrada en
informacin de salida? Hay caractersticas de rendimiento especiales que
abordar?

La descomposicin del problema, es una actividad basada en el anlisis de requisitos del
software. Durante la exposicin 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 vencers que sirve para afrontar problemas
complejos. Para nuestro propsito, esta estrategia consiste en dividir el problema en
problemas ms pequeos (que resultan ms manejables).

Las funciones del software, descritas en la exposicin del mbito, se evalan y refinan para
proporcionar ms detalle antes del comienzo de la estimacin.

4. Actividades y tareas de ingeniera de software

Las fases genricas que caracterizan el proceso de software (definicin, desarrollo y
mantenimiento), son aplicables a todo el software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniera del software que debe aplicar el equipo del proyecto.

El gestor del proyecto debe decidir qu modelo de proceso es el ms adecuado para el
proyecto, despus debe definir un plan preliminar basado en un conjunto de actividades
estructurales vlidas para cualquier proyecto. Una vez establecido el plan preliminar, empieza
la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas
requeridas a las personas para cubrir las actividades estructurales.

4.1. Maduracin del problema y el proceso

Todas las funciones que se deben tratar dentro de un proceso de ingeniera por el equipo de
software deben pasar por el conjunto de actividades estructurales que se han definido para
una organizacin de software.

Un ejemplo de actividades estructurales asumidas por una organizacin podra ser:

Comunicacin con el cliente: tareas requeridas para establecer una comunicacin
eficiente entre el desarrollador y el cliente.

Planificacin: tareas requeridas para definir los recursos, la planificacin temporal
del proyecto y cualquier informacin relativa a l.

Anlisis de riesgo: tareas requeridas para valorar los riesgos tcnicos y de gestin.

Ingeniera: tareas requeridas para construir una o ms representaciones de la
aplicacin.

Construccin y entrega: tareas requeridas para construir, probar, instalar y
proporcionar asistencia al usuario.

Evaluacin del cliente: tareas requeridas para obtener informacin de la opinin del
cliente basadas en la evaluacin de las representaciones de software creadas durante la
fase de ingeniera e implementadas en la fase de instalacin.


Fig. 4-1. Tabla que relaciona tareas con actividades estructurales

Los miembros del equipo que trabajan en cada funcin aplicarn todas las actividades
estructurales. Se crea una matriz en la que cada funcin 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 finalizacin para las tareas asociadas con cada celda y establecer los productos que
surgirn en cada una de ellas.

4.2. Descomposicin del proceso

Una vez elegido el modelo de proceso, las actividades estructurales se adaptan a l. Esta
estructura comn de proceso es invariable y sirve como base para todo el trabajo de
software realizado por una organizacin.

Lo que varan son las tareas de trabajo reales. La descomposicin de proceso comienza
cuando se plantea cmo se va a realizar una determinada actividad estructural.

Para un proyecto pequeo, una empresa determinada, podra sugerir las siguientes tareas para
la actividad Comunicacin 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 exposicin del mbito del proyecto.
4. Revisar el alcance del proyecto con todos los implicados.
5. Modificar el alcance del proyecto cuando se requiera.

Captulo 5
Planificacin de proyectos software y
Gestin del Riesgo

La estimacin de recursos, costes, y la planificacin temporal de un esfuerzo de desarrollo
software requiere experiencia, acceder a una buena informacin histrica y la confianza en
medidas cuantitativas cuando todo lo que existe son datos cualitativos.

La estimacin conlleva un riesgo inherente, y es este riesgo el que lleva a la incertidumbre:

- 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
esfuerzos anteriores.

- El tamao del proyecto es otro factor importante que puede afectar a la precisin de
las estimaciones.

- La disponibilidad de informacin histrica determina el riesgo de la estimacin.
Aquellos que no pueden recordar el pasado estn condenados a repetirlo.

El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas
por recursos, coste y planificacin temporal.

Si no se entiende bien el mbito del proyecto o los requisitos del proyecto estn sujetos a
cambios, la incertidumbre y el riesgo son peligrosamente altos. El planificador de software
debera solicitar definiciones completas de rendimiento y de interfaz. Cualquier cambio en los
requisitos software significa inestabilidad en el coste y en la planificacin temporal.

1. Objetivos de la planificacin del proyecto

El objetivo consiste en proporcionar un marco de trabajo que permita al gestor hacer
estimaciones razonables de recursos, coste y planificacin 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. Adems, las estimaciones
deberan definir los escenarios del mejor y peor caso de forma que los resultados del proyecto
puedan limitarse.


2. mbito del software

La primera actividad de la planificacin del proyecto de software es determinar el mbito del
software. Se deben evaluar la funcin y rendimiento que se asignaron al software durante la
ingeniera de sistemas de computadora para establecer un mbito de proyecto que no sea
ambiguo, ni incomprensible para directivos y tcnicos.

El mbito del software describe:

- La funcin: Se evalan las funciones descritas en el enunciado del mbito, y
en algunos casos se refinan para dar ms detalles antes del
comienzo de la estimacin.

- El rendimiento: Abarca los requisitos de tiempo de respuesta y de
procesamiento.

- Las restricciones: Identifican los lmites del software originados por el hardware
externo, por la memoria disponible y por otros sistemas
existentes.

La tcnica utilizada con ms frecuencia para acercar al cliente y al desarrollador, y para hacer
que comience el proceso de comunicacin es establecer una reunin o entrevista preliminar.

3. Recursos

La segunda tarea de la planificacin es la estimacin de los recursos requeridos para
acometer el esfuerzo de desarrollo de software.

Estos recursos son:

* Recursos humanos:

Dado el mbito, y una vez seleccionadas las habilidades tcnicas que se
requieren para llevar a cabo el desarrollo, se selecciona al personal adecuado
para desarrollar cada una de las tareas.

Se debe especificar la posicin dentro de la organizacin y la especialidad.

El nmero de personas requerido para un proyecto software slo puede ser
determinado despus de hacer una estimacin del esfuerzo de desarrollo.

* Recursos hardware:

El sistema de desarrollo, o sistema anfitrin, consistente en la computadora
y perifricos asociados que se utilizarn durante la fase de desarrollo.

El sistema de explotacin, el sistema informtico que se requerir para la
explotacin y uso del software una vez se haya desarrollado.

Otros elementos, todos aquellos elementos hardware que sean necesarios
para el proceso de desarrollo y explotacin.

* Recursos software: el software que se utiliza durante el proceso de desarrollo
(incluso para la explotacin) del producto que se desea construir:

Herramientas orientadas al cdigo: compiladores, editores, enlazadores,...

Herramientas de metodologa: dan soporte a la planificacin, diseo,
prueba y gestin de la configuracin y mantenimiento (p.e. Developer 2000)

Herramientas de cuarta generacin: permiten especificar problemas
utilizando lenguajes especiales y tcnicas no procedimientales. (p.e. Oracle)

4. Estimacin del proyecto software

La estimacin del coste y del esfuerzo del software nunca ser una ciencia exacta. Son
demasiadas variables (humanas, tcnicas, de entorno, polticas) 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 estimacin para ms adelante.
2. Basar las estimaciones en proyectos similares ya terminados.
3. Utilizar tcnicas de descomposicin relativamente sencillas para generar estas
estimaciones.
4. Desarrollar un modelo emprico para el clculo de costes y esfuerzos del software.

La primera opcin no es muy prctica. La segunda puede funcionar razonablemente bien si el
proyecto es bastante similar a los esfuerzos pasados y para proyectos similares. Las opciones
restantes son ms viables.

La tcnica de descomposicin utiliza el enfoque divide y vencers, descomponiendo el
proyecto en sus funciones principales y en las tareas que correspondan.

5. Desarrollo de una estrategia de solucin

La tendencia que tienen los ingenieros de software es la de utilizar la primera solucin que
aparece en el proceso de planificacin. Para evitarlo hay que desarrollar una estrategia de
solucin, es decir, un enunciado general sobre la naturaleza de las posibles soluciones.

Se debe considerar varias estrategias de solucin antes de decidirse por una, aunque los
planificadores deben escoger una o ms para poder realizar el estudio de la posibilidad o
anlisis de riesgo.

6. Anlisis de Riesgo

La estrategia de riesgo reactiva, en el mejor de los casos, supervisa el proyecto en previsin
de posibles riesgos. Pero lo ms frecuente es que el equipo no haga nada respecto a los
riesgos hasta que algo va mal. Despus el equipo, apresuradamente trata de corregir el
problema. Cuando falla, la gestin de crisis entra en accin y el proyecto se encuentra en
peligro real.

La estrategia proactiva empieza mucho antes de que comiencen los trabajos tcnicos. Se
identifican los riesgos potenciales, se valora su probabilidad y se establece una prioridad
segn su importancia. Despus 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 caractersticas:

Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no ocurrir

Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no
deseadas o prdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado
de prdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categoras de
riesgos:

Los riesgos del proyecto amenazan el plan de proyecto. Si los riesgos de proyecto se
hacen realidad, es probable que la planificacin temporal del proyecto se retrase y que
los costos aumenten.
Los riesgos de proyecto identifican problemas potenciales de:
- presupuesto,
- planificacin temporal,
- personal,
- recursos y
- requisitos.


Los riesgos tcnicos amenazan la calidad y la planificacin temporal del software
que hay que producir. Si un riesgo tcnico se convierte en realidad, la implementacin
puede llegar a ser difcil o imposible.

Los riesgos tcnicos identifican problemas potenciales de:

- diseo,
- implementacin,
- interfaz,
- verificacin y
- mantenimiento.

Los riesgos de negocio amenazan la viabilidad del software a construir. A menudo
ponen en peligro el proyecto o el producto.

Estos riesgos pueden ser:

- Riesgo de mercado: construir un producto o sistema excelente que no quiere
nadie en realidad.

- Riesgo estratgico: construir un producto que no encaja en la estrategia
comercial general de la compaa.

- Construir un producto que el departamento de ventas no puede vender.

- Riesgo de direccin: perder el apoyo de una gestin experta debido a
cambios de enfoque o a cambios de personal.

- Riesgos de presupuesto: perder presupuesto o personal asignado.

Charrette propone otra categorizacin de riesgos, los divide en:

Riesgos conocidos: son todos aquellos que se pueden descubrir despus de una
cuidadosa evaluacin del plan del proyecto, del entorno tcnico y comercial en el que
se desarrolla el proyecto y otras fuentes de informacin fiables.

Riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (p.e.
cambio de personal, mala comunicacin con el cliente,...)

Riesgos impredecibles: pueden ocurrir, pero son extremadamente difciles de
identificar por adelantado.

6.1. Identificacin del Riesgo

La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan de
proyecto (estimaciones, planificacin temporal, carga de recursos, etc.). Identificando los
riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos
cuando sea posible y controlarlos cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categora:

Riesgos genricos: son una amenaza potencial para todos los proyectos de software.

Riesgos especficos de producto: slo pueden identificarse una vez que se tiene una
visin clara de la tecnologa, personal y entorno especfico del proyecto en cuestin.

Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de
riesgo. Se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes
subcategoras genricas:

- Tamao del producto: riesgos asociados con el tamao general del software a
construir o a modificar.

- Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la
gestin o por el mercado.

- Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la
habilidad del desarrollador para comunicarse con el cliente.

- Definicin del proceso: riesgos asociados con el grado de definicin del proceso del
software y su seguimiento por la organizacin de desarrollo.

- Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las
herramientas que se van a emplear en la construccin del producto.

- Tecnologa a construir: riesgos asociados con la complejidad del sistema a
construir y la tecnologa punta que contiene el sistema.

- Tamao y experiencia de la plantilla: riesgos asociados con la experiencia tcnica
y de proyectos de los ingenieros del software que van a realizar el trabajo.

Las respuestas a estas preguntas permiten al planificador del proyecto estimar el impacto del
riesgo.


6.2. Proyeccin y evaluacin del riesgo

La proyeccin o estimacin 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 evaluacin del riesgo se cuenta con un conjunto de ternas de la forma:

riesgo = {r
i
, p
i
, c
i
}

donde r
i
identifica al riesgo i, p
i
es la probabilidad de que se produzca el problema que
genera el riesgo i, y c
i
es el coste del riesgo.

Para que la evaluacin sea til, es necesario definir un nivel de referencia para el riesgo.
Para la mayora de los proyectos software el coste, la temporizacin 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 decisin de seguir o parar el
desarrollo del mismo.

6.3. Reduccin, supervisin y gestin del riesgo

Todas las actividades de anlisis 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
- Gestin 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 reduccin del riesgo.

A medida que progresa el proyecto, comienzan las actividades de supervisin del riesgo. El
jefe del proyecto supervisa factores que pueden proporcionar una indicacin de si el riesgo se
est haciendo ms o menos probable.

La gestin del riesgo y los planes de contingencia asumen que los esfuerzos de reduccin
han fracasado y que el riesgo se ha convertido en una realidad.

Tabla 5-1. Actividades de la planificacin del proyecto software
Definicin
del
problema
Desarrollar un enunciado definitivo del problema a resolver orientado al cliente.
Incluir una descripcin de la situacin actual, restricciones del problema y de las metas que se
lograrn.
Justificar una estrategia de solucin para el problema.
Identificar las funciones a realizar, las restricciones y los subsistemas hardware, software y de
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 validacin del producto.
Desarrollo
de una
estrategia
de solucin
Esbozar varias estrategias de solucin sin considerar las restricciones innatas al sistema,
organizacin o a las propias estrategias.
Realizar un estudio de la factibilidad para cada estrategia.
Recomendar una estrategia de solucin indicando por qu se rechazan las dems.
Desarrollar una lista de prioridades para las caractersticas del producto.
Proceso de
desarrollo
Definir un modelo de desarrollo y estructura organizativa del proyecto.
Planear las actividades de administracin de la configuracin, control de calidad y validacin.
Determinar las herramientas por fase, tcnicas y notacin a utilizar.
Establecer estimaciones preliminares del coste de desarrollo.
Establecer un programa preliminar para el desarrollo.
Establecer estimaciones preliminares del personal necesario.
Desarrollar estimaciones preliminares de los recursos de cmputo necesario para operar y
mantener el sistema.
Preparar un glosario de trminos.
Identificar las fuentes de informacin y referirse a ellas a lo largo del plan de proyecto.

7. Gestin de expectativas

Los directores de proyectos con experiencia a menudo se quejan de que gestionar las
expectativas de los proyectos es ms difcil que gestionar el coste, los plazos, los equipos o la
calidad. Vamos a utilizar una herramienta sencilla que har uso de una matriz de gestin 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
aplicacin y la calidad. En un mundo ideal, podra conseguirse optimizar todos estos
parmetros. La direccin de las empresas tiene a menudo una serie de expectativas. Sin
embargo, la realidad sugiere que no suele ser posible optimizar todos los parmetros, y que es
preciso enfrentarse a lo que es factible y lo que es aceptable dentro de la gestin. ste es el
propsito de la matriz de gestin de expectativas.

Una matriz de gestin de expectativas es una herramienta basada en conjuntos de
reglas cuya misin es ayudar a los directores de proyectos a valorar los posibles
cambios en los parmetros de un proyecto. Entre los parmetros se incluyen el coste,
el calendario, el campo de aplicacin y la calidad.

La matriz bsica, consta de tres filas y tres columnas (adems de los encabezamientos). Las
filas corresponden a las medidas de xito de un proyecto: coste, plazos y mbito de aplicacin
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:


- Maximizar o minimizar. La ms importante de las tres medidas en un proyecto
dado.

- Limitacin. La segunda prioridad ms importante de las tres medidas de un
proyecto.

- Aceptacin. La menos importante de las tres medidas de un proyecto.

Prioridades
Medidas de xito
Mx. o mn. Limitacin Aceptacin
Coste
Estimado 20.000 millones de dlares
X
Calendario
Plazo lmite = 31 diciembre de 1969
X
mbito y/o calidad
1. Llevar un hombre a la Luna
2. Traerlo de nuevo sano y salvo
X
Tabla 5-2. Matriz de gestin de expectativas. Ejemplo de gestin para el proyecto de alunizaje de EEUU

Estas tres medidas tienden a equilibrarse entre s de una manera natural. Por ejemplo, si se
ampla el mbito de un proyecto o los requisitos de calidad, se necesitar ms tiempo y/o ms
dinero. Por el contrario, si se intenta hacer un trabajo ms deprisa, por lo general se reducirn
el mbito del proyecto o los requisitos de calidad, o bien se invertir ms dinero para
compensarlo. La matriz de gestin de expectativas ayuda a la direccin a conocer estas tres
sencillas reglas:

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

- Ninguna fila debe contener ms de una X. En otras palabras, cada medida de xito
debe tener una y slo una prioridad.

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


Captulo 6
Estimacin de Costes y Plazos

1. Introduccin

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 produccin de software viene dado por los gastos de personal. Por este motivo,
el coste del proyecto suele medirse en personas-mes.

La estimacin de proyectos software es compleja pues es normal desarrollar un producto
distinto cada vez y usar distintas tcnicas y herramientas.

Suele hacerse ms de una estimacin de coste a lo largo del proyecto:
Estimacin preliminar en el estudio de viabilidad en la planificacin.
Esta estimacin es revisada y modificada al finalizar la especificacin de requisitos.
Nuevamente, la estimacin es modificada en la revisin del diseo.

2. Mtodos de estimacin de costes

Veremos los principales mtodos que nos ayudarn a realizar la estimacin:

1. Juicio de expertos: adivinacin basada en la experiencia

2. Estimacin por analoga: Se compara el proyecto que se va a desarrollar con uno o ms
proyectos terminados de los que se disponen datos. En funcin de las similitudes y
diferencias con dichos proyectos se deduce el coste del nuevo desarrollo.

3. Descomposicin: 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 estimacin: En general, son frmulas matemticas que
relacionan diversos parmetros del proyecto (tamao del software, condiciones del
entorno del proyecto, etc) con el coste o esfuerzo requerido.

2.1. Juicio de Expertos

Existen tcnicas especficas que intentan sistematizar y mejorar la opinin de las distintas
personas involucradas en la estimacin. Se suele emplear la opinin de ms de un experto
para obtener una mayor fiabilidad en la estimacin. En algunos casos, simplemente se calcula
la media de los valores ofrecidos por las distintas personas. Tambin se puede efectuar una
reunin tan larga como sea necesaria hasta llegar a un consenso.

La tcnica ms conocida es la tcnica Delphi. La mecnica es la siguiente:

1. Un coordinador proporciona a cada experto una documentacin con la definicin del
sistema y una papeleta para que escriba su estimacin y las razones de su estimacin.

2. Cada experto estudia la definicin y determina su estimacin de forma annima, 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 extrao efectuado por alguno de los expertos.

4. Los expertos realizan una segunda ronda de estimaciones (annima), utilizando los
resultados de la ronda anterior. En los casos en que una estimacin difiera mucho de las
dems, se podr solicitar que, de forma annima, sta sea justificada.

5. El proceso se repite tantas veces como se juzgue necesario impidiendo una discusin del
grupo durante el proceso.

Es posible que despus de una serie de rondas no se llegue a un acuerdo, en tal caso, el
coordinador deber analizar los aspectos problemticos con cada experto para determinar las
causas de tales discrepancias y, en su caso, recabar informacin adicional y presentarla a los
expertos a fin de resolver las discrepancias.

2.2. Estimacin por analoga

Las personas involucradas no slo trabajan con su experiencia acumulada, sino que disponen
tambin de datos de proyectos acabados relativamente similares al que hay que estimar. As,
por comparacin, se pueden evaluar las diferencias entre el nuevo proyecto y los antiguos
para extrapolar su coste.

Los ajustes de coste, esfuerzo o tamao del nuevo proyecto pueden realizarse de forma
lineal, es decir, se mantiene aproximadamente la proporcionalidad.

Los plazos de tiempo no guardan una relacin lineal con el esfuerzo o tamao del proyecto
(un 10% menos de tiempo para acabar el proyecto no implica un 10% ms de coste, sino
aproximadamente un 52% de incremento).

Ventaja: Est basada en la experiencia real de los proyectos.

Inconveniente: Dificultad a la hora de conocer realmente el grado de similitud con otro
proyecto.

2.3. Estimacin por descomposicin

El responsable de cada componente del software a construir estima el coste de su desarrollo.
La estimacin para el proyecto completo se calcula mediante la suma de las cantidades
parciales. Para aplicar esta tcnica hay que tener un diagrama de descomposicin 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 estimacin obtenida.

Inconvenientes:

- Suele haber actividades relacionadas con el proyecto que no suelen incluirse en la
definicin del mismo (leer cdigo, revisar, reunirse, ...) (40% del tiempo).

- Suele haber tambin actividades no relacionadas con el proyecto que consumen
tiempo (formacin, asuntos personales, ...) (30% del tiempo).

2.4. Modelos de estimacin

Brbara Kitchenham distingue dos tipos de modelos:

- Modelos de costes: proporciona estimaciones directas del esfuerzo o de la duracin. La
mayora son modelos de factores empricos que cuentan con una parte principal
(habitualmente una media del tamao del producto) y un cierto nmero de factores de ajuste.
P.e. el modelo COCOMO.

- Modelos de restricciones: muestran las relaciones en el tiempo entre dos o ms parmetros
de coste (p.e. esfuerzo, duracin 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 estimacin costos del software mejor documentados.

Se basa en el estudio realizado sobre 63 proyectos de software que cubran varios lenguajes y
varias reas de aplicacin, existiendo tres versiones del mismo: una bsica, una intermedia y
otra detallada.


3.1. Definiciones y suposiciones previas

El modelo COCOMO utiliza como base para la estimacin de costos el tipo de desarrollo del
software y el tamao estimado del producto de programacin, y supone una serie de
cuestiones que deben considerarse para aplicarlo correctamente.

3.1.1. Tipos de proyectos

Las frmulas que usa el modelo COCOMO para la estimacin distinguen tres clases o tipos
de proyectos de software:

a) Proyectos orgnicos:

- Son aquellos en los que existen pequeos equipos que trabajan en un entorno
familiar desarrollando aplicaciones con las que estn familiarizados.

- Las comunicaciones formales son escasas y cada miembro del equipo conoce quin
puede hacer un determinado tipo de trabajo.

b) Proyectos semi-separados:

- Este tipo de proyectos representa un estado intermedio entre el tipo orgnico 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 extraos 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 aplicacin particular que se desarrolla.

3.1.2. Tamao del Software

El tamao estimado para el software se mide en miles de instrucciones fuente entregadas.

Se considera instruccin fuente entregada a una lnea de cdigo, entendiendo por tal
cualquier cdigo que haya en una lnea que termine con un carcter de fin de lnea.

Normalmente se excluye el software de soporte no entregado, salvo en el caso de que el
desarrollo de este software se efecte con el mismo cuidado que el software entregado.

Las lneas de comentarios no se contabilizan.

3.1.3. Otras suposiciones

La estimacin de costos en el modelo COCOMO se obtiene a travs del esfuerzo requerido
para el desarrollo del producto.

Este esfuerzo se mide utilizando el nmero 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 das, promediando a lo largo de 12 meses.

El modelo supone tambin que:

- La especificacin de requisitos del software no cambiar significativamente despus
de la planificacin y anlisis de requisitos del producto.

- El proyecto tendr una buena administracin, tanto por parte del cliente como por
parte del responsable del desarrollo del software.

- El perodo cubierto por la estimacin de costos comienza con la fase de diseo del
producto y termina con el final de la fase de integracin y prueba.

3.2. El modelo bsico

3.2.1. Esfuerzo requerido para el desarrollo

En el modelo COCOMO bsico, las frmulas para calcular los costos o, ms exactamente, el
esfuerzo requerido en el desarrollo de software son las siguientes:

- Tipo Orgnico: PM = 2.4 * (MIFE ^ 1.05)

- Tipo Semi-separado: PM = 3.0 * (MIFE ^ 1.12)

- Tipo Empotrado: PM = 3.6 * (MIFE ^ 1.20)

Observaciones:

- PM representa el nmero de personas-mes requerido para el desarrollo del proyecto.
- MIFE es el nmero de miles de instrucciones fuente entregadas.
- Los coeficientes y exponentes crecen del tipo orgnico al tipo empotrado.


3.2.2. Tiempo de desarrollo.

El tiempo de desarrollo ser el tiempo requerido en meses para completar el proyecto
suponiendo la disponibilidad de suficiente personal.

Las ecuaciones de estimacin de tiempo para los diferentes tipos de proyecto son:

- Tipo Orgnico: TDES = 2.5 * (PM ^ 0.38)

- Tipo Semi-separado: TDES = 2.5 * (PM ^ 0.35)

- Tipo Empotrado: TDES = 2.5 * (PM ^ 0.32)

3.2.3. Observaciones

- El modelo supone una estimacin implcita de la productividad en el desarrollo del
proyecto, obtenindose como cociente entre el nmero de instrucciones fuente entregadas
(IFE) y el esfuerzo estimado (PM). Es decir:

Productividad = IFE / PM

- Permite conocer el nmero 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 funcin que depende del esfuerzo
total requerido para el proyecto y no del nmero de ingenieros de software que trabajen en el
mismo.

- El modelo COCOMO (bsico) no aporta gran ayuda en la estimacin de tiempo cuando el
personal disponible est limitado y, por el contrario, el tiempo de entrega es flexible.

3.2.4. Ejemplo

Suponer un proyecto de software de tipo orgnico cuyo tamao se estima en 32000
instrucciones fuente entregadas. Para dicho proyecto se obtienen los siguientes valores:

PM = 2.4 * (32 ^ 1.05) = 91 personas-mes

TDES = 2.5 * (91 ^ 0.38) = 14 meses

Productividad = 32000 / 91 = 352 ife/p-m (alrededor de 18 instrucc. por persona-da)

N = 91 / 14 = 6.5 personas

3.3. El modelo intermedio

3.3.1. Ecuaciones del modelo

El modelo COCOMO intermedio utiliza para sus estimaciones:

- Ecuaciones de esfuerzo nominal similares a las del COCOMO bsico.
- Las mismas ecuaciones de estimacin de tiempo que en el modelo bsico.
- Quince multiplicadores de esfuerzo divididos en cuatro categoras:
Atributos del producto
Atributos de la computadora
Atributos del personal
Atributos del proyecto

Las ecuaciones de esfuerzo nominal, o normal, en el modelo COCOMO intermedio son las
siguientes:

- Tipo orgnico: EN = 3.2 * (MIFE ^ 1.05)

- Tipo semi-separado: EN = 3.0 * (MIFE ^ 1.12)

- Tipo empotrado: EN = 2.8 * (MIFE ^ 1.20)

La ecuacin general de esfuerzo en el modelo COCOMO intermedio se puede establecer del
siguiente modo para los tres tipos de proyectos:

PM = EN * F1 * F2 * F3 * ... * F15

Observaciones:

EN es el esfuerzo nominal calculado segn el tipo de proyecto.
F1 hasta F15 representan a cada uno de los quince multiplicadores considerados en
el modelo COCOMO intermedio.

3.3.2. Atributos del modelo

A continuacin se expone una tabla en la que aparece cada atributo y sus correspondientes
valores en una lnea, teniendo en cuenta que MB significa muy bajo, B significa bajo, N es
nominal o normal, A representa un valor alto, MA es muy alto y EA significa
extremadamente alto:


Atributo MB B N A MA EA
F1 RELY 0.75 0.88 1.00 1.15 1.40 --
F2 DATA -- 0.94 1.00 1.08 1.16 --
F3 CPLX 0.70 0.85 1.00 1.15 1.30 1.65
F4 TIME -- -- 1.00 1.11 1.30 1.66
F5 STOR -- -- 1.00 1.06 1.21 1.56
F6 VIRT -- 0.87 1.00 1.15 1.30 --
F7 TURN -- 0.87 1.00 1.07 1.15 --
F8 ACAP 1.46 1.19 1.00 0.86 0.71 --
F9 AEXP 1.29 1.13 1.00 0.91 0.82 --
F10 PCAP 1.42 1.17 1.00 0.86 0.70 --
F11 VEXP 1.21 1.10 1.00 0.90 -- --
F12 LEXP 1.14 1.07 1.00 0.95 -- --
F13 MODP 1.24 1.10 1.00 0.91 0.82 --
F14 TOOL 1.24 1.10 1.00 0.91 0.83 --
F15 SCED 1.23 1.08 1.00 1.04 1.10 --
*Estos valores se pueden interpolar, pero no extrapolar
Tabla 6-1. Valores de los atributos del modelo COCOMO intermedio.

Descripcin de los atributos:

A continuacin se describen los quince multiplicadores de esfuerzo divididos en cuatro
categoras: atributos del producto, atributos de la computadora, atributos de personal y
atributos del proyecto.

Los atributos del producto

RELY: Fiabilidad requerida del software:

Toma valores en una escala que va desde muy bajo cuando un fallo en el software slo
causa pequeos inconvenientes, hasta normal cuando un fallo genera unas prdidas
moderadas recuperables, o muy alto cuando un fallo conlleva riesgos para la vida
humana.

DATA: Tamao de la base de datos:

Vara desde bajo cuando el tamao de la base de datos medido en bytes es menor que
10 veces el nmero de IFEs, hasta normal cuando el tamao de la base de datos est
entre 10 y 100 veces el tamao del sistema, o muy alto cuando el tamao de la base de
datos es ms de 1000 veces mayor que el programa.

CPLX: Complejidad del producto:

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

implica algn procesamiento de entrada/salida, mltiples ficheros de entrada, el uso
de bibliotecas de rutinas matemticas y estadsticas, y alguna comunicacin entre
mdulos. La complejidad alta y extremadamente alta supone la posibilidad de
reutilizacin de cdigo reentrante o recursivo, tratamiento de ficheros complejo,
procesamiento paralelo, administracin 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 ejecucin:

Vara desde normal a extremadamente alto. Un valor normal significa que se utiliza
menos del 50% del tiempo de ejecucin disponible y extremadamente alto sera 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 sera cuando usase el
95% de la memoria disponible.

VIRT: Volatilidad de la mquina virtual:

Se entiende por mquina 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
slo ocasionalmente ocurren grandes cambios en la mquina virtual. Un valor normal
implica cambios importantes cada seis meses y un valor muy alto sugiere que la
mquina virtual cambia una vez cada dos semanas.

TURN: Tiempo de respuesta de la computadora:

Representa el tiempo transcurrido para la obtencin de resultados. Un valor bajo
implica un sistema de desarrollo interactivo, mientras que un valor muy alto significa
que pasarn ms de 12 horas hasta la obtencin 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 ao de experiencia, o muy alto, en el caso de tener ms de tres aos de experiencia.
Dichos atributos son:

ACAP: Capacidad de los analistas.
AEXP: Experiencia en aplicaciones.
PCAP: Capacidad de los programadores.
VEXP: Experiencia en la mquina virtual.
LEXP: Experiencia en lenguajes de programacin.

Los atributos del proyecto

Hacen referencia al uso de herramientas de software, el tiempo de desarrollo del proyecto y la
utilizacin de tcnicas de programacin modernas. El presentar estos factores como
miembros de la misma categora obedece ms bien al intento de limitar su efecto aislado. Son
las siguientes:

MODP: Uso de tcnicas de programacin modernas:

Boehm considera como tcnicas de programacin modernas el uso de diseo
descendente, revisiones de diseo y cdigo, la programacin estructurada y la
utilizacin de bibliotecas de soporte de programa, entre otras tcnicas. Este factor
toma valores en una escala que va desde muy bajo cuando no se utilizan tales tcnicas,
hasta normal cuando se usan algunas, o muy alto en el caso de que los miembros del
equipo utilicen las tcnicas 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 slo se dispone de herramientas muy bsicas tales como un ensamblador.
Un valor normal significa tener un conjunto ms completo de herramientas para la
implementacin, pruebas y depuracin, 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 variacin de tiempo de
desarrollo respecto a la estimacin nominal, obtenida utilizando la ecuacin de
esfuerzo nominal y la ecuacin de estimacin de tiempo dada en el modelo COCOMO
bsico. Un valor muy bajo para este atributo significa la necesidad de acelerar el
tiempo de desarrollo, mientras que un valor alto implica la dilatacin 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 ao 1985 que se expone a continuacin.

Se supone una situacin 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. Tambin 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.

- Todos los multiplicadores de esfuerzo para el modelo COCOMO intermedio tienen
un valor normal, salvo los siguientes:

RELY = 1.15 (A) STOR = 1.21 (MA) TIME = 1.11 (A) TOOL = 1.10 (B)

Utilizando el modelo COCOMO intermedio se obtiene la siguiente estimacin para el
esfuerzo de desarrollo:

PM = 45 * 1.15 * 1.21 * 1.11 * 1.10 = 76 p-m

El costo total de desarrollo de este proyecto sera:

C = 76 * 6000 = 456000$

Caso 2: Supongamos que se tuviera el propsito de utilizar un procesador compatible a 8
MHz y con 128 Kbytes de memoria.

- En este caso, se requerira el desarrollo de una interfaz especial con un costo
adicional de hardware de 30000$

- El atributo TOOL tendra un valor muy bajo en lugar de bajo, no vindose afectados
los atributos de personal, TIME y STOR podran reducirse a sus valores normales.

PM = 45 * 1.15 * 1.24 = 64 p-m
C = 64 * 6000 = 384000$

En consecuencia, se podra disponer de 42000$ para investigar en la mejora del
hardware si se desea.

4. Crticas a los modelos de coste

A pesar de que parecen totalmente eficaces, hay que matizar esta impresin.

- Los modelos dependen de LDC, pero este parmetro hay que estimarlo.
- Los modelos han surgido del anlisis estadstico de datos de proyectos. La cantidad y
representatividad de los proyectos no es tan amplia como sera deseable.

- Los modelos pierden precisin al utilizarse en entornos distintos de aquellos en los que se
crearon.
- Los factores de coste son difciles de cuantificar y se consideran independientes aunque no
necesariamente lo son.
- Los modelos tienen un margen de error que puede ser ms o menos aceptable.
- El modelo COCOMO intermedio no considera atributos tales como el tipo de aplicacin
que se va a desarrollar, la documentacin requerida, la continuidad del personal o la
calidad de la interfaz, entre otros.
- Estos modelos asumen pequeos cambios en los requisitos del producto pero requieren
que la administracin del proyecto sea de alta calidad.

5. Beneficios del uso de modelos de coste

- Proporciona una base cuantitativa para la toma de decisiones administrativas.
- El uso consistente de un modelo de estimacin de coste, dentro de cualquier organizacin
debera preferirse a la improvisacin de estimaciones de coste del software.
- Es posible realizar estimaciones para cada actividad del desarrollo del producto de
programacin (en el modelo COCOMO puede hacerse una estimacin para cada
actividad).

Captulo 7
Planificacin Temporal y
Seguimiento del Proyecto

1. Conceptos bsicos

La planificacin temporal de un proyecto software es una actividad que distribuye el
esfuerzo estimado a lo largo de la duracin prevista del proyecto, asignando el esfuerzo a las
tareas especficas de la ingeniera de software.

La planificacin temporal evoluciona con el tiempo, desde una visin macroscpica a una
detallada.

La planificacin temporal del proyecto puede verse desde dos perspectivas diferentes:

- La fecha de lanzamiento del producto est establecida sin posibilidad de cambio.
- Existe un margen de holgura que es ajustado por el equipo de gestin del software.

La planificacin de un proyecto de desarrollo comprende varias tareas importantes:

- Definir un modelo de ciclo de vida.
- Ajustar el conjunto de tareas a un calendario.
- Asignar los recursos adecuados y a tiempo a esas tareas.
- Establecer hitos o puntos de control en el calendario previsto.

Podemos guiarnos en la planificacin temporal por un conjunto de principios bsicos:

- Particin: El proyecto debe dividirse en un nmero de actividades y tareas
manejables. Se descompone tanto el producto como el proceso.

- Interdependencia: Determinar la interdependencia de cada actividad o tarea.

- Asignacin de tiempo: Asignar a cada tarea un cierto nmero de unidades de
trabajo, as como una fecha de inicio y fin.

- Validacin del esfuerzo: Comprobar que los recursos asignados no sobrepasan a los
que se tienen.

- Responsabilidades definidas: asignan cada tarea a un miembro especfico.

- Resultados definidos: cada tarea debera 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 ms
productos y se han aceptado.

2. Acerca de los retrasos

Hay muchas razones por las que el software se entrega tarde, la mayora pertenece a una o
ms de las siguientes causas:

- Fecha lmite de entrega poco realista.
- Cambios en los requisitos que no se reflejan en la P.T.
- Subestimacin honesta del esfuerzo y recursos requeridos.
- Errores predecibles y no predecibles considerados cuando comenz el proyecto.
- Dificultades tcnicas o humanas que no fueron prevista.
- Falta de comunicacin entre la plantilla del proyecto.
- Falta de reconocimiento por parte de la gestin del proyecto de su retraso y falta de
medios para corregir el problema.

Hay un mito comn: si se retrasa el proyecto, siempre podemos aadir ms gente y recuperar
el ritmo ms adelante en el proyecto. Sin embargo esto provoca ms retraso. El personal
agregado debe aprenderse el sistema, aumentan las vas de comunicacin y la complejidad de
la comunicacin a lo largo del proyecto.

3. Distribucin de esfuerzo

Una distribucin recomendada de esfuerzo en las fases de definicin y desarrollo se le conoce
normalmente con el nombre de regla 40-20-40:

40% o ms Anlisis y diseo
20% Codificacin
40% Prueba y depuracin

Esto es una directriz, estos porcentajes dependen del proyecto considerado.

Planificacin 2-3%
Anlisis de requisitos 10-25%
Diseo de software 20-25%
Revisin de diseo 5-10%
Codificacin 15-20%
Prueba y depuracin 30-40%

4. Definicin de tareas

Se debe definir una coleccin 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 disean 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 algn nuevo
concepto de negocio o aplicacin de alguna nueva tecnologa.

- Proyectos de desarrollo de una nueva aplicacin: que se aceptan como
consecuencia del encargo de un cliente especfico.

- Proyectos de mejora de aplicaciones que corrigen, adaptan o amplan un software
existente de maneras que pueden no ser obvias de forma inmediata para el usuario
final.

- Proyectos de reingeniera: que se lleva a cabo con la intencin 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 adems tareas en paralelo.
Las tareas concurrentes deben coordinarse, de forma que finalicen cuando tareas
posteriores requieran sus resultados.

Una red de tareas es una representacin grfica del flujo de tareas de un proyecto. En su
forma ms sencilla muestra las tareas principales de ingeniera del software.

Fig. 7-1. Red de tareas para un proyecto

El planificador debe determinar las dependencias internas de las tareas para garantizar un
progreso continuo hasta su finalizacin. Adems el gestor del proyecto debera estar al tanto
de las tareas que pertenecen al camino crtico, es decir, tareas que deben finalizarse segn la
planificacin temporal si se quiere que el proyecto en general se termine a tiempo.

5. Planificacin temporal

Se pueden aplicar herramientas de planificacin temporal de proyectos y tcnicas generales
al software con pocas modificaciones:

- Tcnicas de evaluacin y revisin de programas (PERT)
- Mtodo del camino crtico (CPM)

Ambas tcnicas son dirigidas por la informacin ya desarrollada en actividades anteriores de
la planificacin del proyecto:

- Estimaciones de esfuerzo.
- Una descomposicin de la funcin del producto.
- La seleccin del modelo de proceso adecuado.
- La seleccin 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 crtico: cadenas de tareas que determina la duracin del
proyecto.
- Establecer las dimensiones de tiempo ms probables para las tareas individuales
aplicando modelos estadsticos.
- Calcular las limitaciones de tiempo que definen una ventana de tiempo de una
tarea determinada.

5.1. Grficos de tiempo

Una vez definidas las tareas, se define el esfuerzo, duracin y fecha de inicio de cada tarea.
Adems se asigna cada tarea a individuos especficos.

Como consecuencia de cada entrada (tarea) se genera un grfico de tiempo tambin
denominado Grfico Gantt.

Las tareas se colocan en la columna de la izquierda. Se indica la duracin de cada tarea
mediante barras horizontales. Si aparecen mltiples barras al mismo tiempo hay concurrencia
de tareas. Los rombos indican hitos.


Fig. 7-2. Ejemplo de diagrama de Gantt

5.2. Seguimiento de la planificacin 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 peridicas 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
ingeniera 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.

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


6. El Plan de Proyecto

Es un documento que se produce a la culminacin de las tareas de planificacin. Proporciona
informacin bsica de costes y planificacin 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 tcnico y al
cliente.
- Definir los riesgos y sugerir tcnicas de aversin de riesgos.
- Definir los costes y planificacin temporal para la revisin de la gestin.
- Proporcionar un enfoque general del desarrollo del software para todo el personal
relacionado con el proyecto.
- Describir cmo se garantizar la calidad y se gestionan los cambios.


Documento de Plan de Proyecto Software

I. Introduccin
A. mbito del proyecto y Objetivos.
1. Declaracin del mbito.
2. Funciones principales.
3. Aspectos de rendimiento.
4. Restricciones tcnicas y de gestin.
B. Modelo de ciclo de vida utilizado.
C. Definicin de los estndares de documentacin.
II. Estimaciones del proyecto
A. Datos histricos usados para las estimaciones.
B. Tcnicas de estimacin.
C. Estimaciones de esfuerzo, coste y duracin.
III. Riesgos del proyecto
A. Anlisis del riesgo.
1. Identificacin.
2. Estimacin del riesgo.
3. Evaluacin.
B. Gestin del riesgo.
IV. Planificacin Temporal.
A. Estructura de descomposicin del trabajo del proyecto.
B. Red de tareas (red Pert).
C. Grfico de Tiempo (grfico Gantt)
V. Recursos del Proyecto.
A. Personal.
B. Hardware y Software.
C. Tabla de Recursos (enlazados al grfico de tiempo)
VI. Organizacin del Personal.
A. Estructura de equipo (si procede).
VII. Mecanismos de seguimiento y de control.
A. Garanta de calidad y control.
B. Gestin y control de cambios.
VII. Apndices.
A. Glosario de trminos.
B. Bibliografa.
...


Captulo 8
Tcnicas de
Planificacin Temporal

Vamos a contemplar varias tcnicas que se pueden utilizar en la realizacin del calendario.
Algunas son muy sencillas y no muestran la interrelacin entre las actividades, como son el
diagrama de hitos y los diagramas de Gantt. Para mostrar dicha interrelacin, se hace
necesario el anlisis de las redes de precedencia por medio de la tcnica PERT.

1. Diagrama de hitos

El diagrama de hitos es el mtodo ms simple para determinar el calendario. Es un cuadro o
tabla formado por dos columnas; en la primera se sealan las actividades y en la segunda se
indican sus fechas de finalizacin.

Las ventajas de esta tcnica son la facilidad de uso y el mnimo coste de preparacin. Las
desventajas son la incertidumbre existente sobre las fechas de comienzo de las actividades y
la imposibilidad de reflejar las interrelaciones entre ellas.

Esta tcnica tambin se utiliza para resumir calendarios complejos que contienen muchas
tareas.

2. Diagramas de Gantt

El diagrama de Gantt se utiliza frecuentemente en proyectos pequeos y supera algunos de
los inconvenientes de los diagramas de hitos. Este tipo de calendario es seguramente el ms
utilizado, quizs porque muchas personas lo encuentran ms comprensible que las redes de
precedencia.

Aunque con estos diagramas no es posible representar las dependencias entre actividades, es
ms fcil 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 funcin 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 duracin de las mismas (columnas).


Unidades de tiempo
tareas 1 2 3 4 5 6 7 8 9 10
fase 1
1.1
1.2
1.3
fase 2
2.1
2.2
2.3

Fig. 8-1. Diagrama de Gantt

Dentro del diagrama se pueden incluir fases que engloben diferentes tareas y se representan
los tiempos de la fase como los de cada tarea en particular.

Los diagramas de Gantt pueden utilizarse para mostrar el avance de los proyectos, en virtud
de que pueden comparar de forma conveniente la planificacin original con el desarrollo real.
Para informar del avance del proyecto, hemos de ampliar las convenciones utilizadas. Si una
tarea ha sido completada, su barra correspondiente aparecer ms oscura. Si ha sido
completada slo parcialmente, la parte proporcional de la barra estar ms oscura. El
porcentaje de la barra oscurecida debera corresponder al porcentaje de tarea completa. Las
barras ms claras simbolizan tareas que no has sido empezadas. A continuacin se trazar una
lnea vertical perpendicular la eje horizontal y que cortar a ste en la fecha del da. As
podemos evaluar el alcance de nuestro proyecto.

Unidades de tiempo
tareas 1 2 3 4 5 6 7 8 9 10
fase 1
1.1
1.2
1.3
fase 2
2.1
2.2
2.3

Fig. 8-2. Avance del proyecto con diagramas de Gantt

hoy

3. Redes de precedencia

Hay dos tcnicas principales basadas en grafos para la planificacin de proyectos. Estas son
PERT y CPM.

Es conveniente utilizar estas tcnicas 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 estn ordenadas de forma que se pueda conseguir una secuencia.
- Una vez comenzada una actividad, debe continuar sin interrupcin hasta su
finalizacin.

La red es un modelo grfico que seala las relaciones secuenciales entre los sucesos claves de
un proyecto. PERT puede mostrar el camino crtico, que es la secuencia ms larga de
actividades conectadas a travs de la red y que determina la duracin total del proyecto.

Este camino crtico es la base para la planificacin y el control de un proyecto. Para
disminuir el tiempo total, hay que reducir los tiempos de las actividades que estn dentro del
camino crtico, teniendo en cuenta que esa disminucin suele conllevar un aumento del coste
de la actividad.

Esta tcnica tambin permite visualizar las tareas que no son crticas. 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. Tcnica PERT

La tcnica PERT sirve de ayuda en proyectos complejos y que requieren una cuidadosa
planificacin, programacin y coordinacin de diferentes actividades interrelacionadas.

La tcnica PERT parte de la descomposicin de un proyecto en actividades. Para su
realizacin 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 representacin 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 relacin alguna con la duracin de la actividad.


Fig. 8-3. Representacin actividad y suceso en PERT

4.1. Representacin de una red PERT

El problema que se plantea es el de encontrar el camino ms largo a travs de una red, y se
puede solucionar con la tcnica de administracin PERT. Se emplea una red de proyectos
para visualizar grficamente 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 estn ordenadas.

Fig. 8-4. Relacin entre actividades.

El siguiente paso es la determinacin 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 simultneamente (por
ejemplo, de convergencia y divergencia).
El mtodo PERT exige que la red de proyecto sea acclica y que dos nodos no estn
conectados directamente por ms de un arco.

A
1 2

Existen casos en los que, para determinadas combinaciones, existen conflictos. Por ejemplo,
supongamos que tenemos las siguientes relaciones:

Las actividades A y B preceden a la actividad D
Las actividades A, B y C preceden a la actividad E

Segn estas relaciones se podra representar el siguiente grafo:

Fig. 8-5. Grafo de relaciones entre actividades

Observamos que en el grafo se cumple la segunda regla, pero no la primera, ya que es
necesario que finalice tambin la actividad C para comenzar la actividad D.

Para resolver el problema se aade una actividad ficticia F, de duracin cero.

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

Una vez vistos los aspectos en los que se basa la representacin de actividades, vamos a ver la
realizacin del grafo PERT mediante un ejemplo.

Supongamos que tenemos que realizar un proyecto que tiene las siguientes actividades A, B,
C, D, E, F y G. Las relaciones entre actividades son las siguientes:


A precede a B, C y D
B precede a E
C precede a F
D precede a G
E, F precede a H

Vamos a recoger este conjunto de relaciones mediante la matriz de encaminamientos. La
matriz de encaminamientos es una matriz cuya dimensin coincide con el nmero de
actividades en las que se descompone el proyecto. Sea M
ij
un elemento de la matriz, si M
ij
=
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
F X
G X
H X X
Fig. 8-7. Matriz de encaminamientos

En este punto se construye el grafo:

Fig. 8-8. Grafo que relaciona las actividades del ejemplo

A continuacin, estudiamos las asignaciones de los tiempos de cada actividad. PERT
considera que la duracin de las actividades es una variable aleatoria de la que conocemos
su ley de distribucin. Para ello consideramos tres tiempos:

Estimacin de tiempo pesimista (t
p
): representa el tiempo mximo en el que podra
finalizarse la actividad si aparecen todas las circunstancias negativas que pueden darse
durante su ejecucin.

Estimacin de tiempo ms probable (t
n
): representa el tiempo normal de duracin
de la actividad considerando que hay problemas durante las actividades, pero no
aparecen en su totalidad.

Estimacin de tiempo optimista (t
o
): representa el tiempo mnimo si no aparece
ningn problema durante la ejecucin de la actividad.

En base a estas estimaciones, se calcula el tiempo PERT T como:

T = (t
p
+ 4t
n
+ t
o
) / 6

y la varianza:

= SQRT ( ((t
p
t
o
) / 6)
2
)

El siguiente paso es el clculo de los tiempos early (tiempo ms temprano posible) y last
(tiempo ms tardo posible) de cada suceso descrito en el grafo. Para ello, nos basaremos en
la representacin de la figura:

Fig. 8-9. Representacin grfica de tiempos de una actividad

4.2. Clculo de los tiempos ms prximos (early):

El tiempo ms prximo para un suceso es el tiempo estimado en el que ocurrir el suceso si
las actividades que lo preceden comienzan lo ms pronto posible.

El tiempo early del suceso j, que representamos por TE
j
ser igual a:

TE
j
= mx. [ TE
i
+ T
ij
], j

donde TE
i
es el tiempo early del suceso i y T
ij
es la duracin de la actividad que comienza en
el suceso i y finaliza en el suceso j. Es decir, se calcula sumando los tiempos early de los
sucesos en los que nace una actividad que finaliza en el suceso j, la duracin de la actividad y
cogiendo el mayor.

Volviendo al ejemplo, supongamos que tenemos calculados los tiempos PERT de cada una de
las actividades y que son los siguientes:

Actividad A B C D E F G H
Duracin 8 5 6 5 6 7 9 3

Por ejemplo, para calcular el TE
6
, estudiamos los sucesos iniciales de las actividades E y F:
TE
6
= mx [14+7, 13+6] = 21, y para TE
7
= mx.[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 continuacin. El
suceso inicial siempre tiene un TE
i
= 0.

Fig. 8-10. Clculo de los tiempos ms prximos en una red Pert

El proceso para obtener los tiempos ms prximos es el siguiente:

- Se efecta un paso hacia delante a travs de la red.
- Se calcula sucesivamente el tiempo en el que ocurrir cada suceso si el precedente
inmediato ocurre en su tiempo ms prximo y cada actividad que interviene
consume exactamente su tiempo estimado.
- La iniciacin del proyecto se debe etiquetar como el tiempo 0.

4.3. Clculo de los tiempos ms lejanos (late).

El tiempo ms lejano para un suceso es el ltimo momento estimado en el que puede ocurrir
un suceso sin retrasar la terminacin del proyecto ms all de su tiempo ms prximo.

El tiempo late del ltimo suceso coincide con su tiempo early. El resto de los tiempos late se
calculan:

TL
i
= min. [TL
j
T
ij
], j

donde TL
j
es el tiempo last del suceso j y T
ij
la duracin 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 duracin de las actividades y
cogiendo el menor.
Fig. 8-11. Clculo de los tiempos ms lejanos en una red Pert

El proceso de obtencin de los tiempos ms lejanos consiste en:

- Efectuar un paso hacia atrs a travs 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 ms lejano si cada actividad involucrada consume
exactamente su tiempo estimado.

4.4. Holgura total de una actividad y camino crtico

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
ms lejano y su tiempo ms prximo:

H
i
= TL
i
TE
i

La holgura de un suceso nos indica el nmero de unidades de tiempo en las que se puede
retrasar su realizacin de forma que no se aumente la duracin total del proyecto.

Se dice que un suceso es crtico si H
i
= 0. En el ejemplo vemos que son crticos los sucesos:
1, 2, 4, 6 y 7.


La holgura total de una actividad que une el suceso i con el suceso j se define como:

H
T
ij
= TL
j
TE
i
- T
ij

Representa el nmero de unidades de tiempo que puede retrasarse la realizacin de la
actividad con respecto al tiempo PERT previsto sin que aumente la duracin del proyecto.

Si la actividad H aumenta dos unidades de tiempo, el tiempo final del proyecto se ver
afectado de igual modo: TE
i
= TE
j
= 26. Sin embargo, la actividad E tiene una holgura total
H
t
36
= 21 13 6 = 2, luego podemos retrasar esta actividad como mximo 2 unidades de
tiempo ms sin que se retrase la finalizacin del proyecto.

Las holguras se relacionan con posibles retrasos de la siguiente forma:

- Para un suceso, representa cunto retraso se puede admitir para llegar a ese suceso
sin retrasar la terminacin del proyecto.

- Para una actividad, indica lo mismo respecto a un retraso en la terminacin 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 disminucin de la holgura total de la siguiente actividad.

Las actividades que tienen una holgura total igual a cero se denominan actividades crticas.

En el ejemplo podemos ver que la actividad H es crtica: H
T
67
= 24 21 3 = 0.

Uniendo todas las actividades crticas se forma un camino desde el suceso inicial al suceso
final del proyecto, que recibe el nombre de camino crtico (que se representa por una lnea
gruesa). Cualquier retraso que sufra alguna de las actividades del camino crtico implicar un
retraso en el proyecto.

El director de proyecto no debe slo prestar atencin a las actividades crticas, sino tambin a
las que no lo son, ya que si una actividad no crtica consume el total de su holgura, se
convierte en crtica, y aparecera un nuevo camino crtico.

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 bsica para el proyecto, mostrando todas las relaciones de
precedencia.


4. Estimar el tiempo esperado de duracin para cada actividad.

5. Empleando una revisin hacia delante de la red, calcular el tiempo ms prximo
para cada suceso.

6. Utilizando el tiempo esperado de terminacin del proyecto, calculando en la
revisin hacia delante de la red, usar el procedimiento de revisin hacia atrs para
calcular el tiempo ms lejano para cada suceso.

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

8. Identificar la ruta crtica para la red. Las actividades crticas son las que tienen un
tiempo de holgura cero.

4.6. Valoracin del mtodo PERT

El objetivo de los sistemas tipo PERT consiste en ayudar en la planificacin y el control,
por lo que no implica que sea un mtodo de optimizacin en si.

Algunas veces el objetivo primario es determinar la probabilidad de cumplir con fechas de
entrega especficas.

Se identifican aquellas actividades que es ms probable que se conviertan en cuellos de
botella.

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

Adems, se pueden evaluar otros cambios entre recursos y desempeo, y se puede evaluar el
efecto de desviarse de lo programado.

El mtodo PERT es apropiado cuando se maneja mucha incertidumbre al predecir los
tiempos de las actividades y cuando es importante controlar de manera efectiva la
programacin del proyecto.


Captulo 9
Control de calidad del Software y
Gestin de la Configuracin

1. Introduccin

La garanta de calidad del software (SQA, Software Quality Assurance) es una actividad de
proteccin que se aplica a lo largo de todo el proceso de ingeniera del software.

La SQA engloba:

Un enfoque de gestin de calidad.
Tecnologa de ingeniera del software efectiva (mtodos y herramientas)
Revisiones tcnicas formales que se aplican durante el proceso del software.
Una estrategia de prueba multiescalada.
El control de la documentacin del software y de los cambios realizados.
Un procedimiento que asegure un ajuste a los estndares de desarrollo del software
(cuando sea posible).
Mecanismos de medicin y de generacin de informes.

2. Conceptos de calidad

2.1. Calidad

Cuando se examina un artculo segn sus caractersticas mensurables, se pueden encontrar
dos tipos de calidad: calidad del diseo y calidad de concordancia.

La calidad del diseo se refiere a las caractersticas que especifican los ingenieros de
software para un artculo. El grado de materiales, tolerancias, y especificaciones del
rendimiento, todos contribuyen a la calidad del diseo. Cuando se utilizan materiales de alto
grado y se especifican tolerancias ms estrictas y niveles ms altos de rendimiento, la calidad
de diseo de un producto aumenta, si el producto se fabrica de acuerdo con las
especificaciones.

La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseo
durante su realizacin. Una vez ms, cuanto mayor sea el grado de cumplimiento, ms alto
ser el nivel de calidad de concordancia.

En el desarrollo de software, la calidad de diseo acompaa a los requisitos, especificaciones
y diseo del sistema. La calidad de concordancia es un aspecto centrado principalmente en la
implementacin. Si la implementacin sigue el diseo, 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. Garanta de calidad

La garanta de calidad consiste en la auditora y las funciones de informacin de la gestin.
El objetivo de la garanta de calidad es proporcionar la gestin para informar de los datos
necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms
profunda y segura de que la calidad del producto est cumpliendo sus objetivos.

3. Garanta (aseguramiento) de calidad del software

La calidad del software se define como:

Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos,
con los estndares de desarrollo explcitamente documentados, y con las caractersticas
implcitas que se espera de todo software desarrollado profesionalmente.

La definicin 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 estndares especificados definen un conjunto de criterios de desarrollo que guan la
forma en que se aplica la ingeniera del software. Si no se siguen esos criterios, casi
siempre habr falta de calidad.

3. Existe un conjunto de requisitos implcitos que a menudo no se mencionan (p.e. el deseo
de un buen mantenimiento). Si el software se ajusta a sus requisitos explcitos pero falla en
alcanzar los requisitos implcitos, la calidad del software se queda en entredicho.


3.1. Actividades de SQA

La garanta de calidad del software comprende una gran variedad de tareas, asociadas con
dos componentes diferentes:

- Los ingenieros de software que realizan trabajo tcnico, y
- Un grupo de SQA que tiene la responsabilidad de la planificacin de garanta de
calidad, supervisin, mantenimiento de registros, anlisis e informes.

4. Revisiones del software

Una revisin es una forma de aprovechar la diversidad de un grupo de personas para:

1. Sealar 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 tcnico de una calidad ms uniforme, o al menos ms predecible,
que la que puede ser conseguida sin revisiones, con el fin de hacer ms manejable el
trabajo tcnico.

5. Revisiones tcnicas formales

Una revisin tcnica formal (RTF) es una actividad de garanta 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 funcin, la lgica o la implementacin de cualquier
representacin del software.

2. Verificar que el software bajo revisin alcanza sus requisitos.

3. Garantizar que el software ha sido representado de acuerdo con ciertos estndares
predefinidos.

4. Conseguir un software desarrollado de forma uniforme.

5. Hacer que los proyectos sean ms manejables.


6. Los estndares de calidad ISO-9000

Un sistema de garanta de calidad se puede definir como la estructura organizativa,
responsabilidades, procedimientos, procesos y recursos para implementar gestin de calidad.
ISO 9000 describe los elementos de garanta de calidad en trminos genricos que pueden
aplicarse a cualquier negocio con independencia de los productos o servicios ofrecidos.

6.1. El estndar ISO-9001

ISO 9001 es el estndar de garanta de calidad que se aplica a la ingeniera del software. El
estndar contiene 20 requisitos que deben estar presentes en un sistema de garanta de calidad
efectiva.

7. Gestin de configuracin software

La gestin de configuracin del software (GCS) es una actividad de autoproteccin que se
aplica a lo largo del proceso de ingeniera 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 ingeniera del software es una informacin que se puede dividir en
tres amplias categoras:

1. Programas de computadora (tanto en forma de cdigo fuente, como ejecutable)
2. Documentos que describen los programas de computadora (tantos tcnicos como de
usuario).
3. Datos (contenidos en el programa o externos a l).

Los elementos que componen toda la informacin producida como parte del proceso de
ingeniera del software se denomina colectivamente configuracin del software.


Mdulo III
SISTEMAS DE BASES DE DATOS


Captulo 10
Introduccin a los SGBD

Un sistema de gestin de bases de datos (SGBD) consiste en una coleccin de datos
interrelacionados y un conjunto de programas para acceder y manipular dichos datos.

La coleccin de datos, normalmente denominada base de datos, contiene informacin acerca
de una empresa particular.

El primer objetivo de un SGBD es proporcionar un entorno que sea tanto prctico como
eficiente de usar en la recuperacin y el almacenamiento de la informacin de la base de
datos.

Los sistemas de bases de datos deben proporcionar la fiabilidad de la informacin
almacenada, a pesar de las cadas del sistema o los intentos de acceso sin autorizacin. Si los
datos van a ser compartidos entre diversos usuarios, el sistema debe evitar posibles resultados
anmalos.

1. Propsito de los Sistemas de Bases de Datos

Considrese parte de una empresa de cajas de ahorro que mantiene informacin acerca de
todos los consumidores y cuentas de ahorro. Una manera de mantener la informacin en una
computadora es almacenarla en archivos del sistema permanentes. Para permitir a los usuarios
manipular la informacin, el sistema tiene un nmero de programas de aplicacin que
manipula los archivos, incluyendo:

Un programa para efectuar cargos o abonos en una cuenta.
Un programa para aadir 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 aaden nuevos programas de aplicacin al sistema.

El sistema de procesamiento de archivos tpico que se acaba de describir se mantiene
mediante un sistema operativo convencional.

Mantener la informacin de la organizacin en un sistema de procesamiento de archivos tiene
una serie de inconvenientes importantes:


Redundancia e inconsistencia de datos. La misma informacin puede estar
duplicada en diferentes lugares (archivos). Esta redundancia conduce a un
almacenamiento y coste de acceso ms altos. Adems, 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
prctica y eficiente.

Aislamiento de datos. Debido a que los datos estn dispersos en varios archivos, y
los archivos pueden estar en diferentes formatos, es difcil escribir nuevos programas
de aplicacin 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 aadiendo el cdigo apropiado en los diversos
programas de aplicacin. Sin embargo, cuando se aaden nuevas ligaduras, es difcil
cambiar los programas para hacer que se cumplan.

Problemas de atomicidad. Un sistema de una computadora, como cualquier otro
dispositivo mecnico o elctrico, 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 exista antes del fallo. Las operaciones deben ser
atmicas, es decir, cada operacin debe ocurrir por completo o no ocurrir en absoluto.
Es difcil asegurar esta propiedad en un sistema de procesamiento de archivos
convencional.

Anomalas en el acceso concurrente. Muchos sistemas han ido permitiendo a
mltiples usuarios actualizar los datos simultneamente. En tales sistemas un entorno
de interaccin de actualizaciones concurrentes puede dar lugar a datos inconsistentes.

Problemas de seguridad. No todos los usuarios de un sistema de bases de datos
deberan poder acceder a todos los datos. Como los programas de aplicacin se
aaden al sistema de una forma ad hoc, es difcil garantizar tales ligaduras de
seguridad.

Estas dificultades, entre otras, han dado comienzo al desarrollo de SGBD.

2. Visin de los datos

El propsito principal de un sistema de bases de datos es proporcionar a los usuarios una
visin abstracta de los datos. El sistema esconde ciertos detalles de cmo se almacenan y
mantienen los datos.

2.1. Abstraccin de Datos

Para que el sistema sea til, debe recuperar los datos eficientemente. Esta preocupacin ha
conducido al diseo de estructuras de datos complejas para la representacin de los datos en
la base de datos. Como muchos usuarios de sistemas de bases de datos no estn
familiarizados con computadoras, los desarrolladores esconden la complejidad a los usuarios
a travs de varios niveles de abstraccin para simplificar la interaccin de los usuarios con el
sistema:

Nivel fsico. El nivel ms bajo de abstraccin describe cmo se almacenan realmente
los datos. En el nivel fsico se describen en detalle las estructuras de datos complejas
de bajo nivel.

Nivel lgico. El siguiente nivel ms alto de abstraccin 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 informacin que se mantiene
en la base de datos, usan el nivel lgico de abstraccin.

Nivel de vistas. El nivel ms alto de abstraccin describe slo parte de la base de
datos completa. A pesar del uso de estructuras ms simples en el nivel lgico, queda
algo de complejidad, debido al gran tamao de la base de datos. Para que la
interaccin con el sistema se simplifique, se define la abstraccin del nivel de vistas.
El sistema puede proporcionar nuevas vistas para la misma base de datos.

Fig. 10-1. Niveles de abstraccin de datos

2.2. Instancias y Esquemas

La coleccin de informacin almacenada en la base de datos en un momento particular se
llama una instancia de la base de datos.

El diseo completo de la base de datos se llama el esquema de la base de datos.

Los sistemas de bases de datos tienen varios esquemas divididos, de acuerdo a los niveles de
abstraccin que se han visto. En el nivel ms bajo est el esquema fsico; en el nivel
intermedio est el esquema lgico, y en el nivel ms alto est el subesquema.

2.3. Independencia de Datos

La capacidad para modificar una definicin de esquema en un nivel sin que afecte a una
definicin de esquema en el siguiente nivel superior se llama independencia de datos. Hay
dos niveles de independencia de datos:

Independencia fsica de datos. Es la capacidad para modificar el esquema fsico sin
provocar que los programas de aplicacin tengan que reescribirse.

Independencia lgica de datos. Es la capacidad para modificar el esquema lgico
sin causar que los programas de aplicacin tengan que reescribirse.

La independencia de datos lgica es ms difcil de proporcionar que la independencia de
datos fsica, ya que los programas de aplicacin son fuertemente dependientes de la estructura
lgica 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 coleccin de
herramientas conceptuales para describir los datos, las relaciones de datos, la semntica de
los datos y las ligaduras de consistencia.

3.1. Modelos lgicos basados en objetos

Los modelos lgicos basados en objetos se usan para describir datos en los niveles lgico y de
vistas. Se caracterizan por el hecho de que proporcionan capacidades estructurales muy
flexibles y permiten que las ligaduras de datos sean especificadas explcitamente.

Varios de los modelos ms ampliamente conocidos son:

El modelo de entidad-relacin.
El modelo orientado a objetos.
El modelo de datos semntico.
El modelo de datos funcional.

3.1.1. Modelo entidad-relacin

El modelo de datos entidad-relacin (E-R) est basado en una percepcin del mundo real
que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre
estos objetos.

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 relacin es una asociacin entre varias entidades. Por ejemplo, una relacin 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.

Adems 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 nmero de entidades con las que otra
entidad se puede asociar a travs de un conjunto de relaciones.

La totalidad de estructuras lgicas de una base de datos se pueden expresar grficamente
mediante un diagrama E-R, que consta de los siguientes componentes:

Rectngulos, que representan conjuntos de entidades.
Elipses, que representan atributos.
Rombos, que representan relaciones entre conjuntos de entidades.
Lneas, que unen los atributos con los conjuntos de entidades y los conjuntos de
entidades con las relaciones.

Fig. 10-2. Diagrama entidad-relacin

3.1.2. Modelo orientado a objetos

Como el modelo E-R, el modelo orientado a objetos est basado en una coleccin de
objetos. Un objeto contiene valores almacenados en variables de instancia dentro de ese
objeto. Un objeto tambin contiene fragmentos de cdigo que operan en el objeto. Estos
fragmentos de cdigo se llaman mtodos.

Los objetos que contienen los mismos tipos de valores y los mismos mtodos se agrupan
juntos en clases.

La nica manera de que un objeto pueda acceder a los datos de otro objeto es mediante la
invocacin de un mtodo de ese otro objeto. Esta accin se llama paso de mensaje al otro
objeto. As, la interfaz de llamada de los mtodos de un objeto define la parte visible
externamente del objeto. La parte interna del objeto (las variables de instancia y el cdigo de
los mtodos) no son visibles externamente. El resultado es obtener dos niveles de abstraccin
de datos.

3.2. Modelos lgicos basados en registros

Los modelos lgicos basados en registros se usan para describir datos en los niveles lgico y
de vistas. En contraste con los modelos de datos basados en objetos, se usan tanto para
especificar la estructura lgica completa de la base de datos como para proporcionar una
descripcin de alto nivel de la implementacin.

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 nmero
fijo de campos o atributos, y cada campo tiene normalmente una longitud fija.

Los tres modelos basados en registros ms ampliamente aceptados son los que vamos a ver a
continuacin.

3.2.1. Modelo relacional

En el modelo relacional se usa una coleccin 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.


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
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.

Fig. 10-4. Ejemplo de base de datos en red


3.2.3. Modelo jerrquico

El modelo jerrquico 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-5. Ejemplo de base de datos jerrquica

3.3. Modelo de datos fsico

El modelo de datos fsico se usa para describir datos en un nivel ms bajo. En contraste con
el modelo de datos lgico, hay pocos modelos de datos fsicos 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 definicin de datos

Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas
mediante un lenguaje especial llamado lenguaje de definicin de datos (LDD). El resultado
de la compilacin 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.

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 manipulacin de datos

Los niveles de abstraccin se aplican no slo a la definicin o estructuracin de los datos,
sino tambin a la manipulacin de los datos. Por manipulacin de datos se quiere decir:

La recuperacin de informacin almacenada en la base de datos.
La insercin de informacin nueva en la base de datos.
El borrado de informacin de la base de datos.
La modificacin de informacin almacenada en la base de datos.

En el nivel fsico se deben definir algoritmos que permitan un acceso eficiente a los datos. En
los niveles ms altos de abstraccin se enfatiza la facilidad de uso.

Un lenguaje de manipulacin 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 bsicamente:

LMD procedimientales. Requieren que el usuario especifique qu datos se
necesitan y cmo obtener esos datos.

LMD no procedimientales. Requieren que el usuario especifique qu datos se
necesitan, sin especificar cmo obtener esos datos.

Una consulta es una instruccin de solicitud para recuperar informacin. La parte de un LMD
que implica la recuperacin de informacin se llama lenguaje de consultas.

5. Gestin de transacciones

Varias operaciones sobre la base de datos forman a menudo una nica unidad lgica de
trabajo.

Una transaccin es una coleccin de operaciones que se lleva a cabo como una funcin
lgica simple en una aplicacin de bases de datos. Cada transaccin 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 transaccin comenz, la base de
datos debe ser consistente cuando la transaccin 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 transaccin que falle no

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 transaccin en cuestin comenzara su ejecucin.

Finalmente, cuando varias transacciones actualizan la base de datos concurrentemente, la
consistencia de los datos puede no ser preservada, incluso aunque cada transaccin
individualmente sea correcta. Es responsabilidad del gestor de control de concurrencia
controlar la interaccin 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:

Definicin del esquema.
Estructura de almacenamiento y definicin del mtodo de acceso.
Esquema y modificacin de la organizacin fsica.
Concesin de la autorizacin para el acceso a los datos.
Especificacin 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 informticos que interactan
con el sistema a travs de llamadas al LMD, que estn incluidas en un programa
escrito en un lenguaje anfitrin. Estos programas comnmente se llaman programas
de aplicacin.

Los usuarios sofisticados interactan 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 estn los sistemas de diseo asistido por
computadora, sistemas de bases de conocimientos y expertos.

Usuarios normales. Son usuarios no sofisticados que interactan con el sistema
mediante la invocacin de alguno de los programas de aplicacin permanentes que se
han escrito previamente.

Captulo 11
Sistemas de BD en las
Organizaciones

1. Compartir datos y bases de datos

Quizs la diferencia ms 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 estn acostumbrados a sentirse dueos de los datos
resultantes de sus actividades cotidianas. Compartir los datos tambin requiere un cambio
importante en la forma en que se manejan y administran los datos dentro de la organizacin.

Se consideran tres formas de compartir los datos:

- Entre unidades funcionales.
- Entre los niveles de direccin.
- Entre localidades que estn geogrficamente dispersas.

1.1. Compartir datos entre unidades funcionales

El trmino compartir datos sugiere que personas en reas funcionales diferentes compartan
un grupo comn 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 ms valor que la suma de los datos en los archivos por separado.

A este fenmeno de combinar los datos para un uso comn se le llama integracin de datos.

1.2. Compartir datos entre diferentes niveles de usuarios

Diferentes niveles de usuarios necesitan compartir datos. Normalmente se distinguen tres
niveles de usuarios:
- Personal
- Mandos intermedios
- Ejecutivos

Estos niveles corresponden con los tres diferentes tipos de automatizacin de los sistemas de
negocios que han evolucionado durante las tres ltimas dcadas:

- Procesamiento electrnico de datos (PED)
- Sistemas de informacin de gestin (MIS)
- Sistemas de apoyo a la toma de decisiones (STD)

Fig. 11-1. Niveles y comparticin de datos entre unidades funcionales

Los PED se aplicaron por primera vez a los niveles operacionales ms bajos de la
organizacin para automatizar el trabajo en papel. Sus caractersticas bsicas incluyen:

Foco de atencin en el nivel operativo del almacenamiento, el procesamiento y el
flujo de datos.
Procesamiento eficiente de transacciones.
Informes resmenes para los dirigentes.

El enfoque de los MIS elevan el foco de atencin a las actividades de los sistemas de
informacin, con un nfasis adicional en la integracin y planificacin de la funcin de los
sistemas de informacin. En la prctica, estas caractersticas de los MIS incluyen:

Foco en la informacin orientada a los mandos intermedios.
Una integracin de las tareas de PED por sus funciones en los negocios, tales como
MIS de produccin, MIS de marketing, MIS de personal, etc.
Generacin de encuestas e informes, usualmente como una base de datos.

Un STD se centra en un nivel an ms alto dentro de la organizacin, con nfasis en las
caractersticas siguientes:

Sistema de
soporte a la
toma de
decisiones
Sistema de
informacin de
gestin
Sistema de
procesamiento
electrnico de datos
Ejecutivo
Dirigente
intermedio
Operativos
Informes Estratgicos
Consultas
Anlisis
Transacciones
Mantenimiento archivos
Procesamiento informes de control
Informes de direccin
por reas funcionales

Inters centrado en la decisin, orientado a dirigentes de alto nivel y ejecutivos que
toman decisiones.
nfasis en la flexibilidad, adaptabilidad y la respuesta rpida.
Apoyo a los estilos personales de toma de decisin 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 podran luego resumirse para la informacin que se necesita en niveles ms
altos. Los ejecutivos en el nivel ms alto usan los sistemas de apoyo a la decisin para
descubrir las tendencias a largo plazo que se pueden aplicar a su propia corporacin, as
como para identificar el entorno econmico, social y poltico en el que deben operar.

1.3. Compartir datos entre diferentes localidades

Una base de datos centralizada es una base de datos que est fsicamente situada en un
nico lugar, controlado por una sola computadora. La mayora de las funciones para las que
se crean las bases de datos se llevan a cabo ms fcilmente si la base de datos est
centralizada. Es decir, es ms fcil actualizar, hacer copias de seguridad, consultar y
controlar el acceso a una base de datos, si sabemos exactamente donde est y cul 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 lneas de comunicacin.

Los sistemas de bases de datos distribuidas son atractivos porque hacen posible la ubicacin
local de los datos: Los datos residirn en los lugares donde se necesitan con ms frecuencia.

Cuando una empresa comienza a distribuirse por distintas localidades, el tener una base de
datos centralizada, puede aumentar el tiempo de elaboracin 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. Planificacin estratgica de bases de datos

Moverse de una situacin en la que los datos son privados y fragmentados a una en la que los
datos son compartidos es ms fcil 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 realizacin y su utilizacin en una o varias bases de datos.

Un elemento esencial en este proceso es la planificacin de la base de datos. La planificacin
de la base de datos es un esfuerzo colectivo estratgico para determinar las necesidades de la
organizacin para un extenso perodo de tiempo en el futuro.

2.1. El proyecto de planificacin de la base de datos

La planificacin estratgica 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 informacin y en
otras reas funcionales de la compaa. Se recomienda un grupo de cuatro miembros a
tiempo completo, dos de sistemas de informacin y dos que estn familiarizados con la
mayora de las reas de la compaa. Todos los miembros del equipo deben ser empleados
cualificados y capaces, puesto que su trabajo tendr un gran impacto en la organizacin para
muchos aos.

Durante el proyecto, tal equipo interacta 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 informacin. El equipo de proyecto sintetiza estos datos en un modelo de
informacin corporativa que se incluye como parte de un comprensivo plan de base de datos.

Para que el proyecto cumpla sus objetivos dentro de la organizacin, ste no debera
demorarse ms de seis meses. Al cabo de ese tiempo, se debera entregar al director general
un informe que cubra al menos los prximos cinco aos. Este informe debe incluir el anlisis
de lo siguiente:

Necesidades de informacin de las reas funcionales.
Necesidades de informacin de los diferentes niveles de direccin.
Necesidades de informacin de las localidades geogrficas.
Un modelo de estas necesidades de informacin.
Volmenes anticipados de datos por localidad geogrfica para el perodo bajo
estudio.
Una estimacin 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 informacin detallado en este plan. Los
modelos detallados se deben desarrollar en los proyectos subsiguientes de diseo de la base
de datos. En lugar de esto, el equipo del proyecto debera identificar los elementos estables
de la estructura de la informacin de la organizacin, 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:

Informacin recolectada para determinar las necesidades de los usuarios.
El diseo del esquema de la base de datos (estructura lgica) para satisfacer esas
necesidades.

La seleccin de un SGBD para dar soporte al uso de la base de datos.
El desarrollo de programas para utilizar la base de datos.
Una revisin de las necesidades de informacin de los usuarios en el contexto de la
base de datos desarrollada.

3. Bases de datos y gestin de control

Al ser un recurso de la compaa que es de un valor significativo, la base de datos requiere de
proteccin y control. Esta responsabilidad usualmente se le asigna al administrador de la
base de datos (ABD).

Las funciones del ABD incluyen:

Diseo de la base de datos.
Formacin del usuario.
Seguridad e integridad de la base de datos.
Rendimiento de la base de datos.

3.1. Diseo de bases de datos

El diseo conceptual de la base de datos consiste primariamente en la definicin 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 estratgico en la definicin y establecimiento de los estndares de la
compaa. Puesto que el diseo de la base de datos se controla centralmente, el ABD puede
definir estndares sobre cmo 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
documentacin y los requisitos de entrenamiento y facilita la integracin de los sistemas
dentro de la compaa.

Las decisiones de diseo 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. Formacin del usuario

Muchas de las ventajas resultantes de compartir los datos slo pueden manifestarse en la
prctica si los usuarios entienden cmo 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
travs del SGBD.


3.3. Seguridad e integridad de los datos

El concepto de combinar los datos en una organizacin en un lugar comn 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 daar 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 organizacin. Este acceso se puede restringir a porciones de los datos,
permitir el acceso slo para la recuperacin, o permitir acceso y actualizacin. La
informacin 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 precisin y
consistencia de los valores de los datos. Los mecanismos de seguridad, tales como las
contraseas 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 simultneamente muchos usuarios puede
responder a veces muy lentamente debido a que los problemas fsicos asociados a los usuarios
que estn compitiendo por los recursos no son triviales.

El equipo de ABD debe diagnosticar y resolver los problemas de tiempo de respuesta del
sistema. La solucin del problema puede implicar la compra de hardware, la construccin de
ndices para el acceso rpido a grandes volmenes de datos, etc.

4. Riesgos y costos de las bases de datos

El efecto sinrgico de las bases de datos, la estandarizacin del diseo de los datos, los
procedimientos de manipulacin, los beneficios de seguridad, el poder de los lenguajes de
manipulacin 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 tambin sus inconvenientes.

4.1. Conflictos en las organizaciones

Poner los datos en una base de datos comn puede que no sea polticamente 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 integracin de los mismos. Es ms,
el riesgo que implica compartir datos (por ejemplo, un grupo puede daar los datos de otro

grupo) y los problemas potenciales del sistema que pueden limitar los accesos de un grupo a
sus propios datos pueden ser vistos ms 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 estn 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 podra 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 compaa. Si no puede encontrarse personal para
reemplazarlo, entonces el proyecto pudiera no terminarse con xito.

4.3. Malfuncionamiento del sistema

Cuando el sistema de cmputo 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 aplicacin falla, esto pudiera ocasionar un
dao permanente en la base de datos.

Un sistema de base de datos distribuida tambin reduce el riesgo de averas 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 ms 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 organizacin en particular. No obstante, estos recursos pueden costar
dinero y usar disco y memoria del sistema.

El SGBD puede tambin aumentar los costos de operacin, ya que requiere mayor tiempo de
ejecucin.

5. Desarrollo de la base de datos

Esta seccin se centrar en el procedimiento de desarrollo del esquema conceptual de la
base de datos, identificando los datos que se incluirn 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. Planificacin preliminar

La planificacin preliminar de un sistema de base de datos especfico tiene lugar durante el
proyecto de planificacin estratgica de la base de datos. Durante este proceso, la firma
recoge informacin para responder a las preguntas siguientes:

Cuntos programas de aplicacin estn en uso y qu funciones realizan?
Qu archivos estn asociados con cada una de las aplicaciones?
Qu nuevas aplicaciones y archivos estn bajo desarrollo?

Tambin ayuda a identificar futuros requisitos del sistema y para apreciar los beneficios
econmicos 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 preparacin de un informe con las caractersticas
siguientes:

Viabilidad tecnolgica. Hay tecnologa adecuada disponible para dar soporte al
desarrollo de la base de datos?
Viabilidad operacional. Tiene la compaa personal, presupuesto y experiencia
interna para hacer que un sistema de base de datos tenga xito?
Viabilidad econmica. Se pueden identificar los beneficios? Los beneficios
costearan el sistema que se desea? Se pueden medir los costos y los beneficios?

5.3. Definicin de requisitos

La definicin de los requisitos involucra a la definicin del alcance de la base de datos, la
identificacin de requisitos de informacin de las reas funcionales y administrativas y la
determinacin de los requisitos de software y el hardware.

Los requisitos de informacin se determinan por las respuestas a cuestionarios, entrevistas
con los directivos y usuarios de oficina y los informes y formularios que estn en uso
actualmente.

El modelo de informacin general que se crea durante la planificacin de la base de datos se
expande a modelos para cada una de las reas funcionales. Estas son las bases para el
diseo detallado de la base de datos que se llevar a cabo en la etapa siguiente.


5.4. Diseo conceptual

La etapa de diseo conceptual crea el esquema conceptual de la base de datos. Se
desarrollan las especificaciones hasta el punto en que puede comenzar la implementacin.
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. Implementacin

Durante la implementacin de la base de datos se selecciona y adquiere un SGBD. Luego el
modelo conceptual detallado se convierte al modelo de implementacin del SGBD, se
construye el diccionario de datos, se puebla la base de datos, se desarrollan los programas de
aplicacin y se entrenan los usuarios.

5.6. Evaluacin y perfeccionamiento del esquema de la BD

La evaluacin 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,
introducindole mejoras y aadindole nuevos programas y elementos de datos en la medida
que cambian y se amplan las necesidades del negocio.



Mdulo IV
SISTEMAS DISTRIBUIDOS
Y REDES


Captulo 12
Comunicacin de datos y
redes de ordenadores

1. Introduccin

1.1. Redes y sistemas distribuidos

Usaremos el trmino red de computadoras para referirnos a una coleccin interconectada de
computadoras autnomas.

Se dice que dos computadoras estn interconectadas si son capaces de intercambiar
informacin.

Al indicar que las computadoras son autnomas, queremos excluir de nuestra definicin a los
sistemas en los que existe una clara relacin amo-esclavo. Si una computadora puede
arrancar, parar o controlar otra a voluntad, las computadoras no son autnomas. Un sistema
con una unidad de control y muchos esclavos no es una red; tampoco lo es una computadora
grande con impresoras y terminales remotas.

Existe considerable confusin entre la red de computadoras y un sistema distribuido. La
diferencia radica en que en el sistema distribuido la existencia de mltiples computadoras
autnomas es transparente para el usuario. El usuario puede teclear una orden para ejecutar un
programa y ste se ejecutar. La tarea de seleccionar el mejor procesador, encontrar y
transportar todos los archivos de entrada al procesador y poner los resultados en el lugar
apropiado, corresponde al sistema operativo.

En una red, el usuario debe ingresar de forma explcita en una mquina, enviar los trabajos
remotos explcitamente, mover explcitamente 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
forma explcita; el sistema lo hace todo automticamente sin que el usuario tenga
conocimiento de ello.

En efecto, un sistema distribuido es un sistema de software construido encima de una red, a
la que el software confiere un alto grado de cohesin y transparencia. As, la distincin entre
una red y un sistema distribuido tiene que ver con el software ms que con el hardware
(especialmente el sistema operativo).

1.2. Un modelo para las comunicaciones

Fig. 12-1. Modelo de comunicaciones

El objetivo principal de todo sistema de comunicaciones es intercambiar informacin entre
dos entidades. En la figura podemos ver un ejemplo particular de comunicacin entre una
estacin de trabajo y un servidor a travs de una red telefnica pblica. Otro posible ejemplo
es el intercambio de seales de voz entre dos telfonos a travs de la misma red anterior. Los
elementos clave en este modelo son los siguientes:

La fuente. Este dispositivo genera los datos a transmitir; por ejemplo telfonos o
computadores personales.

El transmisor. Normalmente los datos generados por la fuente no se transmiten
directamente como son generados. Al contrario, el transmisor transforma y codifica la
informacin produciendo seales electromagnticas susceptibles de ser transmitidas a
travs de algn sistema de transmisin. Por ejemplo, un modem convierte las cadenas
de bits generadas por un computador personal y los transforma en seales analgicas
que pueden ser transmitidas a travs de la red telefnica.

El sistema de transmisin, que puede ser desde una simple lnea de transmisin
hasta una compleja red que conecte la fuente con el destino.

El receptor, que acepta la seal proveniente del sistema de transmisin y la
convierte de tal manera que pueda ser manejada por el dispositivo destino. Por
ejemplo, un modem aceptar la seal analgica de la red o lnea de transmisin y la
convertir en una cadena de bits.

El destino, que toma los datos del receptor.

Para que un dispositivo pueda transmitir tendr que hacerlo a travs de la interfaz con el
medio de transmisin. Una vez que la interfaz est establecida, se necesitar la generacin
de la seal. Las caractersticas de la seal, es decir, la forma y la intensidad, deben ser tales
que permitan 1) interpretar la seal y 2) ser interpretada en el receptor como datos.

Las seales se deben generar no solamente considerando que deben cumplir los requisitos del
sistema de transmisin 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 seal recibida. Igualmente deber conocer la duracin de cada elemento de la seal.

Adems de las cuestiones bsicas referentes a la naturaleza y temporizacin de las seales, se
necesitar un conjunto de requisitos que se deben verificar y que se pueden englobar bajo el
trmino gestin 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
necesitarn ciertas convenciones adems del simple hecho de establecer la conexin. Por
ejemplo se deber establecer si ambos dispositivos pueden transmitir simultneamente 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 seal
transmitida se distorsiona de alguna manera antes de alcanzar su destino. Por tanto, en
circunstancias donde no se puedan tolerar errores, se necesitarn procedimientos para la
deteccin y correccin de errores.

Para evitar que la fuente no sature al destino transmitiendo datos ms rpidamente 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 ms de dos dispositivos, el sistema
fuente deber de alguna manera indicar a dicho recurso compartido la identidad del destino.
El sistema de transmisin deber garantizar que ese y slo ese destino reciba los datos. Es
ms, el sistema de transmisin puede ser una red donde haya la posibilidad de ms de un
camino para alcanzar el destino; en este caso se necesitar por tanto la eleccin de una de
entre las posibles rutas.

La recuperacin es un concepto distinto a la correccin de errores. En ciertas situaciones en
las que el intercambio de informacin, por ejemplo una transaccin de una base de datos o la
transferencia de un fichero, se vea interrumpida por algn fallo, se necesitar un mecanismo
de recuperacin. El objetivo ser pues, o bien ser capaz de continuar transmitiendo desde
donde se produjo la interrupcin, 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 cdigo binario para representar los caracteres.


Adems, frecuentemente es necesario dotar al sistema de algunas medidas de seguridad. El
emisor debe asegurarse de que slo el destino deseado reciba los datos. Igualmente, el
receptor querr estar seguro de que los datos recibidos no se han alterado en la transmisin y
que dichos datos realmente provienen del supuesto emisor.

2. Usos de las redes de computadoras

2.1. Redes para compaas

Muchas organizaciones tienen una cantidad importante de computadoras en operacin, con
frecuencia alejadas entre s. Por ejemplo, una compaa con muchas fbricas puede tener una
computadora en cada localidad para llevar el control de los inventarios, vigilar la
productividad y pagar la nmina local. Inicialmente, cada una de estas computadoras puede
haber trabajado aislada de las otras, pero en algn momento la gerencia decidi conectarlas
para poder extraer y correlacionar informacin acerca de toda la compaa.

La cuestin aqu es compartir los recursos y la meta es hacer que todos los programas, el
equipo y especialmente los datos estn disponibles para cualquiera en la red, sin importar la
localizacin fsica 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 podran replicarse en dos o tres mquinas; as, si
una de ellas no est disponible, podrn usarse las otras copias.

Otra meta es ahorrar dinero. Las computadoras pequeas tienen una relacin
precio/rendimiento mucho mejor que las grandes. Las mainframes son aproximadamente 10
veces ms rpidas que las computadoras personales, pero cuestan 1000 veces ms. Este
desequilibrio ha ocasionado que muchos diseadores construyan sistemas compuestos por
computadoras personales, una por usuario, con los datos guardados en una o ms mquinas
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, aadiendo solamente
ms procesadores.

Un objetivo ms del establecimiento de una red de computadoras tiene poco que ver con la
tecnologa. Una red de computadoras puede proporcionar un potente medio de comunicacin
entre empleados que estn muy distantes. Al usar una red, es fcil para dos o ms personas
que viven lejos escribir un informe juntas.

A largo plazo, el uso de redes para mejorar la comunicacin entre las personas probablemente
resultar ms importante que las metas tcnicas tales como la mejora de la confiabilidad.

2.2. Redes para la gente

Al iniciar la dcada de 1990, las redes de computadoras comenzaron a prestar servicios a
particulares en su hogar. Estos servicios y la motivacin para usarlos son muy diferentes del
modelo de eficiencia corporativa descrito en la seccin anterior. A continuacin
esbozaremos tres de los ms estimulantes aspectos de esta evolucin:

Acceso a informacin remota.
Comunicacin persona a persona.
Entretenimientos interactivos.

El acceso a informacin 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 electrnica.

Los peridicos se publicarn en lnea y sern personalizados.

Otra aplicacin en sta categora es el acceso a sistemas de informacin como la actual red
mundial (World Wide Web), la cual contiene informacin sobre arte, negocios, cocina,
gobierno, salud, historia, aficiones, recreacin, ciencia, deportes, viajes y muchos otros temas.

Millones de personas utilizan ya el correo electrnico 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 categora es el entretenimiento, juegos de simulacin en tiempo real
multipersonales, simuladores de vuelo en los que los jugadores de un equipo tratan de
derribar a los del equipo contrario, ...

3. Hardware de red

Vamos a ver una clasificacin de las redes en funcin de su escala.

Distancia entre
procesadores
Ubicacin
procesadores
Ejemplo
0,1 m Tarjeta de circuitos Procesador paralelo
1 m Sistema Multicomputadora
10 m Cuarto
100 m Edificio
1 km Campus
Red de rea local
10 km Ciudad Red de rea metropolitana
100 km Pas
1.000 km Continente
Red de rea amplia
10.000 km Planeta Internet

Fig. 12-2. Clasificacin de redes segn su escala


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 kilmetros de
extensin. Se usan ampliamente para conectar computadoras personales y estaciones de
trabajo en oficinas de compaas y fbricas con objeto de compartir recursos (por ejemplo
impresoras) e intercambiar informacin. Las LAN se distinguen de otro tipo de redes por tres
caractersticas: Su tamao, su tecnologa de transmisin y su topologa.

Las LAN estn restringidas en tamao, lo cual significa que el tiempo de transmisin del
peor caso est limitado y se conoce de antemano. Conocer este lmite hace posible usar
ciertos tipos de diseos que de otra manera no seran prcticos, y tambin simplifica la
administracin de la red.

Las LAN a menudo usan una tecnologa de transmisin que consiste en un cable sencillo al
cual estn conectadas todas las mquinas.

Las LAN de transmisin pueden tener diversas topologas; la figura muestra dos de ellas.

Fig. 12-3. Topologa de redes. a) Bus. b) En anillo

En una red de bus (esto es, un cable lineal), en cualquier instante una computadora es la
mquina maestra y puede transmitir; se pide a las otras mquinas que se abstengan de enviar
mensajes. Es necesario un mecanismo de arbitraje para resolver conflictos cuando dos o ms
mquinas quieren transmitir simultneamente.

Un segundo tipo de sistema de difusin es el anillo. En un anillo, cada bit se propaga por s
mismo, sin esperar al resto del paquete al cual pertenece. Tpicamente, cada bit recorre el
anillo entero en el tiempo que toma transmitir unos pocos bits, a veces antes de que el paquete
entero se haya transmitido. Como en todos los sistemas de difusin, se necesitan reglas para
arbitrar el acceso simultneo al anillo.

3.2. Redes de rea metropolitana

Una red de rea metropolitana o MAN (metropolitan area network) es bsicamente una
versin ms grande de una LAN y normalmente se basa en una tecnologa similar. Podra
abarcar un grupo de oficinas corporativas cercanas o una ciudad y podra ser privada o
pblica. Una MAN slo tiene uno o dos cables y no contiene elementos de conmutacin, lo
cuales desvan los paquetes por una de varias lneas de salida potenciales. Al no tener que
conmutar se simplifica el diseo.

3.3. Redes de rea amplia

Una red de rea amplia o WAN (wide area network), se extiende sobre un rea geogrfica
extensa, a veces un pas o un continente; contiene una coleccin de mquinas dedicadas a
ejecutar programas de usuario. Seguiremos el uso tradicional y llamaremos a estas mquinas
hosts. Los hosts estn conectados por una subred de comunicacin, o simplemente subred.
El trabajo de la subred es conducir mensajes de un host a otro. La separacin entre los
aspectos exclusivamente de comunicacin de la red y los aspectos de aplicacin, simplifica
enormemente el diseo total de la red.

En muchas redes de rea amplia, la subred tiene dos componentes distintos: las lneas de
transmisin y los elementos de conmutacin.

Las lneas de transmisin (tambin llamadas circuitos o canales) mueven bits de una
mquina a otra.

Los elementos de conmutacin son computadoras especializadas que conectan dos o ms
lneas de transmisin. Cuando los datos llegan por una lnea de entrada, el elemento de
conmutacin debe escoger una lnea de salida para reenviarlos. Para las computadoras de
conmutacin usaremos la palabra enrutador.

Fig. 12-4. Interconexin en una red de rea amplia

Cuando se enva un paquete de un enrutador a otro a travs de uno o ms enrutadores
intermedios, el paquete se recibe completo en cada enrutador intermedio, se almacena hasta
que la lnea de salida requerida est libre, y a continuacin se reenva. Una subred basada en
este principio se llama de punto a punto.

Cuando se usa una subred punto a punto, una consideracin de diseo importante es la
topologa de interconexin del enrutador. Podemos ver algunas a continuacin:

Fig. 12-5. Topologas de interconexin de enrutadores. a) Estrella. b) Anillo. c) rbol. d) Totalmente
conectada. e) Doble anillo. f) Irregular

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
mquinas llamadas pasarelas para hacer la conexin y realizar la traduccin necesaria, ambas
en trminos de hardware y software. Una coleccin de redes interconectadas se llama
interred.

Captulo 13
Ingeniera del Software
Cliente/Servidor

1. Estructura de los sistemas cliente/servidor

Las tecnologas 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 ms
general, una arquitectura de computadora distribuida y cooperativa se ilustra en la siguiente
figura:

Fig. 13-1. Arquitectura de ordenadores distribuida en una corporacin

Un sistema raz, que tpicamente ser una gran computadora, acta como depsito de los
datos corporativos. El sistema raz est conectado con servidores y que poseen un doble
papel. Los servidores actan para actualizar y solicitar datos corporativos mantenidos por el
sistema raz. Adems mantienen sistemas departamentales locales y desempean un papel
clave al poner en red los PC del nivel de usuario a travs 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 nmero de implementaciones distintas:

Servidores de archivos. El cliente solicita registros especficos de un archivo. El
servidor transmite estos registros al cliente a travs de la red.

Servidores de bases de datos. El cliente enva solicitudes en lenguaje de consulta
estructurado (SQL) al servidor. stas se transmiten como mensajes a travs de la red.
El servidor procesa la solicitud SQL y halla la informacin solicitada, pasando
nicamente los resultados al cliente.

Servidores de transacciones. El cliente enva una solicitud que invoca
procedimientos remotos en el centro servidor. Los procedimientos remotos pueden ser
un conjunto de sentencias SQL. Se produce una transaccin cuando una solicitud da
lugar a la ejecucin de procedimientos remotos y a la transmisin del resultado al
cliente.

Servidores de grupos de trabajo. Cuando el servidor proporciona un conjunto de
aplicaciones que hacen posible la comunicacin entre clientes (y las personas que los
usan) mediante el uso de texto, imgenes, boletines electrnicos, 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
mquinas:

Componente de interaccin con el usuario y presentacin. Este componente
implementa todas las funciones que tpicamente se asocian a una interfaz grfica de
usuario (IGU).

Componente de aplicacin. Este componente implementa los requisitos definidos
por la aplicacin en el contexto del dominio en el cual funciona la aplicacin. El
software de aplicacin se puede descomponer de tal modo que alguno de los
componentes residan en el cliente y otros residan en el servidor.

Gestin de bases de datos. Este componente lleva a cabo la manipulacin y gestin
de datos requerida por una aplicacin. La manipulacin y gestin de datos puede ser
tan sencilla como la transferencia de un registro, o tan compleja como el
procesamiento de sofisticadas transacciones SQL.

Adems de estos componentes, existe otro bloque de construccin 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 aplicacin especializado
que presta su apoyo a las aplicaciones especficas de bases de datos, a estndares de
distribucin de solicitudes de objetos, a tecnologas de trabajo en grupo, a gestin de
comunicaciones, y a otras caractersticas que facilitan la conexin cliente/servidor.

3. Distribucin de componentes de software

Una vez que se han determinado los requisitos bsicos de una aplicacin cliente/servidor,
debe decidirse la forma en que se distribuirn 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 diseo de servidor principal. A la inversa, cuando el
cliente implementa la mayor parte de los componentes de interaccin/presentacin con el
usuario, de aplicacin y de bases de datos, se tiene un diseo 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
gestin de datos, pero todo el software de aplicacin y de IGU reside en el cliente.

Los servidores principales son los que suelen disearse cuando se implementan sistemas de
transacciones y de trabajo en grupo. El servidor proporciona el apoyo de la aplicacin
necesario para responder a transacciones y comunicaciones que provengan de los clientes. El
software de cliente se centra en la gestin de IGU y de comunicaciones.

4. Lneas generales para distribuir componentes de
aplicaciones

An cuando no existen reglas absolutas que describan la distribucin de componentes de
aplicaciones entre el cliente y el servidor, suelen seguirse las siguientes lneas generales:

El componente de presentacin/interaccin suele ubicarse en el cliente. La
disponibilidad de entornos basados en ventanas y de la potencia de cmputo necesaria
para una interfaz grfica de usuario hace que este enfoque sea eficiente en trminos de
coste.

Si es necesario compartir la base de datos entre mltiples usuarios conectados a
travs de la LAN, entonces la base de datos suele ubicarse en el servidor. El sistema
de gestin de la base de datos y la capacidad de acceso a la base de datos tambin se
asignan al servidor, junto con la base de datos fsica.

Los datos estticos que se utilicen como referencia deberan de asignarse al cliente.
Esto sita los datos ms prximos al usuario que tiene necesidad de ellos, y minimiza
un trfico de red innecesario y la carga del servidor.

El resto de los componentes de aplicacin se distribuye entre cliente y servidor basndose en
la distribucin que optimice las configuraciones de cliente y servidor y de la red que los
conecta.



Mdulo V
SISTEMAS DE AYUDA A LA
TOMA DE DECISIONES


Captulo 14
Ingeniera del Software
asistida por computadora

1. Definicin de CASE

El mejor taller de un artesano (sea mecnico, carpintero o ingeniero del software) tiene tres
caractersticas fundamentales:

- Una coleccin de herramientas tiles que le ayudarn en todos los pasos de la
construccin de un producto.

- Una disposicin organizada que permite hallar rpidamente 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 ingeniera del software se denomina entorno de apoyo de proyectos
integrados, y el conjunto de herramientas que llena ese taller se denomina ingeniera 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 visin general de la ingeniera. Al igual que las herramientas de ingeniera y
de diseo asistidos por computadora que utilizan los ingenieros de otras disciplinas, las
herramientas CASE ayudan a asegurar que la calidad sea algo diseado antes de llegar a
construir el producto.

2. Niveles de integracin CASE

Algunas herramientas CASE siguen siendo soluciones puntuales, es decir, se utiliza una
herramienta que preste su apoyo en una actividad de ingeniera del software concreta (p.e.
anlisis 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-

CASE). An cuando esta situacin no es ideal, se puede utilizar una herramienta CASE
eficientemente, aunque se trate de una solucin puntual.

Los niveles relativos de integracin CASE se muestran en la siguiente figura:

Fig. 14-1. Niveles relativos de integracin CASE

En el extremo inferior del espectro de integracin se encuentra la herramienta individual
(solucin puntual).

Cuando las herramientas individuales proporcionan capacidades adecuadas para el
intercambio de datos (tal como hace la mayora), el nivel de integracin mejora ligeramente.
Estas herramientas producen su salida en un formato estndar que debera 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 anlisis y diseo que se
enlaza con un generador de cdigo). Mediante el uso de este enfoque, la sinergia entre
herramientas puede producir unos resultados finales que sera difcil crear empleando cada
una de las herramientas por separado.

La integracin de fuente nica se produce cuando un nico vendedor de herramientas
CASE integra un cierto nmero de herramientas distintas y las vende en forma de paquete.
An cuando este enfoque es bastante eficiente, la arquitectura cerrada de la mayora de los
entornos de fuente nica evita una adicin sencilla de herramientas procedentes de otros
fabricantes.

En el extremo superior del espectro de integracin se encuentra el entorno de apoyo de
proyectos integrado (EAPI). Se crean estndares para cada uno de los bloques de

construccin descritos anteriormente. Los fabricantes de herramientas CASE utilizan estos
estndares EAPI para construir herramientas que sean compatibles con el EAPI, y que por
tanto sean compatibles entre s.

3. Taxonoma de herramientas CASE

Las herramientas CASE se pueden clasificar por su funcin, por su papel como instrumentos
para administradores, por su utilizacin en los distintos pasos del proceso de ingeniera del
software. La taxonoma presentada utiliza como criterio principal la funcin.

Herramientas de ingeniera de la informacin.

Al modelar los requisitos de informacin estratgica de una organizacin, las
herramientas de la ingeniera de la informacin proporcionan un metamodelo del cual
se derivan sistemas de informacin especficos.

El objetivo primordial de las herramientas de esta categora 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 compaa.

Modelado de procesos y herramientas de administracin.

Si una organizacin 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 planificacin de proyectos.

Se concentran en dos reas primordiales: estimacin de esfuerzos de proyecto y de
costes de software, y planificacin de proyectos.

Las herramientas de estimacin calculan el esfuerzo estimado, la duracin del
proyecto y el nmero recomendado de personas.

Las herramientas de planificacin 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 grfica), para representar las
interdependencias entre tareas y para modelar la cantidad de paralelismo que sea
posible para ese proyecto.

Herramientas de anlisis de riesgos.

La identificacin 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 gua detallada en la identificacin y anlisis de riesgos.

Herramientas de administracin de proyectos.

La planificacin del proyecto y el plan del proyecto deben seguirse y monitorizarse de
forma continua. Adems, el gestor deber utilizar las herramientas que recojan
mtricas que en ltima instancia proporcionen una indicacin de loa calidad del
producto de software. Las herramientas de esta categora suelen ser extensiones de
herramientas de planificacin 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 sistemtico para el aislamiento
de requisitos, comenzando por la solicitud del cliente de una propuesta o
especificacin. Las herramientas de trazado de requisitos tpicas combinan una
evaluacin de textos por interaccin humana, con un sistema de gestin de bases de
datos que almacena y categoriza todos y cada uno de los requisitos del sistema que se
analizan a partir de la especificacin original.

Herramientas de mtricas y gestin.

Las mtricas 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 mtricas y herramientas de medida actuales se centran
en procesos, proyectos y caractersticas del producto.

Basndose en caractersticas 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 documentacin.

Las herramientas de produccin de documentos y de autoedicin prestan su apoyo a
casi todos los aspectos de la ingeniera del software, y representan una importante
oportunidad de aprovechamiento para todos los desarrolladores de software.

Herramientas de control de calidad.

La mayor parte de las herramientas CASE que afirman que tienen como principal
inters el control de calidad son en realidad herramientas mtricas que hacen una
auditora del cdigo fuente para determinar si se ajusta o no a ciertos estndares del
lenguaje.

Herramientas de gestin de bases de datos.

El software de gestin de bases de datos sirve como fundamento para establecer una
base de datos CASE, que tambin se denominar base de datos del proyecto.

Herramientas de gestin de configuracin de software.

La gestin de configuracin de software (GCS) se encuentra en el ncleo de todos los
entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas
principales de GCS: identificacin, control de versiones, control de cambios,
auditora y contabilidad de estados.

Herramientas de anlisis y diseo.

Las herramientas de anlisis y diseo capacitan al ingeniero del software para crear
modelos del sistema que haya que construir. Los modelos contienen una
representacin de los datos, de la funcin y del comportamiento (en el nivel de
anlisis), as como caracterizaciones del diseo de datos, arquitectura, procedimientos
e interfaz.

Herramientas PRO/SIM.

Las herramientas PRO/SIM (de prototipos y simulacin) proporcionan al ingeniero
del software la capacidad de predecir el comportamiento de un sistema en tiempo real
antes de llegar a construirlo.

Adems, capacitan al ingeniero del software para desarrollar simulaciones del sistema
de tiempo real que permitirn al cliente obtener ideas acerca de su funcionamiento,
comportamiento, y respuesta antes de la verdadera implementacin.

Herramientas de desarrollo y diseo de interfaz.

Las herramientas de desarrollo y diseo de interfaz son en realidad un conjunto de
primitivas de componente de programas tales como mens, botones, estructuras de
ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivo, etc.


Herramientas de generacin de prototipos.

Se pueden utilizar toda una gama de herramientas de generacin de prototipos. Los
generadores de pantallas permiten al ingeniero de software definir rpidamente la
disposicin de la pantalla para aplicaciones interactivas.

Otras herramientas de prototipos CASE ms sofisticadas permiten la creacin de un
diseo de datos, acoplado con las disposiciones de la pantalla y de los informes
simultneamente.

Herramientas de programacin.

La categora de herramientas de programacin abarca los compiladores, editores y
depuradores que estn disponibles para prestar su apoyo en la mayora de los
lenguajes de programacin convencionales.

Adems, los entornos de programacin orientados a objetos, los lenguajes de cuarta
generacin, los entornos de programacin grfica, los generadores de aplicaciones, y
los lenguajes de consulta de bases de datos residen tambin en esta categora.

Herramientas de anlisis esttico.

Las herramientas de anlisis esttico prestan su asistencia al ingeniero de software a
efectos de derivar casos de prueba prcticos.

Las herramientas de comprobacin basadas en cdigo admiten un cdigo fuente
como entrada, y efectan un cierto nmero de anlisis que dan lugar a la generacin
de casos de prueba.

Los lenguajes de comprobacin especializados capacitan al ingeniero del software
para escribir detalladas especificaciones de comprobacin que describirn todos los
casos de prueba y la logstica de su ejecucin.

Las herramientas de comprobacin basadas en requisitos aslan requisitos especficos
del usuario y sugieren casos de prueba que ejerciten estos requisitos.

Herramientas de anlisis dinmico.

Las herramientas de anlisis dinmico interactan con un programa que se est
ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del
valor de variables especficas y en general instrumentan el flujo de ejecucin del
programa.

Herramientas de comprobacin cliente/servidor.

El entorno C/S exige unas herramientas de comprobacin especializadas que ejerciten
la interfaz grfica de usuario y los requisitos de comunicaciones en red para el cliente
y el servidor.

Herramientas de reingeniera.

Esta categora puede subdividirse en las funciones siguientes:

Herramientas de ingeniera inversa para producir especificaciones.

Se toma el cdigo fuente como entrada y se generan modelos grficos de anlisis y
diseo estructurados, listas de utilizacin y otras informaciones de diseo.

Herramientas de reestructuracin y anlisis de cdigo.

Se analiza la sintaxis del programa, se genera una grfica de control de flujo y se
genera automticamente un programa estructurado.

Herramientas de reingeniera para sistemas en lnea.

Se utilizan para modificar sistemas de bases de datos en lnea (p.e. para convertir
archivos IDMS o DB2 traducindolos 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 ingeniera del software por separado, la verdadera potencia de CASE
solamente se puede lograr mediante la integracin.

Los beneficios del CASE integrado (I-CASE) incluyen:

- Una transferencia suave de informacin (modelos, programas, documentos, datos)
entre una herramienta y otra, y entre un paso de ingeniera y el siguiente.

- Una reduccin del esfuerzo necesario para efectuar actividades globales tales como
la administracin de configuracin de software, el control de calidad y la produccin
de documentos.

- Un aumento del control del proyecto que se logra mediante una mejor planificacin,
monitorizacin y comunicacin.

- Una mejor coordinacin entre los miembros del personal que estn trabajando en
grandes proyectos de software.

Para definir la integracin en el contexto del proceso de software, es necesario establecer un
conjunto de requisitos para I-CASE. Un entorno CASE integrado debera de:

- Proporcionar un mecanismo para compartir la informacin de ingeniera del software
entre todas las herramientas que estn contenidas en el entorno.

- Hacer posible que un cambio de un elemento de informacin se siga hasta los dems
elementos de informacin relacionados.

- Proporcionar un control de versiones y una gestin de configuracin general para
toda la informacin de la ingeniera 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 ingeniera 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
utilizacin consistente en la interfaz hombre-mquina.

- Permitir la comunicacin entre ingenieros del software.

- Recoger mtricas tanto de gestin como tcnicas que se puedan utilizar para mejorar
el proceso y el producto.

5. La arquitectura de integracin

Un equipo de ingeniera del software utiliza herramientas CASE, los mtodos
correspondientes y un marco de referencia de proceso con objeto de crear un conjunto de
informaciones de ingeniera del software.

El marco de referencia de integracin facilita la transferencia de informacin desde y hacia
ese conjunto de informaciones. Para lograr esto, deben existir los siguientes componentes de
arquitectura:

- Una base de datos para almacenar la informacin.
- Un sistema de administracin de objetos que gestione los cambios efectuados en
la informacin.
- Un mecanismos de control de herramientas que coordine la utilizacin 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.

La mayora de los modelos del marco de referencia de integracin 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 integracin

La capa de interfaz de usuario incorpora un conjunto de herramientas de interfaz
estandarizado, con un protocolo de presentacin comn.

El kit de herramientas de interfaz contiene software para la gestin de la interaccin
hombre-mquina, y una biblioteca de objetos de visualizacin. Ambos proporcionan
un mecanismo consistente para la comunicacin entre la interfaz y las herramientas
CASE individuales.

El protocolo de presentacin es el conjunto de lneas generales que proporciona a
todas las herramientas CASE un mismo aspecto. Las convenciones de distribucin de
pantalla, los nombres de men y la organizacin, los iconos, los nombres de los
objetos, la utilizacin del teclado y el ratn, y el mecanismo para acceder a las
herramientas se definen todos ellos como parte del protocolo de presentacin.

La capa de herramientas contiene un conjunto de servicios de gestin de herramientas con
las herramientas CASE en s. Los servicios de gestin de herramientas (TMS) controlan el
comportamiento de las herramientas dentro del entorno. Si se emplea multitarea durante la
ejecucin de una o ms herramientas, TMS efecta la sincronizacin y comunicacin
multitarea, coordina el flujo de informacin desde el depsito y sistema de gestin de objetos
a las herramientas, realiza funciones de seguridad y auditora y recoge mtricas acerca de la
utilizacin de herramientas.

La capa de gestin de objetos (OML) lleva a cabo las funciones de gestin de configuracin.
En esencia, el software de esta capa proporciona el mecanismo para la integracin de
herramientas. Cada herramienta CASE se enchufa en la capa de gestin de objetos.

Funcionando en conjuncin con el depsito CASE, la OML proporciona los servicios
de integracin, un conjunto de mdulos estndar que acoplan las herramientas con el
depsito.

Adems, la OML proporciona los servicios de gestin de configuracin haciendo
posible la identificacin de todos los objetos de configuracin, llevando a cabo el
control de versiones, y proporcionando apoyo para el control de cambios, las
auditoras y la contabilidad de estados.

La capa de depsito compartido es la base de datos CASE y las funciones de control de
acceso que hacen posible que la capa de gestin de objetos interacte con la base de datos. La
integracin de datos se logra mediante las capas de gestin de objetos y de depsito
compartido.

6. El depsito CASE

Estamos utilizando un determinado nmero de trminos distintos para hacer alusin al lugar
de almacenamiento de la informacin de la ingeniera 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 depsito. An cuando existen sutiles diferencias entre algunos de estos trminos,
todos ellos se refieren al centro de acumulacin y almacenamiento.

6.1. El papel del depsito en I-CASE

El depsito de un entorno I-CASE es el conjunto de mecanismos y estructuras de datos que
consiguen la integracin de datos y herramientas y entre datos y datos. Proporciona las
funciones y herramientas de un sistema de gestin de bases de datos, pero adems, el depsito
lleva a cabo las funciones siguientes:

Integridad de datos:

Incluye funciones para validar las entradas efectuadas en el depsito, para asegurar la
consistencia entre objetos relacionados, y para efectuar automticamente

modificaciones en cascada cuando un cambio efectuado en un objeto exige algn
cambio en otros objetos relacionados con l.

Informacin compartida:

Proporciona un mecanismo para compartir informacin entre mltiples
desarrolladores y entre mltiples herramientas, gestiona el control multiusuario a los
datos, y bloquea/desbloquea objetos para que los cambios no se superpongan
inadvertidamente.

Integracin 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 gestin
de configuracin adecuadas.

Integracin datos-datos:

El sistema de gestin de bases de datos relaciona los objetos de datos de tal modo que
se puedan llevar a cabo las dems funciones.

Imposicin de la metodologa:

El modelo E-R de datos almacenado en el depsito puede implicar un paradigma
especfico de ingeniera del software, como mnimo, las relaciones y los objetos
definen un conjunto de pasos que ser preciso realizar para construir el contenido del
depsito.

Estandarizacin de documentos:

La definicin de objetos de la base de datos da lugar directamente a un enfoque
estndar para la creacin de documentos de ingeniera del software.


Captulo 15
Internet e intranet

1. Un poco de Historia de Internet

La coleccin mundial de redes, ahora llamada Internet, comenz hace ms de 20 aos
como un proyecto conjunto entre las fuerzas armadas de los Estados Unidos y algunos de los
principales centros de investigacin. Habiendo recibido el encargo de disear 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 estndares de comunicaciones. La caracterstica diferenciadora de estos
estndares, conocidos colectivamente como protocolos entrerredes, consista en permitir a
computadores separados por grandes distancias ponerse en comunicacin e intercambiar
informacin, sin necesidad de confiar en un conjunto determinado de cables. Despus de
todo, nunca se sabe qu postes telefnicos van a quedar en pie despus 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 acadmicos y de investigacin. Pero se
fueron conectando progresivamente redes de otros mbitos geogrficos, hasta alcanzar un
mbito mundial

2. Cmo funciona Internet

Un ordenador se prepara para enviar un mensaje Internet envolvindolo en un sobre dirigido
llamado paquete. La localizacin de todos los computadores en Internet queda expresamente
especificada por medio de una direccin IP, un conjunto de cuatro nmeros separados por
puntos (por ejemplo, 159.74.20.254). Ya que los seres humanos tienden a recordar nombres
mejor que nmeros se puede asignar a las direcciones IP un mnemnico, formalmente un
Fully Qualified Domain Name (FQDN). Por ejemplo, el nombre mcp.com.

Determinados sitios Internet mantienen computadores de referencia pblica que listan cada
direccin IP registrada y su nombre de dominio correspondiente. Esta informacin es
suficiente para direccionar los datos de forma fiable desde un computador a otro.

Una mquina est en Internet si opera con los protocolos de TCP/IP, tiene una direccin IP y
es capaz de enviar paquetes IP a todas las dems mquinas de Internet.

3. Aplicaciones en Internet

Tradicionalmente, Internet ha tenido cuatro aplicaciones principales, que son las siguientes:

Correo electrnico. La capacidad de redactar, enviar y recibir correo electrnico ha
estado disponible desde los primeros das de ARPANET y es enormemente popular.
Mucha gente recibe docenas de mensajes al da y lo considera su forma primaria de
interactuar con el mundo externo, dejando muy atrs al telfono y al correo ordinario.
En estos das, los programas de correo electrnico estn disponibles virtualmente en
todo tipo de ordenadores.

Noticias. Los grupos de noticias son foros especializados en los que usuarios con un
inters comn pueden intercambiar mensajes. Existe miles de grupos de noticias, con
temas tcnicos y no tcnicos.

Sesin remota. Mediante el uso de Telnet, Rlogin u otros programas, los usuarios en
cualquier lugar de Internet pueden ingresar en cualquier otra mquina en la que tengan
una cuenta autorizada.

Transferencia de archivos. Con el programa FTP, es posible copiar archivos de una
mquina en Internet a otra. De esta forma est disponible una vasta cantidad de
artculos, bases de datos y otra informacin.

Hasta casi finales de la dcada de los 90, Internet se poblaba en gran medida de
investigadores acadmicos, del gobierno y de la industria. Una aplicacin nueva, la WWW
(world wide web, red mundial) cambi esto y atrajo a millones de nuevos usuarios no
acadmicos a la red. Esta aplicacin no cambi ninguno de los recursos subyacentes pero los
hizo ms fciles de usar. Junto con el visor de Mosaic, la WWW hizo posible que una
localidad estableciera varias pginas de informacin conteniendo texto, dibujos, sonido y
hasta vdeo con enlaces intercalados a otras pginas. Al accionar el ratn en un enlace, el
usuario se ve transportado de inmediato a la pgina 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 artculos de investigacin para su revisin entre otros investigadores. Las
publicaciones cientficas se encuentran entre los documentos ms complejos, debido a que
mezclan textos, ecuaciones y figuras detalladas en cada pgina. El desafo consista en cmo
mover estos documentos por Internet en un formato que requiriera una mnima 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 tecnologas. Defini un lenguaje, HTML, que permite la intercalacin
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

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 interconexin sin barreras de servidores http y navegadores HTML la World Wide
Web.

Esta tecnologa es tan atractiva por la forma como combina las virtudes de Internet con una
sencilla interfaz de usuario basada en documentos.

5. El correo electrnico

El envo de mensajes por un cable es tan antiguo como el telgrafo. Lo nico que el correo
electrnico, o e-mail, aade realmente a este paradigma es su eficacia.

Un sistema de correo electrnico permite a las personas en una red enviarse mensajes entre
s. Si est conectado a Internet y yo supiera su direccin de red, podra enviarle un mensaje
incluso aunque no tuviera idea alguna de su localizacin geogrfica. Otra caracterstica que el
correo electrnico aporta a la comunicacin 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. Dnde comienza intranet

Una intranet es una red interna y autosuficiente que enlaza mltiples usuarios usando la
tecnologa Internet. Las intranets ponen un lmite 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 quedarn inscritos con una DNS pblica, en caso contrario, slo es
necesario que queden registrados en un sistema interno.

La diferencia entre Internet e intranet no es tecnolgica. La verdadera diferencia estriba en:

El nivel de acceso.
La forma como se utilizan las tecnologas para el establecimiento de
comunicaciones.
Los objetivos de las partes en comunicacin.

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
corporacin, pero sirve a una comunidad de usuarios bien definida y limitada.

Internet resuelve un nmero de espinosos problemas de trabajo en red que son relevantes
para las comunicaciones tanto privadas como pblicas. Junto con los estndares desarrollados

para la World Wide Web, la tecnologa Internet resuelve unos requisitos de la informtica
empresarial, que estaban pendientes de resolver desde hace mucho tiempo, mediante la
provisin de un medio de distribucin 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 fcil a la
informacin y la comunicacin dentro de una organizacin. Aunque las plataformas
tradicionales de trabajo en grupo ya instaladas tambin ofrecen estos beneficios, una intranet
expande la capacidad de una organizacin de acceder a la informacin y hacerlo utilizando
estndares abiertos y software cliente flexible e intercambiable. Una intranet ofrece una
arquitectura ms abierta para construir y personalizar el software y las interfaces y preparar
una mayor compatibilidad futura.

La plataforma tradicional de trabajo en grupo est diseada para usuarios que estn
trabajando en un rea geogrfica 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, mdems o escneres compartidos. Hoy en da, los sistemas de trabajo en grupo
heredados son empleados para llevar a cabo una amplia serie de funciones de comunicacin e
intercambio de datos y estn ofreciendo lentamente su utilidad tambin a usuarios remotos.
Una intranet, por otro lado, sirve para usuarios que se encuentren diseminados en reas
geogrficas muy diversas y desean controlar informacin 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
rpido y sencillo a la informacin apropiada.

El objetivo del trabajo en grupo (groupware) es permitir a las personas trabajar
conjuntamente mediante la comunicacin, la colaboracin y la coordinacin. Definido de
esta forma, el software de trabajo en grupo tiene mucho en comn con la tecnologa 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. Adems, una gran parte de la
aplicacin 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, estn construidos en base a componentes propios de mensajera y bases de
datos. Las webs estn basadas en tecnologas de dominio pblico como, por ejemplo, SMTP
y HTTP, que son estndares flexibles y abiertos.

Los productos actuales de software de trabajo en grupo acostumbran a tener un mayor nivel
de seguridad integral y mejor administracin de datos distribuidos que las aplicaciones
basadas en la web.

7.2. Homogeneidad de los PCs

Con los sistemas de trabajo en grupo, gran parte del trabajo computacional es realizado por el
PC individual. As, debe existir un grupo de PCs razonablemente homogneo 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 mltiples 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 informacin 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. Informacin corporativa esttica bsica

Para implementar una biblioteca de red de publicaciones y documentos internos, una
organizacin slo necesita la adquisicin 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 pginas WWW en HTML para el manual del
empleado, las polticas corporativas, o para cualquier otra informacin esttica, y la almacena
en el servidor Web. Ahora la informacin est disponible en la intranet para todo el mundo y,
en cualquier momento, sin costes de reproduccin 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 tambin construyen aplicaciones software para acceder a la informacin 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.


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 podra contactar con la base de
datos, extraer informacin en cualquier formato y mostrar la informacin de cualquier manera
que se pida. Mediante este sistema, no slo es posible acceder a los datos con cualquier tipo
de ordenador, sino que ste puede ser personalizado para manipular la informacin, por lo
que los usuarios que posean cualquier clase de mquina cliente podrn consultar y actualizar
la base de datos.

Otro inconveniente de este sistema es que la herramienta desarrollada para acceder a la
base de datos slo sirve para este cometido. Sin embargo, con una intranet, su navegador
Web es til para consultar informacin corporativa, buscar datos pblicos o, simplemente,
comunicarse.

7.5. Comunicacin

Existen muchos medios de comunicacin diferentes dentro de un sistema existente de trabajo
en grupo. Uno de los inconvenientes es que se necesitan distintas piezas software para cada
funcin requerida, por ejemplo, para una videoconferencia. Adems, la comunicacin bsica
con usuarios externos a la red no es una tarea fcil.

Una intranet proporciona un enlace e-mail tanto interno (a nivel de oficina) como externo (a
nivel mundial), poniendo a disposicin de los empleados recursos globales. La sociedad
Netscape-Collabra, que combina el navegador Web ms 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 organizacin desea proporcionar soporte tcnico a los clientes o quisiera
obtener realimentacin de los consumidores sobre las ltimas innovaciones de sus productos,
podra abrir uno de sus tablones de mensajes a usuarios externos a la red. Con el trabajo en
grupo tradicional esto no es una opcin, pero si en una intranet.

7.6. Gestin de documentos

La gestin de documentos presenta cuatro dimensiones esenciales:

Bsqueda/recuperacin. La capacidad de encontrar lo que se est buscando.

Seguridad. Control del acceso de escritura/lectura a los documentos.

Control de versin. Mantener un seguimiento de las modificaciones de los
originales.

Archivo. Conseguir la disponibilidad de datos histricos.

Los sistemas de gestin de documentos pueden hacer estas cuatro cosas. Las intranets slo
la Bsqueda/recuperacin. Por otra parte, el establecimiento de un completo sistema de
gestin de documentos podra costar millones, en comparacin al bajo precio de una web
interna.

Si no requiere gestin automtica de documentos, la eleccin es sencilla: necesita una
intranet. Si las cuatro funciones son bsicas en su organizacin, la eleccin es un sistema de
gestin de documentos. Pero entre los dos extremos, la eleccin es ms difcil.


Captulo 16
Beneficios de intranet

1. Introduccin

Las intranets ofrecen un amplio rango de beneficios que entran dentro de dos grandes
categoras: eficiencia y efectividad. En este contexto, la eficiencia significa la mejora de los
mecanismos de intercambio de informacin, superando los obstculos logsticos que existen
para recolectar y diseminar la informacin necesaria de una manera precisa. La efectividad se
refiere al impacto organizativo del perfeccionamiento de la colaboracin 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 telefnicas de larga distancia). Otros ahorros se derivan de la disminucin de la
dependencia de los documentos impresos, como puedan ser manuales de empresa,
catlogos de productos o relaciones de materiales de clientes, que se pueden distribuir
electrnicamente en vez de ser impresos y enviados por correo.

Oculto dentro de la ecuacin de eficiencia est el ahorro en horas de trabajo personal. Una
intranet a pleno funcionamiento puede reducir drsticamente la factura telefnica,
intercambiando mltiples borradores de documentos, y reduciendo el tiempo empleado en
coordinar la recopilacin de informacin.

La fuerza de ventas de una empresa utiliza su intranet exclusivamente como un medio de
relacin con el cliente. Los representantes de ventas pueden acceder a una informacin on-
line complementaria sobre los productos desde las oficinas de los clientes en vez de acarrear
con un montn de catlogos o folletos.

Una multinacional comercial utiliza su intranet para, entre otras cosas, organizar una
compleja planificacin de citas. En cualquier momento dado, la organizacin estar
preparando simposiums tcnicos, encuentros de equipos especiales y conferencias de
negocios; adems de sus reuniones plenarias semestrales y anuales, que generalmente atraen a
cientos de participantes de todo el mundo.


Cada una de estas reuniones tendr su propia lista de participantes, agenda, instrucciones,
gestin de locales, consideraciones logsticas y resultados esperados.

1.2. Aumento de la efectividad

Las intranets, virtualmente por definicin, estimulan el intercambio de informacin por
encima de los lmites tradicionales, tanto organizativos como geogrficos. Si se gestionan
propiamente, tal aumento del intercambio se convierte en trampoln para la colaboracin
sustantiva entre sectores de la organizacin patrocinadora previamente fragmentados. El
uso creativo de una intranet puede acelerar la evolucin de una organizacin desde un modelo
jerrquico, a una estructura ms gil e interdisciplinar, promoviendo la interaccin
coordinada.

Una firma internacional de abogados, por ejemplo, emplea su intranet para fortalecer su
prctica ambiental. La intranet permiti que los especialistas en medio ambiente de la firma
intercambiaran (en un entorno seguro) informacin acerca de casos y de las nuevas
regulaciones y tendencias legales que les afectaban y solicitar el consejo de sus colegas,
rpida 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: visualizacin de informacin general.

Nivel dos: comparticin 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 segn sus necesidades y a su propio
ritmo. Muchos patrocinadores de intranet utilizan este medio solamente para diseminar
informacin a travs de toda la organizacin. Sea por propia eleccin o debido a obstculos
organizativos, no progresan ms all del nivel uno. Otros patrocinadores ms ambiciosos
apuntan hacia la colaboracin (nivel tres) desde el principio. Para estas organizaciones, los
niveles uno y dos ofrecen ms un medio para alcanzar un fin que un fin en s mismo.

2.1. Nivel uno: visualizacin de informacin general

Desde la comunidad de usuarios ms pequea hasta la multinacional comercial de mayor
tamao, toda organizacin genera alguna forma comn de informacin, tanto para sus
propios miembros o constituyentes como para el mundo exterior. Sea formal o informal, esta
informacin ayuda a mantener la cohesin de la organizacin, estableciendo una
comprensin general de su misin, metas, recursos, polticas y novedades.


A su nivel ms bsico, una intranet funciona como almacn privado de la informacin del
patrocinador, accesible para aquellos que la organizacin reconoce como su capital humano.
Puede tratarse de empleados, voluntarios, miembros asociados, lderes de la comunidad,
clientes, accionistas y cualquier otro grupo involucrado en la organizacin.

La gran cantidad de informacin disponible para este pblico puede adoptar muchas formas,
pudindose adaptar casi todas al entorno intranet. El contenido de una intranet puede ser
actualizado instantneamente 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 estndar
(que en muchas empresas estn sufriendo constantemente un proceso de revisin), pueden ser
publicados en una intranet y ledos slo por usuarios autorizados. La intranet tambin puede
ser utilizada para la diseminacin de documentos de lectura obligada, registrando el acceso
de los usuarios y evitando el mucho ms montono mtodo de leer y firmar, obligado
tradicionalmente por cumplimiento legal.

Muchas empresas utilizan sus intranets para visualizar el rendimiento histrico de los fondos
de pensiones de los empleados o planes de almacenamiento.

Otras organizaciones muestran grficos de rendimientos de ventas por divisiones o por
regiones, actualizados y comparados mensualmente.

La informacin sobre los productos es una categora 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 rpidamente, as como proporcionar unas especificaciones del producto e
instrucciones de uso fciles de entender asegurando la consistencia de la informacin.

2.2. Nivel dos: compartir los datos del negocio

Adems de la publicacin de informacin relativamente esttica o histrica, como informes
anuales, cada organizacin mantiene los datos que estn cambiando constantemente. Estos
datos pueden cuantificar la produccin semestral, las ventas semanales, o el inventario de
productos; tambin pueden documentar niveles de pertenencia de miembros o contribuciones;
o pueden reflejar cambios en la contabilidad general. Adems, 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) hacindolos residir en potentes
bases de datos tales como Oracle. Estas bases de datos proporcionan una capacidad mxima

para facilitar la realizacin rpida de cambios de los contenidos de un servidor intranet, a
menudo por medios automatizados.

Por ejemplo, muchos grandes almacenes informticos con cadenas en muchas ciudades o en
una regin 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 informacin y la
revisin de trabajos en progreso. Una firma de ingeniera y construccin utiliza un sector de
su intranet como enlace de los directores de los principales proyectos de construccin
esparcidos por el mundo. Ya que muchos de estos proyectos (plantas hidroelctricas, por
ejemplo) comparten un diseo comn y unos requisitos de recursos similares, la capacidad de
intercambiar informes de progreso, especificaciones tcnicas, grficos y cualquier otra
informacin permite a cada director beneficiarse de la experiencia de otros.

2.3. Nivel tres: comunicaciones interactivas

En su perfil ms dinmico, las intranets ofrecen un medio de colaborar en tiempo real,
creando plataformas seguras para las comunicaciones interactivas intraorganizativas.

Una compaa aeroespacial comprometida en un extenso programa de investigacin y
desarrollo utiliza su intranet para estimular la cooperacin entre los tcnicos de diferentes
divisiones. Histricamente, estos especialistas haban trabajado en aislamiento, cada uno
centrndose en un nico componente de un prototipo de avin comercial. Con el tiempo, la
alta direccin tuvo que reconocer que este patrn de trabajo creaba barreras a la productividad
y promova los conflictos entre divisiones y directores de departamentos, en vez de una
competencia saludable. La direccin necesitaba un modo de derribar estas barreras,
estableciendo una visin comn y restaurando un sentimiento funcional de metas comunes, en
este caso, la construccin de un nuevo avin.

La intranet de esta empresa proporcionaba los medios para alcanzar este fin. Pero, en primer
lugar, la alta direccin tuvo que aclarar que la empresa haca negocio cambiando sus
procedimientos, y no slo daba soporte sino que requera una colaboracin tangible entre las
distintas divisiones. Se vio claro que con slo proporcionar la intranet no era suficiente;
convertirla en vital y dinmica haca necesario un fuerte trabajo de base por adelantado,
recibiendo informes tanto de los jefes de divisin como de los expertos tcnicos.

La intranet de nivel tres de la empresa est dividida en sectores, cada uno de los cuales
representa un proyecto individual, aunque son fcilmente conectables con el resto. Cada
proyecto tiene asignado un equipo I+D cuyos miembros estn dentro de un grupo de usuarios
de intranet definido con acceso a toda la informacin del proyecto. La reaccin inicial de los
usuarios fue cauta y escptica (los viejos hbitos nunca mueren), y los directores de divisin
recibieron instrucciones para estimular el uso del servidor organizando reuniones on-line y
publicando la informacin ms actual.

En este caso triunf la curiosidad tcnica, dirigida por los ingenieros de software de la
empresa. Su inters en la tecnologa subyacente bajo intranet y sus aplicaciones potenciales

les empujaron a explotarla y utilizarla. Cuantos ms y ms usuarios se integraban en el
sistema, el servidor se haca muchos ms sofisticado, reflejando su uso e ideas. El software
interactivo permite a los usuarios consultar y modificar diseos tcnicos, moderar
conferencias en tiempo real y generar simulaciones animadas de diversas caractersticas del
avin bajo desarrollo. La alta direccin dio crdito a la intranet no slo para mejorar la
productividad, sino tambin para mejorar la capacidad de la empresa de atraer y motivar el
talento tcnico final.

Las aplicaciones intranet ayudaron a facilitar la colaboracin necesaria para la
simplificacin drstica del proceso. La tecnologa disponible actualmente permite a los
usuarios de intranet intercambiar, almacenar y modificar informacin en formato texto,
audio y vdeo. 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 mtodos de colaboracin
ms tradicionales como puedan ser reuniones y conferencias. Adems, una intranet posibilita
preservar y archivar las deliberaciones del grupo.

3. Ventajas de intranet

3.1. Acceso a la informacin

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 organizacin. Pero slo se pueden tomar decisiones tan buenas como lo
permite la informacin con la que cuentan quienes deciden. Los sistemas de informacin son
valiosos ya que la eficiencia de la organizacin est en funcin de la calidad de la
informacin a la que las personas tienen acceso.

La tecnologa de la web interna aporta claras ventajas de acceso a la informacin. Estas
ventajas se dividen en tres categoras.

1. Una plataforma universal. Las webs proporcionan una plataforma comn para
encontrar, recuperar, visualizar y actualizar una variedad de activos informativos,
incluyendo datos numricos y bases de datos relacionales y documentos
compuestos de texto estructurado, imgenes e incluso objetos multimedia como,
por ejemplo, audio e imgenes en movimiento.

2. Una visin unificada. Las webs ayudan a organizar informacin presentando
diversos tipos de datos en un estilo estndar. En un navegador web, la gama de
comunicaciones e informes empresariales, artculos, memorndums y tablas
tradicionales adoptan un aspecto y manejo comn. Adems de soportar una rpida
toma de decisiones, los estndares familiares pueden facilitar el aprendizaje de
nuevas aplicaciones.

3. Un lenguaje comn. La tecnologa web se construye sobre estndares flexibles y
de aceptacin universal. En consecuencia las intranets pueden acceder a

informacin residente en sistemas ya existentes sin necesidad de costosas labores
de programacin.

3.1.1. Las webs unen datos y documentos

Tradicionalmente, el software informtico ha lidiado con la diversidad de informacin
mediante la utilizacin de una estrategia del tipo divide y vencers. El texto normal se
manipula mediante un programa, como por ejemplo Windows Notepad. Otro programa,
maneja el texto muy formateado, como Microsoft Word. Los grficos son diferentes y se
visualizan mejor utilizando un programa distinto, editado con otro y catalogado, tal vez como
imgenes en miniatura, con un tercer programa. Los datos orientados a registros son pasto del
software de gestin de base de datos. Y as se organiza todo los dems.

El problema de este enfoque es que fragmenta los datos de una organizacin de forma poco
natural. Para resolverlo surge la informtica centrada en documentos. Estos son los
familiares espacios de trabajo que contienen texto e imgenes 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 informacin en la misma forma como estamos acostumbrados a verla: dispuesta
en una pgina.

La tecnologa web aporta dos cosas a la informtica centrada en documentos. Primero,
consagra a los documentos HTML como el estndar universal a travs del cual se accede a
toda la informacin. 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 tecnologa web es independiente de plataformas. Las
pginas 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 ms importantes es
la coherencia en el modo de operar a lo largo de todo el producto o, mejor an, a lo largo de
una familia de productos.

Qu determina la consistencia en el modo de operar? Dos cosas: el aspecto de una
aplicacin y su comportamiento.

Es ms fcil 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
presentacin totalmente diferente. La colocacin coherente de controles y mensajes dentro de
programas es tambin importante para ayudar a los usuarios a permanecer orientados cuando
cambien de tarea.

La tecnologa web impone un aspecto y manejo coherente en la informacin. Hay tan slo
unos cuantos elementos bsicos de diseo en HTML. Las cabeceras, listas, tablas y formatos

tienen un aspecto muy similar en la web, al margen del navegador utilizado para
visualizarlos.

3.2. Procesos empresariales

El uso de la informacin para la toma de decisiones constituye una faceta esencial del
rendimiento de las organizaciones. Pero, una vez se adopta una decisin, el nivel de
rendimiento depende de la accin. La tecnologa intranet tambin ofrece ventajas a este
respecto.

El trabajo del da a da de cualquier organizacin consiste en un conjunto de actividades
estndares, cuestiones como la planificacin, marketing, emisin de informes, facturacin,
etc. Un proceso empresarial describe las rutinas utilizadas por una organizacin para
desempear dichas actividades. La sustitucin de algunos o todos los pasos manuales en un
proceso empresarial con transferencias electrnicas recibe a menudo el nombre de
automatizacin del flujo de trabajo.

La tecnologa intranet es extremadamente eficaz como un medio de reunir informacin de los
usuarios de la web y de aportar informacin a estos mismos usuarios.

Una intranet puede aumentar o sustituir flujos de trabajo al mismo tiempo que genera una
pista de auditora.

La capacidad de creacin de formularios se aadi al estndar HTML a partir de la versin
2.0. Los formularios elevan la tecnologa intranet desde una distribucin esttica de datos a
una automatizacin interactiva.

Los formularios HTML hacen posible que las pginas web acten como puerta de acceso a
sofisticadas aplicaciones. Las aplicaciones de consulta de base de datos, por ejemplo,
pueden construirse rpidamente utilizando slo HTML, secuencias de software gratuito para
proceso de formularios, software gratuito de conexin 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 auditora.

4. Los costes de intranet

Una intranet es un inversin en tecnologa de la informacin (IT). Al igual que cualquier
inversin en IT, incurre en costes en cada punto de su ciclo de vida. Los desembolsos
relativos a su adquisicin, instalacin, uso y mantenimiento se cargan a la inversin a partir
del momento en que alguien propone la idea de instituir una intranet. El coste aadido que
supone el sistema slo compensar si los beneficios que genera su empleo superan la suma de
estos costes.


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:

Conversin: Los costes de conversin son aquellos asociados con las
herramientas, mano de obra y estndares requeridos para convertir los formatos
ya existentes a HTML.

Coordinacin: Otro coste es la necesidad de coordinar proveedores de contenido
en departamentos de forma que sus contribuciones se ajusten a los estndares
de aspecto y uso de la intranet.

Indexacin: Finalmente, es necesario indexar peridicamente las pginas web a
fin de permitir a las personas encontrar agujas de valor en el pajar de la
informacin.

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 proteccin contra el
robo fsico, la corrupcin 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 informacin como propiedad pblica y adems, de pleno derecho, libre de honorarios de
paso. Una intranet es diferente. El hecho de que su propsito consista en proporcionar acceso
libre a informacin corporativa no significa que cualquiera pueda acceder a cualquier cosa
en cualquier momento.

Puede que resulte necesario proteger de miradas extraas informacin sensible que viaje
por la red como, por ejemplo, registros legales o secretos comerciales, incluso dentro de la
misma organizacin. La tecnologa bsica para hacerlo es la encriptacin.

La encriptacin funciona transcribiendo el texto de un mensaje con una clave que no es otra
cosa que un nmero muy largo.

Los servidores seguros web como Netscape Commerce Server utilizan tecnologa de claves
pblicas para prestar servicios de encriptacin, autentificacin y firma digital. En un
sistema de clave pblica cada persona tiene un par exclusivo de claves. Una de ellas se
denomina la clave pblica 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 pblica del recipiente. Una vez cifrado, el mensaje slo podr ser ledo
descifrndolo con la clave privada del destinatario. Es esta forma, cualquiera puede enviar un
mensaje seguro, pero slo su destinatario podr leerlo.


Captulo 17
Intranets en accin

1. El contenido es la clave

Cualquier intranet de xito proporciona un contenido (informacin) al que los usuarios dan
valor. Por supuesto, la naturaleza de este contenido vara considerablemente, dependiendo de
los grupos individuales de usuarios y sus prioridades. Sin embargo, se aplican unos cuantos
principios bsicos a cualquier consideracin sobre contenido, y los patrocinadores y usuarios
de intranet deben estar de acuerdo en que la informacin del servidor incluya caractersticas
como las siguientes:

Relevancia: este concepto lo ve el usuario, no el patrocinador.

Oportunidad: los atascos de trfico en las intranet desaniman a los usuarios;
stos vuelven rpidamente a los medios de comunicacin convencionales cuando
sus tablones de mensajes y su correo electrnico son lentos y poco fiables.

Actualizaciones frecuentes: muchos servidores web, pblicos y privados,
adolecen de contenidos estticos, por lo que su inters y su utilizacin decaen
rpidamente. Las intranets ofrecen capacidad que debera ser explotada
completamente por medio de la automatizacin y otras funcionalidades.

Accesibilidad: el mejor servidor del mundo es de escaso valor si los usuarios no
pueden llegar a l rpida y fcilmente. El cometido de la intranet es hacer
disponible la informacin y el diseo del servidor debe aprovechar los motores de
bsqueda y otras funcionalidades que mejoren el acceso de los usuarios.

Al considerar las cuestiones de contenido, es importante tener en mente que las intranets
estn dirigidas nicamente al usuario y que las necesidades y preferencias del mismo deben
ser factorizadas en el diseo e ingeniera iniciales del servidor.

2. Es intranet la respuesta?

La clave determinante del valor de intranet reside en las necesidades de informacin de su
organizacin. Como regla muy general, las intranet son las ms tiles para las organizaciones
que:


Tienen gran dispersin geogrfica.
Comparten objetivos comerciales comunes.
Tienen necesidades de informacin comunes.
Se benefician de la colaboracin.

Para que una intranet sea verdaderamente til, debe reflejar un ncleo central, lo ms
frecuente es un negocio comn 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 pequea empresa, que opere desde un nico emplazamiento, puede intercambiar
informacin de forma ms apropiada a travs de memorias, reuniones o en la mquina de
caf. Una organizacin de este tipo bien puede usar Internet como recurso para la recoleccin
de informacin, pero probablemente no necesite aadir el poder y eficacia de una intranet.

En contraste, una empresa que dispone de mltiples oficinas de venta o divisiones operativas
en emplazamientos diferentes, o una asociacin comercial o grupo sin afn 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 informacin concisa y oportuna de sus directivos; estn sobrecargadas por
desafos logsticos que surgen de mltiples zonas horarias, sistemas informticos
incompatibles y de un errtico servicio telefnico local.

Como resultado de estas y otras barreras, es posible que las decisiones crticas no se
beneficien de una colaboracin total entre los participantes claves, o de una informacin
concisa del entorno, disponible de forma equivalente para todos los que participan en la toma
de decisiones. Pueden existir graves inconsistencias entre oficinas en trminos de su
capacidad para diseminar informacin entre los miembros del personal.

A su mximo rendimiento, las intranets ayudan a crear y profundizar una visin comn entre
componentes dispares de la organizacin potenciando lo individual. Para muchas
corporaciones, este concepto es, en si mismo, revolucionario: alcanzar una influencia comn
distribuyendo (no centralizando) el poder.

3. Descubrir las necesidades

Las intranets estn, por definicin, dirigidas al usuario, y su diseo debe reflejar las
necesidades del usuario. As mismo, una buena manera de comenzar es identificar esas
necesidades dentro de la organizacin que espera que intranet le ayude a satisfacer.

La organizacin patrocinadora debe hacerse a s misma algunas preguntas muy bsicas antes
de embarcarse en un proyecto de esta clase:

Qu es lo que se quiere conseguir?

Qu es lo que queremos que la intranet satisfaga?

Cmo esperamos cumplir nuestras metas? Esta pregunta ayuda a establecer un
marco de trabajo para la planificacin del proyecto, incluyendo la asignacin de
responsabilidades, especificaciones tcnicas, requerimientos de recursos, un
calendario y patrones de personal.

Cunto costar? Una descripcin real de los costes de intranet debera incluir
estimaciones del desembolso a corto plazo como del ahorro esperado a largo plazo.

Cmo monitorizaremos los progresos?

Cmo determinaremos el grado de xito? Como con cualquier otro tipo de
iniciativa, la eficacia de intranet se determina de forma definitiva por medio del
anlisis coste/beneficio.

Quines son a priori los posibles usuarios de la intranet? El universo de
usuarios potenciales puede ser tan amplio o tan restringido como necesite la
organizacin.

Cmo esperamos que use la intranet la audiencia objetivo? Para cada grupo de
usuarios, la organizacin debe definir utilidades y beneficios especficos para
asegurar que el diseo del servidor satisfaga las necesidades y expectativas de cada
grupo.

Qu necesita la audiencia para utilizarla? Evaluar qu es lo que ya existe en
trminos de capacidad de computacin, conectividad y experiencia.

4. Metas de una intranet

Estructura: la comprensin de la estructura de la organizacin ayuda a determinar la utilidad
de la intranet en general, as como qu funciones especficas pueden resultar ms valiosas.

1. Posee la organizacin mltiples oficinas en diferentes emplazamientos?

2. Existen diversas funciones de personal (tales como I+D, ventas, recursos humanos,
asesora jurdica, ingeniera) residentes en ms de un sitio?

3. Se trata de una organizacin esencialmente jerrquica? Es distribuida? Es
centralizada? Es descentralizada?

Comunicaciones internas / intercambio de informacin: la comprensin de cmo la
organizacin intercambia rutinariamente la informacin interna ayuda a revelar los huecos y
barreras que una intranet puede solventar.


1. Cules son las fuentes primarias de informacin, dentro y fuera de la organizacin?

2. Cul es la forma habitual de entregar la informacin comercial? (por correo
electrnico, entrega especial, telfono, reuniones o cualquier otro medio)

3. Cmo se toman generalmente las decisiones?

4. Cmo se dirige y comparte la investigacin?

Comunicaciones externas: la comprensin de cmo interacta la organizacin 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 organizacin (como puedan ser clientes,
accionistas, voluntarios) con los que se interacta de forma rutinaria?

2. Cmo les mantiene informados la organizacin?

3. Qu informacin necesitan?

4. Cmo recibe y procesa la organizacin la informacin que proviene de estos
grupos?

Barreras: una revisin objetiva de las barreras que impiden una comunicacin eficaz ayuda a
identificar las debilidades de la organizacin y a asignar prioridades para el desarrollo de
intranet.

1. Cules son los obstculos primarios que se encuentra el intercambio eficaz de
informacin?

2. Se tratan de barreras mecnicas? Logsticas? Culturales?

3. Cul es el impacto de estas barreras?

Recursos: la evaluacin de los recursos disponibles ayuda a establecer un punto de partida
realista para el diseo e implementacin de una intranet.

1. Cul es el nivel actual de informatizacin de la organizacin?

2. Qu recursos (personal y contratista) se requieren para construir y gestionar la
intranet?

3. Qu recursos (financieros, tcnicos, etc.) estn actualmente disponibles?

5. Comenzando con intranet

Un proyecto intranet de xito necesita:

El beneplcito de la alta direccin
Un director de proyecto nombrado con un mandato explcito.
Las herramientas y el dinero necesarios para realizar el trabajo.

Adems, en cuanto el liderazgo y la contabilidad estn claros, un proyecto de esta clase se
beneficia enormemente de una aproximacin de equipo multidisciplinar, lo que ayuda a
asegurar que la organizacin como un todo recoja el mximo beneficio de su inversin.

Construir un equipo de proyecto que comprenda a un amplio rango de usuarios potenciales de
la organizacin para que los ingenieros software dispongan de los beneficios de las
necesidades de los usuarios mientras desarrollan las especificaciones de la intranet.

La consecucin de las ventajas de una intranet depende de su personal, estilo de gestin y
base tecnolgica ya existente.

1. Para que las personas puedan beneficiarse al mximo de una intranet es necesario que
compartan objetivos empresariales claves. Esto, ms la confianza necesaria para
permitir el flujo de informacin (en lugar de reservrsela), 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 tecnologa web, asigne
desarrolladores que aporten su propia disciplina a la codificacin, ya que todava no
existen mtodos formales para intranets. La centralizacin de pruebas y del
establecimiento de estndares le ayudar a tratar con la dudosa ventaja de contar con
versiones 1.0 de software.

4. Puede sobreponerse la tecnologa intranet en la mayora de las redes privadas de
trabajo. Es posible que su personal de red tuviera que aprender la gestin de
direcciones TCP/IP, pero su experiencia favorecer el ptimo despliegue de las webs
internas.

6. Planificacin de intranet

El coste de la operacin y el mantenimiento de una red informtica crece exponencialmente
con el nmero de usuarios conectados, mientras que el valor de la red aumenta con mayor
lentitud. Las intranets no constituyen una excepcin.

Cuando determine el mbito de su primera intranet, incluya el grupo ms pequeo que pueda
beneficiarse de la nueva web y cntrese en satisfacer los requisitos de dicho grupo.

Cuando llegue el momento de crecer, ample 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 planificacin conceptual.

Divida los costes en dos categoras: costes iniciales y no repetitivos como, por ejemplo,
compras de hardware, y costes recurrentes como, por ejemplo, el correspondiente a los
contratos de mantenimiento del software.

Divida los objetivos relativos a beneficios en dos categoras: reduccin de los costes de
gestin de la empresa y una mayor capacidad de generacin de ingresos.


APNDICES


Apndice I
Anlisis Estructurado de Sistemas

1. Conceptos bsicos.

El anlisis estructurado de sistemas (Structured System Analysis) es un mtodo clsico de
especificacin de los requerimientos del software, propuesto en la segunda mitad de los aos
70. Se ver la versin de DeMarco.

Junto al diseo estructurado de sistemas (Structured System Design) constituye toda una
metodologa de desarrollo de software, que tambin contempla labores de Ingeniera de
Sistemas.

El mtodo SSA pretende alcanzar los siguientes objetivos:

- Disponer de un modelo lgico (independiente de la implementacin) del sistema,
inteligible para el usuario, y grfico en la medida de los posible, antes de proceder a
implementarlo.

- Emplear un mtodo efectivo de descomposicin funcional durante el anlisis.

- Dar cuenta de las caractersticas tanto lgicas como fsicas de los sistemas,
distinguindolas adecuadamente.

- Obtener un documento de especificacin modificable, que pueda cambiarse o
mantenerse.

Para ello hace uso de una serie de herramientas:

- Diagrama de flujo de datos (DFD)

- Diccionario de datos (DD)

- Otras: lenguaje natural estructurado, tablas de decisin, especificacin algebraica, ...

En el documento de especificacin deben figurar DFDs, DD y las especificaciones de las
primitivas funcionales.

La metodologa SSA utiliza estas herramientas para construir una especificacin estructurada.
SSA propone un procedimiento de trabajo y un ciclo de vida:

Fig. I-1. Ciclo de vida del Software en SSA

Fig. I-2. Estructura de la fase de Anlisis

2. Diagramas de Flujo de Datos.

Un Diagrama de Flujo de Datos es una representacin en forma de red que refleja el flujo de
la informacin 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 abstraccin. 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 ms 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 informacin que fluye
por el sistema.
- Flujos de datos: representan los datos que fluyen entre las funciones.

Y su representacin:

Proceso Entidad Externa

Almacn Flujo de datos

Nombre del
fichero

Fig. I-3. Representacin 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,
dejndose guiar por la informacin procedente del usuario, intentando reflejar el flujo
de informacin tal como es ms que preguntarse porqu es as. Iremos:
- Reflejando los flujos de informacin que aparezcan en el sistema.
- Situando procesos (sin darles nombre en un principio) donde sea necesario
procesar informacin para conectar unos flujos con otros.
- Introduciendo los almacenes de informacin que existan en el sistema.

Nombre entidad
Nombre flujo
Nbre.
Proceso

3. Seguir el camino de la informacin, de las entradas a las salida, de las salidas a
las entradas, y del centro a la periferia.

* Examinando los flujos y su contenido, preguntndonos:
- Qu necesito para elaborar este contenido.
- De dnde proceden sus componentes.
- Puedo elaborar (con un proceso) la informacin de algn otro flujo para
obtener la de este?
* Examinando los procesos (sin nombre an), preguntndonos:
- Si es necesaria la informacin de algn otro flujo para obtener las salidas del
proceso a partir de las entradas.
- Podremos ir dando nombre, en trminos de sus entradas y salidas, a los
procesos.

Estos recorridos nos llevarn 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
informacin, y si es relevante, el estado de la misma. Por ejemplo,
numero_de_cuenta refleja el contenido de informacin, pero
numero_de_cuenta_validado no solo refleja el contenido, sino una
informacin relevante.
- El estilo de denominacin a base de frases con palabras delimitadas es ms
conveniente que el uso de abreviaturas.
- A veces, en ficheros simples, slo 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 inicializacin y la terminacin. Basta con que los DFD reflejen el
comportamiento de los sistemas cuando estn en un rgimen estacionario.

6. Omitir los detalles de los caminos de error triviales (por ahora).

7. No incluir flujos de control o informacin de control.

8. Comenzar de nuevo. Puede ser que:
- Exista algn flujo de entrada desconectado del resto del diagrama (lo
eliminamos sin ms).
- Exista alguna zona en el centro del diagrama desconectada del resto del
mismo (si no es una zona de inters la eliminaramos)


3. Componentes de los DFD

3.1. Procesos.

Este componente representa una funcin que transforma los flujos de datos de entrada en
uno o varios flujos de datos de salida. El trmino proceso a veces puede dar lugar a
confusin, puesto que no hay que considerarlo como un programa en ejecucin, sino como
una funcin 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 ms una informacin (constante o variable) del proceso, lo que se conoce
como "la regla de conservacin de los datos". Cuando al proceso no le llegan todos los datos
necesarios para obtener datos de salida diremos que hay un error de conservacin de datos.
Esto implica que por lo menos se ha olvidado incluir ciertos datos de entrada. Tambin puede
ocurrir el caso contrario, que sera aquel en el que el flujo de datos o algn componente suyo
"muere" dentro del proceso, es decir, no se utiliza para generar flujo de salida, lo que se
denomina "prdida de informacin".

Los procesos deben ir numerados y nominados, debiendo cumplir las siguientes
caractersticas:

* Ser lo ms representativo posible de la funcin que especifica. Siendo un nombre
que englobe a toda la funcin y no slo a parte de ella.

* Ser breve, normalmente est formado por un verbo seguido de un sustantivo, como
por ejemplo: Analizar paquete.

* El nombre y nmero del proceso deben ser nicos en el conjunto de los DFD que
representan el sistema.

Cuando se realizan los DFD lgicos, los procesos deben estar desligados de cualquier
connotacin fsica, como por ejemplo: lugar donde se realiza el proceso, personas o
dispositivos que realizan el proceso, etc. Cuando se realizan los DFD fsicos se pueden
incluir este tipo de connotaciones.

3.2. Almacenes de datos.

Representan informacin del sistema almacenada de forma temporal, representando datos
que se encuentran "en reposo". Se trata de dispositivos lgicos de almacenamiento y, por
tanto, pueden representar a cualquier dato temporalmente almacenado, independientemente
del dispositivo utilizado. Por ello, pueden representar a un cajn con papeles, un archivador
manual, un fichero o una base de datos.

3.3. Entidades externas.

Representan un generador o consumidor de informacin del sistema y que no pertenece al
mismo. Puede representar un subsistema, una persona, departamento, organizacin, etc, que
proporcione datos al sistema o que los reciba de l.

3.4. Flujos de datos.

Se pueden definir como "un camino a travs del cual viajan datos de composicin conocida
de una parte del sistema a otra".

Se representan por arcos dirigidos, en donde se indica la direccin del flujo.

La conexin directa entre dos procesos mediante un flujo de datos es posible siempre y
cuando la informacin sea sncrona, es decir, que el proceso destino comience en el momento
en el que el proceso origen finaliza su funcin. Si no ocurre, es necesario que exista un
almacn temporal que guarde los datos del proceso origen, y el proceso destino capturar
estos datos cuando los necesite.

4. Desarrollo de niveles de abstraccin en los DFD.

Para representar un modelo de un sistema grande es conveniente hacerlo por capas,
realizando una aproximacin descendente (top-down) en el que cada nivel proporciona una
aproximacin ms 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 jerarqua.
Tambin 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
descomposicin 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 ms diagramas de nivel inferior. Es importante recalcar que para cada proceso
primitivo habr una especificacin que la describa.


Es necesario comprobar la consistencia entre los distintos niveles del DFD, es decir, que la
informacin que entra y sale de un proceso representado en un DFD de nivel N, sea
consistente con la informacin que entra y sale del DFD en el que se descompone.

Un fichero slo puede aparecer en un diagrama. Podemos plantearnos en qu nivel debe
aparecer el fichero, la solucin consiste en ponerlo en el primer nivel en que interaccione con
ms de un proceso.

No debe indicarse, sobre los diagramas, la procedencia o destino de los flujos exteriores. Esto
puede averiguarse mirando en el correspondiente diagrama de nivel superior.

La numeracin de los DFD se realiza de la forma siguiente:

* Cada diagrama recibe el nmero y nombre del proceso del que proviene (proceso
padre).
* El diagrama de contexto se numera como 0.
* Los diagramas de nivel 1, se numeran desde 1 hasta el N. En los restantes niveles los
nmeros de los procesos estn formados por la concatenacin del nmero del
diagrama en el que estn, ms un punto, ms un nmero entero nico para
identificarlo dentro del diagrama.

Recomendaciones:

- En los diagramas, el nmero de procesos no debe ser ni muy bajo, lo que multiplicara el
nmero de diagramas, ni muy alto (un nmero mayor de siete comienza a ser problemtico).

- Las interfaces, como consecuencia de una divisin en subdiagramas apropiada, no deben
ser muy complejas, y deben guardar una cierta relacin con el problema.

- 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 quin entiende que esto requiere que
slo se presente un flujo de entrada y otro de salida).

- No es necesario marcar de ninguna forma especial los diagramas terminales.

- Por ltimo, decir que en la realizacin de los DFD hay que tratar de evitar una particin
desigual, siendo la particin o descomposicin ideal aquella que genera partes de igual
tamao.


5. Verificacin y Validacin de los DFD

Aspectos a verificar:

* Denominaciones:

- Que todos los flujos tengan un nombre asignado.
- Que todos los flujos tengan un contenido conocido.
- Que los nombres de los procesos hagan referencia a sus entradas y salidas, y
guarden relacin con el contenido de los subdiagramas que dependan de ellos.

* Consistencia:

- Balanceo de flujos.
- Que un mismo proceso no aparezca ms de una vez.
- Que cada proceso pueda elaborar los flujos de salida contando slo con la
informacin de los flujos de entrada (conservacin de los datos)

* Ficheros:

- Que no aparezcan ficheros que slo reciben informacin (sumideros).

* Legibilidad:

- Que las interfaces sean sencillas.
- Que los nombres de los procesos sean significativos (p.e. Procesar_salida no
lo es)
- Que la descomposicin funcional sea uniforme (que la jerarqua de
diagramas est equilibrada).

6. Diccionario de Datos.

El diccionario de datos se puede definir como: "una lista organizada de los datos utilizados
por el sistema y que grficamente se encuentran presentes en los flujos de datos, entidades
externas y los almacenes del conjunto de DFD"

El DD se crea a la vez que los DFD durante el anlisis del sistema. Las entradas son
realizadas cada vez que se identifica un elemento, pudiendo ser de cuatro tipos: flujo de dato,
almacn, dato elemental y entidades externas, debiendo ser nicas para cada componente
del DFD. (Muchos autores incluyen en el DD la especificacin de Procesos, pero para la
realizacin de las prcticas no las incluiremos en el mismo.)


La definicin de los flujos de datos sigue una aproximacin top-down, es decir, los
componentes son definidos a su vez mediante componentes ms detallados, y se procede de
esta forma hasta obtener partes indivisibles, es decir datos elementales.

Un flujo de datos se puede definir tericamente mediante la inclusin, seleccin e iteracin
de sus componentes, adems de incluir otros smbolos que aportan ms significado a cada
entrada en el DD. Cualquier herramienta de especificacin puede ser vlida para describir
los items del diccionario: expresiones regulares, lenguaje natural estructurado, notaciones de
estados, tablas de decisin, especificacin algebraica, etc.

Las definiciones en el DD, irn ordenadas alfabticamente. Se recomienda que
cada componente incluya:

- Flujos de datos:
- Nombre del flujo.
- Sinnimos.
- Composicin en BNF.
- Notas o comentarios.

- Datos elementales:
- Nombre.
- Sinnimos.
- Valores de los datos y su significado.
- Notas.

- Ficheros:
- Nombre.
- Sinnimos.
- Composicin.
- Organizacin.
- Notas.
- Componentes de datos: (igual que en los Flujos de datos)

- Entidades externas:
- Nombre
- Descripcin

En un DD se presentan "alias" cuando al modelar un sistema hay datos que se nombran de
distinta manera y que en realidad representan el mismo dato. Su utilizacin no es muy
conveniente ya que se crean redundancias en la especificacin estructurada.


7. Descripcin de Procesos

Como vimos en la descripcin de los elementos del DD, cualquier herramienta de
especificacin puede ser vlida para describir los procesos: expresiones regulares, lenguaje
natural estructurado, notaciones de estados, tablas de decisin, especificacin algebraica, etc.

Recomendaciones:

- Incluir una entrada Nivel.Proceso (como se ha visto en la Numeracin de DFD), para
referenciar su posicin en el diagrama.
- No indicar los flujos de entrada y de salida
- Una buena descripcin del proceso podra hacerse utilizando el lenguaje natural
estructurado, pero pueden usarse otras herramientas, como ya hemos visto.

8. El proceso de obtencin de modelos.

La metodologa SSA propone un proceso de obtencin de modelos sucesivos, en los que
aparecen los aspectos lgicos y fsicos del sistema. Proporciona adems procedimientos de
anlisis y diseo a nivel de sistema, as como de los requerimientos del software.

SSA propone la obtencin de 4 modelos del sistema:
- Modelo fsico actual
- Modelo lgico actual
- Modelo lgico nuevo
- Modelo fsico nuevo

Podemos definir aspectos fsicos aquellos que dependen de la implementacin, y aspectos
lgicos los que no dependen de ella.

El trmino implementacin no debe entenderse como relativo a cdigo (implementacin
software), sino como el resultado de la asignacin de funciones a los elementos de que pueda
constar un sistema.

Los siguientes son aspectos fsicos que podran darse en un DFD:

- Referencias a nombres de departamentos.
- Referencias a lugares concretos.
- Nombres de personas.
- Ficheros fsicos.
- Detalles procedimentales.
- Dispositivos.
- Sistemas informticos ya existentes.

8.1. Modelo fsico actual

El modelo fsico actual se obtiene plasmando el flujo de informacin que observemos en el
sistema en su configuracin actual. Aunque procuremos evitar reflejar aspectos fsicos, el
carcter fsico de este primer modelo es inevitable:

- An no poseemos un grado de conocimiento del sistema (de sus aspectos esenciales,
de qu) como para abstraer todos los detalles fsicos (lo accidental, el cmo).

- La ausencia total de referencias fsicas podra dificultar la comunicacin con los
usuarios, justo en la fase en que ms necesitamos obtener informacin de ellos.

8.2. Modelo lgico actual

Se trata de eliminar los aspectos fsicos del modelo del sistema actual. Para ello:

1. Reestructurar la jerarqua de DFD:

Construir DFD expandidos en los que eliminaremos duplicidades, y volveremos a
agrupar los procesos, en diagramas, con arreglo a criterios lgicos. Cuando un DFD
contiene referencias fsicas es fcil que un mismo procesamiento (desde el punto de
vista lgico) 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.

Tambin puede suceder que el mero hecho de la dispersin geogrfica de un
procesamiento genere necesidades de procesamiento que desaparecen en cuanto se
elimina la dispersin.

2. Obtener un equivalente lgico a la estructura de ficheros:

Se tratara de estudiar en conjunto los ficheros del sistema y obtener una estructura
equivalente, con la misma informacin, pero una estructura ms adecuada.
Bsicamente se trata de descomponer las estructuras complejas en estructuras simples,
tipo tuplas relacionales, y normalizar la estructura resultante. Esta normalizacin es
til de cara a la obtencin del modelo lgico, an cuando no se piense hacer uso de un
SGBD.

DeMarco propone una tcnica que partiendo de los ficheros permite obtener una
estructura de tablas en tercera forma normal.

Otros proponen obtener un diagrama entidad-relacin equivalente, a la estructura de
ficheros, y realizar un diseo convencional a partir de ste.

3. Revisar la estructura resultante, eliminando detalles fsicos residuales:

No est de ms hacernos acompaar de los usuarios en alguno de estos recorridos;
rememorando las caractersticas fsicas eliminadas; para asegurarnos de la completitud
del modelo; y familiarizarnos con el nuevo modelo lgico.

8.3. Modelo lgico 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 jerarqua de DFD detectando las partes del sistema que se vern 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 informacin a travs 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,
drsticamente si es necesario, las zona del cambio. Esto, por supuesto, a nivel lgico,
introduciendo nuevos flujo y procesos, sin anticipar detalles fsicos de la nueva
implementacin del sistema.

Esta labor debe hacerse poniendo en prctica todas las indicaciones dadas (buena
descomposicin funcional, completitud y coherencia del DD).

4. Verificacin y validacin.

Los diagramas deben someterse al proceso de verificacin y validacin expuestos
anteriormente.


8.4. Modelo fsico nuevo

Se trata de seguir el proceso inverso, revistiendo de detalles fsicos el modelo lgico nuevo
para obtener una nueva implementacin del sistema. Esta fase, como la anterior son creativas,
no de anlisis, sino de diseo (a nivel de sistema, no de diseo de subsistemas software).

La estrategia recomendada es la de proponer varias opciones, labor creativa, a la que
suceder una labor destructiva de evaluacin de opciones y de seleccin de la ms adecuada,
o de proponer nuevas opciones si ninguna de las disponibles se considera viable.

En todo el proceso la participacin de los usuarios debe ser activa, y en la seleccin decisiva.

Los aspectos a decidir van desde:

- La distribucin geogrfica del sistema.
- y el nivel de automatizacin a implantar, pasando
- por los requerimientos hardware, y la configuracin de las interfaces hombre-
mquina.

Tambin pueden plantearse nuevas formas de organizacin y funcionamiento, a nivel de
sistema.

Por ltimo habrn de delimitarse las restricciones de costo y tiempo de ejecucin de los
distintos subproyectos a emprender, y de los productos y servicios a contratar.

Para ilustrar estos aspectos ser necesario elaborar algunos DFD fsicos que: no sern tan
detallados como los DFD lgicos; no estn llamados a sustituirlos, sino a ilustrar las
decisiones de diseo fsico.

No ser necesario en cambio modificar el DD, todo lo ms habr que aadir algn trmino al
glosario del proyecto.

Por lo que respecta a los subsistemas software, lo que ms nos atae ahora, lo que aporta el
modelo fsico es:
- La seleccin de los subsistemas a automatizar.
- Las restricciones de costo-tiempo (elementos de planificacin).
- Los requerimientos no funcionales de los subsistemas software.

La especificacin de los requerimientos funcionales queda cubierta con los productos del
diseo lgico.


Apndice II
Tcnicas de Obtencin de Informacin

1. Introduccin

Disponer de tcnicas eficaces de obtencin de informacin es vital en el desarrollo de
proyectos de sistemas. Estas tcnicas son utilizadas durante todas las fases del ciclo de vida
del desarrollo de sistemas.

Las tcnicas de obtencin de informacin son procesos formales que utilizan procedimientos
de bsqueda, entrevistas, cuestionarios, muestreo y otras tcnicas para recoger toda la
informacin disponible sobre los sistemas, sus necesidades y las preferencias de los usuarios.

Existen muchas ocasiones para obtener informacin durante el ciclo de vida del desarrollo de
sistemas. Sin embargo, la obtencin de informacin es de vital importancia principalmente
durante las fases de la planificacin y anlisis 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 obtencin de informacin es necesaria tambin durante las fases de diseo y soporte, pero
en menor medida. Durante el diseo de sistemas intenta incrementar sus conocimientos sobre
la tecnologa elegida para el nuevo sistema. Durante la fase de soporte de sistemas, la
obtencin de informacin adquiere importancia para determinar en qu medida alcanza el
sistema el punto a partir del cual ha de plantearse desarrollarlo de nuevo.

2. Clasificacin

Una vez justificada la necesidad de conocer tcnicas de obtencin de informacin pasamos a
discutir las tcnicas ms utilizadas para el desarrollo de sistemas. Para obtener el xito en ste
cometido es necesario tener un conocimiento de todas estas tcnicas. Normalmente, los
analistas aplican varias de ellas a lo largo de cada proyecto de sistemas. Para poder elegir la
ms adecuada en una situacin dada, habrn de conocerse las ventajas y los inconvenientes de
cada una de estas tcnicas:

Muestreo de documentacin, formularios y archivos existentes
Investigacin y visitas a instalaciones
Observacin del entorno de trabajo.
Entrevistas
Cuestionarios
Diseo conjunto de aplicaciones

3. Muestreo de documentacin, formularios y archivos
existentes

Cuando se estudia un sistema existente, puede conseguirse una buena comprensin del mismo
si se analizan la documentacin, los formularios y los archivos existentes. Un buen analista
deduce los hechos antes de la documentacin existente que de las personas.

Qu clase de documentos pueden informarnos sobre la naturaleza de un sistema? El primer
documento que debera buscar el analista es el esquema de la organizacin. A continuacin,
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.

Adems de los documentos que describen el problema, existen normalmente documentos que
describen la funcin de empresa en fase de estudio o de diseo. Adems, no ha de olvidarse
de verificar la documentacin de los estudios y diseos previos sobre los sistemas llevados a
cabo por consultores y analistas de sistemas.

En cuanto a archivos, programas y formularios, como no sera prctico estudiar todas las
presencias de cada uno de los formularios y archivos existentes, los analistas suelen aplicar
tcnicas de muestreo para obtener una idea general de lo que est sucediendo en el sistema.

4. Investigacin y vistas a instalaciones

Una segunda tcnica de obtencin de informacin consiste en llevar a cabo una detenida
investigacin de la aplicacin y el problema. Buenas fuentes de informacin son las
publicaciones informticas disponibles comercialmente, as como las revistas que leen
tpicamente los usuarios finales. De esta forma, ser posible aprender el modo en que
actuaron otros para resolver problemas similares. Tambin puede saberse as si existen o no
paquetes de software que puedan resolver nuestro problema.

Una forma similar de investigacin consiste en visitar otras empresas o departamentos que
hayan vivido problemas similares. Los miembros de las sociedades profesionales pueden
suministrarnos interesantes contactos.

5. Observacin del entorno de trabajo

La observacin es una de las tcnicas ms eficaces para reunin de datos que nos ayuden a
conseguir comprender un sistema.

La observacin es una tcnica de obtencin de informacin durante la cual los analistas o
bien participan activamente o bien actan como espectadores de las actividades llevadas a
cabo por una persona para conocer mejor un sistema.

Esta tcnica 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 estn claras.

Incluso aunque disponga de un plan de observacin 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 tcnica de observacin:

Ventajas

1. Los datos recogidos por observacin pueden ser muy fiables.
2. El analista de sistemas puede ver exactamente lo que se hace. Adems puede obtener
los datos que describen el entorno fsico de la tarea.
3. La observacin es relativamente barata en comparacin con otras tcnicas.
4. La observacin permite al analista de sistemas hacer medidas del trabajo.

Inconvenientes

1. Como las personas suelen sentirse incmodas cuando son objeto de observacin,
pueden hacer las cosas de forma diferente sin darse cuenta.
2. En el momento de la observacin, 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 planificacin al analista de sistemas.
4. Las tareas que se observan estn 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 estndar, pueden proceder temporalmente de forma
correcta mientras estn siendo observadas.

Directrices para la observacin

La observacin debera hacerse primero cuando la carga de trabajo es normal. Ms adelante,
pueden llevarse a cabo observaciones durante los periodos de mximo trabajo para reunir
informacin que mida los efectos causados por un mayor volumen de trabajo. El analista de

sistemas podra obtener tambin muestras de los documentos o formularios empleados por las
personas que observa.

Con una planificacin adecuada completa, puede iniciarse la observacin real. Una
observacin eficaz es difcil 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 tcnicas de observacin:

1. Determinar el quin, el qu, el dnde, el cundo, el porqu y el cmo de la
observacin.
2. Obtener autorizacin de los directivos o supervisores adecuados.
3. Informar a quienes sern observados del propsito de la observacin.
4. Tratar de pasar inadvertido.
5. Tomar notas durante la observacin o inmediatamente despus de la misma.
6. Revisar las notas de la observacin 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 ingeniera del software con la finalidad de
demarcarla de otras tcnicas de obtencin de informacin.

Esta definicin podra ser:

Tcnica de obtencin de informacin mediante el dilogo mantenido en un encuentro
formal y planeado, entre una o ms personas fuente y una o ms destino, en el que se
transforma y sistematiza la informacin conocida por aquellas, de forma que sea un
elemento til para el desarrollo de un proyecto de software.

Aclararemos algunos de los trminos que han sido utilizados en la anterior definicin:

Formal: Lo utilizamos para referirnos a que los encuentros deben ser concertados y
realizados segn ciertas reglas del entorno ( considerar las reglas de cada
entorno). Como ejemplos podramos 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 debern
ser estudiadas previamente.

Fuente: Sern los usuarios para los cuales se intenta desarrollar la aplicacin.

Destino: En este trmino englobamos a los ingenieros de sistemas y analistas
encargados de realizar el proyecto.

6.1. Clasificacin

El criterio que seguiremos para clasificar las entrevistas se basar en el modo de realizacin
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.

3. Mixta:

Agrupamos preguntas tanto del primer tipo como del segundo.

Las ventajas (V) e inconvenientes (I) que podramos encontrarnos al utilizar el primero o el
segundo tipo de entrevista quedan reflejadas en la siguiente tabla.

Caracterstica Estructurada No estructurada
Costo de preparacin I V
Flexibilidad en preguntas I V
Flexibilidad en reas de informacin a explorar. I V
Sesgo personal del entrevistador V Depende del entrevistador
Preparacin del entrevistador V I
Evaluacin objetiva de preguntas y respuestas V I
Comodidad de los entrevistados Depende del
entrevistado
Depende del entrevistador
Duracin V I
Rendimiento de la entrevista (informacin/tiempo) V Depende del entrevistador
Administracin y evaluacin V I
Uniformidad entre entrevistados V Depende del entrevistador

Tabla II-1. Ventajas e inconvenientes de utilizar entrevistas estructuradas o no estructuradas

Conclusin: El tipo mixto podra resolver los problemas de ambos. En el punto siguiente
veremos lo apropiado de adaptarse en cada caso a las necesidades de recogida
de informacin.

En general las ventajas e inconvenientes de las entrevistas en relacin a otras tcnicas de
obtencin de informacin son las siguientes:

Ventajas

1. Las entrevistas dan al analista la oportunidad de animar al entrevistado a responder
con libertad y espritu abierto a las preguntas. Al establecerse una compenetracin, el
analista de sistemas puede inducir en el entrevistado un sentimiento de contribucin
activa al proyecto de sistemas.
2. Las entrevistas permiten al analista de sistemas obtener mayor informacin del
entrevistado.
3. Permiten adems adaptar o replantear las preguntas para cada persona.
4. Dan la oportunidad de observar la comunicacin no verbal del entrevistado.

Inconvenientes

1. Hacer entrevistas lleva mucho tiempo y es, por tanto, un mtodo costoso.
2. El xito de las entrevistas depende fuertemente de las dotes de comunicacin del
analista de sistemas.
3. Las entrevistas pueden perder utilidad debido a la posicin de los entrevistados.

6.2. Plan de entrevistas

Es conveniente elaborar un plan de entrevistas ya que la finalidad de stas es recoger la mayor
informacin posible sin ambigedades ni informacin no relevante para el proyecto. Para ello
se pueden seguir los siguientes pasos:

1. Realizar una toma de contacto inicial que permita:

- Conocer los objetivos generales del sistema.
- Conocer la estructura jerrquica de los diferentes usuarios
- Determinar qu informaciones adicionales deben ser recogidas de fuentes externas
al sistema: legales, bibliogrficas, etc.

Podemos citar los siguientes ejemplos:

- Sistema experto: teora del sistema experto, conocimientos del rea...
- Biblioteca: normativas bibliogrficas, catlogos ...

2. Identificar jerarquas de usuarios e identificar usuarios clave (aquellos que pueden
proporcionar mejor informacin )

3. Elaborar un plan de entrevistas:

- En la especificacin del sistema y del software es cuando la entrevista tiene mayor
valor como tcnica.

- Se debe elaborar un plan y un calendario de entrevistas para realizar esta
definicin, que puede formar parte de la planificacin de la especificacin del
sistema.
- El plan necesitar ser modificado conforme se desarrolle el estudio y el que sea
ms 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 estructuracin. Incluso puede
llegar el momento en el que se concierten entrevistas para resolver problemas especficos
perfectamente delimitados.

6.3. Estrategia de entrevista

6.3.1. Preparacin

Una entrevista no debe improvisarse, debe prepararse seriamente. Esta preparacin implica la
realizacin de los siguientes puntos:

Identificacin del (los) interlocutor (es).

Si viene impuesto debemos conocer:

- Su posicin dentro del sistema
- Su grado de conocimiento del tema o de aspectos particulares de ste.
- Su deseo de cooperacin

Si podemos escogerlo, debe:

- Conocer los problemas bajo todos sus aspectos (prcticos 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 jerrquicos (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 ms informado.
- En empresas pequeas, 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 jerarqua, por varios motivos:

o Favorecer la buena disponibilidad del personal de cara al producto que se
elabora (hacer que se sientan implicados).

o Conocer parcelas de actividad srdidas o intrascendentes, pero que puedan ser
fundamentales para el sistema.
o Conocer las actitudes de todos los usuarios, sus problemas y cmo los puede
aliviar el nuevo sistema (o empeorar).

- Cuidado con los presuntos conocedores de la informtica: respetar sus opiniones,
jams despreciar su trabajo, ser siempre crticos.

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 rpidamente 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 antelacin da visos de formalidad.
- El ltimo es que el entrevistado conozca el motivo de la entrevista y pueda
preparrselo.

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 da.

Preparacin 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 ms nos interesan.

Esto se podra 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 preparacin de entrevista )

6.3.2. La entrevista

Expondremos observaciones prcticas 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 cortesa el tiempo que su interlocutor le puede dedicar.
Precisar que deseara 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 dilogo 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, permitirn deducir las informaciones deseadas.
Evitar que el interlocutor se salga del tema, pero no interrumpindole jams.
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 inters en los trabajos que realiza su interlocutor. Preguntarle qu
dificultades tiene: esto le dar ocasin para informarle de sus tareas, sus
responsabilidades, sus mtodos 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 autnticas preguntas-respuestas (en
entrevistas libres).
Si se presenta la ocasin, no dudemos en aliviar la atmsfera concediendo algo
de importancia a acontecimientos anodinos: alguien que abre la puerta del
despacho, cigarrillos, etc.
Hacer, peridicamente, el balance mental de los problemas evocados.
No utilizar jams trminos tcnicos, o explicarlos en trminos sencillos y
comprensibles.
No olvidar tomar notas discretamente para evitar distraer al entrevistado.
Procurar no superar el lmite de tiempo que su interlocutor le ha concedido. En
cualquier caso este ha de ser menor de una hora.

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, reunin con la participacin de otras personas, etc. Tambin habra que
determinar, si es posible, los perodos, 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 habra 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, recordndole
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 informacin
recabada.
Respetar el plazo de envo de la memoria o informe.
Enviar los documentos prometidos en los plazos fijados.
Dar las gracias al superior jerrquico 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 poblacin, generalmente esta poblacin es amplia. Segn el contenido de los
cuestionarios podemos clasificarlos en los siguientes tipos:

- Abiertos:
Las respuestas no estn delimitadas, esto permite mayor libertad de expresin.

- Cerrados:
Se fuerza a respuestas concretas. Un mismo tipo de pregunta puede formularse para
obtener diferente rango de respuestas:

Eleccin 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,

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 cuntos 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.)
Seleccin de respuestas limitadas. Por ejemplo: Las causas ms
frecuentes de circuitos integrados defectuosos son:

a) Fallo en la impresin de la pista.
b) Fallo en la conexin de las patillas.
c) Fallo en el encapsulado de plstico.

- Mixtos: una combinacin de los anteriores

Los buenos cuestionarios no solo se escriben sino que se disean. Una buena elaboracin
acompaada de una prueba previa, tanto del formato como de las preguntas, son la base de
una recopilacin de datos significativa a travs del cuestionario. Introduciremos una serie de
pautas que ayudarn en la formulacin de un cuestionario:

1. Determinar qu datos necesitan recabarse y qu personas son las ms calificadas
para proporcionarlos. Si hay otros grupos que pueden proporcionar datos variantes
y mayor visin tambin se identificarn.
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 estn escritas de forma que se escoger la respuesta
preferida.
e. Preguntas que se interpretarn 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 pequeo de personas, para detectar
otros problemas posibles. As no solamente se describen los problemas en cuanto a

su escritura, espaciado, ortografa, y mtodos de registro de respuestas, sino
tambin proporciona una indicacin del tipo de respuestas que se recopilarn en un
grupo mayor. Si existen muchas respuestas inesperadas, se captarn 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 anlisis 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 edicin, correcciones de mecanografa 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 mayora, 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 econmico para recoger datos de un
amplio nmero de personas.
3. Los cuestionarios permiten a las personas mantener el anonimato. Por consiguiente, es
ms probable que stas informen de los hechos reales, en vez de decir lo que piensan
que su jefe aprobara que dijera.
4. Las respuestas pueden incluirse en tablas y analizarse rpidamente.

Inconvenientes

1. El nmero de encuestados es, a menudo, insuficiente.
2. No existe garanta de que los encuestados respondan o expliquen todas las preguntas.
3. Los cuestionarios suelen ser poco flexibles. Impiden que el analista de sistemas
obtenga informacin 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 difciles de preparar.

8. Diseo conjunto de aplicaciones

La tcnica clsica de elaboracin 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 informacin estn haciendo uso de
sesiones de trabajo en grupo como sustitutas de las entrevistas.

El diseo 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 tcnica son esencialmente los mismos que los de las entrevistas, con la
salvedad de que se necesitan ms 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 direccin de una sesin de diseo conjunto de aplicaciones requiere una fuerte
preparacin, y seguir una serie de etapas: definicin del proyecto, direccin de una
investigacin general previa, planificacin de la sesin, direccin de la sesin y presentacin
de resultados.

8.1. Definicin del proyecto

El analista debe entrevistar a los propietarios del sistema para determinar la panormica
general de requisitos y expectativas. En estas entrevistas, el analista debe desempear las
siguientes funciones:

1. Pedir a los propietarios del sistema que sealen a los usuarios que participarn en la
sesin de DCA.
2. Proponer o solicitar fechas para las cuales deban llevarse a cabo las sesiones DCA.
3. Obtener su autorizacin para permitir a los usuarios del sistema tomar parte durante
toda la sesin.
4. Resumir y revisar la definicin del proyecto.
5. Seleccionar el coordinador (o moderador) y el escribiente de la sesin DCA.
6. Seleccionar el lugar para celebrar la o las sesiones DCA.

8.2. Direccin de una investigacin general previa

En el mbito de definicin 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 investigacin, 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 sesin DCA.

8.3. Planificar la sesin DCA

La siguiente etapa consiste en la planificacin de la sesin DCA

Si fuera necesario, se dar la formacin adecuada al moderador y al escribiente de la
sesin.
Se distribuir entre los participantes adecuados la agenda de la misma y la
documentacin anteriormente reunida.
Se programar el lugar donde se llevar a cabo la sesin.
Se desarrollar un guin que deber seguirse durante la sesin DCA (el guin es
normalmente una ampliacin en detalle de la agenda que usar el moderador).
Se prepararn soportes de transparencias u otros medios de exposicin con apoyo de
equipos audiovisuales.

Hacer una planificacin correcta es fundamental para el xito de una sesin DCA. Una vez
completa la planificacin, puede darse paso al inicio de la sesin DCA.

8.4. Direccin de la sesin

La sesin DCA comienza con los comentarios de apertura, la introduccin y un breve repaso
de la agenda y los objetivos de la sesin DCA. El moderador dirigir la sesin conforme al
guin preparado. Para dirigir con xito la sesin, el moderador deber seguir las directrices
que se proponen a continuacin:

No desviarse excesivamente de la agenda propuesta.
Vigilar la programacin.
Asegurar que el escribiente puede tomar notas.
Evitar el uso de argot tcnico.
Aplicar tcnicas de resolucin de conflictos.
Permitir grandes pausas.
Estimular el consenso del grupo.
Estimular la participacin de todos los usuarios impidiendo que unos dominen sobre
otros.

8.5. Presentar los resultados

El producto final de una sesin DCA es tpicamente un documento escrito formal. Este
documento es esencial para confirmar que todos los participantes en la o las sesiones estn de
acuerdo con las especificaciones. El contenido y la organizacin de las especificaciones
depender evidentemente de los objetivos de la sesin DCA.

Apndice III
Tareas a realizar en la fase de definicin
de un proyecto

1. Anlisis 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 anlisis de los
problemas.

El software como un subsistema ms mantiene relaciones con otros subsistemas de la
organizacin (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 abstraccin 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 anlisis tcnico y econmico.
- Asignar funciones al hardware, software, personal, B.D. y otros elementos del
sistema.
- Establecer las restricciones de presupuesto y planificacin temporal.
- Crear una definicin de sistema que forme el fundamento de todo el trabajo de
ingeniera subsiguiente.

1.1. Identificacin de necesidades

El analista se rene con el cliente y el usuario final. El cliente puede ser el representante de
una compaa, el departamento de marketing de la compaa del analista, u otro departamento
tcnico (para el desarrollo de un producto interno).

La intencin es entender los objetivos del producto y definir las metas necesarias para
alcanzar esos objetivos.


- Una vez identificadas las metas globales, se evala la informacin suplementaria:
- Existe la tecnologa para construir el sistema?
- Qu recursos especiales de desarrollo y fabricacin sern necesarios?
- Qu lmites se han puesto al presupuesto y planificacin temporal?

- Si el nuevo sistema es un producto a vender a muchos clientes, se plantean a su
vez las siguientes cuestiones:
- Cul es el mercado potencial del producto?
- Cmo es comparativamente este producto con los de la competencia?
- Qu posicin ocupa este producto en la lnea general de produccin de la
compaa?

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 prdidas de esfuerzo es necesario un estudio de
viabilidad lo antes posible.

La viabilidad y el anlisis de riesgo estn relacionados: Si el riesgo del proyecto es alto, la
viabilidad de producir software de calidad se reduce.

Durante la ingeniera de productos centramos nuestro inters en las siguientes reas:

- Viabilidad econmica: evaluacin del coste de desarrollo sopesado con los
ingresos netos o beneficios obtenidos.

- Viabilidad tcnica: un estudio de funcin, rendimiento y restricciones que pueden
afectar a la consecucin de un sistema aceptable.

- Viabilidad legal: determinar cualquier infraccin, violacin o responsabilidad
legal en que se podra incurrir por el desarrollo del sistema.

- Alternativas: Evaluacin de enfoques alternativos al desarrollo del producto.

No es necesario un estudio de viabilidad para sistemas en que la justificacin econmica es
obvia, el riesgo tcnico es bajo, se esperan pocos problemas legales y no existe ninguna
alternativa razonable.

La justificacin econmica es generalmente la consideracin fundamental para la mayora de
los sistemas. La justificacin econmica incluye una amplia gama de aspectos a tener en
cuenta como son el anlisis 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.

La viabilidad tecnolgica es frecuentemente el rea ms difcil de valorar en la etapa del
proceso de ingeniera del producto. Como los objetivos, funciones y rendimiento son poco
claros, cualquier cosa parece posible si se hacen las suposiciones correctas.

La viabilidad legal comprende una gama muy amplia de aspectos que incluyen contratos,
responsabilidades legales, infracciones y un montn de trampas frecuentemente desconocidas
para el personal tcnico.

El grado con el que se consideran las alternativas est a menudo limitado por restricciones de
tiempo y costes; sin embargo, no debera despreciarse una alternativa legtima por no estar
subvencionada.

El estudio de viabilidad es revisado:

- Primero por el jefe del proyecto: para valorar la fiabilidad del contenido.
- Por la direccin: para valorar el estado del proyecto.

El estudio debera concluir en una decisin adelante/abandonamos.

1.3. Anlisis econmico

Es una de las informaciones ms importantes de un estudio de viabilidad: el llamado anlisis
coste / beneficio (una valoracin de la justificacin econmica para un proyecto)

Determina los costes para el desarrollo del proyecto y los pondera con los beneficios
tangibles (medibles directamente en dinero) e intangibles del sistema.

1.4. Anlisis tcnico

Se evalan los principios tcnicos del sistema al mismo tiempo que se recoge informacin
adicional sobre el rendimiento, la fiabilidad, las caractersticas de mantenimiento y la
productividad

Se suele comenzar con una valoracin de la viabilidad tcnica del sistema propuesto:

Riesgo de desarrollo:
Puede desarrollarse el elemento del sistema de manera que se consigan la funcin y
rendimiento necesario dentro de las restricciones descubiertas durante el anlisis?

Disponibilidad de recursos:
Tenemos disponible una plantilla cualificada para desarrollar el elemento del
sistema en cuestin?
Tenemos disponibles otros recursos necesarios (hardware y software) para construir
el sistema?

Tecnologa:
Ha progresado la tecnologa respectiva hasta el punto que sea capaz de soportar el
sistema?
Qu tecnologas se requieren para lograr el funcionamiento y rendimiento del
sistema?
Cmo afectan estos aspectos tecnolgicos a los costes?

Tareas

Identificar elementos del sistema actual: software, hardware, personas, B.D.,
documentacin, procedimientos.
Identificar los distintos subsistemas.
Identificar la informacin: ingeniera de la informacin.
Identificar el producto: ingeniera del producto.
Identificar las necesidades del cliente.
o Establecer los objetivos.
o Establecer las restricciones.
o Obtener funcionalidad del producto.
o Obtener rendimiento del producto.
o Obtener la fiabilidad del producto.
o Establecer la interfaz del producto
Establecer la viabilidad.
o Viabilidad econmica.
o Viabilidad tcnica.
o Viabilidad legal.
o Alternativas
Configuraciones alternativas.
Criterios empleados en la seleccin de la configuracin.
Configuracin elegida y motivos.
o Anlisis econmico: coste/beneficio
o Anlisis tcnico.
Riesgo de desarrollo.
Disponibilidad de recursos.
Tecnologa.
o Revisin del estudio de viabilidad.
o Decisin de continuar.
Considerar caractersticas de mantenimiento.
Descripcin funcional y de los datos
o Diagrama de contexto.
o Diagramas de niveles o de subsistemas.
o Asignacin de elementos del sistema.
o Diccionario de datos.
o Descripcin de los procesos.
Asignar funciones al hardware, software, personal, B.D. y otros elementos del sistema.
Establecer restricciones de presupuesto y planificacin temporal.

2. Aspectos de Gestin del proyecto

Tareas

Identificar los participantes en el proyecto (Gestores superiores, gestores tcnicos,
profesionales, clientes y usuarios finales)
Especificar el tipo de equipo de desarrollo (DD, DC, CC; cerrado, aleatorio, abierto,
sincronizado)
Establecer el mbito:
o Contexto
o Objetivos de informacin
o Funcin y rendimiento
o Restricciones (tcnicas y de gestin)
Seleccionar el modelo de proceso (paradigma de ingeniera)
Definir el tipo de aplicacin software a desarrollar (de sistemas, de tiempo real, de
gestin, de ingeniera, cientfico, empotrado, de computadoras personales, de I.A., etc.)
Definir los elementos de ingeniera del software
o Definir los mtodos (actividades de planificacin, anlisis, diseo, etc.)
o Definir las herramientas a utilizar.
o Definir los procedimientos:
Secuencia de aplicacin de los mtodos
Informacin necesaria.
Controles de calidad.
Gestin de cambios.
Guas de desarrollo.
o Definir el paradigma de I.S. a utilizar.
Identificar las etapas
Identificar los hitos
Identificar productos de cada etapa
Definir las actividades estructurales
Descomponer la funcionalidad del producto
Estimar recursos para cada par (funcin-actividad estructural)
Establecer fechas de inicio-fin para cada par.
Establecer los productos que surgirn como consecuencia de cada par.
Descomponer el proceso (tareas para cada actividad estructural).

3. Planificacin del proyecto

En esta fase se realiza el anlisis del riesgo una vez establecido el mbito del proyecto,
asignando los recursos, estimndose los costes, definiendo cada una de las tareas a desarrollar
y planificando el trabajo.

Un producto software se comprende mejor segn se va desarrollando el anlisis, diseo, y
codificacin del mismo. Sin embargo, el proyecto no debe estar supeditado a la disponibilidad
de informacin suficiente para iniciar la planificacin preliminar, aunque se debe tener en
cuenta que esta planificacin preliminar est sujeta a cambios que se producirn a lo largo de
la vida del proyecto a medida que se conozca ms informacin sobre el mismo.

Tareas

Establecer el mbito:
o Contexto
o Objetivos de informacin
o Funcin y rendimiento
o Restricciones (tcnicas y de gestin)
Seleccionar el modelo de proceso (paradigma de ingeniera)
Definir los estndares de documentacin.
Estimar esfuerzo de desarrollo (o coste)
o Elegir mtodo de estimacin.
o Cobertura del mtodo
o Datos histricos utilizados en la estimacin
o Datos del proyecto utilizados en la estimacin
o Estimacin segn el mtodo elegido
o Resultados obtenidos (esfuerzo, coste $ y duracin)
o Margen de error
Estimar recursos:
o Humanos
Estructura del equipo
o Hardware
Sistema de desarrollo
Sistema de explotacin
Otros elementos
o Software
Herramientas orientadas al cdigo
Herramientas de metodologa
Herramientas de cuarta generacin
Desarrollar una estrategia de solucin
o Posibles soluciones
o Solucin elegida

Anlisis de riesgo.
o Elaborar lista de comprobacin de elementos de riesgo
Riesgos genricos
Riesgos especficos de producto
o Proyeccin y evaluacin del riesgo riesgo = {probabilidad + coste}
o Definir un nivel de referencia para el riesgo (temporizacin, coste o
rendimiento).
o Supervisin del riesgo
o Gestin del riesgo y planes de contingencia.
Planificacin temporal.
o Definir modelo de ciclo de vida.
o Definir las tareas a realizar en funcin del tipo de proyecto.
Descomponer el producto
Descomponer el proceso
o Determinar las interdependencias entre tareas
Red de tareas
o Establecer duracin de las tareas
o Realizar anlisis PERT
Representar grfico con dependencias de tareas.
Asignar duracin de las tareas
Calcular tiempos PERT
Calcular tiempos ms prximos y ms lejanos para cada suceso.
Calcular holguras y camino crtico
o Ajustar las tareas a un calendario
Establecer fecha de finalizacin (fija o con holgura)
Grfico de tiempo (Grfico Gantt)
o Asignar los recursos a las tareas.
o Validar el esfuerzo (comprobar que los recursos asignados no sobrepasan a los
que se tienen)
o Definir los resultados de cada tarea.
o Establecer hitos o puntos de control
o Determinar el seguimiento del proyecto
o Establecer cmo se garantizar la calidad
Configurar el equipo de gestin de calidad
Establecer calendario de revisiones
Establecer requisitos a comprobar en cada revisin
o Establecer la gestin de los cambios (gestin de la configuracin)
Determinar la configuracin del software
Programas
Documentos
Datos
Cmo identificar el cambio
Cmo controlar el cambio
Cmo informar del cambio a las personas implicadas.


4. Anlisis de requisitos

En esta fase se procede a la recogida de toda la informacin posible sobre el software que se
pretende construir, y sobre el problema que se pretende solucionar. Es decir, en esta fase el
analista tiene el cometido de comprender el dominio de la informacin que manejar el
software, el procesamiento a que debe someterse esa informacin, el rendimiento de este
procesamiento, as como las interfaces tanto en la entrada, como en la salida de la
informacin para estos procedimientos.

El objetivo de esta etapa es el especificar total, concisa, consistentemente y sin ambigedades
los requisitos tcnicos del producto, emplendose para ello una notacin formal.

La ERS se basa en el documento de anlisis del sistema, y en esta fase se detallan los
requisitos que se especificaron a un alto nivel de abstraccin en la fase de planificacin inicial
con el fin de definir las caractersticas que el producto de programacin deber tener.

Tareas

- Entrevistas con el cliente o cualquier otra tcnica de recogida de informacin que
nos aporte una visin detallada del sistema a desarrollar.

- Resumen del producto y del objetivo del mismo, as como los ambientes de
desarrollo, operacin y mantenimiento. Esta informacin ha sido previamente
registrada en el plan de proyecto software, y aqu se vuelve a reflejar como una
introduccin al documento.

- Especificacin de los requerimientos funcionales del software utilizando un
mtodo de especificacin (en nuestro caso podemos utilizar la metodologa SSA).
Independientemente del mtodo utilizado debe especificarse:

1. El dominio de la informacin, tanto el dominio de los datos como de las
funciones. Contiene tres visiones diferentes de los datos que son procesados
por las funciones:

- El flujo de la informacin, es decir, cmo la informacin se mueve a
travs de la arquitectura del sistema.

- El contenido de la informacin, es decir, qu informacin se mueve
a travs del sistema y qu significa esa informacin en el dominio del
problema.

- La estructura de la informacin, es decir, cmo esa informacin se
encuentra estructurada, qu forma tiene dentro de la estructura del
sistema.


2. La particin o descomposicin del problema. El problema debe
subdividirse de forma que se descubran los detalles de una forma progresiva o
jerrquica.

3. Representaciones lgicas y fsicas, la visin lgica de los requisitos del
software presenta las funciones que se han de realizar y la informacin que se
debe procesar con independencia de los detalles de implementacin. La visin
fsica presenta una manifestacin del mundo de las funciones y de
procesamiento y las estructuras de informacin. Esta visin indica la
asignacin existente o propuesta para todos los elementos del sistema.

- Especificacin de requerimientos no funcionales del software, requisitos de
operacin, software, personal, recursos, etc.

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

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

- Especificar criterios de validacin que nos guiarn a la hora de aceptar o rechazar
el sistema. Esta gua deber contemplar cada uno de los requisitos expuestos en otras
secciones.

- Revisin de la especificacin de requerimientos. Esta revisin debe ser llevada a
cabo tanto por el desarrollador del software como por el cliente. Los revisores intentan
asegurarse de que la especificacin est completa, es consistente y exacta. (Al final
del guin se presentan algunas cuestiones a revisar).


Apndice IV
Formatos de Documento

1. Entrevistas

Introduciremos dos vertientes de esta propuesta de formato de documento, una
respecto a los elementos necesarios para un documento de preparacin de entrevista y otra
respecto a los elementos necesarios para un documento de resultado de las entrevistas.

I. Preparacin.
A. Identificacin de la entrevista:
1. Identificativo nico.
2. Preparada por: nombre(s) y cargo(s).
3. Fecha de preparacin.
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 preparacin.
B. Identificacin de los participantes previstos:
1. Entrevistado(s): nombre(s) y cargo(s).
2. Entrevistador(es): nombre(s) y cargo(s).
C. Objetivos : Se identificarn mediante numeracin, caracteres alfabticos, ...
D. Descripcin de los puntos a tratar y/o cuestionario: que tambin sern
identificados.
E. Previsiones respecto a la entrevista:
1. Lugar.
2. Fecha.
3. Hora.
4. Duracin prevista.
F. Recomendaciones a los entrevistadores:
1. Informacin previa a recabar.
2. Documentacin a revisar.
3. Informaciones pendientes de entrevistas anteriores.
4. Consideraciones especiales sobre los participantes.
5. Otras cuestiones.


II. Resultado.
A. Identificacin de la entrevista:
1. Identificativo de la preparacin.
2. Lugar.
3. Fecha.
4. Hora.
5. Duracin.
B. Incidencias sobre los participantes: Modificaciones sobre las previsiones
realizadas.
C. Cuerpo de la entrevista: Anotaciones para cada punto y/o preguntas del
cuestionario.
D. Informe final sobre la entrevista:
1. Informacin obtenida.
2. Informacin pendiente:
a. Documentos que los entrevistados deben entregar.
b. Documentos que los entrevistadores deben entregar.
c. Informacin olvidada en la entrevista.
3. Grado de cobertura de los objetivos.
4. Grado de participacin y colaboracin de los entrevistados.
5. Notas y recomendaciones especiales.


2. Anlisis del Sistema y Planificacin

FORMATO 1. Pressman, R.S.

I. Introduccin.
A. mbito y propsito del documento.
B. Visin general.
1. Objetivos.
2. Restricciones.
II. Descripcin funcional y de los datos.
A. Arquitectura del sistema.
1. Diagrama de contexto
2. Descripcin del diagrama de contexto
III. Descripcin de los subsistemas.
A. Especificacin del diagrama para el subsistema n.
1. Diagrama de flujo de datos.
2. Descripcin del DFD.
4. Restricciones.
5 Asignacin de componentes del sistema.
B. Diccionario de Datos.
C. Descripcin de los Procesos.
IV. Asignacin de funciones a los recursos.
V. Coste y Planificacin. (puede referenciarse al Plan de Proyecto).
VI. Apndices.

FORMATO 2. Fairley, R.E.

I. Definicin del problema.
II. Justificacin del Sistema.
III. Metas del sistema y del proyecto.
IV. Restricciones del sistema y del proyecto.
V. Asignacin de funciones a los elementos del sistema. (se puede usar SSA)
VI. Caractersticas del usuario.
VII. Ambientes de desarrollo/operacin/mantenimiento.
VIII. Estrategia de Solucin. Estudio de viabilidad.
IX. Prioridades para las caractersticas del sistema.
X. Criterios de aceptacin del sistema.
XI. Fuentes de Informacin.
XII. Glosario de trminos.


3. Plan de Proyecto Software

I. Introduccin
A. mbito del proyecto y Objetivos.
1. Declaracin del mbito.
2. Funciones principales.
4. Restricciones tcnicas y de gestin.
B. Modelo de ciclo de vida utilizado.
C. Definicin de los estndares de documentacin.
II. Estimaciones del proyecto
A. Datos histricos usados para las estimaciones.
B. Tcnicas de estimacin.
C. Estimaciones de esfuerzo, coste y duracin.
III. Riesgos del proyecto
A. Anlisis del riesgo.
1. Identificacin.
2. Estimacin del riesgo.
3. Evaluacin.
B. Gestin del riesgo.
IV. Planificacin Temporal.
A. Estructura de descomposicin del trabajo del proyecto.
B. Red de tareas (red Pert).
C. Grfico de Tiempo (grfico Gantt)
V. Recursos del Proyecto.
A. Personal.
B. Hardware y Software.
C. Tabla de Recursos (enlazados al grfico de tiempo)
VI. Organizacin del Personal.
A. Estructura de equipo (si procede).
VII. Apndices.
A. Glosario de trminos.
B. Bibliografa.
...


4. Estudio de Viabilidad

I. Introduccin.
A. Declaracin del problema.
B. Entorno de implementacin.
C. Restricciones.
II. Resumen de gestin y recomendaciones.
A. Objetivos importantes.
B. Comentarios.
C. Recomendaciones.
D. Impacto.
III. Alternativas.
A. Configuraciones alternativas del sistema.
B. Criterios empleados en la seleccin del enfoque final.
IV. Descripcin del sistema.
A. Exposicin abreviada del mbito.
B. Viabilidad de los elementos asignados.
V. Anlisis de coste/beneficio.
VI. Evaluacin del riesgo tcnico.
VII. Consideraciones legales.
VIII. Otros temas especficos del proyecto.


5. Especificacin de Requerimientos del Software

FORMATO 1. (Aconsejable)

I. Introduccin.
Descripcin de los fines y objetivos del software en el contexto de un sistema basado
en computadora. Debe contener una breve descripcin del software, de sus objetivos y
de las principales restricciones del proyecto software.
II. Descripcin de las interfaces del software con otros elementos del sistema.
Se describen las interfaces con el hardware, personas y bases de datos. En ocasiones
es necesario describir las interfaces con otro software existente o que debe disearse.
Es importante la descripcin del tipo de interface de usuario que se utilizar (puede
ayudar el manual preliminar de usuario).
III. Descripcin del dominio de la informacin.
A. Descripcin del flujo de informacin
B. Descripcin del contenido de la informacin.
C. Descripcin de la estructura de la informacin (para ello se puede utilizar un
modelo de especificacin de Bases de Datos, como el modelo Entidad-Relacin).
IV. Descripcin del dominio funcional.
A. Particin funcional.
B. Descripcin funcional.
1. Texto explicativo del proceso.
2. Restricciones.
3. Requerimientos no funcionales.
4. Diagramas de soporte.
V. Criterios de validacin.
Esta seccin, a la que generalmente no se presta ningn inters, es una de las ms
importantes. En ella se establecen que requerimientos funcionales y no funcionales
debern ser probados y cuales son los lmites para cada una de las pruebas.
A. Requerimientos de validacin.
Se especifican los requerimientos que formarn la base de las pruebas de
validacin.
B. Pruebas de validacin.
Discusin de los tipos de pruebas a realizar.
C. Recursos.
Recursos que sern necesarios para las pruebas de validacin.
VI. Glosario de trminos.
VII. Apndices.

La descripcin de los puntos III y IV suele realizarse en el contexto de un mtodo de
especificacin (como puede ser SSA, si este es el caso, tener en cuenta que el mtodo slo
especifica requerimientos funcionales, habr que tener en cuenta los requisitos no
funcionales).


FORMATO 2. Pressman, R.S.

I. Introduccin.
A. Referencia del sistema.
B. Descripcin general.
C. Restricciones del proyecto de software.
II. Descripcin de la informacin.
A. Representacin de la informacin.
B. Representacin del flujo de la informacin.
1. Flujo de datos.
2. Flujo de control.
III. Descripcin funcional.
A. Particin funcional.
B. Descripcin funcional.
1. Descripcin del procesamiento.
2. Restricciones / limitaciones.
3. Requisitos de rendimiento.
4. Restricciones de diseo.
5. Diagramas de soporte.
C. Descripcin del control.
1. Especificacin del control.
2. Restricciones de diseo.
IV. Descripcin del comportamiento.
A. Estados del sistema.
B. Eventos y acciones.
V. Criterios de validacin.
A. Lmites de rendimiento.
B. Clases de pruebas.
C. Respuesta esperada del Software.
D. Consideraciones especiales.
VI. Bibliografa.
VII. Apndice.


6. Identificacin de la Documentacin

Los documentos realizados se identificarn adecuadamente. A continuacin figura un
ejemplo. Nosotros podemos usarlo como base o definir nuestros propios convenios de
identificacin.

XXX-Z-V-F

donde:

XXX identificador del proyecto

Z es un identificador del tipo de documento:
si Z = P es el plan de proyecto.
si Z = R es la especificacin de requisitos.
si Z = D es el diseo.
si Z = C es el cdigo fuente.
si Z = T es la prueba.
si Z = U es el manual de usuario.
si Z = I es la gua de instalacin.
si Z = M es el manual de mantenimiento.

V versin

F Fecha

Ejemplo: SPC-P-0-3/95
Computador de propsito especial; documento de plan de proyecto;
versin 0; pas un control de cambios en marzo de 1995


7. Manual de Usuario

I. Introduccin.
A. Panorama y exposicin del producto.
B. Terminologa y caractersticas bsicas.
C. Resumen de informes.
D. Bosquejo del manual.
II. Pasos previos.
A. Arranque.
B. Funcionamiento de la Ayuda.
C. Ejemplo de ejecucin.
III. Funcionamiento.
A. Modos de Operacin.
B. Comandos / dilogos / informes.
IV. Caractersticas especializadas.
V. Sintaxis de comandos y opciones del sistema.


Apndice V
Listas de Inspeccin

1. Revisiones

Los productos obtenidos durante la especificacin de requerimientos del software deben ser
revisados profundamente antes de seguir el proceso de desarrollo. La revisin debe realizarse
cuidadosamente por varios motivos:

- El software diseado y producido se atendr a las especificaciones contenidas en
estos documentos. La especificacin 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 especificacin se convierte en el producto de referencia para evaluar las
caractersticas del producto final. La validacin de ste se realizar en base a lo
especificado.

Durante la revisin se evalan el Documento de Especificacin de Requerimientos y el
Manual Preliminar de Usuario intentado responder a una serie de preguntas.

La revisin de la especificacin de requerimientos es una de las ms importantes de las
revisiones del ciclo de vida, por lo ya comentado. Si los productos obtenidos la pasan con
xito se iniciar el diseo del software.

En general en cada una de las fase del ciclo de vida clsica, podemos plantear una lista de
inspeccin o cuestiones a responder para comprobar que estamos realizando el trabajo de
desarrollo de una manera correcta, sin olvidarnos de ningn aspecto. A continuacin se
muestra una lista de inspeccin por fases del ciclo de vida.

2. Especificacin del Sistema

1. Se define con claridad y sin ambigedad 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. Estn disponibles los recursos?
9. Es tecnolgicamente posible abordar el proyecto?
10. Se han considerado diferentes alternativas de configuracin 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 lmites del proyecto?
15. Se ha pensado en el impacto humano del sistema?
16. Se ha documentado suficientemente esta fase?
17. Se han utilizado tcnicas de obtencin de informacin adecuadas?
18. Se ha realizado una investigacin de otros sistemas con las mismas prestaciones?
19. Se ha hecho una estimacin del tiempo necesario de desarrollo?
20. Hay una descripcin de cada funcin del sistema?
21. Se ha asignado cada funcin al elemento del sistema apropiado?
22. Ha tenido lugar una comunicacin 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 especificacin del sistema?
27. Se ha establecido un mecanismo para la verificacin y la validacin?

3. Planificacin del Proyecto

1. Se han determinado los recursos humanos, hardware y software necesarios?
2. Y los recursos disponibles?
3. Se utilizan mtricas para la estimacin de costos?
4. Se usan tales mtricas de la forma adecuada?
5. Se usa informacin histrica para las estimaciones?
6. Es razonable la estimacin de costos?
7. Es realista el presupuesto?
8. Es realista la fecha de finalizacin?
9. Se han ajustado el presupuesto y la fecha de finalizacin?
10. Se ha desarrollado una planificacin temporal?
11. Estn 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 mtodo de planificacin estandarizado?
15. Se usan diagramas que faciliten la comprensin de la planificacin?
16. Se ha documentado suficientemente esta fase?
17. Se ha elaborado y distribuido el documento de Plan de Proyecto?

4. Anlisis de requerimientos del software

1. Se utiliza algn mtodo de anlisis de los requerimientos del software?
2. El mtodo utilizado para el A.R.S. es el adecuado?
3. Se establece adecuadamente el dominio de informacin referente al flujo de
informacin, a su contenido y su estructura?
4. Se realiza la particin del problema con el suficiente nivel de detalle? Es completa?
5. Hay una correspondencia de tareas entre la particin del problema y la especificacin
del sistema?
6. Hay una divisin entre visin fsica y lgica del modelo?
7. La informacin es anidada de forma que se puede descender al nivel de detalle
deseado?
8. Se establece adecuadamente el dominio de informacin referente a la interfaz?
9. Se realiza una descripcin 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. Estn 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 informacin redundante?
17. Hay procedimientos que no realicen ninguna tarea?
18. La informacin para cada nodo es la requerida?
19. Se han nombrado todos los elementos de los diagramas?
20. Se han establecido los criterios de validacin?
21. Se ha elaborado el manual de usuario preliminar?
22. Ha tenido lugar la comunicacin con el cliente?
23. Ha dado opinin el usuario sobre el manual de usuario preliminar?
24. Se ha elaborado y distribuido el documento de especificacin 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 especificacin?
28. Es completa la especificacin?
29. Se ha pensado en el mantenimiento?
30. El documento est bien organizado?

5. Diseo

1. Ha tenido lugar una divisin entre diseo preliminar y diseo detallado?
2. El grado de cohesin es adecuado (suficientemente alto)?
3. El grado de acoplamiento es adecuado (suficientemente bajo)?
4. Se ha hecho una descomposicin modular adecuada?
5. Se explica adecuadamente la funcin de cada mdulo con alguna herramienta?
6. Se describe la interfaz de cada mdulo?
7. Se establece bien la estructura modular (presumiblemente jerrquica)?
8. Se ha realizado y distribuido el documento de Especificacin del diseo?
9. Se han establecido las estructuras de datos adecuadas al problema?
10. La descomposicin realizada y su funcionalidad se ajustan a la especificacin de los
requerimientos del software?
11. Se contemplan todas las funciones?
12. Estn adecuadamente separadas las representaciones de datos y procedimientos?
13. Se corresponden los algoritmos de diseo detallado con la estructura dada en el
diseo preliminar?
14. Se ha especificado el tratamiento de errores?
15. Es adecuado el nivel de detalle del algoritmo con el lenguaje destino de la
implementacin?
16. Se ha tenido en cuenta la facilidad de mantenimiento?
17. La funcionalidad del algoritmo es la adecuada?
18. Ha tenido lugar una revisin de la planificacin?
19. Se han nombrado los componentes de los diagramas adecuadamente?
20. Hay un diccionario de datos del diseo?
21. Se han descrito las bases de datos?
22. Faltan/sobran elementos de la especificacin 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?

6. Codificacin

1. Se ha elegido el lenguaje adecuado para la implementacin?
2. Se aprovechan los recursos del lenguaje de programacin?
3. Se considera la portabilidad del cdigo?
4. Se dispone de las herramientas adecuadas para el desarrollo?
5. Se ha considerado la facilidad de mantenimiento?
6. Se ha elegido adecuadamente los nombres de los identificadores?
7. Se utilizan comentarios que aclaren la estructura del cdigo y de los datos?
8. Se hace una descripcin de la interfaz de cada mdulo?
9. Existen comentarios de prlogo?
10. Es el cdigo legible?Con la identacin adecuada?Buen estilo de codificacin?
11. Es comprensible el cdigo?
12. Se utilizan caractersticas estndar en la implementacin?
13. Se produce una validacin de datos adecuada?
14. Es el programa robusto?
15. Hay un tratamiento de errores adecuado?
16. Es el cdigo eficiente?
17. Se utiliza adecuadamente el espacio en memoria?
18. Se usan suficientemente los dispositivos de E/S?
19. Se corresponde el cdigo con el diseo?
20. Se ha revisado la planificacin?

7. Prueba

1. Ha tenido lugar un diseo de casos de prueba de unidad para cada mdulo?
2. Es completo el conjunto de caminos independientes de prueba?
3. Se han probado todos?
4. Se han diseado pruebas de bucles?
5. Se ha diseado un procedimiento de prueba de integracin?
6. Se ha especificado un conjunto de casos de prueba para la integracin?
7. Se ha diseado la prueba de validacin?
8. Se ha diseado la prueba del sistema?
9. Se ha diseado la prueba de recuperacin?
10. Se ha diseado la prueba de seguridad?
11. Se ha diseado la prueba de resistencia?
12. Se ha diseado la prueba de rendimiento?


Apndice VI
Glosario de Trminos

1. Los Sistemas de Informacin

Sistema

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 interacta.

Informacin

La informacin est construida a partir de un conjunto de datos que mantienen una
estructura y que adems resulten tiles o significativos. Darse cuenta de que es mejor
calidad de la informacin que cantidad.

Calidad de la informacin

Grado de adecuacin de la informacin a nuestro sistema evitando ambigedades.
Conjunto de cualidades que adems de la capacidad de disminuir la incertidumbre,
ayudan al receptor a tomar la decisin ms ventajosa.

Sistema de informacin

Conjunto formal de procesos que, operando sobre una coleccin de datos estructurada
segn las necesidades de la empresa, recopilan, elaboran y distribuyen la informacin
necesaria para las operaciones de dicha empresa y para las actividades de direccin y
control correspondientes, es decir, las decisiones, para desempear su actividad de
acuerdo a su estrategia de negocio.

Flujo de informacin

Caudal de informacin que se transmite de un lugar a otro. Hay dos tipos, vertical y
horizontal.

Dato

Registro de hechos, acontecimientos, transacciones, etc. Materia prima con la que
construimos la informacin.

Automatizacin de un sistema de informacin

Eleccin de hardware, configuracin adecuada de software de base y aplicaciones que
permitan cubrir las necesidades de informacin que marcan la estructura del Sistema de
Informacin.

2. Ingeniera de Sistemas

Ingeniera de sistemas basados en computadora

Es un tipo de ingeniera que no se concentra nicamente en el software, sino que se
concentra en una variedad de elementos, analizando, diseando y organizando esos
elementos en un sistema que pueden ser un producto, un servicio o una tecnologa para la
transformacin de informacin o control de informacin.

Ingeniera de la informacin

Es el proceso de ingeniera del software cuando el contexto del trabajo de ingeniera se
enfoca a una empresa; esta ingeniera trabaja para asignar un papel al software de
computadora y para establecer los enlaces que unen al software con un servicio
determinado.

Ingeniera de producto

Es el proceso de ingeniera del software cuando hay que construir un producto; esta
ingeniera 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

Conjunto de elementos que estn organizados para realizar un objetivo predefinido
procesando informacin, como puede ser:

Soportar alguna funcin 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, documentacin y procedimientos.

La jerarqua de la ingeniera de SBC

La jerarqua de sistemas de computadora comprende una coleccin de mtodos para
navegar de arriba abajo y de abajo arriba en la jerarqua. El proceso de la ingeniera de
sistemas de computadora empieza normalmente con una vista global. Es decir, se
examina el dominio entero de negocio o tecnolgico apropiado. La visin global se refina
para enfocarse totalmente en un dominio de inters especfico. Dentro de un dominio

especfico, se analiza la necesidad de elementos del sistema (p. e.: informacin, software,
hardware, personas). Finalmente se inicia el anlisis, diseo y construccin del elemento
del sistema deseado. En la parte alta de la jerarqua se establece un contexto muy amplio y
en la parte baja se llevan a cabo actividades tcnicas detalladas, realizadas por la
disciplina de ingeniera correspondiente(p. e.: ingeniera hardware o software).

Ingeniera de la informacin

Persigue definir arquitecturas que permitan a las empresas emplear la informacin
eficazmente. Se deben analizar y disear tres arquitecturas diferentes dentro del contexto
de objetivos y metas de negocio:

Arquitectura de datos: proporciona una estructura para las necesidades de
informacin de un negocio o de una funcin de negocio.

Arquitectura de aplicaciones: comprende aquellos elementos de un sistema que
transforman objetos dentro de la arquitectura de datos por algn propsito del
negocio.

Infraestructura de la tecnologa: 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, tecnologas de
almacenamiento y la arquitectura diseada para implementar esta tecnologa.

Ingeniera 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 tecnologa
requerida para unir los componentes y la informacin (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 informacin y aplicaciones
informticas.

Planificacin de sistemas

El mbito de la planificacin de sistemas puede ser toda la empresa, una divisin de la
misma o cualquier otro tipo de sus unidades organizativas. Su propsito es identificar y
establecer las prioridades sobre aquellas aplicaciones de los sistemas de informacin cuyo

desarrollo reporte mximos beneficios para la empresa considerada en su conjunto. Esta
fase indica la relativa madurez del funcionamiento de los sistemas de informacin.

Analistas de planificacin

Profesionales dotados de una formacin especial, que deben pensar en la empresa incluso
ms que los analistas de sistemas normales. Han de conocer la metodologa de
planificacin que debe usarse y los resultados que van a obtenerse. Se requiere que
dispongan de una combinacin muy especial de habilidades y experiencias, entre las que
se incluyen la gestin de empresas, el anlisis y diseo de sistemas, la gestin de datos y
el diseo de redes.

Estudio del cometido de la empresa

Consiste en estudiar la misin de la empresa. Idealmente, el mbito de la fase de
planificacin debera ser toda la empresa, pero este mbito debe reducirse a un nivel
manejable.

Arquitectura de informacin

Plan de seleccin de la tecnologa de informacin y el desarrollo de los sistemas de
informacin necesarios para apoyar el cometido de la empresa.

Anlisis de reas de empresa

Consiste en evaluar las reas de empresa que han de identificarse y establecer prioridades
sobre proyectos de desarrollo especficos.

Anlisis del sistema

Es un procedimiento necesario para el desarrollo del producto en la ingeniera del
producto que proporciona una visin 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 anlisis
tcnico y econmico; asignar funciones al hardware, software, personal, B.D. y otros
elementos del sistema; establecer las restricciones de presupuesto y planificacin
temporal y crear una definicin de sistema que forme el fundamento de todo el trabajo de
ingeniera subsiguiente.

Identificacin de necesidades del cliente

En esta etapa el analista se rene con el cliente y el usuario final (si es otro distinto al
cliente) con la intencin de definir los objetivos del producto y definir las metas
necesarias para alcanzar esos objetivos. Una vez identificadas las metas globales, el
analista evala la informacin suplementaria como puede ser la existencia de tecnologa

para construir el sistema, que recursos especiales de desarrollo y fabricacin sern
necesarios..... En el caso de que el nuevo sistema sea un producto a vender a muchos
clientes, se plantean adems otras cuestiones como: Cul es el mercado potencial del
producto?, cmo es comparativamente este producto con los de la competencia?, qu
posicin ocupa este producto en la lnea general de produccin de la compaa?.

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 difciles.
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 econmica, la viabilidad
tcnica 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 direccin.

Anlisis econmico

Determina los costes para el desarrollo del proyecto y los pondera con los beneficios
tangibles e intangibles del sistema.

Anlisis tcnico

Durante este el analista evala los principios tcnicos del sistema al mismo tiempo que
recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de
mantenimiento y productividad. Este etapa comienza con una viabilidad tcnica del
sistema.

Modelizacin

Consiste en elaborar una o ms representaciones grficas 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.

Diseo 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.

Especificacin del sistema

La especificacin del sistema es un documento que sirve como fundamento para la
ingeniera hardware, software, de bases de datos y humana. Describe la funcin y el
rendimiento de un sistema basado en computadora y las restricciones que gobernarn su
desarrollo.

Diseo de sistemas

El dominio que cubre el diseo de sistemas sigue siendo la aplicacin de sistemas de
informacin nica de que hablbamos en el anlisis de sistemas. Su propsito es disear
una solucin tcnica, de tipo informtico, que satisfaga las necesidades de empresa segn
han sido especificadas durante el anlisis de sistemas.

Implantacin de sistemas

El dominio que cubre la implantacin de sistemas est definido por los componentes de
tipo tecnolgico de la aplicacin de sistemas de informacin que se disearon en la fase
anterior. Su propsito es construir y/o ensamblar los componentes tcnicos y poner en
funcionamiento el sistema de informacin nuevo o mejorado.

Pruebas de unidad

Aseguran que los programas de aplicacin funcionen de forma adecuada cuando se
prueban de forma aislada con respecto a otros programas de aplicacin.

Pruebas de sistema

Aseguran que los programas de aplicacin 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 informacin puesto en
produccin mediante la implantacin de sistemas. El propsito del soporte de sistemas es
sostener y mantener el sistema durante el resto de su vida til.

Ingeniera de los componentes

Es un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de
los componentes del sistema: la ingeniera del software, ingeniera hardware, ingeniera
humana e ingeniera de bases de datos. Cada una de estas disciplinas de ingeniera tomo
una vista de dominio especfica, pero es importante resaltar que las disciplinas de
ingeniera deben establecer y mantener una comunicacin activa entre ellas. Parte del
papel del anlisis de sistemas es establecer los mecanismos de interfaz que permitirn que
esto suceda.

Software

Programas, estructuras de datos y documentacin que hacen efectivo el mtodo lgico,
procedimiento o control requerido.


Hardware

Dispositivos electrnicos que proporcionan capacidad de clculo y dispositivos
electromecnicos (por ejemplo sensores, motores y bombas) que proporcionan una
funcin externa.

Bases de Datos

Coleccin de informacin organizada a la que se accede a travs del software.

Documentacin

Manuales, formularios e informacin descriptiva del empleo y operacin del sistema.

Actividades cruzadas del ciclo de vida

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.

Investigacin de hechos

Es el proceso formal que emplea encuestas, entrevistas, reuniones, cuestionarios,
muestreos y otras tcnicas para recoger la informacin de los sistemas, las necesidades y
las preferencias.

Estimacin

Actividad encargada de calcular el tiempo, el esfuerzo, los costes y las ventajas del
desarrollo de un sistema.

Medida

Actividad consistente en medir y analizar la productividad y la calidad (y a veces los
costes) de las personas que desarrollan el sistema.

Gestin de proyectos

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.

Gestin de procesos

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

3. La Ingeniera del Software

Software

Llamamos software al conjunto de programas, estructuras de datos (que permiten a los
programas manipular adecuadamente la informacin) y documentos (que describen la
operacin y el uso de programas).

Software de sistemas

Conjunto de programas que han sido escritos para servir a otros programas (compiladores,
editores, ...)

Software de gestin

Es el software en sistemas de informacin de gestin (SIG) que acceden a una o ms
bases de datos grandes que contienen informacin comercial (por ejemplo,
procesamiento de transacciones en puntos de venta).

Software de ingeniera y cientfico

Es el que utiliza algoritmos complejos de tratamientos numricos. Otros: CAD,
simulacin de sistemas, astronoma, biologa molecular, ...

Software empotrado

Es el que reside en memoria de slo lectura y se utiliza para controlar productos y
sistemas de mercados industriales y de consumo.

Software de computadores personales

Es el software ms comn utilizado en los ordenadores personales (procesamiento de
texto, hojas de clculo, entretenimiento, ...)

Software de Inteligencia Artificial

Est basado en el uso de algoritmos no numricos para resolver problemas complejos para
los que no son adecuados el clculo o el anlisis directo.

Software de tiempo real

Mide, analiza y controla sucesos del mundo real conforme ocurren (por ejemplo:
componentes de adquisicin de datos).


Ingeniera del software

Disciplina tecnolgica y administrativa dedicada a la produccin sistemtica de productos
de programacin, que son desarrollados y modificados a tiempo, y dentro de un
presupuesto definido. Es el establecimiento y uso de principios de ingeniera robustos,
orientados a obtener econmicamente software que sea fiable y que funcione
efectivamente sobre mquinas reales.

Paradigma de la I.S.

Es un modelo para el proceso de desarrollo del software. Acompaa al proceso, mtodos,
herramientas y fases para resolver un problema real.

Paradigma del prototipo

Es un proceso que facilita la creacin de un modelo del producto a construir.

Ciclo de vida clsico

Modelo estructurado en etapas que define los pasos que se han de seguir para la
realizacin de un proyecto

Tcnicas de cuarta generacin

Son una serie de herramientas de software que facilitan la especificacin. Se orienta hacia
la posibilidad de especificar el software usando formas de lenguaje especializado o
notaciones grficas que describan el problema que hay que resolver en trminos que los
entienda el cliente. Estas generan el cdigo fuente de forma automtica.

Mtodo

Elemento de la I.S. que suministra informacin para conocer como construir el software.
Abarcan actividades de planificacin, anlisis, diseo, etc.

Herramienta

Componente de la I.S. que sirve de soporte al proceso de produccin, proporcionando
elementos para la ejecucin de los mtodos.

Procedimiento

Nexo de unin entre los mtodos y las herramientas. Definen la secuencia en la que se
deben aplicar los mtodos, la informacin 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 guas para establecer su desarrollo.

4. Conceptos sobre gestin de proyectos

Modelo de madurez de la capacidad

Es un modelo desarrollado por el Instituto de Ingeniera del Software, para mejorar en las
organizaciones su capacidad de desarrollo de software.

Objetivos

Identifican las metas generales del proyecto sin considerar cmo se conseguirn.

mbito

Identifica los datos primarios, funciones y comportamientos que caracterizan el problema
e intenta abordar estas caractersticas de una manera cuantitativa.

Soluciones alternativas

Una vez identificados los objetivos y el mbito, se consideran las soluciones alternativas
que permiten a los gestores y a los profesionales seleccionar el mejor enfoque, teniendo
en cuenta todos los factores.

Tareas estructurales

Son las que se pueden aplicar a todos los proyectos de software, sin tener en cuenta su
tamao o complejidad.

Conjunto de tareas

Tareas, hitos, entregas, etc., que permiten a las actividades estructurales adaptarse a las
caractersticas del proyecto.

Actividades protectoras

Tales como garanta de calidad del software, gestin de la configuracin del software y
medicin, cubren el modelo de proceso. Son independientes de las estructurales y tienen
lugar a lo largo del proceso.

Gestores superiores

Definen los aspectos de negocios que a menudo tienen una significativa influencia en el
proyecto.

Gestores tcnicos del proyecto

Deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo
de software.

Profesionales

Proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o
aplicacin.

Clientes

Especifican los requisitos para la ingeniera del software.

Usuarios finales

Interaccionan con el software una vez que se ha entregado para la produccin.

Equipo Descentralizado democrtico (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 comunicacin es horizontal entre los miembros del
equipo.

Equipo Descentralizado concentrado (DC)

Equipo de ingeniera del software que tiene un jefe definido que coordina tareas
especficas y jefes secundarios que tienen responsabilidades sobre subtareas. La
resolucin de problemas sigue siendo una actividad del grupo, pero la implementacin de
soluciones se reparte entre subgrupos por el jefe de equipo. La comunicacin entre
subgrupos e individuos es horizontal. Tambin hay comunicacin vertical a lo largo de la
jerarqua de control.

Equipo Centralizado controlado (CC)

Hay un jefe del equipo que soluciona los problemas a alto nivel y que se encarga de la
coordinacin interna del equipo, la comunicacin es vertical.

Paradigma cerrado

Paradigma de organizacin de ingeniera del software que estructura a un equipo con una
jerarqua 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 organizacin de ingeniera del software que estructura al equipo libremente
y depende de la iniciativa individual de los miembros del equipo. Cuando se requiere
innovacin o avances tecnolgicos, son excelentes. Pueden chocar cuando se requiere un
rendimiento ordenado.


Paradigma abierto

Paradigma de organizacin de ingeniera del software que intenta estructurar a un equipo
de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero
tambin mucha de la innovacin asociada al paradigma aleatorio. El trabajo se desarrolla
en colaboracin, con mucha comunicacin y toma de decisiones consensuadas. Es
adecuado para la resolucin de problemas complejos, pero su rendimiento puede ser
menos eficiente.

Paradigma sincronizado

Paradigma de organizacin de ingeniera del software que se basa en la divisin natural de
un problema. Organiza los miembros del equipo para trabajar en partes del problema con
poca comunicacin activa entre ellos.

mbito del problema

Es la primera actividad de gestin de un proyecto de software, y se define estableciendo el
contexto, los objetivos de informacin y la funcin y rendimiento.

Descomposicin del problema

Es una actividad que trata de dividir el problema para solucionarlo mejor (divide y
vencers). Esta descomposicin del problema se hace en dos reas principales:
funcionalidad a entregar y proceso para entregar el producto.

Maduracin del problema y el proceso

Se trata de seleccionar el conjunto de actividades estructurales adecuado como por
ejemplo: comunicacin con el cliente, planificacin, anlisis de riesgo, ingeniera,
construccin y entrega, evaluacin del cliente.

Modelo de madurez de la capacidad de gestin de personal

Para aumentar la preparacin de organizaciones de software para llevar a cabo las cada
vez ms 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 bsicas por las que deben pasar todas las funciones que se deben
tratar dentro de un proceso de ingeniera por el equipo de software.


5. Planificacin de proyectos software y gestin del riesgo

Planificacin del proyecto

Conjunto de actividades que conjuntamente forman el proceso de gestin del proyecto
software.

mbito del software

Describe la funcin, rendimiento, las restricciones, las interfaces y la fiabilidad que deben
conseguir el software a desarrollar.

Riesgos del software

El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas
establecidas por recursos, coste y planificacin temporal.

Riesgos tcnicos

Son aquellos que amenazan la calidad y la planificacin temporal del software. Identifican
problemas potenciales de: diseo, implementacin, interfaz, verificacin y
mantenimiento.

Riesgo de negocio

Amenazan la viabilidad del software a construir. A menudo ponen en peligro el proyecto
o el producto.

Identificacin del riesgo

Es un intento sistemtico para especificar las amenazas al plan de proyecto (estimaciones,
planificacin temporal, carga de recursos, etc.)

Riesgo de mercado

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

Riesgo estratgico

Construir un producto que no encaja en la estrategia comercial general de la compaa.

Riesgo de direccin

Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de
personal.


Riesgos de presupuesto

Perder presupuesto o personal asignado.

Estrategia de riesgo reactiva

El equipo no hace nada respecto a los riesgos hasta que algo va mal. Despus el equipo,
apresuradamente trata de corregir el problema.

Estrategia de riesgo proactiva

Se identifican los riesgos potenciales, se valora su probabilidad y se establece una
prioridad segn su importancia. Despus el equipo de desarrollo establece un plan para
controlar el riesgo.

Anlisis de riesgo

Es una actividad de garanta de calidad del software que se centra en la identificacin y
evolucin de los riesgos potenciales que puedan producir un impacto negativo en el
software y hacer que falle el sistema completo. Si se pueden identificar pronto los riesgos
en el proceso de ingeniera del software podrn especificarse las caractersticas de diseo
del software que permitan eliminar o controlar los riesgos potenciales.

Riesgos genricos

Son una amenaza potencial para todos los proyectos de software.

Riesgos especficos de producto

Slo pueden identificarse una vez que se tiene una visin clara de la tecnologa, personal
y entorno especfico del proyecto en cuestin.

6. Estimacin de costes y plazos

Estimacin de costes y plazos

Consiste en la prediccin del coste de un proyecto, as como prever su plazo de
realizacin.

Estimacin de expertos

Basndose en la experiencia, averiguar cual va a ser el coste del proyecto. Una de las ms
utilizadas es la tcnica Delphi.

Estimacin por analoga

En funcin de las similitudes y diferencias con otros proyectos vamos a deducir el coste
de un desarrollo nuevo.

Estimacin por descomposicin

Se descompone el producto en sus componentes o incluso el proyecto en tareas ms
sencillas hasta conseguir un nivel de detalle en el que podemos estimar directamente el
coste de cada una de las subpartes.

Estimacin por ecuaciones o modelos de estimacin

Frmulas matemticas que nos van a relacionar diversos parmetros 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 duracin. La mayora son modelos
de factores empricos que cuentan con una parte principal (habitualmente una media del
tamao del producto) y un cierto nmero de factores de ajuste. P.e. el modelo COCOMO.

Modelos de restricciones

Muestran las relaciones en el tiempo entre dos o ms parmetros de coste (p.e. esfuerzo,
duracin 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 tamao del producto para realizar sus estimaciones. Dando lugar a
tres tipos de submodelos: el bsico, el intermedio y el detallado.


Atributo

Cada una de las caractersticas que definen el modelo y que estarn ponderadas, esto es,
afectarn a los resultados en ms o menos medida, segn el modelo.

Proyecto Orgnico

Tipo de desarrollo del modelo COCOMO en el que hay pequeos equipos de trabajo que
trabajan en un entorno familiar, desarrollando aplicaciones que ya haban hecho antes. La
comunicacin es escasa e informal.

Proyecto Semiseparado

Tipo de desarrollo del modelo COCOMO en el que podemos tener personal con o sin
experiencia, en general los miembros del equipo van a tener una experiencia limitada
relacionada con los sistemas y pueden ser extraos a algunos de los aspectos, no todos,
del sistema que se va a desarrollar.

Proyecto empotrado

Tipo de desarrollo del modelo COCOMO en el que se 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 aplicacin particular que se desarrolla.

7. Planificacin temporal y seguimiento del proyecto

Planificacin temporal

Es una actividad que distribuye el esfuerzo estimado de realizacin de un proyecto a lo
largo de la duracin de ste asignando el esfuerzo a las tareas de ingeniera del software,
esto es, consiste en planear cuando y como acometer las tareas de un proyecto, haciendo a
su vez una asignacin de recursos adecuada para cumplir los objetivos

Particin

Es la divisin del proyecto en un nmero de actividades y tareas manejables,
descomponindose tanto el producta como el proceso.

Asignacin de tiempos

Consiste en asignar a cada tarea un cierto nmero de actividades y tareas manejables,
descomponindose tanto el producto como el proceso.

Red de tareas

Es una representacin grfica del flujo tareas de un proyecto, mostrando en su manera
ms simple las principales tareas principales de ingeniera del software

Camino crtico

Son el flujo o cadena de tareas que deben finalizarse segn la planificacin temporal si se
quiere que el proyecto en general se termine a tiempo y que por tanto determine la
duracin del proyecto.

Grfico Gantt

Es un grfico de tiempos donde las tareas se colocan en una columna a la izquierda y se
indica la duracin de cada tarea mediante barras horizontales.

Plan de proyecto

Es un documento que se produce a la culminacin de las tareas de planificacin temporal
que proporcionando informacin bsica de coste y planificacin temporal que ser
empleada a lo largo del proceso de ingeniera del software.

PERT

Tcnica de evaluacin y revisin de programas. Es una herramienta cuantitativa que
permite al planificador de software determinar el camino crtico, establecer las

dimensiones de tiempo ms probables para las tareas individuales aplicando modelos
estadsticos y calcular las limitaciones de tiempo del proyecto.

Distribucin de esfuerzo

Consiste en la asignacin, de forma relativa, de los recursos y tiempo a las distintas fases
del proyecto.

Conjunto de tareas

Coleccin de actividades, cuya misin es la de satisfacer las necesidades de los distintos
tipos de proyectos. Han de ser lo ms acertadas posible (cumplir su papel de la forma ms
brillante) y as alcanzar una calidad alta.

Hito

Punto en el tiempo en el que comprobamos si estamos cumpliendo con ciertos objetivos.

8. Tcnicas de planificacin temporal

Diagrama de hitos

El diagrama de hitos es el mtodo ms 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 finalizacin.

Diagrama de Gantt

El diagrama de Gantt es un diagrama de columnas en forma de barras donde se hace una
referencia cruzada entre las tareas (filas) y los tiempos de duracin de cada una de ellas
(columnas). El diagrama de Gantt se puede utilizar para estimar los recursos y el
presupuesto en funcin del tiempo.

Red de precedencia

La red es un modelo grfico que seala las relaciones secuenciales entre los sucesos clave
de un proyecto.

Actividad ficticia

Consiste en aadir una actividad de duracin cero en una red de precedencia en la que no
se cumplen las relaciones de precedencia lineales. Es un pequeo truco para poder realizar
correctamente procesos lineales convergentes.

Holgura de una actividad

Representa el nmero de unidades de tiempo que puede atrasarse la realizacin de la
actividad con respecto al tiempo PERT previsto, sin que aumente la duracin del
proyecto.

Tcnica PERT

La tcnica es un procedimiento que sirve de ayuda en proyectos complejos y que
requieren una cuidadosa planificacin, programacin y coordinacin de diferentes
actividades interrelacionadas.

Matriz de encaminamientos

La matriz de encaminamientos es una matriz cuya dimensin coincide con el nmero 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.


Tiempo pesimista

Representa el tiempo mximo en que podra finalizarse la actividad si se dan todas las
circunstancias negativas que podran darse durante su ejecucin.

Tiempo ms probable

Representa el tiempo normal de la duracin de la actividad suponiendo que hay problemas
en las actividades, pero no aparecen en su totalidad.

Tiempo optimista

Representa el tiempo mnimo si no aparece ningn problema durante la realizacin de la
actividad.

Tiempo ms prximo

Es el tiempo estimado en que ocurrir un suceso si las actividades que lo preceden
comienzan lo ms pronto posible.

Tiempo ms lejano

Es el ltimo momento estimado en que puede ocurrir un suceso sin retrasar la finalizacin
del proyecto ms all de su tiempo prximo.

Holgura de un suceso

Es la diferencia entre su tiempo ms lejano y su tiempo ms prximo.

9. Control de calidad del software y gestin de la
configuracin

Garanta de calidad del software:

La garanta de calidad del software es una actividad de proteccin que se aplica a lo largo
de todo el proceso de la Ingeniera del Software.

Calidad

Conjunto de caractersticas de un producto, proceso o servicio que le confieren su aptitud
para satisfacer las necesidades del usuario.

Calidad del diseo

Se refiere a las caractersticas que especifican los ingenieros del software para un
producto.

Calidad de concordancia

Es el grado de cumplimiento de las especificaciones de diseo durante su realizacin.
Cuanto mayor sea el grado de cumplimiento, ms alto ser el nivel de calidad de
concordancia.

Calidad del software

Concordancia con los requisitos funcionales y de rendimiento explcitamente definidos,
con los estndares de desarrollo explcitamente documentados y con las caractersticas
implcitas que de todo software desarrollado profesionalmente se espera.

Control de calidad

Conjunto 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.

Revisiones del software

Una revisin es una forma de aprovechar la diversidad de un grupo de personas para:
Sealar la necesidad de mejoras en el producto, personas o equipos.
Confirmar las partes del producto en las que no es necesaria una revisin.
Conseguir un producto de una calidad ms uniforme.


Revisin tcnica formal

Una revisin tcnica formal es una actividad de la garanta de calidad de del software que
es llevada a cabo por los ingenieros del software. Pretende descubrir errores, verificar que
el software alcanza sus requisitos, que sigue unos estndares, que sea uniforme y controlar
para que los proyectos sean ms manejables.

Sistema de garanta de calidad

Un sistema de garanta de la calidad se puede definir como la estructura organizativa,
responsabilidades, procedimientos, procesos y recursos para implementar gestin de la
calidad.

Sistema de garanta de calidad ISO-9000

ISO-9000 describe los elementos de garanta de calidad en trminos genricos que pueden
aplicarse a cualquier negocio con independencia de los productos o servicios ofrecidos.

Sistema de garanta de calidad ISO-9001

Es el estndar de garanta de calidad que se aplica a la ingeniera del software. El estndar
contiene 20 requisitos que deben estar presentes en un sistema de garanta de calidad
efectiva.

Gestin de la configuracin del software

La gestin de configuracin del software es una actividad de autoproteccin que se aplica
a lo largo del proceso de la ingeniera del software, cuya misin es identificar y controlar
el cambio, de garantizar que el cambio se implemente adecuadamente y de informar del
cambio a todos aquellos a los que le interese.

Configuracin del software

Se llama as a todos los elementos que componen toda la informacin producida como
parte del proceso de ingeniera del software.

10. Introduccin a los Sistemas de Gestin de Bases de
Datos

Sistema de gestin de bases de datos (SGBD)

Coleccin de datos interrelacionados y un conjunto de programas para acceder y
manipular dichos datos.

Redundancia de datos

Cuando una misma informacin est duplicada en diferente lugar.

Inconsistencia de datos

Cuando los datos redundantes no coinciden en su valor.

Aislamiento de datos

Datos dispersos en varios archivos, incluso con distintos formatos.

Ligadura de consistencia

Restriccin que se le impone a los datos.

Integridad de datos

Cuando los datos no cumplen alguna de las ligaduras de consistencia.

Atomicidad

Propiedad que nos dice que una operacin debe realizarse ntegramente o no realizarse.
No permite estados intermedios.

Acceso concurrente a datos

Cuando varias aplicaciones pueden acceder simultneamente a los datos.

Nivel fsico de abstraccin de datos

Es el nivel ms bajo de abstraccin y describe cmo se almacenan realmente los datos. En
el nivel fsico se describen en detalle las estructuras de datos complejas de bajo nivel.

Nivel lgico de abstraccin de datos

Es el segundo nivel ms alto de abstraccin y describe qu datos se almacenan en la base
de datos y qu relaciones existen entre esos datos.

Nivel de abstraccin de datos de vistas

Es el nivel ms alto de abstraccin y describe slo parte de la base de datos completa. A
pesar del uso de estructuras ms simples en el nivel lgico, queda algo de complejidad,
debido al gran tamao de la base de datos. Para que la interaccin con el sistema se
simplifique, se define la abstraccin del nivel de vistas. El sistema puede proporcionar
nuevas vistas para la misma base de datos.

Instancia de una base de datos

Coleccin de informacin almacenada en la base de datos en un momento particular.

Esquema de la base de datos

Diseo completo de la base de datos. Los sistemas de bases de datos tienen varios
esquemas divididos, de acuerdo a los niveles de abstraccin que se han visto. En el nivel
ms bajo est el esquema fsico; en el nivel intermedio est el esquema lgico, y en el
nivel ms alto est el subesquema.

Independencia de datos

Es la capacidad para modificar una definicin de esquema en un nivel sin que afecte a una
definicin de esquema en el siguiente nivel superior.

Independencia fsica de datos

Es la capacidad para modificar el esquema fsico sin provocar que los programas de
aplicacin tengan que reescribirse.

Independencia lgica de datos

Es la capacidad para modificar el esquema lgico sin causar que los programas de
aplicacin tengan que reescribirse.

Modelo de datos

Coleccin de herramientas conceptuales para describir los datos, las relaciones de datos,
la semntica de los datos y las ligaduras de consistencia.

Modelos lgicos basados en objetos

Se usan para describir datos en los niveles lgico y de vistas. Se caracterizan por el hecho
de que proporcionan capacidades estructurales muy flexibles y permiten que las ligaduras
de datos sean especificadas explcitamente.


Modelo de datos entidad-relacin (E-R)

Est basado en una percepcin del mundo real que consta de una coleccin de objetos
bsicos, llamados entidades, y de relaciones entre estos objetos.

Entidad

Objeto del mundo real que es distinguible de otros objetos. Las entidades se describen en
una base de datos mediante un conjunto de atributos.

Relacin

Asociacin entre varias entidades.

Diagrama entidad-relacin

Diagrama grfico que se utiliza para expresar la totalidad de estructuras lgicas de una
base de datos.

Modelo orientado a objetos

Est basado en una coleccin de objetos. Un objeto contiene valores almacenados en
variables de instancia dentro de ese objeto. Un objeto tambin contiene fragmentos de
cdigo que operan en el objeto. Estos fragmentos de cdigo se llaman mtodos. Los
objetos que contienen los mismos tipos de valores y los mismos mtodos se agrupan
juntos en clases.

Modelo basado en registros

La base de datos se estructura en registros de formato fijo de diferentes tipos. En cada tipo
de registro se define un nmero fijo de campos o atributos, y cada campo tiene
normalmente una longitud fija.

Modelo relacional

Usa una coleccin 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.

Modelo de red

Los datos se representan mediante colecciones de registros y las 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.


Modelo jerrquico

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.

Lenguaje de definicin de Datos (LDD)

Lenguaje utilizado para definir el esquema de una base de datos.

Diccionario de datos

Archivo que contiene metadatos, es decir, datos acerca de los datos.

Lenguaje de manipulacin de datos (LMD)

Lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante
el modelo de datos apropiado

LMD procedimientales

Requieren que el usuario especifique qu datos se necesitan y cmo obtener esos datos.

LMD no procedimientales

Requieren que el usuario especifique qu datos se necesitan, sin especificar cmo obtener
esos datos.

Consulta

Instruccin de solicitud para recuperar informacin.

Lenguaje de consultas

Parte de un LMD para la recuperacin de informacin.

Transaccin

Coleccin de operaciones que se lleva a cabo como una funcin lgica simple en una
aplicacin de bases de datos. Cada transaccin es una unidad de atomicidad y
consistencia.


Administrador de la base de datos

Persona que se encarga del control centralizado de los datos y de los programas que
acceden a los datos.

Programador de aplicaciones

Son profesionales informticos que interactan con el sistema a travs de llamadas al
LMD, que estn incluidas en un programa escrito en un lenguaje anfitrin. Estos
programas comnmente se llaman programas de aplicacin.

Usuarios sofisticados

Interactan 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 estn los sistemas de diseo asistido por computadora, sistemas de bases de
conocimientos y expertos.

Usuarios normales

Son usuarios no sofisticados que interactan con el sistema mediante la invocacin de
alguno de los programas de aplicacin permanentes que se han escrito previamente.

11. Sistemas de Bases de Datos en las organizaciones

Compartir datos entre unidades funcionales

Cuando personas en reas funcionales diferentes comparten un grupo comn de datos,
cada cual para sus propias aplicaciones.

Sinergia de datos

Los datos combinados tien ms valor que la suma de los datos en archivos por separado.

Base de datos centralizada

Bases de datos que est fsicamente situada en un nico lugar, controlado por una sola
computadora.

Sistema de base de datos distribuida

Est compuesto de varios sistemas de bases de datos operando en los sitios locales y
conectados por lneas de comunicacin. Hacen posible la ubicacin local de los datos, es
decir, los datos residen en los lugares donde se necesitan con mayor frecuencia.

Planificacin de la base de datos

Esfuerzo colectivo estratgico para determinar las necesidades de la organizacin para un
extenso perodo de tiempo en el futuro.

Ciclo de vida del desarrollo de base de datos

Incluye:
Informacin recolectada para determinar las necesidades de los usuarios.
El diseo del esquema de la base de datos (estructura lgica) para satisfacer esas
necesidades.
La seleccin de un SGBD para dar soporte al uso de la base de datos.
El desarrollo de programas para utilizar la base de datos.
Una revisin de las necesidades de informacin de los usuarios en el contexto de la
base de datos desarrollada.

12. Comunicacin de datos y redes de ordenadores

Red de computadoras

Coleccin interconectada de computadoras autnomas

Sistema distribuido

La diferencia con una red de computadoras consiste en que la existencia de mltiples
computadoras autnomas es transparente al usuario. Es un sistema software construido
sobre una red.

Fuente

Dispositivo que genera los datos a transmitir.

Transmisor

Elemento que transforma y codifica la informacin produciendo seales
electromagnticas susceptibles de ser transmitidas a travs de algn sistema de
transmisin.

Sistema de transmisin

Medio por el que se transmite la informacin entre transmisor y receptor.

Receptor

Elemento que acepta la seal que proviene del sistema de transmisin y la convierte de
manera que pueda ser entendida y manejada por el dispositivo destino.

Destino

Dispositivo que recibe los datos del receptor.

Sincronizacin

Se produce entre receptor y emisor. El receptor debe ser capaz de determinar cuando
comienza y cuando acaba la seal recibida, as como la duracin de cada elemento de la
seal.

Gestin de intercambio

Cooperacin entre dispositivos. Convenciones en la comunicacin.


Deteccin y correccin de errores

Capacidad en un sistema de comunicacin para detectar y posiblemente corregir los
errores producidos en la transmisin de un mensaje.

Control de flujo

Procedimientos que evitan la saturacin del destino ante gran cantidad de informacin
recibida.

Direccionamiento

Mtodo para indicar el destinatario de un mensaje. El sistema de transmisin debe
garantizar que ese y slo ese destino reciba el mensaje.

Encaminamiento

El sistema de transmisin se encargar de elegir una de las posibles rutas para enviar el
mensaje a su destino.

Recuperacin

Propiedad del sistema que permite volver a un estado anterior estable ante un fallo en la
transmisin de un mensaje.

Formato de mensajes

Conformidad entre fuente y destino en cuanto al formato de los datos intercambiados.

Seguridad

El receptor debe asegurarse que slo el destino reciba los datos. El destino debe
asegurarse a su vez que los datos proceden del receptor.

Escalabilidad

Capacidad para incrementar el rendimiento del sistema gradualmente cuando la carga de
trabajo crece, aadiendo ms procesadores.

Red de rea local (LAN)

Redes de propiedad privada dentro de un solo edificio o campus de hasta unos cuantos
kilmetros de extensin. Se usan ampliamente para conectar computadoras personales y
estaciones de trabajo en oficinas de compaas y fbricas con objeto de compartir recursos
(por ejemplo impresoras) e intercambiar informacin. Las LAN se distinguen de otro tipo
de redes por tres caractersticas: Su tamao, su tecnologa de transmisin y su topologa.


Red de rea metropolitana (MAN)

Es bsicamente una versin ms grande de una LAN y normalmente se basa en una
tecnologa similar. Podra abarcar un grupo de oficinas corporativas cercanas o una ciudad
y podra ser privada o pblica. Una MAN slo tiene uno o dos cables y no contiene
elementos de conmutacin, lo cuales desvan los paquetes por una de varias lneas de
salida potenciales. Al no tener que conmutar se simplifica el diseo.

Red de rea amplia (WAN)

Se extiende sobre un rea geogrfica extensa, a veces un pas o un continente; contiene
una coleccin de mquinas dedicadas a ejecutar programas de usuario.

Host

Cada una de las mquinas que componen una WAN.

Subred de comunicacin

Red que interconecta los Hosts.

Elementos de conmutacin

Computadoras especializadas que conectan dos o ms lneas de transmisin en una
subred. Tambin llamados enrutadores.

Subred punto a punto

Subred en la que cuando se enva un paquete de un enrutador a otro a travs de uno o ms
enrutadores intermedios, el paquete se recibe completo en cada enrutador intermedio, se
almacena hasta que la lnea de salida requerida est libre, y a continuacin se reenva.

Interred

Coleccin de redes interconectadas

Pasarela

Computador que se encarga de comunicar y traducir los mensajes entre dos redes distintas
de una interred.

13. Ingeniera del software Cliente/Servidor

Sistema raz

Ordenador que acta como depsito de los datos corporativos en un sistema
Cliente/Servidor.

Sistema Cliente/Servidor

Sistema en el que ordenadores interconectados actan como clientes y servidores de
servicios. Los clientes solicitan servicios que se los proporciona el servidor.

Servidor de archivos

El cliente solicita registros especficos de un archivo. El servidor transmite estos registros
al cliente a travs de la red.

Servidor de bases de datos

El cliente enva solicitudes en lenguaje de consulta estructurado (SQL) al servidor. stas
se transmiten como mensajes a travs de la red. El servidor procesa la solicitud SQL y
halla la informacin solicitada, pasando nicamente los resultados al cliente.

Servidor de transacciones

El cliente enva una solicitud que invoca procedimientos remotos en el centro servidor.
Los procedimientos remotos pueden ser un conjunto de sentencias SQL. Se produce una
transaccin cuando una solicitud da lugar a la ejecucin de procedimientos remotos y a la
transmisin del resultado al cliente.

Servidor de grupos de trabajo

Cuando el servidor proporciona un conjunto de aplicaciones que hacen posible la
comunicacin entre clientes (y las personas que los usan) mediante el uso de texto,
imgenes, boletines electrnicos, video y otras representaciones, existe una arquitectura
de grupos de trabajo.

Componente de interaccin con el usuario y presentacin

Este componente implementa todas las funciones que tpicamente se asocian a una
interfaz grfica de usuario (IGU).

Componente de aplicacin

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

descomponer de tal modo que alguno de los componentes residan en el cliente y otros
residan en el servidor.

Gestin de bases de datos.

Este componente lleva a cabo la manipulacin y gestin de datos requerida por una
aplicacin. La manipulacin y gestin de datos puede ser tan sencilla como la
transferencia de un registro, o tan compleja como el procesamiento de sofisticadas
transacciones SQL.

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 aplicacin
especializado que presta su apoyo a las aplicaciones especficas de bases de datos, a
estndares de distribucin de solicitudes de objetos, a tecnologas de trabajo en grupo, a
gestin de comunicaciones, y a otras caractersticas que facilitan la conexin
cliente/servidor.

Diseo de servidor principal

Cuando la mayor parte de la funcionalidad se asocia al servidor

Diseo de cliente principal

Cuando el cliente implementa la mayor parte de los componentes de
interaccin/presentacin con el usuario, de aplicacin y de base de datos.

14. Ingeniera del Software asistida por computadora

Herramienta CASE

Aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas
propias del desarrollo de sistemas. Son programas que automatizan o apoyan una o ms
fases del ciclo de vida del desarrollo de sistemas.

CASE de alto nivel

Herramientas que automatizan o apoyan las fases iniciales o superiores del ciclo de vida
del desarrollo de sistemas (planificacin, anlisis y diseo)

CASE de bajo nivel

Herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida
(diseo detallado de sistemas, implantacin y soporte de sistemas).

CASE cruzado del ciclo de vida

Herramientas que apoyan las actividades que tienen lugar a lo largo de todo el ciclo de
vida, como la gestin de proyectos y la estimacin.

Integracin CASE

Unin de herramientas CASE con el fin de conseguir la mxima automatizacin del ciclo
de vida del desarrollo de sistemas. No es la simple suma de herramientas, deben cumplir
una serie de propiedades especficas.

Entorno de apoyo de proyectos integrados (EAPI)

Distintos fabricantes utilizan una serie de estndares EAPI para construir herramientas
CASE compatibles entre s.

Capa de interfaz de usuario

Conjunto de herramientas de interfaz estandarizado, con un protocolo de presentacin
comn.

Kit de herramientas de la interfaz

Software para la gestin de la interaccin hombre-mquina, con una biblioteca de objetos
de visualizacin. Estos proporcionan un mecanismo consistente para la comunicacin
entre la interfaz y las herramientas CASE individuales.


Protocolo de presentacin

Conjunto de lneas generales que proporcionan a todas las herramientas CASE un mismo
aspecto.

Capa de herramientas

Contiene un conjunto de servicios de gestin de herramientas, as como las propias
herramientas CASE.

Capa de Gestin de objetos (OML)

Lleva a cabo las funciones de gestin de la configuracin. Proporciona el mecanismo para
la integracin de las herramientas.

Capa de depsito compartido

Base de datos CASE junto a funciones de control de acceso que permite la interaccin de
la capa de gestin de objetos con la base de datos.

Depsito CASE

Tambin llamada Base de datos CASE, base de datos del proyecto, diccionario de datos,
etc. Hace referencia al centro donde se almacena la informacin de CASE.

15. Internet e intranet

Internet

Coleccin mundial de redes.

Protocolo TCP/IP

Protocolo de comunicaciones utilizado en Internet.

Paquete de datos

Unidad de informacin utilizada por Internet para enviar mensajes a travs de la red.

Direccin IP

Conjunto de cuatro nmeros comprendidos entre 0 y 255 y separados por puntos que son
utilizados para direccionar los ordenadores que se encuentran en una red.

Correo electrnico

Medio de comunicacin en el que a travs de Internet pueden mandarse mensajes a
distintos usuarios conectados a la red.

Grupos de noticias

Foro especializado en el que usuarios con inters comn pueden intercambiar mensajes en
Internet.

Sesin remota

Conexin a un ordenador de una red, de manera que pueden ejecutarse aplicaciones en
dichos ordenadores, a travs del envo de rdenes por la red. El acceso a estos
ordenadores se realiza a travs de cuentas de usuario y contraseas. Telnet y rlogin son
programas que nos permiten realizar esta tarea.

Transferencia de archivos (FTP)

Aplicacin que permite enviar ficheros a travs de una red de ordenadores.

World Wide Web

Parte de Internet en la que se consulta informacin a travs de pginas de hipertexto.
Utiliza el lenguaje HTML para producir contenidos y el protocolo http para las
comunicaciones.


HTML

Lenguaje que permite el intercambio de documentos independiente de plataformas.
Permite intercalar textos, imgenes, ecuaciones, e hipervnculos a otras pginas de una
manera sencilla.

HTTP

Protocolo de Internet que permite el intercambio de documentos independiente de
plataformas.

Navegador

Programa que interpreta el lenguaje HTML y visualiza pginas de hipertexto recibidas
mediante el protocolo http. Actualmente poseen mltiples capacidades, como envo de e-
mail, transferencia de ficheros, etc.

Intranet

Red interna y autosuficiente que enlaza mltiples usuarios usando la tecnologa Internet.

DNS

Lugar donde se hace una correspondencia de direcciones fsicas IP en direcciones lgicas.

Trabajo en grupo (Groupware)

Es el software necesario para que diversas personas trabajen conjuntamente mediante la
comunicacin, la colaboracin y la coordinacin, de manera que este software (o parte del
mismo) est en cada una de las mquinas conectadas a la red.

Informacin corporativa esttica

Informacin esttica de una organizacin. Es la informacin que cambia con menor
frecuencia y que suele distribuirse en masa por la organizacin.

Datos corporativos

Informacin de trabajo de una organizacin. Esta es la base del funcionamiento de la
misma y va cambiando y fluyendo de manera continua.

Sistema de gestin de documentos

Sistema destinado a la gestin documental. Abarca los aspectos de bsqueda/recuperacin
de informacin, seguridad, control de versin y archivo de informacin.


16. Beneficios de intranet

Eficiencia

Mejora en los mecanismos de intercambio de informacin, mediante la superacin de los
obstculos logsticos que existen para recolectar y diseminar la informacin necesaria de
una forma precisa con la ayuda de una Intranet.

Efectividad

Se refiere al impacto organizativo como consecuencia del perfeccionamiento de la
colaboracin y la toma de decisiones con la ayuda de una Intranet.

Niveles de uso e impacto

Son una medida de la utilizacin y beneficios obtenidos con el uso de una Intranet en una
empresa.

Fragmentacin de datos

Cada tipo de dato o cada tipo de informacin necesita de una aplicacin (programa) para
poder consultar o manipularlo.

Plataforma

Hardware ms software especfico.

Coherencia en la operatoria

Indica que el aspecto y el comportamiento de una aplicacin es similar a una familia de
productos (software).

Automatizacin del flujo de trabajo

Sustitucin de algunos o todos los pasos manuales en un proceso empresarial mediante el
uso de transferencias electrnicas.

Pista de auditora

Informacin sobre el flujo de trabajo de una empresa que queda registrada (en nuestro
caso mediante medios electrnicos).

Formularios HTML

Permiten la introduccin de datos a travs de pginas Web. Es un aadido a la simple
visualizacin de informacin y nos proporcionan el nivel 2 de uso de una Intranet.


Costes de conversin

Son aquellos asociados con las herramientas, mano de obra y estndares requeridos para
convertir los formatos de informacin ya existentes a HTML.

Costes de coordinacin

Son los costes asociados a la coordinacin de contenidos de diversos departamentos de
manera que se ajusten a los estndares de aspecto y uso de la Intranet de la empresa.

Costes de indexacin

Costes asociados a la indexacin peridica de las pginas Web.

Seguridad

Proteccin contra el robo fsico, la corrupcin o el borrado de informacin, contra un fallo
del soporte de la informacin o al acceso no autorizado a la misma.

Encriptacin

Mecanismo de seguridad que cifra la informacin para que solo aquellos que posean
cierta clave puedan acceder a la misma.

Claves pblicas

Mecanismo de encriptacin en la que la informacin se cifra con una clave pblica y se
descifra con una clave privada.

Autentificacin

Mecanismo de seguridad que me permite asegurar que estoy recibiendo o enviando
informacin al destinatario deseado.

Firma digital

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

17. Intranets en accin

Relevancia

Importancia.

Oportunidad

Hace referencia a que si no funciona adecuadamente una Intranet, los usuarios volvern
rpidamente a los mtodos tradicionales de intercambio de informacin.

Actualizacin

La informacin en una Intranet debe estar actualizada de manera frecuente.

Accesibilidad

La informacin de una Intranet debe ser fcilmente accesible, y de manera rpida.

Barreras

Impedimentos de diversa ndole que limitan el acceso a la informacin de una Intranet, o
que limitan las comunicaciones a travs de la misma.

Comunicaciones internas

Comunicacin entre usuarios que estn dentro de la misma Intranet.

Comunicaciones externas

Comunicacin de usuarios que estn dentro de una Intranet con usuarios que no lo estn.

Bibliografa

Mdulo I. Ingeniera de Sistemas

[Press98] Pressman, Roger S.
"Ingeniera del Software. Un enfoque prctico".
Ed. McGraw-Hill. 4 Edicin, 1998

[Luque99] Luque Ruiz, Irene
"Ingeniera del Software. Fundamentos para el desarrollo de sistemas
informticos".
Ed. Servicio de publicaciones. Universidad de Crdoba, 1999

[Whitten96] Whitten, Jeffrey L., et al.
Anlisis y diseo de sistemas de informacin
Ed. IRWIN, 1996

Mdulo II. Planificacin y Gestin de Proyectos


[Piatt96] Piattini, M.G.
Anlisis y diseo detallado de aplicaciones informticas de
gestin,Ed. Ra-ma, 1996

[Luque99] Luque Ruiz, Irene
"Ingeniera del Software. Fundamentos para el desarrollo de sistemas
informticos".
Ed. Servicio de publicaciones. Universidad de Crdoba, 1999


Mdulo III. Sistemas de Bases de Datos

[Hansen97] Hansen, Gary W.
"Diseo y administracin de Bases de Datos"

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

Mdulo IV. Sistemas distribuidos y redes

[Stalin97] Stalings, William
"Comunicaciones y Redes de Computadores"
Ed. Prentice Hall, 5 Edicin, 1997

[Tanen] Tanenbaum, A.S.
Redes de Computadoras
Ed.Prentice Hall, 3 Edicin


Mdulo V. Sistemas de ayuda a la toma de decisiones


[Garret] Garret, D.
Intranets al descubierto
Ed. PrenticeHall

[Benett] Benett, G.
Introduccin a las Intranets
Ed. PrenticeHall

[Tanen] Tanenbaum, A.S.
Redes de Computadoras
Ed.Prentice Hall, 3 Edicin


Bibliografa complementaria:

[Sommer97] Sommerville, Ian
"Software Engineering".
Ed. Addison-Wesley, 5 Edicin, 1997

[Senn92] Senn, James A.
Anlisis y diseo de sistemas de informacin
Ed. McGrawHill, 2 Edicin, 1992

[Rivera] Rivera, A.J.
Redes de Computadores
Coleccin de apuntes. Universidad de Jan

Analisis y Diseño de Sistemas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Analisis y Diseño de Sistemas

Caricato da

Copyright:

Formati disponibili

Organizacin de Sistemas Informticos

Aspectos de Anlisis, Planificacin y Gestin de Proyectos

Potrebbero piacerti anche