Apuntes de Fundamentos de Des. de Sist.

S e c r Secretaría de Educación Pública Subsecretaría de Educación Superior

e t

SEP

a r í

SES

DGEST a

d e

INSTITUTO TECNOLÓGICO DE LÁZARO CÁRDENAS E d u c a c i ó n

TRABAJO DE TITULACION OPCION II (LIBRO DE TEXTO)

P ú b l

MONOGRAFIA:

i c a

“FUNDAMENTOS DE DESARROLLO DE SISTEMAS”

S u b s e c r e

PARA OBTENER EL TITULO DE:

t a r

INGENIERO EN SISTEMAS COMPUTACIONALES

í a d e

E d u c a

PRESENTA: MAGALI GUERRERO ZARAGOZA NUMERO DE CONTROL: 03560092

c i ó n

S u p e r i o

ASESOR: M.C. DANIEL ROJAS CID

r

CD. Y PUERTO LÁZARO CÁRDENAS MICH. DICIEMBRE DEL 2009.

CERTIFICADO ISO 9001

RSGC - 247

PREFACIO

Este libro es el producto de una investigación de docencia a nivel licenciatura, en el área de los sistemas de información dentro de la Tecnología de la información (IT). Aunque en la actualidad existe un número cada vez mayor de libros de texto, en especial en ingles, relacionados con la ingeniería de software y los sistemas de información, el principal objetivo de esta obra es su enfoque, que cubre de manera integral tanto los aspectos teóricos como los prácticos. En particular se busca que el lector aprenda cómo desarrollar sistemas de calidad mediante la creación de una arquitectura de software y el seguimiento de una metodología bien definida. Por tal razón, una parte importante del libro se basa en un sistema comprensivo de software, en lugar de pequeños ejemplos aislados. Otro motivo para la escritura de este libro es reducir la brecha existente entre el número de textos en ingles y español. 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 maestría, con programas semestrales o trimestrales, de manera completa o parcial, pues es una introducción a la ingeniería de software. El título 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 más relevantes para un curso de ingeniería 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 definición, historia, características y mitos de la Ingeniería de Software. Se analiza las capas de dicha ingeniería para realizar el desarrollo del software tomando en cuenta los factores de calidad y productividad.

Unidad III Analiza las actividades más 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 técnicas de recopilación para darle una estructura orientada a objetos y se desarrolle el prototipo de dicha información.

Unidad VI Describe las características de cada arquitectura para el diseño del software tomando en cuenta el tipo de dominio de la aplicación.

2

INDICE

Unidad 1 Conceptos Introductorias PÁGINA 1.1 Introducción a los Sistemas .........................................................................................10 1.1.1 Descripción General ................................................................................................11 1.1.2 Tipos .........................................................................................................................12 1.1.3 Clasificación ..............................................................................................................24 1.2 Ciclo de Vida de un Proyecto de Software .................................................................26 1.2.1 Planificación y Gestión del Proyecto ........................................................................27 1.2.2 Determinación de Requerimientos ..........................................................................29 1.2.3 Análisis y Diseño .......................................................................................................30 1.2.4 Programación ...........................................................................................................32 1.2.5 Pruebas e Implementación .......................................................................................32 Preguntas y ejercicios .......................................................................................................36

Unidad 2 Introducción a la ingeniería de software 2.1 Definición de Ingeniera de Software ............................................................................38 2.2 Historia de la Ingeniería de Software ...........................................................................40 2.3 Características del Software ........................................................................................47 2.4 Mitos del Software .......................................................................................................50 2.5 Capas de la Ingeniería 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 ingeniería 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 Diseño de Módulos ..................................................................................................84 3.1.4 Descomposición en Procesos .................................................................................85 3.2 El Enfoque Orientado a Objetos .................................................................................87 3.2.1 Análisis .....................................................................................................................91 3.2.2 Diseño Objetos ........................................................................................................97 Ejercicios ..........................................................................................................................101

3

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 Técnicas herramientas y estudios previos 5.1 Técnicas de Recopilación de Información ................................................................127 5.1.1 Entrevista ...............................................................................................................127 5.1.2 Cuestionario ...........................................................................................................135 5.1.3 Recopilación y análisis de documentos .................................................................143 5.1.4 Observación y Técnica “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 Diseño y arquitectura de productos de software 6.1 Descomposición Modular..........................................................................................181 6.2 Arquitecturas de Dominio Específico ........................................................................184 6.2.1 Diseño de Software Arquitectura Multiprocesador ................................................186 6.2.2 Diseño de Software Arquitectura Cliente Servidor ................................................188 6.2.3 Diseño de Software Distribuido .............................................................................191 6.2.4 Diseño de Software de Tiempo Real ........................................................................... 196 Ejercicios ..........................................................................................................................200

Conclusión ...........................................................................................................................201

Bibliografía ..........................................................................................................................202

4

INDICE DE FIGURAS PÁGINA 1.1 Elementos básicos de control en un modelo de sistema .................................................12 1.2 Sistema en línea ...............................................................................................................16 1.3 Sistema de tiempo real .....................................................................................................18 1.4 Sistema Ligtyear de apoyo a la toma de decisiones ........................................................20 1.5 Modelo de planeación estratégico basado en el análisis de brecha de posición .............21 1.6 Jerarquía de los sistemas de procesamiento de información. .........................................21 1.7 Modelo de planeación estratégica basado en la fuerza del mercado ...............................23 1.8 Actividades para desarrollar e implantar un sistema de información ...............................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 Configuración del software ................................................................................................52 2.7 Capas de la ingeniería de software ...................................................................................53 2.8 Marco de trabajo del proceso de software .........................................................................57 2.9 Relación entre elementos del proceso del software .........................................................58 2.10 Niveles de madurez del proceso del software ...............................................................61 3.1 Símbolos básicos de un diagrama de flujo .......................................................................66 3.2 Diagrama de flujo de datos en nivel 0 y nivel 1 ................................................................69 3.3 Igualación del diagrama de flujo nivel 0 y el de contexto .................................................70 3.4 Diagrama de flujo de datos nivel 0 para un sistema médico 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 constitución del DD ................................83 3.15 Diseño de módulos .........................................................................................................85 3.16 Ejemplo de la descomposición de un diagrama de flujo de datos (DFD) .......................86 3.17 Ejemplo de los atributos de un objeto de la clase Automóviles ......................................87

5

3.18 Los atributos compartidos de los objetos se agrupan en la clase ..................................88 3.19 Ejemplo de la información 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 análisis orientado a objetos ............................................................................91 3.24 Notación 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 diseño O-O agrupados en componentes y capas ....................................97 3.30 Componentes del manejo de tareas del análisis y diseño O.O ......................................99 3.31 Diseño de una clase y objeto, servidor, objetos ...........................................................100 3.32 Ejemplo parcial de una clase almacenada ...................................................................100 3.33 Notación de diseño de herencia comparativo de cinco autores diferentes de análisis y diseño O.O ............................................................................................................................101 4.1 Esquema básico de modelo cascada .............................................................................105 4.2 Modelo en espiral típico ..................................................................................................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 Evolución 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 planeación 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 información 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 Utilización del círculo para la respuesta .......................................................................142 5.14 Tipo de información obtenida durante la investigación.................................................143 5.15 Preguntas de forma oficial y extraoficial que ya se encuentren llenas .........................148 5.16 Análisis de los memorándums que orientan a la organización ....................................149

6

5.17 Revelación de los valores, las actitudes y las creencias de los miembros de las organizaciones, respecto al uso de la información ...............................................................150 5.18 Manual de políticas .......................................................................................................151 5.19 Ventajas y desventajas en el uso de información de archivo para el analista de sistemas ..................................................................................................................................151 5.20 Tipo de información cuando se observa la conducta del tomador de decisiones .............. ..................................................................................................................................151 5.21 Resumen de las características de los elementos STORE ..........................................155 5.22 escala tipo likert utilizados para examinar con ESTORE .............................................157 5.23 Lista anecdótica con símbolos utilizada en la aplicación 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 utilización de las tecnologías del ambiente ...........................................162 5.27 Desventajas de la utilización de las tecnologías del ambiente .....................................163 5.28 Tipos de información buscada durante el desarrollo de prototipos ..............................169 5.29 Prototipo de remedio .....................................................................................................170 5.30 Prototipo no funcional puede indagar sobre la opinión de los usuarios sobre .................. interfaces (Entrada/ Salida) ..........................................................................................171 5.31 Primer modelo a escala completa .................................................................................172 5.32 Modelo que cuenta con ciertas características 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 más 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 descomposición modular .................................................................182 6.3 Arquitectura de dominios específicos (DSSA) ................................................................184 6.4 Modelo de compilador .....................................................................................................185 6.5 Modelo OSI, modelo en capas para sistemas de comunicación ....................................185 6.6 Arquitectura del diseño de software multiproceso ..........................................................187 6.7 Arquitectura cliente/servidor ...........................................................................................189 6.8 Creación de un software de arquitectura cliente/servidor...............................................190 6.9 Arquitectura de software distribuido ................................................................................192 6.10 Arquitectura en tiempo real ...........................................................................................196

7

INDICE DE TABLAS

PÁGINA

1.1 Hoja de cálculo financiero que calcula las ganancias de un departamento de una organización .........................................................................................................................19

2.1 Lenguajes utilizados en cada era de la historia de la ingeniería de software .................... .......................................................................................................................................44 2.2 Cronograma de estándares y modelos para la calidad del software .............................59 2.3 Niveles de madurez del proceso del software ...............................................................61

5.1 Balance general de la corporación ...............................................................................144

8

CONCEPTOS INTRODUCTORIOS

1.1 INTRODUCCIÓN A LOS SISTEMAS 1.1.1 DESCRIPCIÓN GENERAL 1.1.2 TIPOS 1.1.3 CLASIFICACIÓN

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

PLANIFICACIÓN Y GESTIÓN DEL PROYECTO DETERMINACIÓN DE REQUERIMIENTOS ANÁLISIS Y DISEÑO PROGRAMACIÓN PRUEBAS E IMPLEMENTACIÓN

9

1.1

INTRODUCCIÓN A LOS SISTEMAS

No se puede decir mucho acerca del análisis de sistemas hasta que se tenga una idea clara de lo que es un sistema. Existe una definición “oficial” en el diccionario, que parecerá algo abstracto, sin embargo hay muchos usos comunes del término que le serán familiares y existen muchos tipos comunes de sistemas con los que tenemos contacto todos los días. El analista de sistemas esta mas familiarizado y enfocado con los diferentes tipos de sistemas de sistemas de información 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 organización (que en sí, es un sistema), que a su vez es parte de un sistema económico mayor, etc., o bien se puede estar haciendo un sistema de control de procesos que es parte de una refinería química 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. También la mayoría de los sistemas computarizados interactúan 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, teorías y filosofías comunes que se aplican muy bien, prácticamente a todos los tipos de sistemas. Por ello, frecuentemente se puede aplicar lo aprendido acerca de otros sistemas basándose en la experiencia diaria, y en la de diversos tipos de científicos e ingenieros a los sistemas que se construye en el campo de la computación. Por ejemplo, uno de los principios importantes de sistemas, primeramente observando en el campo de la biología, es conocido como la ley de la especialización: entre más adaptado se encuentra un organismo a un ambiente específico, más difícil le será adaptarse a un ambiente diferente. Esto ayuda a explicar la desaparición de los dinosaurios cuando cambio drásticamente el clima de la tierra, y también ayuda a los analistas a entender que si optimizan un sistema computarizado para obtener la máxima ventaja de un procesador, de un lenguaje, de programación y de un sistema administrador de base de datos, probablemente tendrán grandes dificultades para adaptar dicho sistema de forma que se ejecute en un procesador diferente o con un sistema de administración de base de datos diferentes. De aquí se comprende algo de la teoría general de sistemas, ayudara a entender mejor los sistemas computarizados (automatizados) de información. 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 años.

10

1.1.1 DESCRIPCIÓN GENERAL

El Instituto Americano de Estándares Nacionales (ANSI) define a un sistema como: Un conjunto de métodos, procedimientos o técnicas unidas por una interacción regulada para formar un todo organizado. El Comité Técnico de la Organización Internacional para la Estandarización (La Internacional Organization for Standardization Technical Committee) también define un sistema como: Un conjunto organizado de hombres, máquinas y métodos que se requieren para lograr un conjunto de funciones específicas. En el sentido más amplio un sistema es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común. Nuestra sociedad está rodeada de sistemas. Por ejemplo, cualquier persona experimenta sensaciones físicas gracias a un complejo sistema nervioso formado por el cerebro, la médula espinal, los nervios y las células sensoriales especializadas que se encuentran debajo de la piel; estos elementos funcionan en conjunto para hacer que el sujeto experimente sensaciones de frío, calor, comezón, etc. Las personas se comunican con el lenguaje, que es un sistema muy desarrollado formado por palabras y símbolos que tienen significado para el que habla y para quienes lo escuchan. Asimismo, las personas viven en un sistema económico en el que se intercambian bienes y servicios por otros de valor comparable y en el que, al menos en teoría, los participantes obtienen un beneficio en el intercambio. Una organización es un sistema, sus componentes -mercadotecnia, manufactura, ventas, investigación, embarques, contabilidad y personal- trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los accionistas de la compañía. 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, facturación y auditoria entre otras. Todo sistema organizacional depende, en mayor o menor medida, de una entidad abstracta denominada sistema de información. 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 comunicación interna entre los diferentes componentes de la organización y líneas telefónicas hasta sistemas de cómputo que generan reportes periódicos para varios usuarios. Los sistemas de información proporcionan servicio a todos los demás sistemas de una organización 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 razón de su existencia, por ejemplo, existe un sistema legislativo, para estudiar los problemas que enfrentan los ciudadanos y aprobar la legislación que los resuelva. El sistema de encendido de un automóvil tiene el claro propósito de quemar el combustible para crear la energía que emplean los demás sistemas del automóvil. Los sistemas ser dividen en dos por cómo interactúan con el medio ambiente. Los que reciben entradas y producen salidas se denominan sistemas abiertos y los que no interactúan para nada con el medio ambiente se llaman sistemas cerrados. Todos los sistemas tienen niveles aceptables de desempeño, denominado estándares y contra los que se comparan los niveles de desempeño actuales. Siempre deben anotarse las actividades que se encuentran muy por encima o por debajo de los estándares para poder efectuar los ajustes necesarios. La información proporcionada al comparar los resultados con los estándares junto con el proceso de reportar las diferencias a los elementos de control recibe el nombre de retroalimentación (véase Fig. 1.1).

11

Los sistemas emplean un modelo de control básico, que consiste en: Un estándar para lograr un desempeño aceptable. Un método para medir el desempeño actual Un medio para comparar el desempeño actual contra el estándar. Un método de retroalimentación.

Frontera del Sistema

F r o

Entrada

D

n

e

t

s E e n Actual

e

m t p r

a

e a ñ d

d

o a

l

r

Salida Estándar

S a l i

e

d a

S i

Figura 1.1 Elementos básicos 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 mayoría de los sistemas no están hechos por el hombre: existen sistemas en la naturaleza. Dado que el objetivo son los sistemas computacionales, estos se dividen en dos categorías: Sistemas Naturales y Sistemas Hechos por el hombre. Se tiene que tomar en cuenta que muchos sistemas hechos por el hombre (sistemas automatizados) interactúan con sistemas vivientes: por ejemplo, los marcapasos computarizados interactúan con el corazón humano. En algunos casos, se diseñan 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 subcategorías básicas: 1. Sistemas físicos. Los sistemas físicos incluyen ejemplos tan variados como: a. Sistemas estelares: galaxias, sistemas solares, etcétera. b. Sistemas geológicos: ríos, cordilleras, etcétera. 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 categoría también comprende jerarquías de organización viviente individuales, por ejemplo hierbas, manadas, tribus, grupos sociales, compañías y naciones. Miller argumenta que los sistemas vivos, sean estos a nivel celular, de órgano, de organismo, de grupo, de organización, 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 organización de negocios, pudiera ser una división de plantación 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 materiaenergía e información. En una organización de negocios, esto pudiera constituir la planta misma (edificio de oficinas, fábricas, etc.) y los guardias u otro personal de seguridad que evitan el ingreso de intrusos indeseables. c. El inyector.-Transporta la materia-energía a través de la frontera del sistema desde el medio ambiente. En una organización de negocios, este pudiera ser el departamento de compras o recepción, 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 organización. d. El distribuidor.-Trae materia desde el exterior del sistema y lo reparte desde sus subsistemas a cada componente. En una organización de negocios, pudiera estar conformado por las líneas telefónicas, correos electrónicos, mensajeros, bandas y una variedad de otros mecanismos. e. El convertidor.-Cambia ciertos materiales que ingresan al sistema a formas más útiles para los procesos especiales de dicho sistema particular. Nuevamente, se puede imaginar un buen número de ejemplos de esto en una organización de negocios típica. f. El productor.-Forma asociaciones estables durables por periodos significativos con la materia-energía que ingresa al sistema o que egresa de su convertidor. Estos materiales sintetizados puede servir para crecimiento, reparación de daños o reposición de componentes de sistema, o bien para proveer energía para mover o constituir los productos o la información de mercado a su suprasistema. g. El subsistema de almacenamiento de materia-energía.-Retiene en el sistema, durante diferentes periodos, depósitos de diversos tipos de materia-energía. h. El expulsor.- Transmite materia-energía al exterior del sistema en forma de desechos o de productos. i. El motor.-Mueve el sistema o a sus partes en relación 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 señales portadoras de información al sistema transformándolas en otras forma de materia-energía adecuada para su transmisión al interior. l. El transductor interno.- Recibe de otros subsistemas o componentes del sistema señales de portan información acerca de alteraciones significativas en dichos subsistemas o componentes, transformándolos en otras formas de materia-energía transmisibles en su interior. m. El canal y la red,.- Están compuestos por una sola ruta en el espacio físico, o bien por múltiples rutas interconectadas, mediante las cuales las señales portadoras de información se transmiten a todas las partes del sistema. n. El decodificador.- Altera las claves de información 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 información dentro del sistema. p. La memoria.- Lleva a cabo la segunda etapa del proceso de aprendizaje, almacenando diversos tipos de información en el sistema durante diferentes periodos. q. El que decide, que recibe información de todos los demás subsistemas y les transmite información que sirve para controlar al sistema completo. r. El codificador.- Altera la clave de información que se le introduce desde otros subsistemas procesadores de información, convirtiéndola, 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 señales portadoras de información desde el sistema, transformando los marcadores dentro del sistema en otras formas de materia-energía que puedan ser transmitidas por medio de canales en el medio ambiente del sistema. Sistemas hechos por el hombre.- Un buen número de sistemas son construidos, organizados y mantenidos por humanos, e incluyen: 1. Sistemas Sociales.- Organizaciones de leyes, doctrinas, costumbres, etcétera. 2. Una colección organizada y disciplinada de ideas.- El sistema decimal Dewey de organización de libros en bibliotecas, el sistema de reducción de los cuida-kilos, etcétera. 3. Sistemas de Transporte.- Redes de carreteras, canales, aerolíneas, buques cargueros, etcétera. 4. Sistemas de Comunicación.- Teléfono, telex, utilizadas por los corredores de bolsa, etcétera.

señales de humo, señales de mano

5. Sistemas de Manufactura.- Fábricas, líneas de ensamblado, etcétera. 6. Sistemas Financieros: contabilidad, inventarios, libro mayor, bolsa de valores, etcétera. En la actualidad, la mayoría de estos sistemas incluyen las computadoras; de hecho, muchos no podrían sobrevivir sin ellas. Sin embargo, es igualmente importante señalar que dichos sistemas existían 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 tecnología utilizada para implantar el sistema. En la mayoría de los casos, se pude determinar si tiene sentido utilizar una computadora para llevar a cabo las funciones del sistema sólo tras haber modelado su comportamiento esencial. Por ejemplo, la frase común, “Juan tiene un sistema para llevar a cabo su trabajo” o “vaya que María tiene una manera sistemática de hacer su trabajo”. Tales frases no necesariamente sugieren que María ha computarizado su trabajo o que Juan ha utilizado algunos de los instrumentos formales de modelación para hacer su trabajo. Pero ciertamente las frases implican que Juan y María han dividido su trabajo en una serie de pasos definidos, la suma acumulativa de los cuales logrará algún propósito general. ¿Por qué no debieran automatizarse algunos sistemas de procesamiento de información? Puede haber muchas razones; las más comunes:

1. Costo.- Puede ser más barato continuar llevando a cabo las funciones y almacenando la información del sistema en forma manual. No siempre es cierto que las computadoras sean más rápidas y económicas que el método “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 información mantiene datos confidenciales, el usuario pudiera no creer que el sistema automatizado sea lo suficientemente seguro; tal vez desee mantener la información físicamente protegida y bajo llave. 4. Facilidad de Mantenimiento.- El usuario pudiera argumentar que un sistema de información computarizada sería costeable, excepto por el hecho de que no hay ningún miembro del personal que pudiera encargarse del mantenimiento del hardware y/o el software de la computadora, de manera que nadie podría reparar el sistema si éste sufriera un desperfecto, ni habría quien pudiera efectuar cambios o mejoras. 5. Políticas.- La comunidad usuaria pudiera recelar que las computadoras amenazan con privarla de sus empleos o con volver aburridos o “mecánicos” sus trabajos o con una docena de otras razones que el analista de sistemas podría considerar irracionales. Pero dado que se trata del sistema del usuario, sus recelos son de primera importancia. Si no desean tener un sistema automatizado, harán todo lo posible por lograr que falle si se les quiere imponer.

Sistemas automatizados Son sistemas hechos por el hombre que interactúan con o son controlados por una o más computadoras. Una manera de ordenar por categorías los sistemas automatizados es por su aplicación: sistemas de manufactura, sistemas de contabilidad, sistema de defensa militar, etc. Sin embargo las técnicas para analizar, modelar, diseñar e implantar sistemas automatizados generalmente son las mismas, independientemente de su aplicación. Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener componentes en común que son el hardware y software: ________________________________ 1

Dispositivo electrónico o electromecánico de hardware, usado para introducir o mostrar datos de un computador o de un sistema de computación

15

Una división en categorías más útil de los sistemas automatizados es la siguiente: 1.- Sistemas en línea En 1972, Yourdon definió los sistemas en línea de la siguiente forma: “Un sistema en línea es aquel que acepta material de entrada directamente del área donde se creó. También es el sistema en el que el material de salida, o el resultado de la computación, 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 característica común de los sistemas en línea 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 interactúan con la computadora desde terminales que pueden estar localizadas a cientos de kilómetros de la computadora misma. Otra característica de un sistema en línea 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 información (registro individual o un expediente individual) puedan ser recuperadas modificados o ambas cosas rápidamente y sin tener necesariamente que efectuar accesos a otros componentes de información del sistema. Esto contrasta enormemente con los sistemas fuera de línea o en lotes (batch), que eran más comunes en las décadas de los años 60 y 70. En un sistema computacional por lotes, la información 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 línea interactúa 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, además 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 automático es “el usuario ha insertado su tarjeta y se ha identificado. La información se teclea desde el lugar de origen

Los datos se organizan de modo que se puedan recobrar fácilmente Procesador

La salida se transmite a donde es requerida

Figura 1.2.-Sistema en línea.

16

A menudo se hace referencia a esto como “dialogo hombre-máquina”, o “interfaz hombre maquina”. Cada vez son más las organizaciones de desarrollo de sistemas que utilizan la expresión “interfaz humano-computadora” o, simplemente, “interfaz humana. Dado que los sistemas en línea por lo común requieren recuperar datos con rapidez (para poder responder a preguntas y órdenes provenientes de terminales en línea), suele ser muy importante diseñar los archivos y bases de datos de la manera más eficiente posible. A menudo las operaciones de computación llevadas a cabo por un sistema en línea suelen ser relativamente triviales, mientras que los datos (sobre todo, la estructura y organización de los datos mantenida por el sistema en línea) suelen ser bastante complejos. La decisión de convertir o no un sistema ordinario en un sistema en línea son, en el contexto de este libro, una decisión de puesta en práctica, es decir, no es algo que debiera ser determinado por el analista de sistemas sino más bien por las personas que ponen en práctica 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 decisión de puesta en práctica en la cual habitualmente los usuarios querrán participar. Sistema de tiempo real Es aquel que controla un ambiente recibiendo datos, procesándolos y devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese momento. Ciertamente, existen muchos sistemas en línea (sistemas bancarios, de reservaciones aéreas y sistemas de bolsa) que se espera reaccionen en uno o dos segundos a un mensaje tecleando en la terminal. Sin embargo, en la mayoría de los sistemas de tiempo real, la computadora debe reaccionar en milisegundos y a veces en microsegundos a los estímulos que recibe. Esto es característico de los siguientes tipos de sistemas: 1. Sistemas de control de procesos.- Sistemas computacionales que se utilizan para verificar y controlar refinerías, procesos químicos, molinos y operaciones de maquinado. 2. Sistemas de cajeros automáticos.- Las “maquinas de efectivo” que muchos de nosotros usamos para hacer depósitos y retiros sencillos en el banco. 3. Sistemas de alta velocidad para adquisición de datos.- Sistemas computacionales que obtienen datos de telemetría a alta velocidad de satélites de órbita o las computadoras que capturan cantidades enormes de datos de experimentos de laboratorio. 4. Sistemas de guía de proyectiles.- Sistemas computacionales que deben rastrear la trayectoria de un proyectil y hacer ajustes continuos a la orientación y empuje de los propulsores. 5. Sistemas de conmutación telefónica.-Sistemas computacionales que controlan la transmisión de voz y datos en miles de llamadas telefónicas, detectando los números marcados, condiciones de ocupado y todas las demás condiciones de una red telefónica típica. 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 límites predeterminados. Además de la velocidad, existe otra característica que diferencia a los sistemas de tiempo real de los sistemas en línea: estos últimos suelen interactuar con las personas, mientras que los sistemas de tiempo real usualmente interactúan tanto con personas como con un ambiente que en generalmente es autónomo y a menudo hostil. La principal preocupación 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 línea que no responda con la suficiente rapidez en general no hará más que volver impaciente y gruñones 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 práctica, los sistemas de tiempo real (así como algunos sistemas en línea) se caracterizan por lo siguiente: 1. Simultáneamente 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 comunicación entre tareas, especialmente dado que muchas tratan diferentes aspectos de un proceso general, como el control de un proceso de manufactura. 5. Existe acceso simultáneo a datos comunes, tanto en memoria como en el almacenamiento secundario, por lo cual se requiere de un elaborado proceso de sincronización y “semáforos” para asegurar que los datos comunes no se corrompan. Sistemas de apoyo a decisiones y sistemas de planeación estratégica La mayor parte de los sistemas automatizados de información que se crearon durante los últimos 30 años son sistemas operacionales que ayudan a llevar a cabo los detalles del trabajo cotidiano de una organización, también se conocen como sistemas de procesamiento de transacciones como por ejemplo los sistema de nómina, de contabilidad y de manufactura. Sin embargo, dado que los sistemas operacionales actuales continúan tambaleándose, muchas organizaciones se están enfocando a un nuevo tipo de sistemas: los de apoyo a la toma de decisiones.

18

Como lo implica el término, estos sistemas computacionales no toman decisiones por sí mismos, sino ayudan a los administradores y a otros profesionistas “trabajadores del conocimiento” de una organización a tomar decisiones inteligentes y documentadas acerca de los diversos aspectos de la operación. Estos sistemas son pasivos en el sentido de que no operan en forma regular, se utilizan de manera a propósito, cuando se les necesita. Existe un gran número de ejemplos sencillos de sistemas de apoyo a decisiones: programas de hoja de cálculo, sistemas de análisis estadístico, programas de pronóstico de mercados, etc. Una característica común de los sistemas de apoyo a decisiones es que no sólo recuperan y exhiben los datos, sino que también realizan varios tipos de análisis matemáticos y estadísticos de los mismos. Los sistemas de apoyo a decisiones también tienen la capacidad, en la mayoría de los casos, de presentar la información en una variedad de formas gráficas (tablas, gráficos, etc.) al igual que en forma de “reportes” (informes) convencionales. En la tabla 1.1 se muestra una hoja de cálculo financiera característica que pudiera utilizar un gerente para evaluar las ganancias de alguna división dentro de su organización; De cualquier forma que se muestre el resultado, la información de salida producida por el sistema no “toma” una decisión, sino que provee información relevante para que el gerente pueda decidir. “Proyección de pérdidas y ganancias de la compañía “

Venta Nacional Venta Internacional Ingresos diversos TOTAL DE INGRESOS Costo de venta Salarios Otros gestos de empleo Renta Teléfono Correos Viajes/diversos Contabilidad/asuntos legales Depreciación Gastos diversos TOTAL DE GASTOS GANACIA/PERDIDA

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

Tabal 1.1.- Hoja de cálculo financiero que calcula las ganancias de un departamento de una organización.

Algunos sistemas de apoyo a decisiones son útiles para articular y mecanizar las reglas utilizadas para llegar a alguna decisión 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 múltiples usuarios) describir los detalles de un problema que requiera decisiones; un ejemplo podría ser el problema de decidir en dónde ubicar una nueva oficina. primeramente el usuario identifica los criterios que se utilizarán para tomar la decisión. Para el problema de ubicar una nueva oficina esto pudiera incluir, por ejemplo, que “debe ser accesible en transporte público” y que “no debe estar en una zona de alta probabilidad sísmica”. 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 selección automática de otra. La mejor alternativa automáticamente será seleccionada por el programa Lightyear. La figura 1.4 ilustra este proceso.

19

Identificar alternativas

Establecer criterios de evaluación

Clasificar las alternativas de acuerdo con los criterios

Elegir lo más adecuado Figura 1.4.-Sistema Lightyear de apoyo a la toma de decisiones

Sistemas de planeación estratégica Son utilizados por los gerentes en jefe para evaluar y analizar la misión de la organización. En lugar de dar consejos acerca de alguna decisión de negocios aislada, estos sistemas ofrecen consejos más amplios y generales acerca de la naturaleza del mercado, las preferencias de los consumidores, el comportamiento de la competencia, etc. Los sistemas de planeación estratégica no son programas de computadora en sí; son complejas combinaciones de actividades y procedimientos, muchas de los cuales las llevan a cabo humanos utilizando información obtenida de fuentes externas (estudios de mercado, etc.) y datos internos de los sistemas operacionales de la organización y los sistemas de apoyo a decisiones. Steiner señala que hay muchos tipos de sistemas de planeación estratégica, según el tamaño y naturaleza de la organización. La figura 1.5 muestra el sistema de planeación estratégica basada en el análisis de brecha de posición trata de identificar la discrepancia entre la posición actual de la organización (en términos de ganancias, rentabilidad, etc.) y la posición 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 planeación estratégica.

__________________________ 2.-

Uno de los ejemplos más interesantes de una situación de tiempo real es el de un equipo de trabajo cuya misión era unir una pequeña computadora a una bomba nuclear. Cuando se detonara la bomba (como parte de un programa de pruebas), la computadora dispondría 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 explosión. Esa sí que es una real exigencia del procesamiento en tiempo real.

20

Figura 1.5.-Modelo de planeación estratégica basado en el análisis de brecha de posición.

Los sistemas operacionales crean los datos requeridos por los sistemas de nivel superior y continúan actualizando los datos de una manera continua. La forma piramidal de la figura representa otra característica típica de los sistemas de información que se pueden encontrar en la mayoría de las organizaciones hoy en día: el tamaño de los sistemas operacionales (medidos en años-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 planeación estratégica. 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 planeación estratégica.

Figura 1.6.- Jerarquía de los sistemas de procesamiento de información.

21

La planeación estratégica 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 planeación estratégica no son programas de computadora en sí; son complejas combinaciones de actividades y procedimientos, muchas de las cuales las llevan a cabo humanos utilizando información obtenida de fuentes externas (estudios de mercado, etc.) y datos internos de los sistemas operacionales de la organización y los sistemas de apoyo a decisiones. Existen muchos tipos de sistemas de planeación estratégica, según el tamaño y naturaleza de la organización.

Sistemas basados en el conocimiento. Un término 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 científicos de la computación que trabajan en el campo de la inteligencia artificial es producir programas capaces de imitar el desempeño humano en una gran variedad de tareas “inteligentes”. Para algunos sistemas expertos la meta está próxima a ser alcanzada; para otros, aunque aún no sabemos construir programas que funcionen bien por sí solos, podemos comenzar a crear programas capaces de auxiliar a las personas en la ejecución 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 desempeño de una tarea dada. Los sistemas expertos son una especie de sistema basado en el conocimiento, aunque ambos términos a menudo se utilizan indistintamente. Se construyen de tal manera que sean capaces de explicar las líneas 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 característica primordial de los sistemas expertos. Los diseñadores 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. Aún 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 estándar, y cascarones de sistemas expertos, que son estructuras de software para el desarrollo de aplicaciones específicas de sistemas expertos.

Principios de sistemas generales Todos los ejemplos expuestos tienen una cosa en común: todos son sistemas. Mientras que pueden diferir en varias cosas, también poseen muchas características comunes. El estudio de dichas características comunes se conoce como teoría general de sistemas y existen algunos principios “generales” que son de interés particular para quienes crean sistemas automatizados de información, e incluyen los siguientes: 1. Entre más especializado sea el sistema, menos capaz es de adaptarse a circunstancias diferentes. Entre más general sea un sistema, menos óptimo será para una situación determinada; pero entre más óptimo sea, para tal situación menos adaptable será a nuevas circunstancias.

22

2. Cuanto mayor sea el sistema mayor es el número de sus recursos que deben dedicarse a su mantenimiento diario. Un pequeño 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 revisión de errores, la edición, el respaldo, el mantenimiento, la seguridad, y la documentación. 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 aún más importante es el hecho de que sugiere que la definición 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 violaría un principio general muy familiar, la ley de la conservación de la energía. Pero muchos sistemas con los que estamos familiarizados sí crecen y resulta importante reconocerlo, pues a menudo omitimos (como analistas y como diseñadores de sistemas) tomar esto en cuenta al comenzar a crear el sistema. Un sistema de información típico, crecerá hasta el punto de incluir más software, más datos, más funciones y más usuarios que los que inicialmente habíamos planeado.

Figura 1.7.- Modelo de planeación estratégica basado en la fuerza del mercado.

23

Aunque los sistemas expertos van más allá de los alcances de este libro, gradualmente se convertirán en un componente cada vez más importante de los sistemas “típicos” en los que trabaja un analista de sistemas. A fines de la década de los 80, los investigadores comenzaron a estudiar la relación entre las técnicas de desarrollo de software clásico y la inteligencia artificial, un estudio típico es Jacob y Froscher. Keller prevé un momento en el futuro cercano en el cual los sistemas de IA y los sistemas expertos formarán parte de la actividad “normal” del análisis de sistemas; otros, como Barstow y Lucas y Harandi, prevén que la inteligencia artificial auxiliará a los analistas de sistemas en la documentación de los requerimientos del usuario para mediados de la década 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 Corporación Financiera Internacional (CFI), filial del Banco Internacional para la Reconstrucción y el Desarrollo, cuyo sistema de transacciones funciona de la siguiente manera: El CFI busca inversores interesados en los países más desarrollados y el capital proveído por éstos, es transferido a empresas privadas de países 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 países, siendo uno de los más transportados el petróleo, cuyos pedidos pueden ser ya sea privado o por contrato. Los barcos transportan el petróleo desde los campos petrolíficos a las refinerías, 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 diseñadores gráficos en crear su arte publicitario por medio de poderosas herramientas con las cuales se puede manipular y modificar distintos tipos de gráficos y fotografías.

Sistemas Expertos. La inteligencia artificial es un famoso sistema experto para la realización de diagnósticos, el cual aconseja a los médicos en la investigación y determinación de diagnósticos en el campo de las enfermedades infecciosas de la sangre. El sistema MYCIN, al ser consultado por el médico, solicita primero datos generales sobre el paciente: nombre, edad, síntomas, etc. Una vez conocida esta información por parte del sistema, el Sistema Experto plantea unas hipótesis. Para verificar la hipótesis el sistema consulta a la base de conocimientos, y también haciendo una serie de preguntas al usuario. Con las respuestas que recibe, el MYCIN verifica o rechaza las hipótesis planteadas. Otro sistema experto es el XCON el cual es un sistema experto de configuraciones el cual, según 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 más rápido 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 Visión Quest, el cual permite realizar juntas electrónicas. Entre sus ventajas se encuentra su facilidad de uso. Cualquiera puede conducir una junta electrónica 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 interacción se realiza a través 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 interacción informal. CRUISER está diseñado alrededor del concepto de comunidad o grupo virtual que existe sólo en un mundo virtual, donde las distancias geográficas entre los participantes no son importantes. Por sus características este sistema provee acceso instantáneo a cualquier persona y cualquier lugar. La importancia del sistema está basada en dos ideas. La primera, los usuarios pueden navegar a través del mundo virtual en búsqueda de encuentros sociales. La segunda, el mundo virtual es independiente del mundo físico y puede ser organizado de acuerdo a las necesidades del usuario. En la práctica el usuario recorre pasillos, oficinas y áreas comunes, todas ellas generadas por computadora. Los usuarios se comunican a través de audio y video. CRUISER ataca uno de los problemas de los trabajos en equipo, reconoce la importancia de la comunicación informal. Provee además características de la práctica de trabajo permitiéndole diferentes niveles de privacidad.

Sistema de ejecutivos. Un ejemplo es el sistema comprado por Pratt & Whitney, una corporación que se dedica a la producción de motores de propulsión 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 táctil, ratón o teclado y pueden agrandar las imágenes para mayores niveles de detalle, ya sea navegando por sí mismos o siguiendo caminos previamente definidos. El Commnander EIS permite a la organización hacer el seguimiento de los parámetros de la calidad y factibilidad de las medidas tomadas para cada motor a reacción por tipo de cliente. Los datos aparecen de los sistemas actuales de producción y proporcionan información 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 año fiscal. La administración puede bajar para ver los detalles específicos en cada categoría. El sistema sólo 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 fácil de usar. Los nuevos usuarios son capacitados mediante una demostración 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 ingeniería de software como una actividad de modelado. Los desarrolladores construyen modelos de los dominios de la aplicación y la solución 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 más efectiva los problemas y responder preguntas. El proceso de desarrollo de software también puede verse como un sistema complejo con entradas, salidas, actividades y recursos. Por lo tanto, no es sorprendente que las mismas técnicas 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 análisis y diseño, comienza cuando la administración o algunos miembros del personal encargado de desarrollar sistemas, detectan un sistema de la empresa que necesita mejoras. El método del ciclo de vida para desarrollo de sistemas (SDLC) es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información, véase la figura 1.8. El SDLC es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo específico de actividades del analista y del usuario. Los analistas no están 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 continuación se examinarán 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 están muy relacionadas, en general son inseparables, y quizá sea difícil 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 análisis mientras que otros en etapas avanzadas de diseño.

El método del ciclo de vida para desarrollo de sistemas consta de las siguientes actividades: 1. 2. 3. 4. 5.

Planificación y gestión del proyecto. Determinación de los requerimientos del sistema. Análisis y diseño. Desarrollo de software (programación). Prueba e implementación de los sistemas.

26

Investigació n preliminar

Implantación

Determinación de los requerimientos del sistema Prueba del Sistema

Diseño del sistema

Desarrollo del Sistema

Figura 1.8.- Actividades para desarrollar e implantar un sistema de información

1.2.1 PLANIFICACIÓN Y GESTION DE PROYECTOS

Investigación preliminar En la primera fase del ciclo de vida del desarrollo de sistemas, el analista tiene que ver con la identificación de problemas, oportunidades y objetivos. Esta etapa es crítica 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 demás miembros de la organización, el analista hace resaltar los problemas; frecuentemente estos ya han sido vistos por los demás, y la razón por la cual el analista fue llamado inicialmente para que puedan ser mejoradas por medio del uso de sistemas de información computarizados. El aprovechar las oportunidades puede permitir que la empresa gane un avance competitivo o ponga un estándar de la industria. La identificación de objetivos es también 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 algún aspecto de la aplicación de sistemas de información puede ayudar para que el negocio alcance sus objetivos atacando problemas específicos u oportunidades.

27

La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones; sin importar cuáles sean éstas, el proceso se inicia siempre con la petición de una persona – administradora, empleada o especialista en sistemas. Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigación preliminar. Esta actividad tiene tres partes: aclaración de la solicitud, estudio de factibilidad y aprobación de la solicitud. Aclaración de la solicitud. Muchas solicitudes que provienen de empleados y usuarios no están formuladas de manera clara. Por consiguiente, antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe examinarse para determinar con precisión lo que el solicitante desea. Si éste tiene una buena idea de lo que necesita pero no está seguro cómo expresarlo, entonces bastará con hacer una llamada telefónica. Por otro lado, si el solicitante pide ayuda sin saber qué es lo que está mal o dónde se encuentra el problema, la aclaración del mismo se vuelve más difícil. En cualquier caso, antes de seguir adelante, la solicitud de proyecto debe estar claramente planteada. Estudio de factibilidad. Un resultado importante de la investigación preliminar es la determinación de que el sistema solicitado sea factible. En la investigación preliminar existen tres aspectos relacionados con el estudio de factibilidad: 1. Factibilidad técnica. El trabajo para el proyecto, ¿puede realizarse con el equipo actual, la tecnología existente de software y el personal disponible? Si se necesita nueva tecnología, ¿cuál es la posibilidad de desarrollarla? 2. Factibilidad económica. Al crear el sistema, ¿los beneficios que se obtienen serán suficientes para aceptar los costos?, ¿los costos asociados con la decisión 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 disminución de los posibles beneficios de la aplicación?

El estudio de factibilidad lo lleva a cabo un pequeño equipo de personas (en ocasiones una o dos) que está familiarizado con técnicas de sistemas de información; dicho equipo comprende la parte de la empresa u organización que participará o se verá afectada por el proyecto, y es gente experta en los procesos de análisis y diseño de sistemas. En general, las personas que son responsables de evaluar la factibilidad son analistas capacitados o directivos. Aprobación de la solicitud. No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo 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 común es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, la administración decide qué proyectos son los más importantes y decide el orden del que se llevarán a cabo. Muchas organizaciones desarrollan sus planes para sistemas de información con el mismo cuidado con el que planifican nuevos productos y programas de fabricación o la expansión de sus instalaciones. Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta información se determina dónde 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, sumarización del conocimiento obtenido, estimación del alcance del proyecto y documentación de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definición del problema y la sumarización de los objetivos. Luego los

28

administradores deben tomar una decisión para ver si continúan con el proyecto propuesto. Si el grupo de usuarios no tiene los suficientes fondos en su presupuesto y desea atacar problemas que no están relacionados, o los problemas no requieren un sistema de cómputo, puede ser recomendada una solución manual y el proyecto de sistemas ya no continúa.

1.2.2 DETERMINACIÓN DE REQUERIMIENTOS

Las herramientas utilizadas para definir los requerimientos de información se encuentran: muestreo e investigación de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboración de prototipos. En esta fase el analista está esforzándose por comprender qué información necesitan los usuarios para realizar su trabajo. Se puede ver que varios de los métodos para determinar los requerimientos de información involucran la interacción directa con los usuarios. Esta fase sirve para formar la imagen que el analista tiene de la organización 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 propósitos, y es realizado típicamente por un especialista llamado analista de información (IA). Las personas involucradas en esta fase son los analistas y los usuarios, típicamente 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: quién (las personas que están involucradas), qué (la actividad del negocio), dónde (el ambiente donde se lleva a cabo el trabajo), cuándo (en qué momento) y cómo (de qué manera se desarrollan los procedimientos actuales) del negocio bajo estudio. El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. (Es por esta razón que el proceso de adquirir información se denomina, con frecuencia, investigación 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? ¿Cómo se hace? ¿Con qué frecuencia se presenta? ¿Qué tan grande es el volumen de transacciones o de decisiones? ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? ¿Existe algún problema? Si existe un problema, ¿qué tan serio es? Si existe un problema, ¿cuál 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 información cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organización. Asimismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observación 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 métodos actuales, y deben ser considerados cuando se diseña cualquier sistema nuevo. Sin embargo, si la razón de las operaciones actuales es que “siempre se han hecho así”, el analista puede desear la mejora de los procedimientos. Conforme se reúnen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema, incluyendo la información que deben producir los sistemas junto con características operacionales tales como controles de procesamiento, tiempos de respuesta y métodos de entrada y salida. Al término de esta fase, el analista debe comprender el por qué de las funciones del negocio y tener información completa sobre las personas, objetivos, datos y procedimientos involucrados.

1.2.3 ANÁLISIS Y DISEÑO Análisis del sistema. El analista de sistemas involucra al análisis de las necesidades del sistema. Nuevamente, herramientas y técnicas 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 gráfica 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 alfanuméricos y qué tanto espacio ocupan cuando se imprimen. Durante esta fase el analista de sistemas también analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis de decisiones estructurales: lenguaje estructurado, tablas de decisión y árboles de decisión. No todas las decisiones de la organización son estructuradas, pero todavía 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 decisión. El análisis de las decisiones de criterios múltiples (decisiones en las que deben ser balanceados muchos factores) también parte de esta fase. Se dispone de muchas técnicas para el análisis de decisiones de criterios múltiples, incluyendo el proceso de compromiso y el uso de métodos 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 análisis 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 administración, el analista continúa sobre ese curso. Cada problema de sistema es único y nunca hay una sola solución correcta. La manera en que se formula una solución o recomendación depende de la capacidad y entrenamiento profesional individual de cada analista.

30

Diseño del Sistema. Se usa la información recolectada anteriormente para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de información sean correctos. Además, también se debe proporcionar entradas efectivas para el sistema de información mediante el uso de técnicas para el buen diseño de formas y pantallas. Parte del diseño lógico del sistema de información es diseñar 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, menús en pantalla para elegir comandos del usuario y un ratón para seleccionar opciones. También incluye el diseño de archivos o bases de datos que guardarán la mayor parte de los datos necesarios para los tomadores de decisiones de la organización. Una base de datos bien organizada es la base para todos los sistemas de información. En esta fase, el analista también trabaja con los usuarios para diseñar la salida (ya sea en la pantalla o impresa) que satisfaga sus necesidades de información. El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de desarrollo del software, a la que denominan diseño físico. Se comienza el proceso de diseño identificando los reportes y demás salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisión los datos específicos para cada reporte y salida. Es común que los diseñadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema esté terminado. Lo anterior se efectúa en papel o en la pantalla de una terminal utilizando para ello algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas. El diseño de un sistema también indica los datos de entrada, aquellos que serán calculados y los que deben ser almacenados. Así mismo, se escriben con todo detalle los procedimientos de cálculo y los datos individuales. Se seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnéticas o incluso archivos en papel. Los procedimientos que se escriben indican cómo procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseño representan a éste de muchas maneras (diagramas, tablas y símbolos especiales). La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software; los diseñadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseño. Por último se diseña 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 diseños de entrada y salida, especificaciones de archivos y detalles de procesamiento, y también puede incluir árboles o tablas de decisión, diagramas de flujo de datos, un diagrama de flujo del sistema y los nombres y funciones de cual quiera de las rutinas de código que ya hayan sido escritas.

31

1.2.4 PROGRAMACIÓN

En la programación, el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Algunas de las técnicas estructuradas para el diseño y documentación de software incluyen diagramas estructurados, el método HIPO, diagramas de flujo, diagramas NassiSchneiderman y Warnier-Orr y seudo código. El analista de sistema usa uno o más de estos dispositivos para comunicar al programador lo que necesita ser programado. Los encargados de desarrollar software pueden instalar (o modificar y después instalar) software comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección 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 pequeñas, donde no hay programadores, se pueden contratar servicios externos de programación. Durante esta fase también se trabaja con los usuarios para desarrollar documentación efectiva para el software, incluyendo manuales de procedimientos. La documentación le dice al usuario la manera de usar el software y también qué hacer si suceden problemas con el software. Los programadores también son responsables de la documentación de los programas y de proporcionar una explicación de cómo y por qué ciertos procedimientos se codifican en determinada forma. La documentación es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicación se encuentra instalada. Los programadores tienen un papel principal en esta fase conforme diseñan, 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 diseño o un ensayo del código, explicando las partes complejas del programa a un equipo de otros programadores.

1.2.5 PRUEBAS E IMPLEMENTACIÓN

Antes de que pueda ser usado, el sistema de información 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 después 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 organización 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 más confiable.

32

El mantenimiento del sistema comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de información. 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 sistemáticos 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 mínimo. Implementación del Sistema. En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de información. La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Dentro del entrenamiento a los usuarios para que manejen el sistema, algún entrenamiento es hecho por los proveedores, pero la supervisión del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversión suave del sistema antiguo al nuevo. Este proceso incluye la conversión de archivos de formatos antiguos a nuevos o la construcción de una base de datos, la instalación de equipo y la puesta del nuevo sistema en producción Dependiendo del tamaño de la organización que empleará la aplicación y el riesgo asociado con su uso, puede elegirse comenzar la operación del sistema sólo 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 día para comenzar a emplear el nuevo al día siguiente. Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál 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 años. 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 información deben mantenerse siempre al día. En este sentido, la implantación es un proceso en constante evolución. Debe hacerse notar que a veces los sistemas trabajan en forma cíclica. 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ó código para apoyar determinadas partes del diseño del sistema o aquel diseño fue incompleto. En cualquier caso deben ser modificados los programas, y el analista puede tener que cambiar algunos de los materiales del diseño del sistema. A su vez, esto puede necesitar que el analista se reúna con el usuario y vuelva a investigar cómo funciona una actividad específica del negocio. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones: 1. Evaluación operacional.- Forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

33

2. Impacto organizacional.- Identificación y medición de los beneficios para la organización en áreas tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información interno y externo. 3. Opinión de los administradores.- Evalúa las actitudes de directivos y administradores dentro de la organización así como de los usuarios finales. 4. Desempeño del desarrollo.- Se evalúa el proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo. Desafortunadamente la evaluación de sistemas no siempre recibe la atención que merece. Sin embargo cuando se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes. La importancia del mantenimiento Después 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 instalación MIS típica. 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, también 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 "anomalías 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 razón 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 características adicionales después de que familiarizan con el sistema de cómputo y sus capacidades. Estas características 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 través del tiempo. Se debe modificar el software para abarcar cambios tales como nuevos requerimientos de reportes gubernamentales o corporativos, la necesidad de producir nueva información para clientes, etcétera. 3. El hardware y software están cambiando a un ritmo acelerado. Un sistema que usa tecnología antigua puede ser modificado para usar las capacidades de una tecnología más nueva. Un ejemplo de tal cambio es el reemplazo de una terminal de macro computadora con una estación 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 dólares 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 más conveniente realizar un nuevo estudio del sistema, debido a que el costo de mantenimiento continuado es claramente mayor que la creación de un sistema de información completamente nuevo. Resumiendo, el mantenimiento es un proceso continuo a lo largo del ciclo de vida de un sistema de información. Después de que es instalado el sistema de información, el mantenimiento por lo general toma la forma de corrección 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 eliminación de unos cuantos errores no detectados anteriormente y la actualización del sistema con unas cuantas mejoras menores. Sin embargo, conforme pasa el tiempo y cambia el negocio y la tecnología, los esfuerzos de mantenimiento se incrementan dramáticamente.

35

Cambios mayores en el negocio y en la tecnología

Cantidad de recursos consumidos, tiempo y dinero

Errores posteriores a la instalación

Cambios menores debido a errores y mejoras

Desarrollo de sistemas

Tiempo

Días de instalación 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. ¿Cómo están divididos los sistemas automatizados? 3. Dar cinco ejemplos de sistemas que hayan durado más de un año y que aun existan hoy en día. 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 opinión, no debería automatizarse. ¿Por qué no debería ser automatizado? 7. Dar cinco ejemplo de: a. Sistemas de tiempo real. b. Sistemas en línea. c. Sistema de apoyo a la toma de decisiones. d. Sistema de planeación estratégica. 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 básicos de control en un modelo de sistemas. 10. ¿Cuál es el objetivo del mantenimiento en los sistemas?

36

INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE

2.1 DEFINICIÓN DE INGENIERÍA DE SOFTWARE 2.2 HISTORIA DE LA INGENIERÍA DE SOFTWARE 2.3 CARACTERÍSTICAS DEL SOFTWARE 2.4 MITOS DEL SOFTWARE 2.5 CAPAS DE LA INGENIERÍA DE SOFTWARE 2.6 EL PROCESO DEL SOFTWARE 2.7 SOFTWARE DE ALTA CALIDAD 2.8 FACTORES DE CALIDAD Y PRODUCTIVIDAD

37

2.1 DEFINICIÓN DE INGENIERÍA DE SOFTWARE

Una de las primeras definiciones de ingeniería del software fue la propuesta por Fritz Bauer en la primera conferencia importante NAU69 dedicada al tema: El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales. 2

La definición de la IEEE siguiente: La ingeniería de software se define como la disciplina tecnológica preocupada de la producción sistemática 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 ingeniería de software difiere de la programación tradicional en que se utilizan técnicas de ingeniería para especificar, diseñar, instrumentar, validar y mantener los productos dentro del tiempo y el presupuesto establecidos para el proyecto; además esta ingeniería se preocupa por aspectos administrativos que quedan fuera del dominio normal de la programación. En pequeños proyectos, al emplear uno ó dos programadores durante uno ó dos meses, los detalles más preocupantes sean los técnicos; en proyectos que utilizan más programadores durante mayor tiempo, se requiere de un control administrativo para coordinar todas las actividades técnicas. El término “programador” se emplea para denominar al individuo preocupado por los detalles de la instrumentación, empacado y modificación de los algoritmos y estructura de datos codificados en un lenguaje de programación particular. Los ingenieros de programación están además, ocupados con aspectos como el análisis, el diseño, la verificación y pruebas de programas, la documentación, el mantenimiento y la administración de proyectos; así un ingeniero de programación deberá tener aptitudes y experiencia como programador, para entender las zonas de problemas, metas y objetivos de la ingeniería de software. Algunas veces se ha dicho que los conceptos de la ingeniería de software son aplicables únicamente a proyectos grandes y de larga duración; es cierto que en grandes proyectos son esenciales las prácticas estándar y los procedimientos formales y que algunas notaciones, herramientas y técnicas de la ingeniería de software se han desarrollado para tales casos. Por otro lado un proyecto pequeño; puede ser más sencillo, sin embargo, los principios fundamentales de análisis sistemático, diseño, instrumentación, prueba y modificaciones permanecen constantes, ya sea para un proyecto de una persona y de un mes, o de 1000 personas y 10 años. Los conceptos fundamentales de desarrollo de software y mantenimiento presentados anteriormente son útiles en cualquier proyecto de programación; se emplean algunas técnicas analizadas son costeables sólo en grandes proyectos. Aunque se han propuesto muchas más definiciones generales, todas refuerzan la importancia de una disciplina de ingeniería para el desarrollo del software. Es común darse cuenta que la inversión de una tecnología pueda tener profundos e inesperados en otras tecnologías con las que en apariencia no tiene ninguna relación, como en empresas comerciales, en personas y aún en la cultura en su conjunto. Este fenómeno a menudo se denomina “la ley de las secuencias imprevistas”. En la actualidad el software de computadoras es la tecnología individual más importante en el ámbito mundial. También es uno de los ejemplos principales de la ley de las consecuencias imprevistas. Nadie en la década de los 50´s podría haber predicho que el software se convertiría

38

en una tecnología indispensable en los negocios, en la ciencia y en la ingeniería; tampoco que el software permitiera la creación de nuevas tecnologías(por ejemplo la ingeniería genética), la expansión de tecnología existente(como las telecomunicaciones), el fin de la tecnología antigua(como la industria de la impresión); que el software fuera la fuerza conductora detrás de la evolución detrás de las computadoras personales; que los productos empaquetados de software se pudieran comprar en los centro comerciales; que una compañía de software se volviera muy grande y más influyente que la mayoría de las compañías de la era industrial de la impresión; que una gran red construida con software llamada Internet cubriría y cambiaria todo, desde la investigación bibliográfica hasta las compras de los consumidores y los hábitos diarios de los jóvenes (y no tan jóvenes ).Nadie podría haber previsto que el software estaría relacionado con sistemas de todo tipo: de transporte, médicos, 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 todavía es imposible predecir diario. Por último, nadie podría a ver predicho que millones de programas de computadora tendrían que corregirse, adaptarse y mejorarse conforme pasara el tiempo y que la labor de desarrollar estas actividades de “mantenimiento” absolvería más gente y recursos que todo el trabajo aplicado para la creación del software del nuevo software.

La ingeniería del software surge de la ingeniería de sistemas y de hardware. Abarca un conjunto de tres elementos clave (métodos, herramientas y procedimientos) que facilitan al gestor controlar el proceso del desarrollo del software y suministrar a los que practiquen dicha ingeniería las bases para construir software de alta calidad de una forma productiva. Los métodos de la ingeniería del software indican “como” construir técnicamente el software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los requisitos del sistema y del software, diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos, codificación, prueba y mantenimiento. Los métodos de la ingeniería del software introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de criterios para la calidad del software. Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de los métodos mencionados anteriormente. Cuando se integran las herramientas de forma que la información creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte del desarrollo del software, llamado ingeniería del software asistida por computadora (del inglés, CASE). CASE combina software, hardware y bases de datos sobre ingeniería del software (una estructura de datos que contenga la información relevante sobre el análisis, diseño, codificación y prueba) para crear un entorno de ingeniería del software. Los procedimientos de la ingeniería del software son el pegamento que junta los métodos 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 métodos, 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 ingeniería del software está compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería del software. La elección de un paradigma para la ingeniería del software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y poscontroles y entregas requeridos.

_______________________________ 2

IEEE, siglas de Institute of Electrical and Electronic Engineers, en español es el Instituto de Ingenieros Eléctricos y Electrónicos

39

2.2

HISTORIA DE LA INGENIERÍA DE SOFTWARE

La Ingeniería del Software, se término 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 según Alan Davis como “la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios”. El término empezó a usarse a finales de la década de los 60`s, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. Un factor que ha sido relevante en este desarrollo de tecnologías ha sido el Software, ya que ha facilitado y agilizado varios procesos que ya se manejaban con anterioridad. Además que se ha convertido en una característica primordial que deben tener las organizaciones para poder convertirse en una de las mejores a nivel mundial. A continuación se menciona las eras de la ingeniería de software. PRIMERA ERA Durante los primeros años de la era de la computadora, el software se contemplaba como un añadido. Desde entonces el campo se ha desarrollado tremendamente. La programación de computadoras era un arte de andar por casa para el que existían pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin ninguna planificación, 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 salían con éxito. Los problemas a ser resueltos eran principalmente de una naturaleza técnica, el énfasis estaba en expresar algoritmos conocidos eficazmente en algún lenguaje de programación. En estos primeros años lo normal era que el hardware fuera de propósito general. Por otra parte, el software se diseña a medida para cada aplicación y tenía una distribución relativamente pequeña. El software como producto estaba en su infancia, la mayoría se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, 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 algún error. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien, y la documentación normalmente no existía. A lo largo de los primeros años aprendimos mucho sobre la implementación de sistemas informáticos, pero relativamente poco sobre la ingeniería de las computadoras. Sin embargo, en honor de la verdad, se debe reconocer que durante esa era se desarrollaron muchos sistemas informáticos excepcionales. Algunos de ellos todavía se siguen utilizando hoy y, por sus características, siguen siendo admirados con toda justicia. SEGUNDA ERA Se extienden desde la mitad de la década de los 60s hasta finales de los 70s. La multiprogramación y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre − máquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del hardware y del software. Los sistemas de tiempo real podían recoger, analizar y transformar datos de múltiples fuentes, controlando así los procesos y produciendo

40

salidas en milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en línea condujeron a la primera generación de sistemas de gestión de bases de datos. La segunda era se caracterizó también por el establecimiento del software ya se desarrollaba para tener una amplia distribución en un mercado multidisciplinario. Los programas se distribuían 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 crecía el número de sistemas informáticos, comenzaron a extenderse las bibliotecas de software de computadora. Las casas desarrollaban proyectos en los que se producían 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 tenían 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. Aún peor, la naturaleza personalizada de muchos programas los hacía virtualmente imposibles de mantener. “Había comenzado una crisis del software” TERCERA ERA La tercera era comenzó a mediados de los años 70s y continuó más allá de una década. El sistema distribuido, múltiples computadoras, cada una ejecutando funciones concurrentemente y comunicándose con alguna otra, incrementó notablemente la complejidad de los sistemas informáticos. Las redes de área local y de área global, las comunicaciones digitales de alto ancho de banda y creciente demanda de acceso instantáneo a los datos, supusieron una fuente presión sobre los desarrolladores del software. Aún más, los sistemas y el software que lo permitían continuaron residiendo dentro de la industria y de la academia. El uso personal era extraño. La conclusión 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 automóviles hasta hornos microondas, desde robots industriales a equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más importante que la computadora personal. En menos de una década, las computadoras llegarán a ser fácilmente accesibles al público. CUARTA ERA En esta era, se aleja de las computadoras individuales y da los programas de computadoras, dirigiéndose al impacto colectivo de las computadoras individuales del software. Potentes máquinas personales controladas por sistemas operativos sofisticados, en redes globales y locales, acompañadas por aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas informáticas están cambiando de entornos centralizados de grandes computadoras a entornos descentralizados cliente/servidor. Las redes de información en todo el mundo proporcionan una infraestructura que iguala a expertos y políticos en pensar sobre una súper autopista de información y una conexión 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 economía del mundo. Las decisiones tomadas por gigantes de la industria tales como Microsoft arriesgan billones de dólares. A medida que la cuarta generación progresa, han comenzado a surgir nuevas tecnologías. La tecnología orientadas a objetos está desplazando rápidamente los enfoques de desarrollo de software más convencionales en muchas áreas de aplicaciones. Aunque las predicciones de las computadoras de quinta

41

generación continúan eludiéndonos, las técnicas de cuarta generación para el desarrollo del software están cambiando en forma en que la comunidad del software construye programas informáticos. Los sistemas expertos y el software de inteligencia artificial han salido del laboratorio para entrar en aplicaciones prácticas de una gran variedad de problemas del mundo real. El software de redes neuronales artificiales junto con la aplicación de lógica difusa ha abierto posibilidades excitantes para el reconocimiento de patrones y habilidades de procesamiento de información de carácter humano. La programación de realidad virtual y los sistemas multimedia ofrecen formas radicalmente diferentes de comunicar información al usuario final. Los algoritmos genéricos ofrecen el potencial para el software que reside dentro de las computadoras biológicas masivamente en paralelo. Sin embargo, un conjunto de problemas relacionados con el software ha persistido a través de la evolución de los sistemas basados en computadora, y estos problemas continúan aumentado.

Aportaciones al campo Se ha percatado de los problemas que existión en algún momento respecto a que no se llevaba una planificación para un buen desarrollo del software. Esto trajo consecuencias que repercutieron en las organizaciones. Muchas de estas consecuencias originaron pérdidas millonarias en diferentes empresas como el caso de una Aerolínea Internacional de los Estados Unidos de América, que tuvo el problema de que al momento de que un pasajero pretendía hacer su reservación de vuelo, el sistema de información mostraba que los asientos se encontraban ocupados, mientras que físicamente el vuelo contaba con demasiados asientos libres. Esto origino una pérdida de $50 millones de dólares. A la vez se presentaron casos en los cuales las pérdidas eran iguales o mayores materialmente hablando. Las transacciones financieras de aquél entonces se empezaron a llevar por medio de software especializado, pero también tuvo errores, ya que al enviar facturas de pago, su total de pago presentaba $0.00, lo cual originó bastantes pérdidas. Pero, no sólo existieron pérdidas materiales en los malos desarrollos de software de aquellos días. Una computadora que se usaba para el servicio militar de los Estados Unidos de América, reportó una alarma acerca de la Unión Soviética de Repúblicas Socialistas había iniciado un ataque de proyectiles nucleares en contra de ese país. Esto originó una gran movilización para contrarrestar el ataque, se alistaron a los bombarderos atómicos norteamericanos, pero al día siguiente a través de un periódico se daba la noticia que todo había sido un error en el Software de la computadora. Otra de las consecuencias en donde si hubo pérdidas humanas, fue en un caso en Inglaterra, en donde se enjuiciaba a una mujer de 54 años de edad por asesinar a su hija, esto fue debido a un mensaje de un sistema informatizado hizo de la compañía de seguro social, informaba a la mujer que ella estaba gravemente enferma, se le decía que padecía una forma incurable de sífilis, además de que había infectado a sus dos hijos. En pánico, ella estranguló a su hija de 15 años e intento matar a su hijo de 13, el muchacho escapó y consiguió ayuda para después 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 planeación acerca del desarrollo del software; en aquél entonces el programador no se adentraba hacia las repercusiones que pudiera tener el software que estaba creando, y ante la falta de documentación para la enseñanza de la creación de Software, los programadores aprendían solamente practicando. Actualmente los desarrolladores de Software, al momento de diseñarlo debe de darce cuenta de varias cosas para no tener ese tipo de errores que existieron con anterioridad. Además de otras cosas creemos que entre lo más importante que se debe saber es: ¿Hacia quién va dirigido el SW? ¿Quienes serán los usuarios? ¿Qué tipo de información les ser La facilidad de acceso. Entre muchas otras cosas más. 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 planeación. Sin embargo, no es del todo satisfactorio dejar las cosas simplemente en las etapas de planeación. Después de que los programas estén terminados deben recibir mantenimiento, y los esfuerzos de mantenimiento normalmente sobrepasan el esfuerzo gastado en el diseño y programación original. Parte importante de este aspecto es la documentación, se deben documentar el software y los procedimientos para que estén codificados en un formato que pueda ser fácilmente accesado. La documentación permite que los usuarios, programadores y analistas observen el sistema, software y procedimientos sin tener que interactuar con él. Después de ver todos los avances se puede observar que no sólo se cambia una manera de trabajar, sino que se cambia la forma de conceptualizar la vida, ¿Quién vive ya sin la ayuda de una computadora que agilice procesos?, y en caso drástico podemos ver que se cambian las costumbres y cultura de la sociedad actual. A manera de conclusión, se finaliza con una semblanza ágil y rápida que permitirá observar los aspectos más relevantes que a un juicio han marcado con hechos la evolución del software. Es de suma relevancia el mencionar algunas de los lenguajes de programación que fueron utilizados en sus respectivas eras (Tabla 2.1). Esto nos ayudará a comprender mejor el objetivo que se perseguía en cada una de ellas.

43

40 30 20 10

Se trabajaba con la idea de Codificar y Corregir. No existía un planteamiento previo. No existía documentación de ningún tipo. Existencia de pocos métodos formales y pocos creyentes en ellos. Desarrollo a base de prueba y error.

1950

Nuevo Concepto: Sistemas Distribuidos.

Simplificar código. Multiprogramación y Sistemas Multiusuario. Sistemas de Tiempo Real apoyan la toma de decisiones. Aparición de Software como producto. (Casas de Software). Inicio de la crisis del software Se buscan procedimientos para el desarrollo del Software.

1960

Impacto Colectivo de Software. Aparecen: Redes de Información, Tecnologías Orientadas a Objetos. Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia Artificial. La información como valor preponderante dentro de las Organizaciones.

Complejidad en los Sistemas de Información. Aparecen: Redes de área local y global, y Comunicadores Digitales. Amplio Uso de Microprocesadores.

1972

1989

¿?

Figura 2.1.- Eras de la historia de la Ingeniería de software

ERA

10

20

LENGUAJES

CARACTERÍSTICAS

Fortran Basic Logo Cobol

Fue el primer y principal lenguaje Científico. Diseñado por IBM. Utilizado también para aplicaciones comerciales. Desarrollado como lenguaje de tiempo compartido. Traza elementos gráficos estableciendo la geometría de lápiz. Ampliamente usado en programación en minicomputadores.

Pascal Prolog Mumps Lisp

Lenguaje Académico. Sus características son copiadas por otros lenguajes. Éxito comercial a través de Borland. Desarrollado en Francia, 1973. Aplicaciones en Inteligencia Artificial (IA). Sistema de Multiprogramación. Incluye su propia base de datos.

44

30

C, C++ Modula−2 dBase

40

Visual C++ Visual Basic

Utilizado en aplicaciones médicas. Sintaxis muy diferente de los demás lenguajes. Programa aplicaciones en IA. Desarrollado en los ochentas. Se utiliza en aplicaciones comerciales. C++, se utiliza para la tecnología orientada a objetos. Versión mejorada de Pascal. Desarrollada en 1979. Lenguaje estándar para aplicaciones comerciales. Ramas colaterales: Clipper, FoxBase. Desarrollado por Microsoft. Principalmente orientado a la tecnología de objetos. Principalmente para aplicaciones comerciales. Versión cotizada, ya que permite interactuar con tablas de manejadores de bases de datos y lenguaje SQL.

Tabla 2.1.- Lenguajes utilizados en cada era de la historia de la Ingeniería de software.

En estos días 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 organización, pero ésa no es la idea general, ya que los muchos analistas son de la opinión 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 están terminadas, y aunque la nueva plataforma ofrezca características modernas y sencillas, utilizarlas dependerá si Microsoft logra que los principales negocios acepten cambiar a esta nueva forma de crear soluciones. A continuación se presenta una lista de algunas personas que hicieron contribuciones significativas en la creación y crecimiento de la industria de productos de software Charles Bachman. Inventó la tecnología del banco de datos en los inicios de los sesentas. John Backus. FORTRAN desarrollado para IBM (1954) · Bob Bemer. Uno de los diseñadores de COBOL y el ASCII normal para IBM (años sesenta); inventor de la sucesión 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 investigación de mercado para enfocar el software y comienza a comercializar los productos del software en 1974. Tom DeMarco. El pionero en utilizar una metodología de caso, el autor, y consultor en los años setenta. Wilfred J. Dixon. Empezó distribuyendo el software estadístico 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 metodología de caso desarrollada en los años setenta. · La mayoría de estas personas nombradas, trabajaron sobre algún aspecto del Software con el que aún 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 fisonomías del Software con el que actualmente se trabaja.

46

2.3 CARACTERÍSTICAS DEL SOFTWARE

La diferencia entre el software y otras cosas que construye el ser humano, es que el software es un elemento lógico, en lugar de físico, de un sistema. Por lo tanto el software tiene características muy diferentes a las del hardware: 1. El software se desarrolla o construye; no se manufactura en el sentido clásico.- Aunque existen algunas similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre la gente dedicada y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construcción de un “producto”, pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería; esto significa que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.

o

l

l

a

f

e

d

e

c

“Mortalidad

i

d

n

Í

2. El software no se desgasta.- La figura 2.3 describe, para el hardware, la proporción de fallos como una función del tiempo. Esa relación, denominada frecuentemente “curva de bañera”, indica que el hardware exhibe relativamente muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a defectos del diseño o de la fabricación); 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 vibración, los malos tratos, las temperaturas extremas y muchos otros males externos. Sencillamente, el hardware comienza a estropearse.

“Desgaste”

infantil”

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 teoría, la curva de fallos para el software tendría la forma que muestra la figura 2.3. Los defectos no detectados harán 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 simplificación de los modelos reales de fallos del software. Sin embargo, la implicación es clara el software no se estropea. ¡Pero se deteriora!

Índice de fallos

Esto, que parece una contradicción, 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 mínimo de fallos comienza a crecer; el software se va deteriorando debido a los cambios.

Continúa el mismo nivel hasta estar obsoleto

Tiempo Figura 2.3 Curva de fallos del software (idealizada)

Índice de fallos

Curva real

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 diseño o en el proceso mediante el que se tradujo el diseño a código máquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware. 3. La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. Consideremos la forma en la que se diseña y se construye el hardware de control para un producto basado en microprocesador. El ingeniero de diseño construye un sencillo esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se realiza la función adecuada y va al catálogo de ventas de componentes digitales existentes. Cada circuito integrado (frecuentemente llamado un “CI” o “pastilla”) tiene un número de pieza, una función definida y válida, una interfaz bien definida y un conjunto estándar de criterios de integración. Después de seleccionar cada componente, puede solicitarse la compra. Por desgracia, los diseñadores del software no disponen de esa comodidad que acabamos de describir. Con unas pocas excepciones, no existen catálogos 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 mitología que surge durante los primeros años del desarrollo del software. A diferencia de los mitos antiguos, que ofrecían a los hombres lecciones dignas de tener en cuenta, los mitos del software propagaron información errónea y confusión. 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 día”. Hoy, la mayoría de los profesionales competentes consideran a los mitos por lo que son actitudes erróneas que han causado varios problemas, tanto a los gestores como a los técnicos. Sin embargo, las viejas actitudes y hábitos son difíciles de modificar y, cuando vamos hacia la quinta década del software, todavía se cree en algunos restos de los mitos del software.

MITOS DE GESTIÓN Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Igual que se agarra al vacío una persona que se ahoga, un gestor de software se agarra frecuentemente a un mito del software, aunque tal creencia sólo disminuya la presión temporalmente. Mito. Tenemos ya un libro que está lleno de estándares 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 prácticas 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 más avanzadas; después de todo, les compramos las computadoras más nuevas. Realidad. Se necesita mucho más que el último modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE), aunque la mayoría todavía no se usen, son más importantes que el hardware para conseguir buena calidad y productividad. Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido (el llamado algunas veces “concepto de la horda mongoliana”). Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. En palabras de Brooks “….añadir gente a un proyecto de software retrasado lo retrasa aún más”. Al principio, esta declaración puede parecer un contrasentido. Sin embargo, cuando se añaden 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 añadirse gente, pero sólo de una manera planificada y bien coordinada.

50

MITOS DEL CLIENTE Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía 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 información. Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el que desarrolla el software. Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas, podemos dar los detalles más adelante. Realidad. Una mala definición inicial es la principal causa del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista. Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio varía según el momento en que se introduzca. La figura 2.5 ilustra el impacto de los cambios. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el coste.

1 x Definición Mantenimiento

o

i

b

m

a

c

l

e

d

e

t

s

o

C

Cuando los cambios se solicitan durante el diseño del software, el impacto en el coste crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un esqueleto del diseño. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseño; es decir, coste adicional. Los cambios en la función, rendimiento, interfaces u otras características, durante la implementación (codificación 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 más caro que el mismo cambio pedido al principio.

1 ,

Desarrollo

5

Figura 2.5.- Impacto del cambio. 6 x

6 0 1 0 0 x

51

MITOS DE LOS DESARROLLADORES

Los Mitos en los que aún creen muchos desarrolladores se han ido fomentando durante cuatro décadas de cultura informática. Como ya se indicó anteriormente, durante los primeros días del desarrollo de software, la programación se veía 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 más pronto se comience a escribir código, más 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á después de que se le haya entregado al cliente por primera vez. Mito. Hasta que no tengo el programa “ejecutándose”, realmente no tengo forma de comprobar su calidad. Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software – la revisión técnica formal. La revisión del software es un “filtro de calidad” que se ha comprobado que es más 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 sólo una parte de una configuración del software que incluye todos los elementos que se muestran en la figura 2.6. La documentación es la base de un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software. Muchos profesionales del software reconocen la falsedad de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para el desarrollo del mismo.

Estructuras de datos

Programa Operativo Plan

Especificación

L

Diseño

i

de requisitos

s t Especificación de la prueba

a d o

Figura 2.7.-Configuración del software.

52

2.5 CAPAS DE LA INGENIERÍA DE SOFTWARE

La ingeniería de software es una unión de capas que debe estar sustentado en un compromiso con la calidad. La gestión de calidad total, la metodología 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 ingeniería de software. La base que soporta dicha ingeniería es un enfoque en la calidad. El proceso de la ingeniería de software es el elemento que mantiene juntos los estratos de la tecnología 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 tecnología y forma la base para el control de la gestión de los proyectos de software y establecer el contexto en el cual se aplica los métodos técnicos, se generan los productos del trabajo (modelo, documentos, datos, reportes, formatos, etcétera), se establecen los fundamentos, se aseguran la calidad, y el cambio se maneja de manera apropiada. Las herramientas de la ingeniería de software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos.

Herramientas Métodos Proceso Enfoque de Calidad

Figura 2.7.- Capas de la Ingeniería de Software.

CAPA DE CALIDAD Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería 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 gestión de proyectos de software y establecen el contexto en el cual; se aplican los métodos técnicos, se producen resultados de trabajo, se establecen métodos, se asegura la calidad y el cambio se gestiona adecuadamente.

CAPA DE MÉTODOS Los métodos construye técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

CAPA DE HERRAMIENTAS Proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas de la Ingeniería en Computación Software Asistida (CASE). Para resolver los problemas reales de una empresa, el equipo de ingenieros de SW debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y herramientas. Esta estrategia a menudo se llama Modelo de Proceso y se selecciona un modelo de proceso según: La naturaleza del proyecto. La aplicación que se necesite. Los Métodos 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 propósito la producción eficaz y eficiente de un producto software que reúna 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 ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un producto software en sí es complejo, es prácticamente inviable conseguir un 100 porciento de confiabilidad de un programa por pequeño que sea; existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución 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 definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos de software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no solo después de entregado un producto sino también 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 difícil automatizar todo un proceso de desarrollo de software. Contiene tres fases genéricas, independientemente del paradigma de ingeniería que se encuentran en todos los desarrollos de software, independientemente del área de aplicación, del tamaño del proyecto o de la complejidad:

1. Definición.- Se centra sobre el qué, el que desarrolla el software intenta identificar qué información ha de ser procesada, que función y rendimiento se desea, qué interfaces han de establecerse, que restricciones de diseño existen y qué criterios de validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del software aplicado (o combinación de paradigmas), de alguna forma se producirán tres pasos específicos: a) Análisis del sistema. El análisis del sistema define el papel de cada elemento de un sistema informático, asignando finalmente al software el papel que va a desempeñar. b) Planificación 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) Análisis de requisitos. El ámbito establecido para el software proporciona la dirección a seguir, pero antes de comenzar a trabajar es necesario disponer de una información más detallada del ámbito de información y de función del software. 2. Desarrollo.- Se centra en el cómo, el que se desarrolla el software intenta descubrir cómo han de diseñarse las estructuras de datos y la arquitectura del software, cómo han de implementarse los detalles procedimentales, cómo ha de traducirse el diseño a un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos

55

aplicados durante la fase de desarrollo variarán, pero de alguna forma se producirán tres pasos concretos: a) Diseño del software. El diseño traduce los requisitos del software a un conjunto de representaciones (algunas gráficas y otras tabulares o basadas en lenguajes) que describen la estructura de los datos, la arquitectura, el procedimiento algorítmico y las características de la interfaz. b) Codificación. Las representaciones del diseño deben ser traducidas a un lenguaje artificial (un lenguaje de programación 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 codificación es el que lleva a cabo esa traducción. c) Prueba del software. Una vez que el software ha sido implementado en una forma ejecutable por la máquina, debe ser probado para descubrir los defectos que puedan existir en la función, en la lógica y en la implementación.

3. Mantenimiento.- Se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas por la evolución 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 definición y de desarrollo, pero en el contexto del software ya existente. Durante la fase de mantenimiento se encuentran tres tipos de cambios: a) Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. b) Adaptación. Con el paso del tiempo es probable que cambie el entorno original (por ejemplo, la UCP, el sistema operativo, los periféricos) 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 podría interesar que estuvieran incorporadas en el software. El mantenimiento perfectivo amplia el software más allá de sus requisitos funcionales originales.

Además de estas actividades de mantenimiento básico, se está forzando a algunas empresas a considerar la ingeniería inversa. Mediante un conjunto de herramientas CASE especializadas se hace ingeniería a la inversa con el software para entender y mejorar su funcionamiento interno. Las fases y sus pasos relacionados descritos en la visión genérica de la ingeniería del software, se complementan con varias actividades “protectoras”; las revisiones que se realizan durante cada paso para asegurar que se mantiene la calidad. La documentación que se desarrolla y controla para asegurar que toda la información 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. Además, 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 ingeniería 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 Acción de la ingeniería de software #1.1 Tareas del trabajo

Conjunto de Producto del trabajo Puntos de aseguramiento Tareas de calidad . Fundamentos del proyecto . Acción de la SW #1.k Conjunto de Tareas

Tareas del trabajo Producto del trabajo Puntos de aseguramiento de calidad Fundamentos del proyecto

. . . Actividades del marco de trabajo #n Acción de la ingeniería 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 Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

57

Prácticas y principios Actividades

Personas

Herramientas

Proceso SW

Roles

Artefactos

Notación

Figura 2.9.- Relación 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: Quién: Las personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos. Qué: Un artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones. Cómo y Cuándo: 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 terminación de ciertos Artefactos. La composición y sincronía de las actividades está basada en un conjunto de principios y prácticas. Las prácticas 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 definición de la norma ISO- 900 de la Organización Internacional para la Estandarización (ISO, siglas de International Organización for Standardization), la calidad de software es el grado (pobre, bueno o excelente) en que un conjunto de características 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 medición y predicción de eventos, permite controlar en buena medida la producción de software y, en consecuencia, producir software de calidad. Los factores que más afectan la obtención 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 producción 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 relación, que afecta tanto a la ingeniería del producto como a la organización, la cual debe establecer estándares para los procesos de desarrollo y evaluación, empleado medidas bien establecidas, que permitan mejorar continuas de los productos. La evaluación de los procesos evita especificaciones incompletas o anomalías, la aplicación incorrecta de metodología, etc. Con el ejemplo de evaluar la calidad de los procesos de software, se define el concepto de modelo de madurez del proceso de producción de software, que son modelos que apoyan no solo la mejora continua de los procesos de desarrollo de software, sino que también la estandarización de la producción en toda la organización. Dada la importancia de los procesos, existen diversas certificaciones basadas en los modelos de madurez de proceso que evalúan que las empresas “digan lo que hacen”. La razón adicional para estas certificaciones es que los modelos a menudo requieren cambios en la cultura de la organización y una fuente inversión en cursos, como son los financieros, tecnológicos y humanos. En la tabla 2.2 se muestra un cronograma de algunos estándares y modelos más importantes para la calidad de software. AÑO 2000 1999 1998 1997 1996 1995

DESCRIPCCION ISO 9000-2000 SEI CMMI V1.02 PEMM V1.0 ISO 15504(SPICE)(lanzamiento al público como Reporte Técnico “tipo 2” TickIT V4.0 ISO 9000-3(nuevo lanzamiento) SEI para las versiones de SW- CMM apoyado a CMM Integración (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 estándares y modelos para la calidad del software.

El modelo más importante en la actualidad para la evaluación de la madurez de los procesos de desarrollo es el modelo de madurez de capacidades (CMM) del , Instituto de Ingeniería de Software (SEI). CMM tiene como objetivo evaluar los procesos en sus niveles de madurez e identificar los niveles que una organización debe formar para establecer una cultura de excelencia en la ingeniería 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 guías para organizaciones de software que requieren incrementar su capacidad de procesos, considera los siguientes pasos: Identificar fortalezas y debilidades en la organización. 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 organización a través de una guía. Los procesos se evalúan 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

continúa Procesos predecibles

Procesos estandarizados

Administrado

Definido

Repetible

Procesos disciplinados

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

NIVEL 1 INICIAL 2 REPETIBLE

3

DEFINIDO

4 ADMINISTRADO 5

OPTIMIZADO

LOS CINCO NIVELES DEL MODELO CMM CARACTERISTICAS TRANSICION AL SIGUIENTE NIVEL Ad hoc, poca formación, Inicia una administración 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 estadístico Introducir métodos y tecnologías de ingeniería de software. Establece un conjunto básico de administraciones del proceso para Se cuenta con una base para identificar la calidad y costos de los un progreso mayor o continuo. parámetros, 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 administración. Mejoras sustanciales en la Apoya la recopilación automática 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 también 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 capacitación e instrumentación. PSP resalto la medida personal al profesional de la planeación, también hace responsables al profesional de la planeación del proyecto y la calidad de todos los productos. Existen 5 actividades de marco de trabajo que son: 1. Planeación: Aquí se selecciona los requisitos y se desarrolla el tamaño y la estimación 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. Diseño de alto nivel: Se analizan los factores externos y se construyen prototipos cuando hay incertidumbre. 3. Revisión del diseño de alto nivel: Se aplican los métodos de verificación a los errores que se descubrieron en el diseño. 4. Desarrollo: Se refina, se revisa el diseño, se verifica el código y se compila, además todas las mediciones se guardan para los resultados de trabajo. 5. Análisis 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 difícil, pero no imposible, medida. Existen una serie de factores que influyen 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 aplicación. 2. La comunicación 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 aplicación a desarrollar y es de difícil estimación, ya que muchas veces hasta la fase de desarrollo no es posible comprender en toda su perspectiva las complicaciones que conlleva su realización. 4. Utilización de una notación adecuada.- Este factor es de gran importancia para facilitar la comunicación entre las partes involucradas (incluido el usuario).

62

5. Empleo de métodos sistemáticos.- Es importante que se empleen técnicas que sean de amplio consenso y bien conocidas por los integrantes del equipo de desarrollo de la aplicación. También es fundamental que estas técnicas se empleen de manera sistemática sobre todas las aplicaciones de características semejantes con objeto de facilitar el análisis de coste y tiempo, y también 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 básico conocer el tiempo que puede aportar cada miembro del equipo y en que plazos, sobre todo en función 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 (automáticas o no) que faciliten las labores de desarrollo e integración de la aplicación. En mayor medida cuando se conocen aplicaciones parecidas de fácil trasportabilidad y modificación que puedan servir de base a la que hay que realizar. Como en el resto de las actividades industriales, en el desarrollo de software, también es importante realizar una buena planificación del trabajo y una buena asignación de recursos a los distintos miembros del equipo. Una mala planificación termina con una mala aplicación o una aplicación 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 más de cien años, años bisiestos que tienen un impacto en las fechas de caducidad). En otros casos los desarrolladores no anticiparon que el usuario haría mal uso del sistema (la opresión de un botón, la exploración de las facilidades de depuración del envió de correo). En otros casos las fallas del sistema resultaron por fallas de administración (entrega tardía y con presupuesto excedido, entrega a tiempo de un sistema incorrecto, complejidad innecesaria). Los sistemas de software son creaciones complejas: realizan muchas funciones, están 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 años y, por último, los sistemas complejos son difíciles de comprender por completo para una sola persona. Muchos sistemas son tan difíciles 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 están 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 comprensión de la aplicación. Si el proyecto dura muchos años, la rotación de personal es alta y requiere entrenamiento constante. El tiempo entre los cambios tecnológicos con frecuencia es más corto que la duración del proyecto. La suposición 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. ¿Cuál es el propósito del modelado? 2. Un lenguaje de programación es una notación para la representación de algoritmos y estructuras de datos. Liste dos ventajas y dos desventajas del uso de un lenguaje de programación como notación única a lo largo del proceso de desarrollo. 3. Considere una tarea con la que no esté familiarizado, como el diseño de un automóvil con cero emisiones de contaminantes. ¿Cómo podría atacar el problema? 4. ¿Qué significa “la adquisición de conocimiento no es lineal”? Proporcione un ejemplo concreto de adquisición de conocimiento que ilustre esto. 5. Plantee una fundamentación hipotética para las siguientes decisiones de diseño: 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 botón de cancelación para abortar la transacción”. 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 fácil de usar”. 7. Especifique cuales de las siguientes decisiones se tomaron durante el levantamiento de requerimiento o durante el diseño 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 comunicación con la computadora central”. b. “El distribuidor de boletos usara chips de procesador PowerPC”: c. “El distribuidor de boletos proporciona ayuda en línea al viajero”. 8. ¿Cuál es la diferencia entre una tarea y una actividad? Un avión 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 versión de Word para Windows, un procesador de palabras lanzado por Microsoft en noviembre de 1989, requirió 55 años hombre, dando como resultado 249,000 líneas de código fuente y fue entregado con 4 años 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 opinión, las diferencias entre el desarrollo de un avión, un puente y un procesador de palabras que pueden causar esta situación.

64

PARADIGMAS DE LA INGENIERÍA DE SOFTWARE

3.1 El Enfoque Estructurado 3.1.1 Diagramas de Flujos de Datos 3.1.2 Diccionarios de Datos 3.1.3 Diseño de Módulos 3.1.4 Descomposición en Procesos

3.2 El Enfoque Orientado a Objetos 3.2.1 Análisis Objetos 3.2.2 Diseño Objetos

65

3.1 EL ENFOQUE ESTRUCTURADO

Definiciones de análisis estructurado: El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se establece cómo se cumplirán los requerimientos o la forma en que implantará la aplicación. Más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.) Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado. El análisis estructurado es un método para el análisis 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 lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente. Significado de “estructurado” ¿Qué es lo que se desea estructurar? ¿Qué significa “estructura”? El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. A partir de aquí se determinan los requerimientos que serán la base de un sistema nuevo o modificado. En el análisis estructurado, la palabra estructura significa que:

1. El método intenta estructurar el proceso de determinación de los requerimientos comenzado con la documentación 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 fácil verificar cuándo se han omitido detalles relevantes 4. La identificación 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 comunicación eficientes.

La capacidad del analista de sistemas para captar el flujo de la información se facilita debido al uso de los métodos de análisis y de diseño estructurado. Existen varios métodos para realizar el análisis 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 gráficamente el flujo de datos dentro del sistema empresarial. En su estado original, los DFD presentan una visión, lo más 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 información de los usuarios, se debe ser capaz de interpretar la manera en que los datos fluyen a través de la organización, los procesos o transformaciones que sufren tales datos y sus tipos de salidas. Se agrupan en un esquema gráfico, los movimientos del flujo de los datos a lo largo de la organización, mediante el uso de DFD. El enfoque de flujo de datos enfatiza la lógica que sustenta al sistema, por medio de sólo cuatro símbolos, se debe crear una descripción pictórica de la información, que eventualmente proporcionará una documentación sólida del sistema. El enfoque del flujo de datos, tiene tres ventajas principales a la explicación narrativa, sobre la manera en que la información fluye a través del sistema. Tales ventajas son: 1. La libertad de contar con rapidez con una implantación técnica del sistema. 2. La comprensión adicional de la relación existente entre los sistemas y los subsistemas. 3. La comunicación 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 sólo cuatro símbolos. Porque, aunque el analista especifica que los datos se almacenarán 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 realización. Además 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 aplicación interesante reside en mostrarle al usuario una representación incompleta de la visión que el analista tiene del sistema. Luego se les pediría a los usuarios que presentaran sus comentarios sobre la precisión de la conceptuación del analista, y que éste incorporara los cambios que reflejen con mayor precisión las perspectivas del sistema por parte del usuario.

Para representar el flujo en un DFD se utilizan cuatro símbolos básicos, que son: un cuadro doble, una flecha, un rectángulo con esquinas redondeadas y un rectángulo 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 gráficamente con la combinación de estos cuatro elementos.

67

Entidad

Flujo de datos

Proceso

Almacén de datos

Figura 3.1.- Símbolos básicos del diagrama de flujo.

El cuadrado doble representa una entidad externa (una empresa, una persona o una máquina) que da y recibe datos del sistema. A esta entidad externa se le denomina también como fuente o destino de los datos y tiene una connotación 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 límite del sistema. La flecha representa el movimiento de datos de un punto hacia otro, donde la punta señala el destino de los datos. El flujo de información que ocurre de manera simultánea puede representarse por medio de dos flechas paralelas. Un rectángulo con sus esquinas redondeadas indicar la existencia de un proceso de transformación. Los procesos siempre denotan un cambio o transformación de los datos, y es por ello que el flujo de información que sale, siempre tendrá un nombre diferente al que hubiera tenido al entrar. El rectángulo abierto representa el almacenamiento de la información en los DFD el tipo de almacenamiento físico (esto es, cinta, diskette, etc.) no se especifica. En este punto, el símbolo de almacenamiento de datos, simplemente indica un depósito de datos, el cual permite la adición y acceso de los datos. En la figura 3.2 puede observarse la manera en que los DFD comienzan con el enfoque más 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

Flujo de

DE

Datos 1

1 Proceso 1

DATOS

D1

2

Flujo de

Proceso

Datos 5

Flujo de Datos 3

DESTINOF DE l DATOS u

2 Flujo de

Flujo de

Datos 2

Datos 4

ALMACEN DE DATOS 1

D2

j o

d

ALMACEN DE DATOS 2

e D NIVEL 1 DEL DIAGRAMA DE FLUJO DE DATOS

a t o

Proceso 2 (particionado)

s 2.1

1 Flujo de

Proceso

Datos 3

1

Sub-

Flujo de

Proceso

Datos 5

DESTINO DE

5

DATOS

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

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 médicos y cirujanos, con especialidades en ojos, oídos, nariz y garganta se asociaron para colaborar como un grupo. Piensan que si trabajan en colaboración seis de ellos, podrán cubrir la ausencia de un doctor sin interrumpir el tratamiento del paciente. También intentan alcanzar cierta economía de escala por medio de la centralización de funciones comunes, tales como la facturación, la programación de las citas, el pago de gastos indirectos por áreas de oficinas y el pago de seguros y suministros.

69

Los médicos contrataron a un analista de sistemas para establecer la manera de obtener ventajas de los posibles beneficios de agrupar sus oficinas. Después de entrevistar a los doctores y a sus dos recepcionistas y recopilar ciertas formas representativas que utilizan los médicos, 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.- Igualación del diagrama del flujo Nivel 0 y el de contexto.

La figura 3.4 es un DFD de nivel cero del sistema de facturación de los médicos. Se puede observar que es un DFD que ilustra el movimiento de los datos a lo largo del sistema de facturación, comenzando en la parte superior izquierda y dirigiéndose hacia abajo y a la derecha. Comienza con la entidad externa MEDICOS, quienes, después 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 almacén de datos denominado TARIFAS, el cual tiene la tarifa para el cobro de los servicios médicos. 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 catálogo 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 almacén de datos llamado REGISTRO DE PACIENTES se consulta con el fin exclusivo de obtener la dirección de algún 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 almacén de datos COMPAÑIAS DE SEGUROS. Un nuevo flujo de datos DIRECCIÓN 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 líneas 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 almacén 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 envía al almacén de datos CUENTAS POR COBRAR. Observe que la implantación física del sistema no se cubre a propósito, 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 serían automatizados o manuales. Además, observe que la lógica para el cálculo de las tarifas y los procesos no se documenta con los DFD; sin embargo, más adelante, el analista tendrá que definir tal lógica. Aunque una visión general del sistema es un buen comienzo, se requiriere de más 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 visión 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 cómo será realizado. En esta etapa del análisis, no es apropiado especificar el cómo. Mientras que las entradas y las salidas básicas siguen siendo las mismas, el número de procesos se expande para revelar una mayor complejidad del sistema. Como se imaginará, los diagramas de flujo de datos pueden descomponerse aún más y dar una imagen muy detallada del flujo de la información.

71

PACIENTES

MEDICOS

Registro del examen

Forma de seguros llenada

Factura para el seguro

Tarifas 1

2

válidas de Datos 5

Verificar el registro del examen y calcular las tarifas

Preparar las facturas

Dirección del paciente

CORREDORE S DE SEGUROS

PACIENTES Factura del paciente

Pago del corredor de seguros

Tarifas aplicables Pago del paciente D1

CATALOGO DE TARIFAS

P l

D2 REGISTRO DEL PACIENTE

a n3

D3

COMPAÑIAS DE SEGUROS

Verificar el pago de d los pacientes e

Pago correcto del paciente

s

4

Verificar el pago del corredor de seguros

e g u r

Pago correcto del corredor de seguros

o D4

s

CUENTAS POR COBRAR

y

d i el analista de sistemas para un Figura 3.4.- Diagrama de flujo de datos de nivel 0 desarrollado por sistema médico de facturación.r e c c i ó n

72

2

PREPARAR FACTURAS

PACIENTES

Forma de seguros llenada Datos 5

Tarifas válidas

D3

1

2.1

Verificar el registro del examen y calcular las tarifas

Verificar si el paciente está asegura do

COMPAÑIAS DE SEGUROS

Plan de seguros y dirección

D2

Información sobre seguros y tarifas 2.2 Comparar la cuenta con la cantidad estableci da

Factura para el seguro CORREDORES DE SEGUROS

Cantidad del paciente

REGISTRO DEL PACIENTE

Dirección del paciente

2.3 Calcular el remanent e de la cuenta del paciente

Factura del paciente PACIENTES

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 sistemática. La figura 3.6 resume los pasos involucrados en la elaboración 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 límites del sistema que desarrolla. b) Dibuje un diagrama de flujo de datos básico que ilustre exclusivamente los aspectos generales.

2. Cubra los detalles. a) Por pasos añada más detalle a cada proceso. b) Indique excepciones cuando éstas se requieran

3. Dibuje de nuevo los diagramas y vuelva a definir todos los símbolos 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 narración del sistema organizacional, haciendo uso de cuatro categorías: entidad externa, flujo de datos, proceso y almacén de datos. Esta lista, en su momento, permitirá determinar los límites del sistema que se describe. Tan pronto se compile la lista básica de los datos elementales, puede inicializar la elaboración del diagrama de contexto. El primer diagrama, de nivel cero, debe tener una visión que incluya lo básico de las entradas, los procesos y las salidas. Es la concepción más 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 “descomposición 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 descomposición de los flujos de datos ya que se perdería tiempo y se sacrificaría comprensión 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 omisión.

Mejoras de la comunicación a través 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 lógica del recorrido de los datos a través del diagrama de flujo de datos; sin embargo, si se desea que los diagramas sean un verdadero elemento de comunicación, deberán incorporarse leyendas significativas para todos los datos. Los rótulos no deben ser muy genéricos pues dirán poco de la situación particular. Todos los modelos generales de sistemas se apegan a la configuración de entrada, proceso y salida. De tal forma que los rótulos de los DFD deben ser más específicos que esto último. Cada vez que sea posible se debe unificar los términos de tal forma que sólo se tengan unos cuántos términos para el mismo dato. Parte de la efectividad de los DFD se debe a que mantienen su consistencia de página a página (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 análisis y diseño de procesos, desde el principio se debe utilizar DFD sin detallar para establecer los requisitos de información. En esta etapa pueden ser útiles para obtener una visión 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 interacción adicional con los usuarios. En esta etapa, el DFD está mostrando su particular concepción de las corrientes de datos del negocio. Se enseñara a los usuarios claves, las convenciones que utilice en los DFD, y luego realice los niveles consecutivos. Pedir opinión sobre todo de aquello que pudiera aclarar el proceso o permitiera lograr una mayor precisión en los diagramas. Después, incorporar las modificaciones de los usuarios; y luego, tanto el grupo de análisis como los usuarios deberán aprobar los DFD como un reflejo preciso del flujo de datos de la organización. Finalmente, los DFD sirven para documentar al sistema. Pueden utilizarse para documentar niveles superiores e inferiores del análisis. Los DFD auxilian de manera sustancial a concebir la lógica de los flujos de datos de la organización.

75

En la actualidad se cuenta con excelentes apoyos que evitan el tedio y la impresión asociada al dibujo manual de los diagramas de flujo de datos. Esto forma parte de lo que se denomina tecnologías 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 análisis y el diseño. Como documento, recopila, coordina y confirma lo que un término específico significa para la gente de la organización. 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 había sido implantado en todos los programas que comparten el dato actualizado. También 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 cómo llegará a utilizarse. Es el elemento básico de referencia para localizar los nombres y atributos de los datos utilizados en todo el sistema de la organización. Por esto es que deberá incluir todos los datos sencillos; sin embargo, conviene visualizar como evolutiva a la documentación. Mientras que un diccionario de datos pueda incluir numerosos elementos, nunca estará concluido. De hecho, deberá actualizarse cada vez que se hagan cambios, como ocurriría para cualquier otro tipo de documentación. Con el fin de ser de utilidad, los registros del diccionario de datos deben contener información referente a las categorías siguientes: 1. El nombre y el sinónimo del dato (“alias”).- Contiene el nombre de cada dato; esto es, la manera de denominar el dato en la mayoría 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 más común del dato, así como el sinónimo. Todo esto debe quedar registrado en el diccionario de datos, para facilitar la comunicación y la referencia cruzada entre los departamentos y sus programas. 2. Las descripciones del dato.- La descripción 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 término. 4. El rango permitido del dato.- Junto con el nombre, el sinónimo y la descripción de cada dato elemental, el diccionario de datos debe incluir los distintos rangos y límites que se aplican al elemento. Por ejemplo, el límite 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 número 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 función del número de caracteres impresos y no por la cantidad requerida de memoria.

76

6. Una adecuada codificación.- Cada dato debe incorporarse al diccionario de datos junto con su código, si es que lo tiene, y el significado de éste. Es indispensable que la codificación sea consistente. 7. Cualquier otra información pertinente de edición.- La información requerida para asegurar la edición 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 modificación y mantenimiento. Es de gran utilidad el diccionario de datos si cada entrada se registra de manera consistente, incluyendo el nombre del dato, el sinónimo, su descripción, los elementos relacionados, el rango, la longitud, la codificación y cualquier otra información necesaria para su edición. 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 sistemática 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 iníciales. Estos son aquellas transformaciones esenciales que el sistema debe realizar con el fin de cumplir sus objetivos. Catalogue los flujos básicos de datos. Catalogue los flujos básicos que entren y salgan de los procesos plasmados en los DFD. En la misma etapa, catalogue también los almacenes de datos que contengan los datos fundamentales para la operación 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 más simple del sistema, los cuales son los datos elementales. Estos son los bloques básicos para la construcción de los sistemas y deben conformar todos ellos las estructuras de los datos. El diccionario de datos ideal se encuentra automatizado, y además es interactivo, en línea y evolutivo para conocer más de los sistemas de la organización y se puede crear en forma paralela al análisis y diseño de los sistemas. Para tener el potencial máximo, 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 automática, se actualice o elimine de la base de datos porque se puede convertir en una curiosidad histórica si no se actualiza. Los diccionarios de datos automatizados logran mejoras dramáticas en la documentación. Para ello, también llegan a cambiar la rutina de los analistas de sistemas. Aunque la tendencia se dirige hacia los diccionarios de datos automatizados en línea, es relevante apreciar la importancia de integrar (aun de manera manual) un diccionario de datos, que sea común para la organización. Si comienza temprano ahorrará muchas horas del tiempo del análisis y del diseño. El diccionario de datos de la organización llega a ser una fuente común de información de la organización, para resolver incógnitas y disputas sobre aspectos relativos a la definición de los datos sirve como excelente referencia para el mantenimiento de sistemas poco familiares. Catálogo 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 designación simbólica en su esquina superior derecha, indicando que el proceso se está catalogando. Después, 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

Descripción

Verificar el registro del examen y cálculo de las tarifas Entradas

Descripción del proceso

Registro del del examen Tarifas

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 catálogo de tarifas. .

Salidas Tarifas Validas

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

Un nuevo flujo de datos, TARIFA VÁLIDA, 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 símbolo 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 número de movimientos que fluyen a través del sistema se registra como la magnitud de la información, en este caso, “alrededor de 100 por día”. Después llenar una tarjeta para el almacén de datos al que se tiene acceso. Esta tarjeta se ilustra en la figura 3.10, para el almacén de datos TARIFAS. Acompañando al nombre se encuentra en la esquina superior derecha la representación simbólica de este elemento. De manera similar a las dos tarjetas anteriores, proporciona una breve descripción de TARIFAS

T AR I F A - V A L I DA

Descripción:

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

Fuente Verificar el examen y calcular la tarifa

Destino Preparar la factura

Estructura de datos que viaja con el flujo

Volumen Alrededor de 100/día

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 almacén de datos requiere de una columna de “flujo de datos entrante”, de la que se carece en este caso, pues el proceso de acceso sólo es de consulta y no se llega a modificar a las TARIFAS. También pide “los flujos salientes”, que serían cualquiera de las tarifas de los médicos. También en la tarjeta del almacén de datos hay un lugar para anotar el contenido, donde podemos “observar el interior” de los datos almacenados y ver su composición.

T A R I F A S

Descripción Catálogo de las tarifas de los servicios básicos que realizaron los médicos.

Tarifas

Categoría del examen tarifas – regulares tarifas – por – emergencias

Flujos de datos entrantes

Flujos de datos salientes

Contenido

Tarifas aplicables

Figura 3.10 Una tarjeta del diccionario de datos para el almacén 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 representación simbólica en la esquina superior derecha; como en las otras tarjetas, se tiene una breve descripción. Observe que varios datos elementales integran la FACTURA DE PACIENTE, además 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

Descripción breve Enviar la cuenta al paciente Descripción (Utilice un * para iteraciones) Identificación de la factura Fecha – factura Información – paciente Nombre paciente Número paciente Dirección del paciente Seguro del paciente Información 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 más básico, el dato elemental. Recuerde que los datos elementales son aquellos datos dentro del sistema que no tienen significado alguno si se llegaran a descomponer aún más. En la figura 3.12 el diccionario de datos muestra el registro para un dato elemental llamado CIASEGURO (breve versión de compañía de seguros). Una vez más, se requiere el nombre del dato elemental, así como la designación de que es un registro para un elemento, en la esquina superior derecha. También se da una breve descripción textual, así como cualquier sinónimo y el contexto dentro del cual pudiera encontrarse. En la parte derecha de la forma, se especifica si el dato elemental es alfabético, numérico o de código alfanumérico, 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 heurístico al nivel de detalle que usted requiera para el registro, y de manera consistente mantenga su aplicación.

C I A - D E

Descripción breve

S E GU R O S

Un código de dos letras para el corredor de

Sinónimos (contextos)

seguros CLAVE-SEC (lista de correos)

Alfabético Alfanumérico Numérico

Sies continuo:

Si es discreto Valor BC BS MM HM MO

Significado Blue Cross Blue Shield Mutualidad Médica HMO Mutualidad de Omaha

Longitud Rango

Si son más 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. Además de los mismos detalles particulares que requieren las otras entidades, se tiene el código del NUMERO DE PACIENTE. Por el registro en el diccionario de datos, es aparente que con seis médicos que operan el sistema, el valor de los primeros dos dígitos del NUMERO DEL PACIENTE serían 01, 02, 03, 04, 05 ó 06, dependiendo del médico que atiende al paciente en su primera visita. Los códigos del médico nunca van sin el código 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 código del paciente, asignado con secuencia, donde todos los valores comienzan después de 10000. Un cajero debe percatarse que un código que contenga 00008 en los últimos cinco dígitos del NUMERO DEL PACIENTE estaría en un error. El código del paciente nunca se utiliza sólo en el sistema, sin acompañarse por el código de médico, de forma tal que tampoco se trata como un dato elemental.

82

NUM E R O

Descripción breve

DE

PA C I E NT E

Identifica al paciente para propósito de la facturación NUM-DE-PAC (lista de publicaciones)

Sinónimos (contextos)

Alfabético Alfanumérico Numérico

Si es continúo: Longitud Rango

Si es discreto Valor NN - NNNNN

Significado (Los últimos cinco dígitos se asignan de manera secuencial) 2 primeros dígitos Nombre del doctor 01 Watson 02 Holmes 03 Moriarty Si son más de cinco valores, utilice el reverso de la tarjeta o tarjetas adicionales.

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

La determinación de la longitud del campo se muestra en la figura 3.14 se puede observar el porqué una determinación correcta de la longitud de campo es tan importante al compilar un registro del diccionario de datos. La figura muestra la factura que el médico envía al paciente, al final del mes correspondiente al tratamiento. Los cargos requieren sólo de tras lugares a la izquierda del punto decimal, ya que no hay servicio alguno por el cual los médicos cubren más de $999.99. Sin embargo, es posible que el total del cargo por los servicios médicos 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 realización Del servicio

Descripción del servicio realizado Tarifa

MM/DD/YY MM/DD/YY MM/DD/YY MM/DD/YY

XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX

Crédito

999.99 999.99 999.99 999.99

999.99 999.99 999.99 999.99

Totales

9.999.99

9.999.99

Neto

9.999.99

Figura 3.14.- Longitud de los campos se determinan en la construcción del DD.

83

3.1.3 DISEÑO DE MÓDULOS Módulo.- Fragmento de programa casi independiente que habitualmente tiene un nombre y algunas instrucciones y datos propios. Un módulo se llama desde otro módulo y, de forma similar, invoca otros módulos”. “Unidad sintácticamente bien formada de acuerdo con las reglas del lenguaje de programación en uso” “Colección de declaraciones, en principio ocultas, respecto a toda acción o declaración ajena al propio módulo, es decir definidas en un ámbito de visibilidad cerrado” Modularidad.- División de software en porciones manejables, módulos independientes, o agrupación de items mutuamente afines.

El objetivo del diseño de módulos es conseguir una visión del software como una estructura jerárquica de módulos. Cuando aumenta la complejidad de los problemas, es necesario dividirlos en subproblemas para facilitar su resolución. Cada subproblema se aborda independientemente, combinando las subsoluciones para llegar a la solución final. La programación modular se basa en la creación de unidades llamadas módulos, que agrupan datos y procedimientos relacionados entre sí. La filosofía de este paradigma es la ocultación 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 través de los procedimientos del modulo. Cada modulo tiene una interfaz bien definida, que permite un uso fácil por parte de otros módulos. Además, cada uno es desarrollado independientemente de los demás. Esto requiere la posibilidad de compilación separada. Los módulos ofrecen un segundo nivel de ocultación de información, no solo con respecto a los algoritmos, sino también a los datos.

Ideas fundamentales: Reducir el esfuerzo de desarrollo Separación entre estructuras de datos y procedimientos Independencia funcional: Cada módulo debe realizar una tarea concreta que afecte lo menor posible al resto Ocultamiento de Información: La información de un módulo es inaccesible para el resto de módulos Un buen diseño modular consiste en contemplar nuestros futuros algoritmos como una jerarquía de módulos perfectamente comunicados entre sí, donde cada uno de ellos cuente con un objetivo diferenciado, como si fueran piezas de una máquina que pudiesen ser utilizadas para construir otras máquinas. Ver figura 3.15. PASOS EN EL DISEÑO MODULAR   

Selección/Diseño de tipos de datos Selección/Diseño de estructuras de datos necesarias Selección/Diseño de algoritmos para procesar la información

84

PROGRAMA PRINCIPAL

MODULO 1

MODULO 5

MODULO 2

MODULO 4

MODULO 3

MODULO 5

MODULO 6

Fig. 3.15.-Diseño de Módulos.

De forma más específica se siguen los siguientes pasos: 1. Diseño de la arquitectura. Determinación de las estructuras a gran escala, poca modularidad es igual a problemas posteriores. 2. Diseño de módulos. Módulo con un propósito bien definido, con conexiones claras a otros módulos, si la arquitectura es modular, el diseño de los módulos es más sencillo. 3. Depuración. Fácil de hacer en el interior de cada módulo. 4. Verificación. Verificación virtualmente imposible en el sistema completo, mejor en “partes”. 5. Mantenimiento. Lo más conveniente es hacer el cambio en un solo módulo, con la confianza de que los otros módulos no se van a ver afectados. 6. Desarrollo independiente. Entre distintos miembros de equipo ya que independiza la codificación, interfaz entre módulos claros y limitados. 7. Reutilización del software. "No reinventar la rueda".

3.1.4 DESCOMPOSICIÓN EN PROCESOS

Los procesos se descomponen en “subprocesos”, hasta llegar a los procesos primitivos. DESCOMPOSICIÓN FUNCIONAL: a) b) c) procesos. d)

Cada proceso se puede explotar, refinar o descomponer en un DFD más detallado. El DFD de un sistema es realmente un conjunto de DFD’s dispuestos jerárquicamente. Los niveles de la jerarquía están determinados por la descomposición funcional de los La raíz de la jerarquía es el “diagrama de contexto”, que es el más general de todos.

85

El diagrama de contexto se utiliza para entender mejor las reglas de producción.

Destino

A

P Sist

B

Fuente

GENERAL - PARTICULAR X

P F2

V

P F5

X

P F4

Z

P F1 Y

P F45

X1

P F3

P F41

Y2

W

Z

X2

P F43

A

X

P F44 Y1

P F42 Y

Figura3.16.- Ejemplo de la descomposición de un Diagrama de Flujo de Datos (DFD).

Consistencia de DFD: Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo”. Balanceo de DFD’s: Las E/S de un proceso “padre” deben corresponder con las E/S del DFD “hijo” que lo explica. Jerarquía de DFD s: En un DFD completo cada proceso tiene un número único que lo identifica en función de su situación en la jerarquía. Cada DFD tiene también un número ú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 especificación.

86

3.2

EL ENFOQUE ORIENTADO A OBJETOS

Los conceptos de análisis y diseño orientados a objetos (OO) se originaron a partir de desarrollos en los lenguajes modernos de programación. 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 técnicas orientadas a objetos son mejores que los enfoques más antiguos para el manejo del ritmo de cambio cada vez más grande en muchas de las organizaciones actuales. Por ejemplo, muchos productos están siendo hechos cada vez más bajo pedido o fabricados en lotes pequeños, conforme los fabricantes buscan mayor concentración sobre la satisfacción del cliente y la penetración 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 rápido desarrollo y mantenimiento de sistemas. Se piensa que las técnicas OO trabajen bien este tipo de situaciones, donde sistemas de información complicados están sufriendo mantenimiento, adaptación y rediseño continuos (reingeniería). Fueron desarrollados para dar soporte a la tecnología de programación OO; no fue una evolución instantánea, sino la evolución de un conjunto de conceptos algo desconectados que han sido puestos juntos para formar un nuevo paradigma para la ingeniería del software. Por ejemplo, la programación OO toma su concepto de encapsulación de la idea de ingeniería de software de la abstracción de datos, y su concepto de herencia a partir de la idea de base de datos de generalización y especialización. Debido a que el análisis y diseño OO está fuertemente relacionado con la programación OO, se debe explorar brevemente el contexto de programación OO antes de proceder al análisis y diseño OO. Seis ideas básicas caracterizan a la programación OO: 1).-Objetos.- Es una representación en computadora de alguna cosa o evento del mundo real. La figura 3.13 muestra cómo una computadora podría representar un auto. Por ejemplo si se trata de un Jeep Wrangler, la computadora podría guardar el nombre del modelo, el número ID del vehículo (#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 Automóviles.

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 cómo un grupo de objetos que representan automóviles podrían estar formados en una clase llamada “Automóviles”. Por ejemplo, todo automóvil 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.

Automóviles

Marca/Modelo

VIN

Motor

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

3).-Mensajes.- Se puede enviar información 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 “Automóviles”. El mensaje es “arrancar motor”; estos mensajes no son de forma libre en ningún sentido, ya que en vez de eso las clases Operador y Automóviles han sido programadas cuidadosamente para enviar y recibir un mensaje de “arrancar motor”.

Automóviles

Jeep Wrangler

#51Y62BG826341Y

6-Cil

“Arrancar motor” Operador

Kim McCabe

001-64-9532

Café

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

88

4).-Encapsulación.- Típicamente, la información 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 Mecánico) envía un mensaje Quitar motor al objeto Jeep (clase Automóviles); la clase Automóviles reacciona a este mensaje con un comportamiento (también llamado “método” o “procedimiento”) que cambia el atributo de motor a Ninguno. Este método 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 característica 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 construcción facilita la construcción de objetos que son muy confiables y consistentes, debido a que ellos tienen control completo sobre sus propios atributos.

Automóviles

Jeep Wrangler Arrancar motor

#51Y62BG826341Y Parar motor

Instalar motor

“Ninguno” Quitar motor

Quitar

Mecánico

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 (Camión) en forma tal que hereda todos los atributos de la clase base Automóviles. Una clase derivada puede tener también atributos y comportamientos adicionales. Por ejemplo, la clase Camión no solo tiene atributos para fabricante/modelo, VIN y motor, sino también tiene atributos para carga, remolques y refrigeración. Los objetos Automóviles no tienen estos nuevos atributos.

89

La herencia reduce la labor de programación reutilizando fácilmente objetos antiguos. El programador sólo necesita declarar que la clase Camión hereda de la clase Automóviles, y luego proporcionar cualquier detalle adicional acerca de nuevos atributos o comportamientos (mostrados en el cuadro de línea continua de la figura). Todos los atributos y comportamientos antiguos de la clase Automóviles son parte automática e implícitamente de la clase Camión (se muestra en el cuadro de guiones) y no requiere ninguna nueva programación. Algunos lenguajes de programación O-O proporcionan herencia múltiple. En estos casos especiales se puede crear una clase derivada en forma tal que herede todos los atributos y comportamientos de más de una clase base.

Automóviles

Marca/Modelo

VIN

Motor

Cantidad de remolques

Refrigeración

Camión: hereda Automóviles

Capacidad de carga Marca/Modelo

VIN

Motor

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 excepción del comportamiento imprimir. Un mensaje para activar el comportamiento Imprimir de un objeto de la clase archivo madre genérica puede causar que se impriman los atributos tamaño de archivo, tipo de archivo y fecha/hora. El mismo mensaje enviado a un objeto ASCII podría causar que se enviara el texto del archivo a la impresora. El mismo mensaje enviado a un objeto de mapa de bits podría causar que ejecutara un programa de desplegado gráfico.

90

Tamaño de archivo

Tipo de archivo

Fecha/Hora

Imprimir

Archivo ASCII: hereda Archivo Delimitador

Imprimir

Tamaño de registro

Archivo de mapa de bits: hereda Archivo Imprimir Color/Monocromático Resolución

Figura 3.22.- Ejemplo de polimorfismo entre clases relacionadas.

3.2.1 ANÁLISIS

El enfoque de Coad y Yourdon para el análisis Orientado a Objetos (O-O) está basado en un modelo de cinco capas; la figura 3.19 ilustra cómo se entrelazan estas cinco capas que añaden una estructura tridimensional a la notación de análisis y diseño que da mayor poder para la representación 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 análisis orientado a objetos.

91

1. CLASE/OBJETO. Esta capa del análisis y diseño indica las clases y objetos en las siguientes formas: a. Objeto: Es una abstracción de algo en un dominio de un problema que refleja las capacidades de un sistema para llevar información acerca de ello, interactuar con ello o ambas cosas. Una encapsulación de valores de atributos y sus servicios exclusivos. Sinónimo: una ocurrencia. b. Clase: Una descripción de uno o más objetos con un conjunto de atributos y servicios uniformes, incluyendo una descripción de cómo crear nuevos objetos en la clase. c. Clase y objeto: Un término 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 análisis. Los objetos a veces representan cosas tangibles como vehículos, 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 también pueden ser derivados de incidentes o eventos, tales como vuelo, accidente o reunión. Los incidentes suceden típicamente en un momento específico. Otros objetos pueden indicar interacciones tales como una venta o un matrimonio. Las interacciones tienen una cualidad de transacción o contrato. Los objetos también pueden detallar especificaciones. Las especificaciones tienen estándares o una cualidad de definición y, por lo general, implican que otros objetos representarán ocurrencias de cosas tangibles. Por ejemplo, una clase de objetos tales como “tipo de póliza 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 “póliza de seguros”. En la figura 3.20 se muestra la notación para Clase, Objeto y Clase y Objeto. Las clases son representadas por cuadros rectangulares redondeados (bubtángulos) divididos en tres partes. El nombre de la clase se muestra en la división 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 serán 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 notación clase y objeto para distinguir gráficamente entre estructuras y mensajes que están 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.- Notación que representa los conceptos Clase, Objeto y Clase y Objeto.

92

Las técnicas para describir objetos son básicamente 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 diseños sobre analizados. iv. Usualmente una clase tendrá más de una instancia de objeto, a menos de que sea una clase base. v. Usualmente los atributos tendrán 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 generalización-especialización. vi. Usualmente los servicios siempre se comportarán en la misma forma para todos los objetos de una clase. Los servicios que varían dramáticamente para algunos objetos de una clase o que regresan sin realizar acción para algunos objetos también sugieren una estructura generalizaciónespecificación. vii. Los objetos deben implementar requerimientos que son derivados del problema y no de la tecnología de solución. La parte de análisis del proyecto O-O no debe llegar a ser dependiente de una tecnología de implementación particular, tal como un sistema de computadora específico o un lenguaje de programación específico. Los objetos que atienden tales detalles técnicos no deben aparecer sino hasta muy tarde en la etapa de diseño. Los objetos dependientes de la tecnología sugieren que el proceso de análisis 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 básicos de estructuras que deben ser impuestas en las clases y objetos. Estas son: a. ESTRUCTURAS GEN-SPEC(estructura generalización-especialización).La herencia se crea con las estructuras Gen-Spec. Estas relaciones entre clases son a veces llamadas relaciones de clasificación, subtipo o ISA. Son indicadas por un semicírculo con su lado redondo hacia la clase generalizada. Estas estructuras siempre conectan clases a clases. Son típicamente de forma jerárquica. La figura 3.21 muestra una estructura Gen-Spec entre Clases y Objetos en donde las clases Autobús y Motocicleta heredan todas las propiedades de la clase Automóviles. 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 triángulo 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 Vehículo estando compuestos de dos otros objetos: Motor y Chasis. Las estructuras Todo-partes también tienen cardinalidad, representada por uno a muchos y muchos a muchos. La notación “0, m” especifica que un vehículo puede no tener motor (0) o uno o más motores (m). La notación “0,1” especifica que un motor puede ser parte de ningún vehículo (0) o de un vehículo (1), pero nunca de más de uno. El “1, m” especifica que un vehículo puede tener uno o más chasis, pero nunca menos de uno. El “1” especifica que un chasis siempre está relacionado con uno y solo un vehículo.

93

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

0, m

1, m

0.1

1

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

3. SERVICIOS. Esta indica los mensajes y comportamientos del objeto (servicios y métodos). También llamados métodos 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 más comúnmente analizados y diseñados usando diagramas de estado. Por consecuencia, el análisis de servicios consiste de tres actividades: análisis del estado del objeto, especificación de servicio y especificación de mensaje.

94

a. Análisis del estado del objeto..- Se puede descubrir cambios de estado más fácilmente 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 ningún atributo cambia el comportamiento del objeto, pero todavía se sabe que el objeto se comportará diferente bajo ciertas condiciones, se debe probablemente añadir 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 reacción a un mensaje “descargar pasajeros”, dependiendo de si el tren está detenido en una plataforma de estación o balanceándose en una vía 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 lógicamente que el objeto descargue pasajeros mientras está en movimiento. Los diagramas de estado son añadidos conforme se necesita a las plantillas de especificación 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 conexión), acezar objeto (obtener o poner los valores de los atributos) y borrar objeto. Son implícitos y muy obvios) o compuestos (involucran ciclos, muchas operaciones o condiciones compuestas, se aplican típicamente a solamente una Clase y Objeto y frecuentemente ocasionan servicios “compañeros” o “privados” que son similares a los módulos de subrutinas). c. Especificaciones de mensajes.- Detallan cómo el comportamiento de un objeto puede activar el comportamiento de otro objeto. Esto es, los mensajes son generados por un objeto con la intención 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 Pdirección han sido puestos en capa sobre el objeto Propietario, y los atributos Modelo y Color han sido puestos en capa sobre el objeto Vehículo. La idea básica 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 más propensos al cambio que las clases. Si una estructura o un conjunto de clases parecen estar amontonándose, debido a que un objeto está cambiando de clase a clase, tal vez la Clase y Objeto en cuestión 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 restricción reduce la programación y mantenimiento, debido a que un cambio hecho en un objeto Gen será automáticamente 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 foráneas. En vez de amontonar el paquete de diseño con tales detalles de implementación, no se especifican los atributos de llave primaria. Por consecuencia, las referencias entre objetos, tales como asociaciones y relaciones, se indican por una sola línea entre los objetos con la misma notación 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 conexión de instancia entre los objetos Propietario y Vehículo. Las notas de cardinalidad nos dicen que un propietario puede estar relacionado con cero, uno más vehículos, pero un vehículo siempre debe estar relacionado con un solo propietario. Con la introducción de los atributos necesitamos detalles de análisis adicional para dar soporte al paquete de diagrama en capas. En esta etapa del análisis estos detalles toman en cuenta solamente descripciones de los atributos y restricciones de sus valores. Coad y Yourdon recomiendan una plantilla de especificación que proporcione un esquema similar al diccionario de datos. Esta plantilla puede ser luego expandida y modificada conforme continúa el análisis.

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 diseño en unidades de implementación 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 análisis, diseño e implementación. Esta capa proporciona un medio para subdividir una especificación compleja en unidades de trabajo lógicas. Una capa de tema es solamente necesaria en proyectos grandes que involucran muchas clases. Los temas son resaltados trazando una línea 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. Típicamente el tema toma nombre por esta clase.

96

3.2.2 DISEÑO OBJETOS Las actividades de diseño en el enfoque de Coad y Yourdon llevan las herramientas de análisis hacia delante hacia el juego completo de especificaciones para la implementación. Donde el análisis es razonablemente independiente de la tecnología, las actividades de diseño llegan a ser cada vez más orientadas hacia un lenguaje O-O particular y ambiente de desarrollo. Las actividades de diseño O-O están 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 diseño O-O es expandida conforme se necesita a lo largo de los cuatro componentes de implementación. La figura 3.25 muestra cómo interactúan estos elementos para completar el diseño de sistema.

Componentes

Capas Capa Clase y

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

Figura 3.29.- Elementos de diseño O-O agrupados en componentes y capas.

Toda la documentación del análisis debe llevar directamente hacia la etapa del diseño. En este punto se necesitan pocas herramientas nuevas. El paquete de diagrama en capas y la plantilla de especificación siguen siendo los componentes principales del diseño. Estos documentos no son complementados o reemplazados, sino que, en vez de ello, son ampliados para incluir los detalles de implementación restantes durante la fase de diseño. Frecuentemente se usa prototipos durante la fase de diseño. Se crean versiones burdas de los objetos y se prueban en sus papeles con los cuatro componentes. Esto significa que frecuentemente el paquete de diseño se envía hacia los programadores con partes del código de programa ya escrito. Los diseñadores usarán frecuentemente el lenguaje de implementación esperado como el mecanismo para escribir especificaciones completas para las clases. Por ejemplo, el diseñador puede encontrar que es fácil copiar la definición de clases C++ de un prototipo operacional en la especificación. Esto puede probar que significa menos trabajo para el diseñador y elimina esfuerzos duplicados por parte de los diseñadores y programadores de implementación.

97

El componente de dominio problema (PDC) es el conjunto básico de objetos funcionales que llega de la etapa de análisis. 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 añadidas al PDC para “hacer que trabaje”. Por consecuencia, el diseño del PDC se termina en su mayor parte en la etapa del análisis. Solamente se necesitan tres actividades para completar el diseño de PDC: 1. DISEÑO DE REUSO.- Tal vez se quiera añadir nuevas clases al PDC para rehusar objetos. Por ejemplo, hay paquetes comerciales de clases altamente generalizadas para objetos. Una organización de programación 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 diseño. Podemos añadir esas clases reusables a nuestro diseño 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 análisis. 2. ESTRUCTURAS DE IMPLEMENTACIÓ.- Tal vez se quiera añadir otras estructuras al diseño, simplemente por razones de implementación; también, tal vez se quiera usar estructuras de agregación 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 más fácil la tarea de programación. 3. ACOMODO AL LENGUAJE.-Tal vez se necesite corregir el diseño para que las estructuras puedan ser construidas en el lenguaje de programación seleccionado, debido a que estos lenguajes pueden tener diferentes patrones de herencia. Algunos lenguajes incluyen herencia múltiple, otros solamente incluyen herencia simple y todavía otros no incluyen herencia. En los casos más restrictivos, los patrones de herencia del diseño deben ser modificados para permitir las capacidades del lenguaje de implementación. Diseño del componente de interfaz humana En esta actividad se crea los menús, reportes y pantallas interactivas que usarán las personas para trabajar con el sistema. Estas actividades son básicamente sobre el diseño de la interfaz de usuario. Sin embargo, en el contexto de diseño O-O esta fase culmina en una especificación para nuevas clases componente de interfaz humana (HIC) que deben ser añadidas al diseño. Por lo general, se puede apoyar en gran forma en clases de biblioteca para el diseño 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 menús, ventanas, control de ratón, iconos, control de tipo de letra y utilerías de cortar y pegar. Los prototipos son muy útiles durante el diseño HIC para suavizar cómo trabajarán las clases de biblioteca con los objetos PDC, la interacción del usuario con los prototipos puede proporcionar información extremadamente útil acerca de la efectividad del diseño.

Diseño de los componentes de administración de tarea y datos Estos dos componentes están enlazados muy fuertemente con la tecnología de implementación. El manejo de tareas está muy determinado por la configuración de hardware de computación, y el manejo de datos está muy determinado por el software de sistemas disponible cuando el sistema esté de hecho en ejecución. El componente de manejo de tareas (TMC) es más 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, asignación 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 añadido 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 varía considerablemente dependiendo de si la tecnología de tiempo de ejecución 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 ,

m

Figura 3.30.- Componentes de manejo de tarea del análisis y diseño O-O.

Hay tres formas diferentes para diseñar el DMC. Un enfoque es construir servicios de almacenamiento en cada Clase y Objeto en el diseño. Esto involucra, por lo general, una cantidad considerable de programación de diseño 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 cómo guardar o recuperar todos los objetos del sistema. Cualquier petición de almacenamiento se hace por medio de mensajes a este único objeto. La figura 3.27 muestra el diseño de un ServidorObjetos.

99

S Figura 3.31.- Diseño de una Clase y Objeto ServidorObjetos

e r

v Un tercer método es crear una clase Almacenable. Este tercer enfoque es una combinación de los dos i servicios básicos guárdame y recupérame en enfoques anteriores. La clase Almacenable incluye forma generalizada. Cada objeto del sistema que deba d ser guardado o recuperado es conectado luego en una estructura Gen-Spec con la clase Almacenable. Esto trabajará solamente, por lo general, en o aquellos casos donde se disponga de herencia múltiple en la tecnología de implementación. 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 notación Las técnicas O-O presentadas aquí están basadas en un enfoque popular presentado por Coad y Yourdon. Hay varios enfoques competitivos que proporcionan variaciones en la notación y en los tipos de abstracciones de análisis y diseño. Ninguna de estas técnicas es fácilmente comparable con las otras. Por ejemplo, en la figura 3.29 encontrará la notación para herencia usada por cinco de los autores mencionados en la bibliografía. Son bastante similares. La cosa importante a darse cuenta aquí es que, una vez que se comprenden los principios de herencia no es difícil un cambio en notación.

100

Shlaer

Booch

Clase Clase

Motocicleta

Embley

Vehículo

Automóviles

Rumbauhg

Coad v Yourdon

Figura 3.33.- Notación de diseño de herencia comparativo de cinco autores diferentes de análisis y diseño O-O.

EJERCICIOS UNIDAD III 1. 2. 3. 4. 5. 6. 7. 8. 9.

¿Qué es análisis? ¿Qué es diseño? Describe análisis y diseño OO. ¿Cuál es la diferencia de análisis y diseño OO? ¿De qué sirve el “divide y vencerás” en OO? ¿Qué es un proceso de desarrollo? ¿Qué pasa dentro de un ciclo de desarrollo? Dibuja y describe los símbolos básicos 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. Descripción: 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 número.

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 representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real”. Los modelos genéricos 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 traído consigo cierta cantidad de estructuras útiles para el trabajo en la ingeniería del software, y han proporcionado un camino a seguir razonablemente efectivo para los equipos de software. En un documento intrigante sobre la extraña relación 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 relación 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 atraído de manera constante hacia el caos o así el orden absoluto”. Cualquier organización de ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo para los procesos de software que adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería del software, y definir cada acción 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. Después, la organización debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo realizarán, 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 genérico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicación, planeación, modelado, construcción y desarrollo. A continuación se examinarán 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 ingeniería del software, tareas, productos del trabajo, aseguramiento de la calidad y mecanismos de control de cambio para cada proyecto. Cada modelo de proceso prescribe también 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 comunicación a través del despliegue de una manera casi lineal. Esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejoras bien definidas a un sistema existente (por ejemplo una adaptación a un software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos, pero solo cuando los requerimientos están bien definidos y son estables en forma razonable. El modelo en cascada, alguna vez llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. Es el paradigma más antiguo para la ingeniera de software, sin embargo en las décadas pasadas, las críticas a este modelo de proceso han ocasionado que aun así más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están: 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 difícil para el cliente establecer todos los requerimientos de manera explícita. 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 versión 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 versión del programa. Las siguientes son algunas creencias del modelo de cascada: a) Las metas se logran mejor cuando se tienen puntos de revisión bien preestablecidos y documentados, dividiendo el desarrollo en actividades secuenciales bien definidas. b) Los documentos técnicos son comprensibles para usuarios y administradores, no técnicos. 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 análisis 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 más común 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 características, funciones y contenido de la información). 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 están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. La figura 4.1 muestra el modelo en cascada.

Modelo Cascada Definición de Requisitos

Diseño de Sistema y software

Implementación y Pruebas de unidad

Integración y Prueba de Sistema

Operación y Mantenimiento

Figura 4.1.- Esquema básico del modelo de cascada.

Análisis 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 Especificación de Requisitos (SRD), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. Diseño.- Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. Como resultado surge el Documento de Diseño del Software (SDD), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Codificación. - Fase de programación propiamente dicha. Aquí se desarrolla el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. El diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.

105

Pruebas.- Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Implantación.- El software obtenido se pone en producción. Mantenimiento.- Durante la explotación del sistema software pueden surgir cambios, los cambios ocurrirán debido a que hayan encontrado errores, o que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Todo ello se recoge en los documentos de cambios. La interacción 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 corrección de los problemas encontrados en fases previas.

106

1.

4.2. MODELO DE ESPIRAL El modelo espiral surge como un modelo no operativo de producción de software que tiende a poner énfasis allí donde los demás 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 comparación con los demás adolece de algunos inconvenientes que se indicarán pero tiene una manera original de generar software que supera con creces los inconvenientes, sobre todo allí donde los problemas financieros, de tecnologías innovativas o cualidades particulares del software hacen que los otros modelos tiendan a no conformar para su elección. El modelo en espiral, que Boehm propuso originalmente, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos 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 ingeniería de software concurrente y con múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras disminuye su grado de riesgo. La otra es un conjunto de puntos de fijación 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 más completas del sistema desarrollado. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniería 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 dirección en el sentido del movimiento de las manecillas del reloj, y que inicia desde el centro. El riesgo es un factor considerado en cada revolución. Los puntos de fijación es una combinación 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 especificación del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentación derivada de la relación con el cliente después de la entrega. Además, el administrador del proyecto ajusta el número 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 podría representar un "proyecto de desarrollo del 3 concepto", el cual se inicia en el centro de la espiral y continúa por múltiples iteraciones hasta que el desarrollo del concepto esté completo. Si el concepto se desarrollará en un producto real, el proceso continúa en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionará a través de un número de iteraciones alrededor de la espiral. Después, un circuito alrededor de la espiral se podría 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 construcción de prototipos como un mecanismo encaminado a reducir riesgos, pero en forma importante, permite al desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo interactivo que refleja de forma más verídica el mundo real. El modelo espiral exige una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que vuelvan problemáticos. Las creencias de los modelos son: Una actividad comienza cuando se entienden los objetivos y riesgos involucrados. Basado en la evaluación de soluciones alternas, se usan las herramientas que mejor reduzcan los riesgos. Todo el personal relacionado debe involucrarse en una revisión que determine cada actividad, planeando y comprometiéndose con las siguientes actividades. El desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto.

Planeación Estimación Itinerario Análisis de riesgos

Comunicación Modelado Análisis Diseño

Despliegue Entrega Retroalimentación

Construcción Código Prueba

Figura. 4.2.- Modelo en espiral típico.

108

El modelo basa sus características en sucesivas iteraciones hasta cumplir cierto punto de control o condiciones prefijadas para derivar a partir de allí en los modelos clásicos (cascada o prototípico). En el primer caso una vez realizadas determinado número 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 más 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 más importantes y los ciclos más 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 demás ciclos por lo que el espiral se va abriendo a medida que avanzamos y su culminación 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, lìmites y condiciones de contorno. A los efectos de referirse diferenciadamente de los aspectos iterativos del inicio a los aspectos de los modelos clásicos 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: Planificación, Análisis de Riesgo, Ingeniería, Evaluación, Toma de Decisiones, Refinamiento, y para el segundo caso (si hablamos del ciclo de cascada): Factibilidad, Requisitos, Desarrollo Preliminar, Desarrollo Detallado, Codificación, Integración y Prueba, Implementación, Operación y Mantenimiento y Retiro. El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.

Este método está basado en dos importantes principios: 1. La práctica de diseño profesional es caracterizar en términos de conocer, actuar en situaciones, conversación con la situación y reflexión en acción. Hay un distinto medio de proceso orientación en esta aproximación al diseño. Es raro que el diseñador tenga el diseño en su cabeza por adelantado y que después meramente lo transcriba. Gran parte del tiempo del diseñador esta inmiscuido en una progresiva relación con su entorno. Una buena metáfora para describirlo es "la conversación con el material", como un escultor, quien está ocupado en una conversación 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 diseñadores de tomar la práctica de trabajo seriamente, de supervisar las formas en las que el trabajo se esté haciendo, en el sentido de una solución abierta y desplegada para aumentar la complejidad de una situación que el diseñador sólo 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 cooperación y comunicación.

____________________________ 3

Las flechas que se apuntan hacia adentro a lo largo del eje que separa la región de despliegue de la de comunicación indican una posibilidad de iteración local de la misma ruta de la espiral.

109

Las etapas del modelo en espiral pueden ser las siguientes: Debe indicarse que el número de etapas pueden variarse o subdividirse generando entre cuatro y siete de ellas según la importancia que se pretende dar a cada una por lo que lo que aquí describimos es una interpretación posible de las mismas en la figura 4.3. Planificación. Determinación de objetivos, limites y condiciones de contorno (condiciones que limitan de alguna manera el desarrollo, económicas, de tiempo, etc.) y alternativas. Predicción de personal esfuerzo y costo que se requerirán 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. Análisis de riesgo. Desarrollo de un plan para descubrir los riesgos más importantes y resolver los mismos. Eliminación de aspectos no compatibles con las condiciones, o condiciones de contorno o límites. Identificar ideas o necesidades, formular soluciones potenciales, conducir estudios de viabilidad, planificar la transición del sistema, refinar y finalizar la idea o necesidad, analizar las funciones del sistema, desarrollar la arquitectura del sistema, descomponer los requisitos del sistema, planificación de contingencias. Ingeniería. Desarrollo del producto o prototipo según las condiciones de la etapa anterior. Dentro de esta etapa se realizan las siguientes actividades: realizar el diseño arquitectónico, analizar el flujo de información, diseñar la base de datos, seleccionar o desarrollar algoritmos, realizar el diseño detallado de la etapa, crear el código fuente. Evaluación. Evaluar los resultados del prototipo obtenido, verificar y validar. Ejecutar las pruebas, generación 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 iteración. Evaluación de resultados, repetición del ciclo o pasaje a otro modelo. Técnicas de toma de decisiones (árboles de decisión, decisiones en condiciones de incertidumbre, etc.). Refinamiento. Si se toma la decisión 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 problemático al momento de establecer contratos de desarrollo. b) Requiere de buenas habilidades en el control y estimación 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

Evaluar alternativas, identificar y resolver los riesgos

o g r Revisión

e s o

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 pequeñas, 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 filosofía interactiva de construcción 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 utilización y/o evaluación se desarrolla un plan para el incremento siguiente, este plan afronta la modificación del producto central con el fin de satisfacer mejor las necesidades del cliente, la entrega de funciones y características 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 también una plataforma para la evaluación del producto.

Características a) Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos. b) El primer incremento es un producto esencial (núcleo), se afrontan requisitos básicos y muchas funciones extras (conocidas o no) quedan para los siguientes incrementos. c) Los requisitos son priorizados. Los requisitos con una más alta prioridad se incluyen en los incrementos más 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 utilización y/o evaluación 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 construcción de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construcción de prototipos, el modelo incremental entrega un producto operacional en cada incremento. h) Es útil cuando la dotación de personal no está disponible para una implementación completa. El primer incremento se puede implementar con pocas personas. Si el producto central es bien recibido, se puede añadir más personal. i) Las siguientes son algunas creencias del modelo incremental: j) La administración de proyectos es más fácil de lograr en incrementos más pequeños. k) Es más fácil comprender y probar incrementos de funcionalidad más pequeños. l) La funcionalidad inicial se desarrolla más temprano, logrando resultados de inversión en menor tiempo. m) Hay más 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 visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin 4 embargo, para la producción del software, se usa el principio de trabajo en cadena o "Pipeline ", utilizado en muchas otras formas de programación. 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 métodos 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 dotación de personal suficiente para una implementación completa en la fecha límite que se haya establecido para el proyecto. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se puede añadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos. Modelo incremental en el desarrollo de los primeros sistemas:

Años 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 años anteriores. Figura 4.4. El sistema, tal como está especificado en los documentos de requerimientos, está particionado en subsistemas funcionales pequeños y se van agregando funciones en cada versión como se muestra en la figura 4.5. El Modelo Incremental se puede ver aquí en forma gráfica:

_______________________________ 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

Ingeniería de sistemas de información Incremento 1 Análisis

Incremento 2

Diseño

Código

Análisis

Diseño

Incremento 3

Análisis

Prueba

Código

Diseño

Incremento 4 Análisis

Entrega de

Prueba

Entrega de

Código

Prueba

Diseño

Entrega de

Código

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 básicos. 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 utilización y/o evaluación. 4. El cliente solicita mejoras al producto 5. Se desarrolla el siguiente incremento incorporando los nuevos requisitos y agregando la nueva función. 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 más críticos. 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 más alta tienden a ser los más probados. e) Puede ser difícil ajustar los requisitos a los incrementos. f) Si un error importante es realizado, sólo la última iteración 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 próximo incremento. Creencias del modelo incremental: a) La administración de proyectos es más fácil de lograr en incrementos más pequeños. b) Es más fácil comprender y probar incrementos de funcionalidad más pequeños. c) La funcionalidad inicial se desarrolla más temprano, logrando resultados de inversión en menos tiempo. d) Hay más 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 céntrica, 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 volvían más poderosas cada año, lo que alentaba que los usuarios esperaran más de ellas. Esta tendencia también la impulsó el uso expandido de Internet para el intercambio de todo tipo de información. Nuestro apetito por un software cada vez más complejo crece en la medida en la que aprendemos cómo 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 más complejo. En resumen, queremos más. De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y características 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 comunicación con el cliente y los métodos 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 reutilización”. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno. Durante la década de 1980 y al principio de la década siguiente, los métodos y lenguajes de programación orientado a objetos (OO) obtuvieron una amplia difusión entre la comunidad de la ingeniería del software. Durante el mismo periodo se propuso una amplia variedad de análisis y diseño orientados a objetos (AOO y DOO) y se introdujo un modelo de proceso orientado a objetos de propósito general. Al igual que la mayoría de los paradigmas “nuevos” para la ingeniería del software, los seguidores de cada uno de los métodos de AOO y DOO argumentaban acerca del cuál de ellos era el mejor, pero ningún método o lenguaje dominó la escena de la ingeniería del software. Al principio de la década de 1990, James Rumbaugh, Grady Booch e Ivar Jacobson comenzaron a trabajar en un “método unificado” que combinaría las mejores características de cada uno de sus métodos individuales y adoptaría características adicionales que propusieran otros expertos (por ejemplo , en el campo OO). El resultado fue el lenguaje de modelado unificado (UML, por sus siglas en inglés) que contiene una notación robusta para el modelado y el desarrollo de sistemas OO. Para 1997, el UML se convirtió en un estándar de la industria para el desarrollo de software orientado a objetos; que proporciona la tecnología necesaria para apoyar la práctica de la ingeniería del software orientada a objetos, pero no provee el marco de trabajo del proceso que guíe a los equipos en la aplicación de la tecnología. En los años siguientes, Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniería del software orientada a objetos, mediante la utilización 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 específicas. Como consecuencia de la aplicación 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 más ágil y reactivo ante el cambio.

116

Fases del proceso unificado. 1. Inicio del PU abarca la comunicación con cliente - actividades de planeación. 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 través de un conjunto preliminar de casos de uso que describen cuáles características 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 máquina, otro sistema) cuando éste interactúa con el software. Los casos de uso ayudan a identificar el ámbito del proyecto y proporcionan una base para la planeación de éste. 2. En este punto, la arquitectura no es más que un esquema tentativo de los subsistemas más importantes y de las funciones y características que los forman. Después, la arquitectura se refinará y expandirá en un conjunto de modelos que representarán visiones diferentes del sistema. La planeación identifica recursos, evalúa los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarán conforme se desarrolle el incremento del software. 3. Elaboración abarca la comunicación con el cliente y las actividades de modelado del modelo genérico del proceso, figura 4.7. La elaboración refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; además, expande la representación arquitectónica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de análisis, el modelo de diseño, el modelo de implementación y el modelo de despliegue. En algunos casos, la elaboración crea una “línea de base arquitectónica ejecutable” que representa un sistema ejecutable en su “primer corte”. La línea de base arquitectónica demuestra la viabilidad de la arquitectura, pero no proporciona todas las características y funciones necesarias para utilizar el sistema. Además, el plan se revisa de manera cuidadosa al término de la fase de elaboración para asegurar que el ámbito, los riesgos y los datos entregados aún son razonables. Las modificaciones al plan se deben hacer en este momento. 4. Construcción del PU es idéntica a la actividad de construcción definida para el proceso genérico del software. Si se utiliza el modelo arquitectónico como entrada, la fase de construcción desarrolla o adquiere los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de análisis y diseño iniciados durante la fase de elaboración se completen para reflejar la versión final del incremento del software. Todas las características y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en código fuente. Conforme los componentes están en proceso de implementación, se diseñan y ejecutan pruebas de unidad para cada uno de ellos. Además, se realizan las actividades de integración (ensamblaje de componentes y pruebas de integración). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptación que se ejecutan antes del inicio de la siguiente fase del PU. 5. Transición del PU abarca las últimas etapas de la actividad genérica de construcción y la primera parte de la actividad genérica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta (el software lo utilizan usuarios finales reales, con la intención de descubrir defectos y deficiencias), y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la información de soporte necesaria (por ejemplo, manuales del usuario, guías de resolución de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de transición, el incremento de software se convierte en un lanzamiento de software utilizable. 6. Producción del PU coincide con la actividad de despliegue del proceso genérico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), se reciben y evalúan los informes de defectos y los requerimientos de cambios.

117

Es probable que mientras se realizan las fases de construcción, transición y producción 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 ingeniería del software. En el contexto del PU, un flujo de trabajo es análogo a un conjunto de tareas. Esto es, un flujo de trabajo identifica las tareas necesarias para completar una acción importante de ingeniería del software y los productos de trabajo que se producen como consecuencia de la realización 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 técnicas del PU. Durante la fase de inicio, el propósito es establecer una "visión" 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 obstáculo para el éxito. Desde el punto de vista del ingeniero de software, el producto de trabajo más importante generado durante la etapa de inicio es el modelo de caso de uso: una colección de casos de uso que describen la forma en que actores externos ("usuarios" humanos y no humanos del software) interactúan con el sistema y obtienen valor a partir de éste. En esencia, el modelo de casos de uso es una colección de escenarios de uso con plantillas estandarizadas que implican características y funciones del software mediante la descripción de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interacción representada. En un inicio, los casos de uso describen requisitos al nivel del domino de negocios (por ejemplo, el grado de abstracción 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 creación de productos de trabajo subsecuentes. Durante la fase de inicio sólo se completa entre el 10 y 20 por ciento de los casos de uso. Después de la elaboración, se ha creado entre un 80 y 90 por ciento del modelo. La fase de elaboración 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 descripción arquitectónica y un diseño preliminar. Cuando el ingeniero de software inicia con el análisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de análisis que describan una forma adecuada el comportamiento del sistema. El modelo de análisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y análisis (colecciones de clases) definidos como una parte del modelo de análisis se refinan después en un modelo de diseño, el cual identifica clases de diseño, subsistemas y las interfaces entre los subsistemas. Los modelos de análisis y diseño expanden y refinan una representación evolutiva de la arquitectura del software. Además, en la fase de elaboración se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez. La fase de construcción produce un modelo de implementación que traduce las clases de diseño en componentes de software que se construirán para ejecutar el sistema, y un modelo de despliegue convierte los componentes en el ambiente físico de computación. 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 transición entrega el incremento del software y evalúa los productos de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentación 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 pequeños de menos de 10,000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administración de configuraciones y Administración 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 estimación de esfuerzo y del 150% en la calidad de la estimación de tamaño. Además, con la utilización del método, el número de sobreestimaciones y de subestimaciones quedó más equilibrado. Por otra parte la calidad del producto aumentó en 2.5 veces. La productividad personal aumentó bastante. No en función del número de líneas de código escritas por programador, mas con relación al producto, resultando en un ciclo de desarrollo de mejor calidad, con menos errores y por lo tanto, con menos tiempo empleado en la corrección de los mismos. El estudio muestra además que, con el método PSP, los errores se detectan ya antes de la fase de test, lo que reduce para menos del 2%, el número de problemas encontrados después de la implantación de la aplicación. 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, también son objetivos del método. Es un proceso de automejoramiento diseñado para ayudar a controlar, administrar y mejorar la forma en que se trabaja individualmente. Está estructurado por formularios, guías y procedimientos para desarrollar software. Si es usado apropiadamente, brinda los datos históricos necesarios para trabajar mejor y lograr que los elementos rutinarios del trabajo sean más predecibles y eficientes. Usando PSP, se pueden construir programas de más de 10,000 líneas de código (LOC), sin embargo, hay dos problemas típicos en los grandes programas. Primero, mientras se crece en tamaño, también lo hace el tiempo y el esfuerzo requerido. Esto puede ser un problema particular si sólo existe un ingeniero en el proyecto. Segundo, la mayoría de los ingenieros tienen problemas en la visualización de todas las facetas importantes de un programa, incluso cuando su tamaño es moderado. Existen muchos detalles e interrelaciones que deben tenerse en cuenta, muchas dependencias lógicas, interacciones en el tiempo o condiciones excepcionales. Una de las formas más 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 evolución similar al que tiene CMM (Evaluación 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 inglés, 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 sólo 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 ningún sentido por lo que es considerado como material de apoyo. Como se ha visto anteriormente el Instituto de la Ingeniería 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 también debe de contar con la más alta calidad posible. La estrategia total de PSP es cerciorarse de que todos los componentes individuales se desarrollen con la más 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 más calidad para mejorar su funcionamiento. El proceso personal de software fue diseñado 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 también muestra cómo aplicar métodos avanzados de ingeniería a sus proyectos y/o deberes diarios. Asimismo provee métodos de estimación y de planeación 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 métodos que se necesitarán más adelante para ir forjando al ingeniero de software. Es importante que la calidad del software desarrollado abarque hasta el más mínimo detalle, por muy pequeño que éste sea, ya que si no se hace así, pueda dañar 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 podrían 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 sería 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 podría tomar para cumplir cuanto antes con los niveles de CMM que se desean alcanzar. Existen resultados que demuestran la eficiencia y una reducción de tiempo considerable cuando se usan estos procesos diseñados para alcanzar los niveles de CMM más rápidamente que si se utilizaran otros "caminos". Hasta ahora se ha visto que PSP tiene sus niveles internos y que también 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 sólo parcialmente. También 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 decisión sobre que puntos tomar

121

de PSP y cuáles 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 común PSP con CMM. De esta manera puede analizarse cuales se podrían aplicar a cada proyecto.

Proceso Personal

Proceso de Calidad Personal

Proceso de Planeación

PSP3

Paso 7 PSP2 Revisión de codificación

PSP2.1 Formato de diseño

Paso 5

Paso 6

PSP1 Estimación del Tamaño

Planeación de diseño

Paso 3 PSP0 Proceso actual Registro de tiempos

Paso 1

PSP1.1

Paso 4 PSP0.1 Estandar de codificación Medición del tamaño Paso 2

Figura 4.9.-"Evolución del proceso personal de Software".

Esta información 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.

Características del PSP. Proporciona una serie de principios al ingeniero para llevar a cabo un proceso personal disciplinado. Asiste a los ingenieros en la realización 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” Administración del Cambio de Proceso Administración del Cambio de Tecnología Pretensión de defectos

Nivel 4 “ADMINISTRADO” Administración De la Calidad Administración del Proceso cuantitativo

Nivel 3 “DEFINIDO” Revisión de Colegas Coordinación entre los grupos Ingeniería de productos de Software Administración Integrada de Software Programa de Entrenamiento Definición de proceso de Software Enfoque en el Proceso de Software

Nivel 2 “REPETIBLE” Administración de la Configuración de Software Aseguramiento de la Calidad de Software Administración del Subcontrato de Software Rastreo y visión 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 diseño de PSP se basa en los siguientes principios de planeación y de calidad. Cada ingeniero es diferente; para ser más eficiente, debe planificar su trabajo basándose en datos tomados de su propia trayectoria profesional. Para mejorar auténticamente 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 más efectivo evitar los defectos que detectarlos y corregirlos. Trabajar bien es siempre la forma más rápida y económica 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 planeación 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 tamaños 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 métodos que necesitarás como ingeniero de sw. La cuestión no es si tú necesitas habilidades personales, sino cuánto tiempo necesitas para desarrollarlas y cómo 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.

GESTIÓN DEL TIEMPO Hacer planes realistas. Intentar seguir el plan. Controlar el uso del tiempo. Determinar errores y cómo 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 cómo 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.

2.

¿Qué factores influyen a la hora de elegir un ciclo de vida para resolver un problema dado?

3. ¿Qué ciclo de vida elegiría para resolver un problema que se comprende bien desde el principio y está muy estructurado? Una vez elegido el ciclo de vida, ¿qué procesos escogería para dicho ciclo de vida, teniendo en cuenta que el desarrollo informático para resolver el problema anterior lo realiza una única persona? 4. Se supone que se va desarrollar una aplicación relativa a la gestión de pedidos de una empresa. En este caso el cliente no tiene todavía muy claro qué es lo que quiere. Además, el personal informático va a utilizar un tecnología que le resulta completamente nueva. Discútase qué tipo de ciclo de vida es más apropiado y qué procesos se deberían utilizar para desarrollar esta aplicación. 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 ningún estándar que describa sus procesos y actividades. c) No se trata sólo de realizar el análisis, diseño, codificación y pruebas; también incluye, entre otros, procesos de soporte. d) El mantenimiento lo constituyen las actividades para mantener sin cambios el sistema. e) En la actividad de análisis de los requisitos software los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema.

125

TÉCNICAS, HERRAMIENTAS Y ESTUDIOS PREVIOS

5.1 TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN

5.1.1 ENTREVISTA 5.1.2 CUESTIONARIO 5.1.3 RECOPILACIÓN Y ANÁLISIS DE DOCUMENTOS 5.1.4 OBSERVACIÓN Y TÉCNICA “STROBE”

5.2 HERRAMIENTAS CASE

5.2.1 ESTRUCTURADAS 5.2.2 ORIENTADAS A OBJETOS

5.3 DESARROLLO DE PROTOTIPOS

126

5.1 TÈCNICAS DE RECOPILACIÒN DE INFORMACIÒN

Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas.

5.1.1 ENTREVISTA

Las entrevistas se utilizan para recabar información en forma verbal, a través 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 proporcionarán datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos. Es una forma de conversación, ¡no interrogación! al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre ese sistema los analistas pueden conocer los datos que no están disponibles en ninguna otra forma. En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son importantes. La información cualitativa está relacionada con opiniones, políticas y descripciones cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de información cualitativa; los otros métodos tienden a ser más útiles en la recavación 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 rápidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aún a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios. Se seleccionará un número de personas para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen información 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 sòlo se aplican a la gerencia o personal de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las entrevistas se aplican en todos los niveles gerenciales de empleados y dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian a la administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los agentes más importantes. La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica 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 aplicación enfocada a la reducción de errores probablemente no tendría éxito; si llegar a una oficina de gerencia de nivel medio con la presentación 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 introducción: “Estamos aquí para resolver su problema”, es igualmente mala. A través 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 información contra estas preguntas, los analistas tendrán más conocimientos no solamente de la información adquirida sino también de su importancia. Planeación de una entrevista Son cinco pasos principales para la preparación de una entrevista, como se indica en la figura 5.1. Estos pasos incluyen una gama de actividades, desde la recopilación de antecedentes, hasta la decisión de a quién entrevistar.

Lectura de antecedentes Establecimiento de los objetivos de la entrevista Selección de los entrevistados Preparación del entrevistado

Selección del tipo y la estructura de las preguntas

Figura 5.1.- Pasos para la planeación de una entrevista.

Lectura de antecedentes.- Consultar y comprender el mayor número posible de antecedentes de los entrevistados y de su organización. Estos se obtienen frecuentemente de manera sencilla por medio de una llamada telefónica a su contacto, pidiéndole un informe anual reciente, un boletín corporativo o cualquier comunicación que explique al público las características de la organización. Conforme se lea este material, se fija bien en el tipo de lenguaje que los miembros de la organización utilizan para describirse y describir a la organización. 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 organización es aprovechar al máximo el tiempo de la entrevista, más 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 información y al proceso de la toma de decisiones sobre los cuales se deseará hacer preguntas. Estos incluyen: las fuentes de información, los formatos de la información, la frecuencia de la toma de decisiones, la calidad de la información y el estilo de la toma de decisiones. Selección de los entrevistados.- Cuando se decida a quiénes se entrevistara, se incluirá a la gente clave de todos los niveles del sistema, es importante una muestra de los miembros de la organización 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 organización dará una idea clara sobre quiénes deberían ser entrevistados. Preparación del entrevistado.- Preparar a la(s) persona(s) que entrevistará, avisándole 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 interés 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 más de una hora, es muy probable que el entrevistado lamente su visita, aunque no exprese tal sentimiento. Selección 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 técnicas inquisitivas adecuadas. Las preguntas tienen ciertas estructuras básicas que se deben conocer. Los dos tipos básicos 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 pirámide, de estructura de embudo y la estructura de diamante. Cada uno de ellos es adecuado para condiciones particulares. A continuación se presentan una serie de decisiones importantes que el entrevistador debe tomar. Estas incluyen qué preguntas realizar y cómo plantearlas, si se estructura la entrevista y cómo 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 “¿Podría explicarnos cómo toma sus decisiones sobre la programación?”. Considere el término abierta. “Abiertas” son las opciones que el entrevistado tiene para responder. Puede ser una respuesta de dos palabras o de dos párrafos. En la figura 5.3 se presentan algunos ejemplos de preguntas abiertas.

129

Tipo de preguntas Documentación Abierta Cerrada Exploratorias

Grabación Cuaderno de notas

DECISIONES IMPORTANTES DEL ENTREVISTADO

Estructura de la entrevista

No estructurada

Estructurada

Pirámide Embudo Diamante

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

1.

¿Cuál es su opinión del sistema de cómputo actual?

2.

¿Cómo ve los objetivos de este departamento?

3.

¿Cómo se relaciona esta forma con el trabajo que usted desempeña?

4.

¿Cuáles son algunos de los problemas que percibe respecto a recibir oportunamente la información?

5.

¿Cuáles son los errores más comunes en la captura de los datos en este departamento?

6. Describa el sistema de cómputo más 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 educación, valores y creencias. c) Proporcionan una gran riqueza de detalle. d) Revelan nuevas alternativas sobre preguntas no consideradas. e) Hacen más 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 información irrelevante. b) La posible pérdida del control de la entrevista. c) Permiten respuestas que pueden llevar demasiado tiempo para la cantidad de información 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 básico de preguntas, las preguntas cerradas, las cuales tienen como estructura básica: “¿Cuántos subordinados tiene usted?”. Las posibles respuestas se encuentran limitadas para el entrevistado, ya que sólo puede responder con un número finito, tal como “ninguno”, “uno” o “quince”. Algunos ejemplos de preguntas cerradas se encuentran en la figura 5.4.

1.

¿Cuántos informes genera en un mes?

2.

¿Durante cuánto tiempo ha trabajado con los hermanos Bakerloo?

3.

De las siguientes fuentes de información, ¿cuáles son las más valiosas para usted? a. Formas de reclamación llenadas por los clientes b. Relación cara a cara con los clientes c. Devolución de la mercancía Enumere dos prioridades principales para el departamento de mercadotecnia en 1986.

4.

¿Quién recibe este reporte? Figura 5.4.- Ejemplo de preguntas cerradas en la entrevista.

Limita las respuestas disponibles del entrevistado porque son aquellas de opción múltiple 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 aún más limitativa al tener sólo 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.

¿Utiliza microcomputadoras?

2.

¿Estará usted de acuerdo o en desacuerdo con que la automatización de las funciones de los cajeros sería de gran valía?

3.

¿Desea recibir mensualmente un reporte hecho en computadora de su status contable?

4.

¿Ofrece su departamento contable transferencia electrónica automática de cheques de nómina para que trabajan por hora?

5.

¿Estará completa esta forma?

Figura 5.5.-Ejemplo de preguntas bipolares de entrevista.

131

Ventajas: a) b) c) d) e) f)

Ahorran tiempo. Facilitan la comparación entre entrevistas. Llegan al punto de interés. Mantienen el control de la entrevista. Cubren rápidamente 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 armonía 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 elección de un tipo respecto del otro tiene un costo. Mientras las preguntas abiertas ofrecen amplitud y profundidad en la respuesta, estas respuestas son difíciles de analizar. ABIERTA

CERRADA

Baja

Confiabilidad de losa datos

Alta

Bajo

Uso eficiente del tiempo

Alto

Baja

Presión de los datos

Alta

Muchas

Amplitud y profundidad

Poca

Muchas

Habilidad requerida en el entrevistador

Poca

Dificil

Facilidad del análisis

Fácil

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

Sondeo.- Es el más simple, es la pregunta “¿Por qué?”. Otras serían, “¿Podría darme un ejemplo?” y ¿Podría dar más detalles? El propósito del sondeo es ir más 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 mayoría 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 sistemática y determinada, le servirá para mostrar a su interlocutor que escucha lo que él dice, pensando al respecto y respondiendo adecuadamente. Más 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 organización inductiva de la entrevista puede concebirse como una pirámide. Mediante el uso de esta estructura, el entrevistador inicia la entrevista con preguntas detalladas, con frecuencia del tipo cerradas. El entrevistador ampliará luego los tópicos, haciendo preguntas abiertas, y en consecuencia, respuestas de carácter más generalizado, como se muestra en la figura 5.7. Debe utilizar una estructura piramidal cuando crea que su entrevistado requiere de una introducción hacia el tópico. También es muy útil si el entrevistado se niega a involucrarse en el tópico. 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 pronósticos, a lo mejor estructuraría la entrevista como una pirámide. También es útil el uso de una estructura piramidal para encadenar preguntas cuando desee llegar a una conclusión final del tópico. Tal es el caso de la pregunta final, “¿En general, qué es lo que usted piensa acerca de los pronósticos?”.

Y concluye con una general

¿Cuál es el problema especifico de su modelo de pronósticos? ¿Has considerado obtener una información más actualizada? Las estructuras piramidales comienzan con una pregunta especifica

En general ¿cuál es su opinión acerca de los pronósticos?

Figura 5.7.- Estructura piramidal para la entrevista.

133

Estructura de embudo. El entrevistador toma el enfoque deductivo, comenzando con preguntas abiertas de carácter general; y más 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 sentirán presión alguna al dar respuestas “erróneas” a preguntas abiertas. La secuencia en la estructura de embudo también es útil cuando el entrevistado está involucrado sentimentalmente con el tópico 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 información tan detallada, que haga innecesarias las largas secuencias de preguntas cerradas y de sondeo.

¿Cuál es su reacción sobre el nuevo sistema de cómputo? ¿Qué computadoras utiliza?

Las estructuras de embudó comienzan con una pregunta general

¿Cuál es el costo del nuevo sistema de cómputo? Con base en su costo ¿vale la pena el nuevo sistema de cómputo?

Y concluye con una especifica

Figura 5.8.- Estructura del embudo para la entrevista.

Estructura en forma de diamante. Es la combinación 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 específica, luego examinar aspectos generales y finalmente llegar a una conclusión muy específica, 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 opinión sobre tópicos generales, que obviamente no logran una respuesta “correcta”. Por último, el entrevistador replanteará las preguntas con mayor precisión, 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 más tiempo. La principal ventaja del uso de una estructura de diamante es que mantiene el interés y la atención de su entrevistado, mediante la variedad de las preguntas.

134

Las estructuras de diamante comienzan con una pregunta especifica ¿Cómo realizar sus decisiones sobre las distribuciones?

Se orienta a preguntas más generales

¿Cree que podría enseñarle a alguien a tomar este tipo de decisiones? ¿Qué necesitaría para establece reglas de decisión, 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 distribución? Y Concluyen con una pregunta especifica

Figura 5.9.- Estructura de diamante para la entrevista.

5.1.2 CUESTIONARIO

Constituyen una técnica de recopilación de información que permite a los analistas de sistemas recoger opiniones, posturas, conductas y características de las diversas personas claves de una organización, que se encuentran involucradas en la operación de un sistema actual o en la implantación de uno nuevo, tal y como se muestra en la figura 5.10. La actitud es el deseo que plantean las personas de una organización (por ejemplo, sobre un nuevo sistema); la opinión es lo que se piensa de la realidad; la conducta es lo que hacen los miembros de una organización, y las características 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. Además, 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 también 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 programación de una serie de entrevistas.

135

Mediante el uso de cuestionarios, el analista puede cuantificar los resultados de las entrevistas. Además, 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 también 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 programación de una serie de entrevistas.

R

IO

CONDUCTAS

TI O N

A

ACTIVIDADES OPINIONES

C

U

ES

CARACTERÍSTICAS

Figura 5.10.-Tipo de información que se exploran por medio de cuestionarios.

Planeación para el uso de cuestionarios A primera vista, los cuestionarios pueden verse como una forma rápida de recopilar cantidades masivas de datos acerca de la opinión 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 volúmenes de información sin requerir entrevistas personales, el desarrollo y la planeación 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 información que les presente nuevos paquetes de software, estonces serían los cuestionarios los más convenientes. Si desea realizar un análisis profundo sobre un proceso de toma de decisiones en la gerencia, entonces la mejor elección sería la entrevista. A continuación 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 corporación). 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 característica particular del sistema propuesto.

136

c) Lleva a cabo un estudio exploratorio y desea medir la opinión general, antes de que el proyecto de sistemas tome una dirección 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 razón para hacer uso de los cuestionarios y ha precisado los objetivos a satisfacer mediante su uso, puede entonces, iniciar la formulación de preguntas.

Redacción de preguntas La mayor diferencia que presentan las preguntas de entrevista y las preguntas de cuestionarios, es que durante la entrevista se mantiene la relación entre la pregunta y su significado. En una entrevista, el analista tiene la oportunidad de afinar una pregunta o un término difícil, 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 básicos 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 opción de respuesta. Por ejemplo: “Describa cualquier problema que en la actualidad experimente con los reportes de salidas”, o “¿Cuál es su opinión 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 desperdiciarán recursos importantes en el desarrollo, la aplicación y la interpretación de un cuestionario inútil. Por ejemplo, si hiciera una pregunta tal como, “¿cuál es su posición ante el sistema?” Las respuestas pueden ser demasiado amplias para una interpretación o comparación 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 específica. 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 opinión de los miembros de una organización 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 también son útiles para explorar situaciones,esto se presenta cuando el analista no es capaz (por la dispersión de los empleados) de establecer con precisión, los problemas que presenta el sistema actual. Las respuestas a preguntas abiertas sirven para centrarse en problemas más específicos, mediante entrevistas a las personas clave que toman las decisiones.

137

53. ¿Cuáles son los problemas más frecuentes con los que se enfrenta en las salidas de la computadora? A ______________________________________ B_______________________________________ C_______________________________________ ________________________________________ 54. De los problemas enumerados arriba ¿cuál de ellos es el más grave? _________________________________________ _________________________________________ _________________________________________

Las preguntas abiertas piden de quien corresponde

Respuestas detalladas

55. ¿Por qué? _________________________________________ _________________________________________ _________________________________________ A continuación, tenemos preguntas acerca de usted. Por favor llene los espacios en blanco de acuerdo con sus características. 67. ¿Durante cuánto tiempo ha trabajado con esta compañía? _______ años ________meses

O respuestas cortas

68. ¿Durante cuánto tiempo ha trabajado en esta compañía? _________años _______meses 69. ¿Cuál es tu edad? _______años

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

Preguntas cerradas.- Limitan o restringen el número disponible de opciones de quien responde al cuestionario. Por ejemplo, en la figura 5.13, el planteamiento: “A continuación tenemos los seis paquetes de software disponibles en el centro de información. Anote cuál 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 más de uno, aunque así se tendría una respuesta más representativa. Se deben utilizarse cuando el analista sea capaz de enumerar de antemano todas las respuestas posibles. También, las respuestas planteadas deben ser mutuamente exclusivas, de forma tal que al elegir una de ellas no implique la elección 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, sería imposible un análisis e interpretación correcta de las respuestas (sin el auxilio de un programa computarizado de análisis de contenidos).

138

La elección del vocabulario Así como en las entrevistas, la selección de las palabras también es de gran relevancia para lograr que los cuestionarios sean efectivos. Aún si el analista de sistemas cuenta con un conjunto estándar de preguntas, referente al desarrollo de sistemas, es prudente redactarlas de nuevo para reflejar la terminología propia de la empresa. Quienes responden los cuestionarios apreciarán el esfuerzo realizado en la preparación 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 información tiene disponible. Por favor señale 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

Las preguntas cerradas se pueden solicitar que se respondan marcando cuadros

Que se encierre en un círculo, un número

SIEMPRE 5

Conteste las preguntas 45-48 encerrando en un circulo el numero apropiado. 45.- La división 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 MÁS

47. Mi sexo es: MASCULINO FEMENINO

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

A continuación, 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 redacción sencilla. b) Sea específico, sin embargo, evite preguntas sumamente específicas. 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 redacción. Esto también 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) Asegúrese que las preguntas sean técnicamente precisas, antes de incluirlas.

139

Escalar es el proceso de asignar números u otros símbolos a un atributo o característica con el fin de poder medirlo. Con frecuencia, las escalas son arbitrarias y no llegan a ser únicas. El analista necesita diseñar escala para: 1. Medir.-Existen cuatro formas de escalas de medición, cada una de ellas ofrece diferentes grados de precisión. La forma de medir también dicta la manera de analizar los datos recopilados. Las cuatro formas de medición son: a. Nominal.- Se utilizan para clasificar objetos. La siguiente pregunta hace uso de una escala nominal: ¿Cuál es el tipo de programa que más utiliza? 1) Procesador de textos. 2) Hoja de cálculo. 3) Base de datos. 4) Programa de graficación. Es obvio que las escalas nominales son las formas más débiles de medición. En general, a lo más que el analista puede llegar es a obtener totales de cada categoría. b. Ordinal.- Al igual que las escalas nominales permiten la clasificación, sin embargo, la diferencia es que la escala ordinal implica además un arreglo por categorías. En este ejemplo, un analista de sistemas le pide al usuario final que encierre en un círculo alguno de los números:

El personal del centro de información es: 1) 2) 3) 4) 5)

Extremamente útil. Muy útil. Moderadamente útil No muy útil. Nada útil.

Son útiles las escalas ordinales porque una categoría 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 característica que la diferencia que existe es la misma entre los intervalos de cada uno de los números. Debido a esta particularidad, las operaciones matemáticas pueden realizarse sobre datos del cuestionario, permitiendo un análisis más completo. Como ejemplos de escalas de intervalo tenemos a las escalas Fahrenheit y centígrada para medir la temperatura. El ejemplo previo sobre el centro de información, en efecto, no hace uso de una escala de intervalo, pero al asignarle una escala que tome los atributos extremos, el analista podría suponer que el que contesta percibe como equivalentes a los intervalos: ¿Qué tan útil es el apoyo ofrecido por el personal del centro de información?

Nada útil 1

2

3

Extremadamente útil 4 5

Si el analista de sistemas toma en cuenta este supuesto, será posible contar con un análisis más cuantitativo.

140

b) Proporcional.-Es similar a las de intervalo porque se supone que los intervalos entre los números son iguales. Sin embargo, las escalas proporcionales cuentan con un cero absoluto. Un ejemplo sería la distancia que mide una regla. Otro ejemplo sería el siguiente: De manera aproximada, ¿cuántas horas dedica diariamente a la computadora? 0

2

4

6

8

El analista usa poco las escalas proporcionales. Como lineamiento, un analista de sistemas debería 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. DISEÑO DE CUESTIONARIOS.- Muchos de los principios relevantes en el diseño de formas para la captura de datos, también son importantes aquí. Si bien el motivo de un cuestionario es recopilar actitudes, opiniones, conductas y características cuyo impacto llegará a afectar el trabajo de los usuarios, los que responden los cuestionarios no están 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 concepción pobre o son triviales. Un cuestionario bien diseñado y de relevancia elimina cierta resistencia para responder. El formato del cuestionario es: Disponga suficiente espacio en blanco. La consideración de mayor importancia en el diseño 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 página. Un cuestionario que sea compacto, que no cuente con espacio en blanco, será poco atractivo para llenarlo, aunque se use menos papel para su impresión. Para incrementar la tasa de respuesta, use exclusivamente papel blanco al imprimir los cuestionarios. Disponga del espacio adecuado para las respuestas. Además de incluir suficiente espacio en blanco, deje suficiente espacio para anotar la respuesta. Si se deben responder preguntas abiertas con un párrafo, deje para ello entre tres y cinco renglones. Use círculos para las respuestas. Otra buena práctica para el registro de una respuesta correcta es solicitar a quien resuelve el cuestionario que encierre en un círculo la respuesta (o el número si emplea escalas) que elija. La figura 5.13 muestra lo que puede ocurrir si no solicitamos de manera explícita que se encierre la respuesta por medio de círculos. 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

1

RARA VEZ

EN OCASIONES

2

3

EN GENERAL

4

SIEMPRE

4

5

Figura 5.13.-Utilización del círculo para la respuesta.

En ocasiones, se selecciona la respuesta mediante el registro dentro de un cuadro de corchetes, o el espacio interno entre dos paréntesis. Sin embargo, debe dejar espacio suficiente para aquellas personas que hacen marcas de gran tamaño. La tabulación de datos y el análisis se dificulta, si quien responde el cuestionario selecciona inadvertidamente varias opciones. Use los objetivos como ayuda para establecer el formato. Antes de diseñar el cuestionario, se necesita definir los objetivos. Por ejemplo, si el objetivo es dirigir las encuestas al mayor número posible de miembros de una organización, con respecto a una lista de problemas identificados en el sistema actual, es posible utilizar formas de respuesta capturadas por medios ópticos o mecánicos. Esto afectaría en sí, el diseño 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 asegúrese de incluir dicho espacio en la forma o en una hoja anexa. Quizás se necesite planificar que, tanto para las respuestas numéricas 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, también es una oportunidad para eliminar errores de captura de datos que las personas sin experiencia pudieran ocasionar al contestar. Además, aquellas hojas de cuestionario que permiten escribir directamente la respuesta, son más fáciles de llenar por quienes deben contestar que las formas especiales de captura de respuestas por medios ópticos o mecánicos. Mantenga un estilo consistente. Organizar de manera consistente el cuestionario. Colocar las instrucciones siempre en el mismo sitio, e relación a la subsección de las preguntas, de tal forma que quienes contestan sepan en dónde encontrar las instrucciones. Utilizar letras mayúsculas y minúsculas para las preguntas y sólo mayúsculas al referirse a las respuestas. Mantener de manera consistente este formato le permitirá a los que contestan, responder de manera rápida y reducir el riesgo de error. Otro aspecto importante del diseño 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 RECOPILACIÓN Y ANÁLISIS DE DOCUMENTOS Durante la investigación, se está sumergido en la búsqueda 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 información que no puede obtenerse por otros métodos, como la entrevista y la observación.

CONTEXTO DE LA ORGANIZACIÓN

D

HECHOS Y DATOS

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

Aunque las organizaciones producen datos concretos como un producto genérico “para quien le interese”, se debe recordar el significado que tuvieron cuando los miembros de la organización los generaron. Por lo tanto, se vuelve importante definir para quiénes fueron emitidos originalmente y por qué se conservan. En otras palabras, se necesita comprender la relevancia del documento dentro de la organización; en general, las organizaciones con un buen soporte en documentación llegan a ser más rígidas que las empresas que operan con una mínima documentación, ya que la documentación sirve para la creación de un control centralizado de dirección única.

INFORMACIÓN FINANCIERA TIPOS DE DOCUMENTOS Y PROBLEMÁTICAS

Figura 5.14.-Tipos de información obtenida durante la investigación

Los documentos, dentro de una organización, transmiten mensajes persuasivos, dando indicios de la conducta de sus integrantes. También se debe considerar que los cambios en la documentación pueden repercutir en cambios de la organización. Los tipos de datos concretos revelan la trayectoria de la organización y hacia dónde se dirige según sus miembros. Con el fin de conformar una imagen precisa, el analista necesita examinar ambos tipos de datos concretos, los cualitativos y los cuantitativos.

143

Análisis de los documentos cuantitativos Existe toda una variedad de documentos cuantitativos disponibles para la interpretación de cualquier empresa. Entre ellos se incluyen los informes corporativos, los informes utilizados para la toma de decisiones, los informes de desempeño 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 depreciación acumulada Neto de activos fijos Activos totales Pasivos Pasivo circulante Cuentas por pagar Títulos 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

1986

440,000 800,000 2,000,000 2,800,000 6,040,000

970,000 450,000 1,800,000 2,900,000 6,120,000

500,000 3,000,000 800,000 100,000 4,400,000 1,000,000 3,400,000 9,440,000 1987

500,000 2,500,000 750,000 90,000 3,840,000 900,000 2,940,000 9,060,000 1986

1,000,000 850,000 550,000 340,000 2,740,000 3,000,000 5,740,000 1987

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,400,000 3,700,000 9,440,000

500,000 1,000,000 800,000 1,300,000 3,600,000 9,060,000

Tabla 5.1.- Balance general de la corporación.

Informes corporativos. La ley exige por mandato y regulación que las firmas proporcionen informes corporativos o informes anuales para la emisión de acciones públicas. El analista externo puede obtener un panorama de la corporación, mediante la consulta de informes anuales consecutivos. Hay varios tópicos clave, si la compañía es solvente, si obtiene utilidades, si le confiere una distinción a la investigación 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 organización. Las cantidades dan indicios de la fortaleza de la empresa y permiten al analista deducir el monto de la inversión más adecuada para su sistema de computación. El estado de pérdidas y utilidades compara el desempeño de la compañía respecto a otros años para saber si ésta obtuvo utilidades o pérdidas. El analista puede examinar los ingresos o el estado de pérdidas y utilidades, y a primera vista tendrá una idea mejor de la organización. 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 operación de la empresa. Estos documentos comúnmente son informes del status de los inventarios, de las ventas o de la producción. Muchos de ellos, si bien no llegan a ser muy complejos, sirven como retroalimentación para tomar acciones inmediatas. Como ejemplo, veamos el caso de un informe de ventas que resume el volumen y el tipo de las ventas. Además, estos informes incluyen gráficas comparativas de los ingresos y las utilidades para una serie de periodos. Esto facilita a quien toma las decisiones, la concepción de tendencias globales. Los informes de producción incluyen aspectos relativos a los costos recientes, a los inventarios actuales, a la mano de obra involucrada y a la información básica de la planta. Más allá de estos informes fundamentales se tiene una serie de resúmenes, que sirve de antecedente para la toma de decisiones o que exponen las excepciones de la operación normal, así como panoramas estratégicos de los planes de la organización. Informes de desempeño. La mayoría de los informes de desempeño 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 desempeño actual y el desempeño esperado. Sirve también para determinar si la tendencia de la diferencia se acorta o se amplía, para cualquier tarea que se inspeccione. Registros. Los registros contienen actualizaciones periódicas de lo que ocurre en la empresa. Si la actualización es continua y cuidadosa, conferirá al analista información útil. Hay diferentes maneras para la inspección de un registro, entre las cuales destacarían las siguientes: 1)Verificación de la ausencia de error en las cantidades y los totales. 2)Búsqueda de oportunidades para mejorar el diseño de la forma de registro. 3)Observación del número y el tipo de transacciones. 4)Identificación de los casos que se simplificarían por el uso de computadoras (esto es, cálculos y otras manipulaciones de datos).

Formas para la captura de datos. Antes de que se disponga a modificar el flujo de información dentro de la organización, debe comprender la operación del sistema vigente. Usted o alguno de los integrantes de su equipo desearán 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 específicamente de la administración 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 distribución, se comparan con las formas que ya están llenas, y se advertirán 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 estándar para su uso, almacenamiento o eliminación.

145

A continuación se presenta un procedimiento para crear un catálogo de formas, que nos auxilie a entender el tipo de información 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 distribución especificado originalmente. 4) Compare el proceso intentado de distribución especificado originalmente con el que actualmente recibe la forma. Aunque lo anterior es tedioso, no deja de ser útil. Otro enfoque sería 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? ¿Cuáles se omiten consistentemente? ¿Por qué razón? 2)¿Hay formas que nunca han sido utilizadas? ¿Por qué? (Verifique el diseño y la validez de la forma para la supuesta función.) 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 estándar, o quizás, dar indicio de la existencia de ciertas pugnas políticas dentro de la organización.) 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 sintomáticos de problemas mayores, son los siguientes: 1)Los datos o la información 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 información ya existe o se presenta de forma distinta, y no la reciben. 4)Una falta de comprensión acerca de la interrelación del flujo de la información (esto es, los empleados ignoran que su trabajo de salida sirve de entrada para otros).

Análisis de documentos cualitativos Existen en la organización toda una serie de documentos que no son cuantitativos. Aunque los documentos cualitativos no siguen lineamientos preestablecidos, su análisis se vuelve fundamental para comprender cómo los integrantes de la organización están involucrados en el proceso de la organización. Los documentos cualitativos incluyen memorándums, avisos pegados en tableros y áreas de trabajo, manuales de procedimientos y de políticas. Muchos de ellos revelan las

146

expectativas de conducta que sus redactores esperaban de los miembros de la organización. Existen varios lineamientos para mantener enfoques sistemáticos en el análisis, que son: 1)Examinar los documentos para identificar aquellas metáforas 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 términos 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 interpretación de los documentos cualitativos, y en efecto, existen otros enfoques que van más allá del análisis requerido. El examen de los documentos en búsqueda de metáforas que den pautas, se debe a que el lenguaje se adapta a la conducta, y en consecuencia, aquellas metáforas empleadas se vuelven relevantes. Por ejemplo, una organización que denomina a los empleados “integrantes de una gran maquinaria” o “los dientes de un engrane” está tomando un enfoque mecánico de la organización. Note la metáfora “formamos parte de una familia feliz”, que da la pauta del memorándum de la figura 5.16. Se puede usar lo anterior para predecir el tipo de metáforas que serán persuasivas en la organización, así como para entender la manera de caracterizar en forma de metáfora un nuevo sistema.

147

GRANJA DE LA FORTUNA

FECHA _________ Nombre de la tienda _________________________ Numero de la tienda _________________________ Productos solicitado

Cajas

Leche (2 litros) Entera 2% 1% Descremada Mantequilla Chocolate

Productos solicitado

La forma oficial puede saturar a la gente, al solicitarle demasiada informacion.

Cajas

Leche (1 litros) _______ _______ _______ _______ _______ _______

Entera 2% 1% Descremada Mantequilla Chocolate

________ ________ ________ ________ ________ ________

La formas puede carecer de un orden lógico

Yoghurt Natura Vainilla Durazno Zarzamora Mora Fresa

_______ ________ _______ ________ ________ ________

Piña Manzana Plátano Tutifruti Frambuesa Limón

________ ________ ________ ________ ________ ________

1 litro Deluxe 1 ½ litro Deluxe 1 litro Premium

________ ________ ________

¿Se necesita realmente el total?

Helado ½ litro Deluxe 2 litro Deluxe Barquillos

________ ________ _________

Total de cajas ordenadas: _____________

Solicitado por (número de empleado)_______ Motivo de la escasez_________________________________________________ _ Número de chofer: ______ Número de ruta: ________ Tienda ____________ Fecha:_________ Chofer:_____

Formas improvisadas que surgen para simplificar los problemas

Producto agotado _____________Cajas requeridas____ Producto agotado _____________Cajas requeridas____ Producto agotado _____________Cajas requeridas____ Producto agotado _____________Cajas requeridas____ Iníciales del gerente de lácteos:____________________

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 políticas existentes. Es obvio que si un departamento está en pugna con otro, será imposible obtener su cooperación para el proyecto de sistemas, mientras no se solucione de manera satisfactoria el problema existente.

148

MEMORÁNDUM 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 día nos hace sentir como toda una familia feliz. Recuerden que en los descansos de esta noche, algunos han traído alimentos. Sírvanse ustedes mismos y demos a Twyla y Al la más cordial bienvenida a nuestro clan.

Figura 5.16.- Análisis de los memorándums que orientan a la organización

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 interés para mantenerse en liderazgo competitivo. La enumeración de aquellos términos 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 acumulación excesiva de documentos se señala 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 sólo “por si acaso”. Memorándums. Cuando sea posible, el analista debe sondear los memorándums que circulan dentro de la empresa. Sin embargo, los memorándums no se conservan o tienen acceso a ellos, sólo los que “deben saberlo”, como lo definen las políticas de la organización. Junto con los cuatro lineamientos anteriores, el analista debe considerar también quiénes son los emisores de los memorándums y quiénes los reciben. Por lo general, la mayor parte de la información de la organización fluye hacia abajo y horizontalmente y no hacia arriba. Los memorándums revelan el diálogo vivo de la organización. El análisis del contenido de los memorándums proporciona una idea clara de los valores, las actitudes y creencias de los miembros de la organización. Avisos en tableros y en áreas de trabajo. Aunque éstos parecieran incidentales a lo que ocurre en la organización, 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 organización. También conviene identificar hacia quiénes se dirigen los avisos, y determinar, mediante entrevistas, si los miembros de la organización los toman en cuenta. Manuales. Otro tipo de documentos cualitativos son los manuales de la organización, incluyendo aquéllos concernientes a la operación 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 memorándums. Recuerde que los manuales reflejan un “ideal” de la conducta que esperamos del equipo y de las personas. La revisión sistemática de los manuales le dará la pauta de cómo

149

debería ocurrir las cosas. Es conveniente recordar que los manuales rara vez se mantienen al día y, en ocasiones, se aíslan 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 reunión de carácter empresarial, surgió el tópico 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 determinación al respecto es que ustedes deberán pensar antes de archivarlos. El monstruo de papel llegó a más de una de nuestras oficinas y los archivos voluminosos se vuelven cada vez más caros. Me niego rotundamente a autorizar cualquier partida adicional para nuevos archiveros. La mayoría de las secretarias de departamentos conservan en archivo, la correspondencia relevante, los informes y los memos oficiales; la computadora tiene aún más información. Por lo tanto, no se conviertan en “ratas pepenadoras”. Si su secretaria los conserva, ustedes deben tirarlos. Figura 5.17.- Revelación de los valores, las actitudes y las creencias de los miembros de las organizaciones, respecto al uso de la información.

Manuales de políticas. Mientras estos cubren típicamente amplios aspectos de la conducta de la organización y de sus empleados, deberá adentrarse en aquellos que se refieran a las políticas del uso, acceso y cargos de los servicios de cómputo. Las políticas son los lineamientos generales que plantean, de manera ideal, la conducta a seguir de los miembros de la organización, con el fin de alcanzar las metas estratégicas, como se plantea en la figura 5.18. Una vez más, los miembros pueden ser indiferentes a las políticas particulares, o bien, las hacen a un lado a propósito, en nombre de la eficiencia o la simplificación. Sin embargo, la consulta de las políticas permite al analista de sistemas darse cuenta de los valores, las actitudes y las creencias que guían a la corporación.

Obtención de datos a partir de documentos de archivo. Gran parte de la información, tanto cuantitativa como cualitativa, que se necesita, no es de uso corriente; más bien, se encontrará almacenada en archiveros. Cierto material se guarda por mandato gubernamental, por práctica contable o porque la empresa produzca información histórica por una solicitud formal

150

MANUAL DE LAS POLITICAS DE CÓMPUTO DE VEPCO Pagina 7 Sección 8

Los manuales de políticas indican la manera ideal de hacer las cosas

8.1 Todos los empleados que soliciten servicios de cómputo se encuentren fuera del centro de información deberán solicitarlos formalmente por escrito al departamento de sistemas informáticos 8.2 Sólo los empleados autorizados podrán hacer requisiciones 8.2.1Los requisitos se deben de presentar en la forma apropiada e incluirán la fecha de la solicitud, el número 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 atenderán con base a la primeras entradas, serán las que atienden primero. 8.3.1 Cuando el personal del departamento de sistemas lo considere pertinente una requisición podrá clasificarse como “Urgente” lo cual permite que los requisitos se cumplan.

MANUAL DE LAS POLITICAS DE COMPUTO Página 8 Sección 9 PRESTAMO A MICROCOMPUTADORAS PREMISAS Una analista se sorprenderá al encontrar políticas ya existentes.

DOMICILIO CON BASE EN

DE LAS

9.1 Los empleados podrían solicitar un préstamo de algunos de los equipos portátiles de microcomputadoras disponibles incluyendo las microcomputadoras, las lectoras de discos y algunos programas de software. 9.1.1 Se requiere de un depósito para cada artículo y programa de software. 9.2El depósito se puede entregar al cajero en turno

Figura. 5.18.- Manual de políticas.

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ó desconocía que se estudiarían. Desventajas del uso de datos de archivo 1. Existe cierta incertidumbre acerca de que los datos sean sólo una parte de la información original. 2. Los registros existentes pueden no ser los de mayor importancia o los más significativos. 3. Por algún motivo pudo haber parcialidad cuando se decidió qué archivar. 4. Es difícil obtener datos nuevos de muestras equivalentes.

Figura 5.19.-Ventajas y desventajas en el uso de información de archivo por el analista de sistemas.

151

Además de todas las precauciones precedentes, existen lineamientos que permiten una valiosa selección 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 fenómeno, por diferentes analistas (o tal vez, por alguien dentro de la organización). 3) Estar consiente de la parcialidad inherente asociada a las decisiones originales para archivar la información, conservarla y/o destruirla. 4) El uso de otros métodos para perfilar la imagen de la organización, tales como la entrevista y la observación, y realizar además una verificación cruzada.

5.1.4

OBSERCAIÓN Y TÉCNICAS “STROBE”

Una técnica de recopilación de información de gran importancia para el analista de sistemas es aquella que se funda en la observación del tomador de decisiones y de su ambiente físico. A través de la observación de las actividades de los tomadores de decisiones, el analista profundiza en lo que se hace, y no sólo lo que se dice o se tiene documentado. Además, mediante la observación del tomador de decisiones, el analista procura identificar en primera instancia, las relaciones existentes entre los tomadores de decisiones y los demás miembros de la organización. Al observar el ambiente de trabajo, el analista de sistemas trata de encontrar el significado simbólico del ambiente donde labora el tomador de decisiones. El analista examina los elementos físicos del sitio de trabajo, buscando la influencia de la conducta del tomador de decisiones. Además, mediante la observación de los elementos físicos bajo control del tomador de decisiones (vestimenta, ubicación 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 observación, la influencia de quien toma las decisiones sobre los demás elementos de la organización. Todos estos tipos de información se resumen en la figura 5.20.

ACTIVIDADES

RELACIONES

MENSAJES

INFLUENCIAS

Figura 5.20.- Tipos de información cuando se observa la conducta del tomador de decisiones.

152

Los analistas de sistemas hacen uso de la observación por múltiples razones. Una de ellas es obtener información sobre los tomadores de decisiones y su ambiente, que ningún otro método podría proporcional. La observación también 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 métodos encontraron. Si realmente se está interesado en interpretar los hallazgos de la observación, ésta debe ser estructurada y sistemática. Por ello, es fundamental que el analista de sistemas esté consiente de lo que observa. Debe tener gran cuidado y reflexionar sobre qué y quiénes serán sujetos de observación, así como cuándo, dónde, por qué y cómo. No es suficiente darse cuenta de que la observación es sólo una necesidad. La observación de las actividades de los tomadores de decisiones sólo es una forma de averiguar sus necesidades de información. El ambiente físico en el cual desempeñan sus actividades los tomadores de decisiones, también revela sus requerimientos de información. Muchas veces, esto implica examinar de manera sistemática 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 físico que los rodea. Al método de Observación Estructurada del Ambiente se le denomina como STROBE (STRucture OBservation of the Enviroment). Como toda metodología, el STROBE es sistemático: 1)Porque proporciona un método y clasificación estándar para el análisis de los elementos de la organización que participan en la toma de decisiones. 2)Permite que cualquier otro analista de sistemas aplique la misma estructura analítica a la misma organización. 3)Limita el análisis de la organización 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 información, así como dar información referente a la credibilidad del tomador de decisiones dentro de su ámbito de trabajo. 1.- Ubicación de la oficina. La oficina del tomador de decisiones con respecto a las demás oficinas; las oficinas accesibles tienden a incrementar la frecuencia de relación y las comunicaciones informales, mientras que aquellas oficinas inaccesibles tienden a reducir tal relación y a incrementar los mensajes orientados a la tarea. Las oficinas que se distribuyen en el perímetro del edificio, originan comúnmente informes o memorándums emitidos por una de las oficinas, mientras que las oficinas agrupadas favorecen que la información se comparta. También es factible que la gente que se encuentra en oficinas distantes, tienda a ver de manera diferente a la organización y a desviarse en sus objetivos, más que otros miembros de la organización. 2.-Ubicación del escritorio del tomador de decisiones. La ubicación 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 posición máxima de autoridad. Un ejecutivo cuyo escritorio ve hacia la pared con una silla lateral para el visitante, probablemente favorecerá la participación y un intercambio al mismo nivel. Los analistas de sistemas deben notar el arreglo del mobiliario de la oficina, en particular la posición del escritorio. 3.- Equipo fijo de oficina. Los archiveros, los libreros y todo aquel mobiliario para almacenar artículos se incluyen en la categoría 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 presumiría que el tomador de decisiones le da gran valor a la información.

153

4.-Artículos personales (Props). Los artículos personales, o props (abreviatura del término fílmico properties) son todos aquellos objetos personales que se utilizan para procesar información. Estos incluyen las calculadoras, terminales de video, plumas, lápices, 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 periódicos. La observación del tipo de publicaciones que conserve en su oficina puede revelar si el tomador de decisiones consulta información externa (presente en artículos de revistas, en periódicos, notas referentes a otras empresas industriales, etc.); o más bien, información de carácter interno (informes de la compañía, correspondencia interna, manuales de procedimientos).

6.-Iluminación y color de la oficina. La iluminación y el color de la oficina desempeñan un papel importante en la manera en que el tomador de decisiones obtiene la información. Si la oficina es iluminada cálidamente con lámparas incandescentes, favorecerá la comunicación personal. Un ejecutivo obtendrá mayor información de carácter informal dentro de una oficina cálida. Mientras que otro miembro de la organización que trabaje en una oficina con una iluminación brillante y colores fuertes recibirá la información mediante memorándums 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 organización, al examinar su presentación. Con base en los estudios realizados por los investigadores sobre la impresión lograda por la apariencia de los ejecutivos, los trajes masculinos formales de tres piezas y los trajes sastre femeninos, representarían la máxima autoridad. Una presentación informal abre las puertas para la toma de decisiones más participativa, pero con frecuencia, si predominan los valores tradicionales, ocasiona cierta pérdida de credibilidad dentro de la organización. Mediante el uso del STROBE, el analista de sistemas logra una mejor comprensión de cómo los gerentes obtienen, procesan, almacenan y utilizan la información. Un resumen de estas características y de los elementos correspondientes para examinar, se tiene en la figura 5.21. La aplicación del STROBE tiene muchas opciones. Puede ser altamente estructurada (tales como la toma de fotografías para análisis posteriores) o sin estructurar. A continuación se describen cuatro métodos. 1.- Análisis de fotografías.- Examen en busca de elementos STROBE es análoga a la aplicación original de la mise-en-scéne del crítico de cine. De manera interesante, esta aplicación tiene paralelo con los inicios del estudio de la gerencia, ya que a principios del siglo Frank Gilberth utilizó películas en sus famosos estudios de tiempos y movimientos, analizando toma por tomamaquellos movimientos que eran necesarios para realizar una tarea.

154

Características del tomador de decisiones

Elementos correspondiente en el ambiente físico

1.- Recopila de manera informal la Información.

Iluminación incandescentes y tonos cálidos.

.- Busca información fuera de La organización.

Revistas especializadas existentes en la oficina.

3.- Procesa los datos de Manera personal.

Calculadoras y terminales de video Presentes en la oficina.

4.- Conserva la información de manera personal.

Archiveros presentes en la oficina.

5.- Hace uso de la autoridad En la toma de decisiones.

Escritorios ubicados para el orden.

6.- Exhibe creatividad en la Toma de decisiones.

Hace uso de vestimenta autoritaria.

7.- Comparte la información con Otros miembros de la organización.

Oficina fácilmente accesible.

Figura 5.21-Resumen de las características de los elementos STROBE.

La aplicación fotográfica 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 organización, y la segunda ventaja es que el fotógrafo puede hacer el enfoque específicamente en los elementos pertinentes del STROBE; y en consecuencia, eliminar otros elementos extraños. Además, al usar la fotografía para el STROBE contamos con un instrumento de análisis detallado, y con la fotografía quedan superadas las limitaciones de tiempo y espacio. Una cuarta ventaja es que el fotógrafo puede registrar aquellos detalles que pasan desapercibidos fácilmente, si el analista no sólo observa, sino además conduce una entrevista o investiga documentos. Hay ciertos inconvenientes de la toma de fotografías para implantar el STROBE. El primero y más importante es la decisión de qué fotografiar. A diferencia del ojo humno, las fotografías están limitadas sobre lo que pueden apuntar y “tomar”. El segundo inconveniente es que la fotografía, 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 más aceptable para el analista.

2.-Enfoque de lista de verificación/escala de Likert.-Los investigadores han desarrollado escalas de Likert de cinco puntos relativos a siete de las características de los tomadores de decisiones, que pueden observarse a través de los elementos físicos del ambiente del tomador de decisiones, como se muestra en la figura 5.22. En un estudio original de dieciséis administradores de bancos de sangre y directores médicos de Estados Unidos y de Canadá, hubo una validación convergente y discriminante de la información obtenida por escala STROBE; de la información 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 métodos más tradicionales.

155

3.- Listas anecdóticas (con uso de símbolos).- Este enfoque STROBE fue útil para averiguar los requerimientos de información 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 símbolos taquigráficos para evaluar la observación de los elementos STROBE comparada con la narración de la organización obtenida por medio de entrevistas. Los cinco símbolos utilizados son: Un círculo con una paloma significa que se confirma la narración. Un círculo cruzado significa que contradice a la narración. Un círculo dentro de un ojo sirve como indicio para que el analista examine más allá. Un círculo dentro de un cuadro significa que la observación de los elementos STROBE modifica la narración. Dos círculos juntos significa que lo observado complementa la narración.

156

Escalas STROBE para el examen del ambiente físico 1) Los tonos cálidos en la iluminación de la oficina, paredes, pinturas y graficas crean un foro informal para el intercambio de la información. Lámparas fluorescentes paredes de tonos fríos sin decoración

Lámpara incandescentes paredes de tonos cálidos decoración cálida.

2) La oficina tiene varias formas de información traídas del exterior de la organización revistas, publicaciones de asociaciones y periódicos comerciales. No existen fuentes cuatro o más revistas externas de información o periódicos. 3) Se tienen apoyos para el proceso de la información, se encuentran presentes y son fácilmente 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 información. No existen archiveros en la oficina.

Cuatro o más 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 más que un atuendo informal o sport. Vestido informal o sport

vestido conservador

7) La oficina del administrador es fácilmente accesible. Oficina localizada en un piso diferente a sus subordinados

oficina no más allá de 15m de sus subordinados.

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

157

Se utiliza una lista anecdótica con símbolos en la aplicación de STROBE

Narración planteada Por los miembros de la organización

Ubicación y equipo de la oficina

Color, iluminación y grafica de la oficina

Vestimenta del tomador de decisiones

La información fluye fácilmente 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 compañía 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”

Símbolo

Confirma la narración

Nota para mirar mas allá

Niega ose opone a la narración

Modificar la narrativa

Complementar la narración

Figura 5.23.- Lista anecdótica con símbolos utilizada en la aplicación del STROBE.

Cuando el STROBE se implanta de esta manera, el primer paso a seguir es determinar los temas fundamentales de la organización que dan lugar a las entrevistas. Después se observan los elementos STROBE de manera sistemática y se construye una matriz que contiene las ideas principales de la narración de la organización, acerca de la obtención de información, su procesamiento, cómo 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 símbolos, para caracterizar la relación entre la narración y los elementos observados de relevancia. El analista deberá crear luego una tabla que primero documente y luego facilite el análisis de las observaciones. 4.- Comparación de la observación/narración.- Los fanáticos del cine rara vez asisten a una película con una lista de verificación de mise-en-scéne 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-scéne y los llega a observar de manera consciente, puede alcanzarse cierta perspicacia de valor, aún sin el auxilio de una lista de verificación. Examinar la organización con un enfoque basado en el STROBE, es el comienzo de la observación estructurada.

158

5.2 HERREMIENTAS CASE

Los analistas deben ser organizados, precisos y completar todo aquello que realicen. En los últimos años, los analistas han comenzado a beneficiarse de novedosos intrumentos de productividad creados explícitamente para mejorar sus tareas de rutina mediante el uso de soportes automatizados. A estos elementos se les denomina “tecnologías 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 tecnologías 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

Comunicación efectiva con los usuarios

Integración de las actividades del ciclo de la vida de los sistemas

OPCION DE TECNOLOGIAS DE TALLER

Figura 5.24.- Enfoques del CASE.

Las tecnologías de ambientes integrados (que apoyan diferentes combinaciones de técnicas estructuradas, tales como los diagramas de flujo de datos, los diccionarios de datos, los diagramas estructurales, los diagramas de relación de entidades y la documentación) son otras formas de incrementar la productividd del analista de sistemas. La medición de productividad de un analista, definitivamente no es sencilla, en especial a corto plazo. A largo plazo, es claro que la modificación o la creación de un sistema de información bien utilizado forma parte del criterio. Se pouede ver en retroespectiva en el proyecto y aceptar que el analista habría sido más productivo si el sistema de información 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 través de las tecnologías 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 tecnologías, comparada con lo que pudiera haber ocurrido, posiblemente con métodos alternativos. Los instrumentos CASE facilitan la interacción entre los miembros del grupo al permitir que la elaboración de diagramas sea un proceso dinámico e imperativo, más que uno en el cual los cambios sean tediosos; y, en consecuencia, tiendan a disminuir la productividad. En este caso, las tecnologías de ambiente integrado para el dibujo y el registro de diagramas de flujo proveen de un registro del cambio de opinión de los grupos, con base en los diagramas de flujo. Mejoramiento de la comunicación analista-usuario Con el fin de que el sistema propuesto llegue a utilizarse, es esencial que exista una comunicación excelente entre los analistas y los usuarios a todo lo largo del ciclo de desarrollo de sistemas. Indiscutiblemente, el éxito de la eventual implantación 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 tecnologías de taller, redunde en una comunicación significativa entre los usuarios y los analistas. Lo que los analistas y los usuarios han reportado es que las tecnologías de taller les confieren una comunicación significativa acerca del sistema. A través del uso de las peculiaridades del soporte automatizado en pantalla, los clientes pueden ver cómo los flujos de datos (y otros conceptos del sistema) fueron concebidos. Al observarlos, pueden solicitar correcciones o cambios que podrían requerir mucho más tiempo que por medio de un sistema manual. Quizás 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 diseño de ciclo de vida (con frecuencia, de manera imperceptible para los usuarios) como un elemento de conclusión al actuar como catalizador de la interacción analista-usuario. El mismo tipo de argumentos planteados para la productividad existe también 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.

Integración de las actividades del ciclo de vida En las tecnologías 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 consultoría de sistemas de información 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) Identificación de problemas, objetivos y objetivos.

7) Implementación y evaluación del sistema.

Inicio de la elaboración del diagrama E-R del plan del proyecto

2) Determinación de los requerimientos de información.

Uso del software de administración de proyectos para la conclusión

Organizar las actividades de captura de datos mediante uso de prototipos

6) Pruebas y mantenimiento de sistema.

3) Análisis de las necesidades del sistema.

Generar datos de prueba y verificar los datos de las pruebas

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

Construir diagramas de estructuras, transferir datos del diccionario de datos al código de programación

Elaborar las pantallas y reportes; modelar los datos

4) Diseño del sistema recomendado.

5) Desarrollo y documentación de software.

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

Las actividades de integración 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, más que hacer parches con trabajos de planeación estratégica y otros realizados en el diseño lógico de programas, la integración a través de la automatización facilita el movimiento entre las diferentes actividades del ciclo de vida. Esto es especialmente útil cuando hay la necesidad de realizar iteraciones de retroalimentación y modificación a lo largo de una etapa particular del ciclo de vida, recordando también que el compromiso del usuario es sumamente importante durante todas las etapas.

161

VENTAJAS Inversión en paquetes comerciales del alto costo

Forzar al analista a cambiar sus métodos de trabajo por otros nuevos.

Productividad

Comunicación

Descubrir puntos ciegos de las herramientas de desarrollo a través del recorte y pegado del software

Integración

Requerimiento de automatización de los instrumentos CASE debido al rezago de la integración d las actividades del ciclo de vida.

Figura 5.26.- Ventajas de la utilización de las tecnologías de ambiente.

1. Alcanzar un nivel competitivo sobre otros en la misma línea de trabajo.- Las ventajas servicios de sistemas con quien plantee la “mejor” cotización, ya sea interno o externo. De manera alternativa, si hay un claro sistema de reembolsos, donde los usuarios estén bien informados de cuánto cuesta un servicio y cuánto tiempo involucra su realización, 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 tecnologías de ambiente integrado. 2. Estandarización de métodos internos y externos.- Mucho se ha dicho acerca de la elección de las técnicas para el diseño y la documentación surge del hecho de que no hay un estándar, ni una técnica universal. Se ha observado que esto puede causar problemas de comunicación 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 común para analistas y usuarios. 3. A través de la estandarización en la elaboración 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é técnica de elaboración de diagramas se empleó antes de llegar al contenido. La estandarización también tiene una ventaja externa, ya que un analista que ha tenido experiencia en el uso de ciertos paquetes de tecnologías de ambiente integrado, permitirá que el cliente cuente con una manera fácil de comunicarse. 4. Viendo problemas viejos de nuevas maneras.- La importancia de resolver el problema correcto mediante una solución de sistemas. Esto implica ubicar con precisión el problema dentro de un contexto, de tal forma que se involucren el número y los tipos correctos de subsistemas de la organización. Una ventaja de la utilización de las tecnologías de ambiente integrado es que crean un nuevo contexto para problemas viejos, de tal forma que se estimula la creación de nuevos ideas. Por ejemplo, cuando los diagramas de flujo pueden elaborarse con rapidez y luego corregirse, es más fácil comparar la conceptualización de los flujos de datos que se tenían con anterioridad. Este tipo de tormenta de ideas gráfico sirve como un catalizador para la creación de nuevas de ideas. Además, observe que cuando se integran las actividades del ciclo de vida (esto

162

es, la documentación con la elaboración 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. Adopción de la automatización como rutina.- Cuando los analistas adoptan las tecnologías 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 automatización le confiere beneficios a los usuarios. El analista no mencionará la automatización por un momento, para luego regresar a preparar laboriosamente los bosquejos manuales de su tarea siguiente. El uso de las tecnologías de ambiente integrado también 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 integración. La necesidad de superar las lagunas del responsable del desarrollo. El cambio de los métodos del trabajo. La inversión en un paquete comercial caro.

Alcanzar un nivel competitivo superior a alas compañías que no han adoptado las tecnologías de ambiente integrado

Adopción de la automatización como parte de la rutina del analista y practicar lo que este pregona

Productividad

Comunicación

Mejoras en la uniformidad de los métodos de elaboración de diagramas tanto internas como externas

Integración

Descubrimiento de ideas única al ver viejos problemas con nuevos enfoques

Figura 5.27.-Desventajas de la utilización de las tecnologías de ambiente.

6. Adaptación 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 automatización, la decisión debe incluir la aceptación de que con el fin de integrarlo plenamente será necesario un buen esfuerzo de adaptación.

163

7. Superación de puntos ciegos del desarrollador.-Es difícil anticiparse a cada uno de los usos que pudiera tener una aplicación. Lo mismo es cierto para las tecnologías de ambiente integrado desarrolladas con fines comerciales. Quienes las desarrollan no pueden ayudar, pero tienen lagunas en términos de comprender con precisión 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 programación aunque sean los de mayor difusión como por ejemplo COBOL. 8. El cambio de métodos de trabajo.- El cambio de tecnología implica también un cambio de los métodos de trabajo. Como se ha visto, en las interacciones con los usuarios, la resistencia al cambio es parte de la naturaleza humana, Nunca será fácil dejar atrás un antigui método de trabajo por otro nuevo, a un nivel emotivo, incluso si los beneficios son claros a un nivel intelctual. Un gran grupo de consultoría en administración y en sistemas ha intentado resolver el problema asociado al cambio, permitiendo que los analistas adopten aquellas tecnologías de ambiente integrado que encuentren personalmete útiles. Y no es obligatorio el cambio sistemático a un método de automatización. 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 estandarización. Afortunadamente, la mayoría de los analistas desean mantenerse actualizados y no tienen prejuicios por la tecnología, como podría ocurri con otros tipos de usuarios. 9. La inversión 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 pequeña empresa, que apenas comienza o de otra que tiene dificultades para obtener utilidades, los costos iniciales de las tecnologías de ambiente integrado le hará reconsiderar su adquisición. El reconocimiento de las desventajas que hemos discutido, tales como el rezago en las capacidades de interacción, así como las inevitables lagunas de quien desarrolla, pueden darle pautas para considerar si invierte en los instrumentos CASE, que podrían desilucionarlo más adelante. Es imperativo que analice los factores internos, así como los externos antes de tomar una decisión. Debe ponderar los incrementos en productividada largo plazo contra los costos de adquisición y de aprendizaje. Además, el usuario necesitará considerar si puede sobrevivir sin las tecnologías de ambiente integrado, si es que sus competidores las están utilizando de rutina.

5.2.1 ESTRUCTURADAS De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o más fases del ciclo de vida del desarrollo de sistemas. Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir: 1. Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos. 2. Herramientas de diseño para dar apoyo al análisis de datos. 3. Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico.

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 aplicación de bases de datos.

En la década de los setenta el proyecto ISDOS desarrolló un lenguaje llamado "Problem Statement Language" (PSL) para la descripción de los problemas de usuarios y las necesidades de solución de un sistema de información en un diccionario computarizado. Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relación de problemas y necesidades. Pero la primera herramienta CASE como hoy se conoce fue "Excelerator" en 1984, era para PC. Tecnología Case Supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean los siguientes objetivos: a. Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo. b. Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones. c. Simplificar el mantenimiento de los programas. d. Mejorar y estandarizar la documentación. e. Aumentar la portabilidad de las aplicaciones. f. Facilitar la reutilización de componentes software. g. Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos. Automatizar: a. b. c. d. e.

El desarrollo del software. La documentación. La generación del código. El chequeo de errores. La gestión del proyecto.

Permitir: a. b. c. d.

La reutilización del software. La portabilidad del software. La estandarización de la documentación. Componentes de una herramienta case.

De una forma esquemática 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 gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros. b. Meta modelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías 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 comunicación con otras herramientas.

165

d. Comprobación de errores, facilidades que permiten llevar a cabo un análisis 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 diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías. f. La estructura CASE general se basa en la siguiente terminología: 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 planificación de sistemas, el análisis de sistemas y el diseño 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 diseño detallado de sistemas, la implantación 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 gestión de proyectos y la estimación.

5.2.2 HERRAMIENTAS CASE ORIENTADA A OBJETOS

Las herramientas CASE orientadas a objetos proporcionan el soporte para las metodologías y notaciones orientadas a objetos, e incluso permiten generar parte del código de las aplicaciones. Las nuevas versiones de las herramientas CASE orientadas a objetos están ya incorporando los nuevos lenguajes como Java. Muchas de estas herramientas también dan soporte a bases de datos relacionales, permitiendo el modelado y diseño lógico y en algunos casos el físico, de la base de datos, incluyendo la generación de esquemas e ingeniería inversa sobre tablas y otros elementos del RDBMS. Las herramientas CASE ofrecen grandes ventajas a los desarrolladores de sistemas software de gran tamaño. Mientras una espiral de requisitos del sistema sigue llevando la complejidad del sistema a nuevos niveles, las herramientas CASE nos permiten abstraernos del código fuente, a un nivel donde la arquitectura y el diseño son más aparentes y fáciles de entender y modificar. Se puede decir que cuanto mayor es el proyecto software, más importante resulta el utilizar tecnologías CASE. Ya que los desarrolladores en este tipo de sistemas interaccionan sólo con una o varias partes del sistema diseñado por los diseñadores, deben encontrar de manera sencilla el subconjunto de clases y métodos, así como asimilar y entender cuáles son las interfaces con ellos. En el mismo sentido el gestor del proyecto debe ser capaz de ver una representación del diseño a alto nivel y entender cómo funciona en un tiempo razonable. Por estas razones, las herramientas CASE junto con las metodologías nos proporcionan una forma de representar sistemas demasiado complejos de entender ya sea a partir del código subyacente o de alguna forma basada en esquemas. Para alcanzar el grado de abstracción necesario las herramientas CASE orientadas a objetos (OOCASE) permiten crear diagramas que representan el modelo de objetos utilizando los elementos notacionales de metodologías específicas como: OMT (Object Modeling Technique), Booch, Jacobson Use Cases, UML (Unified Modeling Language) o Fusion. El soporte notacional es sólo una forma de clasificar las herramientas CASE, otras características a tener en cuenta son: el soporte de varios lenguajes de programación, el uso de ficheros o bibliotecas para almacenar la información del modelo y la integración con software de control de versiones. Las herramientas OOCASE crean diagramas que representan el modelo de objetos utilizando los elementos notacionales de las diferentes metodologías. Estas notaciones representan gráficamente clases (incluyendo atributos, métodos y eventos), relaciones entre objetos (herencia,

166

agregación, colaboración), y cardinalidad. Además la mayoría, aunque no todas, las herramientas OOCASE ofrecen la posibilidad de generar un esqueleto del código de la aplicación. Este esqueleto generalmente incluye la definición 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 páginas Web, acceso a bases de datos, código C++, código Java, interfaz CORBA de acceso a un servidor C++, etc. Esta disparidad es el reto básico que tienen que afrontar los vendedores de herramientas CASE que quieran proporcionar un entorno de dice no integrado Con los años va siendo mayor la capacidad de trabajar más con menos herramientas, lo que supone una mayor integración y una menor complejidad en las herramientas CASE, lo que nos lleva a una mayor productividad. A la hora de alcanzar una mayor integración, 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 visión de este modelo nos muestra elementos orientados a objetos como clases, atributos y métodos, todos ellos y sus interrelaciones representados como metaclases. Al modelo UML se le pueden añadir más metaclases, por ejemplo para describir modelos entidad relación, así como realizar extensiones para tratar con interfaces como las definidas usando CORBA. El estándar UML define notaciones para representar la información y su interrelación desde una perspectiva gráfica, además 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 relación que existe entre la información que ha de ser almacenada en una biblioteca (repository), no especifica cómo se debe guardar esta información, dejando la elección a los distintos vendedores. El CDIF permite una representación ASCII para una biblioteca de diseños, dicha representación puede ser utilizada para transferir los datos del diseño 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 código'', nos estamos refiriendo a cabeceras y prototipos en el caso de C++ o Java, y a información de esquema en el caso de bases de datos relacionales. O sea, se proporciona la base para clases, métodos, y atributos en aplicaciones orientadas a objetos, así como tablas, columnas y relaciones en DBMS relacional. El tener una herramienta CASE que proporcione código de aplicación y de base de datos ayuda a garantizar que el modelo y su implementación estén sincronizados. Esta sincronización hace que la herramienta de modelado sea más útil para los desarrolladores. Sin un mecanismo integrado para guardar la implementación y el modelo sincronizados, se produce con frecuencia una desconexión entre ambos. Dicho de otra forma, es frecuente que las mejores soluciones se hagan evidentes en el proceso de implementación, si estas soluciones, que llevan con frecuencia a modificaciones en el diseño, no son realimentadas hacia atrás en el modelo de una forma conveniente, el modelo puede pasar a estar ``out of date''. El valor intrínseco del modelo se pierde desde el momento en que no podemos confiar en él y por lo tanto deja de usarse. Para soportar la generación de ficheros de cabecera y prototipos de métodos, debe haber una forma de asegurar que la herramienta no sobrescribe el cuerpo de los métodos y otro código y comentarios introducidos por el desarrollador. La forma más fácil y frecuente de hacer esto es introducir información del modelo dentro del código 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 código fuente se reduce de una forma significativa debido a la información introducida por la herramienta CASE en bloques de comentarios. Dos razones reducen la importancia del problema de ``polución'' del código: a. Los desarrolladores están acostumbrados a ver los comentarios extra y filtrarlos mentalmente. b. La utilización cada vez más frecuente de entornos de desarrollo integrado cada vez más sofisticados (Ej.: Visual Basic de Microsoft). Estos entonos ofrecen browsers para clases y métodos que hacen la navegación hacia declaraciones y definiciones específicas muy sencilla, con lo cual los desarrolladores pueden evitar el ``ruido'' introducido en los ficheros de código 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 están expuestos a frecuentes cambios durante el análisis y el diseño, muchos vendedores integran ya este tipo de software. Además, 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 almacén, deben definir unidades de modelo que puedan ser utilizadas de forma concurrente por diferentes diseñadores y analistas. Estas unidades además deben estar bajo el control de algún software de versiones. La granularidad de las unidades de este tipo es un factor importante ya que con frecuencia diferentes partes del modelo están entrelazadas. Cuando un desarrollador coge una parte del modelo, esa parte debería ser lo suficientemente pequeña 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 común a más 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 seguirán en el futuro soportando diferentes metodologías. Incluso cuando UML alcance su esperada penetración en el mercado, aparecerán otras metodologías con gran número de seguidores, existiendo siempre varias notaciones y metodologías activas. Es por eso, que será importante que las herramientas CASE que ahora almacenan la información del modelo en ficheros evolucionen hacia almacenes a los que puedan acceder diferentes herramientas. Esto hará más fácil el intercambio de información entre herramientas que realizan clases específicas de modelado. De todas formas es también deseable que se reduzca el número de herramientas CASE necesarias para modelar una aplicación. El número de herramientas CASE que soportan UML ha crecido muy considerablemente estos último años.

168

5.2 DESARROLLO DE PROTOTIPOS

El desarrollo de prototipos es una metodología valiosa para identificar con rapidez, las necesidades particulares de información del usuario. En términos generales, el desarrollo efectivo de prototipos debería realizarse en las primeras etapas del ciclo de vida de desarrollo de sistemas, durante la fase de establecimiento de los requerimientos de información. Sin embargo, el desarrollo de prototipos es una técnica 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 técnica de obtención de información. 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 depuración si éste ya fue presentado; las posibles innovaciones para él y los planes de revisión para aquellas partes del sistema que requieran implantarse primero o las áreas de la organización que deberán considerarse próximamente. La figura 5.28, muestra los cuatro tipos de información que busca el analista durante el desarrollo de prototipos.

REACCIONES DEL USUARIO

SUGERENCIAS DEL USUARIO

INNOVACIONES PLANES DE REVISIÓN

Figura 5.28.- Tipos de información buscada durante el desarrollo de prototipos.

La palabra prototipo se utiliza de muchas maneras diferentes. Más que intentar la síntesis de todas estas connotaciones en una sola definición, o tratar de establecer un solo enfoque correcto para el tópico de desarrollo de prototipos.

Prototipos de remiendo Tiene que ver con la construcción de un sistema que si bien funciona, se encuentra remendado o parchado. En ingeniería a este concepto se le denomina como tableta de prototipo (breadboarding), en donde se desarrolla un circuito integrado (microscópico) mediante un modelo operable de elementos sobrepuestos aún no definitivos. Un ejemplo en los sistemas de información es la creación de un modelo operable, el cual cuenta con todas sus características necesarias, aunque pudiera ser ineficiente. En este caso de

169

prototipos, los usuarios se relacionan con el sistema, adaptándose a las interfaces y a los tipos de salidas disponibles. Sin embargo, los procesos de recuperación y almacenamiento de información 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, podría ser aquel sistema de información que cuente con todas las características propuestas, pero que en realidad sea un modelo básico, 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 diseño. Un ejemplo de ello sería la construcción de un modelo de un automóvil a escala para evaluarlo en túneles de viento. Si bien el tamaño y la forma del auto es preciso, el vehículo no funciona. En este caso, sólo se incluyen las características esenciales del automóvil para la realización de las pruebas particulares. Un modelo no funcional de un sistema de información a escala podría ser aquél en el cual la codificación que se requiere es extensa en cantidad; y mas bien, podría 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 información no ha sido contemplado, por ser en sí costoso y requerir de tiempo. Sin embargo, la evaluación 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 opinión 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 sería el desarrollo del prototipo del primer aeroplano de una serie. El prototipo es completamente funcional y es la realización de lo que según el diseñador será una serie de aeroplanos con características idénticas a éste. Este tipo de prototipos es útil cuando se planea implantar el mismo sistema de información en varias instalaciones. Un modelo funcional a escala total permite una interacción realista con el sistema, reduciendo los costos de solución 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 envío 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 típico lo tenemos en las instalaciones bancarias con la transferencia electrónica de fondos. En una o dos localidades se instalaría primero un modelo a escala completa del prototipo, y si tuviera éxito, se implantaría en todas las sucursales, con base en el patrón de uso y en otros elementos fundamentales.

171

LOCACIÓN 1 LOCACIÓN 2 LOCACIÓN 3

Figura 5.31.- Primer modelo a escala completa.

Un modelo que cuenta con ciertas características esenciales Construcción de un modelo funcional que incluya algunas, pero no todas las características que tendrá el sistema final. Una analogía sería 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 artículos, la existencia de restoranes de comida preparada y el estacionamiento; aunque no se ha ocupado por completo, ni se ofrecen todos los artículos que eventualmente se ofrecerán 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 características esenciales, mas no todas. Por ejemplo, el menú que presentará un sistema en la pantalla, puede enumerar seis características: agregar un registro, actualizar un registro, eliminar un registro, búsqueda de un registro con base en una palabra clave, enumerar registros y otras clases de búsquedas. Sin embargo, en el prototipo, el usuario sólo dispone de tres de las seis funciones, de tal forma que él puede agregar un registro (característica 1), eliminarlo (característica 3), o desplegarlos (característica 5), tal y como se muestra en la figura 5.31.

172

OPCIÓN 1

OPCIÓN 3

OPCIÓN 5

Figura 5.32.- Modelo que cuente con ciertas características esenciales.

Cuando se desarrollan este tipo de prototipos, el sistema se planifica con base en módulos, de tal forma que aquellas características que se aprobarán en el prototipo podrían incorporarse en un sistema final mayor, sin requerir de gran esfuerzo durante la conexión. Los prototipos desarrollados de esta manera, operan como parte de sistemas actuales y no son sólo un parche como los hemos considerado en la primera definición de prototipos.

Los prototipos como alternativa en el ciclo de vida del desarrollo de sistemas Ciertos analistas afirman que el desarrollo de prototipos debería 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 más tiempo, el costo del sistema desarrollado se incrementa proporcionalmente. La segunda preocupación 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 análisis 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 (después de haber concluído los análisis iniciales de requerimientos), puede no satisfacer sus expectativas. Como corolario al problema de distanciarse de los requerimientos evolutivos de información 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 indagación de los requerimientos de información y la entrega de un sistema funcional. Además al diseñar prototipos, en lugar de apegarse al ciclo formal de desarrollo, pueden evitarse ciertos problemas concernientes a la identificación precisa de los requerimientos de información del usuario. Con un prototipo, el usuario puede ver en realidad lo que llegará a ser posible; y así mismo, cómo 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 información 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 Identificación de problemas, oportunidades y objetivos

2 Determinación de los requerimientos de información Límites con mayor rigidez

Tiempo requerido para él

3 Análisis de las necesidades de sistemas

4 Diseño del sistema recomendado

5 Desarrollo y documentación del software

Menor participación del usuario

El sistema tangible aparece al final

6 Prueba y mantenimiento del sistema

7 Implantación y evaluación del sistema

La evaluación 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 ofrecería una solución. 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 nómina, tal cual o un sistema de inventarios, los cuales resuelven problemas muy estructurados, desde un punto de vista tradicional, no serían 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

Muy conveniente para prototipos Experiencia en diseño similares

Medio ambiente

Toma de decisiones

Solo unas cuantas anteriores Incierto e inestable Poco estructurada o semiestructurada

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

Más 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, sería adecuado para desarrollarse a partir de un prototipo. El analista de sistemas debe evaluar también el contexto del sistema para decidir si usa prototipos. Si el sistema existirá durante largo tiempo en un ambiente estable, quizás sería 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 sólo una parte del sistema que eventualmente instalará. No es un sistema completo, ya que al desarrollarlo con rapidez, puede quedar limitado, contando con sólo 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 interactúa con un sistema real. El uso de prototipos permite reducir retroalimentación sobre el sistema propuesto, y además qué tan bien satisface las necesidades de información del usuario. Uno de los primeros pasos en el desarrollo de un prototipo es la estimación de los costos involucrados para su construcción, cronsiderándolo como uno de los módulos 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 información dentro del gran sistema de la organización.

175

Lineamientos para el desarrollo de prototipos Una vez que se ha tomado la decisión, deben observarse cuatro lineamientos básicos al integrar el prototipo al SDLC, dentro de la etapa de determinación 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 módulos 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 módulos manipulables.- Cuando desarrolle el prototipo de ciertas características del sistema dentro de un modelo funcional, es imperativo que los módulos 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 módulos manipulables en secciones anteriores, recuerde que un módulo manipulable es aquél que nos permite relacionarnos con sus características, y además su construcción es independiente de otros módulos del sistema. Aquellas características que se consideren poco importantes quedarán fuera del prototipo. Construir el prototipo con rapidez.- La esencia del desarrollo del prototipo de un sistema de información con éxito es la rapidez de su realización. Se recuerda que los inconvenientes planteados comúnmente 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 análisis sobre los requerimientos de información por métodos tradicionales, tales como la entrevista, la observación, y la investigación de datos de archivo, se construyen los módulos funcionales de prototipos. El prototipo debe estructurarse en menos de una semana, de preferencia y si es posible en dos o tres días. Recuerde que con el fin de construir un prototipo así de rápido, 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 todavía recopilando información acerca de lo que necesitan y desean los usuarios del sistema de información. El prototipo se vuelve una extensión valiosa de la forma tradicional de determinar los requerimientos. Por medio del prototipo, el analista establece una retroalimentación conel usuario, con el fin de obtener una mejor visión de las necesidades de información. Al desarrollar el prototipocon rapidez, en el inicio del ciclo de desarrollo de sistemas, el analista contará con una excelente visión sobre la manera en que deberá desarrollar el resto del proyecto. Al mostrar a los usuarios, desde un principio, la operación de los elementos del sistema, mediante un desarrollo rápido del prototipo, puede evitar la asignación de recursos a un proyecto, que eventualmente, podría descartarse.

Modificaciones en el prototipo.- El prototipo requiere contar con módulos que tengan entre sí una baja dependencia. Al observar este lineamiento, será más fácil 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 modificación requiere de una nueva evaluación por parte de los usuarios. Así como ocurrió con el desarrollo inicial, las modificaciones al prototipo deben realizarse de inmediato, comúnmente en uno o dos días, con el fin de conservar el objeto del proyecto. Sin embargo, la programación exacta de las modificaciones dependerá de la dedicación 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. También indica al usuario que será necesaria su retroalimentación 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 más allá sus requerimientos de información. 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 debería ser un obstáculo. Por ejemplo, en esa etapa, la meta del analista es diseñar una interfaz tal, que permita la usuario interactuar con el mínimo de adiestramiento, y además contar con el máximo 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 línea, 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 administración del proyecto. Aunque varias interacciones del prototipo pueden ser necesarias, la extensión indefinida de su uso, también creará problemas. Es importante que el grupo de análisis de sistemas imagine y cuente con un plan que le indique la manera como la retroalimentación al prototipo se registrará, analizará e interpretará. Establezca periodos específicos durante los cuales usted y los tomadores de la decisión de la gerencia harán uso de la retroalimentación para evaluar el buen desempeño 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

Adopción 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 relación con el sistema prototipoque no son compatibles con lo que ocurriría con un sistema completo. Además, un prototipo puede no realizar todas las funciones requeridas. Eventualmente, cuando emerjan las deficiencias, el prototipo se menospreciará, si fue adoptado equívocamente en la empresa como un sistema completo. Ventajas del uso de prototipos Modificación 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 retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades actuales. Aunque el desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre será considerablemente menor a la de u sistema completo. De manera simultánea, los problemas de sistemas y los descuidos son más fáciles de detectar en un prototipo con características e interfaces limitadas que en un sistema complejo. Eliminación de sistemas indeseables. Otra ventaja de los prototipos como elemento de recopilación de información es la posibilidad de eliminar un sistema que no llegó a ser lo que esperaban de él los usuarios y los analistas. Una vez más, la inversión de tiempo y de dinero destacará. Sin embargo, un prototipo representa una menor inversión 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 información que se establecieron. Diseño de un sistema acorde a las necesidades y expectativas de los usuarios Los sistemas en desarrollo se ajustarán mejor a las necesidades de los usuarios, los estudios de sistemas de información 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 práctica es interactuar con los usuarios a todo lo largo del SDLC, los usuarios, que desde un inicio hacen suyo un sistema de información, serán los principales promotores de su éxito. Cuando la evaluación del prototipo indica que el sistema va sobre ruedas, dentro los lineamientos que se establecieron, la decisicón debe ser mantener la operación del prototipo y continuar expandiéndolo, hasta incluir las otras funciones que fueron planificadas. Esto es lo que se considera como un prototipo funcional. Se tomará la decisión de mantener su operación como si el prototipo se encontrara dentro del presupuesto establecido para la programación y el análisis de sistemas. Con ello, los usuarios apreciarán el sistema e irá acorde a los requerimientos de información 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

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, aún cuando es inadecuado.

Ventajas de prototipos

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 precisión 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 realización de la entrevista Liste cuatro situaciones que hagan adecuado el uso de cuestionarios. ¿Cómo debe ser la selección de quien recibirá el cuestionario? Defina lo que significa muestreo Liste tres razones sobre el porqué la observación es útil para el analista de sistemas en la organización Explique brevemente la fase de muestreo. ¿Qué tipos de información deben ser buscados en las entrevistas? Explique lineamientos principales para el desarrollo de prototipos. Para las siguientes situaciones, diga qué técnica de recolección de datos se debe emplear. Justifique su respuesta.

SITUACIONES A INVESTIGAR

TÉCNICAS DE RECOLECCIÓN DE DATOS QUE SE DEBE EMPLEAR

Determinar las condiciones de iluminación de la áreas del Decanato de Medicina. Indaga la opinión de los usuarios del ambulatorio Simón Bolivar, sobre el cobro de la atención medica. Verificar las zonas de riesgo de derrumbes en la ciudad Determinar el grado de conocimiento sobre SIDA en los alumnos de la Universidad

10. Mencione dos ventajas y dos limitaciones de la técnica de entrevista.

179

DISEÑO Y ARQUITECTURA DE PRODUCTOS DE SOFTWARE

6.1 DESCOMPOSICIÓN MODULAR

6.2 ARQUITECTURAS DE DOMINIO ESPECÍFICO 6.2.1 DISEÑO DE SOFTWARE ARQUITECTURA MULTIPROCESADOR 6.2.2

DISEÑO DE SOFTWARE ARQUITECTURA CLIENTE SERVIDOR

6.2.3 DISEÑO DE SOFTWARE DISTRIBUIDO 6.2.4 DISEÑO DE SOFTWARE DE TIEMPO

180

6.1. DESCOMPOSICIÓN MODULAR Consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea representa una actividad completa y se codifica de manera independiente. Facilita el diseño descendente del problema, centrándonos cada vez en la resolución de subproblemas de magnitud inferior. A la resolución de cada uno de estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y depurados independientemente, y a continuación se combinan uno a uno con otros módulos. Estos diseños ayudan a crear arquitecturas para nuestro software más reutilizables y extensibles. Muchos de los lenguajes de programación existentes y de las técnicas arquitectónicas subyacentes a los mismos implementan de una manera u otra algún tipo de técnica que favorezca la descomposición 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 noción de clase. Tanto el paradigma estructurado como el orientado a objetos soportan algún método o técnica 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 debería ser un subproblema y que no debería serlo. Una técnica arquitectónica de software que basa la descomposición de un determinado problema en otros menos complejos basándose en las funciones, acciones o las tareas que lleva a cabo el sistema recibe el nombre de estructurado o funcional, al contrario, una técnica arquitectónica que descompone un problema en otros subproblemas menos complejos basándose en los tipos de objetos que manipula es lo que se conoce por orientación a objetos. La forma en la que los diferentes tipos de arquitectura descomponen los problemas y encuentran sus módulos es una discusión lo suficientemente amplia y trascendental (es el origen de la orientación a objetos) que puede ser tratada en otros textos. Considérese 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 resolución de un problema difícil toma más tiempo. También se deduce que la complejidad observada de dos problemas, cuando están 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 vencerás” (es más fácil resolver un problema complejo cuando éste se divide en piezas más 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 conclusión sea inválida. En relación con la figura 6.1, el esfuerzo (costo) para desarrollar un solo modulo se software decrece conforme se incrementa el número de módulos. Si se tiene el mismo conjunto de requisitos, más módulos significan un tamaño individual menor. Sin embargo, a medida que crece el número de módulos, el esfuerzo (costo) asociado con la integración de los módulos también crece. Estas características conducen también a la curva total de costo o el esfuerzo que se muestra en la figura.

181

Costo total del software Costo por integrar

Costo o esfuerzo

Región de costo mínimo M

Costo /módulo Número de Módulos

Figura 6.1.- Modularidad y costo del software.

Los pasos a seguir para realizar la descomposición modular son los siguientes y se muestra en la figura 6.2: 1. Identificar los módulos. 2. Describir cada módulo. 3. Describir las relaciones entre módulos.

PROGRAMA PRINCIPAL

Módulo 2 Módulo 1

Módulo 11

Módulo 111

Módulo 21

Módulo 112

Módulo 22

Módulo 23

Módulo 221

Figura 6.2.-Arquitectura de la descomposición modular.

182

Tipos de módulos: Código fuente, en el lenguaje de programación usado. Tabla de datos, para datos de inicialización u otros. Configuración, se agrupa en un módulo toda la información de configuración en el entorno de trabajo. Otros: archivos de ayuda en línea, manuales, etc. Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficientemente válida.

1. Independencia Funcional. a. Requisitos/componentes. En un principio, cada función será realizada en un módulo distinto. Si las funciones son independientes los módulos tendrán independencia funcional. b. Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo. c. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión. 2. Acoplamiento.- Mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interface: a. FUERTE: i. POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de otro. ii. COMÚN, se emplea en una zona común de datos a la que tienen acceso varios módulos. b. MODERADO: i.DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos afecta a todos estos módulos. ii.POR ETIQUETA, el intercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, árbol, grafo...). c. DÉBIL: i.DE DATOS, viene dado por los datos que intercambian los módulos, es el mejor posible. ii.SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

3. Cohesión.- Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el número de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo. a. ALTA: i.COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos. ii.COHESIÓN FUNCIONAL, el módulo realiza una función concreta y específica. b. MEDIA: i.COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma secuencial. ii.COHESIÓN DE COMUNICACIÓN, elementos que operan con el mismo conjunto de datos de entrada o de salida. iii.COHESIÓN 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 diseño arquitectónico? Comprende el establecicmiento de un marco de trabajo estructural básico 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 jerárquica de los componentes (módulos), la manera en la que dichos componentes interactúan y la estructura de datos que es utilizada por dichos componentes.

Arquitecturas de Dominio Específico Son arquitecturas diseñadas para cubrir un sistema o una familia de sistemas pero muy centradas en un área o dominio determinado y enfocadas a la reutilización. Pasos para su construcción (según W. Tracz, 1991):

1. Definición del dominio. 2. Definición de requisitos y conceptos del dominio específico. 3. Definición de restricciones de implementación del dominio. 4. Desarrollo de modelos y arquitecturas del dominio. 5. Generación de productos reutilizables.

Megaprogramación DSSA

Tecnología OO (frameworks)

Ingeneria del Dominio

Figura 6.3.- Arquitecturas de Dominio específico (DSSA).

Dos tipos de modelos de dominio específico: • Modelos genéricos los cuales son abstracciones de un número de sistemas reales y que encapsulan las características 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 aplicación más especializados:

184

• Analizador léxico • Tabla de símbolos • Analizador sintáctico • Árbol de sintaxis • Analizador semántico • Generador de código El modelo genérico de compilador podría ser organizado de acuerdo a diferentes modelos arquitectónicos.

Tabla de simbolo

Análisis Lexicos

Análisis Sintáctico

Análisis Semántico

Generación de Código

Figura 6.4.- Modelo de Compilador.

• Modelos de referencia los cuales son más abstractos. Modelos idealizados. Proveen un medio de información acerca de cierta clase de sistemas y permiten comparar diversas arquitecturas. Se derivan a partir de un estudio del dominio de la aplicación antes que a partir de sistemas existentes. Pueden ser usados como una base para la implementación del sistema o para comparar diferentes sistemas. Actúan como un estándar para evaluar sistemas.

7

Application

6

Application

Presentation

5

Presentation

Session

4

Session

Transporte

3

Network

Network

Network

2

Data link

Data link

Data link

1

Physical

Physical

Physacal

Communications medium

Figura 6.5.- El modelo OSI es un modelo en capas para sistemas de comunicación.

185

6.2.1. DISEÑO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido. La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación 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 tráfico aéreo. Un conjunto de sensores distribuidos recolecta la información del flujo de tráfico y la procesa localmente antes de enviarla al cuarto de control. Los sistemas de software compuestos de procesos múltiples no necesariamente son sistemas distribuidos. Si más de un procesador está disponible, entonces se puede implementar la distribución, pero los diseñadores del sistema no siempre consideran lo puntos de distribución durante el proceso de diseño. El enfoque de diseño para este tipo de sistemas es esencialmente el mismo que para los de tiempo real. Ventajas Es económica. El uso de componentes comúnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento Desventajas En ocasiones se menciona también la limitante física; existen factores que limitan la velocidad máxima de un procesador, independientemente del factor económico. Barreras físicas infranqueables, tales como la velocidad de la luz, efectos cuánticos al reducir el tamaño de los elementos de los procesadores, y problemas causados por fenómenos eléctricos a pequeñas escalas Los ordenadores multiprocesador presentan problemas de diseño, derivados del hecho de que 2 programas se ejecuten simultáneamente y potencialmente pueden interferirse entre sí. Por ello existen dos arquitecturas que resuelven dichos problemas. Arquitectura SMP (Uma) .- Los multiprocesadores simétricos (Symmetric Multiprocessor) son ordenadores con arquitectura de memoria compartida que presentan en la memoria principal un acceso simétrico desde cualquier procesador, es decir, el retardo en el acceso a cualquier posición de memoria es el mismo con independencia del procesador desde el que se realice la operación 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 diseño de software Multiproceso.

Arquitectura DSM (Numa).- La memoria compartida distribuida o DSM es una abstracción que se propone como alternativa a la comunicación 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 asimétrico. Esta arquitectura de memoria que se genera en retardo de acceso dependiente tanto la posición de memoria como el procesador se denomina Acceso No Uniforme a Memoria (NUMA), hace su aparición 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 paginación. Las páginas quedan restringidas a estar necesariamente en un único ordenador. Cuando un programa intenta acceder a una posición virtual de memoria, se comprueba si esa página se encuentra de forma local. Si no se encuentra, se provoca un fallo de página, y el sistema operativo solicita la página al resto de computadoras. El sistema funciona de forma análoga al sistema de memoria virtual tradicional, pero en este caso los fallos de página se propagan al resto de ordenadores, hasta que la petición llega al ordenador que tiene la página virtual solicitada en su memoria local. A primera vista este sistema parece más 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 tráfico de páginas excesivo. De la misma manera que la arquitectura SMA se divide en: ccNUMA docNUMA COMA SVM Ventajas • Es económica. • El uso de componentes comúnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento, a un precio menor que el de máquinas con procesadores especialmente diseñados (como por ejemplo las máquinas de procesadores vectoriales y de propósito específico). • 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 introducción de nueva tecnología a un costo posiblemente elevado. Por otro lado, una arquitectura paralela se puede actualizar en términos de rendimiento simplemente agregando más procesadores.

Desventajas • En ocasiones se menciona también la limitante física; existen factores que limitan la velocidad máxima de un procesador, independientemente del factor económico. • Barreras físicas infranqueables, tales como la velocidad de la luz, efectos cuánticos al reducir el tamaño de los elementos de los procesadores, y problemas causados por fenómenos eléctricos a pequeñas escalas, restringen la capacidad máxima de un sistema uniprocesador, dejando la opción obvia de colocar muchos procesadores para realizar cálculos cooperativamente.

6.2.2. DISEÑO 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 información separando la interfaz de usuario (Nivel de presentación) de la gestión de la información (Nivel de gestión de datos). El funcionamiento básico 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 más ventajosa en un sistema multiusuario distribuido a través de una red de computadoras. Sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico. Características de un cliente en la arquitectura C/S el remitente de una solicitud es conocido como cliente, y características son: Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo). Espera y recibe las respuestas del servidor. Por lo general, puede conectase a varios servidores a la vez. Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario. Características de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo). Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado). No es frecuente que interactúen 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 Centralización 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 dañar el sistema. Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Se reduce el tráfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstracción como por ejemplo SQL.

Las siguientes definiciones son las que se utilizan comúnmente en el diseño y arquitectura. Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulación. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.

189

Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles. Tipificación. Es la definición 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 través de la cual su existencia trasciende el tiempo (es decir, el objeto continúa existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado). Este software tendrá la función 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 librerías que incluyen funciones para gestionar los sockets raw que se utilizan. Una librería que permite la creación de paquetes IP con el formato requerido por las políticas. 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 estadísticas.

70.1

8

70.2

80.2

80.1

1 7 10.2

60.1

60.2

10.1

6 2

50.1

20.2

5

3

50.2

20.1

4 40.1

30.2 40.2

30.1

6.8.- Creación de un software de arquitectura cliente/servidor.

190

Las tres librerías 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. Librería de gestión de sockets Esta librería, basándose en los sockets de Linux deberá ofrecer funciones para abrir, cerrar y atarse a un socket, además de enviar y recibir un paquete. Librería de tiempo Esta librería contendrá funciones que permitirán ofrecer el tiempo desde la media noche con dos precisiones distintas. Por un lado en formato segundos/microsegundos, por otro simplemente en milisegundos. Librería de construcción de paquetes Esta librería especificará una estructura que mantenga los campos estándar de una cabecera IP pero que, además, añada una serie de campos en las opciones que nos permita establecer un sello de tiempos apropiado. La librería soporta dos formatos: uno que utiliza una opción de 32 bits estandarizada en IP y que mide el tiempo en milisegundos desde la media noche, otro no estándar que utiliza 64 bytes para representar ese mismo tiempo en formato segundos/microsegundos.

6.2.3. DISEÑO DE SOFTWARE DISTRIBUIDO

Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Es una colección de computadoras autónomas 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 computación El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de alta velocidad a principios de 1970. Más 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, diseñado 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 colección de redes de área local y de área extensa interconectadas, que enlazan millones de ordenadores. Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de cómputo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la información 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 están distribuidos geográficamente, potencial para el crecimiento del sistema para acomodar la expansión del negocio y un marco para la integración de sistema usados por diferentes compañías y organizaciones de usuarios.

191

PC

Mac

Escaner

Pantalla

Servidor RED PC portatil

Multifuncional

Monitor LDC

Impresora

Conmutador

Modem

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

Características Colouris, establece que son seis las características principales responsables de la utilidad de los sistemas distribuidos. Se trata de:

1).- Compartición de Recursos El término '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 compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clásicos desde siempre han provisto compartición 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 automáticamente los beneficios de la compartición de recursos. Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido,

192

manipulado y actualizado de una manera fiable y consistente. Surge el término genérico de gestor de recursos. Un gestor de recursos es un módulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas políticas y métodos específicos junto con requisitos comunes para todos ellos. Éstos incluyen la provisión de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localización; la traslación de nombre de recurso a direcciones de comunicación y la coordinación 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 informático es abierto si el sistema puede ser extendido de diversas maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos, memoria o interfaces de comunicación, etc.) o con respecto a las extensiones software (añadir características al sistema operativo, protocolos de comunicación y servicios de compartición de recursos, etc.). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el que nuevos servicios de compartición de recursos se pueden añadir sin perjudicar ni duplicar a los ya existentes. Básicamente los sistemas distribuidos cumplen una serie de características: Los interfaces de software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores. En una palabra, las interfaces se hacen públicos. Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo, posiblemente proveniente de vendedores diferentes. Pero la conformidad de cada componente con el estándar publicado debe ser cuidadosamente comprobada y certificada si se quiere evitar tener problemas de integración.

3).- Concurrencia Cuando existen varios procesos en una única máquina decimos que se están ejecutando concurrentemente. Si el ordenador está equipado con un único procesador central, la concurrencia tiene lugar entrelazando la ejecución 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 máquinas, cada una con uno o más procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutándose en paralelo. En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones: Muchos usuarios interactúan simultáneamente con programas de aplicación.

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 interacción se ejecutan aisladamente en la estación 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 más procesos servidores para cada tipo de recurso. Estos procesos se ejecutan en distintas máquinas, de manera que se están ejecutando en paralelo diversos servidores, junto con diversos programas de aplicación. 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 múltiples instancias del proceso gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para asegurarse de que no existen conflictos. La sincronización 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 más pequeña 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 podría contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresión y otros servidores de propósito específico. A menudo se conectan varias redes de área local para formar internetworks, y éstas podrían 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 aplicación no deberían 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 diseño de los sistemas distribuidos. El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario aparecerán serias limitaciones. La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño 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, debería 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 número de usuarios y estaciones de trabajo en un sistema distribuido. Entonces, debe ser posible añadir ordenadores servidores para evitar el cuello de botella que se produciría si un solo servidor de ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. En este caso el sistema deberá estar diseñado de manera que permita trabajar con ficheros replicados en distintos servidores, con las consideraciones de consistencias que ello conlleva. Cuando el tamaño y complejidad de las redes de ordenadores crece, es un objetivo primordial diseñar software de sistema distribuido que seguirá siendo eficiente y útil con esas nuevas configuraciones de la red. Resumiendo, el trabajo necesario para procesar una petición simple para acceder a un recurso compartido debería ser prácticamente independiente del tamaño de la red. Las técnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la técnica asociada de caching, y el uso de múltiples servidores para manejar ciertas tareas, aprovechando la concurrencia para permitir una mayor productividad. Una explicación completa de estas técnicas puede encontrarse en [Colouris 1994].

194

5).- Tolerancia a Fallos Los sistemas informáticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podrían producir resultados incorrectos o podrían pararse antes de terminar la computación que estaban realizando. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre sí: Redundancia hardware (uso de componentes redundantes) y recuperación del software (diseño de programas que sean capaces de recuperarse de los fallos). En los sistemas distribuidos, la redundancia puede plantearse en un grano más fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas. La recuperación del software tiene relación con el diseño 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 también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una máquina 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 podría desplazarse a otra estación de trabajo; un proceso servidor podría ejecutarse en otra máquina. 6).- Transparencia La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una colección de componentes independientes. La transparencia ejerce una gran influencia en el diseño del software de sistema. El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Las transparencias definidas son: Transparencia de Acceso: Permite el acceso a los objetos de información remotos de la misma forma que a los objetos de información locales. Transparencia de Localización: Permite el acceso a los objetos de información sin conocimiento de su localización Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de información compartidos y de forma que no exista interferencia entre ellos. Transparencia de Replicación: Permite utilizar múltiples instancias de los objetos de información para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicación tengan por que conoces la existencia de las replicas. Transparencia de Fallos: Permite a los usuarios y programas de aplicación completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software. Transparencia de Migración: Permite el movimiento de objetos de información dentro de un sistema sin afectar a los usuarios o a los programas de aplicación. Transparencia de Prestaciones: Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varía. Transparencia de Escalado: Permite la expansión del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicación.

195

Las dos más importantes son las transparencias de acceso y de localización; su presencia o ausencia afecta fuertemente a la utilización 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. DISEÑO 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 diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño. 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 computación de tiempo real. La computadora está controlando algo que interactúa con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.

Satelite

PC

PC PC

Servidor PC

Servidor Web XML

PC

PC

Figura 6.10.- Arquitectura en tiempo real.

Generan alguna acción en respuesta a sucesos externos. Para realizar esta función, ejecutan una adquisición 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 están frecuentemente dedicados a una única aplicación.

196

Durante muchos años, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reducción del coste del hardware ha hecho posible para la mayoría de las compañías, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatización industrial, investigación medica y científica, gráficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentación industrial. Entre los muchos aspectos relativos al diseño de tiempo real están: la coordinación 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 especificación de las ligaduras de tiempo externas e internas del sistema y el asegurar la precisión de su base de datos. Cada diseño de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento de sistema. En la mayoría de los casos, el rendimiento de un sistema de tiempo real se mide con una o más características relativas al tiempo, pero también se utilizan otras medidas, tales como la tolerancia al fallo. Algunos sistemas de tiempo real se han diseñado para aplicaciones en las que sólo el tiempo de respuesta o la transferencia de datos es crítica. Otras aplicaciones de tiempo real requieren la optimización de ambos parámetros bajo unas condiciones de carga extremas. Y lo que es más, los sistemas de tiempo real deben manejar sus cargas máximas, mientras se ejecutan varias tareas simultáneamente. Puesto que el rendimiento de un sistema de tiempo real se determina principalmente por el tiempo de respuesta del sistema y su razón de transferencia de datos, es importante comprender estos dos parámetros. 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 acción. Frecuentemente, la detección del suceso y la generación de la respuesta son tareas sencillas. Es el procesamiento de la información sobre el suceso para determinar la respuesta adecuada lo que puede implicar algoritmos complejos que consumen mucho tiempo. Entre los parámetros clave que afectan al tiempo de respuesta está el cambio de contextos y la latencia de la interrupción. El cambio de contexto se refiere al tiempo y sobrecarga necesitado para conmutar entre tareas, y la latencia de interrupción es el tiempo que pasa antes de que el cambio sea realmente posible. Otros parámetros que afectan al tiempo de respuesta son la velocidad de calculo y el acceso a memorias masivas. La razón de transferencia de datos indica con que rapidez se introducen o salen del sistema los datos series o paralelos, tanto los analógicos como digitales. Los sistemas de tiempo real necesitan normalmente para procesar un flujo continuo de datos de llegada. El diseño debe asegurar que no falte ningún dato. Además, un sistema de tiempo real debe responder a los sucesos que son asíncronos. Por lo tanto, la secuencia de llegada y el volumen de los datos no pueden predecirse fácilmente de antemano. Aunque todas las aplicaciones de software deben ser fiables, los sistemas de tiempo real hacen una especial demanda de fiabilidad, reinicialización y recuperación de fallos. Debido a que el mundo real está siendo monitorizado y controlado, la pérdida de monitorizado o control (o cambios) es intolerable en muchas circunstancias. Consecuentemente, los sistemas de tiempo real contienen mecanismos de restauración y recuperación de fallos y frecuentemente tienen incorporados redundancias para asegurar la restauración. 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 automáticos de los bancos, también 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 característica 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 estímulo externo –interrupción- en un tiempo dictado por el mundo externo. Debido a que frecuentemente, se presentan múltiples

197

estímulos (interrupciones), deben establecerse prioritarias, en otras palabras, la tarea más importante debe ser siempre servida de las ligaduras de tiempo predefinidas, independientemente de otros sucesos. El manejo de interrupciones supone, no sólo almacenar información, de forma que la computadora pueda restablecer correctamente la tarea interrumpida, sino también 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 interrupción, que bifurca al software apropiado para el manejo de la interrupción. 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 asignación importante como la función, pero las decisiones de asignación relativas al rendimiento son frecuentemente difíciles 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 función de gestión de base de datos. Sin embargo, puede parecer que las bases de datos distribuidas constituyen el método preferido en los sistemas de tiempo real, debido a que multitarea es muy común 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 rápida, fiable y con menos cuellos de botella. El uso de una base de datos distribuida par aplicaciones de tiempo real divide el tráfico 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 partición y replicación de los datos. Aunque la redundancia de los datos mejora el tiempo de requisitos de replicación para los archivos distribuidos también producen problemas logísticos y de sobrecarga, puesto que todas las copias de los archivos deben ser actualizadas, además el uso de base de datos distribuida introduce el problema de control de concurrencia. El control de concurrencia implica la sincronización de las bases de datos de forma que todas las copias tengan la misma y correcta información disponible para los accesos. El método 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 actualización requerida. Sin embargo, se han desarrollado algunas técnicas para aumentar la velocidad de actualización y resolver el problema de concurrencia. Una de estas, llamada protocolo del escritor exclusivo, mantiene la consistencia de los archivos replicados, permitiendo que sólo 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 diseñado exclusivamente para aplicaciones de tiempo real y sistemas operativos de propósito 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 propósito general comportándose como software de aplicación, el ejecuta varias funciones del sistema operativo, particularmente las que afectan al rendimiento de tiempo real de una forma más rápida y eficiente que el sistema operativo de propósito general. Todos los sistemas operativos deben tener un mecanismo de planificación 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. Además, debido a que las interrupciones de prioridad ocurren en respuesta a sucesos asíncronos 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 mínimos programas en memoria principal, de forma que se evite la sobrecarga del almacenamiento en la misma. Para determinar cuándo en una aplicación, 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 elección del lenguaje de programación. Puede usarse con efectividad muchos lenguajes de programación de propósito general. Sin embargo una clase llamada lenguajes de tiempo real, se utilizan frecuentemente en aplicaciones especializadas de comunicaciones y militares. Varias características de un lenguaje de tiempo real hace diferente de un lenguaje de propósito general. Éstas incluyen la capacidad de multitarea, construcciones para implementación directa de funciones de tiempo real y características modernas de programación que ayuden a asegurar la corrección del programa. Es importante que el lenguaje de programación soporte directamente la multitarea debido a que los sistemas de tiempo real deben responder a sucesos asíncronos que ocurren simultáneamente. 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 ejecución del programa de tiempo real. El soporte de tiempo de ejecución requiere menos memoria que un sistema operativo y puede ser adaptado a una aplicación, incrementando así el rendimiento.

ANÁLISIS Y SIMULACIÓN DE SISTEMAS DE TIEMPO REAL Requisitos funcionales de un sistema de tiempo real: Manejo de interrupciones y cambio de contexto. Tiempo de respuesta. Razón de transferencia de datos y tiempo invertido. Asignación de recursos y manejo de prioridades Sincronización de tareas y comunicaciones entre tareas.

199

EJERCICIOS UNIDAD VI

1.- Desarrollo de un sistema para la gestión de artículos deportivos de la empresa Pumas del sector de ventas de deportes a clientes tanto a mayoristas como a minoristas.

200

CONCLUSIÓN Existen diferentes tipos de sistemas con los que el ser humano está en contacto todos los días, pero el analista de sistemas está familiarizado y enfocado con los diferentes sistemas de información 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 inversión en el software. Ahora que la tecnología está en un continuo cambio, el propósito principal del analista es desarrollar aplicaciones muy complejas en cuestión 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 creación y el uso de procedimientos específicos para garantizar el éxito de dicho proyecto, incluyendo tanto la coordinación del esfuerzo de los integrantes como la necesaria secuenciación 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, tecnología y creatividad. En el diseño de un sistema de información o software de aplicación, se debe tomar en cuenta los efectos que pueda producir en la introducción del nuevo sistema sobre el entono en el que se va a poner a funcionar, adecuando los criterios de análisis y diseño a las características del mismo. En este contexto se esta adquiriendo una importante y creciente adaptación de todo sistema-producto para que sea sencilla, cómoda, efectiva y eficiente. De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene como objetivo la optimización de los entornos hombre – máquina. Si bien en un principio estaba concentrada en los aspectos antropométricos de la relación hombre – máquina; en la actualidad a pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento). Así, con respecto al diseño de herramientas de software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de información en pantalla, profundidad de menús, formatos de iconos, nombre de comandos, control de cursores, tiempo de respuesta, manejo de errores, estructura de datos, enlaces de información, utilización 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 técnicas y estudios previos de acuerdo a las necesidades y objetivos del sistema. Al término del análisis, diseño, 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 diseño 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 diseño 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 están 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 diseño 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 británico pedagogo agrónomo e investigador. Fue director de Wye College y director de la Estación Experimental de Rothamsted .

201

BIBLIOGRAFIA

1. Kendall, Kenneth E. (2001). Análisis y Diseño de Sistemas. Ed. Prentice-Hall. 2. Laudon & Laudon 8/E (2003). Management Information Systems. Ed. Prentice-Hall. 3. Pressman Roger S (2001). Ingeniería del software. Ed. McGraw-Hill. 4. Sommerville, Ian (2001). Ingeniería de software. Ed. Prentice-Hall. 5. Yourdan, Edward (1999). Análisis 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). Introducción al Proceso Software Personal. Ed. Addison Wesley. 10. Pfleeger, Shari Lawrence (2002). Ingeniería de Software Teoría y práctica. Ed. Ptentice-Hall. 11. Bruegge Bernd (2001). Ingeniería de Software Orientada a Objetos. Ed. Prentice-Hall.

202

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

PUBLICACIÓN EN WORLD WIDE WEB

PAGINAS DE PDF Notas de profesores http://profesores.elo.utfsm.cl/~agv/elo329/1s03/lectures/CharlaBreveISW.pdf (22 Oct.2009) Ingeniería Sistemas de Software http://www.itlalaguna.edu.mx/Academico/Carreras/sistemas/ingsofware1/Unidad1.pdf (26 Oct. 2009) Análisis de Diseño 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) Introducción Sistemas Distribuidos

http://grasia.fdi.ucm.es/jpavon/dso/introsistemasdistribuidos.pdf (30 de Oct. 2009) Ingeniería 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 Ingeniería de Software http://www.slideshare.net/dersteppenwolf/introduccin-a-la-ingeniera-de-softwarequ-es-unbuen-sistema (5 Nov. 2009) Ingeniería de Software http://www.slideshare.net/pilypardo/ingenieria-de-software-presentation (5 Nov. 2009) Ingeniería de Software http://www.slideshare.net/ruthamada/proceso-del-software-una-visin-general (5 Nov. 2009) Ingeniería de Software II htp://www.slideshare.net/astaroth97/diagramas-de-flujo-975756 (8 Nov. 2009) Ingeniería de Software II http://www.slideshare.net/guestd7f491a/diagrama-de-flujo-2135078 (8 Nov. 2009) Ingeniería 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) Ingeniería de Software http://www.scribd.com/doc/21945705/Resumen-de-Modelos-de-Procesos-de-Software (28 Nov. 2009) Ingeniería 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