S e c r Secretara de Educacin Pblica Subsecretara de Educacin Superior e t a r

SEP

DGEST
a d e E d u c a c i n

SES

INSTITUTO TECNOLGICO DE LZARO CRDENAS

TRABAJO DE TITULACION OPCION II (LIBRO DE TEXTO)

P b l i c a S u b s e c r e t a r a d e

MONOGRAFIA: FUNDAMENTOS DE DESARROLLO DE SISTEMAS

PARA OBTENER EL TITULO DE: INGENIERO EN SISTEMAS COMPUTACIONALES

PRESENTA: MAGALI GUERRERO ZARAGOZA NUMERO DE CONTROL: 03560092

E d u c a c i n

S u p e r i o r

ASESOR: M.C. DANIEL ROJAS CID

CD. Y PUERTO LZARO CRDENAS MICH. DICIEMBRE DEL 2009.

CERTIFICADO ISO 9001

RSGC - 247

PREFACIO

Este libro es el producto de una investigacin de docencia a nivel licenciatura, en el rea de los sistemas de informacin dentro de la Tecnologa de la informacin (IT). Aunque en la actualidad existe un nmero cada vez mayor de libros de texto, en especial en ingles, relacionados con la ingeniera de software y los sistemas de informacin, el principal objetivo de esta obra es su enfoque, que cubre de manera integral tanto los aspectos tericos como los prcticos. En particular se busca que el lector aprenda cmo desarrollar sistemas de calidad mediante la creacin de una arquitectura de software y el seguimiento de una metodologa bien definida. Por tal razn, una parte importante del libro se basa en un sistema comprensivo de software, en lugar de pequeos ejemplos aislados. Otro motivo para la escritura de este libro es reducir la brecha existente entre el nmero de textos en ingles y espaol. Los lectores hacia quienes va dirigido esta obra, son tanto estudiantes universitarios como profesionistas en el rea del desarrollo de software. Como texto, este material tiene como objetivo cubrir las necesidades de un curso de licenciatura o maestra, con programas semestrales o trimestrales, de manera completa o parcial, pues es una introduccin a la ingeniera de software. El ttulo particular de este libro, Fundamento de Desarrollo de Sistemas, busca resaltar los aspectos que en la actualidad tienen un significado muy especial. El libro cubre los temas ms relevantes para un curso de ingeniera de software, el cual est dividido en seis secciones principales: Unidad I Describe las razones de la necesidad de los diferentes tipos de sistemas que existen. As como el ciclo de vida de un proyecto de software.

Unidad II Describe la definicin, historia, caractersticas y mitos de la Ingeniera de Software. Se analiza las capas de dicha ingeniera para realizar el desarrollo del software tomando en cuenta los factores de calidad y productividad.

Unidad III Analiza las actividades ms importantes del desarrollo del software con el enfoque estructurado y el enfoque orientado a objetos.

Unidad IV Enfatiza los modelos de cascada, espiral, incremental, proceso de desarrollo unificado y proceso de software personal que se aplican en el desarrollo de software.

Unidad V Describe las diferentes tcnicas de recopilacin para darle una estructura orientada a objetos y se desarrolle el prototipo de dicha informacin.

Unidad VI Describe las caractersticas de cada arquitectura para el diseo del software tomando en cuenta el tipo de dominio de la aplicacin.

INDICE

Unidad 1 Conceptos Introductorias PGINA 1.1 Introduccin a los Sistemas .........................................................................................10 1.1.1 Descripcin General ................................................................................................11 1.1.2 Tipos .........................................................................................................................12 1.1.3 Clasificacin ..............................................................................................................24 1.2 Ciclo de Vida de un Proyecto de Software .................................................................26 1.2.1 Planificacin y Gestin del Proyecto ........................................................................27 1.2.2 Determinacin de Requerimientos ..........................................................................29 1.2.3 Anlisis y Diseo .......................................................................................................30 1.2.4 Programacin ...........................................................................................................32 1.2.5 Pruebas e Implementacin .......................................................................................32 Preguntas y ejercicios .......................................................................................................36

Unidad 2 Introduccin a la ingeniera de software 2.1 Definicin de Ingeniera de Software ............................................................................38 2.2 Historia de la Ingeniera de Software ...........................................................................40 2.3 Caractersticas del Software ........................................................................................47 2.4 Mitos del Software .......................................................................................................50 2.5 Capas de la Ingeniera de Software ............................................................................53 2.6 El Proceso del Software...............................................................................................55 2.7 Software de Alta Calidad .............................................................................................59 2.8 Factores de Calidad y Productividad ...........................................................................62 Ejercicios ............................................................................................................................64

Unidad 3 Paradigmas de la ingeniera de software 3.1 El Enfoque Estructurado .............................................................................................66 3.1.1 Diagramas de Flujos de Datos ................................................................................67 3.1.2 Diccionarios de Datos ..............................................................................................76 3.1.3 Diseo de Mdulos ..................................................................................................84 3.1.4 Descomposicin en Procesos .................................................................................85 3.2 El Enfoque Orientado a Objetos .................................................................................87 3.2.1 Anlisis .....................................................................................................................91 3.2.2 Diseo Objetos ........................................................................................................97 Ejercicios ..........................................................................................................................101

Unidad 4 Modelos de proceso de software 4.1 Modelo de Cascada ..................................................................................................104 4.2 Modelo de Espiral .....................................................................................................107 4.3 Modelo Incremental ..................................................................................................112 4.4 Proceso de Desarrollo Unificado ..............................................................................116 4.5 Proceso Software Personal ......................................................................................120 Ejercicios ..........................................................................................................................125

Unidad 5 Tcnicas herramientas y estudios previos 5.1 Tcnicas de Recopilacin de Informacin ................................................................127 5.1.1 Entrevista ...............................................................................................................127 5.1.2 Cuestionario ...........................................................................................................135 5.1.3 Recopilacin y anlisis de documentos .................................................................143 5.1.4 Observacin y Tcnica Strobe ............................................................................152 5.2 Herramientas Case ...................................................................................................159 5.2.1 Estructuradas .........................................................................................................164 5.2.2 Orientadas a Objetos .............................................................................................166 5.3 Desarrollo de Prototipos ...........................................................................................169 Ejercicios ..........................................................................................................................179

Unidad 6 Diseo y arquitectura de productos de software 6.1 Descomposicin Modular..........................................................................................181 6.2 Arquitecturas de Dominio Especfico ........................................................................184 6.2.1 Diseo de Software Arquitectura Multiprocesador ................................................186 6.2.2 Diseo de Software Arquitectura Cliente Servidor ................................................188 6.2.3 Diseo de Software Distribuido .............................................................................191 6.2.4 Diseo de Software de Tiempo Real ........................................................................... 196 Ejercicios ..........................................................................................................................200

Conclusin ...........................................................................................................................201

Bibliografa ..........................................................................................................................202

INDICE DE FIGURAS
PGINA 1.1 Elementos bsicos de control en un modelo de sistema .................................................12 1.2 Sistema en lnea ...............................................................................................................16 1.3 Sistema de tiempo real .....................................................................................................18 1.4 Sistema Ligtyear de apoyo a la toma de decisiones ........................................................20 1.5 Modelo de planeacin estratgico basado en el anlisis de brecha de posicin .............21 1.6 Jerarqua de los sistemas de procesamiento de informacin. .........................................21 1.7 Modelo de planeacin estratgica basado en la fuerza del mercado ...............................23 1.8 Actividades para desarrollar e implantar un sistema de informacin ...............................27 1.9 Tiempo empleado en el mantenimiento de sistemas ........................................................24 1.10 Consumo de recursos a lo largo de la vida del sistema..................................................26 2.1 Era de la historia de la ingeniera de software ....................................................................44 2.2 Curva de fallas para el hardware .......................................................................................47 2.3 Curvas de fallas del software (idealizada) ........................................................................48 2.4 Curva real de fallos del software .......................................................................................48 2.5 Impacto del cambio ............................................................................................................51 2.6 Configuracin del software ................................................................................................52 2.7 Capas de la ingeniera de software ...................................................................................53 2.8 Marco de trabajo del proceso de software .........................................................................57 2.9 Relacin entre elementos del proceso del software .........................................................58 2.10 Niveles de madurez del proceso del software ...............................................................61 3.1 Smbolos bsicos de un diagrama de flujo .......................................................................66 3.2 Diagrama de flujo de datos en nivel 0 y nivel 1 ................................................................69 3.3 Igualacin del diagrama de flujo nivel 0 y el de contexto .................................................70 3.4 Diagrama de flujo de datos nivel 0 para un sistema mdico facturado ............................72 3.5 Diagrama de flujo de datos nivel , particionado del proceso PREPARARFACTURA .......... ....................................................................................................................................73 3.6 Pasos a seguir en un diagrama de flujo de datos .............................................................74 3.7 Pasos para construir un diccionario de datos ...................................................................78 3.8 Tarjeta de DD para el proceso denominado VERIFICAR-EXAMEN-Y-CALCULARTARIFAS .................................................................................................................................80 3.9 Tarjeta del DD para el flujo de datos denominado TRIFA- VALIDA ................................80 3.10 Tarjeta del DD para el almacenamiento de datos denominado TARIFAS .....................81 3.11 Tarjeta del DD para la estructura de datos PACIENTE-FACTURA ...............................81 3.12 Tarjeta del DD para el dato elemental denominado CIA-SEGURO ...............................82 3.13 Tarjeta del DD para el dato elemental NUMERO-DE-PACIENTE .................................83 3.14 Longitud de los campos se determinan en la constitucin del DD ................................83 3.15 Diseo de mdulos .........................................................................................................85 3.16 Ejemplo de la descomposicin de un diagrama de flujo de datos (DFD) .......................86 3.17 Ejemplo de los atributos de un objeto de la clase Automviles ......................................87

3.18 Los atributos compartidos de los objetos se agrupan en la clase ..................................88 3.19 Ejemplo de la informacin que puede ser enviada por un objeto de una clase a otro ....... ....................................................................................................................................88 3.20 Mensaje de un objeto hace que otro objeto de una clase diferente cambie uno de sus atributos...................................................................................................................................89 3.21 Ejemplo de herencia de atributos de una clase madre por una clase hija .....................90 3.22 Ejemplo de polimorfismo entre clases relacionadas .......................................................91 3.23 Capas de anlisis orientado a objetos ............................................................................91 3.24 Notacin que representa los conceptos Clase, Objeto y Objeto y Clase .......................92 3.25 Ejemplo de estructura Gen-spec ....................................................................................94 3.26 Ejemplo de la estructura Todo-partes .............................................................................94 3.27 Ejemplo de dos clases y sus atributos respectivos ........................................................95 3.28 Diagrama de estado, de una variable de estado para carros de tren en un sistema de monorriel .................................................................................................................................96 3.29 elementos de diseo O-O agrupados en componentes y capas ....................................97 3.30 Componentes del manejo de tareas del anlisis y diseo O.O ......................................99 3.31 Diseo de una clase y objeto, servidor, objetos ...........................................................100 3.32 Ejemplo parcial de una clase almacenada ...................................................................100 3.33 Notacin de diseo de herencia comparativo de cinco autores diferentes de anlisis y diseo O.O ............................................................................................................................101 4.1 Esquema bsico de modelo cascada .............................................................................105 4.2 Modelo en espiral tpico ..................................................................................................108 4.3 Modelo en espiral con todas sus etapas.........................................................................111 4.4 Desarrollo de los primeros sistemas ...............................................................................113 4.5 Tiempo de calendario de proyecto ..................................................................................114 4.6 Seguimiento de los incrementos .....................................................................................114 4.7 Modelo del proceso unificado (UP) .................................................................................119 4.8 Principales productos de trabajo producidos para cada fase del UP .............................119 4.9 Evolucin proceso personal de software ........................................................................122 4.10 Elementos del PSP en CMM ........................................................................................123 4.11 Procesos de mejora continua .......................................................................................124 5.1 Pasos para la planeacin de una entrevista ...................................................................128 5.2 Decisiones de la estructura de la entrevista ...................................................................130 5.3 Ejemplo de preguntas abiertas en la entrevista ..............................................................130 5.4 Ejemplo de preguntas cerradas en la entrevista ............................................................131 5.5 Ejemplo de preguntas bipolares en la entrevista ............................................................131 5.6 Atributos de las preguntas abiertas y de las preguntas cerradas ...................................132 5.7 Estructura piramidal para la entrevista ...........................................................................133 5.8 Estructura de embudo para la entrevista .......................................................................134 5.9 Estructura de diamante para la entrevista ......................................................................135 5.10 Tipo de informacin que se exploran por medio de cuestionarios ...............................136 5.11 Ejemplo de preguntas abiertas utilizadas en los cuestionarios ....................................138 5.12 Ejemplo de preguntas cerradas en los cuestionarios ...................................................139 5.13 Utilizacin del crculo para la respuesta .......................................................................142 5.14 Tipo de informacin obtenida durante la investigacin.................................................143 5.15 Preguntas de forma oficial y extraoficial que ya se encuentren llenas .........................148 5.16 Anlisis de los memorndums que orientan a la organizacin ....................................149

5.17 Revelacin de los valores, las actitudes y las creencias de los miembros de las organizaciones, respecto al uso de la informacin ...............................................................150 5.18 Manual de polticas .......................................................................................................151 5.19 Ventajas y desventajas en el uso de informacin de archivo para el analista de sistemas ..................................................................................................................................151 5.20 Tipo de informacin cuando se observa la conducta del tomador de decisiones .............. ..................................................................................................................................151 5.21 Resumen de las caractersticas de los elementos STORE ..........................................155 5.22 escala tipo likert utilizados para examinar con ESTORE .............................................157 5.23 Lista anecdtica con smbolos utilizada en la aplicacin del STORE ..........................158 5.24 Enfoques del CASE ......................................................................................................159 5.25 Instrumentos del CASE para las etapas del ciclo de desarrollo de los Sistemas .............. ..................................................................................................................................161 5.26 Ventajas de la utilizacin de las tecnologas del ambiente ...........................................162 5.27 Desventajas de la utilizacin de las tecnologas del ambiente .....................................163 5.28 Tipos de informacin buscada durante el desarrollo de prototipos ..............................169 5.29 Prototipo de remedio .....................................................................................................170 5.30 Prototipo no funcional puede indagar sobre la opinin de los usuarios sobre .................. interfaces (Entrada/ Salida) ..........................................................................................171 5.31 Primer modelo a escala completa .................................................................................172 5.32 Modelo que cuenta con ciertas caractersticas esenciales ...........................................173 5.33 Enfoque tradicional del ciclo de vida del desarrollo de sistema en ocasiones llega a tener desventajas ..................................................................................................................174 5.34 Factores que determinan si un sistema es ms o menos conveniente para desarrollarse a partir de un prototipo ..........................................................................................................175 5.35 Lineamientos principales para el desarrollo de prototipos ............................................176 5.36 Desventajas y ventajas del desarrollo de prototipos .....................................................178 6.1 Modularidad y costo del software ..................................................................................182 6.2 Arquitectura de la descomposicin modular .................................................................182 6.3 Arquitectura de dominios especficos (DSSA) ................................................................184 6.4 Modelo de compilador .....................................................................................................185 6.5 Modelo OSI, modelo en capas para sistemas de comunicacin ....................................185 6.6 Arquitectura del diseo de software multiproceso ..........................................................187 6.7 Arquitectura cliente/servidor ...........................................................................................189 6.8 Creacin de un software de arquitectura cliente/servidor...............................................190 6.9 Arquitectura de software distribuido ................................................................................192 6.10 Arquitectura en tiempo real ...........................................................................................196

INDICE DE TABLAS

PGINA

1.1 Hoja de clculo financiero que calcula las ganancias de un departamento de una organizacin .........................................................................................................................19

2.1 Lenguajes utilizados en cada era de la historia de la ingeniera de software .................... .......................................................................................................................................44 2.2 Cronograma de estndares y modelos para la calidad del software .............................59 2.3 Niveles de madurez del proceso del software ...............................................................61

5.1 Balance general de la corporacin ...............................................................................144

CONCEPTOS INTRODUCTORIOS

1.1 INTRODUCCIN A LOS SISTEMAS 1.1.1 DESCRIPCIN GENERAL 1.1.2 TIPOS 1.1.3 CLASIFICACIN

1.2 CICLO DE VIDA DE UN PROYECTO DE SOFTWARE 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 PLANIFICACIN Y GESTIN DEL PROYECTO DETERMINACIN DE REQUERIMIENTOS ANLISIS Y DISEO PROGRAMACIN PRUEBAS E IMPLEMENTACIN

1.1

INTRODUCCIN A LOS SISTEMAS

No se puede decir mucho acerca del anlisis de sistemas hasta que se tenga una idea clara de lo que es un sistema. Existe una definicin oficial en el diccionario, que parecer algo abstracto, sin embargo hay muchos usos comunes del trmino que le sern familiares y existen muchos tipos comunes de sistemas con los que tenemos contacto todos los das. El analista de sistemas esta mas familiarizado y enfocado con los diferentes tipos de sistemas de sistemas de informacin computarizado, tal vez se puede estar haciendo un sistema de nomina que forma parte de un sistema de recursos humanos, que a su vez forma parte de alguna organizacin (que en s, es un sistema), que a su vez es parte de un sistema econmico mayor, etc., o bien se puede estar haciendo un sistema de control de procesos que es parte de una refinera qumica o un sistema operativo que sea parte de un paquete de software suministrado por el proveedor. Muchos de los sistemas computarizados que se construyen son reemplazados por nuevas versiones de sistemas no computarizados que ya existen. Tambin la mayora de los sistemas computarizados interactan o tienen interfaces con una variedad de sistemas existentes (algunos de los cuales puede estar computarizados y otros no). Aunque muchos tipos de sistemas parezcan bastantes diferentes, resulta que tienen similitud: existen principios, teoras y filosofas comunes que se aplican muy bien, prcticamente a todos los tipos de sistemas. Por ello, frecuentemente se puede aplicar lo aprendido acerca de otros sistemas basndose en la experiencia diaria, y en la de diversos tipos de cientficos e ingenieros a los sistemas que se construye en el campo de la computacin. Por ejemplo, uno de los principios importantes de sistemas, primeramente observando en el campo de la biologa, es conocido como la ley de la especializacin: entre ms adaptado se encuentra un organismo a un ambiente especfico, ms difcil le ser adaptarse a un ambiente diferente. Esto ayuda a explicar la desaparicin de los dinosaurios cuando cambio drsticamente el clima de la tierra, y tambin ayuda a los analistas a entender que si optimizan un sistema computarizado para obtener la mxima ventaja de un procesador, de un lenguaje, de programacin y de un sistema administrador de base de datos, probablemente tendrn grandes dificultades para adaptar dicho sistema de forma que se ejecute en un procesador diferente o con un sistema de administracin de base de datos diferentes. De aqu se comprende algo de la teora general de sistemas, ayudara a entender mejor los sistemas computarizados (automatizados) de informacin. Esto se vuelve cada vez mas importante, pues se desea construir sistemas estables y confiables, que funcionen bien en nuestra compleja sociedad, y existen, desde luego muchos ejemplos de sistemas no computarizados que han sobrevivido durante millones de aos.

10

1.1.1 DESCRIPCIN GENERAL

El Instituto Americano de Estndares Nacionales (ANSI) define a un sistema como: Un conjunto de mtodos, procedimientos o tcnicas unidas por una interaccin regulada para formar un todo organizado. El Comit Tcnico de la Organizacin Internacional para la Estandarizacin (La Internacional Organization for Standardization Technical Committee) tambin define un sistema como: Un conjunto organizado de hombres, mquinas y mtodos que se requieren para lograr un conjunto de funciones especficas. En el sentido ms amplio un sistema es un conjunto de componentes que interaccionan entre s para lograr un objetivo comn. Nuestra sociedad est rodeada de sistemas. Por ejemplo, cualquier persona experimenta sensaciones fsicas gracias a un complejo sistema nervioso formado por el cerebro, la mdula espinal, los nervios y las clulas sensoriales especializadas que se encuentran debajo de la piel; estos elementos funcionan en conjunto para hacer que el sujeto experimente sensaciones de fro, calor, comezn, etc. Las personas se comunican con el lenguaje, que es un sistema muy desarrollado formado por palabras y smbolos que tienen significado para el que habla y para quienes lo escuchan. Asimismo, las personas viven en un sistema econmico en el que se intercambian bienes y servicios por otros de valor comparable y en el que, al menos en teora, los participantes obtienen un beneficio en el intercambio. Una organizacin es un sistema, sus componentes -mercadotecnia, manufactura, ventas, investigacin, embarques, contabilidad y personal- trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los accionistas de la compaa. Cada uno de estos componentes es a su vez un sistema. El departamento de contabilidad, por ejemplo, quiz est formado por cuentas por pagar, cuentas por cobrar, facturacin y auditoria entre otras. Todo sistema organizacional depende, en mayor o menor medida, de una entidad abstracta denominada sistema de informacin. Este sistema es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede ser cualquier cosa, desde la comunicacin interna entre los diferentes componentes de la organizacin y lneas telefnicas hasta sistemas de cmputo que generan reportes peridicos para varios usuarios. Los sistemas de informacin proporcionan servicio a todos los dems sistemas de una organizacin y enlazan todos sus componentes en forma tal que stos trabajen con eficiencia para alcanzar el mismo objetivo. La finalidad de un sistema es la razn de su existencia, por ejemplo, existe un sistema legislativo, para estudiar los problemas que enfrentan los ciudadanos y aprobar la legislacin que los resuelva. El sistema de encendido de un automvil tiene el claro propsito de quemar el combustible para crear la energa que emplean los dems sistemas del automvil. Los sistemas ser dividen en dos por cmo interactan con el medio ambiente. Los que reciben entradas y producen salidas se denominan sistemas abiertos y los que no interactan para nada con el medio ambiente se llaman sistemas cerrados. Todos los sistemas tienen niveles aceptables de desempeo, denominado estndares y contra los que se comparan los niveles de desempeo actuales. Siempre deben anotarse las actividades que se encuentran muy por encima o por debajo de los estndares para poder efectuar los ajustes necesarios. La informacin proporcionada al comparar los resultados con los estndares junto con el proceso de reportar las diferencias a los elementos de control recibe el nombre de retroalimentacin (vase Fig. 1.1).

11

Los sistemas emplean un modelo de control bsico, que consiste en: Un estndar para lograr un desempeo aceptable. Un mtodo para medir el desempeo actual Un medio para comparar el desempeo actual contra el estndar. Un mtodo de retroalimentacin.

Frontera del Sistema

F r o

D e
Entrada

n t e r a
Estndar Salida

s E e n Actual m t p r e a d o a

S a l i

d e l

d a

S
Figura 1.1 Elementos bsicos de control en un modelo de sistemas.

s t e

1.1.2 TIPOS

m a

Existen muchos tipos diferentes de sistemas, de manera que casi todo aquello con lo cual se est en contacto durante la vida cotidiana es un sistema o bien parte de un sistema (o ambas cosas). La gran mayora de los sistemas no estn hechos por el hombre: existen sistemas en la naturaleza. Dado que el objetivo son los sistemas computacionales, estos se dividen en dos categoras: Sistemas Naturales y Sistemas Hechos por el hombre. Se tiene que tomar en cuenta que muchos sistemas hechos por el hombre (sistemas automatizados) interactan con sistemas vivientes: por ejemplo, los marcapasos computarizados interactan con el corazn humano. En algunos casos, se disean sistemas automatizados para reemplazar a sistemas vivos; y en otros, los investigadores consideran a los sistemas vivos como componentes de sistemas automatizados. Los sistemas vivientes y los sistemas hechos por el hombre a menudo forman parte de un metasistema mayor, y entre mas se entienda acerca de ambos, mejores analistas de sistemas habra.

12

Sistemas Naturales.- Sirven a sus propios fines, este a su vez se divide en dos subcategoras bsicas: 1. Sistemas fsicos. Los sistemas fsicos incluyen ejemplos tan variados como: a. Sistemas estelares: galaxias, sistemas solares, etctera. b. Sistemas geolgicos: ros, cordilleras, etctera. c. Sistemas moleculares: organizaciones complejas de tomos. 2. Sistemas vivientes. Es toda la gama de animales y plantas que nos rodean, al igual que la raza humana y esta categora tambin comprende jerarquas de organizacin viviente individuales, por ejemplo hierbas, manadas, tribus, grupos sociales, compaas y naciones. Miller argumenta que los sistemas vivos, sean estos a nivel celular, de rgano, de organismo, de grupo, de organizacin, de sociedad o de sistema supranacional, contienen los siguientes subsistemas: a. El reproductor.-Es capaz de dar origen a otros sistemas similares a aquel en el cual se encuentran. En una organizacin de negocios, pudiera ser una divisin de plantacin de instalaciones que hacen nuevas plantas y construye oficinas regionales nuevas. b. La frontera.- Mantiene unidos a los componentes que conforman el sistema, los protege de tensiones ambientales y excluye o permite la entrada de diversos tipos de materiaenerga e informacin. En una organizacin de negocios, esto pudiera constituir la planta misma (edificio de oficinas, fbricas, etc.) y los guardias u otro personal de seguridad que evitan el ingreso de intrusos indeseables. c. El inyector.-Transporta la materia-energa a travs de la frontera del sistema desde el medio ambiente. En una organizacin de negocios, este pudiera ser el departamento de compras o recepcin, que introduce a la materia prima, los materiales de oficina, etc. O pudiera ser el departamento de pedidos, que recibe pedidos verbales o por escrito de los servicios o productos de la organizacin. d. El distribuidor.-Trae materia desde el exterior del sistema y lo reparte desde sus subsistemas a cada componente. En una organizacin de negocios, pudiera estar conformado por las lneas telefnicas, correos electrnicos, mensajeros, bandas y una variedad de otros mecanismos. e. El convertidor.-Cambia ciertos materiales que ingresan al sistema a formas ms tiles para los procesos especiales de dicho sistema particular. Nuevamente, se puede imaginar un buen nmero de ejemplos de esto en una organizacin de negocios tpica. f. El productor.-Forma asociaciones estables durables por periodos significativos con la materia-energa que ingresa al sistema o que egresa de su convertidor. Estos materiales sintetizados puede servir para crecimiento, reparacin de daos o reposicin de componentes de sistema, o bien para proveer energa para mover o constituir los productos o la informacin de mercado a su suprasistema. g. El subsistema de almacenamiento de materia-energa.-Retiene en el sistema, durante diferentes periodos, depsitos de diversos tipos de materia-energa. h. El expulsor.- Transmite materia-energa al exterior del sistema en forma de desechos o de productos. i. El motor.-Mueve el sistema o a sus partes en relacin con todo o parte del medio ambiente, o bien que mueve a los componentes de ambiente. j. El soporte.- Mantiene las relaciones especiales apropiadas entre los componentes del sistema, de manera que puedan interactuar sin ser un lastre o estorbo entre ellos.

13

k. El transductor de entrada.-Trae seales portadoras de informacin al sistema transformndolas en otras forma de materia-energa adecuada para su transmisin al interior. l. El transductor interno.- Recibe de otros subsistemas o componentes del sistema seales de portan informacin acerca de alteraciones significativas en dichos subsistemas o componentes, transformndolos en otras formas de materia-energa transmisibles en su interior. m. El canal y la red,.- Estn compuestos por una sola ruta en el espacio fsico, o bien por mltiples rutas interconectadas, mediante las cuales las seales portadoras de informacin se transmiten a todas las partes del sistema. n. El decodificador.- Altera las claves de informacin que le es introducida por medio del transductor de entrada o del transductor interno, para dejar una clave privada que pueda ser utilizada internamente por el sistema. o. El asociados.- Lleva a cabo la primera etapa del proceso de aprendizaje, formando asociaciones duraderas entre elementos de informacin dentro del sistema. p. La memoria.- Lleva a cabo la segunda etapa del proceso de aprendizaje, almacenando diversos tipos de informacin en el sistema durante diferentes periodos. q. El que decide, que recibe informacin de todos los dems subsistemas y les transmite informacin que sirve para controlar al sistema completo. r. El codificador.- Altera la clave de informacin que se le introduce desde otros subsistemas procesadores de informacin, convirtindola, de una clave privada utilizada internamente por el sistema, en una clave publica que pueda ser interpretada por otros sistemas en su medio ambiente. s. El transductor de salida.- Emite seales portadoras de informacin desde el sistema, transformando los marcadores dentro del sistema en otras formas de materia-energa que puedan ser transmitidas por medio de canales en el medio ambiente del sistema. Sistemas hechos por el hombre.- Un buen nmero de sistemas son construidos, organizados y mantenidos por humanos, e incluyen: 1. Sistemas Sociales.- Organizaciones de leyes, doctrinas, costumbres, etctera. 2. Una coleccin organizada y disciplinada de ideas.- El sistema decimal Dewey de organizacin de libros en bibliotecas, el sistema de reduccin de los cuida-kilos, etctera. 3. Sistemas de Transporte.- Redes de carreteras, canales, aerolneas, buques cargueros, etctera. 4. Sistemas de Comunicacin.- Telfono, telex, utilizadas por los corredores de bolsa, etctera. seales de humo, seales de mano

5. Sistemas de Manufactura.- Fbricas, lneas de ensamblado, etctera. 6. Sistemas Financieros: contabilidad, inventarios, libro mayor, bolsa de valores, etctera. En la actualidad, la mayora de estos sistemas incluyen las computadoras; de hecho, muchos no podran sobrevivir sin ellas. Sin embargo, es igualmente importante sealar que dichos sistemas existan antes de que hubiera computadoras. El que un sistema de factura humana deba o no ser computarizado no es algo que se deba dar por hecho.

14

La labor del analista de sistemas ser analizar o estudiar el sistema para determinar su esencia que es su comportamiento requerido, independientemente de la tecnologa utilizada para implantar el sistema. En la mayora de los casos, se pude determinar si tiene sentido utilizar una computadora para llevar a cabo las funciones del sistema slo tras haber modelado su comportamiento esencial. Por ejemplo, la frase comn, Juan tiene un sistema para llevar a cabo su trabajo o vaya que Mara tiene una manera sistemtica de hacer su trabajo. Tales frases no necesariamente sugieren que Mara ha computarizado su trabajo o que Juan ha utilizado algunos de los instrumentos formales de modelacin para hacer su trabajo. Pero ciertamente las frases implican que Juan y Mara han dividido su trabajo en una serie de pasos definidos, la suma acumulativa de los cuales lograr algn propsito general. Por qu no debieran automatizarse algunos sistemas de procesamiento de informacin? Puede haber muchas razones; las ms comunes:

1. Costo.- Puede ser ms barato continuar llevando a cabo las funciones y almacenando la informacin del sistema en forma manual. No siempre es cierto que las computadoras sean ms rpidas y econmicas que el mtodo antiguo. 2. Conveniencia.- Un sistema automatizado puede ocupar demasiado espacio, hacer demasiado ruido, generar demasiado calor o consumir demasiada electricidad, o bien, en general, ser una molestia. Esto va dejando de ser as con la creciente influencia de los microprocesadores, pero sigue siendo un factor a considerar. 3. Seguridad.- Si el sistema de informacin mantiene datos confidenciales, el usuario pudiera no creer que el sistema automatizado sea lo suficientemente seguro; tal vez desee mantener la informacin fsicamente protegida y bajo llave. 4. Facilidad de Mantenimiento.- El usuario pudiera argumentar que un sistema de informacin computarizada sera costeable, excepto por el hecho de que no hay ningn miembro del personal que pudiera encargarse del mantenimiento del hardware y/o el software de la computadora, de manera que nadie podra reparar el sistema si ste sufriera un desperfecto, ni habra quien pudiera efectuar cambios o mejoras. 5. Polticas.- La comunidad usuaria pudiera recelar que las computadoras amenazan con privarla de sus empleos o con volver aburridos o mecnicos sus trabajos o con una docena de otras razones que el analista de sistemas podra considerar irracionales. Pero dado que se trata del sistema del usuario, sus recelos son de primera importancia. Si no desean tener un sistema automatizado, harn todo lo posible por lograr que falle si se les quiere imponer.

Sistemas automatizados Son sistemas hechos por el hombre que interactan con o son controlados por una o ms computadoras. Una manera de ordenar por categoras los sistemas automatizados es por su aplicacin: sistemas de manufactura, sistemas de contabilidad, sistema de defensa militar, etc. Sin embargo las tcnicas para analizar, modelar, disear e implantar sistemas automatizados generalmente son las mismas, independientemente de su aplicacin. Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener componentes en comn que son el hardware y software: ________________________________
1

Dispositivo electrnico o electromecnico de hardware, usado para introducir o mostrar datos de un computador o de un sistema de computacin

15

Una divisin en categoras ms til de los sistemas automatizados es la siguiente: 1.- Sistemas en lnea En 1972, Yourdon defini los sistemas en lnea de la siguiente forma: Un sistema en lnea es aquel que acepta material de entrada directamente del rea donde se cre. Tambin es el sistema en el que el material de salida, o el resultado de la computacin, se devuelven directamente a donde es requerido. Esto significa que el sistema computacional tiene una arquitectura de hardware parecida a la figura 1.2. Una caracterstica comn de los sistemas en lnea es que entran datos a la computadora o se les recibe de ella en forma remota. Es decir, los usuarios del sistema computacional normalmente 1 interactan con la computadora desde terminales que pueden estar localizadas a cientos de kilmetros de la computadora misma. Otra caracterstica de un sistema en lnea es que los datos almacenados, es decir, sus archivos o su base de datos, usualmente se organizan de tal manera que los componentes individuales de informacin (registro individual o un expediente individual) puedan ser recuperadas modificados o ambas cosas rpidamente y sin tener necesariamente que efectuar accesos a otros componentes de informacin del sistema. Esto contrasta enormemente con los sistemas fuera de lnea o en lotes (batch), que eran ms comunes en las dcadas de los aos 60 y 70. En un sistema computacional por lotes, la informacin suele recuperarse de una manera secuencial, lo cual significa que el sistema computacional lee todos los registros de la base de datos, procesando y actualizando aquellos para los cuales haya actividad. Dado que un sistema en lnea interacta directamente con personas (usuarios humanos en sus terminales) es importante que el analista de sistemas planee cuidadosamente la interfaz humanocomputadora. Es decir, el analista debe tener alguna manera de modelar, esto es, de crear modelos de todos los posibles mensajes que el usuario humano puede teclear en su terminal, y de todas las respuestas que el sistema pudiera dar, adems de todas las respuestas que pudiera dar el humano ante las respuestas de la computadora, etc. Esto usualmente se lleva a cabo identificando todos los estados en los que la computadora y el usuario pudieran encontrarse, e identificando todos los cambios de estado. Un ejemplo de un estado en el que pudiera encontrase una computadora de un sistema de un cajero automtico es el usuario ha insertado su tarjeta y se ha identificado.
La informacin se teclea desde el lugar de origen

Los datos se organizan de modo que se puedan recobrar fcilmente Procesador

La salida se transmite a donde es requerida

Figura 1.2.-Sistema en lnea.

16

A menudo se hace referencia a esto como dialogo hombre-mquina, o interfaz hombre maquina. Cada vez son ms las organizaciones de desarrollo de sistemas que utilizan la expresin interfaz humano-computadora o, simplemente, interfaz humana. Dado que los sistemas en lnea por lo comn requieren recuperar datos con rapidez (para poder responder a preguntas y rdenes provenientes de terminales en lnea), suele ser muy importante disear los archivos y bases de datos de la manera ms eficiente posible. A menudo las operaciones de computacin llevadas a cabo por un sistema en lnea suelen ser relativamente triviales, mientras que los datos (sobre todo, la estructura y organizacin de los datos mantenida por el sistema en lnea) suelen ser bastante complejos. La decisin de convertir o no un sistema ordinario en un sistema en lnea son, en el contexto de este libro, una decisin de puesta en prctica, es decir, no es algo que debiera ser determinado por el analista de sistemas sino ms bien por las personas que ponen en prctica el sistema. Sin embargo, dado que decidir tal cosa tiene un impacto tan obvio en el usuario (la presencia o ausencia de terminales de computadora, etc.) es una decisin de puesta en prctica en la cual habitualmente los usuarios querrn participar. Sistema de tiempo real Es aquel que controla un ambiente recibiendo datos, procesndolos y devolvindolos con la suficiente rapidez como para influir en dicho ambiente en ese momento. Ciertamente, existen muchos sistemas en lnea (sistemas bancarios, de reservaciones areas y sistemas de bolsa) que se espera reaccionen en uno o dos segundos a un mensaje tecleando en la terminal. Sin embargo, en la mayora de los sistemas de tiempo real, la computadora debe reaccionar en milisegundos y a veces en microsegundos a los estmulos que recibe. Esto es caracterstico de los siguientes tipos de sistemas: 1. Sistemas de control de procesos.- Sistemas computacionales que se utilizan para verificar y controlar refineras, procesos qumicos, molinos y operaciones de maquinado. 2. Sistemas de cajeros automticos.- Las maquinas de efectivo que muchos de nosotros usamos para hacer depsitos y retiros sencillos en el banco. 3. Sistemas de alta velocidad para adquisicin de datos.- Sistemas computacionales que obtienen datos de telemetra a alta velocidad de satlites de rbita o las computadoras que capturan cantidades enormes de datos de experimentos de laboratorio. 4. Sistemas de gua de proyectiles.- Sistemas computacionales que deben rastrear la trayectoria de un proyectil y hacer ajustes continuos a la orientacin y empuje de los propulsores. 5. Sistemas de conmutacin telefnica.-Sistemas computacionales que controlan la transmisin de voz y datos en miles de llamadas telefnicas, detectando los nmeros marcados, condiciones de ocupado y todas las dems condiciones de una red telefnica tpica. 6. Sistemas de vigilancia de pacientes.-Sistemas computacionales que detectan los signos vitales de diversos pacientes (por ejemplo, temperatura y pulso) y que son capaces ya sea de ajustar el medicamento administrado o de hacer sonar la alarma si los signos vitales se mantienen fuera de ciertos lmites predeterminados. Adems de la velocidad, existe otra caracterstica que diferencia a los sistemas de tiempo real de los sistemas en lnea: estos ltimos suelen interactuar con las personas, mientras que los sistemas de tiempo real usualmente interactan tanto con personas como con un ambiente que en generalmente es autnomo y a menudo hostil. La principal preocupacin del analista de sistemas en tiempo real es que, si la computadora no responde con la suficiente rapidez, el ambiente pudiera quedar fuera de control, los datos de entrada pudieran perderse sin remedio o un proyectil

17

pudiera salirse de su trayectoria tanto que ya no fuera posible recuperarlo, o bien que un proceso 2 de manufactura pudiera explotar . En cambio, un sistema en lnea que no responda con la suficiente rapidez en general no har ms que volver impaciente y gruones a sus usuarios. Esto se ilustra en la figura 1.3.

Figura 1.3.- Sistema de tiempo real.

Un analista que trabaja en sistemas de tiempo real generalmente estar muy pendiente por el comportamiento dependiente del tiempo que el sistema tenga. Desde un punto de vista de la puesta en prctica, los sistemas de tiempo real (as como algunos sistemas en lnea) se caracterizan por lo siguiente: 1. Simultneamente se lleva a cabo el proceso de muchas actividades. 2. Se asignan prioridades diferentes a diferentes procesos: algunos requieren servicio inmediato mientras que otros pueden aplazarse por periodos razonables. 3. Se interrumpe una tarea antes de concluirla, para comenzar otra de mayor prioridad. 4. Existe gran comunicacin entre tareas, especialmente dado que muchas tratan diferentes aspectos de un proceso general, como el control de un proceso de manufactura. 5. Existe acceso simultneo a datos comunes, tanto en memoria como en el almacenamiento secundario, por lo cual se requiere de un elaborado proceso de sincronizacin y semforos para asegurar que los datos comunes no se corrompan. Sistemas de apoyo a decisiones y sistemas de planeacin estratgica La mayor parte de los sistemas automatizados de informacin que se crearon durante los ltimos 30 aos son sistemas operacionales que ayudan a llevar a cabo los detalles del trabajo cotidiano de una organizacin, tambin se conocen como sistemas de procesamiento de transacciones como por ejemplo los sistema de nmina, de contabilidad y de manufactura. Sin embargo, dado que los sistemas operacionales actuales continan tambalendose, muchas organizaciones se estn enfocando a un nuevo tipo de sistemas: los de apoyo a la toma de decisiones.

18

Como lo implica el trmino, estos sistemas computacionales no toman decisiones por s mismos, sino ayudan a los administradores y a otros profesionistas trabajadores del conocimiento de una organizacin a tomar decisiones inteligentes y documentadas acerca de los diversos aspectos de la operacin. Estos sistemas son pasivos en el sentido de que no operan en forma regular, se utilizan de manera a propsito, cuando se les necesita. Existe un gran nmero de ejemplos sencillos de sistemas de apoyo a decisiones: programas de hoja de clculo, sistemas de anlisis estadstico, programas de pronstico de mercados, etc. Una caracterstica comn de los sistemas de apoyo a decisiones es que no slo recuperan y exhiben los datos, sino que tambin realizan varios tipos de anlisis matemticos y estadsticos de los mismos. Los sistemas de apoyo a decisiones tambin tienen la capacidad, en la mayora de los casos, de presentar la informacin en una variedad de formas grficas (tablas, grficos, etc.) al igual que en forma de reportes (informes) convencionales. En la tabla 1.1 se muestra una hoja de clculo financiera caracterstica que pudiera utilizar un gerente para evaluar las ganancias de alguna divisin dentro de su organizacin; De cualquier forma que se muestre el resultado, la informacin de salida producida por el sistema no toma una decisin, sino que provee informacin relevante para que el gerente pueda decidir. Proyeccin de prdidas y ganancias de la compaa C1 400 100 125 10 535 123 100 15 15 20 5 10 10 12 5 315 220 C2 425 150 60 10 645 148 120 18 15 20 6 10 10 13 5 365 280 C3 250 200 50 15 515 118 120 18 15 20 5 10 15 13 5 339 176 C4 375 125 25 10 535 123 125 19 18 20 7 10 10 14 5 351 184 TOTAL 1450 575 160 45 2230 513 465 70 63 80 23 40 45 52 20 1371 859

Venta Nacional Venta Internacional Ingresos diversos TOTAL DE INGRESOS Costo de venta Salarios Otros gestos de empleo Renta Telfono Correos Viajes/diversos Contabilidad/asuntos legales Depreciacin Gastos diversos TOTAL DE GASTOS GANACIA/PERDIDA

Tabal 1.1.- Hoja de clculo financiero que calcula las ganancias de un departamento de una organizacin.

Algunos sistemas de apoyo a decisiones son tiles para articular y mecanizar las reglas utilizadas para llegar a alguna decisin de negocios. Uno de estos sistemas es un programa llamado Lightyear (de Lightyear, Inc.) que se ejecuta en computadoras personales compatibles con IBM. Permite al usuario (o a mltiples usuarios) describir los detalles de un problema que requiera decisiones; un ejemplo podra ser el problema de decidir en dnde ubicar una nueva oficina. primeramente el usuario identifica los criterios que se utilizarn para tomar la decisin. Para el problema de ubicar una nueva oficina esto pudiera incluir, por ejemplo, que debe ser accesible en transporte pblico y que no debe estar en una zona de alta probabilidad ssmica. Algunos de los criterios son binarios, en el sentido de que si no se satisface uno de ellos, se elimina una alternativa o se ocasiona la seleccin automtica de otra. La mejor alternativa automticamente ser seleccionada por el programa Lightyear. La figura 1.4 ilustra este proceso.

19

Identificar alternativas

Establecer criterios de evaluacin

Clasificar las alternativas de acuerdo con los criterios

Elegir lo ms adecuado
Figura 1.4.-Sistema Lightyear de apoyo a la toma de decisiones

Sistemas de planeacin estratgica Son utilizados por los gerentes en jefe para evaluar y analizar la misin de la organizacin. En lugar de dar consejos acerca de alguna decisin de negocios aislada, estos sistemas ofrecen consejos ms amplios y generales acerca de la naturaleza del mercado, las preferencias de los consumidores, el comportamiento de la competencia, etc. Los sistemas de planeacin estratgica no son programas de computadora en s; son complejas combinaciones de actividades y procedimientos, muchas de los cuales las llevan a cabo humanos utilizando informacin obtenida de fuentes externas (estudios de mercado, etc.) y datos internos de los sistemas operacionales de la organizacin y los sistemas de apoyo a decisiones. Steiner seala que hay muchos tipos de sistemas de planeacin estratgica, segn el tamao y naturaleza de la organizacin. La figura 1.5 muestra el sistema de planeacin estratgica basada en el anlisis de brecha de posicin trata de identificar la discrepancia entre la posicin actual de la organizacin (en trminos de ganancias, rentabilidad, etc.) y la posicin deseada por la gerencia, los accionistas y otros. Existente entre los tres distintos tipos de sistemas vistos. Como lo muestra la figura 1.6, los sistemas operacionales representan la base sobre la cual se basa los sistemas de apoyo a decisiones y de planeacin estratgica.

__________________________
2.-

Uno de los ejemplos ms interesantes de una situacin de tiempo real es el de un equipo de trabajo cuya misin era unir una pequea computadora a una bomba nuclear. Cuando se detonara la bomba (como parte de un programa de pruebas), la computadora dispondra tan solo de unos cuantos microsegundos para capturar tanto los datos como fuera posible y transmitirlos a un sistema de computadoras remoto, antes de que se desintegraran el hardware y software por la explosin. Esa s que es una real exigencia del procesamiento en tiempo real.

20

Figura 1.5.-Modelo de planeacin estratgica basado en el anlisis de brecha de posicin.

Los sistemas operacionales crean los datos requeridos por los sistemas de nivel superior y continan actualizando los datos de una manera continua. La forma piramidal de la figura representa otra caracterstica tpica de los sistemas de informacin que se pueden encontrar en la mayora de las organizaciones hoy en da: el tamao de los sistemas operacionales (medidos en aos-persona, o en millones de instrucciones) excede por mucho al de los sistemas de apoyo a la toma de decisiones y al de los sistemas de planeacin estratgica. La mayor parte de la labor que se lleva a cabo actualmente en algunas organizaciones importantes consiste en el desarrollo de sistemas de apoyo a la toma de decisiones y de sistemas de planeacin estratgica.

Figura 1.6.- Jerarqua de los sistemas de procesamiento de informacin.

21

La planeacin estratgica es un concepto que se hizo popular durante la segunda guerra mundial (aunque algunas organizaciones obviamente la practicaron desde mucho antes) y es tema de muchos libros. Los sistemas de planeacin estratgica no son programas de computadora en s; son complejas combinaciones de actividades y procedimientos, muchas de las cuales las llevan a cabo humanos utilizando informacin obtenida de fuentes externas (estudios de mercado, etc.) y datos internos de los sistemas operacionales de la organizacin y los sistemas de apoyo a decisiones. Existen muchos tipos de sistemas de planeacin estratgica, segn el tamao y naturaleza de la organizacin.

Sistemas basados en el conocimiento. Un trmino relativamente novedoso en la industria de las computadoras es el de sistemas expertos o sistemas basados en el conocimiento. Dichos sistemas se asocian con el campo de la inteligencia artificial, la cual Elaine Rich defini de la siguiente manera: La meta de los cientficos de la computacin que trabajan en el campo de la inteligencia artificial es producir programas capaces de imitar el desempeo humano en una gran variedad de tareas inteligentes. Para algunos sistemas expertos la meta est prxima a ser alcanzada; para otros, aunque an no sabemos construir programas que funcionen bien por s solos, podemos comenzar a crear programas capaces de auxiliar a las personas en la ejecucin de alguna tarea. Dos eminentes autores en el campo de la inteligencia artificial, Feigenbaum y McCorduck, describen los sistemas basados en el conocimiento y los sistemas expertos de la siguiente manera: Los sistemas basados en el conocimiento, por decir lo obvio, contienen grandes cantidades de diversos conocimientos que emplean en el desempeo de una tarea dada. Los sistemas expertos son una especie de sistema basado en el conocimiento, aunque ambos trminos a menudo se utilizan indistintamente. Se construyen de tal manera que sean capaces de explicar las lneas de razonamiento que llevaron a las decisiones que tomaron. Algunos de ellos pueden incluso explicar por qu descartaron ciertos caminos de razonamiento y por qu escogieron otros. Esta transparencia es una caracterstica primordial de los sistemas expertos. Los diseadores trabajan arduamente para lograrla, pues comprenden que el uso que se le dar al sistema experto depender de la credibilidad de que disfrute por parte de los usuarios, y la credibilidad surgir debido a un comportamiento transparente y explicable. An se piensa en los sistemas expertos como una especie de sistemas especializados, que utilizan hardware especial y lenguajes especiales, como LISP y PROLOG. Sin embargo, han comenzado a aparecer sistemas expertos sencillos, para computadoras personales estndar, y cascarones de sistemas expertos, que son estructuras de software para el desarrollo de aplicaciones especficas de sistemas expertos.

Principios de sistemas generales Todos los ejemplos expuestos tienen una cosa en comn: todos son sistemas. Mientras que pueden diferir en varias cosas, tambin poseen muchas caractersticas comunes. El estudio de dichas caractersticas comunes se conoce como teora general de sistemas y existen algunos principios generales que son de inters particular para quienes crean sistemas automatizados de informacin, e incluyen los siguientes: 1. Entre ms especializado sea el sistema, menos capaz es de adaptarse a circunstancias diferentes. Entre ms general sea un sistema, menos ptimo ser para una situacin determinada; pero entre ms ptimo sea, para tal situacin menos adaptable ser a nuevas circunstancias.

22

2. Cuanto mayor sea el sistema mayor es el nmero de sus recursos que deben dedicarse a su mantenimiento diario. Un pequeo sistema de juguete, del tipo que se puede crear en una sola tarde, por ejemplo, involucrar usualmente muy poca burocracia, mientras que un sistema grande requerir de un esfuerzo enorme en reas tan improductivas como la revisin de errores, la edicin, el respaldo, el mantenimiento, la seguridad, y la documentacin. 3. Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en sistemas menores. Este punto es importante por dos razones: primeramente, sugiere una forma obvia de organizar un sistema computacional que estemos tratando de desarrollar, por el procedimiento de dividirlo en sistemas menores. Pero an ms importante es el hecho de que sugiere que la definicin del sistema que estamos tratando de desarrollar es arbitraria; pudimos haber escogido un sistema ligeramente menor o mayor. Escoger lo que deber abarcar un sistema y definirlo cuidadosamente para que todo mundo conozca su contenido es una actividad importante. 4. Los sistemas crecen. Desde luego, esto pudiera no ser verdad para todos los sistemas pues violara un principio general muy familiar, la ley de la conservacin de la energa. Pero muchos sistemas con los que estamos familiarizados s crecen y resulta importante reconocerlo, pues a menudo omitimos (como analistas y como diseadores de sistemas) tomar esto en cuenta al comenzar a crear el sistema. Un sistema de informacin tpico, crecer hasta el punto de incluir ms software, ms datos, ms funciones y ms usuarios que los que inicialmente habamos planeado.

Figura 1.7.- Modelo de planeacin estratgica basado en la fuerza del mercado.

23

Aunque los sistemas expertos van ms all de los alcances de este libro, gradualmente se convertirn en un componente cada vez ms importante de los sistemas tpicos en los que trabaja un analista de sistemas. A fines de la dcada de los 80, los investigadores comenzaron a estudiar la relacin entre las tcnicas de desarrollo de software clsico y la inteligencia artificial, un estudio tpico es Jacob y Froscher. Keller prev un momento en el futuro cercano en el cual los sistemas de IA y los sistemas expertos formarn parte de la actividad normal del anlisis de sistemas; otros, como Barstow y Lucas y Harandi, prevn que la inteligencia artificial auxiliar a los analistas de sistemas en la documentacin de los requerimientos del usuario para mediados de la dcada de los 90.

1.1.3 CLASIFICACION
Sistemas de Transacciones. Son llamados TPS cuyas siglas corresponden a Transaction Processing System, o sistemas de procesamiento de transacciones. Un ejemplo es la Corporacin Financiera Internacional (CFI), filial del Banco Internacional para la Reconstruccin y el Desarrollo, cuyo sistema de transacciones funciona de la siguiente manera: El CFI busca inversores interesados en los pases ms desarrollados y el capital provedo por stos, es transferido a empresas privadas de pases subdesarrollados cuyo capital privado no basta. Otro ejemplo es el de la industria naviera, el cual por medio de su sistema de transacciones internacionales transportan diferentes tipos de carga de acuerdo a pedidos en diferentes pases, siendo uno de los ms transportados el petrleo, cuyos pedidos pueden ser ya sea privado o por contrato. Los barcos transportan el petrleo desde los campos petrolficos a las refineras, siguiendo una serie de tratados y convenciones internacionales. Sistemas de Conocimiento. KWS, knowledge work system, o sistema de manejo de conocimiento. Un ejemplo es el de aplicaciones como Photoshop, la cual ayuda a diseadores grficos en crear su arte publicitario por medio de poderosas herramientas con las cuales se puede manipular y modificar distintos tipos de grficos y fotografas.

Sistemas Expertos. La inteligencia artificial es un famoso sistema experto para la realizacin de diagnsticos, el cual aconseja a los mdicos en la investigacin y determinacin de diagnsticos en el campo de las enfermedades infecciosas de la sangre. El sistema MYCIN, al ser consultado por el mdico, solicita primero datos generales sobre el paciente: nombre, edad, sntomas, etc. Una vez conocida esta informacin por parte del sistema, el Sistema Experto plantea unas hiptesis. Para verificar la hiptesis el sistema consulta a la base de conocimientos, y tambin haciendo una serie de preguntas al usuario. Con las respuestas que recibe, el MYCIN verifica o rechaza las hiptesis planteadas. Otro sistema experto es el XCON el cual es un sistema experto de configuraciones el cual, segn las especificaciones del cliente, configura redes de ordenadores VAX. Tiene como base de su funcionamiento las siguientes dos preguntas: 1. Pueden conjugarse los componentes solicitados por el cliente de forma conveniente y razonable? 2. Los componentes de sistema especificados son compatibles y completos? Las respuestas a estas preguntas son muy detalladas. XCON es capaz de comprobar y completar los pedidos entrantes mucho ms rpido y mejor que las personas encargadas hasta ahora de esa labor.

24

Sistemas de Apoyo a Grupos. GDSS, group decission support system, o sistemas de apoyo a decisiones de grupo. Un sistema GDSS es el Visin Quest, el cual permite realizar juntas electrnicas. Entre sus ventajas se encuentra su facilidad de uso. Cualquiera puede conducir una junta electrnica y el sistema puede ser usado de manera distribuida. Las juntas se pueden realizar con los participantes en el mismo lugar o diferentes lugares, al mismo tiempo o a distintos tiempos. Aunque no pretende reemplazar las juntas cara a cara, su uso permite reducir los costos de viaje, la rapidez de toma de decisiones lo que resulta en una mejor eficiencia y productividad de las juntas. El sistema funciona en terminales de trabajo que pueden estar o no en el mismo lugar, la interaccin se realiza a travs del teclado y el monitor de la computadora. Otro sistema es el CRUISER cuyas siglas son para Computer Supported Spontaneous Interaction. La importancia de este sistema se basa en la interaccin informal. CRUISER est diseado alrededor del concepto de comunidad o grupo virtual que existe slo en un mundo virtual, donde las distancias geogrficas entre los participantes no son importantes. Por sus caractersticas este sistema provee acceso instantneo a cualquier persona y cualquier lugar. La importancia del sistema est basada en dos ideas. La primera, los usuarios pueden navegar a travs del mundo virtual en bsqueda de encuentros sociales. La segunda, el mundo virtual es independiente del mundo fsico y puede ser organizado de acuerdo a las necesidades del usuario. En la prctica el usuario recorre pasillos, oficinas y reas comunes, todas ellas generadas por computadora. Los usuarios se comunican a travs de audio y video. CRUISER ataca uno de los problemas de los trabajos en equipo, reconoce la importancia de la comunicacin informal. Provee adems caractersticas de la prctica de trabajo permitindole diferentes niveles de privacidad.

Sistema de ejecutivos. Un ejemplo es el sistema comprado por Pratt & Whitney, una corporacin que se dedica a la produccin de motores de propulsin a chorro. Ellos compraron el sistema denominado Commander EIS que permite representaciones a todo color y un men imaginativo que puede aprenderse intuitivamente, con variaciones y excepciones que son destacadas mediante colores. Los usuarios pueden accesar datos mediante una pantalla tctil, ratn o teclado y pueden agrandar las imgenes para mayores niveles de detalle, ya sea navegando por s mismos o siguiendo caminos previamente definidos. El Commnander EIS permite a la organizacin hacer el seguimiento de los parmetros de la calidad y factibilidad de las medidas tomadas para cada motor a reaccin por tipo de cliente. Los datos aparecen de los sistemas actuales de produccin y proporcionan informacin sobre la confiabilidad, disponibilidad de motores y partes, y sobre las entregas. Otro ejemplo es el sistema implantado por la New York State Office of General Services que es responsable de dar servicio a otras dependencias en Nueva York. El sistema permite que los ejecutivos verifiquen el estado por programa, comparando el presupuesto con el gasto real y mostrando el gasto estimado hasta el final del ao fiscal. La administracin puede bajar para ver los detalles especficos en cada categora. El sistema slo contiene datos crudos, permitiendo a los usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus necesidades. El sistema es operado por medio de un men muy fcil de usar. Los nuevos usuarios son capacitados mediante una demostracin que dura media hora, y la experiencia ha demostrado que es todo lo que necesitan. No se cuenta con un manual del usuario.

25

1.2 CICLO DE VIDA DEL SOFTWARE

Describimos la ingeniera de software como una actividad de modelado. Los desarrolladores construyen modelos de los dominios de la aplicacin y la solucin para manejar su complejidad. Al ignorar detalles irrelevantes y enfocarse solo en lo que es relevante para un problema especifico, los desarrolladores pueden resolver en forma ms efectiva los problemas y responder preguntas. El proceso de desarrollo de software tambin puede verse como un sistema complejo con entradas, salidas, actividades y recursos. Por lo tanto, no es sorprendente que las mismas tcnicas de modelado que se aplican a los artefactos de software puedan usarse para los procesos de modelado de software. A un modelo general del proceso de desarrollo de software se le llama ciclo de vida del software. El desarrollo de sistemas, un proceso formado por las etapas de anlisis y diseo, comienza cuando la administracin o algunos miembros del personal encargado de desarrollar sistemas, detectan un sistema de la empresa que necesita mejoras. El mtodo del ciclo de vida para desarrollo de sistemas (SDLC) es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin, vase la figura 1.8. El SDLC es un enfoque por fases del anlisis y diseo que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especfico de actividades del analista y del usuario. Los analistas no estn de acuerdo con qu tantas fases exactas hay en el ciclo de vida del desarrollo de sistemas, pero, por lo general, alaban su enfoque organizado. A continuacin se examinarn cada una de estas actividades que constituyen el ciclo de vida de desarrollo de sistemas. En la mayor parte de las situaciones dentro de una empresa todas las actividades estn muy relacionadas, en general son inseparables, y quiz sea difcil determinar el orden de los pasos que se siguen para efectuarlas. Las diversas partes del proyecto pueden encontrarse al mismo tiempo en distintas fases de desarrollo; algunos componentes en la fase de anlisis mientras que otros en etapas avanzadas de diseo.

El mtodo del ciclo de vida para desarrollo de sistemas consta de las siguientes actividades: 1. 2. 3. 4. 5. Planificacin y gestin del proyecto. Determinacin de los requerimientos del sistema. Anlisis y diseo. Desarrollo de software (programacin). Prueba e implementacin de los sistemas.

26

Investigaci n preliminar

Implantacin

Determinacin de los requerimientos del sistema Prueba del Sistema

Diseo del sistema

Desarrollo del Sistema

Figura 1.8.- Actividades para desarrollar e implantar un sistema de informacin

1.2.1 PLANIFICACIN Y GESTION DE PROYECTOS

Investigacin preliminar En la primera fase del ciclo de vida del desarrollo de sistemas, el analista tiene que ver con la identificacin de problemas, oportunidades y objetivos. Esta etapa es crtica para el xito del resto del proyecto, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. Requiere que el analista observe honestamente lo que est sucediendo en una empresa. Luego, junto con los dems miembros de la organizacin, el analista hace resaltar los problemas; frecuentemente estos ya han sido vistos por los dems, y la razn por la cual el analista fue llamado inicialmente para que puedan ser mejoradas por medio del uso de sistemas de informacin computarizados. El aprovechar las oportunidades puede permitir que la empresa gane un avance competitivo o ponga un estndar de la industria. La identificacin de objetivos es tambin un componente importante de la primera fase. En primer lugar, el analista debe descubrir lo que est tratando de hacer la empresa, luego ser capaz de ver si algn aspecto de la aplicacin de sistemas de informacin puede ayudar para que el negocio alcance sus objetivos atacando problemas especficos u oportunidades.

27

La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones; sin importar cules sean stas, el proceso se inicia siempre con la peticin de una persona administradora, empleada o especialista en sistemas. Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigacin preliminar. Esta actividad tiene tres partes: aclaracin de la solicitud, estudio de factibilidad y aprobacin de la solicitud. Aclaracin de la solicitud. Muchas solicitudes que provienen de empleados y usuarios no estn formuladas de manera clara. Por consiguiente, antes de considerar cualquier investigacin de sistemas, la solicitud de proyecto debe examinarse para determinar con precisin lo que el solicitante desea. Si ste tiene una buena idea de lo que necesita pero no est seguro cmo expresarlo, entonces bastar con hacer una llamada telefnica. Por otro lado, si el solicitante pide ayuda sin saber qu es lo que est mal o dnde se encuentra el problema, la aclaracin del mismo se vuelve ms difcil. En cualquier caso, antes de seguir adelante, la solicitud de proyecto debe estar claramente planteada. Estudio de factibilidad. Un resultado importante de la investigacin preliminar es la determinacin de que el sistema solicitado sea factible. En la investigacin preliminar existen tres aspectos relacionados con el estudio de factibilidad: 1. Factibilidad tcnica. El trabajo para el proyecto, puede realizarse con el equipo actual, la tecnologa existente de software y el personal disponible? Si se necesita nueva tecnologa, cul es la posibilidad de desarrollarla? 2. Factibilidad econmica. Al crear el sistema, los beneficios que se obtienen sern suficientes para aceptar los costos?, los costos asociados con la decisin de no crear el sistema son tan grandes que se debe aceptar el proyecto? 3. Factibilidad operacional. Si se desarrolla e implanta, ser utilizado el sistema?, existir cierta resistencia al cambio por parte de los usuarios que d como resultado una disminucin de los posibles beneficios de la aplicacin?

El estudio de factibilidad lo lleva a cabo un pequeo equipo de personas (en ocasiones una o dos) que est familiarizado con tcnicas de sistemas de informacin; dicho equipo comprende la parte de la empresa u organizacin que participar o se ver afectada por el proyecto, y es gente experta en los procesos de anlisis y diseo de sistemas. En general, las personas que son responsables de evaluar la factibilidad son analistas capacitados o directivos. Aprobacin de la solicitud. No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que slo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo comn es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, la administracin decide qu proyectos son los ms importantes y decide el orden del que se llevarn a cabo. Muchas organizaciones desarrollan sus planes para sistemas de informacin con el mismo cuidado con el que planifican nuevos productos y programas de fabricacin o la expansin de sus instalaciones. Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta informacin se determina dnde ubicarlo dentro de la lista existente de proyectos. Las personas involucradas en la primera fase son los usuarios, analistas y administradores de sistemas que coordinan el proyecto. Las actividades de esta fase consisten en entrevistas a los administradores de los usuarios, sumarizacin del conocimiento obtenido, estimacin del alcance del proyecto y documentacin de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definicin del problema y la sumarizacin de los objetivos. Luego los

28

administradores deben tomar una decisin para ver si continan con el proyecto propuesto. Si el grupo de usuarios no tiene los suficientes fondos en su presupuesto y desea atacar problemas que no estn relacionados, o los problemas no requieren un sistema de cmputo, puede ser recomendada una solucin manual y el proyecto de sistemas ya no contina.

1.2.2 DETERMINACIN DE REQUERIMIENTOS

Las herramientas utilizadas para definir los requerimientos de informacin se encuentran: muestreo e investigacin de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboracin de prototipos. En esta fase el analista est esforzndose por comprender qu informacin necesitan los usuarios para realizar su trabajo. Se puede ver que varios de los mtodos para determinar los requerimientos de informacin involucran la interaccin directa con los usuarios. Esta fase sirve para formar la imagen que el analista tiene de la organizacin y sus objetivos. Algunas veces solamente se completan las dos primeras fases del ciclo de vida del desarrollo de sistemas. Este tipo de estudio puede tener diferentes propsitos, y es realizado tpicamente por un especialista llamado analista de informacin (IA). Las personas involucradas en esta fase son los analistas y los usuarios, tpicamente los administradores de las operaciones y los trabajadores de las operaciones. El analista de sistemas necesita saber los detalles de las funciones actuales del sistema: quin (las personas que estn involucradas), qu (la actividad del negocio), dnde (el ambiente donde se lleva a cabo el trabajo), cundo (en qu momento) y cmo (de qu manera se desarrollan los procedimientos actuales) del negocio bajo estudio. El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. (Es por esta razn que el proceso de adquirir informacin se denomina, con frecuencia, investigacin detallada.) Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave como se mostr anteriormente: 1. 2. 3. 4. 5. 6. 7. 8. Qu es lo que se hace? Cmo se hace? Con qu frecuencia se presenta? Qu tan grande es el volumen de transacciones o de decisiones? Cul es el grado de eficiencia con el que se efectan las tareas? Existe algn problema? Si existe un problema, qu tan serio es? Si existe un problema, cul es la causa que lo origina?

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre porqu ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Se emplean cuestionarios para obtener esta informacin cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organizacin. Asimismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin en condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad.

29

El analista debe preguntar por qu el negocio usa el sistema actual, puede haber muy buenas razones para desarrollar el negocio usando los mtodos actuales, y deben ser considerados cuando se disea cualquier sistema nuevo. Sin embargo, si la razn de las operaciones actuales es que siempre se han hecho as, el analista puede desear la mejora de los procedimientos. Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto con caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida. Al trmino de esta fase, el analista debe comprender el por qu de las funciones del negocio y tener informacin completa sobre las personas, objetivos, datos y procedimientos involucrados.

1.2.3 ANLISIS Y DISEO

Anlisis del sistema. El analista de sistemas involucra al anlisis de las necesidades del sistema. Nuevamente, herramientas y tcnicas especiales ayudan para que el analista haga las determinaciones de los requerimientos. Una herramienta de stas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma grfica estructurada, a partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, as como sus especificaciones, sin son alfanumricos y qu tanto espacio ocupan cuando se imprimen. Durante esta fase el analista de sistemas tambin analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condicin, acciones y reglas de accin. Hay tres mtodos principales para el anlisis de decisiones estructurales: lenguaje estructurado, tablas de decisin y rboles de decisin. No todas las decisiones de la organizacin son estructuradas, pero todava es importante que el analista de sistemas las comprenda. Las decisiones semiestructuradas (decisiones tomadas bajo riesgo) son sustentadas frecuentemente por los sistemas de apoyo a decisiones, cuando se analizan decisiones semiestructuradas, el analista examina las decisiones con base en el grado de habilidad para la toma de decisiones requerida, el grado de complejidad del problema y la cantidad de criterios considerados cuando se toma la decisin. El anlisis de las decisiones de criterios mltiples (decisiones en las que deben ser balanceados muchos factores) tambin parte de esta fase. Se dispone de muchas tcnicas para el anlisis de decisiones de criterios mltiples, incluyendo el proceso de compromiso y el uso de mtodos ponderados. En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistema que sumariza lo que ha sido encontrado, proporciona anlisis de costo/beneficio de las alternativas y hace recomendaciones sobre lo que debe ser hecho (en caso de haberlo). Si alguna de las recomendaciones es aceptable para la administracin, el analista contina sobre ese curso. Cada problema de sistema es nico y nunca hay una sola solucin correcta. La manera en que se formula una solucin o recomendacin depende de la capacidad y entrenamiento profesional individual de cada analista.

30

Diseo del Sistema. Se usa la informacin recolectada anteriormente para realizar el diseo lgico del sistema de informacin. El analista disea procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de informacin sean correctos. Adems, tambin se debe proporcionar entradas efectivas para el sistema de informacin mediante el uso de tcnicas para el buen diseo de formas y pantallas. Parte del diseo lgico del sistema de informacin es disear la interfaz de usuario, que es la que conecta al usuario con el sistema y es, por lo tanto, extremadamente importante. Ejemplos de interfaces de usuario incluyen un teclado para introducir preguntas y respuestas, mens en pantalla para elegir comandos del usuario y un ratn para seleccionar opciones. Tambin incluye el diseo de archivos o bases de datos que guardarn la mayor parte de los datos necesarios para los tomadores de decisiones de la organizacin. Una base de datos bien organizada es la base para todos los sistemas de informacin. En esta fase, el analista tambin trabaja con los usuarios para disear la salida (ya sea en la pantalla o impresa) que satisfaga sus necesidades de informacin. El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo del software, a la que denominan diseo fsico. Se comienza el proceso de diseo identificando los reportes y dems salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema est terminado. Lo anterior se efecta en papel o en la pantalla de una terminal utilizando para ello algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas. El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que deben ser almacenados. As mismo, se escriben con todo detalle los procedimientos de clculo y los datos individuales. Se seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnticas o incluso archivos en papel. Los procedimientos que se escriben indican cmo procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseo representan a ste de muchas maneras (diagramas, tablas y smbolos especiales). La informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de desarrollo de software; los diseadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. Una vez comenzada la fase de programacin, los diseadores contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseo. Por ltimo se disea procedimientos de control y respaldo para proteger el sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener diseos de entrada y salida, especificaciones de archivos y detalles de procesamiento, y tambin puede incluir rboles o tablas de decisin, diagramas de flujo de datos, un diagrama de flujo del sistema y los nombres y funciones de cual quiera de las rutinas de cdigo que ya hayan sido escritas.

31

1.2.4 PROGRAMACIN

En la programacin, el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Algunas de las tcnicas estructuradas para el diseo y documentacin de software incluyen diagramas estructurados, el mtodo HIPO, diagramas de flujo, diagramas NassiSchneiderman y Warnier-Orr y seudo cdigo. El analista de sistema usa uno o ms de estos dispositivos para comunicar al programador lo que necesita ser programado. Los encargados de desarrollar software pueden instalar (o modificar y despus instalar) software comprado a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. En empresas pequeas, donde no hay programadores, se pueden contratar servicios externos de programacin. Durante esta fase tambin se trabaja con los usuarios para desarrollar documentacin efectiva para el software, incluyendo manuales de procedimientos. La documentacin le dice al usuario la manera de usar el software y tambin qu hacer si suceden problemas con el software. Los programadores tambin son responsables de la documentacin de los programas y de proporcionar una explicacin de cmo y por qu ciertos procedimientos se codifican en determinada forma. La documentacin es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicacin se encuentra instalada. Los programadores tienen un papel principal en esta fase conforme disean, codifican y eliminan errores de sintaxis de los programas de computadora. Si el programa va a ser ejecutado en un ambiente de macro computadora, se debe crear el lenguaje de control de trabajos (JCL). Para asegurar la calidad, un programador puede realizar ya sea un diseo o un ensayo del cdigo, explicando las partes complejas del programa a un equipo de otros programadores.

1.2.5 PRUEBAS E IMPLEMENTACIN

Antes de que pueda ser usado, el sistema de informacin debe ser probado, es mucho menos costoso encontrar problemas antes de que el sistema sea entregado a los usuarios. Algunas de las pruebas son realizadas por los programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del sistema actual Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y despus se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organizacin implante el sistema y dependa de l. En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribi los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y, por otra, que el software sea ms confiable.

32

El mantenimiento del sistema comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de informacin. Mucho del trabajo rutinario del programador consiste en el mantenimiento, ya que los negocios gastan gran cantidad de dinero en dicho mantenimiento. Muchos de los procedimientos sistemticos que emplea el analista a lo largo del ciclo de vida del desarrollo del sistema pueden ayudar a asegurar que el mantenimiento se mantenga al mnimo. Implementacin del Sistema. En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de informacin. La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Dentro del entrenamiento a los usuarios para que manejen el sistema, algn entrenamiento es hecho por los proveedores, pero la supervisin del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversin suave del sistema antiguo al nuevo. Este proceso incluye la conversin de archivos de formatos antiguos a nuevos o la construccin de una base de datos, la instalacin de equipo y la puesta del nuevo sistema en produccin Dependiendo del tamao de la organizacin que emplear la aplicacin y el riesgo asociado con su uso, puede elegirse comenzar la operacin del sistema slo en un rea de la empresa (prueba piloto), por ejemplo en un departamento o con una o dos personas. Algunas veces se deja que los dos sistemas, el viejo y el nuevo, trabajen en forma paralela con la finalidad de comparar los resultados. En otras circunstancias, el viejo sistema deja de utilizarse determinado da para comenzar a emplear el nuevo al da siguiente. Cada estrategia de implantacin tiene sus mritos de acuerdo con la situacin que se considere dentro de la empresa. Sin importar cul sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas. Una vez instaladas, las aplicaciones se emplean durante muchos aos. Sin embargo las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente es indudable que debe darse mantenimiento a las aplicaciones; realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua, los sistemas de informacin deben mantenerse siempre al da. En este sentido, la implantacin es un proceso en constante evolucin. Debe hacerse notar que a veces los sistemas trabajan en forma cclica. Cuando un analista termina una fase del desarrollo del sistema y pasa a la siguiente, el descubrimiento de un problema puede obligar a que el analista regrese a la fase anterior y modifique el trabajo que all hizo. Por ejemplo, durante la fase de prueba el programador puede descubrir que el programa no trabaja correctamente, ya sea debido a que no se escribi cdigo para apoyar determinadas partes del diseo del sistema o aquel diseo fue incompleto. En cualquier caso deben ser modificados los programas, y el analista puede tener que cambiar algunos de los materiales del diseo del sistema. A su vez, esto puede necesitar que el analista se rena con el usuario y vuelva a investigar cmo funciona una actividad especfica del negocio. La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: 1. Evaluacin operacional.- Forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin.

33

2. Impacto organizacional.- Identificacin y medicin de los beneficios para la organizacin en reas tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin interno y externo. 3. Opinin de los administradores.- Evala las actitudes de directivos y administradores dentro de la organizacin as como de los usuarios finales. 4. Desempeo del desarrollo.- Se evala el proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos. Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo. Desafortunadamente la evaluacin de sistemas no siempre recibe la atencin que merece. Sin embargo cuando se conduce en forma adecuada proporciona mucha informacin que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes. La importancia del mantenimiento Despus de que el sistema est instalado se le debe dar mantenimiento, esto significa que los programas de computadora deben ser modificados y mantenidos actualizados. La figura 1.9 muestra la cantidad promedio de tiempo gastada en mantenimiento en una instalacin MIS tpica. Las estimaciones del tiempo gastado por los departamentos en mantenimiento han ido del 40 al 60 por ciento del tiempo total empleado en el desarrollo de sistema. Queda muy poco tiempo para nuevo desarrollo de sistemas. Conforme aumenta la cantidad de programas escritos, tambin aumenta la cantidad de mantenimiento que requieren.

Mantenimientos de sistemas existentes 60%

Nuevos sistemas y otras actividades 40%

Fig. 1.9.-Tiempo empleado en el Mantenimiento del Sistema.

34

El mantenimiento se realiza por dos razones. La primera de estas es para corregir errores de software, sin importar que tan completamente se pruebe el sistema, se deslizan errores en los programas de computadora. Los errores del software comercial para microcomputadoras son a veces documentados como "anomalas conocidas", y son corregidos cuando son lanzadas nuevas versiones del software o versiones intermedias. En el software personalizado los errores deben ser corregidos conforme son detectados. La segunda razn para realizar el mantenimiento del sistema es para mejorar las capacidades del software en respuesta a las necesidades organizacionales cambiantes y, por lo general, involucran algunas de las siguientes situaciones: 1. Los usuarios frecuentemente solicitan caractersticas adicionales despus de que familiarizan con el sistema de cmputo y sus capacidades. Estas caractersticas solicitadas pueden ser tan simples como el desplegado de totales adicionales en un reporte o tan complicadas como el desarrollo de nuevo software. 2. El negocio cambia a travs del tiempo. Se debe modificar el software para abarcar cambios tales como nuevos requerimientos de reportes gubernamentales o corporativos, la necesidad de producir nueva informacin para clientes, etctera. 3. El hardware y software estn cambiando a un ritmo acelerado. Un sistema que usa tecnologa antigua puede ser modificado para usar las capacidades de una tecnologa ms nueva. Un ejemplo de tal cambio es el reemplazo de una terminal de macro computadora con una estacin de trabajo de microcomputadora, o una microcomputadora con una computadora de escritorio. La figura 1.10 ilustra la cantidad de recursos, por lo general tiempo y dinero, gastados en el desarrollo y mantenimiento del sistema. El rea bajo la curva representa la cantidad total de dlares gastada. Se puede ver que a lo largo del tiempo es probable que el costo de mantenimiento exceda al del desarrollo del sistema. En cierto punto es ms conveniente realizar un nuevo estudio del sistema, debido a que el costo de mantenimiento continuado es claramente mayor que la creacin de un sistema de informacin completamente nuevo. Resumiendo, el mantenimiento es un proceso continuo a lo largo del ciclo de vida de un sistema de informacin. Despus de que es instalado el sistema de informacin, el mantenimiento por lo general toma la forma de correccin de errores de programa no detectados previamente. Una vez que son corregidos, el sistema alcanza un estado estable proporcionando servicios confiables a sus usuarios. El mantenimiento durante este periodo puede consistir en la eliminacin de unos cuantos errores no detectados anteriormente y la actualizacin del sistema con unas cuantas mejoras menores. Sin embargo, conforme pasa el tiempo y cambia el negocio y la tecnologa, los esfuerzos de mantenimiento se incrementan dramticamente.

35

Cambios mayores en el negocio y en la tecnologa Errores posteriores a la instalacin Cambios menores debido a errores y mejoras

Cantidad de recursos consumidos, tiempo y dinero

Desarrollo de sistemas

Tiempo

Das de instalacin Fig. 1.10.-Consumo de recursos a lo largo de la vida del sistema.

PREGUNTAS Y EJERCICIOS UNIDAD I

1. Dar dos ejemplos de cada una de las definiciones de sistema obtenidas del diccionario Welter. 2. Cmo estn divididos los sistemas automatizados? 3. Dar cinco ejemplos de sistemas que hayan durado ms de un ao y que aun existan hoy en da. 4. De cinco ejemplos de sistemas no hechos por el hombre que hayan durante su vida Por qu fallaron? 5. Dar cinco ejemplos de sistemas hechos por el hombre que hayan fallado durante su vida. 6. Dar un ejemplo de un sistema hecho por el hombre, que en su opinin, no debera automatizarse. Por qu no debera ser automatizado? 7. Dar cinco ejemplo de: a. Sistemas de tiempo real. b. Sistemas en lnea. c. Sistema de apoyo a la toma de decisiones. d. Sistema de planeacin estratgica. e. Sistemas expertos. 8. Dar un ejemplo de un sistema comercial que se describa como de inteligencia artificial o como un sistema en el conocimiento y que est siendo escrito honestamente o exactamente. 9. Describe los elementos bsicos de control en un modelo de sistemas. 10. Cul es el objetivo del mantenimiento en los sistemas?

36

INTRODUCCIN A LA INGENIERA DE SOFTWARE

2.1 DEFINICIN DE INGENIERA DE SOFTWARE 2.2 HISTORIA DE LA INGENIERA DE SOFTWARE 2.3 CARACTERSTICAS DEL SOFTWARE 2.4 MITOS DEL SOFTWARE 2.5 CAPAS DE LA INGENIERA DE SOFTWARE 2.6 EL PROCESO DEL SOFTWARE 2.7 SOFTWARE DE ALTA CALIDAD 2.8 FACTORES DE CALIDAD Y PRODUCTIVIDAD

37

2.1 DEFINICIN DE INGENIERA DE SOFTWARE

Una de las primeras definiciones de ingeniera del software fue la propuesta por Fritz Bauer en la primera conferencia importante NAU69 dedicada al tema: El establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico que sea fiable y funcione de manera eficiente sobre mquinas reales.
2

La definicin de la IEEE siguiente: La ingeniera de software se define como la disciplina tecnolgica preocupada de la produccin sistemtica y mantenimiento de los productos de software que son desarrollados y modificados en tiempo y dentro de un presupuesto definido, el cual tiene como objetivo satisfacer los requerimientos del Cliente con Calidad.

La ingeniera de software difiere de la programacin tradicional en que se utilizan tcnicas de ingeniera para especificar, disear, instrumentar, validar y mantener los productos dentro del tiempo y el presupuesto establecidos para el proyecto; adems esta ingeniera se preocupa por aspectos administrativos que quedan fuera del dominio normal de la programacin. En pequeos proyectos, al emplear uno dos programadores durante uno dos meses, los detalles ms preocupantes sean los tcnicos; en proyectos que utilizan ms programadores durante mayor tiempo, se requiere de un control administrativo para coordinar todas las actividades tcnicas. El trmino programador se emplea para denominar al individuo preocupado por los detalles de la instrumentacin, empacado y modificacin de los algoritmos y estructura de datos codificados en un lenguaje de programacin particular. Los ingenieros de programacin estn adems, ocupados con aspectos como el anlisis, el diseo, la verificacin y pruebas de programas, la documentacin, el mantenimiento y la administracin de proyectos; as un ingeniero de programacin deber tener aptitudes y experiencia como programador, para entender las zonas de problemas, metas y objetivos de la ingeniera de software. Algunas veces se ha dicho que los conceptos de la ingeniera de software son aplicables nicamente a proyectos grandes y de larga duracin; es cierto que en grandes proyectos son esenciales las prcticas estndar y los procedimientos formales y que algunas notaciones, herramientas y tcnicas de la ingeniera de software se han desarrollado para tales casos. Por otro lado un proyecto pequeo; puede ser ms sencillo, sin embargo, los principios fundamentales de anlisis sistemtico, diseo, instrumentacin, prueba y modificaciones permanecen constantes, ya sea para un proyecto de una persona y de un mes, o de 1000 personas y 10 aos. Los conceptos fundamentales de desarrollo de software y mantenimiento presentados anteriormente son tiles en cualquier proyecto de programacin; se emplean algunas tcnicas analizadas son costeables slo en grandes proyectos. Aunque se han propuesto muchas ms definiciones generales, todas refuerzan la importancia de una disciplina de ingeniera para el desarrollo del software. Es comn darse cuenta que la inversin de una tecnologa pueda tener profundos e inesperados en otras tecnologas con las que en apariencia no tiene ninguna relacin, como en empresas comerciales, en personas y an en la cultura en su conjunto. Este fenmeno a menudo se denomina la ley de las secuencias imprevistas. En la actualidad el software de computadoras es la tecnologa individual ms importante en el mbito mundial. Tambin es uno de los ejemplos principales de la ley de las consecuencias imprevistas. Nadie en la dcada de los 50s podra haber predicho que el software se convertira

38

en una tecnologa indispensable en los negocios, en la ciencia y en la ingeniera; tampoco que el software permitiera la creacin de nuevas tecnologas(por ejemplo la ingeniera gentica), la expansin de tecnologa existente(como las telecomunicaciones), el fin de la tecnologa antigua(como la industria de la impresin); que el software fuera la fuerza conductora detrs de la evolucin detrs de las computadoras personales; que los productos empaquetados de software se pudieran comprar en los centro comerciales; que una compaa de software se volviera muy grande y ms influyente que la mayora de las compaas de la era industrial de la impresin; que una gran red construida con software llamada Internet cubrira y cambiaria todo, desde la investigacin bibliogrfica hasta las compras de los consumidores y los hbitos diarios de los jvenes (y no tan jvenes ).Nadie podra haber previsto que el software estara relacionado con sistemas de todo tipo: de transporte, mdicos, de telecomunicaciones, militares, industriales, de entretenimiento, maquinaria para oficina(la lista parece no tener fin). Y si se toma en cuenta la ley de las consecuencias imprevistas, hay muchos efectos que todava es imposible predecir diario. Por ltimo, nadie podra a ver predicho que millones de programas de computadora tendran que corregirse, adaptarse y mejorarse conforme pasara el tiempo y que la labor de desarrollar estas actividades de mantenimiento absolvera ms gente y recursos que todo el trabajo aplicado para la creacin del software del nuevo software.

La ingeniera del software surge de la ingeniera de sistemas y de hardware. Abarca un conjunto de tres elementos clave (mtodos, herramientas y procedimientos) que facilitan al gestor controlar el proceso del desarrollo del software y suministrar a los que practiquen dicha ingeniera las bases para construir software de alta calidad de una forma productiva. Los mtodos de la ingeniera del software indican como construir tcnicamente el software. Los mtodos abarcan un amplio espectro de tareas que incluyen: planificacin y estimacin de proyectos, anlisis de los requisitos del sistema y del software, diseo de estructuras de datos, arquitectura de programas y procedimientos algortmicos, codificacin, prueba y mantenimiento. Los mtodos de la ingeniera del software introducen frecuentemente una notacin especial orientada a un lenguaje o grfica y un conjunto de criterios para la calidad del software. Las herramientas de la ingeniera del software suministran un soporte automtico o semiautomtico para los mtodos. Hoy existen herramientas para soportar cada uno de los mtodos mencionados anteriormente. Cuando se integran las herramientas de forma que la informacin creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte del desarrollo del software, llamado ingeniera del software asistida por computadora (del ingls, CASE). CASE combina software, hardware y bases de datos sobre ingeniera del software (una estructura de datos que contenga la informacin relevante sobre el anlisis, diseo, codificacin y prueba) para crear un entorno de ingeniera del software. Los procedimientos de la ingeniera del software son el pegamento que junta los mtodos y las herramientas y facilita un desarrollo racional y oportuno del software de computadora. Los procedimientos definen la secuencia en la que se aplican los mtodos, las entregas (documentos, informes, formas, etc.) que se requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios, y las directrices que ayudan a los gestores del software a evaluar el progreso. La ingeniera del software est compuesta por una serie de pasos que abarcan los mtodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniera del software. La eleccin de un paradigma para la ingeniera del software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos y herramientas a usar y poscontroles y entregas requeridos.

_______________________________ 2

IEEE, siglas de Institute of Electrical and Electronic Engineers, en espaol es el Instituto de Ingenieros Elctricos y Electrnicos

39

2.2

HISTORIA DE LA INGENIERA DE SOFTWARE

La Ingeniera del Software, se trmino utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comit de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse segn Alan Davis como la aplicacin inteligente de principios probados, tcnicas, lenguajes y herramientas para la creacin y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios. El trmino empez a usarse a finales de la dcada de los 60`s, para expresar el rea de conocimiento que se estaba desarrollando en torno a las problemticas que ofreca el software en ese momento. Un factor que ha sido relevante en este desarrollo de tecnologas ha sido el Software, ya que ha facilitado y agilizado varios procesos que ya se manejaban con anterioridad. Adems que se ha convertido en una caracterstica primordial que deben tener las organizaciones para poder convertirse en una de las mejores a nivel mundial. A continuacin se menciona las eras de la ingeniera de software. PRIMERA ERA Durante los primeros aos de la era de la computadora, el software se contemplaba como un aadido. Desde entonces el campo se ha desarrollado tremendamente. La programacin de computadoras era un arte de andar por casa para el que existan pocos mtodos sistemticos. El desarrollo del software se realizaba virtualmente sin ninguna planificacin, hasta que los planes comenzaron a descalabrarse y los costos a correr. Los programadores trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salan con xito. Los problemas a ser resueltos eran principalmente de una naturaleza tcnica, el nfasis estaba en expresar algoritmos conocidos eficazmente en algn lenguaje de programacin. En estos primeros aos lo normal era que el hardware fuera de propsito general. Por otra parte, el software se disea a medida para cada aplicacin y tena una distribucin relativamente pequea. El software como producto estaba en su infancia, la mayora se desarrollaba y era utilizado por la misma persona u organizacin. La misma persona lo escriba, lo ejecutaba, si fallaba, lo depuraba. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estar all cuando se encontrara algn error. Debido a este entorno personalizado del software, el diseo era un proceso implcito, realizado en la mente de alguien, y la documentacin normalmente no exista. A lo largo de los primeros aos aprendimos mucho sobre la implementacin de sistemas informticos, pero relativamente poco sobre la ingeniera de las computadoras. Sin embargo, en honor de la verdad, se debe reconocer que durante esa era se desarrollaron muchos sistemas informticos excepcionales. Algunos de ellos todava se siguen utilizando hoy y, por sus caractersticas, siguen siendo admirados con toda justicia. SEGUNDA ERA Se extienden desde la mitad de la dcada de los 60s hasta finales de los 70s. La multiprogramacin y los sistemas multiusuario introdujeron nuevos conceptos de interaccin hombre mquina. Las tcnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticacin del hardware y del software. Los sistemas de tiempo real podan recoger, analizar y transformar datos de mltiples fuentes, controlando as los procesos y produciendo

40

salidas en milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en lnea condujeron a la primera generacin de sistemas de gestin de bases de datos. La segunda era se caracteriz tambin por el establecimiento del software ya se desarrollaba para tener una amplia distribucin en un mercado multidisciplinario. Los programas se distribuan para computadoras grandes y para minicomputadoras, a cientos e incluso a miles de usuarios. Los patronatos de la industria, del gobierno y de la universidad se prestaban a desarrollar el mejor paquete de software y ganar as mucho dinero. Conforme creca el nmero de sistemas informticos, comenzaron a extenderse las bibliotecas de software de computadora. Las casas desarrollaban proyectos en los que se producan programas de decenas de miles de sentencias fuente. Los productos de software comprados al exterior incorporaban cientos de miles de nuevas sentencias. Una nube negra apareci en el horizonte. Todos esos programas, todas esas sentencias fuente tenan que ser corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron colectivamente mantenimiento del software. El esfuerzo gastado en el mantenimiento del software comenz a absorber recursos en una medida alarmante. An peor, la naturaleza personalizada de muchos programas los haca virtualmente imposibles de mantener. Haba comenzado una crisis del software TERCERA ERA La tercera era comenz a mediados de los aos 70s y continu ms all de una dcada. El sistema distribuido, mltiples computadoras, cada una ejecutando funciones concurrentemente y comunicndose con alguna otra, increment notablemente la complejidad de los sistemas informticos. Las redes de rea local y de rea global, las comunicaciones digitales de alto ancho de banda y creciente demanda de acceso instantneo a los datos, supusieron una fuente presin sobre los desarrolladores del software. An ms, los sistemas y el software que lo permitan continuaron residiendo dentro de la industria y de la academia. El uso personal era extrao. La conclusin de esta era se caracteriz por la llegada y amplio uso de los microprocesadores. El microprocesador ha producido un extenso grupo de productos inteligentes, desde productos inteligentes, desde automviles hasta hornos microondas, desde robots industriales a equipos de diagnstico de suero sanguneo, pero ninguno ha sido ms importante que la computadora personal. En menos de una dcada, las computadoras llegarn a ser fcilmente accesibles al pblico. CUARTA ERA En esta era, se aleja de las computadoras individuales y da los programas de computadoras, dirigindose al impacto colectivo de las computadoras individuales del software. Potentes mquinas personales controladas por sistemas operativos sofisticados, en redes globales y locales, acompaadas por aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas informticas estn cambiando de entornos centralizados de grandes computadoras a entornos descentralizados cliente/servidor. Las redes de informacin en todo el mundo proporcionan una infraestructura que iguala a expertos y polticos en pensar sobre una sper autopista de informacin y una conexin del ciberespacio. De hecho Internet se puede observar como un software al que pueden acceder usuarios individuales. La industria del software ya es la cuna de la economa del mundo. Las decisiones tomadas por gigantes de la industria tales como Microsoft arriesgan billones de dlares. A medida que la cuarta generacin progresa, han comenzado a surgir nuevas tecnologas. La tecnologa orientadas a objetos est desplazando rpidamente los enfoques de desarrollo de software ms convencionales en muchas reas de aplicaciones. Aunque las predicciones de las computadoras de quinta

41

generacin continan eludindonos, las tcnicas de cuarta generacin para el desarrollo del software estn cambiando en forma en que la comunidad del software construye programas informticos. Los sistemas expertos y el software de inteligencia artificial han salido del laboratorio para entrar en aplicaciones prcticas de una gran variedad de problemas del mundo real. El software de redes neuronales artificiales junto con la aplicacin de lgica difusa ha abierto posibilidades excitantes para el reconocimiento de patrones y habilidades de procesamiento de informacin de carcter humano. La programacin de realidad virtual y los sistemas multimedia ofrecen formas radicalmente diferentes de comunicar informacin al usuario final. Los algoritmos genricos ofrecen el potencial para el software que reside dentro de las computadoras biolgicas masivamente en paralelo. Sin embargo, un conjunto de problemas relacionados con el software ha persistido a travs de la evolucin de los sistemas basados en computadora, y estos problemas continan aumentado.

Aportaciones al campo Se ha percatado de los problemas que existin en algn momento respecto a que no se llevaba una planificacin para un buen desarrollo del software. Esto trajo consecuencias que repercutieron en las organizaciones. Muchas de estas consecuencias originaron prdidas millonarias en diferentes empresas como el caso de una Aerolnea Internacional de los Estados Unidos de Amrica, que tuvo el problema de que al momento de que un pasajero pretenda hacer su reservacin de vuelo, el sistema de informacin mostraba que los asientos se encontraban ocupados, mientras que fsicamente el vuelo contaba con demasiados asientos libres. Esto origino una prdida de $50 millones de dlares. A la vez se presentaron casos en los cuales las prdidas eran iguales o mayores materialmente hablando. Las transacciones financieras de aqul entonces se empezaron a llevar por medio de software especializado, pero tambin tuvo errores, ya que al enviar facturas de pago, su total de pago presentaba $0.00, lo cual origin bastantes prdidas. Pero, no slo existieron prdidas materiales en los malos desarrollos de software de aquellos das. Una computadora que se usaba para el servicio militar de los Estados Unidos de Amrica, report una alarma acerca de la Unin Sovitica de Repblicas Socialistas haba iniciado un ataque de proyectiles nucleares en contra de ese pas. Esto origin una gran movilizacin para contrarrestar el ataque, se alistaron a los bombarderos atmicos norteamericanos, pero al da siguiente a travs de un peridico se daba la noticia que todo haba sido un error en el Software de la computadora. Otra de las consecuencias en donde si hubo prdidas humanas, fue en un caso en Inglaterra, en donde se enjuiciaba a una mujer de 54 aos de edad por asesinar a su hija, esto fue debido a un mensaje de un sistema informatizado hizo de la compaa de seguro social, informaba a la mujer que ella estaba gravemente enferma, se le deca que padeca una forma incurable de sfilis, adems de que haba infectado a sus dos hijos. En pnico, ella estrangul a su hija de 15 aos e intento matar a su hijo de 13, el muchacho escap y consigui ayuda para despus impedir que su madre se suicidara. Finalmente el juez culp el error de la computadora y no consider a la mujer responsable de sus acciones. Como nos podemos dar cuenta estas consecuencias fueron de gran gravedad. En los primeros dos casos se atac hacia los recursos financieros de grandes empresas a nivel internacional, en los siguientes casos aparte de afectar materialmente a la sociedad, se pierde una vida humana por un error en el software acerca de un padecimiento. Es as como se observa los diferentes tipos de consecuencias que se originaban por un mal desarrollo de Software.

42

Con este tipo de casos nos hemos percatado de la importancia que tiene una planeacin acerca del desarrollo del software; en aqul entonces el programador no se adentraba hacia las repercusiones que pudiera tener el software que estaba creando, y ante la falta de documentacin para la enseanza de la creacin de Software, los programadores aprendan solamente practicando. Actualmente los desarrolladores de Software, al momento de disearlo debe de darce cuenta de varias cosas para no tener ese tipo de errores que existieron con anterioridad. Adems de otras cosas creemos que entre lo ms importante que se debe saber es: Hacia quin va dirigido el SW? Quienes sern los usuarios? Qu tipo de informacin les ser La facilidad de acceso. Entre muchas otras cosas ms. Pero ante todo siempre se debe adoptar la postura de todos los tipos de usuarios que vayan a trabajar con el software, ya que as se podr observar si los resultados que se obtienen son los que se requieren, es decir todo en base a una buena planeacin. Sin embargo, no es del todo satisfactorio dejar las cosas simplemente en las etapas de planeacin. Despus de que los programas estn terminados deben recibir mantenimiento, y los esfuerzos de mantenimiento normalmente sobrepasan el esfuerzo gastado en el diseo y programacin original. Parte importante de este aspecto es la documentacin, se deben documentar el software y los procedimientos para que estn codificados en un formato que pueda ser fcilmente accesado. La documentacin permite que los usuarios, programadores y analistas observen el sistema, software y procedimientos sin tener que interactuar con l. Despus de ver todos los avances se puede observar que no slo se cambia una manera de trabajar, sino que se cambia la forma de conceptualizar la vida, Quin vive ya sin la ayuda de una computadora que agilice procesos?, y en caso drstico podemos ver que se cambian las costumbres y cultura de la sociedad actual. A manera de conclusin, se finaliza con una semblanza gil y rpida que permitir observar los aspectos ms relevantes que a un juicio han marcado con hechos la evolucin del software. Es de suma relevancia el mencionar algunas de los lenguajes de programacin que fueron utilizados en sus respectivas eras (Tabla 2.1). Esto nos ayudar a comprender mejor el objetivo que se persegua en cada una de ellas.

43

40 30 20 10
Nuevo Concepto: Sistemas Distribuidos. Complejidad en los Sistemas de Informacin. Aparecen: Redes de rea local y global, y Comunicadores Digitales. Amplio Uso de Microprocesadores. Impacto Colectivo de Software. Aparecen: Redes de Informacin, Tecnologas Orientadas a Objetos. Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia Artificial. La informacin como valor preponderante dentro de las Organizaciones.

Se trabajaba con la idea de Codificar y Corregir. No exista un planteamiento previo. No exista documentacin de ningn tipo. Existencia de pocos mtodos formales y pocos creyentes en ellos. Desarrollo a base de prueba y error.

Simplificar cdigo. Multiprogramacin y Sistemas Multiusuario. Sistemas de Tiempo Real apoyan la toma de decisiones. Aparicin de Software como producto. (Casas de Software). Inicio de la crisis del software Se buscan procedimientos para el desarrollo del Software.

1950

1960

1972

1989

Figura 2.1.- Eras de la historia de la Ingeniera de software

ERA

LENGUAJES
Fortran Basic Logo Cobol

CARACTERSTICAS
Fue el primer y principal lenguaje Cientfico. Diseado por IBM. Utilizado tambin para aplicaciones comerciales. Desarrollado como lenguaje de tiempo compartido. Traza elementos grficos estableciendo la geometra de lpiz. Ampliamente usado en programacin en minicomputadores. Lenguaje Acadmico. Sus caractersticas son copiadas por otros lenguajes. xito comercial a travs de Borland. Desarrollado en Francia, 1973. Aplicaciones en Inteligencia Artificial (IA). Sistema de Multiprogramacin. Incluye su propia base de datos.

10

20

Pascal Prolog Mumps Lisp

44

30

C, C++ Modula2 dBase

Utilizado en aplicaciones mdicas. Sintaxis muy diferente de los dems lenguajes. Programa aplicaciones en IA. Desarrollado en los ochentas. Se utiliza en aplicaciones comerciales. C++, se utiliza para la tecnologa orientada a objetos. Versin mejorada de Pascal. Desarrollada en 1979. Lenguaje estndar para aplicaciones comerciales. Ramas colaterales: Clipper, FoxBase. Desarrollado por Microsoft. Principalmente orientado a la tecnologa de objetos. Principalmente para aplicaciones comerciales. Versin cotizada, ya que permite interactuar con tablas de manejadores de bases de datos y lenguaje SQL.

40

Visual C++ Visual Basic

Tabla 2.1.- Lenguajes utilizados en cada era de la historia de la Ingeniera de software.

En estos das se habla de una nueva plataforma desarrollada por Microsoft: La plataforma .NET, que permitir a los desarrolladores crear aplicaciones extensas e incluso sistemas de componentes y servicios con gran capacidad para operar entre s. Este tipo de aplicaciones se pueden limitar a una organizacin, pero sa no es la idea general, ya que los muchos analistas son de la opinin de que hay gran necesidad de aplicaciones que puedan existir en un ambiente distribuido basado en Internet. Se cree que como normalmente sucede sobre todo con el software de sistemas, algunas reas no estn terminadas, y aunque la nueva plataforma ofrezca caractersticas modernas y sencillas, utilizarlas depender si Microsoft logra que los principales negocios acepten cambiar a esta nueva forma de crear soluciones. A continuacin se presenta una lista de algunas personas que hicieron contribuciones significativas en la creacin y crecimiento de la industria de productos de software Charles Bachman. Invent la tecnologa del banco de datos en los inicios de los sesentas. John Backus. FORTRAN desarrollado para IBM (1954) Bob Bemer. Uno de los diseadores de COBOL y el ASCII normal para IBM (aos sesenta); inventor de la sucesin del Escape, el mecanismo universal para toda la computadora. Larry Constantine. Inventa los datos que fluyen en los diagramas, presentan primero en papel, los conceptos de un plan estructurado en 1968. Peter Cunningham. Funda una de las primeras empresas de investigacin de mercado para enfocar el software y comienza a comercializar los productos del software en 1974. Tom DeMarco. El pionero en utilizar una metodologa de caso, el autor, y consultor en los aos setenta. Wilfred J. Dixon. Empez distribuyendo el software estadstico en 1962.

45

Frank Dodge. Co fund McCormack & el Regate qu vendi el primer software de contabilidad en 1969. Larry Ellison. Dej camino abierto para los DBMS. Dave Ferguson. Logr vender el primer producto de software con xito contra un programa de IBM. Ken Orr. Crea la metodologa de caso desarrollada en los aos setenta. La mayora de estas personas nombradas, trabajaron sobre algn aspecto del Software con el que an se trabaja, pero en otros casos, este tipo de avances dieron pie a nuevas investigaciones que han contribuido al desarrollo del mismo, es decir, que han servido como base para descubrir nuevas fisonomas del Software con el que actualmente se trabaja.

46

2.3 CARACTERSTICAS DEL SOFTWARE

La diferencia entre el software y otras cosas que construye el ser humano, es que el software es un elemento lgico, en lugar de fsico, de un sistema. Por lo tanto el software tiene caractersticas muy diferentes a las del hardware: 1. El software se desarrolla o construye; no se manufactura en el sentido clsico.- Aunque existen algunas similitudes entre el desarrollo del software y la construccin del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseo, pero la fase de construccin del hardware puede introducir problemas de calidad que no existen (o son fcilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relacin entre la gente dedicada y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construccin de un producto, pero los mtodos son diferentes. Los costes del software se encuentran en la ingeniera; esto significa que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricacin. 2. El software no se desgasta.- La figura 2.3 describe, para el hardware, la proporcin de fallos como una funcin del tiempo. Esa relacin, denominada frecuentemente curva de baera, indica que el hardware exhibe relativamente muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a defectos del diseo o de la fabricacin); una vez corregidos los defectos, la tasa de fallos cae hasta un nivel estacionario (bastante bajo, con un poco de optimismo) donde permanece durante un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, los fallos vuelven a presentarse a medida que los componentes del hardware sufren los efectos acumulativos de la suciedad, la vibracin, los malos tratos, las temperaturas extremas y muchos otros males externos. Sencillamente, el hardware comienza a estropearse.

Mortalidad infantil

Desgaste

Tiempo
Figura 2.2.- Curva de fallos del hardware.

47

El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Por tanto, en teora, la curva de fallos para el software tendra la forma que muestra la figura 2.3. Los defectos no detectados harn que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen, suponiendo que no se introducen nuevos errores, la curva se aplana, como muestra la figura. Esa figura es una gran simplificacin de los modelos reales de fallos del software. Sin embargo, la implicacin es clara el software no se estropea. Pero se deteriora! Esto, que parece una contradiccin, puede comprenderse mejor considerando la figura 2.4. Durante su vida, el software sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, haciendo que la curva de fallos tenga picos como se ve en la figura. Antes de que la curva pueda volver al estado estacionario original, se solicita otro cambio, haciendo que de nuevo se cree otro pico. Lentamente, el nivel mnimo de fallos comienza a crecer; el software se va deteriorando debido a los cambios.

ndice de fallos

Contina el mismo nivel hasta estar obsoleto

Tiempo
Figura 2.3 Curva de fallos del software (idealizada)

Curva real

ndice de fallos

Cambio

Curva ideal

Tiempo
Figura 2.4.- Curva real de fallos del software.

48

Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software. Cuando un componente de hardware se estropea, se sustituye por una pieza de repuesto. No hay piezas de repuesto para el software. Cada fallo en el software indica un error en el diseo o en el proceso mediante el que se tradujo el diseo a cdigo mquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware. 3. La mayora del software se construye a medida, en vez de ensamblar componentes existentes. Consideremos la forma en la que se disea y se construye el hardware de control para un producto basado en microprocesador. El ingeniero de diseo construye un sencillo esquema de la circuitera digital, hace algn anlisis fundamental para asegurar que se realiza la funcin adecuada y va al catlogo de ventas de componentes digitales existentes. Cada circuito integrado (frecuentemente llamado un CI o pastilla) tiene un nmero de pieza, una funcin definida y vlida, una interfaz bien definida y un conjunto estndar de criterios de integracin. Despus de seleccionar cada componente, puede solicitarse la compra. Por desgracia, los diseadores del software no disponen de esa comodidad que acabamos de describir. Con unas pocas excepciones, no existen catlogos de componentes de software. Se puede comprar software ya desarrollado pero solo como una unidad completa, no como componentes que puedan reensamblarse en nuevos programas.

49

2.4 MITOS DEL SOFTWARE

Muchas de las causas de la crisis del software se pueden encontrar en una mitologa que surge durante los primeros aos del desarrollo del software. A diferencia de los mitos antiguos, que ofrecan a los hombres lecciones dignas de tener en cuenta, los mitos del software propagaron informacin errnea y confusin. Los mitos del software tienen varios atributos que los hacen insidiosos; por ejemplo, aparecieron como declaraciones razonables de hechos (algunas veces conteniendo elementos verdaderos); tuvieron un sentido intuitivo frecuentemente fueron promulgados por expertos que estaban al da. Hoy, la mayora de los profesionales competentes consideran a los mitos por lo que son actitudes errneas que han causado varios problemas, tanto a los gestores como a los tcnicos. Sin embargo, las viejas actitudes y hbitos son difciles de modificar y, cuando vamos hacia la quinta dcada del software, todava se cree en algunos restos de los mitos del software.

MITOS DE GESTIN Los gestores con responsabilidad sobre el software, como los gestores en la mayora de las disciplinas, estn normalmente bajo la presin de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Igual que se agarra al vaco una persona que se ahoga, un gestor de software se agarra frecuentemente a un mito del software, aunque tal creencia slo disminuya la presin temporalmente. Mito. Tenemos ya un libro que est lleno de estndares y procedimientos para construir software. No le proporciona ya a mi gente todo lo que necesita saber? Realidad. Est muy bien que el libro exista, pero se usa? Conocen los trabajadores su existencia? Refleja las prcticas modernas de desarrollo de software? Es completo? En muchos casos, la respuesta a todas estas preguntas es no. Mito. Nuestra gente dispone de las herramientas de desarrollo de software ms avanzadas; despus de todo, les compramos las computadoras ms nuevas. Realidad. Se necesita mucho ms que el ltimo modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad. Las herramientas de ingeniera del software asistida por computadora (CASE), aunque la mayora todava no se usen, son ms importantes que el hardware para conseguir buena calidad y productividad. Mito. Si fallamos en la planificacin, podemos aadir ms programadores y adelantar el tiempo perdido (el llamado algunas veces concepto de la horda mongoliana). Realidad. El desarrollo de software no es un proceso mecnico como la fabricacin. En palabras de Brooks .aadir gente a un proyecto de software retrasado lo retrasa an ms. Al principio, esta declaracin puede parecer un contrasentido. Sin embargo, cuando se aaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede aadirse gente, pero slo de una manera planificada y bien coordinada.

50

MITOS DEL CLIENTE Un cliente que solicita una aplicacin de software puede ser una persona del despacho de al lado, un grupo tcnico de la sala de abajo, el departamento de ventas o una compaa exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores trabajadores responsables hacen muy poco para corregir la mala informacin. Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el que desarrolla el software. Mito. Una declaracin general de los objetivos es suficiente para comenzar a escribir los programas, podemos dar los detalles ms adelante. Realidad. Una mala definicin inicial es la principal causa del trabajo baldo en software. Es esencial una descripcin formal y detallada del mbito de la informacin, funciones, rendimiento, interfaces, ligaduras del diseo y criterios de validacin. Estas caractersticas pueden determinarse slo despus de una exhaustiva comunicacin entre el cliente y el analista. Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fcilmente, ya que el software es flexible. Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio vara segn el momento en que se introduzca. La figura 2.5 ilustra el impacto de los cambios. Si se pone cuidado al dar la definicin inicial, los cambios solicitados al principio pueden acomodarse fcilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el coste. Cuando los cambios se solicitan durante el diseo del software, el impacto en el coste crece rpidamente. Ya se han acordado los recursos a utilizar y se ha establecido un esqueleto del diseo. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseo; es decir, coste adicional. Los cambios en la funcin, rendimiento, interfaces u otras caractersticas, durante la implementacin (codificacin y prueba) pueden tener un impacto importante sobre el coste. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud ms caro que el mismo cambio pedido al principio.

1 x Definicin Mantenimiento

1 , 5

Desarrollo

Figura 2.5.- Impacto del cambio. 6 x

o
6 0 1 0 0 x

51

MITOS DE LOS DESARROLLADORES

Los Mitos en los que an creen muchos desarrolladores se han ido fomentando durante cuatro dcadas de cultura informtica. Como ya se indic anteriormente, durante los primeros das del desarrollo de software, la programacin se vea como un arte. Las viejas formas y actitudes tardan en morir.

Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad. Alguien dijo una vez: Cuanto ms pronto se comience a escribir cdigo, ms se tardar en terminarlo. Los datos industriales indican que entre el 50 y el 70 por ciento de todo el esfuerzo dedicado a un programa se realizar despus de que se le haya entregado al cliente por primera vez. Mito. Hasta que no tengo el programa ejecutndose, realmente no tengo forma de comprobar su calidad. Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos ms efectivos para garantizar la calidad del software la revisin tcnica formal. La revisin del software es un filtro de calidad que se ha comprobado que es ms efectivo que la prueba, para encontrar ciertas clases de defectos en el software.

Mito. Lo nico que se entrega al terminar el proyecto es el programa funcionando. Realidad. Un programa que funciona es slo una parte de una configuracin del software que incluye todos los elementos que se muestran en la figura 2.6. La documentacin es la base de un buen desarrollo y, lo que es ms importante, proporciona guas para la tarea de mantenimiento del software. Muchos profesionales del software reconocen la falsedad de los mitos descritos anteriormente. Lamentablemente, las actitudes y mtodos habituales fomentan una pobre gestin y malas prcticas tcnicas, incluso cuando la realidad dicta un mtodo mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulacin de soluciones prcticas para el desarrollo del mismo.

Estructuras de datos

Programa Operativo Plan Especificacin de requisitos Diseo L i s t Especificacin de la prueba a d o

Figura 2.7.-Configuracin del software.

52

2.5 CAPAS DE LA INGENIERA DE SOFTWARE

La ingeniera de software es una unin de capas que debe estar sustentado en un compromiso con la calidad. La gestin de calidad total, la metodologa de mejora de procesos y enfoques similares fomentan una cultura de mejora continua del proceso, y es esta cultura la que al final conduce al desarrollo de enfoques muy efectivos para la ingeniera de software. La base que soporta dicha ingeniera es un enfoque en la calidad. El proceso de la ingeniera de software es el elemento que mantiene juntos los estratos de la tecnologa y que permite el desarrollo racional y a tiempo del software de la computadora. El proceso define un marco, que debe establecerse para la entrega efectiva de la tecnologa y forma la base para el control de la gestin de los proyectos de software y establecer el contexto en el cual se aplica los mtodos tcnicos, se generan los productos del trabajo (modelo, documentos, datos, reportes, formatos, etctera), se establecen los fundamentos, se aseguran la calidad, y el cambio se maneja de manera apropiada. Las herramientas de la ingeniera de software proporcionan un enfoque automtico o semiautomtico para el proceso y para los mtodos.

Herramientas Mtodos Proceso Enfoque de Calidad

Figura 2.7.- Capas de la Ingeniera de Software.

CAPA DE CALIDAD Cualquier disciplina de ingeniera (incluida la ingeniera del software) debe descansar sobre un esfuerzo de organizacin de calidad. La gestin total de la calidad y las filosofas similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez ms robustos para la ingeniera del software.

53

CAPA DE PROCESO El proceso define un marco de trabajo para un conjunto de reas clave, las cuales forman la base del control de gestin de proyectos de software y establecen el contexto en el cual; se aplican los mtodos tcnicos, se producen resultados de trabajo, se establecen mtodos, se asegura la calidad y el cambio se gestiona adecuadamente.

CAPA DE MTODOS Los mtodos construye tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Estos mtodos dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.

CAPA DE HERRAMIENTAS Proporcionan un soporte automtico o semi-automtico para el proceso y los mtodos, a estas herramientas se les llama herramientas de la Ingeniera en Computacin Software Asistida (CASE). Para resolver los problemas reales de una empresa, el equipo de ingenieros de SW debe incorporar una estrategia de desarrollo que acompae al proceso, mtodos y herramientas. Esta estrategia a menudo se llama Modelo de Proceso y se selecciona un modelo de proceso segn: La naturaleza del proyecto. La aplicacin que se necesite. Los Mtodos y herramientas a utilizar. Los controles y entregas que se requieran.

54

2.6 EL PROCESO DEL SOFTWARE

Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un producto software en s es complejo, es prcticamente inviable conseguir un 100 porciento de confiabilidad de un programa por pequeo que sea; existe una inmensa combinacin de factores que impiden una verificacin exhaustiva de las todas posibles situaciones de ejecucin que se pueden presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.). Es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos de software similares. Esto hace que los requisitos sean difciles de consolidar tempranamente. As, los cambios en los requisitos son inevitables, no solo despus de entregado un producto sino tambin durante el proceso de desarrollo. El proceso de desarrollo de software no es nico, no existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de software. Contiene tres fases genricas, independientemente del paradigma de ingeniera que se encuentran en todos los desarrollos de software, independientemente del rea de aplicacin, del tamao del proyecto o de la complejidad:

1. Definicin.- Se centra sobre el qu, el que desarrolla el software intenta identificar qu informacin ha de ser procesada, que funcin y rendimiento se desea, qu interfaces han de establecerse, que restricciones de diseo existen y qu criterios de validacin se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los mtodos aplicados durante la fase de definicin variarn dependiendo del paradigma de ingeniera del software aplicado (o combinacin de paradigmas), de alguna forma se producirn tres pasos especficos: a) Anlisis del sistema. El anlisis del sistema define el papel de cada elemento de un sistema informtico, asignando finalmente al software el papel que va a desempear. b) Planificacin del proyecto de software. Una vez establecido el mbito del software, se analizan los riesgos, se asignan los recursos, se estiman los costes, se definen las tareas y se planifica el trabajo. c) Anlisis de requisitos. El mbito establecido para el software proporciona la direccin a seguir, pero antes de comenzar a trabajar es necesario disponer de una informacin ms detallada del mbito de informacin y de funcin del software. 2. Desarrollo.- Se centra en el cmo, el que se desarrolla el software intenta descubrir cmo han de disearse las estructuras de datos y la arquitectura del software, cmo han de implementarse los detalles procedimentales, cmo ha de traducirse el diseo a un lenguaje de programacin (o lenguaje no procedimental) y cmo ha de realizarse la prueba. Los mtodos

55

aplicados durante la fase de desarrollo variarn, pero de alguna forma se producirn tres pasos concretos: a) Diseo del software. El diseo traduce los requisitos del software a un conjunto de representaciones (algunas grficas y otras tabulares o basadas en lenguajes) que describen la estructura de los datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfaz. b) Codificacin. Las representaciones del diseo deben ser traducidas a un lenguaje artificial (un lenguaje de programacin convencional o un lenguaje no procedimental usado en el contexto del paradigma T4G), dando como resultado unas instrucciones ejecutables por la computadora. El paso de la codificacin es el que lleva a cabo esa traduccin. c) Prueba del software. Una vez que el software ha sido implementado en una forma ejecutable por la mquina, debe ser probado para descubrir los defectos que puedan existir en la funcin, en la lgica y en la implementacin.

3. Mantenimiento.- Se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y a las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a reforzar o a ampliar el sistema. La fase de mantenimiento vuelve a aplicar los pasos de las fases de definicin y de desarrollo, pero en el contexto del software ya existente. Durante la fase de mantenimiento se encuentran tres tipos de cambios: a) Correccin. Incluso llevando a cabo las mejores actividades de garanta de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. b) Adaptacin. Con el paso del tiempo es probable que cambie el entorno original (por ejemplo, la UCP, el sistema operativo, los perifricos) para el que se desarroll el software. El mantenimiento adaptativo consiste en modificar el software para acomodarlo a los cambios de su entorno externo. c) Mejora. Conforme utilice el software, el cliente/usuario puede descubrir funciones adicionales que podra interesar que estuvieran incorporadas en el software. El mantenimiento perfectivo amplia el software ms all de sus requisitos funcionales originales.

Adems de estas actividades de mantenimiento bsico, se est forzando a algunas empresas a considerar la ingeniera inversa. Mediante un conjunto de herramientas CASE especializadas se hace ingeniera a la inversa con el software para entender y mejorar su funcionamiento interno. Las fases y sus pasos relacionados descritos en la visin genrica de la ingeniera del software, se complementan con varias actividades protectoras; las revisiones que se realizan durante cada paso para asegurar que se mantiene la calidad. La documentacin que se desarrolla y controla para asegurar que toda la informacin sobre el sistema y el software estar disponible para un uso posterior. El control de los cambios que se instituye de forma que los cambios puedan ser mejorados y registrados. Adems, el marco de trabajo del proceso abarca un conjunto de actividades sombrillas aplicables a lo largo del proceso del software. Como se muestra en la figura 2.8 cada actividad dentro del marco contiene un conjunto de acciones de ingeniera de software; es decir; una serie de tareas relacionadas que producen un producto del trabajo.

56

Marco de trabajo del proceso

Actividades sombrilla Actividades del marco de trabajo #1
Accin de la ingeniera de software #1.1 Conjunto de Producto del trabajo Puntos de aseguramiento Tareas de calidad . Fundamentos del proyecto . Accin de la SW #1.k Conjunto de Tareas
Tareas del trabajo Producto del trabajo Puntos de aseguramiento de calidad Fundamentos del proyecto Tareas del trabajo

. . . Actividades del marco de trabajo #n

Accin de la ingeniera de software #1.1 Conjunto de Tareas
Tareas del trabajo Producto del trabajo Puntos de aseguramiento de calidad Fundamentos del proyecto

Figura 2.8- Marco de trabajo del proceso de software.

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quin debe hacer Qu, Cundo y Cmo debe hacerlo.

57

Prcticas y principios
Actividades

Personas

Herramientas

Proceso SW

Roles

Artefactos

Notacin

Figura 2.9.- Relacin entre elementos del proceso del software.

En la figura 2.9 muestran los elementos de un proceso de desarrollo de software y sus relaciones. As las interrogantes se responden de la siguiente forma: Quin: Las personas participantes en el proyecto de desarrollo desempeando uno o ms Roles especficos. Qu: Un artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones especficas. Las herramientas apoyan la elaboracin de Artefactos soportando ciertas Notaciones. Cmo y Cundo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto est controlado mediante hitos que establecen un determinado estado de terminacin de ciertos Artefactos. La composicin y sincrona de las actividades est basada en un conjunto de principios y prcticas. Las prcticas y principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.

58

2.7 SOFTWARE DE ALTA CALIDAD

La calidad del software tiene diferente significados para distintos grupos. Para el IEEE, es el grado en que un sistema, componente o proceso cumple con los requerimientos especificados y las necesidades del cliente o usuario. En la definicin de la norma ISO- 900 de la Organizacin Internacional para la Estandarizacin (ISO, siglas de International Organizacin for Standardization), la calidad de software es el grado (pobre, bueno o excelente) en que un conjunto de caractersticas inherentes del software cumple con los requisitos del sistema. La calidad del software est directamente relacionada con su proceso de desarrollo. Se considera que un proceso bien conocido y ampliamente utilizado, sustentado en medicin y prediccin de eventos, permite controlar en buena medida la produccin de software y, en consecuencia, producir software de calidad. Los factores que ms afectan la obtencin de un producto de calidad son los siguientes: El cliente o usuario es el participante primordial en el proceso de desarrollo del producto y responsable de definir los requisitos del producto final. El desarrollador es responsable del proceso de produccin y de asegurar la calidad del producto. El proceso seguido para el desarrollo del producto final. El producto correspondiente al sistema a ser desarrollado. Estos factores tienen una estrecha relacin, que afecta tanto a la ingeniera del producto como a la organizacin, la cual debe establecer estndares para los procesos de desarrollo y evaluacin, empleado medidas bien establecidas, que permitan mejorar continuas de los productos. La evaluacin de los procesos evita especificaciones incompletas o anomalas, la aplicacin incorrecta de metodologa, etc. Con el ejemplo de evaluar la calidad de los procesos de software, se define el concepto de modelo de madurez del proceso de produccin de software, que son modelos que apoyan no solo la mejora continua de los procesos de desarrollo de software, sino que tambin la estandarizacin de la produccin en toda la organizacin. Dada la importancia de los procesos, existen diversas certificaciones basadas en los modelos de madurez de proceso que evalan que las empresas digan lo que hacen. La razn adicional para estas certificaciones es que los modelos a menudo requieren cambios en la cultura de la organizacin y una fuente inversin en cursos, como son los financieros, tecnolgicos y humanos. En la tabla 2.2 se muestra un cronograma de algunos estndares y modelos ms importantes para la calidad de software. AO 2000 1999 1998 1997 1996 1995 DESCRIPCCION ISO 9000-2000 SEI CMMI V1.02 PEMM V1.0 ISO 15504(SPICE)(lanzamiento al pblico como Reporte Tcnico tipo 2 TickIT V4.0 ISO 9000-3(nuevo lanzamiento) SEI para las versiones de SW- CMM apoyado a CMM Integracin (CMMI) IEEE/EIA 1227 (corresponde a ISO 12207) TSP ISO 1227 (lanzamiento inicial)

59

1994 1993 1992 1991

1987

ISO 15504 (SPICE)(lanzamiento inicial) PSP ISO 9001 (nuevo lanzamiento) SEI SW-CMMV1.1 TickIT V2.0 ImprovelT V1.0(origen de TickIT) ISO 9000-3(lanzamiento inicial) SEI SW-CMMV1.0(lanzamiento inicial) ISO 9001(lanzamiento inicial)
Tabla 2.2.-Cronograma de estndares y modelos para la calidad del software.

El modelo ms importante en la actualidad para la evaluacin de la madurez de los procesos de desarrollo es el modelo de madurez de capacidades (CMM) del , Instituto de Ingeniera de Software (SEI). CMM tiene como objetivo evaluar los procesos en sus niveles de madurez e identificar los niveles que una organizacin debe formar para establecer una cultura de excelencia en la ingeniera de software. Dentro de la familia de modelos de CMM, se define el modelo para el rea de software, SW-CMM. El marco de trabajo que especifica guas para organizaciones de software que requieren incrementar su capacidad de procesos, considera los siguientes pasos: Identificar fortalezas y debilidades en la organizacin. Ponderar los riesgos de seleccionar entre diferentes contratos y monitorear los mismos. Entender las actividades necesarias para planear e implementar los procesos de software. Ayuda a definir e implementar procesos de software en la organizacin a travs de una gua. Los procesos se evalan mediante distintos niveles de madurez, como se muestra en la figura 2.10 y en la tabla 2.3 se describe detalladamente.

60

Procesos de mejora

Optimizado

contina
Procesos predecibles

Administrado

Procesos estandarizados

Definido

Procesos disciplinados

Repetible

Inicial
Figura 2.10.-Niveles de madurez del proceso del software.

NIVEL 1 INICIAL 2 REPETIBLE

DEFINIDO

4 ADMINISTRADO 5 OPTIMIZADO

LOS CINCO NIVELES DEL MODELO CMM CARACTERISTICAS TRANSICION AL SIGUIENTE NIVEL Ad hoc, poca formacin, Inicia una administracin rigurosa del herramientas aplicadas de proyecto y asegurar la calidad. manera informal al proceso Se cuenta con un proceso Establece un grupo y una arquitectura de estable y un nivel repetible de proceso de desarrollo de software. control estadstico Introducir mtodos y tecnologas de ingeniera de software. Establece un conjunto bsico de administraciones del proceso para Se cuenta con una base para identificar la calidad y costos de los un progreso mayor o continuo. parmetros, y una base de datos del proceso. Juntar y mantener los datos del proceso. Calcular la calidad relativa de cada producto e informar a la administracin. Mejoras sustanciales en la Apoya la recopilacin automtica de datos calidad junto con medidas del proceso. Usar los datos para analizar y compresivas del proceso. modificar el proceso. Mejoras con base en mayor Continuar mejorando y optimizando el calidad y cantidad proceso.
Tabla 2.3.-Niveles de madurez del proceso del software.

61

2.8 FACTORES DE CALIDAD Y PRODUCTIVIDAD

PROCESO DEL SOFTWARE PERSONAL (PSP) Cada desarrollador usa distintos procesos para construir un software, estos pueden ser no eficientes o exitosos o tambin pueden cambiar a diario, pero existe un proceso. Watts Humphrey dice que para cambiar un proceso inefectivo se tiene que pasar por cuatro fases y estas requieren capacitacin e instrumentacin. PSP resalto la medida personal al profesional de la planeacin, tambin hace responsables al profesional de la planeacin del proyecto y la calidad de todos los productos. Existen 5 actividades de marco de trabajo que son: 1. Planeacin: Aqu se selecciona los requisitos y se desarrolla el tamao y la estimacin de los recursos. Estas mediciones se anotan en las plantillas y al final se identifican las tareas de desarrollo y se crea un programa del proyecto. 2. Diseo de alto nivel: Se analizan los factores externos y se construyen prototipos cuando hay incertidumbre. 3. Revisin del diseo de alto nivel: Se aplican los mtodos de verificacin a los errores que se descubrieron en el diseo. 4. Desarrollo: Se refina, se revisa el diseo, se verifica el cdigo y se compila, adems todas las mediciones se guardan para los resultados de trabajo. 5. Anlisis de resultados: Aqu se determina la efectividad del proceso, analizando todos los datos que se tienen. El PSP destaca que cada ingeniero tiene la necesidad de identificar los errores y de entender la importancia y los tipos de errores que suelen cometerse. La calidad del software desarrollado, as como la productividad del programador son factores de difcil, pero no imposible, medida. Existen una serie de factores que inuyen en la calidad y productividad que ayudan a realizar dicha medida que son: 1. La capacidad individual.- En este factor intervienen la competencia del individuo y su familiaridad con el rea de la aplicacin. 2. La comunicacin entre los miembros del equipo.- Es un factor importante, ya que el trabajo en la mayor parte de las ocasiones no es individual y debe integrarse con el que ha sido desarrollado por otros miembros del equipo. 3. La complejidad del producto.- Este factor depende del tipo de aplicacin a desarrollar y es de difcil estimacin, ya que muchas veces hasta la fase de desarrollo no es posible comprender en toda su perspectiva las complicaciones que conlleva su realizacin. 4. Utilizacin de una notacin adecuada.- Este factor es de gran importancia para facilitar la comunicacin entre las partes involucradas (incluido el usuario).

62

5. Empleo de mtodos sistemticos.- Es importante que se empleen tcnicas que sean de amplio consenso y bien conocidas por los integrantes del equipo de desarrollo de la aplicacin. Tambin es fundamental que estas tcnicas se empleen de manera sistemtica sobre todas las aplicaciones de caractersticas semejantes con objeto de facilitar el anlisis de coste y tiempo, y tambin para poder observar la trayectoria profesional de los miembros del equipo. 6. Conocer el tiempo disponible.- Este factor est vinculado a otros anteriores, ya que es bsico conocer el tiempo que puede aportar cada miembro del equipo y en que plazos, sobre todo en funcin de las tareas a realizar y de la mejor o peor productividad de determinados miembros en cada una de ellas. 7. Existencia de facilidades y recursos externos.- Es determinante en la medida en que se conozcan productos o herramientas (automticas o no) que faciliten las labores de desarrollo e integracin de la aplicacin. En mayor medida cuando se conocen aplicaciones parecidas de fcil trasportabilidad y modicacin que puedan servir de base a la que hay que realizar. Como en el resto de las actividades industriales, en el desarrollo de software, tambin es importante realizar una buena planicacin del trabajo y una buena asignacin de recursos a los distintos miembros del equipo. Una mala planicacin termina con una mala aplicacin o una aplicacin terminada a destiempo (disgusto del peticionario), lo cual supone un fracaso. Varios fracasos consecutivos de este mismo estilo suponen la ruina para la mayor parte de las empresas del sector, debido a la competencia existente. Los sistemas de software tiles son complejos, para seguir siendo tiles necesitan evolucionar con las necesidades de los usuarios finales y el ambiente de destino. En algunos casos los desarrolladores no anticiparon situaciones que ocurren rara vez (una persona que vive ms de cien aos, aos bisiestos que tienen un impacto en las fechas de caducidad). En otros casos los desarrolladores no anticiparon que el usuario hara mal uso del sistema (la opresin de un botn, la exploracin de las facilidades de depuracin del envi de correo). En otros casos las fallas del sistema resultaron por fallas de administracin (entrega tarda y con presupuesto excedido, entrega a tiempo de un sistema incorrecto, complejidad innecesaria). Los sistemas de software son creaciones complejas: realizan muchas funciones, estn construidos para lograr muchos objetivos diferentes y con frecuencia conflictivos, comprenden muchos componentes, muchos de sus componentes son en s mismo complejos y hechos a la medida, muchos participantes de disciplinas diferentes intervienen en el desarrollo de estos componentes, el proceso de desarrollo y el ciclo de vida del software a menudo abarcan muchos aos y, por ltimo, los sistemas complejos son difciles de comprender por completo para una sola persona. Muchos sistemas son tan difciles de comprender, incluso durante su fase de desarrollo, que nunca llegan a ser terminados: a estos se les llama vaporware. Los proyectos de desarrollo de software estn sujetos a cambio constantes debido a que los requerimientos son complejos, necesitan ser actualizados cuando se descubren errores y cuando los desarrolladores tienen una mejor comprensin de la aplicacin. Si el proyecto dura muchos aos, la rotacin de personal es alta y requiere entrenamiento constante. El tiempo entre los cambios tecnolgicos con frecuencia es ms corto que la duracin del proyecto. La suposicin ampliamente difundida entre los gerentes de proyecto de software de que hay que abordar todos los cambios y que los requerimientos pueden congelarse, conduce a que se despliegue un sistema irrelevante.

63

EJERCICIOS UNIDAD II

1. Cul es el propsito del modelado? 2. Un lenguaje de programacin es una notacin para la representacin de algoritmos y estructuras de datos. Liste dos ventajas y dos desventajas del uso de un lenguaje de programacin como notacin nica a lo largo del proceso de desarrollo. 3. Considere una tarea con la que no est familiarizado, como el diseo de un automvil con cero emisiones de contaminantes. Cmo podra atacar el problema? 4. Qu significa la adquisicin de conocimiento no es lineal? Proporcione un ejemplo concreto de adquisicin de conocimiento que ilustre esto. 5. Plantee una fundamentacin hipottica para las siguientes decisiones de diseo: a. El distribuidor de boletos ser, a lo mucho, de un metro y medio de alto. b. El distribuidor de boletos incluir dos sistemas de computo redundantes. c. El distribuidor de boletos incluir una pantalla sensible al tacto para el desplegado de instrucciones y entrada de comandos. El nico control adicional ser un botn de cancelacin para abortar la transaccin. 6. Especifique cuales de los siguientes enunciados son requerimientos funcionales y cuales son requerimientos no funcionales: a. El distribuidor de boletos debe permitir que un viajero compre pases semanales. b. El distribuidor de boletos debe estar escrito en java. c. El distribuidor de boletos debe ser fcil de usar. 7. Especifique cuales de las siguientes decisiones se tomaron durante el levantamiento de requerimiento o durante el diseo de sistema: a. El distribuidor de boletos est compuesto por un subsistema de interfaz de usuario, un subsistema para calcular la tarifa y un subsistema de red para manejar la comunicacin con la computadora central. b. El distribuidor de boletos usara chips de procesador PowerPC: c. El distribuidor de boletos proporciona ayuda en lnea al viajero. 8. Cul es la diferencia entre una tarea y una actividad? Un avin de pasajeros est compuesto por varios millones de partes individuales y requiere miles de personas para ensamblarlo. Un puente de autopista de cuatro carriles es otro ejemplo de complejidad. La primera versin de Word para Windows, un procesador de palabras lanzado por Microsoft en noviembre de 1989, requiri 55 aos hombre, dando como resultado 249,000 lneas de cdigo fuente y fue entregado con 4 aos de retraso. Los aviones y los puentes de autopista por lo general se entregan a tiempo y por debajo de su presupuesto, mientras que con el software a menudo no es as. Discuta cuales son, en su opinin, las diferencias entre el desarrollo de un avin, un puente y un procesador de palabras que pueden causar esta situacin.

64

PARADIGMAS DE LA INGENIERA DE SOFTWARE

3.1 El Enfoque Estructurado 3.1.1 Diagramas de Flujos de Datos 3.1.2 Diccionarios de Datos 3.1.3 Diseo de Mdulos 3.1.4 Descomposicin en Procesos

3.2 El Enfoque Orientado a Objetos 3.2.1 Anlisis Objetos 3.2.2 Diseo Objetos

65

3.1 EL ENFOQUE ESTRUCTURADO

Definiciones de anlisis estructurado: El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin. No se establece cmo se cumplirn los requerimientos o la forma en que implantar la aplicacin. Ms bien permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadoras, terminales, sistemas de almacenamiento, etc.) Despus de esto se puede desarrollar un diseo fsico eficiente para la situacin donde ser utilizado. El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Permite al analista conocer un sistema o proceso (actividad) en una forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente. Significado de estructurado Qu es lo que se desea estructurar? Qu significa estructura? El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener la comprensin completa y exacta de una situacin dada. A partir de aqu se determinan los requerimientos que sern la base de un sistema nuevo o modificado. En el anlisis estructurado, la palabra estructura significa que:

1. El mtodo intenta estructurar el proceso de determinacin de los requerimientos comenzado con la documentacin del sistema existente 2. El proceso est organizado de tal forma que intenta incluir todos los detalles relevantes que describen al sistema en uso 3. Es fcil verificar cundo se han omitido detalles relevantes 4. La identificacin de los requerimientos ser similar entre varios analistas e incluir las mejores soluciones y estrategias para las oportunidades de desarrollo de sistemas 5. Los documentos de trabajo generados para documentar los sistemas existentes y propuestos son dispositivos de comunicacin eficientes.

La capacidad del analista de sistemas para captar el flujo de la informacin se facilita debido al uso de los mtodos de anlisis y de diseo estructurado. Existen varios mtodos para realizar el anlisis de flujo de datos. De los sistemas orientados a datos: los DFD, el diccionario de datos, etc. Dispone de la libertad conceptual que le ofrecen los diagramas de flujo de datos (DFD), que caracterizan grficamente el flujo de datos dentro del sistema empresarial. En su estado original, los DFD presentan una visin, lo ms amplia posible de las entradas al sistema, los procesos y las salidas.

66

Una vez que se concluyen los diagramas de flujo de datos en distintos niveles sucesivos, los analistas de sistemas los utilizan para ayudarse a catalogar los procesos, el flujo, el almacenamiento, las estructuras y los elementos de un diccionario de datos. Los nombres utilizados para identificar los datos son de gran importancia; al nombrar a los elementos de los sistemas orientados a datos, deben utilizar nombres significativos que los distingan de otros nombres ya existentes en el sistema.

3.1.1 DIAGRAMAS DE FLUJOS DE DATOS

Cuando se indagan sobre los requisitos de informacin de los usuarios, se debe ser capaz de interpretar la manera en que los datos fluyen a travs de la organizacin, los procesos o transformaciones que sufren tales datos y sus tipos de salidas. Se agrupan en un esquema grfico, los movimientos del flujo de los datos a lo largo de la organizacin, mediante el uso de DFD. El enfoque de flujo de datos enfatiza la lgica que sustenta al sistema, por medio de slo cuatro smbolos, se debe crear una descripcin pictrica de la informacin, que eventualmente proporcionar una documentacin slida del sistema. El enfoque del flujo de datos, tiene tres ventajas principales a la explicacin narrativa, sobre la manera en que la informacin fluye a travs del sistema. Tales ventajas son: 1. La libertad de contar con rapidez con una implantacin tcnica del sistema. 2. La comprensin adicional de la relacin existente entre los sistemas y los subsistemas. 3. La comunicacin a los usuarios del estado actual del sistema, mediante los DFD.

Tal vez la ventaja principal radica en la libertad conceptual de hacer uso de slo cuatro smbolos. Porque, aunque el analista especifica que los datos se almacenarn en un punto particular, el enfoque de flujo de datos no lo obliga a especificar el medio de almacenamiento y esto permite a los analistas conceptualizar el flujo de datos antes de comprometerse prematuramente a la realizacin. Adems tiene como ventaja adicional servir como un ejercicio til para los analistas de sistemas, al capacitarlos para comprender mejor las relaciones entre los sistemas y los subsistemas. Una aplicacin interesante reside en mostrarle al usuario una representacin incompleta de la visin que el analista tiene del sistema. Luego se les pedira a los usuarios que presentaran sus comentarios sobre la precisin de la conceptuacin del analista, y que ste incorporara los cambios que reflejen con mayor precisin las perspectivas del sistema por parte del usuario.

Para representar el flujo en un DFD se utilizan cuatro smbolos bsicos, que son: un cuadro doble, una flecha, un rectngulo con esquinas redondeadas y un rectngulo abierto por una de sus caras (cerrado por la izquierda y abierto por la derecha), ver la figura 3.1, todo un sistema completo y numerosos subsistemas pueden representarse grficamente con la combinacin de estos cuatro elementos.

67

Entidad

Flujo de datos

Proceso

Almacn de datos

Figura 3.1.- Smbolos bsicos del diagrama de flujo.

El cuadrado doble representa una entidad externa (una empresa, una persona o una mquina) que da y recibe datos del sistema. A esta entidad externa se le denomina tambin como fuente o destino de los datos y tiene una connotacin externa durante el estudio. Cada entidad externa se identifica por medio de un nombre apropiado, aunque interacciona con el sistema se considera externa fuera del lmite del sistema. La flecha representa el movimiento de datos de un punto hacia otro, donde la punta seala el destino de los datos. El flujo de informacin que ocurre de manera simultnea puede representarse por medio de dos flechas paralelas. Un rectngulo con sus esquinas redondeadas indicar la existencia de un proceso de transformacin. Los procesos siempre denotan un cambio o transformacin de los datos, y es por ello que el flujo de informacin que sale, siempre tendr un nombre diferente al que hubiera tenido al entrar. El rectngulo abierto representa el almacenamiento de la informacin en los DFD el tipo de almacenamiento fsico (esto es, cinta, diskette, etc.) no se especifica. En este punto, el smbolo de almacenamiento de datos, simplemente indica un depsito de datos, el cual permite la adicin y acceso de los datos. En la figura 3.2 puede observarse la manera en que los DFD comienzan con el enfoque ms amplio posible de las entradas, los procesos y las salidas del sistema que se estudia. A esto se le denomina nivel cero. Los niveles sucesivos de un DFD se muestran, donde el proceso dos se divide o descompone en dos subprocesos: 2.1 y 2.2.

68

NIVEL 0 DEL DIAGRAMA DE FLUJO DE DATOS

FUENTE DE DATOS

Flujo de Datos 1

1 Proceso 1 Flujo de Datos 2

Flujo de Datos 3

2 Proceso 2

Flujo de Datos 5

DESTINO F DE l DATOS u

Flujo de Datos 4
D2 ALMACEN DE DATOS 2

j o

D1

ALMACEN DE DATOS 1

d e D

NIVEL 1 DEL DIAGRAMA DE FLUJO DE DATOS

a t

Proceso 2 (particionado) 1 Proceso 1 Flujo de Datos 3 2.1 SubProceso 2.1 2.2 SubProceso 2.2 Figura 3.2.- Diagramas de flujo de datos en nivel 0 y 1. Flujo deDatos 4
D2 ALMACEN DE DATOS 2

o s Flujo de Datos 5 DESTINO DE DATOS 5

Figura 3.2.- Diagrama de Flujo de datos en nivel 0 y 1.

Un ejemplo de un diagrama de flujo de datos Recientemente, un grupo de mdicos y cirujanos, con especialidades en ojos, odos, nariz y garganta se asociaron para colaborar como un grupo. Piensan que si trabajan en colaboracin seis de ellos, podrn cubrir la ausencia de un doctor sin interrumpir el tratamiento del paciente. Tambin intentan alcanzar cierta economa de escala por medio de la centralizacin de funciones comunes, tales como la facturacin, la programacin de las citas, el pago de gastos indirectos por reas de oficinas y el pago de seguros y suministros.

69

Los mdicos contrataron a un analista de sistemas para establecer la manera de obtener ventajas de los posibles beneficios de agrupar sus oficinas. Despus de entrevistar a los doctores y a sus dos recepcionistas y recopilar ciertas formas representativas que utilizan los mdicos, el analista dibuj un sencillo diagrama, que se muestra en la figura 3.3. Algunas personas lo denominan diagrama de contexto. Un diagrama de contexto presenta un esbozo del sistema. Note que todas las entidades o fuentes, MEDICOS, PACIENTES Y ASEGURADOS toman un nombre, al generar los flujos de los datos principales del sistema. Sin embargo, los procesos permanecen a este nivel sin numerar ni describir.

Registro del examen

MEDICOS

CORREDORES DE SEGUROS

Forma de seguros llenada

Sistema de cobro
Factura al seguro

PACIENTES

Factura al paciente

Figura 3.3.- Igualacin del diagrama del flujo Nivel 0 y el de contexto.

La figura 3.4 es un DFD de nivel cero del sistema de facturacin de los mdicos. Se puede observar que es un DFD que ilustra el movimiento de los datos a lo largo del sistema de facturacin, comenzando en la parte superior izquierda y dirigindose hacia abajo y a la derecha. Comienza con la entidad externa MEDICOS, quienes, despus de examinar al paciente, generan un flujo de datos llamado REGISTRO DE EXAMEN, el cual se aleja de ellos. Este flujo de datos se dirige al proceso llamado REVISAR EL REGISTRO DE EXAMEN Y CALCULAR LOS CARGOS. Para poder hacerlo, el proceso muestra el acceso al almacn de datos denominado TARIFAS, el cual tiene la tarifa para el cobro de los servicios mdicos. Un flujo de datos que parte de TARIFAS llamado TARIFA POR COBRAR, fluye hacia el proceso REVISAR. Note que el proceso 1 ser el REVISAR EL REGISTRO DEL EXAMEN Y CALCULAR LOS CARGOS.

70

Una vez que el registro del examen se verifica y se ha consultado el catlogo de tarifas, el proceso da lugar a un nuevo flujo de datos llamado CARGOS VALIDOS, el cual se dirige al proceso 2 llamados PREPARAR FACTURAS. La otra entidad externa, PACIENTES, contribuye con un flujo de datos llamado FORMA COMPLETA DE SEGUROS que se dirige al proceso 2. Para PREPARAR FACTURAS de manera correcta, un almacn de datos llamado REGISTRO DE PACIENTES se consulta con el fin exclusivo de obtener la direccin de algn paciente. Un nuevo flujo de datos, FACTURA DEL PACIENTE puede fluir desde el proceso 2. Observe que para PREPARAR FACTURAS de manera correcta, debe consultarse el almacn de datos COMPAIAS DE SEGUROS. Un nuevo flujo de datos DIRECCIN Y PROGRAMA DE SEGUROS se dirige al proceso PREPARAR FACTURAS. Fuera del proceso 2, se crean dos nuevos flujos de datos que se dirigen paralelamente. El primero a considerar ser el de FACTURA DEL PACIENTE, que tiene como destino a la entidad externa PACIENTES. Observe que para evitar un entrecruzamiento de lneas de flujo, la entidad externa PACIENTES se dibuja nuevamente, con una diagonal, como indicio de un segundo planteamiento de la misma entidad. Los PACIENTES emiten un nuevo flujo de datos hacia el proceso 3, REVISAR EL PAGO DE LOS PACIENTES. Una vez que el pago ha sido revisado, por medio del proceso 3, se transforma en un flujo de datos denominado PAGO CORRECTO DEL PACIENTE, el cual se dirige a un almacn de datos denominado CUENTAS POR COBRAR. Un nuevo flujo de datos, PAGO DEL CORREDOR, se inicia en CORREDORES DE SEGUROS y se dirige al proceso 4 REVISAR PAGOS DEL CORREDOR DE SEGUROS. Cuando el PAGO DEL CORREDOR se procesa en el PAGO CORRECTO DEL CORREDOR se enva al almacn de datos CUENTAS POR COBRAR. Observe que la implantacin fsica del sistema no se cubre a propsito, con el fin de concebir de forma libre el movimiento de los datos a lo largo del sistema. En este punto, el analista de sistemas elabora los diagramas del sistema sin limitarse por tratar de definir si los procesos seran automatizados o manuales. Adems, observe que la lgica para el clculo de las tarifas y los procesos no se documenta con los DFD; sin embargo, ms adelante, el analista tendr que definir tal lgica. Aunque una visin general del sistema es un buen comienzo, se requiriere de ms detalles de cada uno de los procesos para entender cabalmente el movimiento de los datos a lo largo del sistema. La figura 3.5 es una visin detallada del proceso 2, PREPARAR FACTURAS. El proceso de PREPARAR FACTURAS se integra en realidad por tres procesos separados, REVISAR SI EL PACIENTE TIENE SEGURO, COMPARAR SU CUENTA CON LA CANTIDAD PROGRAMADA, y CALCULAR LA CUENTA REMANENTE PARA EL PACIENTE. Note que REVISAR SI EL PACIENTE TIENE SEGURO describe qu es lo que se realiza y no cmo ser realizado. En esta etapa del anlisis, no es apropiado especificar el cmo. Mientras que las entradas y las salidas bsicas siguen siendo las mismas, el nmero de procesos se expande para revelar una mayor complejidad del sistema. Como se imaginar, los diagramas de flujo de datos pueden descomponerse an ms y dar una imagen muy detallada del flujo de la informacin.

71

MEDICOS

PACIENTES

Registro del examen

Forma de seguros llenada

Tarifas
1 2

Factura para el seguro

Verificar el registro del examen y calcular las tarifas

vlidas de Datos 5

Preparar las facturas

Factura del paciente

CORREDORE S DE SEGUROS

PACIENTES

Direccin del paciente

Tarifas aplicables Pago del paciente D1 CATALOGO DE TARIFAS

Pago del corredor de seguros

P l

D2 REGISTRO DEL PACIENTE

D3

COMPAIAS DE SEGUROS

Verificar el pago de los d pacientes

e

n3

Pago correcto del paciente

s e g u r o s
D4

Verificar el pago del corredor de seguros

Pago correcto del corredor de seguros CUENTAS POR COBRAR

d i Figura 3.4.- Diagrama de flujo de datos de nivel 0 desarrollado por el analista de sistemas para un sistema mdico de facturacin.r e c c i n

72

PREPARAR FACTURAS

PACIENTES

Tarifas vlidas

Forma de seguros llenada Datos 5 2.1

Verificar el registro del examen y calcular las tarifas

Verificar si el paciente est asegura do

Informacin sobre seguros y tarifas 2.2 Comparar la cuenta con la cantidad estableci da

D3

COMPAIAS DE SEGUROS

Factura para el seguro

CORREDORES DE SEGUROS

Plan de seguros y direccin

Cantidad del paciente 2.3 Calcular el remanent e de la cuenta del paciente Factura del paciente PACIENTES

D2

REGISTRO DEL PACIENTE

Direccin del paciente

Figura 3.5 Un diagrama de flujo de datos (de nivel 1) particionado del proceso PREPARAR FACTURAS.

73

Los DFD pueden y deben dibujarse de manera sistemtica. La figura 3.6 resume los pasos involucrados en la elaboracin eficaz de un DFD.

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS

1. Desarrolle el diagrama de flujo de datos mediante el enfoque descendente (top-down). a) Haga una lista de las entidades externas, los flujos de datos, los procesos y los almacenes de datos. Esto determinar los lmites del sistema que desarrolla. b) Dibuje un diagrama de flujo de datos bsico que ilustre exclusivamente los aspectos generales.

2. Cubra los detalles. a) Por pasos aada ms detalle a cada proceso. b) Indique excepciones cuando stas se requieran

3. Dibuje de nuevo los diagramas y vuelva a definir todos los smbolos por medio de nombres significativos Figura 3.6 Pasos a seguir en un diagrama de flujo de datos

Figura 3.6.- Pasos a seguir en un diagrama de flujo de datos.

Enfoque de lo general a lo particular Se tiene que interpretar al flujo de datos desde una perspectiva general a lo particular, que se puede realizar a partir de la narracin del sistema organizacional, haciendo uso de cuatro categoras: entidad externa, flujo de datos, proceso y almacn de datos. Esta lista, en su momento, permitir determinar los lmites del sistema que se describe. Tan pronto se compile la lista bsica de los datos elementales, puede inicializar la elaboracin del diagrama de contexto. El primer diagrama, de nivel cero, debe tener una visin que incluya lo bsico de las entradas, los procesos y las salidas. Es la concepcin ms amplia posible del sistema. A este enfoque se le denomina de lo general a lo particular .

74

Cubriendo los detalles Se llena los DFD agregando los detalles de cada uno de los procesos. Mediante la descomposicin de los diagramas se obtiene un mayor grado de detalle. Cuando se dibuja el primer diagrama las entradas y las salidas se definen, y se mantienen constantes a lo largo de los diagramas consecutivos. El manejo de las excepciones se ignora en los primeros dos o tres niveles de dibujo del DFD. Sin embargo, el resto del diagrama original se descompone mediante diagramas detallados de tres a nueve procesos, agregando en cada nivel inferior nuevos almacenes de datos y nuevos flujos de datos. Cada diagrama que se descomponga de tres a nueve procesos debe caer en una hoja sencilla de papel. Al descomponer los DFD en subprocesos, los analistas de sistemas comienzan a llenar los detalles del movimiento de los datos. Debe evaluarse el grado de descomposicin de los flujos de datos ya que se perdera tiempo y se sacrificara comprensin si el diagrama de flujo de datos se volviera demasiado complejo. Por otra parte, si los diagramas de flujo de datos se descomponen o detallan en forma insuficiente, pueden presentarse errores de omisin.

Mejoras de la comunicacin a travs de leyendas significativas Una vez que los DFD se aclaran, el tercer paso a realizar es volverlos a dibujar y rotularlos de manera significativa para comprender sin duda alguna la lgica del recorrido de los datos a travs del diagrama de flujo de datos; sin embargo, si se desea que los diagramas sean un verdadero elemento de comunicacin, debern incorporarse leyendas significativas para todos los datos. Los rtulos no deben ser muy genricos pues dirn poco de la situacin particular. Todos los modelos generales de sistemas se apegan a la configuracin de entrada, proceso y salida. De tal forma que los rtulos de los DFD deben ser ms especficos que esto ltimo. Cada vez que sea posible se debe unificar los trminos de tal forma que slo se tengan unos cuntos trminos para el mismo dato. Parte de la efectividad de los DFD se debe a que mantienen su consistencia de pgina a pgina (mantener en forma consistente las mismas entradas y salidas entre todos los diagramas). El mismo nivel de consistencia deber mantenerse durante el rotulado.

El uso de DFD Los DFD son de gran utilidad en el anlisis y diseo de procesos, desde el principio se debe utilizar DFD sin detallar para establecer los requisitos de informacin. En esta etapa pueden ser tiles para obtener una visin global de las corrientes de datos del sistema. Esto dar una perspectiva visual no disponible en datos narrados. Una vez que descomponga los DFD originales, se utiliza para una interaccin adicional con los usuarios. En esta etapa, el DFD est mostrando su particular concepcin de las corrientes de datos del negocio. Se enseara a los usuarios claves, las convenciones que utilice en los DFD, y luego realice los niveles consecutivos. Pedir opinin sobre todo de aquello que pudiera aclarar el proceso o permitiera lograr una mayor precisin en los diagramas. Despus, incorporar las modificaciones de los usuarios; y luego, tanto el grupo de anlisis como los usuarios debern aprobar los DFD como un reflejo preciso del flujo de datos de la organizacin. Finalmente, los DFD sirven para documentar al sistema. Pueden utilizarse para documentar niveles superiores e inferiores del anlisis. Los DFD auxilian de manera sustancial a concebir la lgica de los flujos de datos de la organizacin.

75

En la actualidad se cuenta con excelentes apoyos que evitan el tedio y la impresin asociada al dibujo manual de los diagramas de flujo de datos. Esto forma parte de lo que se denomina tecnologas de herramientas integradas (workbench) o, de manera alternativa, instrumentos CASE.

3.1.2 DICCIONARIOS DE DATOS

El diccionario de datos es una referencia de datos acerca de los datos (esto es, meta datos) recopilados para guiarse durante el anlisis y el diseo. Como documento, recopila, coordina y confirma lo que un trmino especfico significa para la gente de la organizacin. Los diccionarios de datos automatizados son valiosos porque permiten la referencia cruzada de los datos sencillos, ya que los cambios necesarios de los programas pueden realizarse en todos los programas que comparten elementos comunes. Esto sustituye a los cambios expuestos en los programas, o a esperar que el programa no funcione, ya que el cambio no haba sido implantado en todos los programas que comparten el dato actualizado. Tambin los diccionarios de datos automatizados son relevantes para los grandes sistemas que producen varios miles de datos elementales que requieren ser catalogados y contar con referencias cruzadas. Datos que contiene el diccionario de datos Una manera de saber lo que debe contener el diccionario de datos, es visualizar cmo llegar a utilizarse. Es el elemento bsico de referencia para localizar los nombres y atributos de los datos utilizados en todo el sistema de la organizacin. Por esto es que deber incluir todos los datos sencillos; sin embargo, conviene visualizar como evolutiva a la documentacin. Mientras que un diccionario de datos pueda incluir numerosos elementos, nunca estar concluido. De hecho, deber actualizarse cada vez que se hagan cambios, como ocurrira para cualquier otro tipo de documentacin. Con el fin de ser de utilidad, los registros del diccionario de datos deben contener informacin referente a las categoras siguientes: 1. El nombre y el sinnimo del dato (alias).- Contiene el nombre de cada dato; esto es, la manera de denominar el dato en la mayora de los programas. Diferentes programas o departamentos pueden utilizar un vocabulario particular para datos sencillos comunes, de tal forma que el diccionario de datos debe contener el nombre ms comn del dato, as como el sinnimo. Todo esto debe quedar registrado en el diccionario de datos, para facilitar la comunicacin y la referencia cruzada entre los departamentos y sus programas. 2. Las descripciones del dato.- La descripcin textual del dato debe ser elemental, la cual debe ser concisa (aproximadamente tres frases), pero informativa para cualquiera que la consulte. 3. Los datos elementales que se relacionan con el trmino. 4. El rango permitido del dato.- Junto con el nombre, el sinnimo y la descripcin de cada dato elemental, el diccionario de datos debe incluir los distintos rangos y lmites que se aplican al elemento. Por ejemplo, el lmite sobre la cantidad disponible para retiro de un elemento llamado cuenta de cheques ser la cantidad real en la cuenta, al momento del retiro. El rango significa el intervalo disponible de datos; por ejemplo, el nmero del mes puede ser mayor o igual a 1 y menor o igual a 12. 5. La longitud disponible en caracteres.- La longitud del dato elemental no debe exceder de once caracteres, incluyendo las dos diagonales. La longitud siempre se da en funcin del nmero de caracteres impresos y no por la cantidad requerida de memoria.

76

6. Una adecuada codificacin.- Cada dato debe incorporarse al diccionario de datos junto con su cdigo, si es que lo tiene, y el significado de ste. Es indispensable que la codificacin sea consistente. 7. Cualquier otra informacin pertinente de edicin.- La informacin requerida para asegurar la edicin adecuada de los datos debe estar presente en el diccionario de datos. Esto incluye a cualquier orden pertinente. Cuando el diccionario de datos se integra de manera correcta, es til para el desarrollo del sistema, su modificacin y mantenimiento. Es de gran utilidad el diccionario de datos si cada entrada se registra de manera consistente, incluyendo el nombre del dato, el sinnimo, su descripcin, los elementos relacionados, el rango, la longitud, la codificacin y cualquier otra informacin necesaria para su edicin. Los diagramas de flujo de datos sirven como punto de partida para el diccionario de datos.

Aunque es un proceso redundante y no necesariamente sigue una secuencia lineal, se tienen cuatro pasos esenciales para integrar un diccionario de datos, los cuales se enumeran en la figura 3.7. Como se plante aqu, es posible tomar ventaja del enfoque de lo general a lo particular para construir los DFD, al seleccionar de manera sistemtica el material para el diccionario de datos.

77

Paso 1 Proceso

Paso 2 Flujo de datos y Almacenamiiento de datos

Paso 3 Estructura de datos

Paso 4 Datos elementales

Figura 3.7.-Pasos para construir un diccionario de datos

78

Incorpore el proceso. Incorpore aquellos procesos que descubra en los DFD inciales. Estos son aquellas transformaciones esenciales que el sistema debe realizar con el fin de cumplir sus objetivos. Catalogue los flujos bsicos de datos. Catalogue los flujos bsicos que entren y salgan de los procesos plasmados en los DFD. En la misma etapa, catalogue tambin los almacenes de datos que contengan los datos fundamentales para la operacin adecuada de los procesos. Describa la estructura de los datos. Describa la estructura de los datos (los grupos relacionados de datos elementales) que existan dentro del sistema. Tanto los flujos como los almacenes de datos alimentan a las estructuras de los datos. Desglose la estructura de los datos en datos elementales. Se refiere al trabajo con los componentes de significado ms simple del sistema, los cuales son los datos elementales. Estos son los bloques bsicos para la construccin de los sistemas y deben conformar todos ellos las estructuras de los datos. El diccionario de datos ideal se encuentra automatizado, y adems es interactivo, en lnea y evolutivo para conocer ms de los sistemas de la organizacin y se puede crear en forma paralela al anlisis y diseo de los sistemas. Para tener el potencial mximo, el diccionario de datos debe estar relacionado con otros programas, para que cuando un dato se actualice o elimine del diccionario de datos, de manera automtica, se actualice o elimine de la base de datos porque se puede convertir en una curiosidad histrica si no se actualiza. Los diccionarios de datos automatizados logran mejoras dramticas en la documentacin. Para ello, tambin llegan a cambiar la rutina de los analistas de sistemas. Aunque la tendencia se dirige hacia los diccionarios de datos automatizados en lnea, es relevante apreciar la importancia de integrar (aun de manera manual) un diccionario de datos, que sea comn para la organizacin. Si comienza temprano ahorrar muchas horas del tiempo del anlisis y del diseo. El diccionario de datos de la organizacin llega a ser una fuente comn de informacin de la organizacin, para resolver incgnitas y disputas sobre aspectos relativos a la definicin de los datos sirve como excelente referencia para el mantenimiento de sistemas poco familiares. Catlogo de los procesos de datos. Comience en el nivel superior del DFD, catalogando los procesos esenciales. Se ilustra un ejemplo de formas usadas para catalogar un PROCESO en la figura 3.8. El proceso se tom del diagrama de flujo de datos mostrado antes en la figura 1.4, REVISAR EL REGISTRO DE EXAMEN Y CALCULAR LOS CARGOS. Observe que la tarjeta contiene el nombre del proceso, as como una designacin simblica en su esquina superior derecha, indicando que el proceso se est catalogando. Despus, se describe brevemente el proceso. Luego se tiene un registro de las entradas al proceso, un resumen del proceso y las salidas del proceso.

79

V E R - E X AMEN - Y - C A L C U L AR TA R I F A S

Descripcin

Verificar el registro del examen y clculo de las tarifas

Entradas Descripcin del proceso
Verificar el registro del examen. Si se encuentra completo calcular las tarifas con base en el tiempo del registro del examen y aplicar las tarifas a partir del catlogo de tarifas. .

Salidas
Tarifas Validas

Registro del del examen Tarifas

Figura 3.8.- Tarjeta de diccionario de datos para el proceso denominado VERIFICAR-EXAMEN-YCALCULAR-TARIFAS.

Un nuevo flujo de datos, TARIFA VLIDA, que es resultado del proceso, se cataloga en la tarjeta, como se muestra en la figura 3.9. Observe que el nombre del flujo de datos se encuentra en la parte superior y que en el extremo superior derecho se tiene el smbolo del dato catalogado. Se anotan la fuente del flujo de datos (REVISAR EL REGISTRO DE EXAMEN Y CALCULAR LOS CARGOS) y el destino (PREPARAR FACTURAS). El nmero de movimientos que fluyen a travs del sistema se registra como la magnitud de la informacin, en este caso, alrededor de 100 por da. Despus llenar una tarjeta para el almacn de datos al que se tiene acceso. Esta tarjeta se ilustra en la figura 3.10, para el almacn de datos TARIFAS. Acompaando al nombre se encuentra en la esquina superior derecha la representacin simblica de este elemento. De manera similar a las dos tarjetas anteriores, proporciona una breve descripcin de TARIFAS

T AR I F A - V A L I DA

Descripcin:

Tarifa correcta por los servicios realizados en base a las tarifas establecidas y verificacin del registro del examen.

Fuente
Verificar el examen y calcular la tarifa

Destino
Preparar la factura Volumen
Alrededor de 100/da

Estructura de datos que viaja con el flujo

Figura 3.9.- Tarjeta del diccionario de datos para el flujo de datos denominado TARIFA-VALIDA.

80

A diferencia de las otras dos tarjetas consideradas, la tarjeta del almacn de datos requiere de una columna de flujo de datos entrante, de la que se carece en este caso, pues el proceso de acceso slo es de consulta y no se llega a modificar a las TARIFAS. Tambin pide los flujos salientes, que seran cualquiera de las tarifas de los mdicos. Tambin en la tarjeta del almacn de datos hay un lugar para anotar el contenido, donde podemos observar el interior de los datos almacenados y ver su composicin.

T A R I F A S

Descripcin Catlogo de las tarifas de los servicios bsicos que realizaron los mdicos. Contenido

Tarifas

Categora del examen tarifas regulares tarifas por emergencias

Flujos de datos salientes

Flujos de datos entrantes

Tarifas aplicables

Figura 3.10 Una tarjeta del diccionario de datos para el almacn de datos denominado TARIFAS.

En la figura 3.11 hay una forma para registrar una estructura de datos, tal como FACTURA DEL PACIENTE. Recuerde que las estructuras de los datos se componen de los datos elementales relacionados. Se requiere el nombre de la estructura de los datos, as como la representacin simblica en la esquina superior derecha; como en las otras tarjetas, se tiene una breve descripcin. Observe que varios datos elementales integran la FACTURA DE PACIENTE, adems el registro requiere enumerar los flujos de datos relacionados y el volumen de FACTURA DEL PACIENTE que ser procesado en base mensual.

P A C I E N T E - F A C T U R A

Descripcin breve Enviar la cuenta al paciente Descripcin (Utilice un * para iteraciones) Identificacin de la factura Fecha factura Informacin paciente Nombre paciente Nmero paciente Direccin del paciente Seguro del paciente Informacin de servicios *(1- ) Costo de los servicios Cobrar al paciente
Flujos relacionados

Factura del paciente

Volumen 3000 mes

Figura 3.11.- Tarjeta del diccionario de datos para la estructura de datos PACIENTE-FACTURA.

81

El quinto y ltimo tipo de elemento del diccionario de datos es el ms bsico, el dato elemental. Recuerde que los datos elementales son aquellos datos dentro del sistema que no tienen significado alguno si se llegaran a descomponer an ms. En la figura 3.12 el diccionario de datos muestra el registro para un dato elemental llamado CIASEGURO (breve versin de compaa de seguros). Una vez ms, se requiere el nombre del dato elemental, as como la designacin de que es un registro para un elemento, en la esquina superior derecha. Tambin se da una breve descripcin textual, as como cualquier sinnimo y el contexto dentro del cual pudiera encontrarse. En la parte derecha de la forma, se especifica si el dato elemental es alfabtico, numrico o de cdigo alfanumrico, su rango de valores y la longitud requerida en caracteres. Observe que una lista de valores y su significado se proporciona para el dato elemental en CIASEGUROS, por lo tanto CA significa Cruz Azul, SA significa Seguro Azul y as sucesivamente. Desarrolle un heurstico al nivel de detalle que usted requiera para el registro, y de manera consistente mantenga su aplicacin.

C I A - D E

S E GU R O S

Descripcin breve

Un cdigo de dos letras para el corredor de seguros CLAVE-SEC (lista de correos)

Si es discreto Valor BC BS MM HM MO Significado Blue Cross Blue Shield Mutualidad Mdica HMO Mutualidad de Omaha

Sinnimos (contextos)

Alfabtico Alfanumrico Numrico

Sies continuo: Longitud Rango

Si son ms de cinco valores, utilice el reverso de la tarjeta o tarjetas adicionales.

Figura 3.12.- Tarjeta del diccionario de datos para el dato elemental denominado CIA-SEGUROS.

En la figura 3.13 se presenta el registro de otro dato elemental NUMERO DE PACIENTE. Adems de los mismos detalles particulares que requieren las otras entidades, se tiene el cdigo del NUMERO DE PACIENTE. Por el registro en el diccionario de datos, es aparente que con seis mdicos que operan el sistema, el valor de los primeros dos dgitos del NUMERO DEL PACIENTE seran 01, 02, 03, 04, 05 06, dependiendo del mdico que atiende al paciente en su primera visita. Los cdigos del mdico nunca van sin el cdigo del paciente (no tienen significado en el sistema) y, en consecuencia, no se consideran como un dato elemental. La segunda parte del NUMERO DEL PACIENTE es el cdigo del paciente, asignado con secuencia, donde todos los valores comienzan despus de 10000. Un cajero debe percatarse que un cdigo que contenga 00008 en los ltimos cinco dgitos del NUMERO DEL PACIENTE estara en un error. El cdigo del paciente nunca se utiliza slo en el sistema, sin acompaarse por el cdigo de mdico, de forma tal que tampoco se trata como un dato elemental.

82

NUM E R O

DE

PA C I E NT E

Descripcin breve

Sinnimos (contextos)

Identifica al paciente para propsito de la facturacin NUM-DE-PAC (lista de publicaciones)

Si es discreto Valor NN - NNNNN Significado (Los ltimos cinco dgitos se asignan de manera secuencial) 2 primeros dgitos Nombre del doctor 01 Watson 02 Holmes 03 Moriarty Si son ms de cinco valores, utilice el reverso de la tarjeta o tarjetas adicionales.

Alfabtico Alfanumrico Numrico

Si es contino: Longitud Rango

Figura 3.13.- Tarjeta del diccionario de datos para el dato elemental NUMERO-DE-PACIENTE.

La determinacin de la longitud del campo se muestra en la figura 3.14 se puede observar el porqu una determinacin correcta de la longitud de campo es tan importante al compilar un registro del diccionario de datos. La figura muestra la factura que el mdico enva al paciente, al final del mes correspondiente al tratamiento. Los cargos requieren slo de tras lugares a la izquierda del punto decimal, ya que no hay servicio alguno por el cual los mdicos cubren ms de $999.99. Sin embargo, es posible que el total del cargo por los servicios mdicos exceda tal cantidad y la longitud calculada para el campo neto debe considerar un espacio para $9, 999,99, incluyendo la coma y el punto decimal.

Drs. Watson, Holmes, Moriarty, Arthur, Conan, y Doyle 2880 S. 70th Street Lincoln, Nebraska 68506 Fecha de realizacin Del servicio Descripcin del servicio realizado Tarifa
MM/DD/YY MM/DD/YY MM/DD/YY MM/DD/YY XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX Totales Neto 999.99 999.99 999.99 999.99 9.999.99 9.999.99

Crdito
999.99 999.99 999.99 999.99 9.999.99

Figura 3.14.- Longitud de los campos se determinan en la construccin del DD.

83

3.1.3 DISEO DE MDULOS

Mdulo.- Fragmento de programa casi independiente que habitualmente tiene un nombre y algunas instrucciones y datos propios. Un mdulo se llama desde otro mdulo y, de forma similar, invoca otros mdulos. Unidad sintcticamente bien formada de acuerdo con las reglas del lenguaje de programacin en uso Coleccin de declaraciones, en principio ocultas, respecto a toda accin o declaracin ajena al propio mdulo, es decir definidas en un mbito de visibilidad cerrado Modularidad.- Divisin de software en porciones manejables, mdulos independientes, o agrupacin de items mutuamente afines.

El objetivo del diseo de mdulos es conseguir una visin del software como una estructura jerrquica de mdulos. Cuando aumenta la complejidad de los problemas, es necesario dividirlos en subproblemas para facilitar su resolucin. Cada subproblema se aborda independientemente, combinando las subsoluciones para llegar a la solucin final. La programacin modular se basa en la creacin de unidades llamadas mdulos, que agrupan datos y procedimientos relacionados entre s. La filosofa de este paradigma es la ocultacin de datos: se agrupan un conjunto de procedimientos relacionados junto con los datos que manipulan en una misma unidad (modulo). Los datos solo deben ser accesibles a travs de los procedimientos del modulo. Cada modulo tiene una interfaz bien definida, que permite un uso fcil por parte de otros mdulos. Adems, cada uno es desarrollado independientemente de los dems. Esto requiere la posibilidad de compilacin separada. Los mdulos ofrecen un segundo nivel de ocultacin de informacin, no solo con respecto a los algoritmos, sino tambin a los datos.

Ideas fundamentales: Reducir el esfuerzo de desarrollo Separacin entre estructuras de datos y procedimientos Independencia funcional: Cada mdulo debe realizar una tarea concreta que afecte lo menor posible al resto Ocultamiento de Informacin: La informacin de un mdulo es inaccesible para el resto de mdulos Un buen diseo modular consiste en contemplar nuestros futuros algoritmos como una jerarqua de mdulos perfectamente comunicados entre s, donde cada uno de ellos cuente con un objetivo diferenciado, como si fueran piezas de una mquina que pudiesen ser utilizadas para construir otras mquinas. Ver figura 3.15. PASOS EN EL DISEO MODULAR Seleccin/Diseo de tipos de datos Seleccin/Diseo de estructuras de datos necesarias Seleccin/Diseo de algoritmos para procesar la informacin

84

PROGRAMA PRINCIPAL

MODULO 1

MODULO 2

MODULO 3

MODULO 5

MODULO 4

MODULO 5

MODULO 6

Fig. 3.15.-Diseo de Mdulos.

De forma ms especfica se siguen los siguientes pasos: 1. Diseo de la arquitectura. Determinacin de las estructuras a gran escala, poca modularidad es igual a problemas posteriores. 2. Diseo de mdulos. Mdulo con un propsito bien definido, con conexiones claras a otros mdulos, si la arquitectura es modular, el diseo de los mdulos es ms sencillo. 3. Depuracin. Fcil de hacer en el interior de cada mdulo. 4. Verificacin. Verificacin virtualmente imposible en el sistema completo, mejor en partes. 5. Mantenimiento. Lo ms conveniente es hacer el cambio en un solo mdulo, con la confianza de que los otros mdulos no se van a ver afectados. 6. Desarrollo independiente. Entre distintos miembros de equipo ya que independiza la codificacin, interfaz entre mdulos claros y limitados. 7. Reutilizacin del software. "No reinventar la rueda".

3.1.4 DESCOMPOSICIN EN PROCESOS

Los procesos se descomponen en subprocesos, hasta llegar a los procesos primitivos. DESCOMPOSICIN FUNCIONAL: a) b) c) procesos. d) Cada proceso se puede explotar, refinar o descomponer en un DFD ms detallado. El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerrquicamente. Los niveles de la jerarqua estn determinados por la descomposicin funcional de los La raz de la jerarqua es el diagrama de contexto, que es el ms general de todos.

85

El diagrama de contexto se utiliza para entender mejor las reglas de produccin.

P Sist

Destino

Fuente

GENERAL - PARTICULAR
X
V

P F2

P F4

P F5

P F1
A

P F43
X1

X2

P F45

P F3
X

P F44
Y1

P F42
Y

Figura3.16.- Ejemplo de la descomposicin de un Diagrama de Flujo de Datos (DFD).

Consistencia de DFD: Cada proceso en un diagrama padre es una consolidacin del DFD hijo. Balanceo de DFDs: Las E/S de un proceso padre deben corresponder con las E/S del DFD hijo que lo explica. Jerarqua de DFD s: En un DFD completo cada proceso tiene un nmero nico que lo identifica en funcin de su situacin en la jerarqua. Cada DFD tiene tambin un nmero nico que coincide con el proceso que describe. Las hojas o nodos terminales corresponden a proceso primitivos o in descomponibles. Para cada proceso primitivo existir una mini especificacin.

Y2

P F41

86

3.2

EL ENFOQUE ORIENTADO A OBJETOS

Los conceptos de anlisis y diseo orientados a objetos (OO) se originaron a partir de desarrollos en los lenguajes modernos de programacin. Estos lenguajes OO tienen nuevas estructuras que se siente que mejoran el mantenimiento del programa y hacen que grandes partes de los programas sean reutilizables. El consecuente reciclado de partes de programa debe reducir el costo de desarrollo de los sistemas basados en computadora. Se cree que las tcnicas orientadas a objetos son mejores que los enfoques ms antiguos para el manejo del ritmo de cambio cada vez ms grande en muchas de las organizaciones actuales. Por ejemplo, muchos productos estn siendo hechos cada vez ms bajo pedido o fabricados en lotes pequeos, conforme los fabricantes buscan mayor concentracin sobre la satisfaccin del cliente y la penetracin de mercado chino. Esta tendencia significa cambios frecuentes al software que est integrado con estos productos. El cambio constante de personas y responsabilidades significa una necesidad cada vez mayor para el rpido desarrollo y mantenimiento de sistemas. Se piensa que las tcnicas OO trabajen bien este tipo de situaciones, donde sistemas de informacin complicados estn sufriendo mantenimiento, adaptacin y rediseo continuos (reingeniera). Fueron desarrollados para dar soporte a la tecnologa de programacin OO; no fue una evolucin instantnea, sino la evolucin de un conjunto de conceptos algo desconectados que han sido puestos juntos para formar un nuevo paradigma para la ingeniera del software. Por ejemplo, la programacin OO toma su concepto de encapsulacin de la idea de ingeniera de software de la abstraccin de datos, y su concepto de herencia a partir de la idea de base de datos de generalizacin y especializacin. Debido a que el anlisis y diseo OO est fuertemente relacionado con la programacin OO, se debe explorar brevemente el contexto de programacin OO antes de proceder al anlisis y diseo OO. Seis ideas bsicas caracterizan a la programacin OO: 1).-Objetos.- Es una representacin en computadora de alguna cosa o evento del mundo real. La figura 3.13 muestra cmo una computadora podra representar un auto. Por ejemplo si se trata de un Jeep Wrangler, la computadora podra guardar el nombre del modelo, el nmero ID del vehculo (#51Y62BG826341Y) y el tipo de motor (6-Cil). Los objetos pueden tener tantos atributos (tales como el modelo, VIN y tipo de motor) y comportamientos (tales como encender luz y apagar luz).

Jeep Wrangler

#51Y62BG826341Y

6-Cil

Figura 3.17.- Ejemplo de los atributos de un objeto de la clase Automviles.

87

2).-Clases.- Define el conjunto de atributos y comportamientos compartidos que se encuentran en cada objeto de la clase y se agrupan en clases; la figura 3.14 muestra cmo un grupo de objetos que representan automviles podran estar formados en una clase llamada Automviles. Por ejemplo, todo automvil tendr atributos para fabricante/modelo, VIN, y motor. El programador debe definir las clases en el programa, cuando el programa ejecuta se pueden crear objetos a partir de las clases establecidas.

Automviles

Marca/Modelo

VIN

Motor

Figura 3.18.- Los atributos compartidos de los objetos se agrupan en la clase.

3).-Mensajes.- Se puede enviar informacin de un objeto a otro, como en la figura 3.15 un objeto (Gloria) de la clase Operador est enviando un mensaje a un objeto (Jeep) de la clase Automviles. El mensaje es arrancar motor; estos mensajes no son de forma libre en ningn sentido, ya que en vez de eso las clases Operador y Automviles han sido programadas cuidadosamente para enviar y recibir un mensaje de arrancar motor.

Automviles

Jeep Wrangler

#51Y62BG826341Y

6-Cil

Arrancar motor Operador

Kim McCabe

001-64-9532

Caf

Figura 3.19.- Ejemplo de la informacin que puede ser enviada por un objeto de una clase a otro.

88

4).-Encapsulacin.- Tpicamente, la informacin acerca de un objeto est encapsulada por su comportamiento. Esto significa que un objeto mantiene datos acerca de cosas del mundo real a las que representa en un sentido verdadero. A un objeto se le debe pedir o decir que cambie sus propios datos con un mensaje, en vez de esperar que tales datos de procesos externos cambien la naturaleza de un objeto, en la figura 3.16 el objeto Bruce (clase Mecnico) enva un mensaje Quitar motor al objeto Jeep (clase Automviles); la clase Automviles reacciona a este mensaje con un comportamiento (tambin llamado mtodo o procedimiento) que cambia el atributo de motor a Ninguno. Este mtodo es llamado Quitar motor, se ve que el objeto Jeep reacciona al mensaje cambiando uno de los atributos a Ninguno. Puede parecer trivial el que un atributo de un objeto sea cambiado alterando directamente sus datos o enviando un mensaje al objeto para que active el comportamiento interno que cambia ese dato. Pero esta diferencia es una caracterstica extremadamente importante de los programas O-O. Los datos encapsulados pueden ser protegidos en forma tal que solamente el objeto mismo puede hacer tales cambios por medio de su propio comportamientos. Esta construccin facilita la construccin de objetos que son muy confiables y consistentes, debido a que ellos tienen control completo sobre sus propios atributos.

Automviles

Jeep Wrangler
Arrancar motor

#51Y62BG826341Y
Parar motor
Instalar motor

Ninguno
Quitar motor

Mecnico

Quitar motor

Bruce Lione

001-45-6630

Caf

Figura 3.20.-Mensaje de un objeto hace que otro objeto de una clase diferente cambie uno de sus atributos.

5).-Herencia.-Son las clases que pueden tener hijos, esto es, una clase puede ser creada a partir de otra clase. La clase original, o madre, es llamada clase base. La clase hija es llamada clase derivada. Una clase derivada puede ser creada en forma tal que herede todos los atributos y comportamientos de la clase base. En la figura 3.17 se crea una clase derivada (Camin) en forma tal que hereda todos los atributos de la clase base Automviles. Una clase derivada puede tener tambin atributos y comportamientos adicionales. Por ejemplo, la clase Camin no solo tiene atributos para fabricante/modelo, VIN y motor, sino tambin tiene atributos para carga, remolques y refrigeracin. Los objetos Automviles no tienen estos nuevos atributos.

89

La herencia reduce la labor de programacin reutilizando fcilmente objetos antiguos. El programador slo necesita declarar que la clase Camin hereda de la clase Automviles, y luego proporcionar cualquier detalle adicional acerca de nuevos atributos o comportamientos (mostrados en el cuadro de lnea continua de la figura). Todos los atributos y comportamientos antiguos de la clase Automviles son parte automtica e implcitamente de la clase Camin (se muestra en el cuadro de guiones) y no requiere ninguna nueva programacin. Algunos lenguajes de programacin O-O proporcionan herencia mltiple. En estos casos especiales se puede crear una clase derivada en forma tal que herede todos los atributos y comportamientos de ms de una clase base.

Automviles

Marca/Modelo
Camin: hereda Automviles

VIN

Motor

Capacidad de carga Marca/Modelo

Cantidad de remolques

Refrigeracin Motor

VIN

Figura 3.21.- Ejemplo de herencia de atributos de una clase madre por una clase hija.

6).-Polimorfismo.- Comportamientos alternos entre clases derivadas relacionadas. Cuando varias clases heredan atributos y comportamientos, puede haber casos donde el comportamiento de una clase derivada deba ser diferente del de su clase base o de sus clases derivadas parientes. Esto significa que un mensaje puede tener diferentes efectos, dependiendo de exactamente qu clase de objeto recibe el mensaje. En la figura 3.18 vemos tres clases: archivo, archivo ASCII y archivo de mapa de bits. Tanto ASCII como mapa de bits heredan todos los atributos de archivo, a excepcin del comportamiento imprimir. Un mensaje para activar el comportamiento Imprimir de un objeto de la clase archivo madre genrica puede causar que se impriman los atributos tamao de archivo, tipo de archivo y fecha/hora. El mismo mensaje enviado a un objeto ASCII podra causar que se enviara el texto del archivo a la impresora. El mismo mensaje enviado a un objeto de mapa de bits podra causar que ejecutara un programa de desplegado grfico.

90

Tamao de archivo

Tipo de archivo

Fecha/Hora

Imprimir

Archivo ASCII: hereda Archivo Delimitador Tamao de registro

Imprimir

Archivo de mapa de bits: hereda Archivo Imprimir Color/Monocromtico Resolucin

Figura 3.22.- Ejemplo de polimorfismo entre clases relacionadas.

3.2.1 ANLISIS

El enfoque de Coad y Yourdon para el anlisis Orientado a Objetos (O-O) est basado en un modelo de cinco capas; la figura 3.19 ilustra cmo se entrelazan estas cinco capas que aaden una estructura tridimensional a la notacin de anlisis y diseo que da mayor poder para la representacin de complejidad en sistemas flexibles.

Capa Clase y Objeto

Capa de estructura

Capa de servicio Capa de atributos

Capa de tema

Figura 3.23.- Capas del anlisis orientado a objetos.

91

1. CLASE/OBJETO. Esta capa del anlisis y diseo indica las clases y objetos en las siguientes formas: a. Objeto: Es una abstraccin de algo en un dominio de un problema que refleja las capacidades de un sistema para llevar informacin acerca de ello, interactuar con ello o ambas cosas. Una encapsulacin de valores de atributos y sus servicios exclusivos. Sinnimo: una ocurrencia. b. Clase: Una descripcin de uno o ms objetos con un conjunto de atributos y servicios uniformes, incluyendo una descripcin de cmo crear nuevos objetos en la clase. c. Clase y objeto: Un trmino que se refiere tanto a la clase como a los objetos que ocurren en la clase. Hay cinco tipos generales de objetos que pueden descubrirse durante el anlisis. Los objetos a veces representan cosas tangibles como vehculos, dispositivos y libros. Algunas veces los objetos representan papeles actuados por personas u organizaciones. Los papeles incluyen objetos como cliente, propietario o departamento. Los objetos tambin pueden ser derivados de incidentes o eventos, tales como vuelo, accidente o reunin. Los incidentes suceden tpicamente en un momento especfico. Otros objetos pueden indicar interacciones tales como una venta o un matrimonio. Las interacciones tienen una cualidad de transaccin o contrato. Los objetos tambin pueden detallar especificaciones. Las especificaciones tienen estndares o una cualidad de definicin y, por lo general, implican que otros objetos representarn ocurrencias de cosas tangibles. Por ejemplo, una clase de objetos tales como tipo de pliza de seguro puede tener ocurrencias como por toda la vida, plazo de vida o propietarios de casas. Tal tipo de clase de objetos especifica cualidades comunes a determinadas ocurrencias de otra clase de objetos llamados pliza de seguros. En la figura 3.20 se muestra la notacin para Clase, Objeto y Clase y Objeto. Las clases son representadas por cuadros rectangulares redondeados (bubtngulos) divididos en tres partes. El nombre de la clase se muestra en la divisin superior del cuadro. Las otras dos divisiones se usan para las capas de atributo y servicio. Cuando una clase aparece sin objetos, puede ser solamente una clase ase para agrupar atributos y servicios que sern heredados por varias otras clases. Los objetos que tienen ocurrencia de una clase son representados por un cuadro sombreado rodeado por la clase. Debido a que los objetos tienen ocurrencias de una clase, no es posible que los objetos existan independientemente de su clase. Debido a esta dependencia, algunas notaciones no distinguen entre clases y objetos. Sin embargo, Coad y Yourdon proporcionan la notacin clase y objeto para distinguir grficamente entre estructuras y mensajes que estn orientados hacia la clase (tales como un mensaje crear una nueva ocurrencia de un objeto) de estructuras y mensajes orientados al objeto (tal como Quitar motor).

Clase

Objetos

Los objetos nunca existen sin una clase.

Conexiones a objetos

Clase y Objeto

Conexiones a clases

Figura 3.24.- Notacin que representa los conceptos Clase, Objeto y Clase y Objeto.

92

Las tcnicas para describir objetos son bsicamente las mismas para descubrir procesos y entidades de datos. Sin embargo, hay determinados criterios que se puede usar para que nos ayuden a determinar si se justifica una nueva clase de objetos: i. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un sentido definido y sus atributos son relevantes para el problema. ii. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque un objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto que deben ser llamados. iii. Usualmente un objeto tendr varios atributos. Los objetos que tienen solamente uno o dos atributos sugieren diseos sobre analizados. iv. Usualmente una clase tendr ms de una instancia de objeto, a menos de que sea una clase base. v. Usualmente los atributos tendrn siempre un valor significativo para cada objeto de la clase. Los objetos que producen un valor NULO para un atributo, o para los que no es aplicable un atributo, por lo general implican una estructura generalizacin-especializacin. vi. Usualmente los servicios siempre se comportarn en la misma forma para todos los objetos de una clase. Los servicios que varan dramticamente para algunos objetos de una clase o que regresan sin realizar accin para algunos objetos tambin sugieren una estructura generalizacinespecificacin. vii. Los objetos deben implementar requerimientos que son derivados del problema y no de la tecnologa de solucin. La parte de anlisis del proyecto O-O no debe llegar a ser dependiente de una tecnologa de implementacin particular, tal como un sistema de computadora especfico o un lenguaje de programacin especfico. Los objetos que atienden tales detalles tcnicos no deben aparecer sino hasta muy tarde en la etapa de diseo. Los objetos dependientes de la tecnologa sugieren que el proceso de anlisis tiene fallas. viii. Los objetos no deben duplicar atributos o servicios que pueden ser derivados de otros objetos en el sistema. Por ejemplo, un objeto que guarda la edad de un empleado es superfluo cuando existe un objeto de empleado separado que conserva el atributo fecha de nacimiento. El objeto edad puede ser eliminado por un servicio edad que es componente del objeto empleado. 2. ESTRUCTURA. Esta capa captura diversas estructuras de clases y objetos, tales como las relaciones uno a muchos y la herencia. Existen dos tipos bsicos de estructuras que deben ser impuestas en las clases y objetos. Estas son: a. ESTRUCTURAS GEN-SPEC(estructura generalizacin-especializacin).La herencia se crea con las estructuras Gen-Spec. Estas relaciones entre clases son a veces llamadas relaciones de clasificacin, subtipo o ISA. Son indicadas por un semicrculo con su lado redondo hacia la clase generalizada. Estas estructuras siempre conectan clases a clases. Son tpicamente de forma jerrquica. La figura 3.21 muestra una estructura Gen-Spec entre Clases y Objetos en donde las clases Autobs y Motocicleta heredan todas las propiedades de la clase Automviles. b. ESTRUCTURAS TODO-PARTES. Estas estructuras indican conjuntos de diferentes objetos que componen otro objeto completo. Tales relaciones entre objetos son a veces llamadas relaciones de ensambles, agregaciones o TIENEUN. Las estructuras Completo-parte son indicadas por un tringulo que apunta hacia el objeto completo. Estas estructuras conectan siempre objeto con objeto. La figura 3.22 muestra una estructura Todo-partes, en donde se muestran los objetos Vehculo estando compuestos de dos otros objetos: Motor y Chasis. Las estructuras Todo-partes tambin tienen cardinalidad, representada por uno a muchos y muchos a muchos. La notacin 0, m especifica que un vehculo puede no tener motor (0) o uno o ms motores (m). La notacin 0,1 especifica que un motor puede ser parte de ningn vehculo (0) o de un vehculo (1), pero nunca de ms de uno. El 1, m especifica que un vehculo puede tener uno o ms chasis, pero nunca menos de uno. El 1 especifica que un chasis siempre est relacionado con uno y solo un vehculo.

93

Figura 3.25.- Ejemplo de la estructura Gen-spec.

0, m

1, m

0.1

Figura 3.26.-Ejemplo de la estructura Todo-partes.

3. SERVICIOS. Esta indica los mensajes y comportamientos del objeto (servicios y mtodos). Tambin llamados mtodos o procedimientos, llegan a ser parte de los objetos, en forma muy similar a los atributos. Debido a que los servicios involucran frecuentemente cambios en el estado de un objeto, son ms comnmente analizados y diseados usando diagramas de estado. Por consecuencia, el anlisis de servicios consiste de tres actividades: anlisis del estado del objeto, especificacin de servicio y especificacin de mensaje.

94

a. Anlisis del estado del objeto..- Se puede descubrir cambios de estado ms fcilmente encontrando los atributos de cada objeto que afectan el comportamiento del objeto. Mientras se examina cada atributo, se debe preguntar, Cambiar el comportamiento del objeto cuando cambie el valor de este atributo? Cuando ningn atributo cambia el comportamiento del objeto, pero todava se sabe que el objeto se comportar diferente bajo ciertas condiciones, se debe probablemente aadir un atributo de estado. Por ejemplo, si se est analizando un carro de tren que tomar y dejar pasajeros, se sabe que el tren debe comportarse diferente en reaccin a un mensaje descargar pasajeros, dependiendo de si el tren est detenido en una plataforma de estacin o balancendose en una va recta a 90 millas por hora. La figura 3.24 ilustra un diagrama de estado para una variable de estado para tal carro de tren. La flecha en la parte superior del cuadro Estado = Detenido muestra que el estado inicial cuando el objeto es creado es siempre Detenido. Las otras flechas muestran cambios de estado posibles, por ejemplo, de Detenido a en Movimiento o de Detenido a Descargando. Observe que no hay forma para cambiar estados de en Movimiento a Descargando. Esto previene lgicamente que el objeto descargue pasajeros mientras est en movimiento. Los diagramas de estado son aadidos conforme se necesita a las plantillas de especificacin para documentar tales atributos de estado.

0, m 1

Figura 3.27.- Ejemplo de dos clases y sus atributos respectivos.

b. Especificaciones en servicio.-Son categorizado como simple (involucran muy pocas condiciones u operaciones, y frecuentemente se aplican a cada Clase y Objeto en un sistema. Crear objeto, almacenar objeto, recuperar objeto, conectar objeto (hacer una ocurrencia de conexin), acezar objeto (obtener o poner los valores de los atributos) y borrar objeto. Son implcitos y muy obvios) o compuestos (involucran ciclos, muchas operaciones o condiciones compuestas, se aplican tpicamente a solamente una Clase y Objeto y frecuentemente ocasionan servicios compaeros o privados que son similares a los mdulos de subrutinas). c. Especificaciones de mensajes.- Detallan cmo el comportamiento de un objeto puede activar el comportamiento de otro objeto. Esto es, los mensajes son generados por un objeto con la intencin de activar un servicio en otro objeto, documentan la dependencia de un proceso sobre otro proceso en un objeto diferente. Los mensajes existen solamente para comunicarse entre servicios, y ocasionan flujo de control y flujo de datos.

4. ATRIBUTOS. Esta capa detallas los atributos de las clases. Como se muestra en la figura 3.23; los atributos Pnombre y Pdireccin han sido puestos en capa sobre el objeto Propietario, y los atributos Modelo y Color han sido puestos en capa sobre el objeto Vehculo. La idea bsica de un atributo queda sin cambiar, sin embargo, tres nuevas ideas relacionadas son relevantes desde la perspectiva orientada a objetos. Primero, los atributos son siempre ms propensos al cambio que las clases. Si una estructura o un conjunto de clases parecen estar amontonndose, debido a que un objeto est cambiando de clase a clase, tal vez la Clase y Objeto en cuestin debiera simplemente llegar a ser un conjunto de atributos en otra clase. Segundo, los atributos deben ser mantenidos tan

95

altos como sea posible en las estructuras Gen-Spec. Esta restriccin reduce la programacin y mantenimiento, debido a que un cambio hecho en un objeto Gen ser automticamente heredado por todos los objetos Spec. Tercero las asociaciones o relaciones entre objetos (aparte de las estructuras) deben ser detalladas como conexiones de ocurrencia, en vez de llaves forneas. En vez de amontonar el paquete de diseo con tales detalles de implementacin, no se especifican los atributos de llave primaria. Por consecuencia, las referencias entre objetos, tales como asociaciones y relaciones, se indican por una sola lnea entre los objetos con la misma notacin cardinal usada en las estructuras Todo-partes. Observe que las conexiones de ocurrencia suceden siempre entre objetos y no entre clases. Por ejemplo, existe una conexin de instancia entre los objetos Propietario y Vehculo. Las notas de cardinalidad nos dicen que un propietario puede estar relacionado con cero, uno ms vehculos, pero un vehculo siempre debe estar relacionado con un solo propietario. Con la introduccin de los atributos necesitamos detalles de anlisis adicional para dar soporte al paquete de diagrama en capas. En esta etapa del anlisis estos detalles toman en cuenta solamente descripciones de los atributos y restricciones de sus valores. Coad y Yourdon recomiendan una plantilla de especificacin que proporcione un esquema similar al diccionario de datos. Esta plantilla puede ser luego expandida y modificada conforme contina el anlisis.

Estado = detenido

Estado = en movimiento Estado = detenido

Figura 3.28.- Diagrama de estado, de una variable de estado para carros de tren en un sistema de monorriel.

5. TEMA. Esta divide el diseo en unidades de implementacin o asignaciones de equipos. En el caso de sistemas muy grandes, podemos usar una capa adicional en el paquete de diagrama en capas O-O para organizar el trabajo de anlisis, diseo e implementacin. Esta capa proporciona un medio para subdividir una especificacin compleja en unidades de trabajo lgicas. Una capa de tema es solamente necesaria en proyectos grandes que involucran muchas clases. Los temas son resaltados trazando una lnea de guiones ancha que indica las fronteras de un tema particular en el diagrama O-O. El nombre del tema se anota en una esquina del cuadro de tema. Por lo general, un tema tendr una clase propietaria aparente. Esta es una clase que est conectada centralmente con todas las clases y objetos en el espacio del tema. Tpicamente el tema toma nombre por esta clase.

96

3.2.2 DISEO OBJETOS

Las actividades de diseo en el enfoque de Coad y Yourdon llevan las herramientas de anlisis hacia delante hacia el juego completo de especificaciones para la implementacin. Donde el anlisis es razonablemente independiente de la tecnologa, las actividades de diseo llegan a ser cada vez ms orientadas hacia un lenguaje O-O particular y ambiente de desarrollo. Las actividades de diseo O-O estn agrupadas en los cuatro componentes principales del sistema final: el componente de problema, el componente de interfaz humana, el componente de manejo de datos y el componente de manejo de tareas. Cada una de las cinco capas del diseo O-O es expandida conforme se necesita a lo largo de los cuatro componentes de implementacin. La figura 3.25 muestra cmo interactan estos elementos para completar el diseo de sistema.

Componentes

Capas
Capa Clase y

objeto estructura Capa de Capa de servicio Capa de atributos Capa de tema

Figura 3.29.- Elementos de diseo O-O agrupados en componentes y capas.

Toda la documentacin del anlisis debe llevar directamente hacia la etapa del diseo. En este punto se necesitan pocas herramientas nuevas. El paquete de diagrama en capas y la plantilla de especificacin siguen siendo los componentes principales del diseo. Estos documentos no son complementados o reemplazados, sino que, en vez de ello, son ampliados para incluir los detalles de implementacin restantes durante la fase de diseo. Frecuentemente se usa prototipos durante la fase de diseo. Se crean versiones burdas de los objetos y se prueban en sus papeles con los cuatro componentes. Esto significa que frecuentemente el paquete de diseo se enva hacia los programadores con partes del cdigo de programa ya escrito. Los diseadores usarn frecuentemente el lenguaje de implementacin esperado como el mecanismo para escribir especificaciones completas para las clases. Por ejemplo, el diseador puede encontrar que es fcil copiar la definicin de clases C++ de un prototipo operacional en la especificacin. Esto puede probar que significa menos trabajo para el diseador y elimina esfuerzos duplicados por parte de los diseadores y programadores de implementacin.

97

El componente de dominio problema (PDC) es el conjunto bsico de objetos funcionales que llega de la etapa de anlisis. Estos objetos resuelven directamente el problema que se pretende sea resuelto por el sistema que se est construyendo. Los otros componentes, tales como la interfaz humana y el manejo de datos, son funciones incidentales que deben ser aadidas al PDC para hacer que trabaje. Por consecuencia, el diseo del PDC se termina en su mayor parte en la etapa del anlisis. Solamente se necesitan tres actividades para completar el diseo de PDC: 1. DISEO DE REUSO.- Tal vez se quiera aadir nuevas clases al PDC para rehusar objetos. Por ejemplo, hay paquetes comerciales de clases altamente generalizadas para objetos. Una organizacin de programacin O-O con experiencia, por lo general posee una biblioteca de clases desarrollada en casa para los objetos. Estas bibliotecas y paquetes pueden contener clases que tienen atributos y servicios para objetos similares a los requeridos en nuestro diseo. Podemos aadir esas clases reusables a nuestro diseo como clases base en una estructura Gen-Spec. Las clases derivadas en estas estructuras Gen-Spec son las clases desarrolladas originalmente en la etapa de anlisis. 2. ESTRUCTURAS DE IMPLEMENTACI.- Tal vez se quiera aadir otras estructuras al diseo, simplemente por razones de implementacin; tambin, tal vez se quiera usar estructuras de agregacin para crear puntos de entrada naturales para listas o filas, o una estructura Gen-Spec para permitir que varias clases de objetos compartan un protocolo o estructura de datos. Estas estructuras usan el concepto de herencia para hacer mucho ms fcil la tarea de programacin. 3. ACOMODO AL LENGUAJE.-Tal vez se necesite corregir el diseo para que las estructuras puedan ser construidas en el lenguaje de programacin seleccionado, debido a que estos lenguajes pueden tener diferentes patrones de herencia. Algunos lenguajes incluyen herencia mltiple, otros solamente incluyen herencia simple y todava otros no incluyen herencia. En los casos ms restrictivos, los patrones de herencia del diseo deben ser modificados para permitir las capacidades del lenguaje de implementacin. Diseo del componente de interfaz humana En esta actividad se crea los mens, reportes y pantallas interactivas que usarn las personas para trabajar con el sistema. Estas actividades son bsicamente sobre el diseo de la interfaz de usuario. Sin embargo, en el contexto de diseo O-O esta fase culmina en una especificacin para nuevas clases componente de interfaz humana (HIC) que deben ser aadidas al diseo. Por lo general, se puede apoyar en gran forma en clases de biblioteca para el diseo de clases HIC. Esta es un rea donde la reusabilidad de las clases O-O ha probado ser muy efectiva. Las clases de biblioteca generalmente proporcionan generalizaciones de mens, ventanas, control de ratn, iconos, control de tipo de letra y utileras de cortar y pegar. Los prototipos son muy tiles durante el diseo HIC para suavizar cmo trabajarn las clases de biblioteca con los objetos PDC, la interaccin del usuario con los prototipos puede proporcionar informacin extremadamente til acerca de la efectividad del diseo.

Diseo de los componentes de administracin de tarea y datos Estos dos componentes estn enlazados muy fuertemente con la tecnologa de implementacin. El manejo de tareas est muy determinado por la configuracin de hardware de computacin, y el manejo de datos est muy determinado por el software de sistemas disponible cuando el sistema est de hecho en ejecucin. El componente de manejo de tareas (TMC) es ms importante cuando el sistema est ejecutando en varios procesadores o computadoras. Una tarea es un conjunto de servicios relacionados que deben ejecutar juntos (tal vez en el mismo procesador). Las tareas son activadas por el tiempo transcurrido o

98

por un evento. Los objetos del TMC obedecen a activadores de tarea, asignacin de procesadores y prioridades cuando son llamados los servicios. El componente TMC aparece, por lo general, como se muestra en la figura 3.26. Este nuevo tema TMC es aadido simplemente al paquete de diagrama en capas existente. El componente TMC es implementado luego creando nuevos objetos Tarea conforme son necesarios por el sistema. El componente de manejo de datos (DMC) comprende, por lo general, clases y objetos necesarios para almacenar y recuperar a los otros objetos del sistema. El DMC vara considerablemente dependiendo de si la tecnologa de tiempo de ejecucin subyacente es una base de datos orientada a objetos, una base de datos relacional o un sistema de archivos plano ordinario. En un ambiente de base de datos orientado a objetos, el DMC es provisto casi completamente por la base de datos. En un ambiente de base de datos relacional o de archivo plano, el DMC debe proporcionar servicios de almacenamiento al sistema.

0 ,

Figura 3.30.- Componentes de manejo de tarea del anlisis y diseo O-O.

Hay tres formas diferentes para disear el DMC. Un enfoque es construir servicios de almacenamiento en cada Clase y Objeto en el diseo. Esto involucra, por lo general, una cantidad considerable de programacin de diseo adicional. Una alternativa es crear una Clase y Objeto, ServidorObjetos, que proporcione todos los servicios de base de datos. Esta alternativa involucra un objeto muy complejo que sepa cmo guardar o recuperar todos los objetos del sistema. Cualquier peticin de almacenamiento se hace por medio de mensajes a este nico objeto. La figura 3.27 muestra el diseo de un ServidorObjetos.

99

S
Figura 3.31.- Diseo de una Clase y Objeto ServidorObjetos

e r

v Un tercer mtodo es crear una clase Almacenable. Este tercer enfoque es una combinacin de los dos i enfoques anteriores. La clase Almacenable incluye servicios bsicos gurdame y recuprame en forma generalizada. Cada objeto del sistema que deba ser guardado o recuperado es conectado luego d en una estructura Gen-Spec con la clase Almacenable. Esto trabajar solamente, por lo general, en o aquellos casos donde se disponga de herencia mltiple en la tecnologa de implementacin. La figura 3.28 muestra un ejemplo parcial de una clase Almacenable. r O b j e t o s

Figura 3.32.- Ejemplo parcial de una clase Almacenable.

Enfoques alternativos y notacin Las tcnicas O-O presentadas aqu estn basadas en un enfoque popular presentado por Coad y Yourdon. Hay varios enfoques competitivos que proporcionan variaciones en la notacin y en los tipos de abstracciones de anlisis y diseo. Ninguna de estas tcnicas es fcilmente comparable con las otras. Por ejemplo, en la figura 3.29 encontrar la notacin para herencia usada por cinco de los autores mencionados en la bibliografa. Son bastante similares. La cosa importante a darse cuenta aqu es que, una vez que se comprenden los principios de herencia no es difcil un cambio en notacin.

100

Shlaer

Booch

Clase Clase

Motocicleta

Embley

Vehculo

Automviles

Rumbauhg

Coad v Yourdon

Figura 3.33.- Notacin de diseo de herencia comparativo de cinco autores diferentes de anlisis y diseo O-O.

EJERCICIOS UNIDAD III

Qu es anlisis? Qu es diseo? Describe anlisis y diseo OO. Cul es la diferencia de anlisis y diseo OO? De qu sirve el divide y vencers en OO? Qu es un proceso de desarrollo? Qu pasa dentro de un ciclo de desarrollo? Dibuja y describe los smbolos bsicos del diagrama de flujo. Realiza el diagrama de contexto con el juego de dados con los atributos de cada proceso. En un juego de dados: Caso de uso: Jugar un juego. Participantes: Jugador. Descripcin: Este caso de uso comienza cuando el jugador recoge y hace rodar los dados. Si los puntos suman seis gana y pierde si suma cualquier otro nmero. 1. 2. 3. 4. 5. 6. 7. 8. 9.

101

MODELOS DE PROCESO DE SOFTWARE

4.1 Modelo de Cascada 4.2 Modelo de Espiral 4.3 Modelo Incremental 4.4 Proceso de Desarrollo Unificado 4.5 Proceso Software Personal

102

Sommerville define modelo de proceso de software como Una representacin simplificada de un proceso de software, representada desde una perspectiva especfica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstraccin de un proceso real. Los modelos genricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones tiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Los modelos convencionales de proceso se propusieron originalmente para ordenar el caos del desarrollo de software. La historia ha indicado que estos modelos convencionales han trado consigo cierta cantidad de estructuras tiles para el trabajo en la ingeniera del software, y han proporcionado un camino a seguir razonablemente efectivo para los equipos de software. En un documento intrigante sobre la extraa relacin entre el orden y el caos en el mundo de software, Nogueira y sus colegas establecen: El borde del caos se define como un estado entre el orden y el caos, una relacin estrecha entre la estructura y la sorpresa. El borde del caos se puede visualizar como un estado inestable, estructurado en forma parcial. . . es inestable porque es atrado de manera constante hacia el caos o as el orden absoluto. Cualquier organizacin de ingeniera del software debe describir un conjunto nico de actividades dentro del marco de trabajo para los procesos de software que adopte. Tambin debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniera del software, y definir cada accin en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Despus, la organizacin debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza especfica de cada proyecto, a las personas que lo realizarn, y el ambiente en el que se ejecutar el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genrico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicacin, planeacin, modelado, construccin y desarrollo. A continuacin se examinarn varios de los modelos prescriptivos del proceso de software. Se les llama "prescriptivos" porque prescriben un conjunto de elementos de proceso: actividades del marco de trabajo, acciones de ingeniera del software, tareas, productos del trabajo, aseguramiento de la calidad y mecanismos de control de cambio para cada proyecto. Cada modelo de proceso prescribe tambin un flujo de trabajo, esto es, la forma en la cual los elementos del proceso se interrelacionan entre s.

103

4.1. MODELO DE CASCADA

Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicacin a travs del despliegue de una manera casi lineal. Esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o mejoras bien definidas a un sistema existente (por ejemplo una adaptacin a un software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir tambin en un nmero limitado de proyectos de nuevos desarrollos, pero solo cuando los requerimientos estn bien definidos y son estables en forma razonable. El modelo en cascada, alguna vez llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que contina con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. Es el paradigma ms antiguo para la ingeniera de software, sin embargo en las dcadas pasadas, las crticas a este modelo de proceso han ocasionado que aun as ms fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn: 1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actual. 2. Con frecuencia es difcil para el cliente establecer todos los requerimientos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la versin del programa. Las siguientes son algunas creencias del modelo de cascada: a) Las metas se logran mejor cuando se tienen puntos de revisin bien preestablecidos y documentados, dividiendo el desarrollo en actividades secuenciales bien definidas. b) Los documentos tcnicos son comprensibles para usuarios y administradores, no tcnicos. c) Cada detalle de los requisitos se conocen de antemano antes de desarrollar el software y los detalles son estables durante el desarrollo. d) Las pruebas y evaluaciones se realizan eficientemente al final del desarrollo.

En el anlisis interesante de proyectos reales, Bradac concluyo que la naturaleza lineal del modelo en cascada conduce a estados de bloqueo en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. El tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial.

104

En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (de caractersticas, funciones y contenido de la informacin). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajos. Sin embargo, puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal. La figura 4.1 muestra el modelo en cascada.

Modelo Cascada
Definicin de Requisitos

Diseo de Sistema y software

Implementacin y Pruebas de unidad

Integracin y Prueba de Sistema

Operacin y Mantenimiento

Figura 4.1.- Esquema bsico del modelo de cascada.

Anlisis de requisitos.- Se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada Documento de Especificacin de Requisitos (SRD), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. El proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (analistas) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas. Diseo.- Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. El diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. Como resultado surge el Documento de Diseo del Software (SDD), que contiene la descripcin de la estructura global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Codificacin. - Fase de programacin propiamente dicha. Aqu se desarrolla el cdigo fuente, haciendo uso de prototipos as como pruebas y ensayos para corregir errores. El diseo debe traducirse en una forma legible para la maquina. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente.

105

Pruebas.- Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotacin. La prueba se centra en la lgica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Implantacin.- El software obtenido se pone en produccin. Mantenimiento.- Durante la explotacin del sistema software pueden surgir cambios, los cambios ocurrirn debido a que hayan encontrado errores, o que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Todo ello se recoge en los documentos de cambios. La interaccin entre fases puede observarse en la Figura 4.1 cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la correccin de los problemas encontrados en fases previas.

106

1.

4.2. MODELO DE ESPIRAL

El modelo espiral surge como un modelo no operativo de produccin de software que tiende a poner nfasis all donde los dems tienen sus debilidades, es decir, en el riesgo a asumir en cada etapa y el control del mismo. Debemos decir no obstante que como modelo reciente en comparacin con los dems adolece de algunos inconvenientes que se indicarn pero tiene una manera original de generar software que supera con creces los inconvenientes, sobre todo all donde los problemas financieros, de tecnologas innovativas o cualidades particulares del software hacen que los otros modelos tiendan a no conformar para su eleccin. El modelo en espiral, que Boehm propuso originalmente, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construccin de prototipos con los aspectos controlados y sistemticos del modelo en cascada. Boehm describe este modelo de la siguiente manera: El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniera de software concurrente y con mltiples usuarios. Tiene dos caractersticas distintivas principales. Una de ellas es un enfoque cclico para el crecimiento incremental del grado de definicin e implementacin de un sistema, mientras disminuye su grado de riesgo. La otra es un conjunto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias. Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas del sistema desarrollado. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniera del software. Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral que se representa en la figura 4.2. Cuando comienza este proceso evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor de la espiral que tiene una direccin en el sentido del movimiento de las manecillas del reloj, y que inicia desde el centro. El riesgo es un factor considerado en cada revolucin. Los puntos de fijacin es una combinacin de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral que se consideran para cada paso evolutivo. El primer circuito alrededor de la espiral quiz genere el desarrollo de una especificacin del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y despus, en forma progresiva, versiones ms elaboradas del software. Cada paso a travs de la regin de planeacin resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentacin derivada de la relacin con el cliente despus de la entrega. Adems, el administrador del proyecto ajusta el nmero de iteraciones planeado que se requiere para completar el software. A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Por lo tanto, el primer circuito alrededor de la espiral podra representar un "proyecto de desarrollo del 3 concepto", el cual se inicia en el centro de la espiral y contina por mltiples iteraciones hasta que el desarrollo del concepto est completo. Si el concepto se desarrollar en un producto real, el proceso contina en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionar a travs de un nmero de iteraciones alrededor de la espiral. Despus, un circuito alrededor de la espiral se podra emplear para representar un "proyecto de mejoramiento del producto". En esencia, la espiral, cuando se caracteriza de esta

107

forma, permanece operativa hasta que el software se retira. En ocasiones el proceso est inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo, mejoramiento del producto). Es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollo y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. Emplea la construccin de prototipos como un mecanismo encaminado a reducir riesgos, pero en forma importante, permite al desarrollador la aplicacin del enfoque de la construccin de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemtico de los pasos que sugiere el ciclo de vida clsico, pero lo incorpora al marco de trabajo interactivo que refleja de forma ms verdica el mundo real. El modelo espiral exige una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que vuelvan problemticos. Las creencias de los modelos son: Una actividad comienza cuando se entienden los objetivos y riesgos involucrados. Basado en la evaluacin de soluciones alternas, se usan las herramientas que mejor reduzcan los riesgos. Todo el personal relacionado debe involucrarse en una revisin que determine cada actividad, planeando y comprometindose con las siguientes actividades. El desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto.

Planeacin Estimacin Itinerario Anlisis de riesgos

Comunicacin
Modelado Anlisis Diseo

Despliegue Entrega Retroalimentacin

Construccin Cdigo Prueba

Figura. 4.2.- Modelo en espiral tpico.

108

El modelo basa sus caractersticas en sucesivas iteraciones hasta cumplir cierto punto de control o condiciones prefijadas para derivar a partir de all en los modelos clsicos (cascada o prototpico). En el primer caso una vez realizadas determinado nmero de iteraciones se pasar a un desarrollo acotado del modelo de cascada. En el ltimo caso lo que se indica es que se usar el ciclo de vida espiral para obtener un prototipo operativo y de all en ms se utilizara el ciclo de vida propio del prototipo. A diferencia de la idea de estos modelos iterativos donde los espirales suelen ser hacia el centro, es decir, que los primeros ciclos involucran las tareas ms importantes y los ciclos ms avanzados tareas de refinamiento hasta llegar al objetivo; en el modelo espiral las primeras iteraciones realizan tareas muy generales que se van ampliando a medida que se abarca los dems ciclos por lo que el espiral se va abriendo a medida que avanzamos y su culminacin debe ser hecha por otros caminos y no por s mismo. En el caso del modelo espiral de Boehm las etapas son las mismas para cada ciclo pero las tareas a realizar en cada una son mayoritariamente definidas por el ciclo anterior. El rea del espiral as trazado va abarcando cada vez mas requisitos, lmites y condiciones de contorno. A los efectos de referirse diferenciadamente de los aspectos iterativos del inicio a los aspectos de los modelos clsicos Boehm llama a los primeros ciclos interiores y a los segundos ciclos exteriores, si bien estos ltimos no tienen en general un aspecto iterativo. Dicho de otra manera los ciclos interiores tienen etapas diferenciadas de los ciclos exteriores siendo para el primer caso: Planificacin, Anlisis de Riesgo, Ingeniera, Evaluacin, Toma de Decisiones, Refinamiento, y para el segundo caso (si hablamos del ciclo de cascada): Factibilidad, Requisitos, Desarrollo Preliminar, Desarrollo Detallado, Codificacin, Integracin y Prueba, Implementacin, Operacin y Mantenimiento y Retiro. El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseo. Eso introduce un ciclo de prototipo iterativo. En cada iteracin, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.

Este mtodo est basado en dos importantes principios: 1. La prctica de diseo profesional es caracterizar en trminos de conocer, actuar en situaciones, conversacin con la situacin y reflexin en accin. Hay un distinto medio de proceso orientacin en esta aproximacin al diseo. Es raro que el diseador tenga el diseo en su cabeza por adelantado y que despus meramente lo transcriba. Gran parte del tiempo del diseador esta inmiscuido en una progresiva relacin con su entorno. Una buena metfora para describirlo es "la conversacin con el material", como un escultor, quien est ocupado en una conversacin con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser. 2. La necesidad para diseadores de tomar la prctica de trabajo seriamente, de supervisar las formas en las que el trabajo se est haciendo, en el sentido de una solucin abierta y desplegada para aumentar la complejidad de una situacin que el diseador slo entiende parcialmente. El hecho por el cual se est tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperacin y comunicacin.

____________________________
3

Las flechas que se apuntan hacia adentro a lo largo del eje que separa la regin de despliegue de la de comunicacin indican una posibilidad de iteracin local de la misma ruta de la espiral.

109

Las etapas del modelo en espiral pueden ser las siguientes: Debe indicarse que el nmero de etapas pueden variarse o subdividirse generando entre cuatro y siete de ellas segn la importancia que se pretende dar a cada una por lo que lo que aqu describimos es una interpretacin posible de las mismas en la figura 4.3. Planificacin. Determinacin de objetivos, limites y condiciones de contorno (condiciones que limitan de alguna manera el desarrollo, econmicas, de tiempo, etc.) y alternativas. Prediccin de personal esfuerzo y costo que se requerirn para terminar las actividades y productos conocidos asociados con el proyecto, planificar tareas y solapamiento de actividades y tareas, definir y desarrollar los requerimientos de software, definir los requisitos de interfaz, priorizar e integrar los requisitos de software. Anlisis de riesgo. Desarrollo de un plan para descubrir los riesgos ms importantes y resolver los mismos. Eliminacin de aspectos no compatibles con las condiciones, o condiciones de contorno o lmites. Identificar ideas o necesidades, formular soluciones potenciales, conducir estudios de viabilidad, planificar la transicin del sistema, refinar y finalizar la idea o necesidad, analizar las funciones del sistema, desarrollar la arquitectura del sistema, descomponer los requisitos del sistema, planificacin de contingencias. Ingeniera. Desarrollo del producto o prototipo segn las condiciones de la etapa anterior. Dentro de esta etapa se realizan las siguientes actividades: realizar el diseo arquitectnico, analizar el flujo de informacin, disear la base de datos, seleccionar o desarrollar algoritmos, realizar el diseo detallado de la etapa, crear el cdigo fuente. Evaluacin. Evaluar los resultados del prototipo obtenido, verificar y validar. Ejecutar las pruebas, generacin de los aspectos de mejora, errores, defectos y ampliaciones. Toma de decisiones. Se determina si se pasa al ciclo exterior o se realiza una nueva iteracin. Evaluacin de resultados, repeticin del ciclo o pasaje a otro modelo. Tcnicas de toma de decisiones (rboles de decisin, decisiones en condiciones de incertidumbre, etc.). Refinamiento. Si se toma la decisin de continuar en los ciclos internos se sofistican las condiciones a tomar en cuenta en el planeamiento del nuevo ciclo, en los ciclos exteriores es una etapa que no se utiliza. Ventajas a) fracaso. b) c) d) Reduce desde temprano los riesgos del proyecto, disminuyendo su probabilidad de Permite lidiar con los cambios en los requerimientos al utilizar prototipos y simulaciones. Permite al cliente observar resultados desde temprano gracias al desarrollo de prototipos. Puede aplicarse tanto para el desarrollo como para el mantenimiento.

Desventajas a) Al no existir fases fijas puede resultar problemtico al momento de establecer contratos de desarrollo. b) Requiere de buenas habilidades en el control y estimacin de riesgos. c) Debe ser refinado para poder ser aplicado.

110

Modelo de espiral
C o s t o Determinar objetivos, alternativas, restricciones P r o g r Revisin e s o Evaluar alternativas, identificar y resolver los riesgos

Planificar las fases siguientes

Desarrollar y verificar el producto del siguiente nivel

Fig. 4.3.- Modelo en espiral con todas sus etapas.

111

4.3. MODELO INCREMENTAL

El modelo incremental entrega el software en partes pequeas, pero utilizables, llamadas "incrementos". En general, cada incremento se construye sobre aquel que haya sido entregado anteriormente. Perteneciente a la familia de los Modelos de Procesos Evolutivos, el Modelo Incremental combina elementos del Modelo Lineal Secuencial (MLS) con la filosofa interactiva de construccin de prototipos. Aplica secuencias lineales de la misma forma que progresa el tiempo en el calendario. El cliente utiliza el producto central desarrollado y como resultado de su utilizacin y/o evaluacin se desarrolla un plan para el incremento siguiente, este plan afronta la modificacin del producto central con el fin de satisfacer mejor las necesidades del cliente, la entrega de funciones y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones "incompletas" del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin del producto.

Caractersticas a) Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofa interactiva de construccin de prototipos. b) El primer incremento es un producto esencial (ncleo), se afrontan requisitos bsicos y muchas funciones extras (conocidas o no) quedan para los siguientes incrementos. c) Los requisitos son priorizados. Los requisitos con una ms alta prioridad se incluyen en los incrementos ms tempranos d) Los requisitos de un incremento son inamovibles. Sin embargo estos pueden verse modificados en incrementos posteriores. e) El cliente usa el producto central y en base a la utilizacin y/o evaluacin se desarrolla un plan para el incremento siguiente. f) Este proceso se repite hasta que se elabora el producto completo. g) Es interactivo, al igual que el de construccin de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construccin de prototipos, el modelo incremental entrega un producto operacional en cada incremento. h) Es til cuando la dotacin de personal no est disponible para una implementacin completa. El primer incremento se puede implementar con pocas personas. Si el producto central es bien recibido, se puede aadir ms personal. i) Las siguientes son algunas creencias del modelo incremental: j) La administracin de proyectos es ms fcil de lograr en incrementos ms pequeos. k) Es ms fcil comprender y probar incrementos de funcionalidad ms pequeos. l) La funcionalidad inicial se desarrolla ms temprano, logrando resultados de inversin en menor tiempo. m) Hay ms probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos del software en el tiempo, que si fueran planeados todos a la vez en el mismo periodo.

112

En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin 4 embargo, para la produccin del software, se usa el principio de trabajo en cadena o "Pipeline ", utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el modelo incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. Es particularmente til cuando no se cuenta con una dotacin de personal suficiente para una implementacin completa en la fecha lmite que se haya establecido para el proyecto. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se puede aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. Modelo incremental en el desarrollo de los primeros sistemas:

Aos
Sistema Requerimientos entregado

Figura 4.4.- Desarrollo de los primeros sistemas

Ejemplo 4.3.1.- En 1996, el 80% de los ingresos de Hewlett Packard fueron de productos presentados durante los dos aos anteriores. Figura 4.4. El sistema, tal como est especificado en los documentos de requerimientos, est particionado en subsistemas funcionales pequeos y se van agregando funciones en cada versin como se muestra en la figura 4.5. El Modelo Incremental se puede ver aqu en forma grfica:

_______________________________
4

Es un conjunto de elementos procesadores de datos conectados en serie, en donde la salida de un elemento es la entrada del siguiente.

113

Modelo Incremental

Ingeniera de sistemas de informacin Incremento 1 Anlisis Diseo Cdigo Prueba Entrega de

Incremento 2

Anlisis

Diseo

Cdigo

Prueba

Entrega de

Incremento 3

Anlisis

Diseo

Cdigo

Prueba

Entrega de

Incremento 4 Anlisis

Diseo

Cdigo

Prueba

Entrega de

Figura 4.5.- Tiempo del calendario de proyecto.

Los pasos que siguen son: 1. El primer incremento a menudo es un producto esencial, se implementan los requerimientos bsicos. Ejemplo: Captura de datos de los estados de las cuentas bancarias y almacenar stas en un archivo. 2. Se entrega un producto operacional al cliente 3. El cliente lo utiliza, como resultado de la utilizacin y/o evaluacin. 4. El cliente solicita mejoras al producto 5. Se desarrolla el siguiente incremento incorporando los nuevos requisitos y agregando la nueva funcin. Ejemplo: Generar las conciliaciones bancarias. 6. Se desarrolla el siguiente incremento. 7. Se repite nuevamente el ciclo.

Incremento 1 Incremento 3 Incremento 2 Incremento 4

Incremento 5

Figura 4.6.- Seguimiento de los incrementos.

114

Ventajas e inconvenientes del Modelo Incremental: a) Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos ms crticos. b) Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos c) Existe un riesgo bajo de fallar en el proyecto total. d) Los servicios del sistema con la prioridad ms alta tienden a ser los ms probados. e) Puede ser difcil ajustar los requisitos a los incrementos. f) Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. g) Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. h) Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento. Creencias del modelo incremental: a) La administracin de proyectos es ms fcil de lograr en incrementos ms pequeos. b) Es ms fcil comprender y probar incrementos de funcionalidad ms pequeos. c) La funcionalidad inicial se desarrolla ms temprano, logrando resultados de inversin en menos tiempo. d) Hay ms probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos del software en el tiempo, que si fueran planeados todos a la vez en un mismo periodo.

115

4.4. PROCESO DE DESARROLLO UNIFICADO

Ivar Jacobson, Grady Booch y James Rumbaugh exponen la necesidad de un proceso de software guiado por los casos de uso, de arquitectura cntrica, iterativo e incremental. Estos autores establecen: En la actualidad la tendencia en el software se encamina a sistemas mayores y complejos. Eso se debe en parte al hecho de que las computadoras se volvan ms poderosas cada ao, lo que alentaba que los usuarios esperaran ms de ellas. Esta tendencia tambin la impuls el uso expandido de Internet para el intercambio de todo tipo de informacin. Nuestro apetito por un software cada vez ms complejo crece en la medida en la que aprendemos cmo puede mejorarse un producto desde que sale uno hasta que llega el otro. Necesitamos un software que se adapte mejor a nuestras necesidades, pero que, a su vez, haga el software ms complejo. En resumen, queremos ms. De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y caractersticas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo gil de software. El proceso unificado reconoce la importancia de la comunicacin con el cliente y los mtodos encaminados a describir el punto de vista del cliente con respecto a un sistema. El Proceso Unificado enfatiza el importante papel de la arquitectura de software, y ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilizacin. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno. Durante la dcada de 1980 y al principio de la dcada siguiente, los mtodos y lenguajes de programacin orientado a objetos (OO) obtuvieron una amplia difusin entre la comunidad de la ingeniera del software. Durante el mismo periodo se propuso una amplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y se introdujo un modelo de proceso orientado a objetos de propsito general. Al igual que la mayora de los paradigmas nuevos para la ingeniera del software, los seguidores de cada uno de los mtodos de AOO y DOO argumentaban acerca del cul de ellos era el mejor, pero ningn mtodo o lenguaje domin la escena de la ingeniera del software. Al principio de la dcada de 1990, James Rumbaugh, Grady Booch e Ivar Jacobson comenzaron a trabajar en un mtodo unificado que combinara las mejores caractersticas de cada uno de sus mtodos individuales y adoptara caractersticas adicionales que propusieran otros expertos (por ejemplo , en el campo OO). El resultado fue el lenguaje de modelado unificado (UML, por sus siglas en ingls) que contiene una notacin robusta para el modelado y el desarrollo de sistemas OO. Para 1997, el UML se convirti en un estndar de la industria para el desarrollo de software orientado a objetos; que proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera del software orientada a objetos, pero no provee el marco de trabajo del proceso que gue a los equipos en la aplicacin de la tecnologa. En los aos siguientes, Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniera del software orientada a objetos, mediante la utilizacin del UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en proyectos OO de todos los tipos. El modelo iterativo e incremental que propone el PU puede y debe adaptarse para satisfacer necesidades de proyecto especficas. Como consecuencia de la aplicacin del UML se puede producir un arreglo de productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, stos los reducen los ingenieros de software para lograr que el desarrollo sea ms gil y reactivo ante el cambio.

116

Fases del proceso unificado. 1. Inicio del PU abarca la comunicacin con cliente - actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de un conjunto preliminar de casos de uso que describen cules caractersticas y funciones son deseables para cada clase importante de usuarios. En general, un caso de uso describe una secuencia de acciones que desarrolla un actor (por ejemplo, una persona, una mquina, otro sistema) cuando ste interacta con el software. Los casos de uso ayudan a identificar el mbito del proyecto y proporcionan una base para la planeacin de ste. 2. En este punto, la arquitectura no es ms que un esquema tentativo de los subsistemas ms importantes y de las funciones y caractersticas que los forman. Despus, la arquitectura se refinar y expandir en un conjunto de modelos que representarn visiones diferentes del sistema. La planeacin identifica recursos, evala los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn conforme se desarrolle el incremento del software. 3. Elaboracin abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico del proceso, figura 4.7. La elaboracin refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. En algunos casos, la elaboracin crea una lnea de base arquitectnica ejecutable que representa un sistema ejecutable en su primer corte. La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las caractersticas y funciones necesarias para utilizar el sistema. Adems, el plan se revisa de manera cuidadosa al trmino de la fase de elaboracin para asegurar que el mbito, los riesgos y los datos entregados an son razonables. Las modificaciones al plan se deben hacer en este momento. 4. Construccin del PU es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software. Todas las caractersticas y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems, se realizan las actividades de integracin (ensamblaje de componentes y pruebas de integracin). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase del PU. 5. Transicin del PU abarca las ltimas etapas de la actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta (el software lo utilizan usuarios finales reales, con la intencin de descubrir defectos y deficiencias), y la retroalimentacin del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria (por ejemplo, manuales del usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en un lanzamiento de software utilizable. 6. Produccin del PU coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), se reciben y evalan los informes de defectos y los requerimientos de cambios.

117

Es probable que mientras se realizan las fases de construccin, transicin y produccin ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas. A lo largo de las fases de PU se distribuye un flujo de trabajo de ingeniera del software. En el contexto del PU, un flujo de trabajo es anlogo a un conjunto de tareas. Esto es, un flujo de trabajo identifica las tareas necesarias para completar una accin importante de ingeniera del software y los productos de trabajo que se producen como consecuencia de la realizacin exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades.

Productos de trabajo del proceso unificado En la figura 4.8 se ilustran los productos de trabajo clave que se produjeron como consecuencia de las cuatro fases tcnicas del PU. Durante la fase de inicio, el propsito es establecer una "visin" general para el proyecto, identificar un conjunto de requisitos de negocios, formar un caso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un obstculo para el xito. Desde el punto de vista del ingeniero de software, el producto de trabajo ms importante generado durante la etapa de inicio es el modelo de caso de uso: una coleccin de casos de uso que describen la forma en que actores externos ("usuarios" humanos y no humanos del software) interactan con el sistema y obtienen valor a partir de ste. En esencia, el modelo de casos de uso es una coleccin de escenarios de uso con plantillas estandarizadas que implican caractersticas y funciones del software mediante la descripcin de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interaccin representada. En un inicio, los casos de uso describen requisitos al nivel del domino de negocios (por ejemplo, el grado de abstraccin es alto). Sin embargo, el modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve como una entrada importante para la creacin de productos de trabajo subsecuentes. Durante la fase de inicio slo se completa entre el 10 y 20 por ciento de los casos de uso. Despus de la elaboracin, se ha creado entre un 80 y 90 por ciento del modelo. La fase de elaboracin produce un conjunto de productos de trabajo que elabora requisitos (incluso requisitos no funcionales "que no se pueden deducir del modelo de caso de uso"), as como una descripcin arquitectnica y un diseo preliminar. Cuando el ingeniero de software inicia con el anlisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de anlisis que describan una forma adecuada el comportamiento del sistema. El modelo de anlisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y anlisis (colecciones de clases) definidos como una parte del modelo de anlisis se refinan despus en un modelo de diseo, el cual identifica clases de diseo, subsistemas y las interfaces entre los subsistemas. Los modelos de anlisis y diseo expanden y refinan una representacin evolutiva de la arquitectura del software. Adems, en la fase de elaboracin se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez. La fase de construccin produce un modelo de implementacin que traduce las clases de diseo en componentes de software que se construirn para ejecutar el sistema, y un modelo de despliegue convierte los componentes en el ambiente fsico de computacin. Por ltimo, un modelo de prueba describe las pruebas empleadas para asegurar que los casos de uso se reflejen de manera apropiada en el software que se ha construido. La fase de transicin entrega el incremento del software y evala los productos de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentacin proveniente de las pruebas beta y los requerimientos cualitativos de cambio.

118

Figura 4.7.- Modelo del Proceso Unificado (PU).

Figuran 4.8.-Principales productos de trabajo producidos para cada fase del PU.

119

4.5. PROCESO SOFTWARE PERSONAL

El modelo de Proceso Software Personal (PSP) se caracteriza porque es de uso personal y se aplica a programas pequeos de menos de 10,000 lneas de cdigo. Se centra en la administracin del tiempo y en la administracin de la calidad a travs de la eliminacin temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administracin de configuraciones y Administracin de requerimientos. El PSP se orienta el conjunto de reas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. En 1997 un estudio realizado por 298 ingenieros de software revel que el PSP puede proporcionar una mejora del 75% en la agudeza de estimacin de esfuerzo y del 150% en la calidad de la estimacin de tamao. Adems, con la utilizacin del mtodo, el nmero de sobreestimaciones y de subestimaciones qued ms equilibrado. Por otra parte la calidad del producto aument en 2.5 veces. La productividad personal aument bastante. No en funcin del nmero de lneas de cdigo escritas por programador, mas con relacin al producto, resultando en un ciclo de desarrollo de mejor calidad, con menos errores y por lo tanto, con menos tiempo empleado en la correccin de los mismos. El estudio muestra adems que, con el mtodo PSP, los errores se detectan ya antes de la fase de test, lo que reduce para menos del 2%, el nmero de problemas encontrados despus de la implantacin de la aplicacin. La mejora de las estimaciones - que la mayor parte de los proyectos se realice, en el tiempo calculado - es una de las principales metas del PSP. El planeamiento y el seguimiento de cronogramas, as como el compromiso personal del ingeniero de software con la calidad, tambin son objetivos del mtodo. Es un proceso de automejoramiento diseado para ayudar a controlar, administrar y mejorar la forma en que se trabaja individualmente. Est estructurado por formularios, guas y procedimientos para desarrollar software. Si es usado apropiadamente, brinda los datos histricos necesarios para trabajar mejor y lograr que los elementos rutinarios del trabajo sean ms predecibles y eficientes. Usando PSP, se pueden construir programas de ms de 10,000 lneas de cdigo (LOC), sin embargo, hay dos problemas tpicos en los grandes programas. Primero, mientras se crece en tamao, tambin lo hace el tiempo y el esfuerzo requerido. Esto puede ser un problema particular si slo existe un ingeniero en el proyecto. Segundo, la mayora de los ingenieros tienen problemas en la visualizacin de todas las facetas importantes de un programa, incluso cuando su tamao es moderado. Existen muchos detalles e interrelaciones que deben tenerse en cuenta, muchas dependencias lgicas, interacciones en el tiempo o condiciones excepcionales. Una de las formas ms poderosas de resolver estos problemas es el proceso de software del equipo (Team Software Process, TSP).

NIVELES DE PSP PSP tiene un marco de proceso de evolucin similar al que tiene CMM (Evaluacin basados en la mejora de procesos internos CBA IPI). PSP trata parcialmente 12 de las 18 capas definidas en el CMM. Las capas son las reas de procesos clave o Key Process reas por su significado en ingls, estas reas ayudan a guiar a los programadores a que exista un mejoramiento notable en el proceso de software. En CMM un nivel de madurez slo se alcanza si se logran cumplir todas las capas que

120

exige cada nivel. Sin embargo PSP solamente cubre de manera parcial estas capas debido a que es un complemento de CMM y no depende uno del otro en ningn sentido por lo que es considerado como material de apoyo. Como se ha visto anteriormente el Instituto de la Ingeniera del Software (SEI) ha desarrollado el proceso personal del software para definir y reparar la holgura que existe entre el modelo de la madurez de la capacidad y el individuo. Por lo tanto es ideal utilizarlo junto con CMM pero no es obligatorio ya que es un proceso y no un modelo como lo es CMM. Para desarrollar software de alta calidad, cada componente individual tambin debe de contar con la ms alta calidad posible. La estrategia total de PSP es cerciorarse de que todos los componentes individuales se desarrollen con la ms alta calidad. PSP logra esto proporcionando un marco de proceso personal ya definido que el programador puede utilizar. Este marco es: Desarrollar un plan para cada proyecto y/o componente. Registrar su tiempo de desarrollo. Registrar sus defectos Conservar sus datos en informes del proyecto Utilizar sus datos para planear los proyectos y/o los componentes futuros. Analizar sus datos para desarrollar sus procesos con ms calidad para mejorar su funcionamiento. El proceso personal de software fue diseado para ayudar y guiar a los ingenieros de software a realizar bien su trabajo y haciendo esto pueden llegar a cubrir las capas requeridas. PSP tambin muestra cmo aplicar mtodos avanzados de ingeniera a sus proyectos y/o deberes diarios. Asimismo provee mtodos de estimacin y de planeacin muy bien detallados que son necesarios para dar un seguimiento a su trabajo. La disciplina del PSP provee un marco estructurado para desarrollar habilidades personales y mtodos que se necesitarn ms adelante para ir forjando al ingeniero de software. Es importante que la calidad del software desarrollado abarque hasta el ms mnimo detalle, por muy pequeo que ste sea, ya que si no se hace as, pueda daar el sistema entero. La figura 4.9 muestra un diagrama que contiene todos los niveles de PSP. As mismo se muestra que cada nivel cuenta con sus propios requerimientos o capas pertenecientes nicamente a PSP pero que podran compartir intereses con las capas de CMM. Es importante para las personas o empresas que quieran implementar PSP saber que deben de cumplir con todas las capas para que avancen de la mejor manera posible al siguiente nivel. Cabe recalcar que se puede "personalizar" el proceso agregando o removiendo tareas conforme a las exigencias de cada persona o empresa. Esto quiere decir que por lo mismo de que PSP es un proceso y no un modelo, se puede amoldar a las necesidades del programador. Ahora bien que si lo que se quiere hacer es que el proceso de PSP sea usado para cumplir con el modelo de capacidad de madurez, entonces se deben de tomar en cuenta los puntos que exige CMM de PSP. En cada nivel de CMM existen capas que pueden ser cumplidas siguiendo el proceso personal de software, de hecho esa sera la mejor manera de cumplir con las exigencias de CMM. No por nada fue que Watts S. Humphrey quiso crear PSP y otros procesos, sino para que fueran el complemento ideal y el "atajo" que se podra tomar para cumplir cuanto antes con los niveles de CMM que se desean alcanzar. Existen resultados que demuestran la eficiencia y una reduccin de tiempo considerable cuando se usan estos procesos diseados para alcanzar los niveles de CMM ms rpidamente que si se utilizaran otros "caminos". Hasta ahora se ha visto que PSP tiene sus niveles internos y que tambin cuenta con niveles que se deben cumplir junto a su modelo por el cual fue creado, CMM. El programador y el proyecto determinan si se debe utilizar PSP en su totalidad o slo parcialmente. Tambin se ha visto la gran dinamicidad que puede llegar a tener PSP con respecto a cualquier proyecto que est en desarrollo. Desgraciadamente ste atributo no es bien aprovechado o en dado caso no se hace de manera correcta la decisin sobre que puntos tomar

121

de PSP y cules no, si conviene hacer uso de todos los puntos que sugiere el proceso o solamente unos cuantos. La figura 4.10 presenta los elementos que tienen en comn PSP con CMM. De esta manera puede analizarse cuales se podran aplicar a cada proyecto.

Proceso Personal

PSP3

Proceso de Calidad Personal

Paso 7
PSP2 Revisin de codificacin

PSP2.1
Formato de diseo

Paso 5
Proceso de Planeacin PSP1 Estimacin del Tamao

Paso 6 PSP1.1
Planeacin de diseo

Paso 3
PSP0 Proceso actual Registro de tiempos

Paso 4 PSP0.1 Estandar de codificacin Medicin del tamao Paso 2

Paso 1

Figura 4.9.-"Evolucin del proceso personal de Software".

Esta informacin es de gran utilidad porque as el programador tiene una idea clara de los puntos que debe cubrir respecto a sus necesidades. Esto quiere decir si sus necesidades se encuentran dentro del rango de lo que exige CMM o si se aplican por separado la figura 4.10.

Caractersticas del PSP. Proporciona una serie de principios al ingeniero para llevar a cabo un proceso personal disciplinado. Asiste a los ingenieros en la realizacin de planes precisos. Determina los pasos que los ingenieros deben seguir para mejorar la calidad del producto Establece bancos de pruebas para medir la mejora del proceso personal y, Determina el impacto que los cambios del proceso tienen sobre el rendimiento del ingeniero.

122

Nivel 5 OPTIMIZACION Administracin del Cambio de Proceso Administracin del Cambio de Tecnologa Pretensin de defectos

Nivel 4 ADMINISTRADO Administracin De la Calidad Administracin del Proceso cuantitativo

Nivel 3 DEFINIDO Revisin de Colegas Coordinacin entre los grupos Ingeniera de productos de Software Administracin Integrada de Software Programa de Entrenamiento Definicin de proceso de Software Enfoque en el Proceso de Software

Nivel 2 REPETIBLE Administracin de la Configuracin de Software Aseguramiento de la Calidad de Software Administracin del Subcontrato de Software Rastreo y visin general del proyecto de Software Planeacion del proyecto de Software Administracion de requerimientos

Nivel 1 INICIAL

Figura 4.10.- Elementos del PSP en CMM.

Principios del PSP El diseo de PSP se basa en los siguientes principios de planeacin y de calidad. Cada ingeniero es diferente; para ser ms eficiente, debe planificar su trabajo basndose en datos tomados de su propia trayectoria profesional. Para mejorar autnticamente su trabajo, los ingenieros deben usar procesos personales bien definidos y cuantificados. Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. Los buenos productos no se obtienen por azar, sino como consecuencia de un esfuerzo positivo para hacer un trabajo de calidad. Cuanto antes se detecten y corrijan los defectos menos esfuerzo ser necesario. Es ms efectivo evitar los defectos que detectarlos y corregirlos. Trabajar bien es siempre la forma ms rpida y econmica de trabajar. Para hacer un trabajo de la manera correcta, se debe planear de la mejor manera el trabajo antes de comenzar y se debe utilizar un proceso bien definido para realizar de la mejor manera la planeacin del trabajo. Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaos de los productos que llegan a producir.

123

Para que as se produzca constantemente productos de calidad, se debe planear, medir y rastrear constantemente la calidad del producto y centrarse en la calidad desde el principio de un trabajo. Finalmente, se analiza los resultados de cada trabajo y se utiliza estos resultados para mejorar sus procesos personales. Ver figura 4.11 del proceso de mejora continua.

La disciplina del trabajo de alta calidad La disciplina PSP proporciona un marco de trabajo estructurado para desarrollar las habilidades personales y los mtodos que necesitars como ingeniero de sw. La cuestin no es si t necesitas habilidades personales, sino cunto tiempo necesitas para desarrollarlas y cmo las utilizas de forma consistente. La disciplina PSP acelerar tu aprendizaje.

Definir el objetivo de calidad

Medir la calidad del producto

Comprender el proceso

Ajustar el proceso

Comparar los resultados con el objetivo

Medir los resultados

Utilizar el proceso ajustado

Figura 4.11.- Proceso de mejora continua.

GESTIN DEL TIEMPO Hacer planes realistas. Intentar seguir el plan. Controlar el uso del tiempo. Determinar errores y cmo corregirlos.

PARA COMPRENDER COMO UTILIZAMOS EL TIEMPO Clasificar actividades. Registrar tiempos dedicados a las mismas. Hacer registros normalizados. Conservarlos adecuadamente.

124

EJERCICIOS UNIDAD IV
1. Describe cmo funciona cada modelo de proceso de software: a) Modelo de cascada. b) Modelo de espiral. c) Modelo incremental. d) Proceso de desarrollo unificado. e) Proceso software personal. Qu factores influyen a la hora de elegir un ciclo de vida para resolver un problema dado?

2.

3. Qu ciclo de vida elegira para resolver un problema que se comprende bien desde el principio y est muy estructurado? Una vez elegido el ciclo de vida, qu procesos escogera para dicho ciclo de vida, teniendo en cuenta que el desarrollo informtico para resolver el problema anterior lo realiza una nica persona? 4. Se supone que se va desarrollar una aplicacin relativa a la gestin de pedidos de una empresa. En este caso el cliente no tiene todava muy claro qu es lo que quiere. Adems, el personal informtico va a utilizar un tecnologa que le resulta completamente nueva. Disctase qu tipo de ciclo de vida es ms apropiado y qu procesos se deberan utilizar para desarrollar esta aplicacin. 5. Indicar la(s) respuesta(s) correcta(s) y razonar la respuesta: El ciclo de vida: a) Comienza con una idea o necesidad que satisfacer y acaba con las Pruebas satisfactorias del producto. b) No existe ningn estndar que describa sus procesos y actividades. c) No se trata slo de realizar el anlisis, diseo, codificacin y pruebas; tambin incluye, entre otros, procesos de soporte. d) El mantenimiento lo constituyen las actividades para mantener sin cambios el sistema. e) En la actividad de anlisis de los requisitos software los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema.

125

TCNICAS, HERRAMIENTAS Y ESTUDIOS PREVIOS

5.1 TCNICAS DE RECOPILACIN DE INFORMACIN

5.1.1 ENTREVISTA 5.1.2 CUESTIONARIO 5.1.3 RECOPILACIN Y ANLISIS DE DOCUMENTOS 5.1.4 OBSERVACIN Y TCNICA STROBE

5.2 HERRAMIENTAS CASE

5.2.1 ESTRUCTURADAS 5.2.2 ORIENTADAS A OBJETOS

5.3 DESARROLLO DE PROTOTIPOS

126

5.1 TCNICAS DE RECOPILACIN DE INFORMACIN

Los analistas utilizan una variable de mtodos a fin de recopilar los datos sobre una situacin existente, como entrevistas, cuestionario, inspeccin de registros y observacin. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigacin completa. A continuacin se vern cada una de ellas.

5.1.1 ENTREVISTA

Las entrevistas se utilizan para recabar informacin en forma verbal, a travs de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionarn datos o sern afectadas por la aplicacin propuesta. El analista puede entrevistar al personal en forma individual o en grupos. Es una forma de conversacin, no interrogacin! al analizar las caractersticas de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre ese sistema los analistas pueden conocer los datos que no estn disponibles en ninguna otra forma. En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la informacin son importantes. La informacin cualitativa est relacionada con opiniones, polticas y descripciones cuantitativas tratan con nmeros, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de informacin cualitativa; los otros mtodos tienden a ser ms tiles en la recavacin de datos cuantitativos. Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rpidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas an a menudo es ms fcil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios. Se seleccionar un nmero de personas para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen informacin que no se podr conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan la factibilidad del proyecto, con frecuencia las entrevistas slo se aplican a la gerencia o personal de supervisin. Sin embargo, durante la investigacin detallada en donde el objetivo es descubrir hechos especficos, opiniones y conocer como se manejan las operaciones desempeadas actualmente, las entrevistas se aplican en todos los niveles gerenciales de empleados y dependen de quien pueda proporcionar la mayor parte de la informacin til para el estudio. As, los analistas que estudian a la administracin de inventarios pueden entrevistar a los trabajadores del embarque y de recepcin, al personal del almacn y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacn; tambin entrevistaran a los agentes ms importantes. La habilidad del entrevistador es vital para el xito en la bsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparacin del objetivo de una entrevista especfica como de las preguntas por realizar a una persona determinada.

127

El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de xito. Por ejemplo, un analista que trabaja en la aplicacin enfocada a la reduccin de errores probablemente no tendra xito; si llegar a una oficina de gerencia de nivel medio con la presentacin equivocada, por ejemplo, si dijera, hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aqu. O la introduccin: Estamos aqu para resolver su problema, es igualmente mala. A travs de la entrevista, los analistas deben preguntarse a s mismos las siguientes interrogantes: Qu es lo que me est diciendo la persona? Por qu me lo est diciendo a m? Qu se est olvidando? Qu espera esta persona que haga yo? Si se considera cada elemento de la informacin contra estas preguntas, los analistas tendrn ms conocimientos no solamente de la informacin adquirida sino tambin de su importancia. Planeacin de una entrevista Son cinco pasos principales para la preparacin de una entrevista, como se indica en la figura 5.1. Estos pasos incluyen una gama de actividades, desde la recopilacin de antecedentes, hasta la decisin de a quin entrevistar.

Lectura de antecedentes Establecimiento de los objetivos de la entrevista Seleccin de los entrevistados Preparacin del entrevistado

Seleccin del tipo y la estructura de las preguntas

Figura 5.1.- Pasos para la planeacin de una entrevista.

Lectura de antecedentes.- Consultar y comprender el mayor nmero posible de antecedentes de los entrevistados y de su organizacin. Estos se obtienen frecuentemente de manera sencilla por medio de una llamada telefnica a su contacto, pidindole un informe anual reciente, un boletn corporativo o cualquier comunicacin que explique al pblico las caractersticas de la organizacin. Conforme se lea este material, se fija bien en el tipo de lenguaje que los miembros de la organizacin utilizan para describirse y describir a la organizacin. Esto permitir elaborar un vocabulario, que eventualmente, capacitar para redactar las preguntas de la entrevista, de manera tal que stas sean comprendidas por su entrevistado. Otro de los beneficios de explorar de antemano la organizacin es aprovechar al mximo el tiempo de la entrevista, ms que desperdiciarlos al hacer preguntas generales sobre los antecedentes.

128

Establecimiento de los objetivos de la entrevista.- Establecer los objetivos de la entrevista con base en los antecedentes que se consulte y en la experiencia particular. Debe haber entre cuatro y seis aspectos fundamentales referentes al procesamiento de la informacin y al proceso de la toma de decisiones sobre los cuales se desear hacer preguntas. Estos incluyen: las fuentes de informacin, los formatos de la informacin, la frecuencia de la toma de decisiones, la calidad de la informacin y el estilo de la toma de decisiones. Seleccin de los entrevistados.- Cuando se decida a quines se entrevistara, se incluir a la gente clave de todos los niveles del sistema, es importante una muestra de los miembros de la organizacin y hacer lo posible por mantener un equilibrio de tal manera que se cubran tantas necesidades de los usuarios como sea posible. Su contacto con la organizacin dar una idea clara sobre quines deberan ser entrevistados. Preparacin del entrevistado.- Preparar a la(s) persona(s) que entrevistar, avisndole con tiempo para que pueda pensar acerca de la entrevista. Se reserva un tiempo especial para sus llamadas y reuniones. Las entrevistas deben fluctuar entre 45 minutos y una hora. No importa qu tanto inters tengan sus entrevistados para prolongar la entrevista, recordar que cuando ellos disponen de tiempo para atenderlo a usted, no atienden sus actividades regulares. Si la entrevista dura ms de una hora, es muy probable que el entrevistado lamente su visita, aunque no exprese tal sentimiento. Seleccin del tipo y estructura de las preguntas.- Redactar preguntas que cubran los aspectos fundamentales de la toma de decisiones, detectados al plantear los objetivos de la entrevista. La esencia de la entrevista se basa en el uso de tcnicas inquisitivas adecuadas. Las preguntas tienen ciertas estructuras bsicas que se deben conocer. Los dos tipos bsicos de preguntas son las abiertas y las cerradas. Cada tipo de pregunta puede lograr algo diferente de las otras y cada una tiene sus ventajas y sus inconvenientes. Es posible estructurar la entrevista bajo tres patrones diferentes: el de estructura de pirmide, de estructura de embudo y la estructura de diamante. Cada uno de ellos es adecuado para condiciones particulares. A continuacin se presentan una serie de decisiones importantes que el entrevistador debe tomar. Estas incluyen qu preguntas realizar y cmo plantearlas, si se estructura la entrevista y cmo documentarla, tal y como se muestra en la figura 5.2. TIPOS DE PREGUNTAS Preguntas abiertas.- Las preguntas abiertas incluyen a aquellas tales como: Qu opina acerca de las microcomputadoras para gerentes? y Podra explicarnos cmo toma sus decisiones sobre la programacin?. Considere el trmino abierta. Abiertas son las opciones que el entrevistado tiene para responder. Puede ser una respuesta de dos palabras o de dos prrafos. En la figura 5.3 se presentan algunos ejemplos de preguntas abiertas.

129

Tipo de preguntas Documentacin Abierta Cerrada Exploratorias Grabacin Cuaderno de notas

DECISIONES IMPORTANTES DEL ENTREVISTADO

Estructura de la entrevista

No estructurada Pirmide Embudo Diamante

Estructurada

Figura 5.2.- Decisiones de la estructura de la entrevista.

1. 2. 3. 4.

Cul es su opinin del sistema de cmputo actual? Cmo ve los objetivos de este departamento? Cmo se relaciona esta forma con el trabajo que usted desempea? Cules son algunos de los problemas que percibe respecto a recibir oportunamente la informacin? Cules son los errores ms comunes en la captura de los datos en este departamento?

5.

6. Describa el sistema de cmputo ms frustrante con el cual haya trabajado.

Figura 5.3.- Ejemplo de preguntas abiertas en la entrevista.

Ventajas: a) Simplifican las cosas para el entrevistado. b) Permiten al entrevistador, seleccionar el vocabulario del entrevistado, lo que refleja su educacin, valores y creencias. c) Proporcionan una gran riqueza de detalle. d) Revelan nuevas alternativas sobre preguntas no consideradas. e) Hacen ms interesante la entrevista. f) Se utilizan como una alternativa, cuando el entrevistado no se encuentra preparado.

130

Desventajas: a) Permiten preguntas que pueden generar demasiada informacin irrelevante. b) La posible prdida del control de la entrevista. c) Permiten respuestas que pueden llevar demasiado tiempo para la cantidad de informacin que aportan. d) Pueden dar la apariencia de que el entrevistador no se prepar. Preguntas cerradas.- Las alternativas a las preguntas abiertas se tienen en el otro tipo bsico de preguntas, las preguntas cerradas, las cuales tienen como estructura bsica: Cuntos subordinados tiene usted?. Las posibles respuestas se encuentran limitadas para el entrevistado, ya que slo puede responder con un nmero finito, tal como ninguno, uno o quince. Algunos ejemplos de preguntas cerradas se encuentran en la figura 5.4.

1. 2. 3.

Cuntos informes genera en un mes? Durante cunto tiempo ha trabajado con los hermanos Bakerloo? De las siguientes fuentes de informacin, cules son las ms valiosas para usted? a. Formas de reclamacin llenadas por los clientes b. Relacin cara a cara con los clientes c. Devolucin de la mercanca Enumere dos prioridades principales para el departamento de mercadotecnia en 1986.

4.

Quin recibe este reporte? Figura 5.4.- Ejemplo de preguntas cerradas en la entrevista.

Limita las respuestas disponibles del entrevistado porque son aquellas de opcin mltiple de su poca escolar. Se le da una pregunta y cinco posibles respuestas, sin permitirle plantear su propia respuesta que pueda ser tomada como correcta. Un tipo especial de pregunta cerrada es la pregunta bipolar. Esta es an ms limitativa al tener slo dos respuestas alternativas, tales como s o no, falso o verdadero, de acuerdo o en desacuerdo. En la figura 5.5 se muestran algunos ejemplos de preguntas bipolares.

1. 2.

Utiliza microcomputadoras? Estar usted de acuerdo o en desacuerdo con que la automatizacin de las funciones de los cajeros sera de gran vala? Desea recibir mensualmente un reporte hecho en computadora de su status contable? Ofrece su departamento contable transferencia electrnica automtica de cheques de nmina para que trabajan por hora? Estar completa esta forma?

3.

4.

5.

Figura 5.5.-Ejemplo de preguntas bipolares de entrevista.

131

Ventajas: a) b) c) d) e) f) Ahorran tiempo. Facilitan la comparacin entre entrevistas. Llegan al punto de inters. Mantienen el control de la entrevista. Cubren rpidamente diversos aspectos. Obtienen datos de relevancia.

Desventajas: a) b) c) d) Aburren al entrevistado. Pierden la riqueza del detalle (al plantear al entrevistado un marco de referencia). Se pueden perder ideas centrales por el punto anterior. No favorecen un clima de armona entre el entrevistado y el entrevistador.

El entrevistador, debe nsar acerca del tipo de preguntas que va a utilizar. Tanto las preguntas cerradas como las abiertas tienen sus ventajas y sus desventajas, como se muestra en la figura 5.6. Hay que notar que la eleccin de un tipo respecto del otro tiene un costo. Mientras las preguntas abiertas ofrecen amplitud y profundidad en la respuesta, estas respuestas son difciles de analizar.
ABIERTA CERRADA

Baja

Confiabilidad de losa datos

Alta

Bajo

Uso eficiente del tiempo

Alto

Baja

Presin de los datos

Alta

Muchas

Amplitud y profundidad

Poca

Muchas

Habilidad requerida en el entrevistador

Poca

Dificil

Facilidad del anlisis

Fcil

Figura 5.6.- Atributos de las preguntas abiertas y de las preguntas cerradas.

Sondeo.- Es el ms simple, es la pregunta Por qu?. Otras seran, Podra darme un ejemplo? y Podra dar ms detalles? El propsito del sondeo es ir ms all de la respuesta inicial para obtener un mayor significado, y aclarar o ampliarlos puntos del entrevistado. El sondeo puede realizarse mediante preguntas abiertas o cerradas.

132

La mayora de los entrevistadores principiantes son reticentes acerca del sondeo, y en consecuencia, aceptan respuestas superficiales. Por lo general, agradecen que el empleado les haya concedido la entrevista y se sienten un poco obligados a aceptar cualquier respuesta. Si se hace de una manera sistemtica y determinada, le servir para mostrar a su interlocutor que escucha lo que l dice, pensando al respecto y respondiendo adecuadamente. Ms que utilizar el enfoque de reportero investigador, usted debe explorar de tal forma que exhiba su escrupulosidad y buen deseo de comprender las respuestas del entrevistado.

Estructura piramidal. La organizacin inductiva de la entrevista puede concebirse como una pirmide. Mediante el uso de esta estructura, el entrevistador inicia la entrevista con preguntas detalladas, con frecuencia del tipo cerradas. El entrevistador ampliar luego los tpicos, haciendo preguntas abiertas, y en consecuencia, respuestas de carcter ms generalizado, como se muestra en la figura 5.7. Debe utilizar una estructura piramidal cuando crea que su entrevistado requiere de una introduccin hacia el tpico. Tambin es muy til si el entrevistado se niega a involucrarse en el tpico. Por ejemplo, si se entrevista a alguien que le ha indicado que no necesita platicar con usted, porque ya sabe en qu falla el modelo de pronsticos, a lo mejor estructurara la entrevista como una pirmide. Tambin es til el uso de una estructura piramidal para encadenar preguntas cuando desee llegar a una conclusin final del tpico. Tal es el caso de la pregunta final, En general, qu es lo que usted piensa acerca de los pronsticos?.

Y concluye con una general

Cul es el problema especifico de su modelo de pronsticos? Has considerado obtener una informacin ms actualizada? Las estructuras piramidales comienzan con una pregunta especifica En general cul es su opinin acerca de los pronsticos?

Figura 5.7.- Estructura piramidal para la entrevista.

133

Estructura de embudo. El entrevistador toma el enfoque deductivo, comenzando con preguntas abiertas de carcter general; y ms adelante, va reduciendo las posibles respuestas mediante el uso de preguntas cerradas. Esta estructura de entrevista puede verse como una estructura de embudo, como se plantea en la figura 5.8. Facilita el inicio de una entrevista sin comprometerla. Sus interlocutores no sentirn presin alguna al dar respuestas errneas a preguntas abiertas. La secuencia en la estructura de embudo tambin es til cuando el entrevistado est involucrado sentimentalmente con el tpico y necesita cierta libertad para expresar sus emociones. Un beneficio que se obtiene del uso de la estructura de embudo es que organiza la entrevista de tal manera que puede redundar en una informacin tan detallada, que haga innecesarias las largas secuencias de preguntas cerradas y de sondeo.

Cul es su reaccin sobre el nuevo sistema de cmputo? Qu computadoras utiliza? Cul es el costo del nuevo sistema de cmputo? Con base en su costo vale la pena el nuevo sistema de cmputo? Y concluye con una especifica

Las estructuras de embud comienzan con una pregunta general

Figura 5.8.- Estructura del embudo para la entrevista.

Estructura en forma de diamante. Es la combinacin de las dos estructuras (piramidal y embudo), lo que da por resultado una entrevista con estructura en forma de diamante. Esto permite comenzar de una manera muy especfica, luego examinar aspectos generales y finalmente llegar a una conclusin muy especfica, tal como se muestra en la figura 5.9. El entrevistador comienza con preguntas cerradas sencillas que crean un ambiente confortable para la entrevista. A la mitad de la entrevista, se le pedir al entrevistado su opinin sobre tpicos generales, que obviamente no logran una respuesta correcta. Por ltimo, el entrevistador replantear las preguntas con mayor precisin, proporcionando un marco de clausura para ambos, el entrevistado y el entrevistador. Combina la fortaleza de las otras dos, pero tiene como inconveniente que requiere ms tiempo. La principal ventaja del uso de una estructura de diamante es que mantiene el inters y la atencin de su entrevistado, mediante la variedad de las preguntas.

134

Las estructuras de diamante comienzan con una pregunta especifica Cmo realizar sus decisiones sobre las distribuciones? Cree que podra ensearle a alguien a tomar este tipo de decisiones? Qu necesitara para establece reglas de decisin, de manera que otros pudieran beneficiarse con su experiencia? Son tiles las computadoras en la toma de decisiones? Una computadora puede realizar este tipo de decisiones sobre la distribucin? Y Concluyen con una pregunta especifica Se orienta a preguntas ms generales

Figura 5.9.- Estructura de diamante para la entrevista.

5.1.2 CUESTIONARIO

Constituyen una tcnica de recopilacin de informacin que permite a los analistas de sistemas recoger opiniones, posturas, conductas y caractersticas de las diversas personas claves de una organizacin, que se encuentran involucradas en la operacin de un sistema actual o en la implantacin de uno nuevo, tal y como se muestra en la figura 5.10. La actitud es el deseo que plantean las personas de una organizacin (por ejemplo, sobre un nuevo sistema); la opinin es lo que se piensa de la realidad; la conducta es lo que hacen los miembros de una organizacin, y las caractersticas son los atributos de las personas o de los objetos. Las respuestas que se obtienen mediante cuestionarios de preguntas cerradas pueden cuantificarse. Las respuestas a cuestionarios que utilizan preguntas abiertas se analizan e interpretan de manera distinta. Las preguntas referentes a actitudes y opiniones son muy sensibles al tipo de palabras que elija el analista de sistemas. Se puede cuantificar los resultados de las entrevistas. Adems, los cuestionarios pueden servir para determinar qu tan difundido o limitado se encuentra un sentimiento (que haya sido expresado durante una entrevista). De manera opuesta, los cuestionarios tambin sirven para sondear una gran muestra de usuarios de sistemas con el fin de detectar problemas, o bien, tener presentes aspectos importantes, antes de la programacin de una serie de entrevistas.

135

Mediante el uso de cuestionarios, el analista puede cuantificar los resultados de las entrevistas. Adems, los cuestionarios pueden servir para determinar qu tan difundido o limitado se encuentra un sentimiento (que haya sido expresado durante una entrevista). De manera opuesta, los cuestionarios tambin sirven para sondear una gran muestra de usuarios de sistemas con el fin de detectar problemas, o bien, tener presentes aspectos importantes, antes de la programacin de una serie de entrevistas.

OPINIONES CARACTERSTICAS

Figura 5.10.-Tipo de informacin que se exploran por medio de cuestionarios.

Planeacin para el uso de cuestionarios A primera vista, los cuestionarios pueden verse como una forma rpida de recopilar cantidades masivas de datos acerca de la opinin de los usuarios al sistema actual; qu problemas experimentan ellos en su trabajo y qu es lo que espera de un sistema nuevo o modificado. Por otra parte, aunque los cuestionarios permiten recopilar grandes volmenes de informacin sin requerir entrevistas personales, el desarrollo y la planeacin de un cuestionario til requiere bastante tiempo. Lo primero que se debe definir es qu busca con un cuestionario. Por ejemplo, si desea saber el porcentaje de usuarios que prefieren contar con un centro de informacin que les presente nuevos paquetes de software, estonces seran los cuestionarios los ms convenientes. Si desea realizar un anlisis profundo sobre un proceso de toma de decisiones en la gerencia, entonces la mejor eleccin sera la entrevista. A continuacin se presenta una serie de lineamientos para establecer la conveniencia de los cuestionarios. Considere el uso de cuestionarios s: a) Las personas a quienes necesita interrogar se encuentran muy dispersas (diferentes reas de una sola corporacin). b) Existe una gran cantidad de personas involucradas en el proyecto de sistemas, y es conveniente saber qu porcentaje de ese grupo (por ejemplo gerentes) aprueba o desaprueba una caracterstica particular del sistema propuesto.

ES

TI O N

ACTIVIDADES

IO

CONDUCTAS

136

c) Lleva a cabo un estudio exploratorio y desea medir la opinin general, antes de que el proyecto de sistemas tome una direccin particular. d) Desea sondear los problemas que presenta el sistema actual para identificarlos y darles seguimiento por medio de entrevistas. Una vez que ha encontrado una buena razn para hacer uso de los cuestionarios y ha precisado los objetivos a satisfacer mediante su uso, puede entonces, iniciar la formulacin de preguntas.

Redaccin de preguntas La mayor diferencia que presentan las preguntas de entrevista y las preguntas de cuestionarios, es que durante la entrevista se mantiene la relacin entre la pregunta y su significado. En una entrevista, el analista tiene la oportunidad de afinar una pregunta o un trmino difcil, cambiar el curso de las preguntas, responder a una mirada inquisitiva, y en general, tener el control sobre de las circunstancias. De lo anterior, poco es posible en los cuestionarios. Lo cual implica para el analista que las preguntas deben ser completamente transparentes; el flujo del cuestionario convincente; se debe anticipar a las respuestas de las preguntas, y que el manejo del cuestionario sea planificado con todo detalle. Los tipos bsicos de preguntas que se utilizan en los cuestionarios son las preguntas abiertas y las preguntas cerradas, tal y como se estudi para la entrevista.

Preguntas abiertas.- Son aquellas que permiten al entrevistado cualquier opcin de respuesta. Por ejemplo: Describa cualquier problema que en la actualidad experimente con los reportes de salidas, o Cul es su opinin acerca de la utilidad de los manuales de usuarios para el sistemas de contabilidad actual?

Cuando se redacta preguntas abiertas para un cuestionario, se anticipa al tipo de respuesta que se puede obtener, es importante que las respuestas que se reciba puedan interpretarse correctamente, de otra manera, se desperdiciarn recursos importantes en el desarrollo, la aplicacin y la interpretacin de un cuestionario intil. Por ejemplo, si hiciera una pregunta tal como, cul es su posicin ante el sistema? Las respuestas pueden ser demasiado amplias para una interpretacin o comparacin precisa. De tal forma, que cuando redacte una pregunta abierta, sea suficientemente preciso para guiar a quien responde el cuestionario a contestar de una manera especfica. En la figura 5.11 se presentan algunos ejemplos de preguntas abiertas. Son adecuadas, en especial, en aquellas circunstancias en que se desea conocer la opinin de los miembros de una organizacin sobre algunos aspectos del sistema. Para apoyar lo anterior, conviene usar preguntas abiertas, cuando sea imposible enumerar todas las posibles respuestas de una pregunta. Las preguntas abiertas tambin son tiles para explorar situaciones,esto se presenta cuando el analista no es capaz (por la dispersin de los empleados) de establecer con precisin, los problemas que presenta el sistema actual. Las respuestas a preguntas abiertas sirven para centrarse en problemas ms especficos, mediante entrevistas a las personas clave que toman las decisiones.

137

53. Cules son los problemas ms frecuentes con los que se enfrenta en las salidas de la computadora? A ______________________________________ B_______________________________________ C_______________________________________ ________________________________________ 54. De los problemas enumerados arriba cul de ellos es el ms grave? _________________________________________ _________________________________________ _________________________________________ 55. Por qu? _________________________________________ _________________________________________ _________________________________________

Las preguntas abiertas piden de quien corresponde

Respuestas detalladas

A continuacin, tenemos preguntas acerca de usted. Por favor llene los espacios en blanco de acuerdo con sus caractersticas. 67. Durante cunto tiempo ha trabajado con esta compaa? _______ aos ________meses 68. Durante cunto tiempo ha trabajado en esta compaa? _________aos _______meses 69. Cul es tu edad? _______aos

O respuestas cortas

Figura 5.11.-Ejemplo de preguntas abiertas utilizadas en los cuestionarios

Preguntas cerradas.- Limitan o restringen el nmero disponible de opciones de quien responde al cuestionario. Por ejemplo, en la figura 5.13, el planteamiento: A continuacin tenemos los seis paquetes de software disponibles en el centro de informacin. Anote cul es el paquete que usted utiliza con mayor frecuencia, en una pregunta cerrada. Observe que no se pregunta a los que responden el cuestionario el motivo de su preferencia, ni se les pide que seleccionen ms de uno, aunque as se tendra una respuesta ms representativa. Se deben utilizarse cuando el analista sea capaz de enumerar de antemano todas las respuestas posibles. Tambin, las respuestas planteadas deben ser mutuamente exclusivas, de forma tal que al elegir una de ellas no implique la eleccin de ninguna otra. Cuando se requiera explorar una gran muestra de personas, se utiliza preguntas cerradas. Si utilizaran preguntas abiertas exclusivamente para cientos de personas, sera imposible un anlisis e interpretacin correcta de las respuestas (sin el auxilio de un programa computarizado de anlisis de contenidos).

138

La eleccin del vocabulario As como en las entrevistas, la seleccin de las palabras tambin es de gran relevancia para lograr que los cuestionarios sean efectivos. An si el analista de sistemas cuenta con un conjunto estndar de preguntas, referente al desarrollo de sistemas, es prudente redactarlas de nuevo para reflejar la terminologa propia de la empresa. Quienes responden los cuestionarios apreciarn el esfuerzo realizado en la preparacin de un cuestionario, si ste hace uso de su lenguaje propio.

Contesta las preguntas 23-24 marcando el recuadro apropiado. 23. Abajo aparece el nombre de seis paquetes de software, que el Centro de informacin tiene disponible. Por favor seale el paquete de software que utilice con mayor frecuencia. ( )LOTUS ( )HAL ( )Dbase III ( )EXSYS ( )WORDSTAR ( )EXCELERATOR 24. Por lo general, los datos de las ventas se reciben tarde. ( )DE ACUERDO ( )EN DESACUERDO Contestar las preguntas 25-35 circulado en numero apropiado. 25. Cuando los datos de ventas se procesan por el centro de computo, se obtienen con retrasos.
NUCA RARA VEZ 1 2 . . . . EN OCASIONES 3 CON FRECUNECIA 4 SIEMPRE 5

Las preguntas cerradas se pueden solicitar que se respondan marcando cuadros

Que se encierre en un crculo, un nmero

Conteste las preguntas 45-48 encerrando en un circulo el numero apropiado. 45.- La divisin en la que actualmente me encuentro se llama.
INVERSIONES OPERACIONES MERCADOCTENIA

46. Mis antecedentes educativos es: O en si se encierra la respuesta

BACHILLERATO CIERTOS CURSOS SUPERIORES GRADO DE LICENCIATURA GRADO DE MAESTRIA O MS

47. Mi sexo es:

MASCULINO FEMENINO

Figura 5.12.- Ejemplo de preguntas cerradas en los cuestionarios.

A continuacin, se presentan ciertos lineamientos que son tiles al elegir el lenguaje de un cuestionario: a) Use, en lo posible, el lenguaje de quien contesta. Mantenga una redaccin sencilla. b) Sea especfico, sin embargo, evite preguntas sumamente especficas. c) Use preguntas cortas. d) No sea condescendiente con lo que contestan. Evite el uso de un lenguaje corriente. e) Evite la parcialidad en la redaccin. Esto tambin significa evitar preguntas censurables. f) Dirija las preguntas a las personas indicadas (esto es, aquellas que sean capaces de responder). No suponga un conocimiento muy profundo. g) Asegrese que las preguntas sean tcnicamente precisas, antes de incluirlas.

139

Escalar es el proceso de asignar nmeros u otros smbolos a un atributo o caracterstica con el fin de poder medirlo. Con frecuencia, las escalas son arbitrarias y no llegan a ser nicas. El analista necesita disear escala para: 1. Medir.-Existen cuatro formas de escalas de medicin, cada una de ellas ofrece diferentes grados de precisin. La forma de medir tambin dicta la manera de analizar los datos recopilados. Las cuatro formas de medicin son: a. Nominal.- Se utilizan para clasificar objetos. La siguiente pregunta hace uso de una escala nominal: Cul es el tipo de programa que ms utiliza? 1) Procesador de textos. 2) Hoja de clculo. 3) Base de datos. 4) Programa de graficacin. Es obvio que las escalas nominales son las formas ms dbiles de medicin. En general, a lo ms que el analista puede llegar es a obtener totales de cada categora. b. Ordinal.- Al igual que las escalas nominales permiten la clasificacin, sin embargo, la diferencia es que la escala ordinal implica adems un arreglo por categoras. En este ejemplo, un analista de sistemas le pide al usuario final que encierre en un crculo alguno de los nmeros:

El personal del centro de informacin es: 1) 2) 3) 4) 5) Extremamente til. Muy til. Moderadamente til No muy til. Nada til.

Son tiles las escalas ordinales porque una categora es superior o inferior a la otra. Por otra parte, no pueden hacerse suposiciones de que la diferencia entre las opciones 1 y 2 sea la misma que existe entre la 3 y la 4. 2. De intervalo.-Tienen como caracterstica que la diferencia que existe es la misma entre los intervalos de cada uno de los nmeros. Debido a esta particularidad, las operaciones matemticas pueden realizarse sobre datos del cuestionario, permitiendo un anlisis ms completo. Como ejemplos de escalas de intervalo tenemos a las escalas Fahrenheit y centgrada para medir la temperatura. El ejemplo previo sobre el centro de informacin, en efecto, no hace uso de una escala de intervalo, pero al asignarle una escala que tome los atributos extremos, el analista podra suponer que el que contesta percibe como equivalentes a los intervalos: Qu tan til es el apoyo ofrecido por el personal del centro de informacin?

Nada til 1

Extremadamente til 4 5

Si el analista de sistemas toma en cuenta este supuesto, ser posible contar con un anlisis ms cuantitativo.

140

b) Proporcional.-Es similar a las de intervalo porque se supone que los intervalos entre los nmeros son iguales. Sin embargo, las escalas proporcionales cuentan con un cero absoluto. Un ejemplo sera la distancia que mide una regla. Otro ejemplo sera el siguiente: De manera aproximada, cuntas horas dedica diariamente a la computadora? 0 2 4 6 8

El analista usa poco las escalas proporcionales. Como lineamiento, un analista de sistemas debera utilizar: 1) Una escala proporcional cuando los intervalos sean iguales y se tenga un cero absoluto. 2) Una escala de intervalo cuando suponga que los intervalos son equivalentes, pero carece de un cero absoluto. 3) Una escala ordinal cuando es imposible suponer que los intervalos son iguales, aunque los grupos puedan clasificarse. 4) Una escala nominal si el analista de sistemas desea clasificar objetos pero sin establecer niveles. DISEO DE CUESTIONARIOS.- Muchos de los principios relevantes en el diseo de formas para la captura de datos, tambin son importantes aqu. Si bien el motivo de un cuestionario es recopilar actitudes, opiniones, conductas y caractersticas cuyo impacto llegar a afectar el trabajo de los usuarios, los que responden los cuestionarios no estn siempre motivadas para hacerlo. Se tiene que recordar que los miembros de las organizaciones tienden a recibir infinidad de cuestionarios, y muchos de ellos tienen una concepcin pobre o son triviales. Un cuestionario bien diseado y de relevancia elimina cierta resistencia para responder. El formato del cuestionario es: Disponga suficiente espacio en blanco. La consideracin de mayor importancia en el diseo del formato del cuestionario es contar con suficiente espacio en blanco, para hacer lo atractivo para quien responde. Por espacio en blanco se refiere a aquellas reas en blanco que rodean el material impreso en una pgina. Un cuestionario que sea compacto, que no cuente con espacio en blanco, ser poco atractivo para llenarlo, aunque se use menos papel para su impresin. Para incrementar la tasa de respuesta, use exclusivamente papel blanco al imprimir los cuestionarios. Disponga del espacio adecuado para las respuestas. Adems de incluir suficiente espacio en blanco, deje suficiente espacio para anotar la respuesta. Si se deben responder preguntas abiertas con un prrafo, deje para ello entre tres y cinco renglones. Use crculos para las respuestas. Otra buena prctica para el registro de una respuesta correcta es solicitar a quien resuelve el cuestionario que encierre en un crculo la respuesta (o el nmero si emplea escalas) que elija. La figura 5.13 muestra lo que puede ocurrir si no solicitamos de manera explcita que se encierre la respuesta por medio de crculos. En este ejemplo, el analista tendr dificultades para identificar la respuesta correcta (la 3 o la 4).

141

13 el informe mensual tiene varios errores que deben corregirse antes de ser de utilidad.

NUCA

RARA VEZ

EN OCASIONES

EN GENERAL

SIEMPRE

Figura 5.13.-Utilizacin del crculo para la respuesta.

En ocasiones, se selecciona la respuesta mediante el registro dentro de un cuadro de corchetes, o el espacio interno entre dos parntesis. Sin embargo, debe dejar espacio suficiente para aquellas personas que hacen marcas de gran tamao. La tabulacin de datos y el anlisis se dificulta, si quien responde el cuestionario selecciona inadvertidamente varias opciones. Use los objetivos como ayuda para establecer el formato. Antes de disear el cuestionario, se necesita definir los objetivos. Por ejemplo, si el objetivo es dirigir las encuestas al mayor nmero posible de miembros de una organizacin, con respecto a una lista de problemas identificados en el sistema actual, es posible utilizar formas de respuesta capturadas por medios pticos o mecnicos. Esto afectara en s, el diseo del cuestionario, as como las indicaciones que se van a incluir. De manera alternativa, si se desea obtener respuestas escritas, se debe estimar el espacio que requiera la longitud de la respuesta esperada. Se tiene que asegrese de incluir dicho espacio en la forma o en una hoja anexa. Quizs se necesite planificar que, tanto para las respuestas numricas como para las escritas, alguien, asignado, capture las respuestas del cuestionario (en lugar de las mismas personas que contestan el cuestionario). Aunque la probabilidad de error aumenta al involucrar a una segunda persona, tambin es una oportunidad para eliminar errores de captura de datos que las personas sin experiencia pudieran ocasionar al contestar. Adems, aquellas hojas de cuestionario que permiten escribir directamente la respuesta, son ms fciles de llenar por quienes deben contestar que las formas especiales de captura de respuestas por medios pticos o mecnicos. Mantenga un estilo consistente. Organizar de manera consistente el cuestionario. Colocar las instrucciones siempre en el mismo sitio, e relacin a la subseccin de las preguntas, de tal forma que quienes contestan sepan en dnde encontrar las instrucciones. Utilizar letras maysculas y minsculas para las preguntas y slo maysculas al referirse a las respuestas. Mantener de manera consistente este formato le permitir a los que contestan, responder de manera rpida y reducir el riesgo de error. Otro aspecto importante del diseo de cuestionarios es el orden de las preguntas. En ocasiones, necesitar el apoyo de un grupo piloto para decidir un mejor orden para las preguntas.

142

5.1.3 RECOPILACIN Y ANLISIS DE DOCUMENTOS

Durante la investigacin, se est sumergido en la bsqueda de hechos y de datos, de situaciones financieras, de contextos organizacionales y de diversos tipos de documentos, y de problemas, como se muestra en la figura 5.14. Los datos concretos presentes en los registros proveen la informacin que no puede obtenerse por otros mtodos, como la entrevista y la observacin. Aunque las organizaciones producen datos concretos como un producto genrico para quien le interese, se debe recordar el significado que tuvieron cuando los miembros de la organizacin los generaron. Por lo tanto, se vuelve importante definir para quines fueron emitidos originalmente y por qu se conservan. En otras palabras, se necesita comprender la relevancia del documento dentro de la organizacin; en general, las organizaciones con un buen soporte en documentacin llegan a ser ms rgidas que las empresas que operan con una mnima documentacin, ya que la documentacin sirve para la creacin de un control centralizado de direccin nica.

HECHOS Y DATOS CONTEXTO DE LA ORGANIZACIN INFORMACIN FINANCIERA TIPOS DE DOCUMENTOS Y PROBLEMTICAS

Figura 5.14.-Tipos de informacin obtenida durante la investigacin

Los documentos, dentro de una organizacin, transmiten mensajes persuasivos, dando indicios de la conducta de sus integrantes. Tambin se debe considerar que los cambios en la documentacin pueden repercutir en cambios de la organizacin. Los tipos de datos concretos revelan la trayectoria de la organizacin y hacia dnde se dirige segn sus miembros. Con el fin de conformar una imagen precisa, el analista necesita examinar ambos tipos de datos concretos, los cualitativos y los cuantitativos.

A N O L C U IS M IS EN D TO E S

143

Anlisis de los documentos cuantitativos Existe toda una variedad de documentos cuantitativos disponibles para la interpretacin de cualquier empresa. Entre ellos se incluyen los informes corporativos, los informes utilizados para la toma de decisiones, los informes de desempeo y formas diversas. Todos estos documentos

Balance general al 31 de diciembre de 1987 Activos Activo circulante Efectivo Obligaciones comerciales al costo Cuentas por cobrar Inventarios Total de activos circulantes Activos fijos Terrenos Inmuebles Maquinaria Mobiliario de oficina Total de propiedades, inmuebles y equipo Menos la depreciacin acumulada Neto de activos fijos Activos totales Pasivos Pasivo circulante Cuentas por pagar Ttulos por pagar Gastos por pagar Impuestos federales por pagar Total de pasivo circulante Obligaciones a largo plazo Pasivos totales Capital Acciones de capital Acciones preferentes Acciones comunes Excedentes de capital Utilidades retenidas acumuladas Total del capital Total de pasivos y de capital 1987 440,000 800,000 2,000,000 2,800,000 6,040,000 500,000 3,000,000 800,000 100,000 4,400,000 1,000,000 3,400,000 9,440,000 1987 1,000,000 850,000 550,000 340,000 2,740,000 3,000,000 5,740,000 1987 500,000 1,000,000 800,000 1,400,000 3,700,000 9,440,000 1986 970,000 450,000 1,800,000 2,900,000 6,120,000 500,000 2,500,000 750,000 90,000 3,840,000 900,000 2,940,000 9,060,000 1986 900,000 1,000,000 300,000 260,000 2,460,000 3,000,000 5,460,000 1986 500,000 1,000,000 800,000 1,300,000 3,600,000 9,060,000

Tabla 5.1.- Balance general de la corporacin.

Informes corporativos. La ley exige por mandato y regulacin que las firmas proporcionen informes corporativos o informes anuales para la emisin de acciones pblicas. El analista externo puede obtener un panorama de la corporacin, mediante la consulta de informes anuales consecutivos. Hay varios tpicos clave, si la compaa es solvente, si obtiene utilidades, si le confiere una distincin a la investigacin y al desarrollo; y finalmente, si existe un equilibrio entre pasivos y capital.

144

El estado de resultados de la empresa, que se presenta en la figura 5.15, muestra la imagen, en cierto momento, de los activos, los pasivos y los bienes de la organizacin. Las cantidades dan indicios de la fortaleza de la empresa y permiten al analista deducir el monto de la inversin ms adecuada para su sistema de computacin. El estado de prdidas y utilidades compara el desempeo de la compaa respecto a otros aos para saber si sta obtuvo utilidades o prdidas. El analista puede examinar los ingresos o el estado de prdidas y utilidades, y a primera vista tendr una idea mejor de la organizacin. Una vez que el analista haya examinado el panorama, se concentrar en los informes utilizados en la toma de decisiones. Informes que soportan la toma de decisiones. Se debe consultar algunos de los documentos que se utilizan en la operacin de la empresa. Estos documentos comnmente son informes del status de los inventarios, de las ventas o de la produccin. Muchos de ellos, si bien no llegan a ser muy complejos, sirven como retroalimentacin para tomar acciones inmediatas. Como ejemplo, veamos el caso de un informe de ventas que resume el volumen y el tipo de las ventas. Adems, estos informes incluyen grficas comparativas de los ingresos y las utilidades para una serie de periodos. Esto facilita a quien toma las decisiones, la concepcin de tendencias globales. Los informes de produccin incluyen aspectos relativos a los costos recientes, a los inventarios actuales, a la mano de obra involucrada y a la informacin bsica de la planta. Ms all de estos informes fundamentales se tiene una serie de resmenes, que sirve de antecedente para la toma de decisiones o que exponen las excepciones de la operacin normal, as como panoramas estratgicos de los planes de la organizacin. Informes de desempeo. La mayora de los informes de desempeo comparan los resultados reales con los planeados. Un aspecto importante de este tipo de informes es el establecimiento de la diferencia que existe entre el desempeo actual y el desempeo esperado. Sirve tambin para determinar si la tendencia de la diferencia se acorta o se ampla, para cualquier tarea que se inspeccione. Registros. Los registros contienen actualizaciones peridicas de lo que ocurre en la empresa. Si la actualizacin es continua y cuidadosa, conferir al analista informacin til. Hay diferentes maneras para la inspeccin de un registro, entre las cuales destacaran las siguientes: 1)Verificacin de la ausencia de error en las cantidades y los totales. 2)Bsqueda de oportunidades para mejorar el diseo de la forma de registro. 3)Observacin del nmero y el tipo de transacciones. 4)Identificacin de los casos que se simplificaran por el uso de computadoras (esto es, clculos y otras manipulaciones de datos).

Formas para la captura de datos. Antes de que se disponga a modificar el flujo de informacin dentro de la organizacin, debe comprender la operacin del sistema vigente. Usted o alguno de los integrantes de su equipo desearn recopilar y catalogar copias en blanco de cada una de las formas (oficiales o extraoficiales) que se utilizan. (A veces las empresas cuentan con personal que se encarga especficamente de la administracin de las formas; y a tal persona debemos solicitar, en primera instancia, dichas formas.) Las formas en blanco, junto con sus instrucciones de llenado y distribucin, se comparan con las formas que ya estn llenas, y se advertirn aquellos puntos, que de manera consistente, se dejan en blanco, si las personas para quienes se elaboran las formas, las reciben, y si se siguen los procedimientos estndar para su uso, almacenamiento o eliminacin.

145

A continuacin se presenta un procedimiento para crear un catlogo de formas, que nos auxilie a entender el tipo de informacin que usa la empresa: 1) Obtenga muestras de todas las formas en uso, tanto las aceptadas de manera formal por la empresa, como las que no lo fueran (oficiales con informales). 2) Anote el tipo de forma (si es impresa internamente, manuscrita, generada por la computadora de la empresa, impresa externamente, comparada, etc.). 3) Documente el proceso de distribucin especificado originalmente. 4) Compare el proceso intentado de distribucin especificado originalmente con el que actualmente recibe la forma. Aunque lo anterior es tedioso, no deja de ser til. Otro enfoque sera tomar muestras de las formas llenadas para la captura de datos. Hay muchas preguntas que plantear, como lo ilustra la figura 5.16. Ellas incluyen: 1)Se est llenando toda la forma? Si no fuera as, qu conceptos se omiten? Cules se omiten consistentemente? Por qu razn? 2)Hay formas que nunca han sido utilizadas? Por qu? (Verifique el diseo y la validez de la forma para la supuesta funcin.) 3)Se circulan todas las copias a las personas adecuadas? Se archivan bien? Si no fuera as, por qu no? 4)Existen formas extraoficiales que se utilicen con frecuencia? (Esto pudiera indicar deficiencias de los procedimientos estndar, o quizs, dar indicio de la existencia de ciertas pugnas polticas dentro de la organizacin.) Existe una serie de aspectos que est tratando de averiguar mediante el estudio de las formas utilizadas. Algunos de los signos que se observan y pueden ser sintomticos de problemas mayores, son los siguientes: 1)Los datos o la informacin no fluyen como fue planeado (los reciben muchas personas, los reciben muy pocas personas o no los reciben las que debieran). 2)Cuellos de botella en el procesamiento de las formas, que frenen o bloqueen totalmente el trabajo. 3)Una duplicidad innecesaria en el trabajo por desconocimiento de los empleados de que la informacin ya existe o se presenta de forma distinta, y no la reciben. 4)Una falta de comprensin acerca de la interrelacin del flujo de la informacin (esto es, los empleados ignoran que su trabajo de salida sirve de entrada para otros).

Anlisis de documentos cualitativos Existen en la organizacin toda una serie de documentos que no son cuantitativos. Aunque los documentos cualitativos no siguen lineamientos preestablecidos, su anlisis se vuelve fundamental para comprender cmo los integrantes de la organizacin estn involucrados en el proceso de la organizacin. Los documentos cualitativos incluyen memorndums, avisos pegados en tableros y reas de trabajo, manuales de procedimientos y de polticas. Muchos de ellos revelan las

146

expectativas de conducta que sus redactores esperaban de los miembros de la organizacin. Existen varios lineamientos para mantener enfoques sistemticos en el anlisis, que son: 1)Examinar los documentos para identificar aquellas metforas que den ciertas pautas. 2)Identificar en los documentos indicios de pugna entre los de adentro y los de afuera o estamos en contra de ellos. 3)Enumerar los trminos que caractericen buenas o malas intenciones y que se presenten regularmente en los documentos. 4)Reconocer, si existe, el sentido del humor.

Cada uno de los lineamientos deben verse como la manera de iniciar la interpretacin de los documentos cualitativos, y en efecto, existen otros enfoques que van ms all del anlisis requerido. El examen de los documentos en bsqueda de metforas que den pautas, se debe a que el lenguaje se adapta a la conducta, y en consecuencia, aquellas metforas empleadas se vuelven relevantes. Por ejemplo, una organizacin que denomina a los empleados integrantes de una gran maquinaria o los dientes de un engrane est tomando un enfoque mecnico de la organizacin. Note la metfora formamos parte de una familia feliz, que da la pauta del memorndum de la figura 5.16. Se puede usar lo anterior para predecir el tipo de metforas que sern persuasivas en la organizacin, as como para entender la manera de caracterizar en forma de metfora un nuevo sistema.

147

GRANJA DE LA FORTUNA La forma oficial puede saturar a la gente, al solicitarle demasiada informacion.

FECHA _________ Nombre de la tienda _________________________ Numero de la tienda _________________________ Productos solicitado Leche (2 litros) Entera 2% 1% Descremada Mantequilla Chocolate _______ _______ _______ _______ _______ _______ Cajas Productos solicitado Leche (1 litros) Entera 2% 1% Descremada Mantequilla Chocolate ________ ________ ________ ________ ________ ________ Cajas

La formas puede carecer de un orden lgico

Yoghurt Natura Vainilla Durazno Zarzamora Mora Fresa _______ ________ _______ ________ ________ ________ Pia Manzana Pltano Tutifruti Frambuesa Limn ________ ________ ________ ________ ________ ________

Se necesita realmente el total?

Helado litro Deluxe 2 litro Deluxe Barquillos ________ ________ _________ 1 litro Deluxe 1 litro Deluxe 1 litro Premium ________ ________ ________

Total de cajas ordenadas: _____________

Solicitado por (nmero de empleado)_______ Motivo de la escasez_________________________________________________ _ Nmero de chofer: ______ Nmero de ruta: ________ Tienda ____________ Fecha:_________ Chofer:_____ Producto agotado _____________Cajas requeridas____ Producto agotado _____________Cajas requeridas____ Producto agotado _____________Cajas requeridas____ Producto agotado _____________Cajas requeridas____ Inciales del gerente de lcteos:____________________

Formas improvisadas que surgen para simplificar los problemas

Figura 5.15.- Preguntas de forma oficial y extraoficial que ya se encuentren llenas.

Cuando el analista encuentra un lenguaje que provoca fricciones entre grupos o departamentos o que coloca al negocio en contra de sus competidores, es posible entender con mayor claridad las polticas existentes. Es obvio que si un departamento est en pugna con otro, ser imposible obtener su cooperacin para el proyecto de sistemas, mientras no se solucione de manera satisfactoria el problema existente.

148

MEMORNDUM Para: nocturno De: Fecha: Asunto: Todos los operadores de computadoras del turno S. Leep, gerente nocturno 15/11/87 Fiesta de bienvenida esta noche

Es un placer dar la bienvenida a los dos nuevos operadores del turno 11-7, Twyla Tine y Al Knight, estoy seguro que les agradar trabajar con nosotros. Trabajar en las primeras horas del da nos hace sentir como toda una familia feliz. Recuerden que en los descansos de esta noche, algunos han trado alimentos. Srvanse ustedes mismos y demos a Twyla y Al la ms cordial bienvenida a nuestro clan.

Figura 5.16.- Anlisis de los memorndums que orientan a la organizacin

Con la misma idea, si el negocio es agresivamente competitivo en sus comentarios hacia las otras empresas del entorno empresarial, una parte fundamental del apoyo al proyecto de sistemas puede provenir del inters para mantenerse en liderazgo competitivo. La enumeracin de aquellos trminos que se encuentran en los documentos cualitativos y que caracterizan las acciones, los grupos o los eventos, como buenos o malos, permite al analista identificar lo que se considera como lo bueno en el negocio y lo que se condena como malo o incorrecto, dando indicios sobre los valores que abraza el grupo. Por ejemplo, si la acumulacin excesiva de documentos se seala en forma negativa, como se plantea en la figura 5.18, entonces se querr saber si las salidas del sistema se utilizan realmente y que no se archivan slo por si acaso. Memorndums. Cuando sea posible, el analista debe sondear los memorndums que circulan dentro de la empresa. Sin embargo, los memorndums no se conservan o tienen acceso a ellos, slo los que deben saberlo, como lo definen las polticas de la organizacin. Junto con los cuatro lineamientos anteriores, el analista debe considerar tambin quines son los emisores de los memorndums y quines los reciben. Por lo general, la mayor parte de la informacin de la organizacin fluye hacia abajo y horizontalmente y no hacia arriba. Los memorndums revelan el dilogo vivo de la organizacin. El anlisis del contenido de los memorndums proporciona una idea clara de los valores, las actitudes y creencias de los miembros de la organizacin. Avisos en tableros y en reas de trabajo. Aunque stos parecieran incidentales a lo que ocurre en la organizacin, los avisos son reforzadores subliminales de los valores del lector. Avisos tales como La calidad es eterna y La seguridad ante todo dan al analista una idea de la cultura oficial de la organizacin. Tambin conviene identificar hacia quines se dirigen los avisos, y determinar, mediante entrevistas, si los miembros de la organizacin los toman en cuenta. Manuales. Otro tipo de documentos cualitativos son los manuales de la organizacin, incluyendo aqullos concernientes a la operacin de las computadoras. Los manuales deben analizarse siguiendo los cuatro lineamientos que fueron descritos previamente. Los redactores de los manuales cuentan con mayor libertad para detallar temas que la que se observa en los avisos o en los memorndums. Recuerde que los manuales reflejan un ideal de la conducta que esperamos del equipo y de las personas. La revisin sistemtica de los manuales le dar la pauta de cmo

149

debera ocurrir las cosas. Es conveniente recordar que los manuales rara vez se mantienen al da y, en ocasiones, se aslan a los anaqueles, sin llegar a consultarse.

Para: De: Asunto:

Todos los gerentes departamentales Fecha: 12 de octubre de 1988 Phil Baskett, gerente general Archivo de papeles

En nuestra ltima reunin de carcter empresarial, surgi el tpico sensible sobre que archivar. Muchos de ustedes admiten abiertamente que son ratas pepenadoras, recogiendo cualquier reporte, por si acaso se requiere. A partir de ahora, la determinacin al respecto es que ustedes debern pensar antes de archivarlos. El monstruo de papel lleg a ms de una de nuestras oficinas y los archivos voluminosos se vuelven cada vez ms caros. Me niego rotundamente a autorizar cualquier partida adicional para nuevos archiveros. La mayora de las secretarias de departamentos conservan en archivo, la correspondencia relevante, los informes y los memos oficiales; la computadora tiene an ms informacin. Por lo tanto, no se conviertan en ratas pepenadoras. Si su secretaria los conserva, ustedes deben tirarlos.
Figura 5.17.- Revelacin de los valores, las actitudes y las creencias de los miembros de las organizaciones, respecto al uso de la informacin.

Manuales de polticas. Mientras estos cubren tpicamente amplios aspectos de la conducta de la organizacin y de sus empleados, deber adentrarse en aquellos que se refieran a las polticas del uso, acceso y cargos de los servicios de cmputo. Las polticas son los lineamientos generales que plantean, de manera ideal, la conducta a seguir de los miembros de la organizacin, con el fin de alcanzar las metas estratgicas, como se plantea en la figura 5.18. Una vez ms, los miembros pueden ser indiferentes a las polticas particulares, o bien, las hacen a un lado a propsito, en nombre de la eficiencia o la simplificacin. Sin embargo, la consulta de las polticas permite al analista de sistemas darse cuenta de los valores, las actitudes y las creencias que guan a la corporacin.

Obtencin de datos a partir de documentos de archivo. Gran parte de la informacin, tanto cuantitativa como cualitativa, que se necesita, no es de uso corriente; ms bien, se encontrar almacenada en archiveros. Cierto material se guarda por mandato gubernamental, por prctica contable o porque la empresa produzca informacin histrica por una solicitud formal

150

MANUAL DE LAS POLITICAS DE CMPUTO DE VEPCO Pagina 7 Seccin 8 8.1 Todos los empleados que soliciten servicios de cmputo se encuentren fuera del centro de informacin debern solicitarlos formalmente por escrito al departamento de sistemas informticos 8.2 Slo los empleados autorizados podrn hacer requisiciones 8.2.1Los requisitos se deben de presentar en la forma apropiada e incluirn la fecha de la solicitud, el nmero del empleado, el motivo de la solicitud y la forma autorizada del supervisor . 8.3 Cuando se presenten los requisitos quedara en lista de espera y se atendern con base a la primeras entradas, sern las que atienden primero. 8.3.1 Cuando el personal del departamento de sistemas lo considere pertinente una requisicin podr clasificarse como Urgente lo cual permite que los requisitos se cumplan.

Los manuales de polticas indican la manera ideal de hacer las cosas

MANUAL DE LAS POLITICAS DE COMPUTO Pgina 8 Seccin 9 PRESTAMO A MICROCOMPUTADORAS PREMISAS Una analista se sorprender al encontrar polticas ya existentes. DOMICILIO CON BASE EN DE LAS

9.1 Los empleados podran solicitar un prstamo de algunos de los equipos porttiles de microcomputadoras disponibles incluyendo las microcomputadoras, las lectoras de discos y algunos programas de software. 9.1.1 Se requiere de un depsito para cada artculo y programa de software. 9.2El depsito se puede entregar al cajero en turno

Figura. 5.18.- Manual de polticas.

Ventajas del uso de datos de archivo 1. Los documentos de archivo ya fueron liquidados (por alguien). 2. Los datos son invariables, puesto que quien los emiti desconoca que se estudiaran. Desventajas del uso de datos de archivo 1. Existe cierta incertidumbre acerca de que los datos sean slo una parte de la informacin original. 2. Los registros existentes pueden no ser los de mayor importancia o los ms significativos. 3. Por algn motivo pudo haber parcialidad cuando se decidi qu archivar. 4. Es difcil obtener datos nuevos de muestras equivalentes.

Figura 5.19.-Ventajas y desventajas en el uso de informacin de archivo por el analista de sistemas.

151

Adems de todas las precauciones precedentes, existen lineamientos que permiten una valiosa seleccin de los datos de archivo, estos son: 1) Descomponer los datos en subclases y verificarlos de manera cruzada para minimizar los errores. 2) Comparar informes del mismo fenmeno, por diferentes analistas (o tal vez, por alguien dentro de la organizacin). 3) Estar consiente de la parcialidad inherente asociada a las decisiones originales para archivar la informacin, conservarla y/o destruirla. 4) El uso de otros mtodos para perfilar la imagen de la organizacin, tales como la entrevista y la observacin, y realizar adems una verificacin cruzada.

5.1.4

OBSERCAIN Y TCNICAS STROBE

Una tcnica de recopilacin de informacin de gran importancia para el analista de sistemas es aquella que se funda en la observacin del tomador de decisiones y de su ambiente fsico. A travs de la observacin de las actividades de los tomadores de decisiones, el analista profundiza en lo que se hace, y no slo lo que se dice o se tiene documentado. Adems, mediante la observacin del tomador de decisiones, el analista procura identificar en primera instancia, las relaciones existentes entre los tomadores de decisiones y los dems miembros de la organizacin. Al observar el ambiente de trabajo, el analista de sistemas trata de encontrar el significado simblico del ambiente donde labora el tomador de decisiones. El analista examina los elementos fsicos del sitio de trabajo, buscando la influencia de la conducta del tomador de decisiones. Adems, mediante la observacin de los elementos fsicos bajo control del tomador de decisiones (vestimenta, ubicacin del escritorio, etc.), el analista trata de identificar el mensaje que emite el tomador de decisiones. Por ltimo, el analista trata de comprender por medio de la observacin, la influencia de quien toma las decisiones sobre los dems elementos de la organizacin. Todos estos tipos de informacin se resumen en la figura 5.20.

ACTIVIDADES

MENSAJES

RELACIONES

INFLUENCIAS

Figura 5.20.- Tipos de informacin cuando se observa la conducta del tomador de decisiones.

152

Los analistas de sistemas hacen uso de la observacin por mltiples razones. Una de ellas es obtener informacin sobre los tomadores de decisiones y su ambiente, que ningn otro mtodo podra proporcional. La observacin tambin auxilia a confirmar lo que las entrevistas y los cuestionarios hubieran detectado. El tercer motivo para hacer observaciones es rebatir o anular lo que los otros mtodos encontraron. Si realmente se est interesado en interpretar los hallazgos de la observacin, sta debe ser estructurada y sistemtica. Por ello, es fundamental que el analista de sistemas est consiente de lo que observa. Debe tener gran cuidado y reflexionar sobre qu y quines sern sujetos de observacin, as como cundo, dnde, por qu y cmo. No es suficiente darse cuenta de que la observacin es slo una necesidad. La observacin de las actividades de los tomadores de decisiones slo es una forma de averiguar sus necesidades de informacin. El ambiente fsico en el cual desempean sus actividades los tomadores de decisiones, tambin revela sus requerimientos de informacin. Muchas veces, esto implica examinar de manera sistemtica la oficina de un tomador de decisiones, al ser sta su sitio principal de trabajo. Los tomadores de decisiones influyen, y a su vez reciben la influencia del ambiente fsico que los rodea. Al mtodo de Observacin Estructurada del Ambiente se le denomina como STROBE (STRucture OBservation of the Enviroment). Como toda metodologa, el STROBE es sistemtico: 1)Porque proporciona un mtodo y clasificacin estndar para el anlisis de los elementos de la organizacin que participan en la toma de decisiones. 2)Permite que cualquier otro analista de sistemas aplique la misma estructura analtica a la misma organizacin. 3)Limita el anlisis de la organizacin a su existencia en la etapa actual de su ciclo de vida.

Elementos STROBE Los elementos de STROBE pueden dar la pauta sobre la manera en que el tomador de decisiones obtiene, procesa y comparte la informacin, as como dar informacin referente a la credibilidad del tomador de decisiones dentro de su mbito de trabajo. 1.- Ubicacin de la oficina. La oficina del tomador de decisiones con respecto a las dems oficinas; las oficinas accesibles tienden a incrementar la frecuencia de relacin y las comunicaciones informales, mientras que aquellas oficinas inaccesibles tienden a reducir tal relacin y a incrementar los mensajes orientados a la tarea. Las oficinas que se distribuyen en el permetro del edificio, originan comnmente informes o memorndums emitidos por una de las oficinas, mientras que las oficinas agrupadas favorecen que la informacin se comparta. Tambin es factible que la gente que se encuentra en oficinas distantes, tienda a ver de manera diferente a la organizacin y a desviarse en sus objetivos, ms que otros miembros de la organizacin. 2.-Ubicacin del escritorio del tomador de decisiones. La ubicacin del escritorio dentro de una oficina puede dar indicios del ejercicio de autoridad del tomador de decisiones. Aquellos ejecutivos que encierran al visitante en un espacio reducido con una pared a sus espaldas, cuando ellos mismos disponen de bastante espacio, tratan de establecer una posicin mxima de autoridad. Un ejecutivo cuyo escritorio ve hacia la pared con una silla lateral para el visitante, probablemente favorecer la participacin y un intercambio al mismo nivel. Los analistas de sistemas deben notar el arreglo del mobiliario de la oficina, en particular la posicin del escritorio. 3.- Equipo fijo de oficina. Los archiveros, los libreros y todo aquel mobiliario para almacenar artculos se incluyen en la categora del equipo fijo de oficina. Si no existiera tal equipo, es probable que el residente almacene muy pocos elementos informativos. Si contara con abundante equipo, se presumira que el tomador de decisiones le da gran valor a la informacin.

153

4.-Artculos personales (Props). Los artculos personales, o props (abreviatura del trmino flmico properties) son todos aquellos objetos personales que se utilizan para procesar informacin. Estos incluyen las calculadoras, terminales de video, plumas, lpices, reglas, etc. La presencia de calculadoras y terminales de video sugerir que el tomador de decisiones las usa personalmente, a diferencia de otro que tenga la necesidad de salir de su oficina para utilizarlos. 5.-Revistas y peridicos. La observacin del tipo de publicaciones que conserve en su oficina puede revelar si el tomador de decisiones consulta informacin externa (presente en artculos de revistas, en peridicos, notas referentes a otras empresas industriales, etc.); o ms bien, informacin de carcter interno (informes de la compaa, correspondencia interna, manuales de procedimientos).

6.-Iluminacin y color de la oficina. La iluminacin y el color de la oficina desempean un papel importante en la manera en que el tomador de decisiones obtiene la informacin. Si la oficina es iluminada clidamente con lmparas incandescentes, favorecer la comunicacin personal. Un ejecutivo obtendr mayor informacin de carcter informal dentro de una oficina clida. Mientras que otro miembro de la organizacin que trabaje en una oficina con una iluminacin brillante y colores fuertes recibir la informacin mediante memorndums y otros informes oficiales 7.-Vestimenta del tomar de decisiones. Se ha escrito bastante sobre la vestimenta del ejecutivo y de otros que ejercen autoridad. El analista de sistemas puede obtener indicios de la credibilidad exhibida por los gerentes de la organizacin, al examinar su presentacin. Con base en los estudios realizados por los investigadores sobre la impresin lograda por la apariencia de los ejecutivos, los trajes masculinos formales de tres piezas y los trajes sastre femeninos, representaran la mxima autoridad. Una presentacin informal abre las puertas para la toma de decisiones ms participativa, pero con frecuencia, si predominan los valores tradicionales, ocasiona cierta prdida de credibilidad dentro de la organizacin. Mediante el uso del STROBE, el analista de sistemas logra una mejor comprensin de cmo los gerentes obtienen, procesan, almacenan y utilizan la informacin. Un resumen de estas caractersticas y de los elementos correspondientes para examinar, se tiene en la figura 5.21. La aplicacin del STROBE tiene muchas opciones. Puede ser altamente estructurada (tales como la toma de fotografas para anlisis posteriores) o sin estructurar. A continuacin se describen cuatro mtodos. 1.- Anlisis de fotografas.- Examen en busca de elementos STROBE es anloga a la aplicacin original de la mise-en-scne del crtico de cine. De manera interesante, esta aplicacin tiene paralelo con los inicios del estudio de la gerencia, ya que a principios del siglo Frank Gilberth utiliz pelculas en sus famosos estudios de tiempos y movimientos, analizando toma por tomamaquellos movimientos que eran necesarios para realizar una tarea.

154

Caractersticas del tomador de decisiones

Elementos correspondiente en el ambiente fsico

1.- Recopila de manera informal la Informacin. .- Busca informacin fuera de La organizacin. 3.- Procesa los datos de Manera personal. 4.- Conserva la informacin de manera personal. 5.- Hace uso de la autoridad En la toma de decisiones. 6.- Exhibe creatividad en la Toma de decisiones. 7.- Comparte la informacin con Otros miembros de la organizacin.

Iluminacin incandescentes y tonos clidos. Revistas especializadas existentes en la oficina. Calculadoras y terminales de video Presentes en la oficina. Archiveros presentes en la oficina.

Escritorios ubicados para el orden.

Hace uso de vestimenta autoritaria.

Oficina fcilmente accesible.

Figura 5.21-Resumen de las caractersticas de los elementos STROBE.

La aplicacin fotogrfica del STROBE presenta algunas ventajas particulares. Una de ellas es que como cualquier documento permite analizarlo de manera repetida, lo cual llega a ser muy til cuando el tiempo, la distancia, o los costos limitan las visitas a la organizacin, y la segunda ventaja es que el fotgrafo puede hacer el enfoque especficamente en los elementos pertinentes del STROBE; y en consecuencia, eliminar otros elementos extraos. Adems, al usar la fotografa para el STROBE contamos con un instrumento de anlisis detallado, y con la fotografa quedan superadas las limitaciones de tiempo y espacio. Una cuarta ventaja es que el fotgrafo puede registrar aquellos detalles que pasan desapercibidos fcilmente, si el analista no slo observa, sino adems conduce una entrevista o investiga documentos. Hay ciertos inconvenientes de la toma de fotografas para implantar el STROBE. El primero y ms importante es la decisin de qu fotografiar. A diferencia del ojo humno, las fotografas estn limitadas sobre lo que pueden apuntar y tomar. El segundo inconveniente es que la fotografa, aunque resulta no interferente a largo plazo, inicialmente s lo es. El analista de sistemas se enfrentar a problemas sobre la postura del tomador de decisiones, as como el cambio de ambiente, intencional o no, con un intento de ofrecer algo ms aceptable para el analista.

2.-Enfoque de lista de verificacin/escala de Likert.-Los investigadores han desarrollado escalas de Likert de cinco puntos relativos a siete de las caractersticas de los tomadores de decisiones, que pueden observarse a travs de los elementos fsicos del ambiente del tomador de decisiones, como se muestra en la figura 5.22. En un estudio original de diecisis administradores de bancos de sangre y directores mdicos de Estados Unidos y de Canad, hubo una validacin convergente y discriminante de la informacin obtenida por escala STROBE; de la informacin lograda por medio de entrevistas y de escalas conductuales. Las mismas escalas de Likert se recomiendan para aquellos analistas de sistemas que quieran aplicar el STROBE junto con otros mtodos ms tradicionales.

155

3.- Listas anecdticas (con uso de smbolos).- Este enfoque STROBE fue til para averiguar los requerimientos de informacin de cuatro tomas de decisiones clave de un banco de sangre del Medio Oeste de Estados Unidos. Como puede observarse en la figura 5.23, en ese caso el analista de sistemas utiliz cinco smbolos taquigrficos para evaluar la observacin de los elementos STROBE comparada con la narracin de la organizacin obtenida por medio de entrevistas. Los cinco smbolos utilizados son: Un crculo con una paloma significa que se confirma la narracin. Un crculo cruzado significa que contradice a la narracin. Un crculo dentro de un ojo sirve como indicio para que el analista examine ms all. Un crculo dentro de un cuadro significa que la observacin de los elementos STROBE modifica la narracin. Dos crculos juntos significa que lo observado complementa la narracin.

156

Escalas STROBE para el examen del ambiente fsico

1) Los tonos clidos en la iluminacin de la oficina, paredes, pinturas y graficas crean un foro informal para el intercambio de la informacin. Lmparas fluorescentes paredes de tonos fros sin decoracin Lmpara incandescentes paredes de tonos clidos decoracin clida.

2) La oficina tiene varias formas de informacin tradas del exterior de la organizacin revistas, publicaciones de asociaciones y peridicos comerciales. No existen fuentes cuatro o ms revistas externas de informacin o peridicos. 3) Se tienen apoyos para el proceso de la informacin, se encuentran presentes y son fcilmente accesibles. No se ven calculadoras ni terminales de video Calculadoras o monitores accesibles desde el asiento

4) la oficina cuenta con numerosos elementos para el almacenamiento de la informacin. No existen archiveros en la oficina. Cuatro o ms archiveros o gabinetes.

5) El escritorio se encuentra ubicado para ampliar el territorio del administrador y limitar el espacio del visitante. Escritorio ubicado contra la pared Escritorio utilizado como una barrara, con poco espacio para el visitante

6) Se viste de manera formal ms que un atuendo informal o sport. Vestido informal o sport 7) La oficina del administrador es fcilmente accesible. Oficina localizada en un piso diferente a sus subordinados oficina no ms all de 15m de sus subordinados. vestido conservador

Figura 5.22.- Escalas tipo Likert utilizadas para examinar con STROBE.

157

Se utiliza una lista anecdtica con smbolos en la aplicacin de STROBE

Narracin planteada Por los miembros de la organizacin La informacin fluye fcilmente en todos Los niveles Adams dice que calculo por mi cuenta los porcentajes Vinne dice: Me gustaria Leer sobre tales temas Dice Ed: La mano Derecha no sabe los Que hace la mano Izquierda Dice Adam que nuestra compaa No cambia mucho El staff de operaciones Trabaja en ocasiones Durante la noche Vinne dice Hacemos Las cosas como desea El Sr. Adms. Julio dice:En ocasiones, Staylen no parece Tener cuidado

Ubicacin y equipo de la oficina

Color, iluminacin y grafica de la oficina

Vestimenta del tomador de decisiones

Smbolo

Confirma la narracin

Nota para mirar mas all

Niega ose opone a la narracin

Modificar la narrativa

Complementar la narracin

Figura 5.23.- Lista anecdtica con smbolos utilizada en la aplicacin del STROBE.

Cuando el STROBE se implanta de esta manera, el primer paso a seguir es determinar los temas fundamentales de la organizacin que dan lugar a las entrevistas. Despus se observan los elementos STROBE de manera sistemtica y se construye una matriz que contiene las ideas principales de la narracin de la organizacin, acerca de la obtencin de informacin, su procesamiento, cmo se almacena y se comparte, en uno de los ejes, y los elementos STROBE en el otro eje. Cuando se comparan las narraciones y las observaciones se utiliza de manera apropiada uno de los cinco smbolos, para caracterizar la relacin entre la narracin y los elementos observados de relevancia. El analista deber crear luego una tabla que primero documente y luego facilite el anlisis de las observaciones. 4.- Comparacin de la observacin/narracin.- Los fanticos del cine rara vez asisten a una pelcula con una lista de verificacin de mise-en-scne en la mano, cuando menos, pocos de los elementos llegan a tener un impacto subconsciente en ellos. Conforme el analista se va percatando de los elementos de la mise-en-scne y los llega a observar de manera consciente, puede alcanzarse cierta perspicacia de valor, an sin el auxilio de una lista de verificacin. Examinar la organizacin con un enfoque basado en el STROBE, es el comienzo de la observacin estructurada.

158

5.2 HERREMIENTAS CASE

Los analistas deben ser organizados, precisos y completar todo aquello que realicen. En los ltimos aos, los analistas han comenzado a beneficiarse de novedosos intrumentos de productividad creados explcitamente para mejorar sus tareas de rutina mediante el uso de soportes automatizados. A estos elementos se les denomina tecnologas de ambientes integrados o de manera alternativa instrumentos CASE (por Computer Aided Software Engineering Tools). Los tres principales enfoques que el analista sigue al adoptar las tecnologas de ambientes integrados son incrementar la productividad, comunicarse con mayor eficacia con los usuarios, e integrar el trabajo que realizan sobre el sistema, desde el principio hasta al final del ciclo de desarrollo, tal y como se ilustra en la figura 5.25 .

Incremento de la productividad

Comunicacin efectiva con los usuarios

Integracin de las actividades del ciclo de la vida de los sistemas

OPCION DE TECNOLOGIAS DE TALLER

Figura 5.24.- Enfoques del CASE.

Las tecnologas de ambientes integrados (que apoyan diferentes combinaciones de tcnicas estructuradas, tales como los diagramas de flujo de datos, los diccionarios de datos, los diagramas estructurales, los diagramas de relacin de entidades y la documentacin) son otras formas de incrementar la productividd del analista de sistemas. La medicin de productividad de un analista, definitivamente no es sencilla, en especial a corto plazo. A largo plazo, es claro que la modificacin o la creacin de un sistema de informacin bien utilizado forma parte del criterio. Se pouede ver en retroespectiva en el proyecto y aceptar que el analista habra sido ms productivo si el sistema de informacin se hubiera enfrentado de manera adecuada a las oportunidades que le fueron planteadas o hubiera resuelto el problema que le fue asignado.

159

Cuando se habla de la productividad a travs de las tecnologas de ambientes integrados, estamos hablando de una mejora mensurable en calidad y cantidad de los resultados del analista, para cada actividad que emprende con la ayuda de nuevas tecnologas, comparada con lo que pudiera haber ocurrido, posiblemente con mtodos alternativos. Los instrumentos CASE facilitan la interaccin entre los miembros del grupo al permitir que la elaboracin de diagramas sea un proceso dinmico e imperativo, ms que uno en el cual los cambios sean tediosos; y, en consecuencia, tiendan a disminuir la productividad. En este caso, las tecnologas de ambiente integrado para el dibujo y el registro de diagramas de flujo proveen de un registro del cambio de opinin de los grupos, con base en los diagramas de flujo. Mejoramiento de la comunicacin analista-usuario Con el fin de que el sistema propuesto llegue a utilizarse, es esencial que exista una comunicacin excelente entre los analistas y los usuarios a todo lo largo del ciclo de desarrollo de sistemas. Indiscutiblemente, el xito de la eventual implantacin del sistema reside en la capacidad de los analistas y los usuarios para comunicarse de una manera significativa. De tal forma que la experiencia que los analistas han acumulado al utilizar las nuevas tecnologas de taller, redunde en una comunicacin significativa entre los usuarios y los analistas. Lo que los analistas y los usuarios han reportado es que las tecnologas de taller les confieren una comunicacin significativa acerca del sistema. A travs del uso de las peculiaridades del soporte automatizado en pantalla, los clientes pueden ver cmo los flujos de datos (y otros conceptos del sistema) fueron concebidos. Al observarlos, pueden solicitar correcciones o cambios que podran requerir mucho ms tiempo que por medio de un sistema manual. Quizs sea cuestionable si un diagrama particular se pueda considerar de utilidad para los usuarios o los analistas al final del proyecto. Sin embargo, lo importante es que el soporte automatizado sirve para muchas actividades del diseo de ciclo de vida (con frecuencia, de manera imperceptible para los usuarios) como un elemento de conclusin al actuar como catalizador de la interaccin analista-usuario. El mismo tipo de argumentos planteados para la productividad existe tambin en este campo; esto es, las tareas manuales de dibujar, reproducir y distribuir toman mucho menos tiempo, y tal progreso puede compartirse con mayor facilidad con los usuarios.

Integracin de las actividades del ciclo de vida En las tecnologas de ambiente integrado es su uso eventual durante el ciclo de vida de los sistemas, con el fin de integrar sus actividades y proporcionar una continuidad entre cada una de las fases. De hecho, aunque los paquetes automatizados disponibles as lo indican, actualmente no lo permiten. Las empresas de consultora de sistemas de informacin trabajan de manera independiente para construir enlaces entre las porciones automatizadas y manuales y, con ello, llenan las ausencias, de tal forma que el soporte automatizado pueda utilizarse a lo largo del ciclo de vida. Algunas de estas empresas han tenido mucho xito, en la figura 5.25 se muestra un ejemplo.

160

1) Identificacin de problemas, objetivos y objetivos. Inicio de la elaboracin del diagrama E-R del plan del proyecto

7) Implementacin y evaluacin del sistema. Uso del software de administracin de proyectos para la conclusin 6) Pruebas y mantenimiento de sistema. Generar datos de prueba y verificar los datos de las pruebas

2) Determinacin de los requerimientos de informacin.

Organizar las actividades de captura de datos mediante uso de prototipos

3) Anlisis de las necesidades del sistema.

Dibujar el diagrama de flujo de datos, desarrollar el diccionario de datos

Construir diagramas de estructuras, transferir datos del diccionario de datos al cdigo de programacin

Elaborar las pantallas y reportes; modelar los datos

4) Diseo del sistema recomendado.

5) Desarrollo y documentacin de software.

Figura 5.25.- Instrumentos de CASE para las etapas del ciclo de desarrollo de los sistemas.

Las actividades de integracin son importantes porque capacitan al analista para concebir lo que se encuentra dentro de la perspectiva del sistema, es de gran valor lograr asimilar adecuadamente el problema, as como auxiliar al analista a percatarse del impacto de cualquier cambio que se contemple. Por ejemplo, ms que hacer parches con trabajos de planeacin estratgica y otros realizados en el diseo lgico de programas, la integracin a travs de la automatizacin facilita el movimiento entre las diferentes actividades del ciclo de vida. Esto es especialmente til cuando hay la necesidad de realizar iteraciones de retroalimentacin y modificacin a lo largo de una etapa particular del ciclo de vida, recordando tambin que el compromiso del usuario es sumamente importante durante todas las etapas.

161

VENTAJAS
Inversin en paquetes comerciales del alto costo

Forzar al analista a cambiar sus mtodos de trabajo por otros nuevos.

Productividad

Comunicacin

Descubrir puntos ciegos de las herramientas de desarrollo a travs del recorte y pegado del software

Integracin

Requerimiento de automatizacin de los instrumentos CASE debido al rezago de la integracin d las actividades del ciclo de vida.

Figura 5.26.- Ventajas de la utilizacin de las tecnologas de ambiente.

1. Alcanzar un nivel competitivo sobre otros en la misma lnea de trabajo.- Las ventajas servicios de sistemas con quien plantee la mejor cotizacin, ya sea interno o externo. De manera alternativa, si hay un claro sistema de reembolsos, donde los usuarios estn bien informados de cunto cuesta un servicio y cunto tiempo involucra su realizacin, y en respuesta pueden ampliar o restringir sus gastos para esfuerzos en sistemas, ser entonces una ventaja para el analista interno utilizar y promover las tecnologas de ambiente integrado. 2. Estandarizacin de mtodos internos y externos.- Mucho se ha dicho acerca de la eleccin de las tcnicas para el diseo y la documentacin surge del hecho de que no hay un estndar, ni una tcnica universal. Se ha observado que esto puede causar problemas de comunicacin entre los mismos analistas, sin mencionar el caso entre los analistas y los usuarios. Una ventaja de los instrumentos CASE es que aportan un vocabularios comn para analistas y usuarios. 3. A travs de la estandarizacin en la elaboracin de diagramas, los nuevos analistas de un grupo se encuentran capacitados para comprender con rapidez el trabajo que se ha realizado en el sistema. Esto eliminar la necesidad de establecer primero qu tcnica de elaboracin de diagramas se emple antes de llegar al contenido. La estandarizacin tambin tiene una ventaja externa, ya que un analista que ha tenido experiencia en el uso de ciertos paquetes de tecnologas de ambiente integrado, permitir que el cliente cuente con una manera fcil de comunicarse. 4. Viendo problemas viejos de nuevas maneras.- La importancia de resolver el problema correcto mediante una solucin de sistemas. Esto implica ubicar con precisin el problema dentro de un contexto, de tal forma que se involucren el nmero y los tipos correctos de subsistemas de la organizacin. Una ventaja de la utilizacin de las tecnologas de ambiente integrado es que crean un nuevo contexto para problemas viejos, de tal forma que se estimula la creacin de nuevos ideas. Por ejemplo, cuando los diagramas de flujo pueden elaborarse con rapidez y luego corregirse, es ms fcil comparar la conceptualizacin de los flujos de datos que se tenan con anterioridad. Este tipo de tormenta de ideas grfico sirve como un catalizador para la creacin de nuevas de ideas. Adems, observe que cuando se integran las actividades del ciclo de vida (esto

162

es, la documentacin con la elaboracin de diagramas) pueden surgir nuevas ideas. El analista tendr una perspectiva diferente de los sistemas, y las interrelaciones que pudieran existir se vuelven aparentes. 5. Adopcin de la automatizacin como rutina.- Cuando los analistas adoptan las tecnologas de ambiente integrado, dan un gran paso hacia el mejoramiento de su credibilidad con sus clientes, ya que el analista muestra con su ejemplo que la automatizacin le confiere beneficios a los usuarios. El analista no mencionar la automatizacin por un momento, para luego regresar a preparar laboriosamente los bosquejos manuales de su tarea siguiente. El uso de las tecnologas de ambiente integrado tambin sensibiliza a los analistas sobre los problemas que entrentan los usuarios al tratar de utilizar instrumentos automatizados. El analista experimentar, en cierta medida, la experiencia del usuario al ser capaz de caminar una milla en los zapatos del usuario.

DESVENTAJAS a. b. c. d. El problema del retraso de la integracin. La necesidad de superar las lagunas del responsable del desarrollo. El cambio de los mtodos del trabajo. La inversin en un paquete comercial caro.

Alcanzar un nivel competitivo superior a alas compaas que no han adoptado las tecnologas de ambiente integrado

Adopcin de la automatizacin como parte de la rutina del analista y practicar lo que este pregona

Productividad

Comunicacin

Mejoras en la uniformidad de los mtodos de elaboracin de diagramas tanto internas como externas

Integracin

Descubrimiento de ideas nica al ver viejos problemas con nuevos enfoques

Figura 5.27.-Desventajas de la utilizacin de las tecnologas de ambiente.

6. Adaptacin debido al rezago de integraci.- Al ser relativamente nuevos, en ocasiones se quedan cortos en las expectativas que crean. Esto ha sido evidente en su incapacidad general para auxiliar a los analistas para cubrir plenamente todas las actividades del ciclo de vida. Al decidir la compra de un paquete comercial de automatizacin, la decisin debe incluir la aceptacin de que con el fin de integrarlo plenamente ser necesario un buen esfuerzo de adaptacin.

163

7. Superacin de puntos ciegos del desarrollador.-Es difcil anticiparse a cada uno de los usos que pudiera tener una aplicacin. Lo mismo es cierto para las tecnologas de ambiente integrado desarrolladas con fines comerciales. Quienes las desarrollan no pueden ayudar, pero tienen lagunas en trminos de comprender con precisin lo que un analista o un programador quisieran al utilizar el software. Un ejemplo de un punto ciego es que los instrumentos CASE no pueden producir estructuras utilizables por los programadores para algunos lenguajes de programacin aunque sean los de mayor difusin como por ejemplo COBOL. 8. El cambio de mtodos de trabajo.- El cambio de tecnologa implica tambin un cambio de los mtodos de trabajo. Como se ha visto, en las interacciones con los usuarios, la resistencia al cambio es parte de la naturaleza humana, Nunca ser fcil dejar atrs un antigui mtodo de trabajo por otro nuevo, a un nivel emotivo, incluso si los beneficios son claros a un nivel intelctual. Un gran grupo de consultora en administracin y en sistemas ha intentado resolver el problema asociado al cambio, permitiendo que los analistas adopten aquellas tecnologas de ambiente integrado que encuentren personalmete tiles. Y no es obligatorio el cambio sistemtico a un mtodo de automatizacin. El cambio gradual hacia los instrumentos CASE basados en una necesidad parecen operar bien para ellos, aunque no se percaten inmediatamente de las ventajas de la estandarizacin. Afortunadamente, la mayora de los analistas desean mantenerse actualizados y no tienen prejuicios por la tecnologa, como podra ocurri con otros tipos de usuarios. 9. La inversin en paquetes comerciales costosos.- Los costos iniciales del software CASE pueden ser significativos, aunque tales costos se han ido reduciendo. Si se es empleado de una pequea empresa, que apenas comienza o de otra que tiene dificultades para obtener utilidades, los costos iniciales de las tecnologas de ambiente integrado le har reconsiderar su adquisicin. El reconocimiento de las desventajas que hemos discutido, tales como el rezago en las capacidades de interaccin, as como las inevitables lagunas de quien desarrolla, pueden darle pautas para considerar si invierte en los instrumentos CASE, que podran desilucionarlo ms adelante. Es imperativo que analice los factores internos, as como los externos antes de tomar una decisin. Debe ponderar los incrementos en productividada largo plazo contra los costos de adquisicin y de aprendizaje. Adems, el usuario necesitar considerar si puede sobrevivir sin las tecnologas de ambiente integrado, si es que sus competidores las estn utilizando de rutina.

5.2.1 ESTRUCTURADAS
De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas, en el caso de CASE para automatizar o apoyar una o ms fases del ciclo de vida del desarrollo de sistemas. Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, tambin se puede escoger una herramienta CASE que permita llevar a cabo el resto de tareas del modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir: 1. Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de bases de datos. 2. Herramientas de diseo para dar apoyo al anlisis de datos. 3. Herramientas que permitan desarrollar el modelo de datos corporativo, as como los esquemas conceptual y lgico.

164

4. Herramientas para desarrollar los prototipos de las aplicaciones. El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicacin de bases de datos.

En la dcada de los setenta el proyecto ISDOS desarroll un lenguaje llamado "Problem Statement Language" (PSL) para la descripcin de los problemas de usuarios y las necesidades de solucin de un sistema de informacin en un diccionario computarizado. Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relacin de problemas y necesidades. Pero la primera herramienta CASE como hoy se conoce fue "Excelerator" en 1984, era para PC. Tecnologa Case Supone la automatizacin del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de informacin y se plantean los siguientes objetivos: a. Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo. b. Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones. c. Simplificar el mantenimiento de los programas. d. Mejorar y estandarizar la documentacin. e. Aumentar la portabilidad de las aplicaciones. f. Facilitar la reutilizacin de componentes software. g. Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilizacin de grficos. Automatizar: a. b. c. d. e. Permitir: a. b. c. d. La reutilizacin del software. La portabilidad del software. La estandarizacin de la documentacin. Componentes de una herramienta case. El desarrollo del software. La documentacin. La generacin del cdigo. El chequeo de errores. La gestin del proyecto.

De una forma esquemtica podemos decir que una herramienta CASE se compone de los siguientes elementos: a. Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestin se realiza mediante el apoyo de un Sistema de Gestin de Base de Datos (SGBD) o de un sistema de gestin de ficheros. b. Meta modelo (no siempre visible), que constituye el marco para la definicin de las tcnicas y metodologas soportadas por la herramienta. c. Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona as un medio de comunicacin con otras herramientas.

165

d. Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta. e. Interfaz de usuario, que constar de editores de texto y herramientas de diseo grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y mens, con la ayuda del ratn, definir los diagramas, matrices, etc. que incluyen las distintas metodologas. f. La estructura CASE general se basa en la siguiente terminologa: g. CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas. h. CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin de sistemas y el soporte de sistemas. i. CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestin de proyectos y la estimacin.

5.2.2 HERRAMIENTAS CASE ORIENTADA A OBJETOS

Las herramientas CASE orientadas a objetos proporcionan el soporte para las metodologas y notaciones orientadas a objetos, e incluso permiten generar parte del cdigo de las aplicaciones. Las nuevas versiones de las herramientas CASE orientadas a objetos estn ya incorporando los nuevos lenguajes como Java. Muchas de estas herramientas tambin dan soporte a bases de datos relacionales, permitiendo el modelado y diseo lgico y en algunos casos el fsico, de la base de datos, incluyendo la generacin de esquemas e ingeniera inversa sobre tablas y otros elementos del RDBMS. Las herramientas CASE ofrecen grandes ventajas a los desarrolladores de sistemas software de gran tamao. Mientras una espiral de requisitos del sistema sigue llevando la complejidad del sistema a nuevos niveles, las herramientas CASE nos permiten abstraernos del cdigo fuente, a un nivel donde la arquitectura y el diseo son ms aparentes y fciles de entender y modificar. Se puede decir que cuanto mayor es el proyecto software, ms importante resulta el utilizar tecnologas CASE. Ya que los desarrolladores en este tipo de sistemas interaccionan slo con una o varias partes del sistema diseado por los diseadores, deben encontrar de manera sencilla el subconjunto de clases y mtodos, as como asimilar y entender cules son las interfaces con ellos. En el mismo sentido el gestor del proyecto debe ser capaz de ver una representacin del diseo a alto nivel y entender cmo funciona en un tiempo razonable. Por estas razones, las herramientas CASE junto con las metodologas nos proporcionan una forma de representar sistemas demasiado complejos de entender ya sea a partir del cdigo subyacente o de alguna forma basada en esquemas. Para alcanzar el grado de abstraccin necesario las herramientas CASE orientadas a objetos (OOCASE) permiten crear diagramas que representan el modelo de objetos utilizando los elementos notacionales de metodologas especficas como: OMT (Object Modeling Technique), Booch, Jacobson Use Cases, UML (Unified Modeling Language) o Fusion. El soporte notacional es slo una forma de clasificar las herramientas CASE, otras caractersticas a tener en cuenta son: el soporte de varios lenguajes de programacin, el uso de ficheros o bibliotecas para almacenar la informacin del modelo y la integracin con software de control de versiones. Las herramientas OOCASE crean diagramas que representan el modelo de objetos utilizando los elementos notacionales de las diferentes metodologas. Estas notaciones representan grficamente clases (incluyendo atributos, mtodos y eventos), relaciones entre objetos (herencia,

166

agregacin, colaboracin), y cardinalidad. Adems la mayora, aunque no todas, las herramientas OOCASE ofrecen la posibilidad de generar un esqueleto del cdigo de la aplicacin. Este esqueleto generalmente incluye la definicin de las clases y los prototipos de las funciones. Analizando la mayor parte de las aplicaciones software nos podemos encontrar con elementos tan dispares como pginas Web, acceso a bases de datos, cdigo C++, cdigo Java, interfaz CORBA de acceso a un servidor C++, etc. Esta disparidad es el reto bsico que tienen que afrontar los vendedores de herramientas CASE que quieran proporcionar un entorno de dice no integrado Con los aos va siendo mayor la capacidad de trabajar ms con menos herramientas, lo que supone una mayor integracin y una menor complejidad en las herramientas CASE, lo que nos lleva a una mayor productividad. A la hora de alcanzar una mayor integracin, UML se presenta como una buena alternativa, ya que se basa en un metamodelo extensible. El metamodelo UML es un modelo que describe modelos. Una visin de este modelo nos muestra elementos orientados a objetos como clases, atributos y mtodos, todos ellos y sus interrelaciones representados como metaclases. Al modelo UML se le pueden aadir ms metaclases, por ejemplo para describir modelos entidad relacin, as como realizar extensiones para tratar con interfaces como las definidas usando CORBA. El estndar UML define notaciones para representar la informacin y su interrelacin desde una perspectiva grfica, adems soporta el uso de un formato de intercambio. El CASE Data Interchange Format (CDIF -www.cdif.org-) es un anexo importante al UML, ya que, aunque UML especifica el tipo y la relacin que existe entre la informacin que ha de ser almacenada en una biblioteca (repository), no especifica cmo se debe guardar esta informacin, dejando la eleccin a los distintos vendedores. El CDIF permite una representacin ASCII para una biblioteca de diseos, dicha representacin puede ser utilizada para transferir los datos del diseo de una herramienta CASE a otra, pudiendo ser utilizada por generadores de informes y otras herramientas de este estilo. Cuando decimos que una herramienta OOCASE ``genera cdigo'', nos estamos refiriendo a cabeceras y prototipos en el caso de C++ o Java, y a informacin de esquema en el caso de bases de datos relacionales. O sea, se proporciona la base para clases, mtodos, y atributos en aplicaciones orientadas a objetos, as como tablas, columnas y relaciones en DBMS relacional. El tener una herramienta CASE que proporcione cdigo de aplicacin y de base de datos ayuda a garantizar que el modelo y su implementacin estn sincronizados. Esta sincronizacin hace que la herramienta de modelado sea ms til para los desarrolladores. Sin un mecanismo integrado para guardar la implementacin y el modelo sincronizados, se produce con frecuencia una desconexin entre ambos. Dicho de otra forma, es frecuente que las mejores soluciones se hagan evidentes en el proceso de implementacin, si estas soluciones, que llevan con frecuencia a modificaciones en el diseo, no son realimentadas hacia atrs en el modelo de una forma conveniente, el modelo puede pasar a estar ``out of date''. El valor intrnseco del modelo se pierde desde el momento en que no podemos confiar en l y por lo tanto deja de usarse. Para soportar la generacin de ficheros de cabecera y prototipos de mtodos, debe haber una forma de asegurar que la herramienta no sobrescribe el cuerpo de los mtodos y otro cdigo y comentarios introducidos por el desarrollador. La forma ms fcil y frecuente de hacer esto es introducir informacin del modelo dentro del cdigo generado. Esto suele llevar a las protestas de los desarrolladores cuando utilizan por primera vez una herramienta de este tipo. Estas protestas son entendibles, ya que la legibilidad del cdigo fuente se reduce de una forma significativa debido a la informacin introducida por la herramienta CASE en bloques de comentarios. Dos razones reducen la importancia del problema de ``polucin'' del cdigo: a. Los desarrolladores estn acostumbrados a ver los comentarios extra y filtrarlos mentalmente. b. La utilizacin cada vez ms frecuente de entornos de desarrollo integrado cada vez ms sofisticados (Ej.: Visual Basic de Microsoft). Estos entonos ofrecen browsers para clases y mtodos que hacen la navegacin hacia declaraciones y definiciones especficas muy sencilla, con lo cual los desarrolladores pueden evitar el ``ruido'' introducido en los ficheros de cdigo nativos.

167

Las herramientas OOCASE necesitan colaborar con otras aplicaciones a lo largo del ciclo de vida del proyecto. Esto es particularmente cierto en el caso del software de control de versiones. Debido a que los modelos estn expuestos a frecuentes cambios durante el anlisis y el diseo, muchos vendedores integran ya este tipo de software. Adems, las herramientas CASE deben trabajar en un entorno multiusuario ya que los proyectos grandes los modelan y construyen equipos de desarrolladores. Las herramientas CASE que almacenan los modelos en ficheros del sistema operativo en vez de utilizar una biblioteca almacn, deben definir unidades de modelo que puedan ser utilizadas de forma concurrente por diferentes diseadores y analistas. Estas unidades adems deben estar bajo el control de algn software de versiones. La granularidad de las unidades de este tipo es un factor importante ya que con frecuencia diferentes partes del modelo estn entrelazadas. Cuando un desarrollador coge una parte del modelo, esa parte debera ser lo suficientemente pequea como para que otros desarrolladores puedan coger otros elementos del modelo y trabajar de una forma independiente. Hay que tener en cuenta que cualquier parte del modelo que es comn a ms de una unidad y a la que se acceda con frecuencia, puede convertirse en un cuello de botella para los procesos de modelado. Las herramientas OOCASE seguirn en el futuro soportando diferentes metodologas. Incluso cuando UML alcance su esperada penetracin en el mercado, aparecern otras metodologas con gran nmero de seguidores, existiendo siempre varias notaciones y metodologas activas. Es por eso, que ser importante que las herramientas CASE que ahora almacenan la informacin del modelo en ficheros evolucionen hacia almacenes a los que puedan acceder diferentes herramientas. Esto har ms fcil el intercambio de informacin entre herramientas que realizan clases especficas de modelado. De todas formas es tambin deseable que se reduzca el nmero de herramientas CASE necesarias para modelar una aplicacin. El nmero de herramientas CASE que soportan UML ha crecido muy considerablemente estos ltimo aos.

168

5.2 DESARROLLO DE PROTOTIPOS

El desarrollo de prototipos es una metodologa valiosa para identificar con rapidez, las necesidades particulares de informacin del usuario. En trminos generales, el desarrollo efectivo de prototipos debera realizarse en las primeras etapas del ciclo de vida de desarrollo de sistemas, durante la fase de establecimiento de los requerimientos de informacin. Sin embargo, el desarrollo de prototipos es una tcnica compleja que requiere del conocimiento cabal del ciclo de vida de desarrollo de sistemas antes de llegar a implantarlo con xito. El desarrollo de prototipos se muestra con el fin de destacar su relevancia como tcnica de obtencin de informacin. Cuando se piensa de esta manera respecto al desarrollo de prototipos, el analista de sistemas se encuentra en posibilidad de detectar las reacciones iniciales de los usuarios y de la gerencia hacia el prototipo; las sugerencias de los usuarios sobre modificaciones al sistema bajo desarrollo o depuracin si ste ya fue presentado; las posibles innovaciones para l y los planes de revisin para aquellas partes del sistema que requieran implantarse primero o las reas de la organizacin que debern considerarse prximamente. La figura 5.28, muestra los cuatro tipos de informacin que busca el analista durante el desarrollo de prototipos.

REACCIONES DEL USUARIO

SUGERENCIAS DEL USUARIO

INNOVACIONES PLANES DE REVISIN

Figura 5.28.- Tipos de informacin buscada durante el desarrollo de prototipos.

La palabra prototipo se utiliza de muchas maneras diferentes. Ms que intentar la sntesis de todas estas connotaciones en una sola definicin, o tratar de establecer un solo enfoque correcto para el tpico de desarrollo de prototipos.

Prototipos de remiendo Tiene que ver con la construccin de un sistema que si bien funciona, se encuentra remendado o parchado. En ingeniera a este concepto se le denomina como tableta de prototipo (breadboarding), en donde se desarrolla un circuito integrado (microscpico) mediante un modelo operable de elementos sobrepuestos an no definitivos. Un ejemplo en los sistemas de informacin es la creacin de un modelo operable, el cual cuenta con todas sus caractersticas necesarias, aunque pudiera ser ineficiente. En este caso de

169

prototipos, los usuarios se relacionan con el sistema, adaptndose a las interfaces y a los tipos de salidas disponibles. Sin embargo, los procesos de recuperacin y almacenamiento de informacin son ineficientes, ya que los programas se escribieron de manera apresurada con el fin exclusivo de que fueran operativos, aunque no eficientes. Este tipo de prototipos se muestra en la figura 5.29. Otro tipo de prototipos para sobreponer, podra ser aquel sistema de informacin que cuente con todas las caractersticas propuestas, pero que en realidad sea un modelo bsico, que eventualmente ser perfeccionado.

Figura 5.29.-Prototipo de remiendo.

Modelo a escala no funcional Se construyen a escala, con el objeto de evaluar ciertos aspectos de diseo. Un ejemplo de ello sera la construccin de un modelo de un automvil a escala para evaluarlo en tneles de viento. Si bien el tamao y la forma del auto es preciso, el vehculo no funciona. En este caso, slo se incluyen las caractersticas esenciales del automvil para la realizacin de las pruebas particulares. Un modelo no funcional de un sistema de informacin a escala podra ser aqul en el cual la codificacin que se requiere es extensa en cantidad; y mas bien, podra lograrse una idea de la utilidad del sistema, si en el prototipo funcionan nicamente los procesos de entrada y salida. Este tipo de prototipos se muestra en la figura 5.30. En este caso, el procesamiento de informacin no ha sido contemplado, por ser en s costoso y requerir de tiempo. Sin embargo, la evaluacin sobre la utilidad del sistema puede realizarse con base en el prototipo de las entradas y salidas.

170

ENTRADA

PROESO

SALIDA

Figura 5.30.- Prototipo no funcional puede indagar sobre la opinin de los usuarios sobre las interfaces (entrada y salida).

Primer modelo a escala completa Desarrollo de prototipos implica crear un primer sistema a escala completa, llamado con frecuencia piloto. Un ejemplo de ello sera el desarrollo del prototipo del primer aeroplano de una serie. El prototipo es completamente funcional y es la realizacin de lo que segn el diseador ser una serie de aeroplanos con caractersticas idnticas a ste. Este tipo de prototipos es til cuando se planea implantar el mismo sistema de informacin en varias instalaciones. Un modelo funcional a escala total permite una interaccin realista con el sistema, reduciendo los costos de solucin de cualquier problema que emerja con el nuevo sistema. Este tipo de prototipos se representa en la figura 5.30. Por ejemplo, cuando una cadena de tiendas de autoservicio piensa utilizar el mismo sistema computarizado para el control de envo de sus vendedores en todas sus sucursales, deber instalarse un primer modelo a escala en uno de los almacenes, con el fin de solucionar cualquier problema que se presente, antes de implantarlo en las demas tiendas. Otro ejemplo tpico lo tenemos en las instalaciones bancarias con la transferencia electrnica de fondos. En una o dos localidades se instalara primero un modelo a escala completa del prototipo, y si tuviera xito, se implantara en todas las sucursales, con base en el patrn de uso y en otros elementos fundamentales.

171

LOCACIN 1 LOCACIN 2 LOCACIN 3

Figura 5.31.- Primer modelo a escala completa.

Un modelo que cuenta con ciertas caractersticas esenciales Construccin de un modelo funcional que incluya algunas, pero no todas las caractersticas que tendr el sistema final. Una analoga sera un centro comercial inconcluso que abre provisionalmente sus puertas. En un centro comercial de este tipo, se tienen las funciones esenciales, tales como la posibilidad de adquirir ciertos artculos, la existencia de restoranes de comida preparada y el estacionamiento; aunque no se ha ocupado por completo, ni se ofrecen todos los artculos que eventualmente se ofrecern en la apertura formal. Con una visita inicial al centro comercial inconcluso es posible imaginar lo que ste tendr en el futuro. Cuando los prototipos se desarrollan de esta manera, se contemplan ciertas caractersticas esenciales, mas no todas. Por ejemplo, el men que presentar un sistema en la pantalla, puede enumerar seis caractersticas: agregar un registro, actualizar un registro, eliminar un registro, bsqueda de un registro con base en una palabra clave, enumerar registros y otras clases de bsquedas. Sin embargo, en el prototipo, el usuario slo dispone de tres de las seis funciones, de tal forma que l puede agregar un registro (caracterstica 1), eliminarlo (caracterstica 3), o desplegarlos (caracterstica 5), tal y como se muestra en la figura 5.31.

172

OPCIN 1

OPCIN 3

OPCIN 5

Figura 5.32.- Modelo que cuente con ciertas caractersticas esenciales.

Cuando se desarrollan este tipo de prototipos, el sistema se planifica con base en mdulos, de tal forma que aquellas caractersticas que se aprobarn en el prototipo podran incorporarse en un sistema final mayor, sin requerir de gran esfuerzo durante la conexin. Los prototipos desarrollados de esta manera, operan como parte de sistemas actuales y no son slo un parche como los hemos considerado en la primera definicin de prototipos.

Los prototipos como alternativa en el ciclo de vida del desarrollo de sistemas Ciertos analistas afirman que el desarrollo de prototipos debera considerarse como una alternativa en el ciclo de vida del desarrollo de sistemas (SDLC), las reservas que se tienen respecto al ciclo de desarrollo de sistemas se centraen dos preocupaciones relacionadas entre s. La primera se debe al extenso tiempo que transcurre a lo largo del SDLC, como se plantea en la figura 5.3. Conforme el analista invierte ms tiempo, el costo del sistema desarrollado se incrementa proporcionalmente. La segunda preocupacin respecto al ciclo de desarrollo de sistemas, es que los requerimientos del usuario se van modificando a lo largo del tiempo. Los requerimientos del usuario evolucionan desde el momento en que se realiza el anlisis de las necesidades del usuario hasta el momento en que se concluye y se entrega el sistema. Esta claro que tales preocupaciones se encuentran relacionadas, pues ambas se basan en el tiempo que se requiere para concluir el SDLC y en el problema que implica alejarse de las necesidades del usuario, durante las etapas subsecuentes del desarrollo. Si un sistema se desarrolla de manera aislada de los usuarios (despus de haber concludo los anlisis iniciales de requerimientos), puede no satisfacer sus expectativas. Como corolario al problema de distanciarse de los requerimientos evolutivos de informacin del usuario, se tiene que algunos usuarios no saben en realidad lo que quieren, sino hasta que ven algo tangible. Con frecuencia, en un SDLC tradicional es demasiado tarde para modificar un sistema no deseado, una vez que se ha entregado.

173

Con el fin de resolver estos inconvenientes , algunos analistas proponenque el desarrollo de prototipos sea una alternativa al SDLC. Cuando los prototipos se desarrollan de esta manera, el analista reduce efectivamente el periodo que transcurre entre la indagacin de los requerimientos de informacin y la entrega de un sistema funcional. Adems al disear prototipos, en lugar de apegarse al ciclo formal de desarrollo, pueden evitarse ciertos problemas concernientes a la identificacin precisa de los requerimientos de informacin del usuario. Con un prototipo, el usuario puede ver en realidad lo que llegar a ser posible; y as mismo, cmo se traducen sus necesidades en hardware y software. Pueden utilizarse cualquiera de los cuatro tipos de modelos para el desarrollo de prototipos. Entre los inconvenientes que implica suplantar el SDLC con el desarrollo de prototipos se tiene que el sistema de informacin puede conformarse de manera prematura, aun antes de entender cabalmente el problema o la oportunidad que se aborda. El uso de prototipos como alternativa puede inducir que ciertos grupos de usuarios lo acepten, a pesar de ser inadecuado para las necesidades globales del sistema.

1 Identificacin de problemas, oportunidades y objetivos

2 Determinacin de los requerimientos de informacin Lmites con mayor rigidez 3 Anlisis de las necesidades de sistemas

Tiempo requerido para l

4 Diseo del sistema recomendado

Menor participacin del usuario

5 Desarrollo y documentacin del software

El sistema tangible aparece al final

6 Prueba y mantenimiento del sistema

7 Implantacin y evaluacin del sistema

La evaluacin ocurre al final

Figura 5.33.- Enfoque tradicional del ciclo de vida del desarrollo de sistemas en ocasiones llega a tener desventajas.

174

DESARROLLO DE PROTOTIPOS Para decididr si el prototipo debe incluirse o no en el ciclo de desarrollo de sistema, el analista debe considerar qu tipo de problema va a solucionarse y analizar de qu manera un sistema ofrecera una solucin. En la figura 5.34 se presentan diferentes tipos de sistemas y la posibilidad de que el prototipo se considere durante sus desarrollos. Un programa de nmina, tal cual o un sistema de inventarios, los cuales resuelven problemas muy estructurados, desde un punto de vista tradicional, no seran buenos candidatos para incluir prototipos durante su desarrollo. Esto es debido a que las salidas de estos sistemas son predecibles y se encuentran bien definidas.

Poco propio para prototipos Muchas veces anteriores Conocido y estable Estructurada Experiencia en diseo similares

Muy conveniente para prototipos Solo unas cuantas anteriores Incierto e inestable Poco estructurada o semiestructurada

Medio ambiente

Toma de decisiones

Figura 5.34.- Factores determinan si un sistema es ms o menos conveniente para desarrollarse a partir de prototipos.

Ms bien, se tiene que considererar aquellos problemas novedosos y complejos, y asimismo soluciones novedosas y complejas. Un sistema que se oriente a problemas poco o nada estructurados, sera adecuado para desarrollarse a partir de un prototipo. El analista de sistemas debe evaluar tambin el contexto del sistema para decidir si usa prototipos. Si el sistema existir durante largo tiempo en un ambiente estable, quizs sera innecesario el uso de prototipos. Sin embargo, si el ambiente para el sistema es sumamente variable, debe considerarse con seriedad el uso de prototipos. Un prototipo es evolutivo por naturaleza, y en consecuencia, estar sujeto a numerosas revisiones. El sistema prototipo es slo una parte del sistema que eventualmente instalar. No es un sistema completo, ya que al desarrollarlo con rapidez, puede quedar limitado, contando con slo ciertas funciones elementales. Sin embargo, es importante imaginar y luego construir el prototipo, como parte de un sistema actual, con el cual interectuar el usuario. Debe incorporar suficientes funciones representativas para que el usuario acepte que interacta con un sistema real. El uso de prototipos permite reducir retroalimentacin sobre el sistema propuesto, y adems qu tan bien satisface las necesidades de informacin del usuario. Uno de los primeros pasos en el desarrollo de un prototipo es la estimacin de los costos involucrados para su construccin, cronsiderndolo como uno de los mdulos del sistema. Si tanto el costo del tiempo de los programadores y de los analistas, como el costo del equipo se encuentran dentro del monto presupuestado, entonces debe procederse al desarrollo del prototipo. Los prototipos son un excelente instrumento para integrar el sistema de informacin dentro del gran sistema de la organizacin.

175

Lineamientos para el desarrollo de prototipos Una vez que se ha tomado la decisin, deben observarse cuatro lineamientos bsicos al integrar el prototipo al SDLC, dentro de la etapa de determinacin de requerimientos. Tal y como se plantea en la figura 5.35. Como se puede ver, estos lineamientos sugieren la manera de proceder con el prototipo y que necesariamente se encuentran relacionados.

PRINCIPALES LINEAMIENTOS PARA EL DESARROLLO DE PROTOTIPOS

Trabajar con mdulos manejables

Construir el prototipo con rapidez

Modificar el prototipo una vez revisado por los usuarios

Enfatizar la interfaz con el usuario

Figura 5.35.- Lineamientos principales para el desarrollo de prototipos.

Trabajar con mdulos manipulables.- Cuando desarrolle el prototipo de ciertas caractersticas del sistema dentro de un modelo funcional, es imperativo que los mdulos sean manipulables. Una ventaja distintiva de los prototipos es que no necesariamente se construye un sistema funcional entero como prototipo. Se expuso un ejemplo de mdulos manipulables en secciones anteriores, recuerde que un mdulo manipulable es aqul que nos permite relacionarnos con sus caractersticas, y adems su construccin es independiente de otros mdulos del sistema. Aquellas caractersticas que se consideren poco importantes quedarn fuera del prototipo. Construir el prototipo con rapidez.- La esencia del desarrollo del prototipo de un sistema de informacin con xito es la rapidez de su realizacin. Se recuerda que los inconvenientes planteados comnmente hacia el SLDC, es que el intervalo que transcurre entre el planteamiento de los requerimientos y la entrega del sistema completo es tan largo, que no llega a satisfacer de manera efectiva las necesidades evolutivas del usuario. Una vez realizado un breve anlisis sobre los requerimientos de informacin por mtodos tradicionales, tales como la entrevista, la observacin, y la investigacin de datos de archivo, se construyen los mdulos funcionales de prototipos. El prototipo debe estructurarse en menos de una semana, de preferencia y si es posible en dos o tres das. Recuerde que con el fin de construir un prototipo as de rpido, usted debe contar con instrumentos especiales, tales como un sistema administrador de bases de datos, y aquel software que le permita generalizar las entradas y las salidas, los sistemas interactivos, etc.

176

Conviene enfatizar que en esta etapa del ciclo de desarrollo, el analista se encuentra todava recopilando informacin acerca de lo que necesitan y desean los usuarios del sistema de informacin. El prototipo se vuelve una extensin valiosa de la forma tradicional de determinar los requerimientos. Por medio del prototipo, el analista establece una retroalimentacin conel usuario, con el fin de obtener una mejor visin de las necesidades de informacin. Al desarrollar el prototipocon rapidez, en el inicio del ciclo de desarrollo de sistemas, el analista contar con una excelente visin sobre la manera en que deber desarrollar el resto del proyecto. Al mostrar a los usuarios, desde un principio, la operacin de los elementos del sistema, mediante un desarrollo rpido del prototipo, puede evitar la asignacin de recursos a un proyecto, que eventualmente, podra descartarse.

Modificaciones en el prototipo.- El prototipo requiere contar con mdulos que tengan entre s una baja dependencia. Al observar este lineamiento, ser ms fcil modificar el prototipo, si llegara a ser necesario. Se modifica en repetidas ocasiones por medio de varias interacciones. Tales cambios deben acercar el prototipo al sistema que el usuario considera como relevante. Cada modificacin requiere de una nueva evaluacin por parte de los usuarios. As como ocurri con el desarrollo inicial, las modificaciones al prototipo deben realizarse de inmediato, comnmente en uno o dos das, con el fin de conservar el objeto del proyecto. Sin embargo, la programacin exacta de las modificaciones depender de la dedicacin de los usuarios para interactuar con el prototipo modificado. El analista de sistemas debe motivar al usuario para que realice su parte, y que consiste en evaluar con rapidez tales cambios. El prototipo no es un sistema concluido. Entrar en la fase de dearrollo de prototipos, con la idea de que el prototipo requerir modificaciones, es una actitud sana. Tambin indica al usuario que ser necesaria su retroalimentacin si desea que mejore el sistema. Enfatizar la interfaz con el usuario.- La interfaz del usuario con el prototipo, y eventualmente con el sistema final es fundamental. Puesto que lo que se trata de obtener en realidad, es que los usuarios planteen ms all sus requerimientos de informacin. Y para ello deben ser capaces de interactuar, sin complicaciones con el prototipo del sistema. Para muchos usuarios la interfaz, se contempla como el sistema y no debera ser un obstculo. Por ejemplo, en esa etapa, la meta del analista es disear una interfaz tal, que permita la usuario interactuar con el mnimo de adiestramiento, y adems contar con el mximo control sobre las funciones presentadas. Aunque muchos aspectos del sistema permanecen sin desarrollo en el prototipo, la interfaz con el usuario debe quedar muy bien desarrollada para que el usuario se involucre en el sistema con rapidez y no se desaliente. Los sistemas interactivos en lnea, que cuentan con salidas en pantalla, son ideales como prototipos. Durante el desarrollo del prototipo debe hacerse a un lado el embrollo de las interfaces, o simplemente ignorarlo. Sin embargo, si la interfaz del prototipo no es lo que los usuarios requiren o buscan, o si los analistas de sistemas se percatan de que no hay un acceso adecuado al sistema, en ambos casos debe modificarse.

Desventajas de los prototipos La administracin del proyecto. Aunque varias interacciones del prototipo pueden ser necesarias, la extensin indefinida de su uso, tambin crear problemas. Es importante que el grupo de anlisis de sistemas imagine y cuente con un plan que le indique la manera como la retroalimentacin al prototipo se registrar, analizar e interpretar. Establezca periodos especficos durante los cuales usted y los tomadores de la decisin de la gerencia harn uso de la retroalimentacin para evaluar el buen desempeo del prototipo. Aunque el prototipo es valioso por su naturaleza evolutiva, el analista no debe permitir que el prototipo sustituya a las otras etapas del ciclo de desarrollo de sistemas.

177

Adopcin de un sistema incompleto como completo. Otra desventaja es que si un sistema se requiere de manera urgente, el prototipo puede llegar a aceptarse a pesar de encontrarse incompleto y ponerse en servicio sin el refinamiento necesario. Los usuarios pueden llegar a crear patrones de relacin con el sistema prototipoque no son compatibles con lo que ocurrira con un sistema completo. Adems, un prototipo puede no realizar todas las funciones requeridas. Eventualmente, cuando emerjan las deficiencias, el prototipo se menospreciar, si fue adoptado equvocamente en la empresa como un sistema completo. Ventajas del uso de prototipos Modificacin del sistema en etapas tempranas de su desarrollo. El xito del uso de los prototipos depende de qu tan pronto y con qu frecuencia se reciba la retroalimentacin del usuario para hacer cambios y adecuarlos a las necesidades actuales. Aunque el desarrollo de prototipos implica una inversin en tiempo y en dinero, siempre ser considerablemente menor a la de u sistema completo. De manera simultnea, los problemas de sistemas y los descuidos son ms fciles de detectar en un prototipo con caractersticas e interfaces limitadas que en un sistema complejo. Eliminacin de sistemas indeseables. Otra ventaja de los prototipos como elemento de recopilacin de informacin es la posibilidad de eliminar un sistema que no lleg a ser lo que esperaban de l los usuarios y los analistas. Una vez ms, la inversin de tiempo y de dinero destacar. Sin embargo, un prototipo representa una menor inversin que aquel sistema completamente desarrollado. Un sistema prototipo se eliminar cuando sea aparente que el sistema ya no es til o que no satisface los requerimientos de informacin que se establecieron. Diseo de un sistema acorde a las necesidades y expectativas de los usuarios Los sistemas en desarrollo se ajustarn mejor a las necesidades de los usuarios, los estudios de sistemas de informacin que fracasaron revelan la existencia de un gran intervalo de tiempo transcurrido entre el establecimiento de los requerimientos y las presentaciones del sistema concluido. La mejor prctica es interactuar con los usuarios a todo lo largo del SDLC, los usuarios, que desde un inicio hacen suyo un sistema de informacin, sern los principales promotores de su xito. Cuando la evaluacin del prototipo indica que el sistema va sobre ruedas, dentro los lineamientos que se establecieron, la decisicn debe ser mantener la operacin del prototipo y continuar expandindolo, hasta incluir las otras funciones que fueron planificadas. Esto es lo que se considera como un prototipo funcional. Se tomar la decisin de mantener su operacin como si el prototipo se encontrara dentro del presupuesto establecido para la programacin y el anlisis de sistemas. Con ello, los usuarios apreciarn el sistema e ir acorde a los requerimientos de informacin y objetivos que se establecieron. Una lista comparativa de las ventajas y desventajas de desarrollo de prototipos se da en la figura 5.36.
Desventajas de prototipos Ventajas de prototipos

1.- Dificultad para manejar el prototipo como un proyecto dentro de un gran esfuerzo de sistemas. 2.- Los usuarios y el analista pueden adoptar al prototipo como un sistema completo, an cuando es inadecuado.

1.- Es posible modificar el sistema al inicio de su desarrollo.

2.- Es posible detener a tiempo el desarrollo de un sistema que no sirve. 3.- pueden atender con mayor precisin las necesidades del usuario.

Figura 5.36.- Desventajas y ventajas del desarrollo de prototipos.

178

EJERCICIOS UNIDAD V

1. 2. 3. 4. 5. 6. 7. 8. 9.

Explique brevemente la realizacin de la entrevista Liste cuatro situaciones que hagan adecuado el uso de cuestionarios. Cmo debe ser la seleccin de quien recibir el cuestionario? Defina lo que significa muestreo Liste tres razones sobre el porqu la observacin es til para el analista de sistemas en la organizacin Explique brevemente la fase de muestreo. Qu tipos de informacin deben ser buscados en las entrevistas? Explique lineamientos principales para el desarrollo de prototipos. Para las siguientes situaciones, diga qu tcnica de recoleccin de datos se debe emplear. Justifique su respuesta.

SITUACIONES A INVESTIGAR Determinar las condiciones de iluminacin de la reas del Decanato de Medicina. Indaga la opinin de los usuarios del ambulatorio Simn Bolivar, sobre el cobro de la atencin medica. Verificar las zonas de riesgo de derrumbes en la ciudad Determinar el grado de conocimiento sobre SIDA en los alumnos de la Universidad

TCNICAS DE RECOLECCIN DE DATOS QUE SE DEBE EMPLEAR

10. Mencione dos ventajas y dos limitaciones de la tcnica de entrevista.

179

DISEO Y ARQUITECTURA DE PRODUCTOS DE SOFTWARE

6.1 DESCOMPOSICIN MODULAR

6.2 ARQUITECTURAS DE DOMINIO ESPECFICO 6.2.1 DISEO DE SOFTWARE ARQUITECTURA MULTIPROCESADOR 6.2.2 DISEO DE SOFTWARE ARQUITECTURA CLIENTE SERVIDOR

6.2.3 DISEO DE SOFTWARE DISTRIBUIDO 6.2.4 DISEO DE SOFTWARE DE TIEMPO

180

6.1. DESCOMPOSICIN MODULAR

Consiste en descomponer el problema a resolver en mdulos o tareas ms simples. Cada tarea representa una actividad completa y se codifica de manera independiente. Facilita el diseo descendente del problema, centrndonos cada vez en la resolucin de subproblemas de magnitud inferior. A la resolucin de cada uno de estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los mdulos pueden ser planificados, codificados, comprobados y depurados independientemente, y a continuacin se combinan uno a uno con otros mdulos. Estos diseos ayudan a crear arquitecturas para nuestro software ms reutilizables y extensibles. Muchos de los lenguajes de programacin existentes y de las tcnicas arquitectnicas subyacentes a los mismos implementan de una manera u otra algn tipo de tcnica que favorezca la descomposicin modular, por ejemplo, en los lenguajes estructurados podemos encontrar el concepto de subrutina, mientras que en los lenguajes orientados a objetos podemos encontrar el concepto o la nocin de clase. Tanto el paradigma estructurado como el orientado a objetos soportan algn mtodo o tcnica que nos permite descomponer un gran problema de software en otros menos complejos, la gran diferencia entre estos paradigmas reside en los criterios que siguen cada uno de ellos para decidir que debera ser un subproblema y que no debera serlo. Una tcnica arquitectnica de software que basa la descomposicin de un determinado problema en otros menos complejos basndose en las funciones, acciones o las tareas que lleva a cabo el sistema recibe el nombre de estructurado o funcional, al contrario, una tcnica arquitectnica que descompone un problema en otros subproblemas menos complejos basndose en los tipos de objetos que manipula es lo que se conoce por orientacin a objetos. La forma en la que los diferentes tipos de arquitectura descomponen los problemas y encuentran sus mdulos es una discusin lo suficientemente amplia y trascendental (es el origen de la orientacin a objetos) que puede ser tratada en otros textos. Considrese dos problemas, p1 y p2. Si la complejidad observada para p1 es mayor que la de p2 se deduce que el esfuerzo requerido para resolver p 1 es mayor que el esfuerzo necesario para resolver p2. Como un casi general, este resultado es obvio en el sentido intuitivo; la resolucin de un problema difcil toma ms tiempo. Tambin se deduce que la complejidad observada de dos problemas, cuando estn combinados, con frecuencia es mayor que la suma de las complejidades observadas cuando cada una de ellas se toma por separado: esto conduce a una estrategia de divide y vencers (es ms fcil resolver un problema complejo cuando ste se divide en piezas ms manejables). Es posible que si el software se subdivide en forma indefinida, el esfuerzo requerido para desarrollo se reducir en forma sensible. Por desgracia, hay otras fuerzas que entran en juego, lo que ocasiona que esta conclusin sea invlida. En relacin con la figura 6.1, el esfuerzo (costo) para desarrollar un solo modulo se software decrece conforme se incrementa el nmero de mdulos. Si se tiene el mismo conjunto de requisitos, ms mdulos significan un tamao individual menor. Sin embargo, a medida que crece el nmero de mdulos, el esfuerzo (costo) asociado con la integracin de los mdulos tambin crece. Estas caractersticas conducen tambin a la curva total de costo o el esfuerzo que se muestra en la figura.

181

Costo total del software Costo por integrar Regin de costo mnimo M

Costo o esfuerzo

Costo /mdulo Nmero de Mdulos

Figura 6.1.- Modularidad y costo del software.

Los pasos a seguir para realizar la descomposicin modular son los siguientes y se muestra en la figura 6.2: 1. Identificar los mdulos. 2. Describir cada mdulo. 3. Describir las relaciones entre mdulos.

PROGRAMA PRINCIPAL

Mdulo 2 Mdulo 1

Mdulo 11

Mdulo 21

Mdulo 22

Mdulo 23

Mdulo 111

Mdulo 112

Mdulo 221

Figura 6.2.-Arquitectura de la descomposicin modular.

182

Tipos de mdulos: Cdigo fuente, en el lenguaje de programacin usado. Tabla de datos, para datos de inicializacin u otros. Configuracin, se agrupa en un mdulo toda la informacin de configuracin en el entorno de trabajo. Otros: archivos de ayuda en lnea, manuales, etc. Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficientemente vlida.

1. Independencia Funcional. a. Requisitos/componentes. En un principio, cada funcin ser realizada en un mdulo distinto. Si las funciones son independientes los mdulos tendrn independencia funcional. b. Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre mdulos al mnimo. c. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin. 2. Acoplamiento.- Mide la interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de la interface: a. FUERTE: i. POR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro. ii. COMN, se emplea en una zona comn de datos a la que tienen acceso varios mdulos. b. MODERADO: i.DE CONTROL, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto implica que un cambio en el formato de datos afecta a todos estos mdulos. ii.POR ETIQUETA, el intercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, rbol, grafo...). c. DBIL: i.DE DATOS, viene dado por los datos que intercambian los mdulos, es el mejor posible. ii.SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

3. Cohesin.- Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el nmero de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y relacionados en un mismo mdulo. a. ALTA: i.COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de objetos. ii.COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica. b. MEDIA: i.COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma secuencial. ii.COHESIN DE COMUNICACIN, elementos que operan con el mismo conjunto de datos de entrada o de salida. iii.COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivo.

183

6.2. ARQUITECTURA DE DOMINIO ESPECIFICO

Qu se entiende por diseo arquitectnico? Comprende el establecicmiento de un marco de trabajo estructural bsico para un sistema. Alude a la estructura general del software y el modo en que la estructura ofrece una integridad conceptual al sistema. De modo simple, se puede considerar que est compuesta por la estructura jerrquica de los componentes (mdulos), la manera en la que dichos componentes interactan y la estructura de datos que es utilizada por dichos componentes.

Arquitecturas de Dominio Especfico Son arquitecturas diseadas para cubrir un sistema o una familia de sistemas pero muy centradas en un rea o dominio determinado y enfocadas a la reutilizacin. Pasos para su construccin (segn W. Tracz, 1991):

1. Definicin del dominio. 2. Definicin de requisitos y conceptos del dominio especfico. 3. Definicin de restricciones de implementacin del dominio. 4. Desarrollo de modelos y arquitecturas del dominio. 5. Generacin de productos reutilizables.

Megaprogramacin DSSA Ingeneria del Dominio Tecnologa OO (frameworks)

Figura 6.3.- Arquitecturas de Dominio especfico (DSSA).

Dos tipos de modelos de dominio especfico: Modelos genricos los cuales son abstracciones de un nmero de sistemas reales y que encapsulan las caractersticas principales de estos sistemas. Son usualmente modelos bottomup; los modelos de referencia son modelos top-down. El modelo de un compilador es un ejemplo bien conocido, sin embargo existen otros modelos en dominios de aplicacin ms especializados:

184

 Analizador lxico Tabla de smbolos Analizador sintctico rbol de sintaxis Analizador semntico Generador de cdigo El modelo genrico de compilador podra ser organizado de acuerdo a diferentes modelos arquitectnicos.

Tabla de simbolo

Anlisis Lexicos

Anlisis Sintctico

Anlisis Semntico

Generacin de Cdigo

Figura 6.4.- Modelo de Compilador.

Modelos de referencia los cuales son ms abstractos. Modelos idealizados. Proveen un medio de informacin acerca de cierta clase de sistemas y permiten comparar diversas arquitecturas. Se derivan a partir de un estudio del dominio de la aplicacin antes que a partir de sistemas existentes. Pueden ser usados como una base para la implementacin del sistema o para comparar diferentes sistemas. Actan como un estndar para evaluar sistemas.

7 6 5 4 3 2 1 Application Presentation Session Network Data link Physical Network Data link Physical Communications medium

Application Presentation Session Transporte Network Data link Physacal

Figura 6.5.- El modelo OSI es un modelo en capas para sistemas de comunicacin.

185

6.2.1. DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razn es porque actualmente la mayora de las CPUs slo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten de forma simultnea varios procesos es tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido. La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta operacin consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada. Un ejemplo de este tipo de sistema es un sistema de control de trfico areo. Un conjunto de sensores distribuidos recolecta la informacin del flujo de trfico y la procesa localmente antes de enviarla al cuarto de control. Los sistemas de software compuestos de procesos mltiples no necesariamente son sistemas distribuidos. Si ms de un procesador est disponible, entonces se puede implementar la distribucin, pero los diseadores del sistema no siempre consideran lo puntos de distribucin durante el proceso de diseo. El enfoque de diseo para este tipo de sistemas es esencialmente el mismo que para los de tiempo real. Ventajas Es econmica. El uso de componentes comnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento Desventajas En ocasiones se menciona tambin la limitante fsica; existen factores que limitan la velocidad mxima de un procesador, independientemente del factor econmico. Barreras fsicas infranqueables, tales como la velocidad de la luz, efectos cunticos al reducir el tamao de los elementos de los procesadores, y problemas causados por fenmenos elctricos a pequeas escalas Los ordenadores multiprocesador presentan problemas de diseo, derivados del hecho de que 2 programas se ejecuten simultneamente y potencialmente pueden interferirse entre s. Por ello existen dos arquitecturas que resuelven dichos problemas. Arquitectura SMP (Uma) .- Los multiprocesadores simtricos (Symmetric Multiprocessor) son ordenadores con arquitectura de memoria compartida que presentan en la memoria principal un acceso simtrico desde cualquier procesador, es decir, el retardo en el acceso a cualquier posicin de memoria es el mismo con independencia del procesador desde el que se realice la operacin o tarea, dicha arquitectura es denominada como Acceso Uniforme a Memoria (UMA) y se lleva a cabo con una memoria compartida pero centralizada. Estos multiprocesadores dominan el volumen como el capital invertido. Esta arquitectura a su vez se encuentra dividida en: SMP con bus. SMP escalable.

186

Procesador

Procesador

Procesador

Procesador

One or more levels of cache

One or more levels of cache

One or more levels of cache

One or more levels of cache

Main memory

I/O System

Figura 6.6.- Arquitectura del diseo de software Multiproceso.

Arquitectura DSM (Numa).- La memoria compartida distribuida o DSM es una abstraccin que se propone como alternativa a la comunicacin por mensajes. Los multiprocesadores de memoria compartida y distribuida (DSM o Distributed Shared Memory), son ordenadores MIMID, en los cuales la memoria est distribuida entre los nodos. Tomando en cuenta que el espacio de direccionamiento es global, el acceso a memoria principal es asimtrico. Esta arquitectura de memoria que se genera en retardo de acceso dependiente tanto la posicin de memoria como el procesador se denomina Acceso No Uniforme a Memoria (NUMA), hace su aparicin cuando la memoria compartida est distribuida entre los nodos. De esta manera, se mejora el retardo medio de acceso a memoria, ya que en cada ordenador los accesos a posiciones de su memoria local presentan un retardo sensiblemente inferior al caso en que es accedido a posiciones de memoria en otros ordenadores. Esta clase de ordenadores con arquitectura NUMA presenta escalabilidad. Propone un espacio de direcciones de memoria virtual que integre la memoria de todas las computadoras del sistema, y su uso mediante paginacin. Las pginas quedan restringidas a estar necesariamente en un nico ordenador. Cuando un programa intenta acceder a una posicin virtual de memoria, se comprueba si esa pgina se encuentra de forma local. Si no se encuentra, se provoca un fallo de pgina, y el sistema operativo solicita la pgina al resto de computadoras. El sistema funciona de forma anloga al sistema de memoria virtual tradicional, pero en este caso los fallos de pgina se propagan al resto de ordenadores, hasta que la peticin llega al ordenador que tiene la pgina virtual solicitada en su memoria local. A primera vista este sistema parece ms eficiente que el acceso a la memoria virtual en disco, pero en la realidad ha mostrado ser un sistema demasiado lento en ciertas aplicaciones, ya que provoca un trfico de pginas excesivo. De la misma manera que la arquitectura SMA se divide en: ccNUMA docNUMA COMA SVM Ventajas Es econmica. El uso de componentes comnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento, a un precio menor que el de mquinas con procesadores especialmente diseados (como por ejemplo las mquinas de procesadores vectoriales y de propsito especfico). Adicionalmente, las computadoras paralelas son inherentemente escalables, permitiendo actualizarlas para adecuarlas a una necesidad creciente.

187

 Las arquitecturas tradicionales se actualizan haciendo los procesadores existentes obsoletos por la introduccin de nueva tecnologa a un costo posiblemente elevado. Por otro lado, una arquitectura paralela se puede actualizar en trminos de rendimiento simplemente agregando ms procesadores.

Desventajas En ocasiones se menciona tambin la limitante fsica; existen factores que limitan la velocidad mxima de un procesador, independientemente del factor econmico. Barreras fsicas infranqueables, tales como la velocidad de la luz, efectos cunticos al reducir el tamao de los elementos de los procesadores, y problemas causados por fenmenos elctricos a pequeas escalas, restringen la capacidad mxima de un sistema uniprocesador, dejando la opcin obvia de colocar muchos procesadores para realizar clculos cooperativamente.

6.2.2. DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE/SERVIDOR

Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el procesamiento se distribuye lo largo de varios procesadores. La arquitectura cliente-servidor es una forma de dividir las responsabilidades de un sistema de informacin separando la interfaz de usuario (Nivel de presentacin) de la gestin de la informacin (Nivel de gestin de datos). El funcionamiento bsico de este modelo consiste en que un programa cliente realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es ms ventajosa en un sistema multiusuario distribuido a travs de una red de computadoras. Sustituye a la arquitectura monoltica en la que no hay distribucin, tanto a nivel fsico como a nivel lgico. Caractersticas de un cliente en la arquitectura C/S el remitente de una solicitud es conocido como cliente, y caractersticas son: Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicacin (dispositivo maestro o amo). Espera y recibe las respuestas del servidor. Por lo general, puede conectase a varios servidores a la vez. Normalmente interacta directamente con los usuarios finales mediante una interfaz grfica de usuario. Caractersticas de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus caractersticas son: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean entonces un papel pasivo en la comunicacin (dispositivo esclavo). Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al cliente. Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos casos el nmero mximo de peticiones puede estar limitado). No es frecuente que interacten directamente con los usuarios finales.

188

CLIENTE 1

SERVIDOR X

CLIENTE i

SERVIDOR Y

CLIENTE m

CLIENTE n...

Figura 6.7.- Arquitectura Cliente/ Servidor.

VENTAJAS Centralizacin del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda daar el sistema. Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Se reduce el trfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstraccin como por ejemplo SQL.

Las siguientes definiciones son las que se utilizan comnmente en el diseo y arquitectura. Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes.

189

Jerarqua o herencia. Es el orden de las abstracciones organizado por niveles. Tipificacin. Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia. Es la propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia. Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto contina existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado). Este software tendr la funcin principal de construir un conjunto de paquetes IP en el cliente, y transmitirlos hacia el servidor, el cual deber consultar parte del contenido de este paquete y establecer una serie de medidas tiles para el estudio de cada escenario. Una serie de libreras que incluyen funciones para gestionar los sockets raw que se utilizan. Una librera que permite la creacin de paquetes IP con el formato requerido por las polticas. Un conjunto de funciones para obtener la hora actual en los formatos apropiados. Un programa cliente que construir los paquetes IP y los enviar a otro nodo de la red (el servidor). Un programa servidor que recibir los paquetes enviados por el cliente y realizar una serie de medidas estadsticas.

70.1 70.2

80.2

80.1

1 7
60.1 10.2

60.2

6 2

10.1

50.1

20.2

5
50.2

3 4

20.1

40.1 40.2 30.1

30.2

6.8.- Creacin de un software de arquitectura cliente/servidor.

190

Las tres libreras que componen este software ofrecen las funciones necesarias para gestionar los sockets utilizados, para calcular los sellos de tiempo, y para construir un paquete IP. Librera de gestin de sockets Esta librera, basndose en los sockets de Linux deber ofrecer funciones para abrir, cerrar y atarse a un socket, adems de enviar y recibir un paquete. Librera de tiempo Esta librera contendr funciones que permitirn ofrecer el tiempo desde la media noche con dos precisiones distintas. Por un lado en formato segundos/microsegundos, por otro simplemente en milisegundos. Librera de construccin de paquetes Esta librera especificar una estructura que mantenga los campos estndar de una cabecera IP pero que, adems, aada una serie de campos en las opciones que nos permita establecer un sello de tiempos apropiado. La librera soporta dos formatos: uno que utiliza una opcin de 32 bits estandarizada en IP y que mide el tiempo en milisegundos desde la media noche, otro no estndar que utiliza 64 bytes para representar ese mismo tiempo en formato segundos/microsegundos.

6.2.3. DISEO DE SOFTWARE DISTRIBUIDO

Para esta arquitectura no hay distincin entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos servicios. Es una coleccin de computadoras autnomas conectadas por una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una nica entidad capaz de proporcionar facilidades de computacin El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de alta velocidad a principios de 1970. Ms recientemente, la disponibilidad de computadoras personales de altas prestaciones, estaciones de trabajo y ordenadores servidores ha resultado en un mayor desplazamiento hacia los sistemas distribuidos en detrimento de los ordenadores centralizados multiusuario. Esta tendencia se ha acelerado por el desarrollo de software para sistemas distribuidos, diseado para soportar el desarrollo de aplicaciones distribuidas. Este software permite a los ordenadores coordinar sus actividades y compartir los recursos del sistema: hardware, software y datos. Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas estaciones de trabajo conectadas por una red de rea local, hasta Internet, una coleccin de redes de rea local y de rea extensa interconectadas, que enlazan millones de ordenadores. Las aplicaciones de los sistemas distribuidos varan desde la provisin de capacidad de cmputo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prcticamente todas las aplicaciones comerciales y tcnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la informacin que el sistema mantiene. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de respuesta, proveer puntos de acceso al servicio que estn distribuidos geogrficamente, potencial para el crecimiento del sistema para acomodar la expansin del negocio y un marco para la integracin de sistema usados por diferentes compaas y organizaciones de usuarios.

191

PC
Pantalla

Escaner

Mac

Servidor RED PC portatil

Multifuncional Impresora

Monitor LDC

Conmutador

Modem

PC Portatil PC
Figura 6.9.- Arquitectura de software distribuido.

Caractersticas Colouris, establece que son seis las caractersticas principales responsables de la utilidad de los sistemas distribuidos. Se trata de:

1).- Comparticin de Recursos El trmino 'recurso' es bastante abstracto, pero es el que mejor caracteriza el abanico de entidades que pueden compartirse en un sistema distribuido. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros, ventanas, bases de datos y otros objetos de datos. La idea de comparticin de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clsicos desde siempre han provisto comparticin de recursos entre sus usuarios. Sin embargo, los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o computadoras personales dentro de un sistema distribuido no obtienen automticamente los beneficios de la comparticin de recursos. Los recursos en un sistema distribuido estn fsicamente encapsulados en una de las computadoras y slo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la comparticin de recursos sea efectiva, sta debe ser manejada por un programa que ofrezca un interfaz de comunicacin permitiendo que el recurso sea accedido,

192

manipulado y actualizado de una manera fiable y consistente. Surge el trmino genrico de gestor de recursos. Un gestor de recursos es un mdulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas polticas y mtodos especficos junto con requisitos comunes para todos ellos. stos incluyen la provisin de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localizacin; la traslacin de nombre de recurso a direcciones de comunicacin y la coordinacin de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia. Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos.

2).- Apertura (openness) Un sistema informtico es abierto si el sistema puede ser extendido de diversas maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (aadir perifricos, memoria o interfaces de comunicacin, etc.) o con respecto a las extensiones software (aadir caractersticas al sistema operativo, protocolos de comunicacin y servicios de comparticin de recursos, etc.). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el que nuevos servicios de comparticin de recursos se pueden aadir sin perjudicar ni duplicar a los ya existentes. Bsicamente los sistemas distribuidos cumplen una serie de caractersticas: Los interfaces de software clave del sistema estn claramente especificados y se ponen a disposicin de los desarrolladores. En una palabra, las interfaces se hacen pblicos. Los sistemas distribuidos abiertos se basan en la provisin de un mecanismo uniforme de comunicacin entre procesos e interfaces publicados para acceder a recursos compartidos. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogneo, posiblemente proveniente de vendedores diferentes. Pero la conformidad de cada componente con el estndar publicado debe ser cuidadosamente comprobada y certificada si se quiere evitar tener problemas de integracin.

3).- Concurrencia Cuando existen varios procesos en una nica mquina decimos que se estn ejecutando concurrentemente. Si el ordenador est equipado con un nico procesador central, la concurrencia tiene lugar entrelazando la ejecucin de los distintos procesos. Si la computadora tiene N procesadores, entonces se pueden estar ejecutando estrictamente a la vez hasta N procesos. En los sistemas distribuidos hay muchas mquinas, cada una con uno o ms procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutndose en paralelo. En un sistema distribuido que est basado en el modelo de comparticin de recursos, la posibilidad de ejecucin paralela ocurre por dos razones: Muchos usuarios interactan simultneamente con programas de aplicacin.

193

Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a diferentes peticiones de los procesos clientes. El caso (1) es menos conflictivo, ya que normalmente las aplicaciones de interaccin se ejecutan aisladamente en la estacin de trabajo del usuario y no entran en conflicto con las aplicaciones ejecutadas en las estaciones de trabajo de otros usuarios. El caso (2) surge debido a la existencia de uno o ms procesos servidores para cada tipo de recurso. Estos procesos se ejecutan en distintas mquinas, de manera que se estn ejecutando en paralelo diversos servidores, junto con diversos programas de aplicacin. Las peticiones para acceder a los recursos de un servidor dado pueden ser encoladas en el servidor y ser procesadas secuencialmente o bien pueden ser procesadas varias concurrentemente por mltiples instancias del proceso gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para asegurarse de que no existen conflictos. La sincronizacin debe ser cuidadosamente planeada para asegurar que no se pierden los beneficios de la concurrencia. 4).- Escalabilidad Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala ms pequea consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un sistema distribuido construido alrededor de una red de rea local simple podra contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresin y otros servidores de propsito especfico. A menudo se conectan varias redes de rea local para formar internetworks, y stas podran contener muchos miles de ordenadores que forman un nico sistema distribuido, permitiendo que los recursos sean compartidos entre todos ellos. Tanto el software de sistema como el de aplicacin no deberan cambiar cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware, sino que est ntimamente ligada con todos los aspectos del diseo de los sistemas distribuidos. El diseo del sistema debe reconocer explcitamente la necesidad de escalabilidad o de lo contrario aparecern serias limitaciones. La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofa de diseo en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debera ser posible extender el sistema para darle servicio. Por ejemplo, la frecuencia con la que se accede a los ficheros crece cuando se incrementa el nmero de usuarios y estaciones de trabajo en un sistema distribuido. Entonces, debe ser posible aadir ordenadores servidores para evitar el cuello de botella que se producira si un solo servidor de ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. En este caso el sistema deber estar diseado de manera que permita trabajar con ficheros replicados en distintos servidores, con las consideraciones de consistencias que ello conlleva. Cuando el tamao y complejidad de las redes de ordenadores crece, es un objetivo primordial disear software de sistema distribuido que seguir siendo eficiente y til con esas nuevas configuraciones de la red. Resumiendo, el trabajo necesario para procesar una peticin simple para acceder a un recurso compartido debera ser prcticamente independiente del tamao de la red. Las tcnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la tcnica asociada de caching, y el uso de mltiples servidores para manejar ciertas tareas, aprovechando la concurrencia para permitir una mayor productividad. Una explicacin completa de estas tcnicas puede encontrarse en [Colouris 1994].

194

5).- Tolerancia a Fallos Los sistemas informticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podran producir resultados incorrectos o podran pararse antes de terminar la computacin que estaban realizando. El diseo de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre s: Redundancia hardware (uso de componentes redundantes) y recuperacin del software (diseo de programas que sean capaces de recuperarse de los fallos). En los sistemas distribuidos, la redundancia puede plantearse en un grano ms fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operacin continuada de aplicaciones crticas. La recuperacin del software tiene relacin con el diseo de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo. Los sistemas distribuidos tambin proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporcin de tiempo que est disponible para su uso. Un fallo simple en una mquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podra desplazarse a otra estacin de trabajo; un proceso servidor podra ejecutarse en otra mquina. 6).- Transparencia La transparencia se define como la ocultacin al usuario y al programador de aplicaciones de la separacin de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una coleccin de componentes independientes. La transparencia ejerce una gran influencia en el diseo del software de sistema. El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen til de la motivacin y metas de los sistemas distribuidos. Las transparencias definidas son: Transparencia de Acceso: Permite el acceso a los objetos de informacin remotos de la misma forma que a los objetos de informacin locales. Transparencia de Localizacin: Permite el acceso a los objetos de informacin sin conocimiento de su localizacin Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de informacin compartidos y de forma que no exista interferencia entre ellos. Transparencia de Replicacin: Permite utilizar mltiples instancias de los objetos de informacin para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicacin tengan por que conoces la existencia de las replicas. Transparencia de Fallos: Permite a los usuarios y programas de aplicacin completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software. Transparencia de Migracin: Permite el movimiento de objetos de informacin dentro de un sistema sin afectar a los usuarios o a los programas de aplicacin. Transparencia de Prestaciones: Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga vara. Transparencia de Escalado: Permite la expansin del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicacin.

195

Las dos ms importantes son las transparencias de acceso y de localizacin; su presencia o ausencia afecta fuertemente a la utilizacin de los recursos distribuidos. A menudo se les denomina a ambas transparencias de red. La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en los sistemas centralizados.

6.2.4. DISEO DE SOFTWARE DE TIEMPO REAL

El software de tiempo real est muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder en un tiempo dictado por el mbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las caractersticas del sistema operativo, por los requisitos de la aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo. La computadora digital se ha convertido en una maquina omnipresente en la vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ltimas generaciones de coches y programar a nuestros aparatos. Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de computacin de tiempo real. La computadora est controlando algo que interacta con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin.

Satelite

PC PC PC

PC

Servidor

PC

Servidor Web XML

PC

Figura 6.10.- Arquitectura en tiempo real.

Generan alguna accin en respuesta a sucesos externos. Para realizar esta funcin, ejecutan una adquisicin y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real estn frecuentemente dedicados a una nica aplicacin.

196

Durante muchos aos, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reduccin del coste del hardware ha hecho posible para la mayora de las compaas, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatizacin industrial, investigacin medica y cientfica, grficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentacin industrial. Entre los muchos aspectos relativos al diseo de tiempo real estn: la coordinacin entre las tareas de tiempo real, el procesamiento de interrupciones del sistema, el manejo de E/S para asegurar que no se pierdan datos, la especificacin de las ligaduras de tiempo externas e internas del sistema y el asegurar la precisin de su base de datos. Cada diseo de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento de sistema. En la mayora de los casos, el rendimiento de un sistema de tiempo real se mide con una o ms caractersticas relativas al tiempo, pero tambin se utilizan otras medidas, tales como la tolerancia al fallo. Algunos sistemas de tiempo real se han diseado para aplicaciones en las que slo el tiempo de respuesta o la transferencia de datos es crtica. Otras aplicaciones de tiempo real requieren la optimizacin de ambos parmetros bajo unas condiciones de carga extremas. Y lo que es ms, los sistemas de tiempo real deben manejar sus cargas mximas, mientras se ejecutan varias tareas simultneamente. Puesto que el rendimiento de un sistema de tiempo real se determina principalmente por el tiempo de respuesta del sistema y su razn de transferencia de datos, es importante comprender estos dos parmetros. El tiempo de respuesta del sistema es el tiempo en el que un sistema debe detectar un suceso interno o externo y responder con una accin. Frecuentemente, la deteccin del suceso y la generacin de la respuesta son tareas sencillas. Es el procesamiento de la informacin sobre el suceso para determinar la respuesta adecuada lo que puede implicar algoritmos complejos que consumen mucho tiempo. Entre los parmetros clave que afectan al tiempo de respuesta est el cambio de contextos y la latencia de la interrupcin. El cambio de contexto se refiere al tiempo y sobrecarga necesitado para conmutar entre tareas, y la latencia de interrupcin es el tiempo que pasa antes de que el cambio sea realmente posible. Otros parmetros que afectan al tiempo de respuesta son la velocidad de calculo y el acceso a memorias masivas. La razn de transferencia de datos indica con que rapidez se introducen o salen del sistema los datos series o paralelos, tanto los analgicos como digitales. Los sistemas de tiempo real necesitan normalmente para procesar un flujo continuo de datos de llegada. El diseo debe asegurar que no falte ningn dato. Adems, un sistema de tiempo real debe responder a los sucesos que son asncronos. Por lo tanto, la secuencia de llegada y el volumen de los datos no pueden predecirse fcilmente de antemano. Aunque todas las aplicaciones de software deben ser fiables, los sistemas de tiempo real hacen una especial demanda de fiabilidad, reinicializacin y recuperacin de fallos. Debido a que el mundo real est siendo monitorizado y controlado, la prdida de monitorizado o control (o cambios) es intolerable en muchas circunstancias. Consecuentemente, los sistemas de tiempo real contienen mecanismos de restauracin y recuperacin de fallos y frecuentemente tienen incorporados redundancias para asegurar la restauracin. Sin embargo, la necesidad de fiabilidad ha estimulado un continuo debate sobre los sistemas interactivos, tales como los sistemas de reserva de billetes y cajeros automticos de los bancos, tambin son de tiempo real. Por otra parte, tales sistemas interactivos deben responder a interrupciones externas dentro de tiempos de respuesta prescritos en el orden de un segundo. Una caracterstica que sirve para distinguir a los sistemas de tiempo real de cualquier otro tipo es el manejo de interrupciones. Un sistema real debe responder a un estmulo externo interrupcin- en un tiempo dictado por el mundo externo. Debido a que frecuentemente, se presentan mltiples

197

estmulos (interrupciones), deben establecerse prioritarias, en otras palabras, la tarea ms importante debe ser siempre servida de las ligaduras de tiempo predefinidas, independientemente de otros sucesos. El manejo de interrupciones supone, no slo almacenar informacin, de forma que la computadora pueda restablecer correctamente la tarea interrumpida, sino tambin evitar interbloqueos y bucles sin fin. El enfoque global para el manejo de interrupciones, el flujo normal de procesamiento es interrumpido por un suceso que es detectado por el hardware del procesador. Un suceso es cualquier ocurrencia que necesita un servicio inmediato y puede ser generado por hardware o por software se salva el estado del programa interrumpido, es decir, se guardan todos los contenidos de los registros, los bloques de control, etc. Y se pasa el control a una rutina de servicio de interrupcin, que bifurca al software apropiado para el manejo de la interrupcin. Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, para conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento. El problema para los sistemas de tiempo real es realzar la asignacin importante como la funcin, pero las decisiones de asignacin relativas al rendimiento son frecuentemente difciles de hacer con seguridad. Base de datos de tiempo real Como muchos sistemas de procesamiento de datos, los sistemas de tiempo real, frecuentemente, van junto con una funcin de gestin de base de datos. Sin embargo, puede parecer que las bases de datos distribuidas constituyen el mtodo preferido en los sistemas de tiempo real, debido a que multitarea es muy comn y que los datos se procesan frecuentemente en paralelo. Si la base de datos es distribuida y no centralizada, las tareas individuales pueden acceder a sus datos de forma rpida, fiable y con menos cuellos de botella. El uso de una base de datos distribuida par aplicaciones de tiempo real divide el trfico de entrada/salida y acorta las colas de las tareas en espera, para acceder a una base de datos raramente causar el fallo del sistema entero si se construyen con redundancia. Las eficiencias del rendimiento conseguido mediante el uso de una forma de base de datos distribuida, debe ser medida frente a cualquier problema potencial asociado con la particin y replicacin de los datos. Aunque la redundancia de los datos mejora el tiempo de requisitos de replicacin para los archivos distribuidos tambin producen problemas logsticos y de sobrecarga, puesto que todas las copias de los archivos deben ser actualizadas, adems el uso de base de datos distribuida introduce el problema de control de concurrencia. El control de concurrencia implica la sincronizacin de las bases de datos de forma que todas las copias tengan la misma y correcta informacin disponible para los accesos. El mtodo convencional para el control de concurrencia se basa en lo que se conoce como bloqueo y estampado de tiempo. En intervalos regulares, se inician las siguientes tareas: las bases de datos son bloqueadas de forma que se asegure el control de concurrencia, se realiza la actualizacin requerida. Sin embargo, se han desarrollado algunas tcnicas para aumentar la velocidad de actualizacin y resolver el problema de concurrencia. Una de estas, llamada protocolo del escritor exclusivo, mantiene la consistencia de los archivos replicados, permitiendo que slo una tarea de escritura actualice un archivo en exclusiva. Por tanto se elimina la gran sobrecarga de los procesamientos de bloqueo y estampado de tiempo.

198

Sistemas operativos de tiempo real Dos amplias clases de sistemas operativos se utilizan los trabajos de tiempo real. Un sistema operativo de tiempo real diseado exclusivamente para aplicaciones de tiempo real y sistemas operativos de propsito general que se han reforzado para suministrar capacidades de tiempo real. El uso de un ejecutivo de tiempo real hace factible el rendimiento en tiempo real para un sistema operativo de propsito general comportndose como software de aplicacin, el ejecuta varias funciones del sistema operativo, particularmente las que afectan al rendimiento de tiempo real de una forma ms rpida y eficiente que el sistema operativo de propsito general. Todos los sistemas operativos deben tener un mecanismo de planificacin de prioridades, pero un sistema operativo de tiempo real debe dar mecanismo de prioridades que permita que las interrupciones de prioridad alta tengan precedencia sobre la menos importante. Adems, debido a que las interrupciones de prioridad ocurren en respuesta a sucesos asncronos no recurrentes, deben ser servidas sin consumir primero un tiempo de respuesta de carga de un programa de disco. Consecuentemente para garantizar el tiempo de respuesta requerido, un sistema operativo de tiempo real debe tener un mecanismo de bloqueo de memoria, esto es, mantener unos mnimos programas en memoria principal, de forma que se evite la sobrecarga del almacenamiento en la misma. Para determinar cundo en una aplicacin, puede definirse y evaluarse medidas de la calidad de sistema operativo de tiempo real.

Lenguajes de tiempo real Debido a los requisitos especiales de rendimiento y de fiabilidad demandados por los sistemas de tiempo real, es importante la eleccin del lenguaje de programacin. Puede usarse con efectividad muchos lenguajes de programacin de propsito general. Sin embargo una clase llamada lenguajes de tiempo real, se utilizan frecuentemente en aplicaciones especializadas de comunicaciones y militares. Varias caractersticas de un lenguaje de tiempo real hace diferente de un lenguaje de propsito general. stas incluyen la capacidad de multitarea, construcciones para implementacin directa de funciones de tiempo real y caractersticas modernas de programacin que ayuden a asegurar la correccin del programa. Es importante que el lenguaje de programacin soporte directamente la multitarea debido a que los sistemas de tiempo real deben responder a sucesos asncronos que ocurren simultneamente. Aunque sistemas operativos de tiempo real dan capacidad multitarea, frecuentemente existe software de tiempo real empotrado sin un sistema operativo. En vez de ello, las aplicaciones se escriben en un lenguaje que da un soporte de tiempo real suficiente para la ejecucin del programa de tiempo real. El soporte de tiempo de ejecucin requiere menos memoria que un sistema operativo y puede ser adaptado a una aplicacin, incrementando as el rendimiento.

ANLISIS Y SIMULACIN DE SISTEMAS DE TIEMPO REAL Requisitos funcionales de un sistema de tiempo real: Manejo de interrupciones y cambio de contexto. Tiempo de respuesta. Razn de transferencia de datos y tiempo invertido. Asignacin de recursos y manejo de prioridades Sincronizacin de tareas y comunicaciones entre tareas.

199

EJERCICIOS UNIDAD VI

1.- Desarrollo de un sistema para la gestin de artculos deportivos de la empresa Pumas del sector de ventas de deportes a clientes tanto a mayoristas como a minoristas.

200

CONCLUSIN
Existen diferentes tipos de sistemas con los que el ser humano est en contacto todos los das, pero el analista de sistemas est familiarizado y enfocado con los diferentes sistemas de informacin computarizados, que es el conjunto de elementos interrelacionados entre si con la finalidad de alcanzar los objetivos con los elementos de software, hardware, datos, usuarios y procedimientos. El desarrollo de software, supone un reto cada vez mayor para las corporaciones que buscan sacar un mayor provecho y aumentar la rentabilidad de su inversin en el software. Ahora que la tecnologa est en un continuo cambio, el propsito principal del analista es desarrollar aplicaciones muy complejas en cuestin estructural pero que sean de gran facilidad de manipular para el cliente. Muchos ingenieros y jefes de proyectos de sistemas en grandes organizaciones, enfatizan en la creacin y el uso de procedimientos especficos para garantizar el xito de dicho proyecto, incluyendo tanto la coordinacin del esfuerzo de los integrantes como la necesaria secuenciacin de las actividades. El inicializador de este movimiento est representado por Alfred 5 Daniel Hall , que en base a su experiencia integra los conceptos de ciencia, tecnologa y creatividad. En el diseo de un sistema de informacin o software de aplicacin, se debe tomar en cuenta los efectos que pueda producir en la introduccin del nuevo sistema sobre el entono en el que se va a poner a funcionar, adecuando los criterios de anlisis y diseo a las caractersticas del mismo. En este contexto se esta adquiriendo una importante y creciente adaptacin de todo sistema-producto para que sea sencilla, cmoda, efectiva y eficiente. De estas cuestiones se ocupa una disciplina, la ergonoma, que tiene como objetivo la optimizacin de los entornos hombre mquina. Si bien en un principio estaba concentrada en los aspectos antropomtricos de la relacin hombre mquina; en la actualidad a pasado a intervenir con fuerza en todos los procesos cognitivos (anlisis, interpretacin, decisin, comunicacin y representacin del conocimiento). As, con respecto al diseo de herramientas de software, la ergonoma tiene mucho que decir en cuestiones relacionadas con la disposicin de informacin en pantalla, profundidad de mens, formatos de iconos, nombre de comandos, control de cursores, tiempo de respuesta, manejo de errores, estructura de datos, enlaces de informacin, utilizacin de lenguajes naturales, etc. Para esto, se toma en cuenta un modelo de proceso de desarrollo de software como puede ser incremental, de cascada, espiral, unificado o personal. Estos modelos se analizan anticipadamente para que as el analista aplique las tcnicas y estudios previos de acuerdo a las necesidades y objetivos del sistema. Al trmino del anlisis, diseo, desarrollo de la estructura, ensamble de cadenas de datos o incluso, cientos de archivos y secuencia de comandos para ejecutar el sistema, se selecciona un diseo y arquitectura del software para que sea utilizado por los usuarios; este puede ser multiprocesador que permite ejecutar de forma concurrente al mismo tiempo. El diseo cliente/servidor divide las responsabilidades, que el cliente realice peticiones al servidor para que este realice las respuesta y mandarla al cliente. Lo que diferencia con l distribuido es que las computadoras estn conectadas en una red para que el software sea visto por los usuarios como una nica entidad capaz de proporcionar las facilidades que requeridas. Y el diseo en tiempo real es aquel que responde en un tiempo dictado por el mbito del problema para que arroje datos actualizados. En la actualidad es lo que se maneja y se busca en el futuro. _______________________________
5

Sir Alfred Daniel Hall, a veces conocido como Sir Daniel Hall (22 junio 1864 hasta 5 julio 1942) fue un britnico pedagogo agrnomo e investigador. Fue director de Wye College y director de la Estacin Experimental de Rothamsted .

201

BIBLIOGRAFIA

1. Kendall, Kenneth E. (2001). Anlisis y Diseo de Sistemas. Ed. Prentice-Hall. 2. Laudon & Laudon 8/E (2003). Management Information Systems. Ed. Prentice-Hall. 3. Pressman Roger S (2001). Ingeniera del software. Ed. McGraw-Hill. 4. Sommerville, Ian (2001). Ingeniera de software. Ed. Prentice-Hall. 5. Yourdan, Edward (1999). Anlisis Estructurado Moderno. Ed. Prentice-Hall. 6. Jacobson,Ivar. (2000). El Proceso unificado de desarrollo de software. Ed. Addison Wesley. 7. Fowler, Martin, (1999). UML Gota a Gota. Ed. Addison Wesley. 8. Larman, Craig (1999). UML y patrones. Pearson. 9. Humphrey, Watts S. (2000). Introduccin al Proceso Software Personal. Ed. Addison Wesley. 10. Pfleeger, Shari Lawrence (2002). Ingeniera de Software Teora y prctica. Ed. Ptentice-Hall. 11. Bruegge Bernd (2001). Ingeniera de Software Orientada a Objetos. Ed. Prentice-Hall.

202

12. Braude, Eric (2003). Ingeniera de Software una perspectiva orientada a objetos. Ed. Alfaomega. 13. Meyer, Bertrand (1999). Construccin de software orientada a objetos. Ed. Prentice Hall. 14. Alfredo Weitzenfeld Ingeniera de Software orientado a objetos con UML, Java e internet Ed. Thomson 15. Roger S. Pressman (2005) Ingeniera del software un enfoque practico Ed. Mc Grawhill Interamericana

PUBLICACIN EN WORLD WIDE WEB

PAGINAS DE PDF Notas de profesores http://profesores.elo.utfsm.cl/~agv/elo329/1s03/lectures/CharlaBreveISW.pdf (22 Oct.2009) Ingeniera Sistemas de Software
http://www.itlalaguna.edu.mx/Academico/Carreras/sistemas/ingsofware1/Unidad1.pdf (26 Oct. 2009) Anlisis de Diseo Orientado a Objetos

http://www.inf.utfsm.cl/~visconti/ili236/Documentos/03-AnDisOO.pdf (28 Oct, 2009) Sistemas Distribuidos http://ccc.inaoep.mx/~lamorales/distribuidos/sistemas%20distribuidos.pdf (14 Mayo 2010)
Introduccin Sistemas Distribuidos

http://grasia.fdi.ucm.es/jpavon/dso/introsistemasdistribuidos.pdf (30 de Oct. 2009) Ingeniera de Software I

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf (12 Mayo 2010)

203

Ingeniera de Software II http://www.itescam.edu.mx/principal/sylabus/rptSylabus.php?tipo=PDF&id_asignatura=35 4&clave_asignatura=SCM-0413&carrera=ISC0405001 (2 Nov. 2009)

SITIO WEB SILDESHARE

Ingeniera de Software http://www.slideshare.net/dersteppenwolf/introduccin-a-la-ingeniera-de-softwarequ-es-unbuen-sistema (5 Nov. 2009) Ingeniera de Software http://www.slideshare.net/pilypardo/ingenieria-de-software-presentation (5 Nov. 2009) Ingeniera de Software http://www.slideshare.net/ruthamada/proceso-del-software-una-visin-general (5 Nov. 2009) Ingeniera de Software II htp://www.slideshare.net/astaroth97/diagramas-de-flujo-975756 (8 Nov. 2009) Ingeniera de Software II http://www.slideshare.net/guestd7f491a/diagrama-de-flujo-2135078 (8 Nov. 2009) Ingeniera de Software II http://www.slideshare.net/masa832/clase-de-fds22 (8 Nov. 2009)
DOC Fundamento de Desarrollo de Sistemas http://www.scribd.com/doc/18621611/Ciclo-de-Vida (3 de Dic. 2009) Ingeniera de Software http://www.scribd.com/doc/21945705/Resumen-de-Modelos-de-Procesos-de-Software (28 Nov. 2009) Ingeniera de Software http://www.scribd.com/doc/21945444/Resumen-de-La-Ingenieria-de-Software (20 de Nov. 2009)

204

Fundamento de desarrollo de Sistemas

http://sanarandapary.wordpress.com/2009/06/12/fundamentos-de-desarrollo-de-sistemas-unidad-vi/ (25 Nov. 2009)

Fundamento de desarrollo de sistemas

http://belvel.wordpress.com/2009/06/09/15/iscitsacayucan.files.wordpress.com/.../11fundamentos-de-desarrollo-de-sistemas.ppt (5 Dic. 2009)

http://www.mitecnologico.com/Main/FundamentosDeDesarrolloDeSistemas (6 Dic. 2009) http://elo-ge-ma.blogspot.com/ (15 Dic. 2009) http://www.slideshare.net/guest9d4dd8/unidad-4-1224328?type=presentation (15 Dic. 2009) http://www.google.com.mx/search?hl=es&lr=lang_es&rlz=1W1ADBS_es&nfpr=1&ei=XeFgS96N4W8Nqzntd8L&sa=X&oi=spell_nofullpage&resnum=0&ct=result&cd=1&ved=0CAYQBSgA&q=pa radigmas+de+la+ingenieria+de+software&spell=1 (15 Dic. 2009) http://www.fing.edu.uy/inco/cursos/iis/wikiIIS/field.php/Material/Teorico (23 Dic. 2009)

http://usuarios.lycos.es/cursosgbd/UD0.htm
(23 Dic. 2009)

http://148.202.148.5/cursos/cc321/fundamentos/unidad4/tema4_9.html
(23 Dic. 2009)

http://pdf.rincondelvago.com/historia-del-software.html
(9 Ene. 2010)

http://www.monografias.com/trabajos29/ciclo-sistema/ciclo-sistema.shtml

(3 Ene. 2010)

205