Sistemas de Informacion

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
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.
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 8
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
10
Mdulo I INGENIERA DE SISTEMAS
11
12
3. Concepto de informacin
Captulo 1
Los Sistemas 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.
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
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 14
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. 13
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.
6. Estructura de los S.I.

En lneas generales podemos representarlo mediante una pirmide de niveles:
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-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.
Objetivos
Procedimientos y prcticas de trabajo
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. 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.
INFORMACIN
PERSONAL
EQUIPO Vertical:
Fig. 1-1. Elementos de los Sistemas de Informacin
15
16
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.
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)
Organizacin o Empresa Sistema de Informacin

Sistema de Informacin automatizado Sistema Informtico de Soporte
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.
17
18
Tabla 1-1. Subsistema de recursos humanos 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. Nivel Generacin de informes oficiales que son necesarios remitir a la administracin pblica (los operativo 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. 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 Nivel tctico 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. Realizacin de las tareas del nivel tctico bajo una perspectiva de medio y largo plazo. Nivel estratgico Tabla 1-2. Subsistema de gestin comercial 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. Nivel Consultas sobre las caractersticas y disponibilidad de los productos de la organizacin. operativo 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. 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. Nivel tctico 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. En este nivel, trabajando a aos vista, se realizan estudios y planificaciones de marketing y Nivel distribucin de los productos, estudiando el mercado y los diferentes sectores dentro del mismo estratgico sobre los que se pueda actuar, realizando predicciones de nuevos productos y sus posibles ventas. Tabla 1-3. Subsistema de control de almacn 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 Nivel de los envos y actualizacin de existencias en el almacn. operativo 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. 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 Nivel tctico prever las cantidades mnimas de stock que permiten no interrumpir los procesos de ventas y produccin. 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 Nivel estratgico 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.
19
20
Principio 3. Definir fases y actividades:
Captulo 2
Ingeniera de Sistemas
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:
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.
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. 22
21
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.
23
24
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
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.
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.
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: 26
25
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?
27
28
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.
Fig. 2-4. Fases de diseo del sistema
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
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
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.
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.
29
30
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.
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-5. Fases de Implantacin del sistema
31
32
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.
Fig. 2-6. Fases de Soporte del sistema
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. 33 34
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.
35
36
Tercera era:
Captulo 3
La Ingeniera del Software
- Sistemas distribuidos - Hardware de bajo coste (microprocesadores y PCs). - Impacto en el consumo. - Sistemas personales potentes. - Entornos descentralizados, cliente/servidor. - Redes de computadoras. - Computacin en paralelo. - Sistemas expertos.
Cuarta era:
1.2. El 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.
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.
1.1. Evolucin del software

Segunda era Primera era 1950 1960 1970 Tercera era 1980 1990 2000 Cuarta era
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.
Fig. 3-2. Curvas del ndice de fallos del hardware y del software
37
38
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.
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. Sirven de soporte al proceso de produccin, proporcionando elementos para la ejecucin de los mtodos. 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.
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.
- Herramientas:
- Procedimientos:
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.
39
40
- Anlisis de requisitos: se realiza una descripcin detallada de:
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:
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 especificacin entendible por la computadora. diseo a una
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:
- 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:
- 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.
- 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.
41
42
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.
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.
Fig. 3-4. Ciclo de vida clsico del desarrollo de sistemas
- 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.
- 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:
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: 44
43
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:
- 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.
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.
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)
2.1.3. Prototipos de necesidades

- 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.
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:
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.
45
46
Mdulo II PLANIFICACIN Y GESTIN DE PROYECTOS
47
48
Captulo 4
Conceptos sobre Gestin de Proyectos
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.
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.2. El Problema
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.
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 50
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
49
limitaciones impuestas por la fecha lmite de entrega, restricciones de presupuesto, disponibilidad de personal y otros muchos factores.
- 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.
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.
Tambin hay comunicacin vertical a lo largo de la jerarqua de control. 5. Usuarios finales: interaccionan con el software una vez que se ha entregado. 3- Centralizado controlado (CC): 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. 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.
51
52
3. Identificacin del Problema

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. 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.
53
54
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. 2. 3. 4. 5. Desarrollar una lista de aspectos a clarificar. Reunirse con el cliente para resolver los aspectos que se han de clarificar. Desarrollar conjuntamente una exposicin del mbito del proyecto. Revisar el alcance del proyecto con todos los implicados. Modificar el alcance del proyecto cuando se requiera.
55
56
Captulo 5
Planificacin de proyectos software y Gestin del Riesgo
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. Abarca los requisitos procesamiento. de tiempo de respuesta y de
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.
- El rendimiento:
- 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.
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.
57
58
* 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)
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.
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.
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.
59
60
6.1. Identificacin del Riesgo

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. 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.
61
62
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 = {ri, pi, ci} donde ri identifica al riesgo i, pi es la probabilidad de que se produzca el problema que genera el riesgo i, y ci es el coste del riesgo. Para que la 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.
Proceso de desarrollo Desarrollo de una estrategia de solucin Definicin del problema
Tabla 5-1. Actividades de la planificacin del proyecto software 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. 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. 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: 64
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.
63
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 Coste

Estimado 20.000 millones de dlares
Mx. o mn. Limitacin
Aceptacin X
Calendario
Plazo lmite = 31 diciembre de 1969
mbito y/o calidad X 1. Llevar un hombre a la Luna 2. Traerlo de nuevo sano y salvo 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.
65
66
2.1. Juicio de Expertos
Captulo 6
Estimacin de Costes y Plazos
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.
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.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. 68
67
Inconveniente: Dificultad a la hora de conocer realmente el grado de similitud con otro proyecto.
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.
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).
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.
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. - 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. 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.2. Tamao del Software

El tamao estimado para el software se mide en miles de instrucciones fuente entregadas.
69
70
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.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) TDES = 2.5 * (PM ^ 0.35) TDES = 2.5 * (PM ^ 0.32)
3.1.3. Otras suposiciones

- Tipo Semi-separado: 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. - Tipo Empotrado:
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. 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: - Tipo Semi-separado: - Tipo Empotrado: Observaciones: PM = 2.4 * (MIFE ^ 1.05) PM = 3.0 * (MIFE ^ 1.12)
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
PM = 3.6 * (MIFE ^ 1.20) TDES = 2.5 * (91 ^ 0.38) = 14 meses Productividad = 32000 / 91 = 352 ife/p-m (alrededor de 18 instrucc. por persona-da)
- 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.
N = 91 / 14 = 6.5 personas 72
71
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: - Tipo semi-separado: - Tipo empotrado: EN = 3.2 * (MIFE ^ 1.05) EN = 3.0 * (MIFE ^ 1.12) EN = 2.8 * (MIFE ^ 1.20)
Atributo F1 RELY F2 DATA F3 CPLX F4 TIME F5 STOR F6 VIRT F7 TURN F8 ACAP F9 AEXP F10 PCAP F11 VEXP F12 LEXP F13 MODP F14 TOOL F15 SCED
MB 0.75 -0.70 ----1.46 1.29 1.42 1.21 1.14 1.24 1.24 1.23
B 0.88 0.94 0.85 --0.87 0.87 1.19 1.13 1.17 1.10 1.07 1.10 1.10 1.08
N 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00
A 1.15 1.08 1.15 1.11 1.06 1.15 1.07 0.86 0.91 0.86 0.90 0.95 0.91 0.91 1.04
MA 1.40 1.16 1.30 1.30 1.21 1.30 1.15 0.71 0.82 0.70 --0.82 0.83 1.10
EA --1.65 1.66 1.56 -----------
*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
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
RELY: Fiabilidad requerida del software: 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. 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
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:
73
74
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:
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:
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.
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.
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:
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.
75
76
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)
- 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).
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 C = 45 * 1.15 * 1.24 = 64 * 6000 = 64 p-m = 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.
77
78
- Responsabilidades definidas: asignan cada tarea a un miembro especfico.
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.
- 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 20% 40% Anlisis y diseo Codificacin Prueba y depuracin
Esto es una directriz, estos porcentajes dependen del proyecto considerado. Planificacin Anlisis de requisitos Diseo de software Revisin de diseo Codificacin Prueba y depuracin 2-3% 10-25% 20-25% 5-10% 15-20% 30-40%
79
80
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.
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.
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.
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-1. Red de tareas para un proyecto
81
82
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.
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.
83
84
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. ...
85
86
Captulo 8
Tcnicas de Planificacin Temporal
tareas fase 1 1.1 1.2 1.3 fase 2 2.1 2.2 2.3
Unidades de tiempo 4 5 6
10
Fig. 8-1. Diagrama de Gantt
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.
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 4 5 6
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).
tareas fase 1 1.1 1.2 1.3 fase 2 2.1 2.2 2.3
10
hoy
Fig. 8-2. Avance del proyecto con diagramas de Gantt
87
88
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.
2
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.
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-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.
89
90
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:
A B C D E, F
precede a precede a precede a precede a precede a
B, C y D E F G 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 Mij un elemento de la matriz, si Mij = X, entonces, para poder iniciar la actividad i, es necesario que haya finalizado la actividad j. En nuestro caso, la matriz quedar de la siguiente manera: A A B C D E F G H X X X X X X X X
Fig. 8-7. Matriz de encaminamientos
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.
En este punto se construye el grafo:
Fig. 8-6. Grafo de relaciones entre actividades con actividad ficticia
Una vez vistos los aspectos en los que se basa la 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:
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:
91
92
Estimacin de tiempo pesimista (tp): 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 (tn): 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 (to): 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 = (tp + 4tn + to) / 6 y la varianza: = SQRT ( ((tp to) / 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:
donde TEi es el tiempo early del suceso i y Tij 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 Duracin A 8 B 5 C 6 D 5 E 6 F 7 G 9 H 3
Por ejemplo, para calcular el TE6, estudiamos los sucesos iniciales de las actividades E y F: TE6 = mx [14+7, 13+6] = 21, y para TE7 = 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 TEi = 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:

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 TEj ser igual a: TEj = mx. [ TEi + Tij], j
- 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.
93
94
El tiempo late del ltimo suceso coincide con su tiempo early. El resto de los tiempos late se calculan: TLi = min. [TLj Tij], j donde TLj es el tiempo last del suceso j y Tij la 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.
La holgura total de una actividad que une el suceso i con el suceso j se define como: HTij = TLj TEi - Tij 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: TEi = TEj = 26. Sin embargo, la actividad E tiene una holgura total Ht36 = 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.
Fig. 8-11. Clculo de los tiempos ms lejanos en una red Pert
En el ejemplo podemos ver que la actividad H es crtica: HT67 = 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.
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: Hi = TLi TEi
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.
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 Hi = 0. En el ejemplo vemos que son crticos los sucesos: 1, 2, 4, 6 y 7.
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. 96
95
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.
97
98
Captulo 9
Control de calidad del Software y Gestin de la Configuracin
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.
1. Introduccin
2.3. Garanta de calidad
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. 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.
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.
99
100
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.
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.
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.
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.
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.
101
102
Mdulo III SISTEMAS DE BASES DE DATOS
103
104
Captulo 10
Introduccin a los SGBD
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.
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:
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.
105
106
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.
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.
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.
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.
107
108
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.
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-2. Diagrama entidad-relacin
109
110
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-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-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

Fig. 10-4. Ejemplo de base de datos en red
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.
111
112
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.
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.
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.
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.
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
113
114
Captulo 11
Sistemas de BD en las Organizaciones
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)
Sistema de soporte a la toma de decisiones
Ejecutivo
Informes Estratgicos Consultas Anlisis
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.
Dirigente intermedio
Sistema de informacin de gestin
Informes de direccin por reas funcionales
Operativos
Sistema de procesamiento electrnico de datos
Transacciones Mantenimiento archivos Procesamiento informes de control
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:
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
115
116
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.
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.
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.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.
117
118
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.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. 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.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.
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.
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 120
119
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.
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.
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.
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.
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.
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?
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.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. 122
121
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.
123
124
Mdulo IV SISTEMAS DISTRIBUIDOS Y REDES
125
126
1.2. Un modelo para las comunicaciones
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).
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. 128
127
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.
129
130
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.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.
3. Hardware de red
Vamos a ver una clasificacin de las redes en funcin de su escala.
Distancia entre procesadores 0,1 m 1m 10 m 100 m 1 km 10 km 100 km 1.000 km 10.000 km Ubicacin procesadores Tarjeta de circuitos Sistema Cuarto Edificio Campus Ciudad Pas Continente Planeta Ejemplo Procesador paralelo Multicomputadora Red de rea local Red de rea metropolitana Red de rea amplia Internet
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.
Fig. 12-2. Clasificacin de redes segn su escala

131
132
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.
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:
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-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.
Fig. 12-4. Interconexin en una red de rea amplia
133
134
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:
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.
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: 135
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. 136
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.
137
138
Mdulo V SISTEMAS DE AYUDA A LA TOMA DE DECISIONES
139
140
Captulo 14
Ingeniera del Software asistida por computadora
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:
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.
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 142
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-
141
Herramientas de anlisis de riesgos. 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. 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.
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.
143
144
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.
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 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.
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.
145
146
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.
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.
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).
- Recoger mtricas tanto de gestin como tcnicas que se puedan utilizar para mejorar el proceso y el producto.
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. 147
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.
148
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.
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
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.
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
149
150
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.
151
152
3. Aplicaciones en Internet
Captulo 15
Internet e intranet
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.
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.
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 154
153
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.
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.
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
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.
155
156
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).
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.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.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.
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.
157
158
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.
159
160
Captulo 16
Beneficios de intranet
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.
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 online 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.
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. 162
161
para facilitar la realizacin rpida de cambios de los contenidos de un servidor intranet, a menudo por medios automatizados. 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. 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 164
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
163
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.
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. 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
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
165
166
tienen un aspecto muy similar en la web, al margen del navegador utilizado para visualizarlos.
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.
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.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.
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.
167
168
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.
169
170
Captulo 17
Intranets en accin
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.
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.
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:
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:
171
172
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.
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?
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.
173
174
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.
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.
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.
175
176
APNDICES
177
178
Apndice I
Anlisis Estructurado de Sistemas
La metodologa SSA utiliza estas herramientas para construir una especificacin estructurada. SSA propone un procedimiento de trabajo y un ciclo de vida:
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 distinguindolas adecuadamente. de los sistemas,
Fig. I-1. Ciclo de vida del Software en SSA
- 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. 179 180
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 Nbre. Proceso Almacn Nombre del fichero
Fig. I-3. Representacin de elementos en un DFD
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)
Entidad Externa Nombre entidad Flujo de datos Nombre flujo
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.
181
182
3.3. Entidades externas.
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.
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.
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.
183
184
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.)
185
186
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.
187
188
3. Revisar la estructura resultante, eliminando detalles fsicos residuales:
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.
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.
8.2. Modelo lgico actual

2. Identificar el dominio del cambio. 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. 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.
189
190
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 hombremquina. 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.
191
192
Apndice II
Tcnicas de Obtencin de Informacin
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 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. 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.
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:
193
194
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. Tanto las pautas a seguir en las entrevistas como los guiones de stas debern ser estudiadas previamente. Sern los usuarios para los cuales se intenta desarrollar la aplicacin. En este trmino englobamos a los ingenieros de sistemas y analistas encargados de realizar el proyecto.
Planeado:
Fuente: Destino: 196
195
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:
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

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 Costo de preparacin Flexibilidad en preguntas Flexibilidad en reas de informacin a explorar. Sesgo personal del entrevistador Preparacin del entrevistador Evaluacin objetiva de preguntas y respuestas Comodidad de los entrevistados Duracin Rendimiento de la entrevista (informacin/tiempo) Administracin y evaluacin Uniformidad entre entrevistados Estructurada I I I V V V Depende del entrevistado V V V V No estructurada V V V Depende del entrevistador I I Depende del entrevistador I Depende del entrevistador I Depende del entrevistador
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 ...
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.
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.
197
198
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.
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.
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.
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.
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
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.
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.
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. 2. Llevando cada punto hasta el final, es decir, desarrollar un punto en concreto hasta el final antes de pasar a otro. Descendiendo en paralelo con todos los puntos.
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). 199 200
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.
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.
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. 201
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,
202
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.
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.
- 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. b. c. d. e. f. g. Interrogantes innecesarias. Preguntas que pueden ser mal interpretadas debido a su enfoque o forma de escritura. Preguntas que el sujeto posiblemente no pueda responder, dado que desconoce la respuesta. Preguntas que estn escritas de forma que se escoger la respuesta preferida. Preguntas que se interpretarn de forma diferente dependiendo del marco de referencia de cada entrevistado. Preguntas que no proporcionan opciones adecuadas de respuesta. Un ordenamiento no adecuado de las preguntas o respuestas.
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. 204
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
203
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.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.
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.
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.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.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.
205
206
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.
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.
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.
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.
207
208
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.
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.
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?
209
210
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
211
212
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. 214
213
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).
215
216
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.
217
218
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. 3. Aspectos de rendimiento. 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. 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. Apndices. A. Glosario de trminos. B. Bibliografa. ...
219
220
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).
221
222
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. versin Fecha 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
V F
Ejemplo:
223
224
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.
225
226
2. Especificacin del Sistema
Apndice V
Listas de Inspeccin
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?
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.
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?
227
228
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?
229
230
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?
231
232
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?
233
234
Automatizacin de un sistema de informacin
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.
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 236
235
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.
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 238
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
237
Diseo de sistemas 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 Software 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. Programas, estructuras de datos y documentacin que hacen efectivo el mtodo lgico, procedimiento o control requerido. 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.
239
240
3. La Ingeniera del Software

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.
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).
241
242
4. Conceptos sobre gestin de proyectos

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.
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. 244
243
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.
245
246
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.
247
248
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.
249
250
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.
251
252
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.
253
254
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.
255
256
Nivel de abstraccin de datos de vistas
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.
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.
257
258
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
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
Asociacin entre varias entidades. Archivo que contiene metadatos, es decir, datos acerca de los datos. Diagrama entidad-relacin Lenguaje de manipulacin de datos (LMD) Diagrama grfico que se utiliza para expresar la totalidad de estructuras lgicas de una base de datos. Modelo orientado a objetos LMD procedimientales 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. 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. 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 Lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado
259
260
11. Sistemas de Bases de Datos en las organizaciones

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. 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.
261
262
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. 263 264
13. Ingeniera del software Cliente/Servidor

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. 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
265
266
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 interaccin/presentacin con el usuario, de aplicacin y de base de datos. de
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.
267
268
15. Internet e intranet

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. 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.
269
270
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 email, 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. 272
271
17. Intranets en accin

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. 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.
273
274
Bibliografa
Mdulo III.
[Hansen97]
Sistemas de Bases de Datos

Hansen, Gary W. "Diseo y administracin de Bases de Datos" Silberschatz, A. Fundamentos de Bases de Datos Ed. McGrawHill
[Silbers]
Mdulo I.
[Press98]
Ingeniera de Sistemas
Pressman, Roger S. "Ingeniera del Software. Un enfoque prctico". Ed. McGraw-Hill. 4 Edicin, 1998 Luque Ruiz, Irene "Ingeniera del Software. Fundamentos para el desarrollo de sistemas informticos". Ed. Servicio de publicaciones. Universidad de Crdoba, 1999 Whitten, Jeffrey L., et al. Anlisis y diseo de sistemas de informacin Ed. IRWIN, 1996
Mdulo IV.
[Stalin97]
Sistemas distribuidos y redes

Stalings, William "Comunicaciones y Redes de Computadores" Ed. Prentice Hall, 5 Edicin, 1997 Tanenbaum, A.S. Redes de Computadoras Ed.Prentice Hall, 3 Edicin Pressman, Roger S. "Ingeniera del Software. Un enfoque prctico". Ed. McGraw-Hill. 4 Edicin, 1998
[Luque99]
[Tanen]
[Press98]
[Whitten96]
Mdulo V.
[Press98]
Sistemas de ayuda a la toma de decisiones

Pressman, Roger S. "Ingeniera del Software. Un enfoque prctico". Ed. McGraw-Hill. 4 Edicin, 1998 Garret, D. Intranets al descubierto Ed. PrenticeHall Benett, G. Introduccin a las Intranets Ed. PrenticeHall Tanenbaum, A.S. Redes de Computadoras Ed.Prentice Hall, 3 Edicin
Mdulo II.
[Press98]
Planificacin y Gestin de Proyectos

Pressman, Roger S. "Ingeniera del Software. Un enfoque prctico". Ed. McGraw-Hill. 4 Edicin, 1998 Piattini, M.G. Anlisis y diseo detallado de aplicaciones informticas de gestin,Ed. Ra-ma, 1996 Luque Ruiz, Irene "Ingeniera del Software. Fundamentos para el desarrollo de sistemas informticos". Ed. Servicio de publicaciones. Universidad de Crdoba, 1999
[Garret]
[Piatt96]
[Benett]
[Luque99]
[Tanen]
275
276
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, A.J. Redes de Computadores Coleccin de apuntes. Universidad de Jan
[Rivera]
277

Sistemas de Informacion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas de Informacion

Cargado por

Copyright:

Formatos disponibles

Organizacin de Sistemas Informticos

Aspectos de Anlisis, Planificacin y Gestin de Proyectos Introduccin a las intranets

Juan Jos Jimnez Delgado

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Mdulo I INGENIERA DE SISTEMAS

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

6. Estructura de los S.I.

5. Elementos de los Sistemas de Informacin

Procedimientos y prcticas de trabajo

Fig. 1-1. Elementos de los Sistemas de Informacin

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

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

8. Arquitectura de los S.I.

Organizacin o Empresa Sistema de Informacin

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

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Principio 3. Definir fases y actividades:

2. Principios para el desarrollo de sistemas

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Fig. 2-2. Fases de Planificacin del Sistema

Organizacin de Sistemas Informticos

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

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Fig. 2-5. Fases de Implantacin del sistema

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

9. Actividades cruzadas del ciclo de vida

Fig. 2-6. Fases de Soporte del sistema

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

1.1. Evolucin del software

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

Organizacin de Sistemas Informticos

2. El Proceso: La ingeniera del Software.

1.3. Tipos de aplicaciones software

1.4. Problemas relacionados con el Software.

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

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

2.1. Paradigmas de la I.S.

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

Organizacin de Sistemas Informticos

Organizacin de Sistemas Informticos

2.1.1. Paradigma del ciclo de vida clsico

Fig. 3-4. Ciclo de vida clsico del desarrollo de sistemas

2.1.2. Paradigma del prototipo

2.1.3. Prototipos de necesidades

2.2. Tcnicas de cuarta generacin (T4G)