Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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
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
Organizacin de Sistemas Informticos
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.
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
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:
15
16
En un S.I. automatizado podemos encontrar distintos niveles de sistemas: Primer nivel: Es el ms bajo. Se incluyen en este nivel los subsistemas informticos que pueden dar soporte a un procesamiento de transacciones. Se le suele llamar tambin operacional o transaccional. Segundo nivel: Formado por los sistemas de informacin para la gestin. Ayudan a los usuarios de mayor nivel de la empresa a tomar decisiones sobre asuntos de cierta regularidad, movindose en los niveles operativo, tctico y estratgico de direccin. Tercer nivel: Constituido por los sistemas para el soporte de decisiones. Dan soporte y ayuda a decisiones poco estructuradas en las que no hay mtodos claros para tomarlas. La automatizacin de un S.I. debe contemplar la eleccin del hardware y la configuracin ms adecuada de software de base, as como la consecucin de las aplicaciones software que permitan cubrir las necesidades de informacin que marcan la estructura del S.I.
Organizacin de Sistemas Informticos
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.
Organizacin de Sistemas Informticos
19
20
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.
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
Organizacin de Sistemas Informticos
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.
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
Organizacin de Sistemas Informticos
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.
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?
Organizacin de Sistemas Informticos
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.
31
32
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.
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.
Organizacin de Sistemas Informticos
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.
- Herramientas:
- Procedimientos:
39
40
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
- 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
Se verifica el producto software. Se pretende asegurar que cada uno de los componentes software del producto funcionan correctamente, asegurndose que todas las partes del software se han probado y que cada una de ellas produce la salida esperada en base a una entrada definida. - Mantenimiento: Se introducen cambios en el software, bien debido a errores, o a cambios en los requisitos. Inconvenientes del paradigma de ciclo de vida clsico: - Los proyectos raramente son secuenciales, se producen iteraciones.
- Los requisitos no se completan hasta fases posteriores. Los cambios en fases finales originan graves problemas. - Es posible que no se detecten los errores hasta que tengamos el producto. La reparacin de esos errores nos pueden ocasionar grandes retrasos y aumento de costes debido a cambios en fases anteriores.
- 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:
Organizacin de Sistemas Informticos
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)
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:
Organizacin de Sistemas Informticos
45
46
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
53
54
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.
55
56
Captulo 5
Planificacin de proyectos software y Gestin del Riesgo
La estimacin de recursos, costes, y la planificacin temporal de un esfuerzo de desarrollo software requiere experiencia, acceder a una buena informacin histrica y la confianza en medidas cuantitativas cuando todo lo que existe son datos cualitativos. La estimacin conlleva un riesgo inherente, y es este riesgo el que lleva a la incertidumbre: - La complejidad del proyecto tiene un gran efecto en la incertidumbre. Sin embargo la complejidad es una medida relativa que se ve afectada por la familiaridad con esfuerzos anteriores. - El tamao del proyecto es otro factor importante que puede afectar a la precisin de las estimaciones. - La disponibilidad de informacin histrica determina el riesgo de la estimacin. Aquellos que no pueden recordar el pasado estn condenados a repetirlo. El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas por recursos, coste y planificacin temporal. Si no se entiende bien el mbito del proyecto o los requisitos del proyecto estn sujetos a cambios, la incertidumbre y el riesgo son peligrosamente altos. El planificador de software debera solicitar definiciones completas de rendimiento y de interfaz. Cualquier cambio en los requisitos software significa inestabilidad en el coste y en la planificacin temporal.
- 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.
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)
6. Anlisis de Riesgo
La estrategia de riesgo reactiva, en el mejor de los casos, supervisa el proyecto en previsin de posibles riesgos. Pero lo ms frecuente es que el equipo no haga nada respecto a los riesgos hasta que algo va mal. Despus el equipo, apresuradamente trata de corregir el problema. Cuando falla, la gestin de crisis entra en accin y el proyecto se encuentra en peligro real. La estrategia proactiva empieza mucho antes de que comiencen los trabajos tcnicos. Se identifican los riesgos potenciales, se valora su probabilidad y se establece una prioridad segn su importancia. Despus el equipo de desarrollo establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada. El riesgo siempre implica dos caractersticas: Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no ocurrir Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas.
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de prdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categoras de riesgos: Los riesgos del proyecto amenazan el plan de proyecto. Si los riesgos de proyecto se hacen realidad, es probable que la planificacin temporal del proyecto se retrase y que los costos aumenten. Los riesgos de proyecto identifican problemas potenciales de: - presupuesto, - planificacin temporal, - personal, - recursos y - requisitos.
59
60
61
62
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
Organizacin de Sistemas Informticos
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.
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
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.
67
Inconveniente: Dificultad a la hora de conocer realmente el grado de similitud con otro proyecto.
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.
Organizacin de Sistemas Informticos
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.3. Observaciones
- El modelo supone una estimacin implcita de la productividad en el desarrollo del proyecto, obtenindose como cociente entre el nmero de instrucciones fuente entregadas (IFE) y el esfuerzo estimado (PM). Es decir: Productividad = IFE / PM - Permite conocer el nmero medio de personas requeridas para completar el proyecto (N). Para ello se divide el esfuerzo entre el tiempo estimado. N = PM / TDES - El tiempo requerido para completar el proyecto es una funcin que depende del esfuerzo total requerido para el proyecto y no del nmero de ingenieros de software que trabajen en el mismo. - El modelo COCOMO (bsico) no aporta gran ayuda en la estimacin de tiempo cuando el personal disponible est limitado y, por el contrario, el tiempo de entrega es flexible.
3.2.4. Ejemplo
Suponer un proyecto de software de tipo orgnico cuyo tamao se estima en 32000 instrucciones fuente entregadas. Para dicho proyecto se obtienen los siguientes valores: PM = 2.4 * (32 ^ 1.05) = 91 personas-mes
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.
Organizacin de Sistemas Informticos
N = 91 / 14 = 6.5 personas 72
71
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
*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
Organizacin de Sistemas Informticos
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.
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.
77
78
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.
Organizacin de Sistemas Informticos
- 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.
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.
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.
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
Unidades de tiempo 4 5 6
10
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).
Organizacin de Sistemas Informticos
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. 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.
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
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
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.
Una vez vistos los aspectos en los que se basa la representacin de actividades, vamos a ver la realizacin del grafo PERT mediante un ejemplo. Supongamos que tenemos que realizar un proyecto que tiene las siguientes actividades A, B, C, D, E, F y G. Las relaciones entre actividades son las siguientes:
A 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.
- 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.
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.
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.
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.
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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.
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.
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.
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
101
102
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.
105
106
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.
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.
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.
109
110
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.
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
Organizacin de Sistemas Informticos
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
Dirigente intermedio
Operativos
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:
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.
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.
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.
121
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.
123
124
125
126
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).
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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.
Organizacin de Sistemas Informticos
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.
129
130
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
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.
131
132
Cuando se enva un paquete de un enrutador a otro a travs de uno o ms enrutadores intermedios, el paquete se recibe completo en cada enrutador intermedio, se almacena hasta que la lnea de salida requerida est libre, y a continuacin se reenva. Una subred basada en este principio se llama de punto a punto. Cuando se usa una subred punto a punto, una consideracin de diseo importante es la topologa de interconexin del enrutador. Podemos ver algunas a continuacin:
Fig. 12-5. Topologas de interconexin de enrutadores. a) Estrella. b) Anillo. c) rbol. d) Totalmente conectada. e) Doble anillo. f) Irregular
3.4. Interredes
Existen muchas redes en el mundo, a veces con diferente hardware y software. La gente conectada a una red a menudo quiere conectarse con gente conectada a una red distinta. Esto requiere conectar redes diferentes y con frecuencia incompatibles, algunas veces usando mquinas llamadas pasarelas para hacer la conexin y realizar la traduccin necesaria, ambas en trminos de hardware y software. Una coleccin de redes interconectadas se llama interred.
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.
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
137
138
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.
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
Organizacin de Sistemas Informticos
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.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.
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.
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
Organizacin de Sistemas Informticos
165
166
tienen un aspecto muy similar en la web, al margen del navegador utilizado para visualizarlos.
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.
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.
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:
Organizacin de Sistemas Informticos
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?
173
174
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
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)
181
182
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.
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.
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.
187
188
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.
189
190
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
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
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.
Organizacin de Sistemas Informticos
Planeado:
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.
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 ...
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.
Organizacin de Sistemas Informticos
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.
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.
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.
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
Organizacin de Sistemas Informticos
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.
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.
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?
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.
209
210
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
Organizacin de Sistemas Informticos
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
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.
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
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
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
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.
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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
Organizacin de Sistemas Informticos
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
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
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
Organizacin de Sistemas Informticos
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.
Organizacin de Sistemas Informticos
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
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
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
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
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
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
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
261
262
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
Organizacin de Sistemas Informticos
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
267
268
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.
Organizacin de Sistemas Informticos
271
273
274
Bibliografa
Mdulo III.
[Hansen97]
[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]
[Luque99]
[Tanen]
[Press98]
[Whitten96]
Mdulo V.
[Press98]
Mdulo II.
[Press98]
[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