Analisis y Diseno de Sistemas 6ª [6 ed.] 9702605776, 9789702605775

Table of contents :
Análisis y diseño de sistemas
Resumen de Contenido
Contenido
Prefacio
1 El Rol del Analista de Sistemas
2 El Estilo Organizacional y su Impacto En los Sistemas de Información
3 Determinación de la Viabilidad y Administración de las Actividades de Análisis y Diseño
4 Recopilación de Información: Métodos Interactivos
5 Recopliación de Información : Métodos no Intrusivos
6 Elaboración de Prototipos, Rad y programación Extrema
7 Uso de Diagramas de Flujo de Datos
8 Análisis de Sistemas Mediante Diccionarios de Datos
9 Descripción de las Especificaciones de Procesos y Decisiones Estructuradas
10 Preparación de la Propuesta de Sistemas
11 Diseño de una Salida Eficaz
12 Diseño de una Entrada Eficaz
13 Diseño de Bases de Datos
14 Diseño de Interfaces de Usuario
15 Diseño de Procedimientos Precisos de Entrada de Datos
16 Aseguramiento de la Calidad Mediante Ingeniería de Software
17 Implementación Exitosa del Sistema de Información
18 Análisis y Diseño de sistemas Orientado a Objetos usando el Lenguaje Unificado de Modelación (UML)
Glosario
Acrónimos
Índice

Citation preview

PORTADA-Kendall afa 2

2/10/05

10:16 AM

Page 1

KENDALL & KENDALL

❖ Un tratamiento más profundo de XML ❖ Mayor cobertura del diseño para intranets y extranets, incluyendo técnicas sencillas de navegación en pantalla ❖ Una explicación más detallada sobre cómo decidir entre usar software comercial empacado (COTS) o subcontratarlo con un ASP ❖ Nueva cobertura sobre la implementación de medidas de seguridad y privacidad en sitios Web, como firewalls, políticas de privacidad corporativas y filtrado del correo electrónico ❖ Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema (XP) y métodos ágiles para desarrollar sistemas orientados al cliente ❖ Un tratamiento más amplio del software para monitorear el tráfico en la Web, realizar perfiles de la audiencia y promover sitios Web corporativos para garantizar la eficacia de los nuevos sistemas de comercio electrónico ❖ Nueva cobertura de la metodología Seis Sigma para mejorar la calidad del diseño de software y sistemas

Análisis y diseño de sistemas

Análisis y diseño de sistemas, de Kendall y Kendall, es un libro que presenta de manera precisa los métodos, herramientas y técnicas de desarrollo de sistemas con un toque humorístico y fácil de entender. Este libro pone énfasis en los aspectos básicos que los estudiantes deben conocer sobre las actividades de un analista. Además de detallar el proceso de análisis y ofrecer explicaciones paso a paso sobre el uso de técnicas especializadas, el libro pone especial atención en el impacto de los sistemas en Novedades de las organizaciones y los efectos de las esta sexta edición decisiones de diseño y métodos de salida en los usuarios. ❖ Más de 65 Oportunidades de consultoría y una gran cantidad de casos breves enfocados al diseño para comercio electrónico, programación extrema y modelado con UML

Visite el sitio Web de este libro en: ww.pearsoneducacion.net/kendall donde encontrará ejercicios, actividades y apoyos para el profesor.

Visítenos en: www.pearsoneducacion.net

sexta edición

ANÁLISIS Y DISEÑO DE SISTEMAS SEXTA

EDICIÓN

KENNETH E. KENDALL Rutgers University School of Business–Camden Camden, New Jersey

JULIE E. KENDALL Rutgers University School of Business–Camden Camden, New Jersey TRADUCCIÓN: Antonio Núñez Ramos Traductor profesional REVISIÓN TÉCNICA: Dr. Macedonio Alanís Departamento de Sistemas de Información Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Monterrey Humberto Cárdenas Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Estado de México María Angélica Pérez de Ovalles Departamento de Procesos y Sistemas Universidad Simón Bolívar, Venezuela

Datos de catalogación bibliográfica E. KENDALL, KENNETH y E. KENDALL, JULIE Análisis y diseño de sistemas. Sexta edición PEARSON EDUCACIÓN, México, 2005 ISBN: 970-26-0577-6 Área: Computación Formato: 21 × 27 cm

Páginas: 752

Authorized translation from the English language edition, entitled Systems analysis and design 6th ed., by Kenneth E. Kendall and Julie E. Kendall, published by Pearson Education, Inc., publishing as PRENTICE HALL, INC., Copyright © 2005. All rights reserved. ISBN 0-13-145455-2 Traducción autorizada de la edición en idioma inglés, titulada Systems analysis and design 6/e de Kenneth E. Kendall y Julie E. Kendall publicada por Pearson Education, Inc., publicada como PRENTICE HALL INC., Copyright © 2005. Todos los derechos reservados. Esta edición en español es la única autorizada. Edición en español Editor:

Guillermo Trujano Mendoza e-mail: [email protected] Editor de desarrollo: Miguel B. Gutiérrez Hernández Supervisor de producción: Enrique Trejo Hernández Edición en inglés Executive Editor: Bob Horan Publisher: Natalie E. Anderson Project Manager (Editorial): Kyle Hannon Editorial Assistant: Robyn Goldenberg Senior Marketing Manager: Sharon M. Koch Marketing Assistant: Danielle Torio Project Manager (Media): Joan Waxman Managing Editor (Production): John Roberts Production Editor: Suzanne Grappi Associate Director, Manufacturing: Vincent Scelta

Production Manager: Arnold Vila Manufacturing Buyer: Diane Peirano Design Manager: Maria Lange Interior Design: John Romer Cover Design: Michael Fruhbeis Cover Illustration: Douglas G. Hamilton, Sydney II Manager, Print Production: Christy Mahon Composition/Full-Service Project Management: Interactive Composition Corporation Printer/Binder: Courier-Kendallville

SEXTA EDICIÓN, 2005 D.R. © 2005 por Pearson Educación de México, S.A. de C.V. Atlacomulco No. 500, 5° piso Col. Industrial Atoto 53519 Naucalpan de Juárez, Edo. de México E-mail: [email protected] Cámara Nacional de la Industria Editorial Mexicana. Reg. Núm. 1031. Prentice Hall es una marca registrada de Pearson Educación de México, S.A. de C.V. Reservados todos los derechos. Ni la totalidad ni parte de esta publicación pueden reproducirse, registrarse o transmitirse, por un sistema de recuperación de información, en ninguna forma ni por ningún medio, sea electrónico, mecánico, fotoquímico, magnético o electroóptico, por fotocopia, grabación o cualquier otro, sin permiso previo por escrito del editor. El préstamo, alquiler o cualquier otra forma de cesión de uso de este ejemplar requerirá también la autorización del editor o de sus representantes. ISBN 970-26-0577-6 Impreso en México. Printed in Mexico. 1 2 3 4 5 6 7 8 9 0 - 08 07 06 05

MARCAS REGISTRADAS DE EMPRESAS

Apple y Macintosh son marcas registradas de Apple Computer. Dragon Naturally Speaking es marca registrada de ScanSoft. FormFlow es marca registrada de Adobe Systems Incorporated. Dreamweaver, Macromedia Flash y Likeminds son marcas registradas de Macromedia. HyperCase es marca registrada de Raymond J. Barnes, Richard L. Baskerville, Julie E. Kendall y Kenneth E. Kendall. Lotus 1–2-3, Freelance Graphics y Organizer son marcas registradas de IBM Corporation. Micrografx Designer, Flowcharter, WebCharter y Graphics Suite fueron marcas registradas de Micrografx Corporation. Microsoft Windows, Microsoft Access, Microsoft Word, Microsoft FrontPage, Microsoft PowerPoint, Microsoft Project, Microsoft Excel y Microsoft Visio Professional son marcas registradas de Microsoft Corporation. Netscape Communicator y Netscape Navigator son marcas registradas de Netscape Communications Corp. OmniPage es marca registrada de ScanSoft. ProModel y Service Model son marcas registradas de PROMODEL Corporation. Visible Analyst es marca registrada de Visible Systems Corporation. Web Strategy Pro y Business Plan Pro son marcas registradas de Palo Alto Software. WinFax Pro y Norton Internet Security son marcas registradas de Symantec. Otros nombres de productos y empresas que se mencionan en esta obra podrían ser marcas registradas de sus respectivos propietarios. Las empresas, nombres y/o los datos que se muestran en las pantallas de computadora y los ejemplos de salida son ficticios a menos que se indique lo contrario.

iii

RESUMEN DE CONTENIDO

PARTE I FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS 1 EL ROL DEL ANALISTA DE SISTEMAS 1 2 EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN 27 3 DETERMINACIÓN DE LA VIABILIDAD Y ADMINISTRACIÓN DE LAS ACTIVIDADES DE ANÁLISIS Y DISEÑO 49

PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN 4 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 89 5 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS NO INTRUSIVOS 123 6 ELABORACIÓN DE PROTOTIPOS, RAD Y PROGRAMACIÓN EXTREMA 151

PARTE III EL PROCESO DE ANÁLISIS 7 8 9 10

USO DE DIAGRAMAS DE FLUJO DE DATOS 191 ANÁLISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS 245 DESCRIPCIÓN DE LAS ESPECIFICACIONES DE PROCESOS Y DECISIONES ESTRUCTURADAS 283 PREPARACIÓN DE LA PROPUESTA DE SISTEMAS 319

PARTE IV ASPECTOS ESENCIALES DEL DISEÑO 11 12 13 14 15

DISEÑO DE UNA SALIDA EFICAZ 359 DISEÑO DE UNA ENTRADA EFICAZ 405 DISEÑO DE BASES DE DATOS 443 DISEÑO DE INTERFACES DE USUARIO 497 DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 543

PARTE V INGENIERÍA E IMPLEMENTACIÓN DE SOFTWARE 16 ASEGURAMIENTO DE LA CALIDAD MEDIANTE INGENIERÍA DE SOFTWARE 581 17 IMPLEMENTACIÓN EXITOSA DEL SISTEMA DE INFORMACIÓN 621 18 ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADO A OBJETOS USANDO EL LENGUAJE UNIFICADO DE MODELACIÓN (UML) 657

GLOSARIO 703 ACRÓNIMOS 713 ÍNDICE 714

iv

CONTENIDO

PARTE I FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS 1

EL ROL DEL ANALISTA DE SISTEMAS 1 Tipos de sistemas 2 Sistemas de procesamiento de transacciones 2 / Sistemas de automatización de la oficina y sistemas de trabajo del conocimiento 3 / Sistemas de información gerencial 3 / Sistemas de apoyo a la toma de decisiones 3 / Sistemas expertos e inteligencia artificial 3 / Sistemas de apoyo a la toma de decisiones en grupo y sistemas de trabajo colaborativo apoyados por computadora 4 / Sistemas de apoyo a ejecutivos 4 Integración de las tecnologías de sistemas 4 Aplicaciones de comercio electrónico y sistemas Web 5 / Sistemas de planeación de recursos empresariales 5 / Sistemas para dispositivos inalámbricos y portátiles 5 / Software de código abierto 6 La necesidad del análisis y diseño de sistemas 6 Roles del analista de sistemas 7 El rol de consultor del analista de sistemas 8 / El rol de experto en soporte técnico del analista de sistemas 8 Oportunidad de consultoría 1.1 Contratación sana: se solicita ayuda para comercio electrónico 8 El rol de agente de cambio del analista de sistemas 9 / Cualidades del analista de sistemas 9 El ciclo de vida del desarrollo de sistemas 10 Identificación de problemas, oportunidades y objetivos 10 / Determinación de los requerimientos de información 11 / Análisis de las necesidades del sistema 11 / Diseño del sistema recomendado 12 / Desarrollo y documentación del software 12 / Prueba y mantenimiento del sistema 13 / Implementación y evaluación del sistema 13 / Impacto del mantenimiento 13 Uso de herramientas case 14 Razones para el uso de las herramientas case 15 Herramientas case de bajo y alto nivel 16 Herramientas case de alto nivel 16 / Herramientas case de bajo nivel 16 Ingeniería inversa y reingeniería de software 18 Análisis y diseño de sistemas orientado a objetos 19 Programación extrema y otras metodologías alternas 20 RESUMEN 20 EXPERIENCIA CON HYPERCASE® 1 21 PALABRAS Y FRASES CLAVE 22 PREGUNTAS DE REPASO 23 BIBLIOGRAFÍA SELECCIONADA 23 CASO DE LA CPU EPISODIO 1: EMPIEZA EL CASO 25

v

2

EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN 27 Las organizaciones como sistemas 27 Interrelación e interdependencia de los sistemas 28 / Organizaciones virtuales y equipos virtuales 29 / Adopción de una perspectiva de sistemas 30 Oportunidad de consultoría 2.1 La E de vitamina E significa comercio electrónico 30 Planeación de recursos empresariales: La organización como sistema 32 Descripción gráfica de sistemas 32 Sistemas y el diagrama de flujo de datos de contexto 32 / Sistemas y el modelo de entidad-relación 33 Niveles de administración 39 Implicaciones para del desarrollo de sistemas de información 40 Oportunidad de consultoría 2.2 Donde hay carbón, hay una copia 40 Cultura organizacional 41 Oportunidad de consultoría 2.3 El poder de la pirámide 41 RESUMEN 42 EXPERIENCIA CON HYPERCASE® 2 43 PALABRAS Y FRASES CLAVE 44 PREGUNTAS DE REPASO 44 PROBLEMAS 45 PROYECTOS DE GRUPO 46 BIBLIOGRAFÍA SELECCIONADA 46 CASO DE LA CPU EPISODIO 2: DESCRIPCIÓN DE LAS RELACIONES 47

3

DETERMINACIÓN DE LA VIABILIDAD Y ADMINISTRACIÓN DE LAS ACTIVIDADES DE ANÁLISIS Y DISEÑO 49 Iniciación de un proyecto 49 Problemas en la organización 50 / Selección de proyectos 51 Oportunidad de consultoría 3.1 El sonido más dulce que he probado 51 Determinación de la viabilidad 52 Definición de objetivos 53 / Determinación de recursos 55 / Evaluación de la viabilidad 57 Planeación y control de actividades 57 Cálculo del tiempo requerido 57 Oportunidad de consultoría 3.2 Alimento para reflexionar 58 Uso de gráficas de Gantt para la programación de proyectos 59 / Uso de diagramas Pert 60 Programación de proyectos por computadora 63 Punto de entrega (timeboxing) 64 Administración de las actividades de análisis y diseño 64 Estrategias de comunicación para administrar equipos 65 / Fijación de las metas de productividad del proyecto 65 / Motivación a los miembros del equipo de un proyecto 66 Oportunidad de consultoría 3.3 Cuidado al establecer metas 66 Administración de proyectos con software comercial 67 / Administración de proyectos de comercio electrónico 67 / Cómo evitar el fracaso de un proyecto 68 Proyectos de programación extrema 68 Balance de los recursos de la programación extrema 69 / Prácticas y roles esenciales de la programación extrema 72 / El proceso de desarrollo para un proyecto de XP 77

vi

CONTENIDO

RESUMEN 78 EXPERIENCIA CON HYPERCASE® 3 79 PALABRAS Y FRASES CLAVE 81 PREGUNTAS DE REPASO 81 PROBLEMAS 82 PROYECTOS DE GRUPO 84 BIBLIOGRAFÍA SELECCIONADA 84 CASO DE LA CPU EPISODIO 3: ADQUIRIR CONOCIMIENTO DE LA U 85

PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN 4

RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 89 Entrevistas 89 Cinco pasos para preparar una entrevista 90 / Tipos de preguntas 91 / Cómo colocar las preguntas en una secuencia lógica 94 Oportunidad de consultoría 4.1 Fortalezca sus tipos de pregunta 95 Redacción del informe de la entrevista 97 Oportunidad de consultoría 4.2 Descreme la superficie 97 Diseño conjunto de aplicaciones 97 EXPERIENCIA CON HYPERCASE® 4.1 98

Condiciones que apoyan el uso de JAD 99 / Quién está involucrado 99 / Dónde celebrar las reuniones de JAD 99 / Realización de un análisis estructurado de las actividades del proyecto 100 / Beneficios potenciales del uso de JAD en lugar de las entrevistas tradicionales 100 Oportunidad de consultoría 4.3 ¿Un analista de sistemas, supongo? 100 Potenciales desventajas del uso de JAD 101 Uso de cuestionarios 101 Planeación del uso de cuestionarios 102 / Redacción de preguntas 102 / Uso de escalas en los cuestionarios 106 / Diseño de cuestionarios 107 Oportunidad de consultoría 4.4 El cuestionario insoportable 108 Aplicación de cuestionarios 109 Oportunidad de consultoría 4.5 Orden en la corte 110 RESUMEN 111 EXPERIENCIA CON HYPERCASE® 4.2 112 PALABRAS Y FRASES CLAVE 113 PREGUNTAS DE REPASO 113 PROBLEMAS 114 PROYECTOS DE GRUPO 117 BIBLIOGRAFÍA SELECCIONADA 118 CASO DE LA CPU EPISODIO 4: ESCUCHARÉ AHORA Y PREGUNTARÉ DESPUÉS 119

5

RECOPILACIÓN DE INFORMACIÓN: MÉTODOS NO INTRUSIVOS 123 Muestreo 123 La necesidad de muestreo 124 / Diseño del muestreo 124 / Decisión del tamaño de la muestra 126 Oportunidad de consultoría 5.1 Detección de una muestra 128 Investigación 128 Análisis de documentos cuantitativos 129 CONTENIDO

vii

Oportunidad de consultoría 5.2 Una rosa por cualquier otro nombre... o calidad, no cantidades 131 Análisis de los documentos cualitativos 132 EXPERIENCIA CON HYPERCASE® 5.1 135

Observación del comportamiento del tomador de decisiones 135 Observación de las actividades de toma de decisiones de un gerente típico 135 Observación del entorno físico 137 Observación estructurada del entorno (STROBE) 137 / Aplicación del STROBE 139 Oportunidad de consultoría 5.3 No dependa de su autoimagen o no todo se refleja en un espejo 140 RESUMEN 142 EXPERIENCIA CON HYPERCASE® 5.2 143 PALABRAS Y FRASES CLAVE 144 PREGUNTAS DE REPASO 144 PROBLEMAS 145 PROYECTOS DE GRUPO 147 BIBLIOGRAFÍA SELECCIONADA 148 CASO DE LA CPU EPISODIO 5: VER ES CREER 149

6

ELABORACIÓN DE PROTOTIPOS, RAD Y PROGRAMACIÓN EXTREMA 151 Elaboración de prototipos 151 Clases de prototipos 152 / Elaboración de prototipos como una alternativa al ciclo de vida del desarrollo de sistemas 154 Cómo desarrollar un prototipo 155 Lineamientos para desarrollar un prototipo 156 / Desventajas de la elaboración de prototipos 157 / Ventajas de la elaboración de prototipos 157 Oportunidad de consultoría 6.1 ¿La elaboración de prototipos es lo mejor? 157 Elaboración de prototipos usando software COTS 158 Oportunidad de consultoría 6.2 Cómo allanar el camino para los vínculos del cliente 158 Oportunidad de consultoría 6.3 El criadero de peces 159 El papel del usuario en la elaboración de prototipos 159 Interacción con el prototipo 159 Oportunidad de consultoría 6.4 Este prototipo está todo mojado 160 Desarrollo rápido de aplicaciones 161 Fases del RAD 161 / RAD en comparación con el SDLC 163 Programación extrema 165 Valores y principios de la programación extrema 165 / Actividades recursos y prácticas de la programación extrema 168 / Proceso y herramientas del desarrollo de XP 171 / Lecciones aprendidas de XP 175 / Modelado ágil y melé (SCRUM) 176 RESUMEN 177 EXPERIENCIA CON HYPERCASE® 6 179 PALABRAS Y FRASES CLAVE 180 PREGUNTAS DE REPASO 180 PROBLEMAS 181 PROYECTOS DE GRUPO 182 BIBLIOGRAFÍA SELECCIONADA 183 CASO DE LA CPU EPISODIO 6: ES HORA DE REACCIONAR 184

viii

CONTENIDO

PARTE III EL PROCESO DE ANÁLISIS 7

USO DE DIAGRAMAS DE FLUJO DE DATOS 191 Enfoque del flujo de datos para determinar los requerimientos 191 Ventajas del enfoque del flujo de datos 192 / Convenciones usadas en los diagramas de flujo de datos 192 Desarrollo de diagramas de flujo de datos 194 Creación del diagrama de contexto 194 / Dibujo del diagrama 0 (el siguiente nivel) 195 / Creación de diagramas hijos (niveles más detallados) 195 / Revisión de errores en los diagramas 197 Diagramas de flujo de datos lógicos y físicos 199 Desarrollo de diagramas de flujo de datos lógicos 201 / Desarrollo de diagramas de flujo de datos físicos 202 Particionamiento de los diagramas de flujo de datos 207 Ejemplo de un diagrama de flujo de datos 208 Creación del diagrama de contexto 209 / Dibujo del diagrama 0 209 / Creación de un diagrama hijo 211 Creación de un diagrama de flujo de datos físico 212 Particionamiento del diagrama de flujo de datos 214 Segundo ejemplo de un diagrama de flujo de datos 215 Particionamiento de sitios Web 221 Comunicación mediante diagramas de flujo de datos 222 Oportunidad de consultoría 7.1 No hay un negocio igual al que fluye 223 RESUMEN 224 EXPERIENCIA CON HYPERCASE® 7 225 PALABRAS Y FRASES CLAVE 225 PREGUNTAS DE REPASO 226 PROBLEMAS 226 PROYECTOS DE GRUPO 228 BIBLIOGRAFÍA SELECCIONADA 229 CASO DE LA CPU EPISODIO 7: LOS FLUJOS DE DATOS 230

8

ANÁLISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS 245 El diccionario de datos 245 Necesidad de entender el diccionario de datos 246 El depósito de datos 246 Definición de los flujos de datos 247 / Descripción de las estructuras de datos 249 / Estructuras de datos lógicas y físicas 251 / Elementos de datos 252 / Almacenes de datos 257 Creación del diccionario de datos 259 Análisis de las entradas y salidas 260 / Desarrollo de almacenes de datos 261 Oportunidad de consultoría 8.1 ¿Quiere hacerla en grande en el teatro? ¡Mejore su dicción(ario)! 261 Uso del diccionario de datos 262 Uso de los diccionarios de datos para crear XML 264 RESUMEN 266 EXPERIENCIA CON HYPERCASE® 8 267

CONTENIDO

ix

PALABRAS Y FRASES CLAVE 268 PREGUNTAS DE REPASO 268 PROBLEMAS 268 PROYECTOS DE GRUPO 271 BIBLIOGRAFÍA SELECCIONADA 271 CASO DE LA CPU EPISODIO 8: DEFINICIÓN DE LO QUE QUIERE DECIR 272

9

DESCRIPCIÓN DE LAS ESPECIFICACIONES DE PROCESOS Y DECISIONES ESTRUCTURADAS 283 Panorama general de las especificaciones de procesos 283 Formato de la especificación de procesos 284 Español estructurado 286 Cómo escribir español estructurado 287 Oportunidad de consultoría 9.1 Koci-Naz, Inc. 288 Oportunidad de consultoría 9.2 Moldeamiento de la estructura 289 Diccionario de datos y especificaciones de procesos 290 Tablas de decisión 292 Desarrollo de tablas de decisión 293 Oportunidad de consultoría 9.3 Ahorros en la renta de automóviles de Citron 295 Verificación de la completitud y la exactitud 296 / Tablas de decisión más avanzadas 297 Árboles de decisión 299 Construcción de árboles de decisión 299 Oportunidad de consultoría 9.4 Un árbol gratuito 300 Selección de una técnica de análisis de decisiones estructuradas 301 Especificaciones de proceso físicas y lógicas 303 Uso de las especificaciones del proceso: Balanceo horizontal 304 RESUMEN 307 EXPERIENCIA CON HYPERCASE® 9 308 PALABRAS Y FRASES CLAVE 309 PREGUNTAS DE REPASO 309 PROBLEMAS 310 PROYECTOS DE GRUPO 311 BIBLIOGRAFÍA SELECCIONADA 312 CASO DE LA CPU EPISODIO 9: TABLAS DE DECISIÓN 313

10 PREPARACIÓN DE LA PROPUESTA DE SISTEMAS 319 Cómo determinar las necesidades de hardware y software 319 Cómo inventariar el hardware de cómputo 320/ Cálculo de las cargas de trabajo 321 / Evaluación del hardware de cómputo 322 / Adquisición del equipo de cómputo 322 / Evaluación del software 325 / Herramientas de apoyo a la toma de decisiones 328 / Sistemas expertos, redes neurales y otras herramientas de decisión 329 Oportunidad de consultoría 10.1 Veni, vidi, vendi o: vine, vi, vendí 329 EXPERIENCIA CON HYPERCASE® 10.1 331

Cómo identificar y pronosticar los costos y beneficios 331 Cómo pronosticar los costos y beneficios 331 / Identificación de beneficios y costos 333

x

CONTENIDO

Oportunidad de consultoría 10.2 Y vamos a ver al mago 334 Comparación de los costos y beneficios 335 Análisis del punto de equilibrio 335 / Análisis de flujo de efectivo 336 / Análisis de valor presente 337 EXPERIENCIA CON HYPERCASE® 10.2 337

Lineamientos para el análisis 339 / Cómo examinar las alternativas de sistemas 339 La propuesta de sistemas 340 Organización de la propuesta de sistemas 340 / Uso de cifras para una comunicación eficaz 341 Presentación de la propuesta de sistemas 346 Cómo entender al público 346 / Organización de la presentación de la propuesta de sistemas 346 Oportunidad de consultoría 10.3 ¿Se debe eliminar esta gráfica? 347 Principios de la presentación oral 348 RESUMEN 348 EXPERIENCIA CON HYPERCASE® 10.3 349 PALABRAS Y FRASES CLAVE 350 PREGUNTAS DE REPASO 350 PROBLEMAS 351 BIBLIOGRAFÍA SELECCIONADA 354 CASO DE LA CPU EPISODIO 10: LA PROPUESTA DE SISTEMAS 356

PARTE IV ASPECTOS ESENCIALES DEL DISEÑO 11 DISEÑO DE UNA SALIDA EFICAZ 359 Objetivos del diseño de la salida 359 Diseño de la salida para satisfacer un propósito específico 360 / Diseño de salida para satisfacer al usuario 360 / Entrega de la cantidad adecuada de salida 360 / Asegúrese de que la salida esté donde se necesita 360 / Suministro de la salida a tiempo 360 / Elección del método de salida correcto 361 Relación del contenido de salida con el método de salida 361 Tecnologías de salida 361 Oportunidad de consultoría 11.1 ¿Su jaula o la mía? 365 Factores a considerar cuando se seleccione la tecnología de salida 368 Oportunidad de consultoría 11.2 Una forma correcta, una forma incorrecta y un metro 372 Cómo afecta a los usuarios el sesgo de la salida 373 Reconocimiento del sesgo en la forma en que se use la salida 373 / Cómo evitar el sesgo en el diseño de la salida 374 Diseño de salida impresa 374 Lineamientos para diseñar un informe impreso 375 Oportunidad de consultoría 11.3 ¿Su trabajo es pesado? 376 Diseño de la salida para informes en monitores 377 Lineamientos para el diseño de pantallas 377 / Uso de la salida gráfica en el diseño de pantalla 378 Diseño de un sitio Web 379 Lineamientos generales para diseñar sitios Web 380 Producción de la salida y XML 387 CONTENIDO

xi

Oportunidad de consultoría 11.4 Un día de campo 388 RESUMEN 389 PALABRAS Y FRASES CLAVE 389 PREGUNTAS DE REPASO 389 EXPERIENCIA CON HYPERCASE® 11 390 PROBLEMAS 391 PROYECTOS DE GRUPO 394 BIBLIOGRAFÍA SELECCIONADA 395 CASO DE LA CPU EPISODIO 11: INFORME DE LAS SALIDAS 396

12 DISEÑO DE UNA ENTRADA EFICAZ 405 Diseño de un buen formulario 405 Creación de formularios fáciles de contestar 406 / Satisfacción del propósito previsto 409 / Cómo asegurar la contestación precisa 409 / Cómo hacer formularios atractivos 409 / Diseño de formularios por computadora 410 Oportunidad de consultoría 12.1 Este formulario podría ser dañino para su salud 411 Control de los formularios de negocios 413 Diseño adecuado de pantallas y formularios para la Web 414 Cómo mantener la sencillez de la pantalla 414 / Cómo mantener consistencia en la pantalla 415 / Cómo facilitar el movimiento 415 / Cómo diseñar una pantalla atractiva 415 Oportunidad de consultoría 12.2 Lo apretado no es agradable 417 Uso de iconos en el diseño de pantallas 418 / Diseño de la interfaz gráfica de usuario 418 Oportunidad de consultoría 12.3 ¿Qué se supone que es eso? 420 Cuadros de diálogo con fichas 421 Oportunidad de consultoría 12.4 Sólo es una máscara 423 Uso de color en el diseño de pantallas 424 Diseño de páginas de intranet e Internet 424 RESUMEN 426 EXPERIENCIA CON HYPERCASE® 12 427 PALABRAS Y FRASES CLAVE 428 PREGUNTAS DE REPASO 428 PROBLEMAS 429 PROYECTOS DE GRUPO 433 BIBLIOGRAFÍA SELECCIONADA 434 CASO DE LA CPU EPISODIO 12: CREACIÓN DE PANTALLAS Y FORMULARIOS 435

13 DISEÑO DE BASES DE DATOS 443 Bases de datos 444 Conceptos de datos 444 Oportunidad de consultoría 13.1 Enganche su carreta de limpieza a una estrella 445 Realidad, datos y metadatos 445 / Organización de archivos 452 / Bases de datos relacionales 454 Normalización 456 Los tres pasos de la normalización 456 / Ejemplo de normalización 457 / Uso del diagrama entidad-relación para determinar las claves del registro 466 / Relación uno a muchos 466 / Relación muchos a muchos 466 Lineamientos para el diseño de relación archivo maestro/base de datos 467 Restricciones de integridad 468

xii

CONTENIDO

Uso de la base de datos 469 Pasos en la recuperación y presentación de datos 469 Desnormalización 474 Almacenes de datos 475 Procesamiento analítico en línea 477 / Minería de datos 479 Publicación de bases de datos para Web 479 Oportunidad de consultoría 13.2 Almacenamiento de minerales para la salud, datos para la minería 481 RESUMEN 482 EXPERIENCIA CON HYPERCASE® 13 483 PALABRAS Y FRASES CLAVE 483 PREGUNTAS DE REPASO 484 PROBLEMAS 485 PROYECTOS DE GRUPO 486 BIBLIOGRAFÍA SELECCIONADA 486 CASO DE LA CPU EPISODIO 13: FUNDAMENTOS DE DATOS 487

14 DISEÑO DE INTERFACES DE USUARIO 497 Tipos de interfaz de usuario 497 Interfaces de lenguaje natural 498 / interfaces de pregunta y respuesta 498 / Menús 499 / Interfaces de formulario (formularios de entrada/salida) 501 Oportunidad de consultoría 14.1 Preferiría hacerlo yo mismo 501 Interfaces de lenguaje de comandos 502 / Interfaces gráficas de usuario 503 Oportunidad de consultoría 14.2 No hagan que me atrase 503 Otras interfaces de usuario 504 Oportunidad de consultoría 14.3 Esto no es un foco 504 Lineamientos para el diseño de diálogos 506 Comunicación significativa 506 / Acción mínima de usuario 507 / Funcionamiento normal y consistencia 508 Oportunidad de consultoría 14.4 Quiero retroalimentación 510 Retroalimentación para los usuarios 510 Tipos de retroalimentación 511 / Inclusión de retroalimentación en el diseño 513 Consideraciones especiales para el diseño de comercio electrónico 514 Cómo solicitar retroalimentación a los clientes de sitios Web de comercio electrónico 514 / Navegación fácil por los sitios Web de comercio electrónico 515 Oportunidad de consultoría 14.5 Cuando participa en un maratón, es bueno saber hacia dónde se dirige 515 Diseño de consultas 516 Tipos de consulta 516 / Métodos de consulta 519 Oportunidad de consultoría 14.6 Hey, mírame (otra vez) 521 Búsqueda en la Web 524 Lineamientos para buscar en la Web 525 Minería de datos 525 Oportunidad de consultoría 14.7 Pérdida de clientes potenciales 527 RESUMEN 527 EXPERIENCIA CON HYPERCASE® 14 528 PALABRAS Y FRASES CLAVE 529

CONTENIDO

xiii

PREGUNTAS DE REPASO 530 PROBLEMAS 530 PROYECTOS DE GRUPO 531 BIBLIOGRAFÍA SELECCIONADA 532 CASO DE LA CPU EPISODIO 14: INTERFAZ DE USARIO 533

15 DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 543 Codificación efectiva 543 Dar seguimiento a algo 544 / Clasificación de la información 545 / Cómo ocultar la información 547 / Cómo revelar la información 548 / Unicode 549 / Solicitud de la acción adecuada 550 / Lineamientos generales para la codificación 550 Oportunidad de consultoría 15.1 Aquí hay mucho por resolver 551 Captura de datos efectiva y eficiente 553 Que se debe capturar 553 / Permitiendo a la computadora hacer el resto 554 Oportunidad de consultoría 15.2 Sólo es un código de verano 554 Evitando cuellos de botella y pasos adicionales 556 / Empezando con un buen formulario 556 / Elección de un método de entrada de datos 557 Cómo asegurar la calidad de los datos a través de la validación de la entrada 560 Validación de las transacciones de entrada 560 / Validación de datos de entrada 561 Oportunidad de consultoría 15.3 Capturar o no capturar: he ahí el dilema 562 Proceso de validación 565 Oportunidad de consultoría 15.4 ¿Válida para el estacionamiento? 567 Ventajas de la precisión en los entornos de comercio electrónico 567 Clientes que codifican sus propios datos 567 / Almacenamiento de datos para su uso posterior 567 / Uso de datos a través del proceso de surtido del pedido 568 / Proporcionando retroalimentación a los clientes 568 RESUMEN 568 EXPERIENCIA CON HYPERCASE® 15 569 PALABRAS Y FRASES CLAVE 570 PREGUNTAS DE REPASO 570 PROBLEMAS 571 PROYECTOS DE GRUPO 574 BIBLIOGRAFÍA SELECCIONADA 574 CASO DE LA CPU EPISODIO 15: LA ENTRADA DE DATOS 575

PARTE V INGENIERÍA E IMPLEMENTACIÓN DE SOFTWARE 16 ASEGURAMIENTO DE LA CALIDAD MEDIANTE INGENIERÍA DE SOFTWARE 581 Enfoque de administración de la calidad total 581 Seis sigma 582 / Responsabilidad de la administración de la calidad total 582 / Repaso estructurado 584 Oportunidad de consultoría 16.1 La calidad de mis no es obligatoria 584 Diseño y desarrollo de sistemas 585 / Desarrollo modular 587 / Modularidad en el entorno de windows 588 Uso de diagramas de estructura para diseñar sistemas 588 Dibujo de un diagrama de estructura 592 / Tipos de módulos 594 / Subordinación de módulo 596

xiv

CONTENIDO

Ingeniería de software y documentación 598 Pseudocódigo 599 / Manuales de procedimiento 600 / El método de folklore 601 / Selección de una técnica de diseño y documentación 603 Oportunidad de consultoría 16.2 Escribir es correcto 603 Cómo probar, mantener y auditar 604 El proceso de probar 604 Oportunidad de consultoría 16.3 Estudiando para su prueba de sistemas 606 Prácticas de mantenimiento 607 / Cómo auditar 607 RESUMEN 608 EXPERIENCIA CON HYPERCASE® 16 609 PALABRAS Y FRASES CLAVE 610 PREGUNTAS DE REPASO 610 PROBLEMAS 611 PROYECTOS DE GRUPO 612 BIBLIOGRAFÍA SELECCIONADA 612 CASO DE LA CPU EPISODIO 16: DIAGRAMACIÓN DE LA ESTRUCTURA 613

17 IMPLEMENTACIÓN EXITOSA DEL SISTEMA DE INFORMACIÓN 621 Implementación de sistemas distribuidos 622 Tecnología cliente/servidor 622 / Tipos de redes de sistemas distribuidos 624 / Modelado de redes 626 / Groupware 630 Capacitación de usuarios 632 Estrategias de capacitación 633 / Lineamientos para la capacitación 634 Conversión 635 Oportunidad de consultoría 17.1 Puede guiar un pez al agua... pero no puede hacer que la tome 635 Estrategias de conversión 636 Aspectos de seguridad para los sistemas tradicionales y los basados en Web 637 Seguridad física 638 / Seguridad lógica 638 / Seguridad conductual 639 / Consideraciones especiales de seguridad para el comercio electrónico 639 / Consideraciones de privacidad para el comercio electrónico 640 Otras consideraciones de conversión 641 Metáforas organizacionales y su relación con los sistemas exitosos 641 Evaluación 642 Técnicas de evaluación 642 / Enfoque de utilidad del sistema de información 643 /

Evaluación del sistema 644 Oportunidad de consultoría 17.2 El dulce aroma del éxito 644 Evaluación de sitios Web Corporativos 645 Oportunidad de consultoría 17.3 Limpiando el nuevo sistema 645 RESUMEN 648 PALABRAS Y FRASES CLAVE 649 EXPERIENCIA CON HYPERCASE® 17 649 PREGUNTAS DE REPASO 650 PROBLEMAS 651 PROYECTO DE GRUPO 653 BIBLIOGRAFÍA SELECCIONADA 653 CASO DE LA CPU EPISODIO 17: SEMPER REDUNDATE 655

CONTENIDO

xv

18 ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADO A OBJETOS USANDO EL LENGUAJE UNIFICADO DE MODELACIÓN (UML) 657 Conceptos orientados a objetos 658 Objetos 658 / Clases 658 / Herencia 659 Tarjetas CRC y pensamiento en objetos 660 Interacción durante una sesión de CRC 661 Oportunidad de consultoría 18.1 Haciendo la bobina mágica 661 Conceptos y Diagramas del Lenguaje Unificado de Modelación (UML) 663 Modelado de casos de uso 665 Símbolos del caso de uso 666 / Relaciones del caso de uso 666 / Desarrollo de diagramas de caso de uso 668 / Desarrollo de escenarios de caso de uso 669 Diagramas de actividades 671 Creación de diagramas de actividades 672 Oportunidad de consultoría 18.2 Reciclaje del entorno de programación 674 Diagramas de secuencias y de colaboración 675 Diagramas de secuencias 675 / Diagramas de colaboración 677 Diagramas de clase 678 Sobrecarga de métodos 680 / Tipos de clases 680 / Un ejemplo de clase para la Web 681 / Relaciones 684 / Diagramas de generalización/especialización 687 Diagramas de estados 691 Ejemplo de una transición de estado 692 Paquetes y otros artefactos de UML 693 UML en la práctica 695 Oportunidad de consultoría 18.3 Desarrollo de un sistema que se retrasó mucho tiempo: Uso del análisis orientado a objetos para el sistema de la biblioteca pública Ruminski 695 La importancia de usar UML para el modelado 697 Oportunidad de consultoría 18.4 C-Shore++ 698 RESUMEN 699 PALABRAS Y FRASES CLAVE 699 PREGUNTAS DE REPASO 700 PROBLEMAS 701 BIBLIOGRAFÍA SELECCIONADA 701

GLOSARIO 703 ACRÓNIMOS 713 ÍNDICE 714

xvi

CONTENIDO

PREFACIO

La sexta edición de Análisis y diseño de sistemas, de Kendall y Kendall, contiene muchas características nuevas y actualizadas, como las siguientes: • Nuevas prácticas y valores esenciales de la programación extrema (XP). • Más de 65 Oportunidades de consultoría, que incluyen una gran cantidad de casos breves dirigidos al diseño para comercio electrónico, programación extrema y modelado con UML. • Mayor énfasis en el diseño basado en la Web. • Nuevos enfoques para diseñar sitios Web de comercio electrónico. • Una mayor cobertura del diseño de interfaces gráficas de usuario (GUI). • Nuevas alternativas para la administración de proyectos con la metodología de la programación extrema. • Nuevos enfoques de diseño para las tecnologías inalámbricas, ERP y sistemas basados en Web. • Un tratamiento más profundo de XML. • Mayor cobertura del diseño para intranets y extranets, incluyendo técnicas sencillas de navegación en pantalla. • Un capítulo nuevo orientado a objetos que incluye modelado con UML. • Una explicación más detallada sobre cómo decidir entre el software comercial (COTS) o subcontratarlo con un ASP. • Nueva cobertura sobre la implementación de medidas de seguridad y privacidad en el sitio Web, como firewalls, políticas de privacidad corporativas, PKI, SSL, SET, VPN, filtros URL y filtrado del correo electrónico. • Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema y métodos ágiles para desarrollar sistemas orientados al cliente. • Un tratamiento más amplio del software para monitorear el tráfico en la Web, realizar perfiles de la audiencia y promover sitios Web corporativos para garantizar la eficacia de los nuevos sistemas de comercio electrónico. • Nueva cobertura de la metodología Seis Sigma para mejorar la calidad del diseño de software y sistemas. • Caso de la CPU continuo y actualizado, en el cual se utiliza Visible Analyst y Microsoft Access. • HyperCase 2.5 actualizado, simulación gráfica de una organización en la Web que permite a los estudiantes aplicar sus conocimientos. Análisis y diseño de sistemas, de Kendall y Kendall, es un libro que presenta de manera precisa los métodos, herramientas y técnicas de desarrollo de sistemas con un toque humorístico y fácil de entender.

CARACTERÍSTICAS DE DISEÑO Se dio una apariencia estilizada a las figuras con el propósito de ayudar a los estudiantes a comprender con más facilidad el contenido de las mismas.

xvii

Se utilizan formularios impresos a lo largo de W todo el libro con la idea de mostrar el diseño de entradas y salidas, así como el diseño de cuestionarios. Aunque la computarización de los procesos manuales es una meta para la mayoría de las organizaciones, gran parte de la captura de datos aún se realiza en formularios impresos. El perfeccionamiento del diseño de formularios permite a los analistas garantizar la captura (entrada y salida) de datos precisa y completa. El uso de mejores formularios también contribuye a agilizar los nuevos flujos de trabajo internos resultantes de las recientes aplicaciones automatizadas “negocio a consumidor” (B2C) que se emplean para el comercio electrónico en la Web. Las pantallas de computadora ilustran características importantes del software muy útiles para el analista. En este ejemplo se muestra la manera de detectar vínculos rotos (o modificados) en un sitio Web mediante un paquete como Microsoft Visio. Imágenes de pantalla, tal como las verá en su computadora, presentan aspectos importantes del diseño. Los analistas buscan constantemente cómo mejorar la apariencia de las pantallas (salidas de programa) y las páginas Web que diseñan; todo en aras de facilitar la labor del usuario. Se emplean diagramas conceptuales para presentar las diversas herramientas con que cuentan los analistas de sistemas. En este ejemplo se demuestran las diferencias entre los diagramas lógicos de flujo de datos y los diagramas físicos de flujo de datos. También se ilustran otras herramientas importantes, como los diagramas de entidad-relación, los diagramas de estructura y el español estructurado. Las tablas se utilizan en aquellos casos en que una lista importante requiere atención especial, o cuando la información se tiene que organizar o clasificar. Asimismo, se emplean para complementar la comprensión del lector de la manera en que se organiza el material en el texto general. Las tablas constituyen una opción útil para los analistas cuando desean organizar cifras y texto con el propósito de reflejar una “visión global” significativa. El siguiente ejemplo de una tabla, del capítulo 3, muestra la forma en que los analistas pueden refinar sus planes de actividades de análisis dividiendo las actividades en tareas más pequeñas y calculando el tiempo que les tomará realizarlas. La filosofía que sustenta nuestro libro consiste en que el análisis y diseño de sistemas es un proceso que integra el uso de diversas herramientas con el talento individual del analista de sistemas para refinar sistemáticamente los negocios mediante la implementación o modificación de sistemas de información computarizados. Los analistas de sistemas pueden progresar en sus trabajos asumiendo nuevos retos de tecnología de la información y manteniéndose actualizados en su profesión mediante la aplicación de nuevas técnicas y herramientas. orld’s Trend

1000 Internationa l Lane Cornwall, CT 06050

Pedido del clien te

Por favor impri ma claramente. Vea mediante tarjet a de crédito banca al reverso los códigos de las tallas de los artícu ria, por favor incluy expiración. En las tablas que los. Si a el número de se encuentran los costos de envío la tarjeta de crédit el pago se hace al reverso puede o y la fecha de por correo. Los ver los códigos residentes de Conn ecticut deben inclui de cada talla y determinar Nombre (prime r el impuesto sobre ro, segundo, apellid la venta. o) Gilbert Sulliva n

Calle

115 Buttercup

Ciudad

Lane

Departamento

Penzance

Núm. de cliente

09288

Cantidad

1 4

Estado Código postal PA País 17057 Núm. de catálog o Fecha del ped. (MM/DD/AAAA) Teléfon 9401A o (Incl. cód. de área) 03/12/2003

(si lo conoce)

Núm. de artículo

12343 54224

1 1

Descripción del artículo

Ropa para trotar Calcetas que amort iguan el impacto Shorts para correr Shorts para correr

10617 10617

(215) 747-2837

Talla

M M M M

Color AZ BL AZ VE

Precio

35.50

Total del artículo

35.50

4.25 12.25 12.25

17.00

12.25 12.25

Forma de pago

Cheque

Crédito

Llenar sólo para

compra con tarjeta de

World’s Trend

Núm. de tarj. de

Total de las mercancías

Giro postal

crédito

AmExpress

MC Visa créd.: No reque rido para cargo s en World’s Trend Fecha de expiración MM/A AAA

Número de formu lario

77.00

Impuesto (sólo CT)

Discover

Gastos de envío

Total del pedido

9.80

86.80

0001 03/2003

de pedido de la

Diagrama de flujo de datos lógico

D1

Cliente

Precios

Cliente

Precios

Artículos por comprar

Pago

Recibo

1

ID de artículo

4

3

2

Identificar artículo

Consultar precios

Calcular el costo total del pedido

Artículos y precios

Cantidad por pagar

Asentar la transacción y emitir el recibo

Diagrama de flujo de datos físico

Cliente

Artículos llevados a la caja

D1

Archivo de precios UPC

1

Pasar los Código de barras UPC artículos por el escáner (manual)

D2

Descripción y precios de los artículos

Código UPC

2

Consultar código y precio en el archivo

Archivo temporal de la transacción

Artículos y precios

Artículos, precios y subtotales

Cliente

Efectivo, cheque o tarjeta de débito

Códigos y precios de los artículos

Calcular el costo total

Recibo de la caja registradora

4

3

Cantidad por pagar calculada

Recibir dinero y entregar recibo (manual)

Actividad detallada

Realizar entrevistas Aplicar cuestionarios Leer informes de la compañía Introducir prototipos Observar las reacciones hacia los prototipos

3 4 4 5 3

Análisis del flujo de datos y de decisiones

Analizar el flujo de datos

8

Preparación de la propuesta

Realizar análisis de costos y beneficios Preparar la propuesta Presentar la propuesta

3 2 2

Divida aú más es n tas activi dades.

xviii

PREFACIO

Semanas requeridas

Actividad

Recopilación de datos

ón inuaci po a cont em e el ti calcul o. id requer

Parte I: Fundamentos del análisis de sistemas

Parte II:

Parte V: Ingeniería e implementación de software

Análisis de los requerimientos de información

Parte IV: Aspectos esenciales del diseño

Parte III:

El proceso

de análisis

REPASO DE LA SEXTA EDICIÓN El análisis y diseño de sistemas se imparte por lo general en uno o dos semestres. Nuestro libro funciona en ambos casos. El texto es apropiado para estudiantes universitarios o de posgrado. El nivel y duración del curso puede variar y complementarse con proyectos reales, HyperCase u otros materiales disponibles en la sección de recursos para el profesor del sitio Web de esta obra. El texto se divide en cinco partes principales: Fundamentos del análisis de sistemas (parte I), Análisis de los requerimientos de información (parte II), El proceso de análisis (parte III), Aspectos esenciales del diseño (parte IV) e Ingeniería e implementación de software (parte V). La parte I (capítulos 1-3) pone énfasis en los aspectos básicos que los estudiantes deben conocer sobre las actividades de un analista; cuál es la función de los diversos sistemas de información en una organización, como las computadoras portátiles, las tecnologías inalámbricas y los sistemas ERP; cómo determinar si vale la pena emprender un proyecto de sistemas; nueva cobertura de administración de proyectos de comercio electrónico, y cómo manejar un proyecto de sistemas con herramientas de software especiales. Contiene material actualizado sobre equipos y organizaciones virtuales. Se presentan técnicas para dibujar diagramas de entidadrelación y diagramas de flujo de datos de contexto para los casos en que se entra en contacto por primera vez con una organización. El capítulo 3 incluye material nuevo para explicar la manera en que un enfoque alternativo denominado programación extrema (XP) equilibra los objetivos para manejar el proceso de análisis y diseño. También se presentan los tres papeles del analista de sistemas, como consultor, experto en apoyo técnico y agente de cambio, y se incorporan ideas actualizadas sobre aspectos éticos y lineamientos profesionales para desempeñar el papel de consultor de sistemas. La parte II (capítulos 4-6) resalta el uso de metodologías sistemáticas y estructuradas para realizar el análisis de los requerimientos de información. La aplicación de un análisis contribuye a que el analista garantice que se está enfocando en el problema correcto previo al diseño del sistema. El capítulo 4 presenta un grupo de métodos interactivos, entre ellos las entrevistas, el diseño conjunto de aplicaciones (JAD) y la elaboración de cuestionarios. El capítulo 5 incluye un grupo de métodos discretos para determinar los requerimientos de información de los usuarios. Entre Taller de diseño del RAD

Planeación de requerimientos Identificar los objetivos y requerimientos de información

Implementación

Trabajar con los usuarios para diseñar el sistema

Construir el sistema

Presentar el nuevo sistema

PREFACIO

xix

estos métodos se cuentan el muestreo, la revisión de datos impresos y archivados, y el estudio del comportamiento de los encargados de la toma de decisiones y de su entorno físico. El capítulo 6 presenta una cobertura especialmente novedosa sobre la elaboración de prototipos como otra técnica de recopilación de datos, que da al analista la posibilidad de resolver el problema preciso al involucrar a los usuarios desde el principio. Este capítulo también incluye material sobre el desarrollo rápido de aplicaciones (RAD). El material nuevo permite a los estudiantes comprender el enfoque de programación extrema (XP) para el desarrollo de sistemas. Se explican las prácticas esenciales que distinguen a XP de otras metodologías. Además, se presentan los valores fundamentales para XP y el modelado ágil. En la parte III (capítulos 7-10) se detalla el proceso de análisis. Toma como base las dos partes anteriores para llevar al estudiante al análisis de los flujos de datos y de las decisiones estructuradas y semiestructuradas. Ofrece explicaciones paso a paso sobre el uso de técnicas estructuradas para dibujar diagramas de flujo de datos (DFDs). El capítulo 7 muestra cómo crear diagramas hijos; cómo desarrollar diagramas lógicos y físicos de flujo de datos, y cómo particionar diagramas de flujo de datos. Incluye una sección actualizada que explica el enfoque orientado a objetos de los casos de uso y los diagramas de flujo de datos. El enfoque orientado a objetos del capítulo 8 presenta material sobre el depósito de datos y el balanceo vertical de diagramas de flujo de datos. El capítulo 8 también presenta una amplia cobertura del Lenguaje de Marcado Extensible (XML) y demuestra cómo usar los diccionarios de datos para crear XML. El capítulo 9 contiene material sobre el desarrollo de especificaciones de procesos. Una explicación de las especificaciones lógicas y físicas de procesos ilustra cómo utilizarlas en el balanceo horizontal. La parte III también describe cómo diagramar decisiones estructuradas a través del español estructurado, tablas de decisión y árboles de decisión. Asimismo, se presentan las tecnologías de actualización automática. El capítulo 10 describe diversos métodos para pronosticar costos y beneficios, los cuales son indispensables para decidir la compra de software y hardware. El material nuevo del capítulo 10 ayuda a los estudiantes a evaluar las ventajas y desventajas entre crear software personalizado, comprar software comercial (COTS) o subcontratar el software con un proveedor de servicios de aplicaciones (ASP). Asimismo, el material nuevo muestra a los estudiantes cómo ayudar a los encargados de la toma de decisiones a seleccionar el software de apoyo a la toma de decisiones, sistemas de recomendación y el uso de redes neurales. El capítulo 10 también guía a los estudiantes a través de la presentación y redacción profesional de una propuesta eficaz de sistemas, que incluya cifras y gráficas para comunicarse con los usuarios. En la parte IV (capítulos 11-15) se explican los fundamentos del diseño. Se empieza por el diseño de la salida, puesto que muchos expertos consideran que los sistemas deben orientarse a la salida. El diseño de los formularios basados en la Web se analiza con detalle. Se pone especial atención en relacionar el método de salida con el contenido, el efecto de la salida sobre los usuarios y en el diseño de formularios y pantallas eficaces. El capítulo 11 compara las ventajas y desventajas de la salida, incluyendo las pantallas de informes en la Web, audio, CD-ROM, DVD y la salida electrónica como el correo electrónico, los faxes y los boletines electrónicos. Se resalta el diseño de un sitio Web dedicado al comercio electrónico, y se describe la producción de salida y de XML. El capítulo 12 incluye material novedoso sobre el diseño de formularios de entrada de datos basados en la Web, así como de otros formularios electrónicos. También se presenta el diseño de formularios asistido por computadora. El capítulo 12 también ofrece una amplia cobertura del diseño de sitios Web, con lineamientos para determinar cuándo deben los diseñadores incorporar vídeo, audio y animación en los diseños de sitios Web. Se explican los usos de las tecnologías de actualización y recepción automática de la Web para diseñar la sali-

xx

PREFACIO

da. Se dedica más espacio a describir cómo crear gráficos apropiados para sitios Web corporativos y a diseñar elementos de navegación en pantalla eficaces para usuarios de sitios Web. También hay una mayor cobertura del diseño de páginas para intranets y extranets. Se incluyó una explicación de las restricciones a la integridad de bases de datos y de la manera en que interactúa el usuario con la computadora y cómo diseñar una interfaz apropiada. En esta parte IV se menciona la importancia de la retroalimentación del usuario. También se resalta el diseño de procedimientos precisos para la entrada de datos que aprovechen al máximo las capacidades humanas y de la computadora con el fin de garantizar la entrada de datos de calidad. El capítulo 13 demuestra cómo utilizar los diagramas de entidad-relación para determinar claves de registros, así como para ofrecer lineamientos para el diseño de relaciones archivo/base de datos. Se muestra a los estudiantes la importancia del diseño de bases de datos para conseguir la máxima utilidad del sistema, y la manera en que los usuarios emplean las bases de datos. El capítulo 14 presenta material sobre el diseño de elementos sencillos de navegación en pantalla para los visitantes de sitios Web. También ofrece material actualizado en relación con aspectos importantes de la extracción y el almacenamiento de datos. Asimismo, se incluyen enfoques novedosos para realizar búsquedas en la Web. Se hace énfasis en el material sobre el diseño de GUIs y se proporcionan enfoques recientes para diseñar cuadros de diálogo. El capítulo 14 estructura nuevas consideraciones especializadas de diseño para sitios Web dedicados al comercio electrónico. También contiene explicaciones más detalladas sobre la generación de consultas que permitan a los usuarios realizar búsquedas en la Web. En el capítulo 15 se presenta material actualizado acerca de la administración de la cadena de abastecimiento mediante el diseño eficaz de sistemas de comercio electrónico negocio a negocio (B2B). La parte V (capítulos 16-18) introduce a los estudiantes en la ingeniería de software estructurada y en técnicas de documentación como medios para implementar un sistema de calidad. El capítulo 16 ofrece nuevo material en la adopción de la metodología Seis Sigma para alcanzar la calidad en el diseño de software y sistemas. El capítulo 16 también incluye una sección acerca de los importantes conceptos de generación de código y reingeniería de diseño. Asimismo, explicamos los desarrollos en técnicas estructuradas y enseñamos a los estudiantes cuáles técnicas son apropiadas para cada situación específica. El material sobre diagramas de estructura contiene detalles sobre la manera de utilizar diagramas de flujo de datos para dibujar diagramas de estructura. Además, se incluye material sobre seguridad de sistemas y firewalls. La prueba, auditoría y mantenimiento de sistemas se explica en el contexto de la administración de la calidad total. El capítulo 17 presenta herramientas novedosas para el modelado de redes, lo cual se puede realizar con herramientas populares como Microsoft Visio. Asimismo, contiene una descripción sobre el software de grupo. La parte V también introduce al estudiante al diseño de sistemas cliente/servidor, sistemas distribuidos y múltiples sistemas inalámbricos, como WLANs, redes Wi-Fi y redes Bluetooth. Se ofrece material relacionado con la seguridad y la privacidad al diseñar aplicaciones de comercio electrónico. También se incluye una mayor cobertura sobre seguridad, en especial acerca de firewalls, puertas de enlace, infraestructura de clave pública (PKI), traducción electrónica segura (SET), capas de sockets seguras (SSL), software de protección antivirus, productos de filtrado URL, productos de filtrado de correo electrónico y redes privadas virtuales (VPNs). Además, se presentan temas actuales de interés para diseñadores de aplicaciones de comercio electrónico, como el desarrollo de perfiles de la audiencia y el desarrollo y publicación de políticas de privacidad corporativa. En esta sección se incluye una cobertura actualizada de la manera en que el analista puede promover y a continuación monitorear un sitio Web corporativo; también se presenta el monitoreo de actividades en la Web, la promoción de sitios Web, el análisis del tráfico en la Web y la generación de perfiles de la audiencia, con el propósito de garantizar la eficacia de nuevos sistemas de comercio electrónico. Asimismo, se cubren sistemáticamente técnicas para evaluar los proyectos terminados de sistemas de información.

PREFACIO

xxi

La parte V concluye con el capítulo 18, relativo al análisis y diseño de sistemas orientados a objetos, que contiene una nueva y detallada sección sobre el uso del Lenguaje de Modelado Unificado (UML). Hay una nueva explicación sobre el modelo de casos de uso, la creación de diagramas de modelo de clases con UML, la creación de diagramas de generalización/especialización, escenarios de casos de uso y diagramas de actividades. Este capítulo demuestra, mediante diversos ejemplos y secciones Oportunidades de consultoría, cómo utilizar un enfoque orientado a objetos. Nuevas Oportunidades de consultoría, diagramas y problemas hacen posible que los estudiantes aprendan y utilicen UML para modelar sistemas desde una perspectiva orientada a objetos. La sexta edición contiene un Glosario de términos y una lista independiente de Siglas que se utilizan en el libro y en el campo del análisis y diseño de sistemas. >

>

Arreglar residencia estudiantil

Estudiante

Relación incluye

Relación comunica

Seguro médico del estudiante

Estudiante de tiempo parcial

>

Estudiante elige tipo de cobertura

Pago de cuotas del estudiante

Estudiante

Relación extiende

Relación generaliza

CARACTERÍSTICAS PEDAGÓGICAS Los capítulos de la sexta edición contienen:

• Objetivos de aprendizaje al principio de cada capítulo. • Resúmenes que enlazan los puntos notables de cada capítulo, al mismo tiempo que ofrecen una excelente fuente de revisión para los exámenes. • Palabras y frases clave. • Preguntas de repaso. • Problemas. • Proyectos de grupo que ayudan a los estudiantes a trabajar en conjunto en un equipo de sistemas, con el propósito de solucionar problemas importantes que se resuelven mejor a través de la interacción en grupo. • Oportunidades de consultoría —más de 65 minicasos a lo largo de todo el libro. • Experiencias con HyperCase. • Episodios de los casos de la CPU —partes de un caso continuo eslabonado a lo largo de todo el libro.

OPORTUNIDADES DE CONSULTORÍA La sexta edición contiene más de 65 Oportunidades de consultoría, muchas de las cuales abordan nuevos temas que han surgido en el campo, como el diseño de aplicaciones de comercio electrónico para la Web, el software comercial (COTS) y el uso de UML para modelar sistemas de información desde una perspectiva orientada a objetos. Las Oportunidades de LO APRETADO NO ES AGRADABLE consultoría se pueden aprovechar para propiciar debates en clase, asignarlas como tareas o como preguntas de examen para resolver en casa. Puesto que no todos los sistemas son proyectos que duran de dos a tres años, nuestro libro contiene muchas Oportunidades de consultoría que se pueden solucionar rápidamente en 20 o 30 minutos de debate en grupo o de manera individual. Estos minicasos, escritos de una manera humorística para hacer ameno el material, requieren que el estudiante sintetice lo que haya aprendido hasta ese punto del curso, que madure en lo concerniente a sus criterios éticos y profesionales, y que explique las razones que lo condujeron a tomar sus decisiones de sistemas. OPORTUNIDAD DE CONSULTORÍA 12.2

El departamento de audiología del gran hospital de veteranos está usando una PC y un monitor para que los técnicos de audiología puedan teclear los datos directamente en el sistema de registros del paciente. Después de hablar con Earl Lobes, uno de los técnicos, usted determina que el diseño de pantallas es el principal problema. “Usamos un formulario una vez, y eso era decente”, dijo el señor Lobes. “Sin embargo, la pantalla no tiene sentido. Supongo que tuvieron que meter todo ahí, y eso la estropeó”.

Le han pedido que rediseñe la pantalla (vea la figura 12.C2) para capturar la misma información pero de manera simplificada, y de esta manera reducirá los errores que han mortificado a los técnicos. Observe que lo apretado no es el único problema de la pantalla. Explique sus razones para cambiar la pantalla de la manera en que lo haya hecho. Podría usar más de una página para la pantalla si cree que es necesario.

REPORTE DE EXAMEN AUDIOLÓGICO

Apellido del paciente Nombre Fecha del examen Estación de examen Número de paciente Número del Seguro Social Primer examen Número de reporte

Inicial

CONDUCCIÓN DE AIRE

500

Oído derecho 1000 2000 4000

Oído izquierdo 1000 2000 4000

6000

500

CONDUCCIÓN DE HUESO Oído derecho Oído izquierdo 1000 2000 4000 6000 500 1000 2000 4000

6000

6000

500

SECCIÓN DE AUDIOMETRÍA DEL HABLA LÍMITE DE PERCEPCIÓN DEL HABLA Oído derecho [ ] Oído izquierdo [ ] DISCRIMINACIÓN DEL OÍDO DERECHO % [ ] Bloqueo [ ] DISCRIMINACIÓN DEL OÍDO IZQUIERDO % [ ] Bloqueo [ ]

Comentarios [

Remitido por [ Razón de la remisión Audiólogo que examinó Próxima cita

FIGURA 12.C2

Esta pantalla se puede diseñar para ser más amigable con el usuario.

xxii

PREFACIO

]

EXPERIENCIAS CON HYPERCASE En cada capítulo hay Experiencias con HyperCase, las cuales plantean ejercicios que constituyen un reto para los estudiantes. HyperCase 2.5 se encuentra ahora disponible en la Web. HyperCase contiene ahora problemas organizacionales 3 actualizados que representan sistemas tecnológicos de vanguardia. HyperCase es una oganización virtual que da a los estudiantes la oportunidad de adentrarse de inmediato en la vida organizacional. Los estudiantes entrevistarán gente, observarán entornos de oficina, analizarán sus prototipos y revisarán la documentación de sus sistemas existentes. HyperCase 2.5 es un software interactivo basado en la Web que presenta una organización denominada Maple Ridge Engineering (MRE) en un entorno de gráficos tridimensionales a todo color. HyperCase da a los profesores la posibilidad de plantear el análisis de sistemas y la clase de diseño con material multimedia interesante. Vigilando con atención el uso del tiempo y manejando múltiples métodos, los estudiantes aprovechan las características de hipertexto de HyperCase en la Web para crear sus propias rutas individuales dentro de la organización. Maple Ridge Engineering es resultado directo de las experiencias reales de consultoría de los autores de la versión original (Raymond Barnes, Richard Baskerville, Julie E. Kendall y Kenneth E. Kendall). Allen Schmidt se integró al proyecto en la versión 2.0. Peter Schmidt fue el programador de HTML y Jason Reed produjo las imágenes para la versión de la Web. En cada capítulo hay Experiencias con HyperCase especiales que incluyen tareas (al igual que algunas pistas) para ayudar a los estudiantes a resolver los difíciles problemas organizacionales que enfrentarán en MRE. HyperCase se ha probado totalmente en los salones de clase y obtuvo un premio en el certamen Decision Sciences Institute Innovative. EXPERIENCIA CON HYPERCASE®

“Espero que todas las personas que haya encontrado en MRE le hayan dado un buen trato. A continuación doy un breve repaso a algunas de las opciones que tiene para acceder a nuestra organización a través de HyperCase. En la recepción de MRE se encuentran los vínculos clave al resto de nuestra organización. Tal vez ya los haya descubierto por sí mismo, pero deseo describírselos en este momento, porque no quisiera concentrarme demasiado en el resto de los problemas de nuestra organización y olvidar mencionarlos más tarde.” “El teléfono en el escritorio de la recepcionista tiene instrucciones relacionadas con la forma de contestarlo en el resto de la organización. Usted cuenta con mi autorización para responder el teléfono si éste suena y nadie más lo contesta.” “La entrada sin puerta que ve, es un vínculo a la siguiente habitación, que nosotros llamamos el Atrio Oriental (East Atrium). Tal vez se haya percatado de que todas las entradas sin puerta son vínculos hacia habitaciones contiguas. Observe el mapa del edificio en una de las paredes de la recepción. Usted puede pasear libremente por las áreas públicas como la taberna, pero como sabe, algún empleado debe acompañarlo para entrar en una oficina privada. No puede entrar solo ahí.” “Tal vez ya haya visto los dos documentos y la computadora en la pequeña mesa de la recepción. El pequeño es el directorio telefónico interno de MRE. Tan sólo haga clic en el nombre de un empleado, y si éste se encuentra disponible, le concederá una entrevista y le dará un paseo por la oficina. Dejo a su iniciativa averiguar de qué trata el otro documento.” “La computadora en la mesa está encendida y muestra la página Web inicial de MRE. Debería usted dar un vistazo a la página corporativa y visitar todos los vínculos. Esta página contiene la historia de nuestra compañía y de la gente que labora aquí. Estamos muy orgullosos de ella y hemos tenido retroalimentación positiva sobre ella de nuestros visitantes.”

FIGURA 3.HC1

La recepción se parece a la de cualquier corporación típica. Mientras usted esté en esta pantalla de HyperCase, consulte el directorio si desea visitar a alguien.

(continúa)

EPISODIOS DE LOS CASOS DE LA CPU Acordes con nuestra creencia de que es importante contar con una diversidad de enfoques, nuevamente hemos integrado el caso de la Central Pacific University (CPU) en cada uno de los capítulos de esta sexta edición. En las pantallas de ejemplo y los ejercicios de los estudiantes, el caso de la CPU utiliza la popular herramienta CASE Visible Analyst, de Visible SysCASO DE LA CPU EPISODIO tems, Inc. El caso de la CPU lleva a los estudiantes por to9 TABLAS DE DECISIÓN das las fases del ciclo de vida del desarrollo de sistemas, demostrando las capacidades de Visible Analyst. Esta herramienta CASE permite a los estudiantes resolver problemas por sí mismos, utilizando datos que pueden descargar del sitio Web con ejercicios de Visible Analyst especialmente diseñados para cada capítulo del libro. Además, en el sitio Web se encuentran archivos de Microsoft Access parcialmente terminados para que los utilice el estudiante. El caso de la CPU ha sido completamente probado en los salones por una gran cantidad de estudiantes, durante numerosos periodos. El caso es suficientemente ALLEN SCHMIDT, JULIE E. KENDALL

Y

KENNETH E. KENDALL

Después de realizar muchas entrevistas de seguimiento con Dot Matricks, Anna le dice a Chip, “he determinado la lógica necesaria para actualizar el almacén de datos PENDING COMPUTER ORDERS. Debido a que se podrían pedir muchas computadoras en la misma orden de compra, cada vez que se introduce una computadora se localiza el registro correspondiente y se resta uno al número de computadoras pendientes en la orden de compra”. Anna muestra a Chip la impresión de la pantalla del depósito Process (descrita en al figura E9.1). “El nombre del proceso correspondiente, UPDATE PENDING COMPUTER ORDER (proceso 2.5), vincula la especificación de proceso con el diagrama de flujo de datos”, explica ella. Las entradas y salidas se listan y deben coincidir con el flujo de datos de entrada o salida del proceso. “El registro VALID COMPUTER TRANSACTION es el flujo de entrada, y el flujo de salida es el PENDING ORDER actualizado.”

FIGURA E9.1

Pantalla Process Repository, UPDATE PENDING COMPUTER ORDER.

PREFACIO

xxiii

detallado, riguroso y rico para funcionar como un proyecto independiente de análisis y diseño de sistemas con una duración de uno o dos periodos. De manera alternativa, el caso de la CPU se puede aprovechar para enseñar el uso de herramientas CASE en conjunto con la asignación de un proyecto real, de uno o dos periodos, fuera del salón de clases.

APOYOS ADICIONALES EN LA WEB La sexta edición de Análisis y diseño de sistemas, de Kendall y Kendall, incorpora apoyo adicional en la Web a las técnicas pedagógicas en el campo de los sistemas de información. Cabe aclarar que toda esta información está en idioma inglés.

• El sitio Web de este libro (www.pearsoneducación.net/kendall) contiene numerosas herramientas de apoyo y aprendizaje, que animan las discusiones en clase. • HyperCase 2.5, un galardonado juego sobre una organización virtual interactiva. Los estudiantes podrán entrevistar a miembros de la organización, analizar problemas, modificar diagramas de flujo de datos y diccionarios de datos, responder a prototipos y diseñar nuevas formas de entrada y salida. HyperCase cuenta ahora con una apariencia tridimensional. • Ejercicios para el estudiante basados en el caso continuo de la CPU, con problemas y ejemplos parcialmente resueltos en archivos de Visible Analyst y Microsoft Access, con el fin de que los alumnos puedan desarrollar un sistema de administración basado en la Web. • Guía de estudio interactiva, con preguntas cierto o falso y de opción múltiple para cada capítulo. Los estudiantes reciben una calificación automática y ayuda para contestar cada cuestionario. • Manual del profesor (en una sección segura para profesores) con respuestas a problemas, soluciones a los casos y sugerencias para impartir la materia. • Un paquete completo de diapositivas de PowerPoint que se pueden emplear en conferencias y que incluyen todas las figuras técnicas de la sexta edición. • Muestras de esquemas de cursos para cursos de uno o dos semestres o trimestres. • Soluciones a ejercicios para los estudiantes basados en el caso continuo de la CPU, con soluciones y ejemplos en archivos de Visible Analyst y Microsoft Access. • La Guía de la Corporación para los Usuarios de HyperCase, una guía del profesor para interpretar el HyperCase y enfoques sugeridos para utilizar en el salón de clases.

MATERIAL DE APOYO EN LA WEB PARA EL PROFESOR (EN INGLÉS) En el sitio Web de este libro se encontrará una mayor cantidad de material de apoyo para los profesores que utilicen esta edición. Entre los recursos se cuentan:

• • • • •

Un paquete completo de diapositivas de PowerPoint para utilizarse en conferencias. Biblioteca de imágenes, una colección de imágenes organizadas por capítulo. Manual del profesor en Microsoft Word. Archivo de pruebas en Microsoft Word. Windows PH Test Manager, un completo paquete de herramientas para probar y evaluar que permite a los profesores crear y distribuir pruebas con suma facilidad. • Soluciones a los ejercicios para el estudiante basados en el caso continuo de la CPU, con soluciones y ejemplos en archivos de Visible Analyst y Microsoft Access.

xxiv

PREFACIO

AGRADECIMIENTOS

Cuando comenzamos a escribir la sexta edición de Análisis y diseño de sistemas observamos un mayor énfasis en la calidad de la información y en los sistemas de información, así como un creciente interés por el uso de la tecnología de la información y nuevos sistemas para mejorar la productividad y la calidad de vida de los individuos, al igual que la calidad de las sociedades establecidas y las emergentes. Mucha gente de todas partes del mundo se especializa en el diseño de sistemas, y aún más gente se ve en la necesidad de utilizar avanzados sistemas e información basados en la Web. Los usuarios responden a los sistemas de información y participan en el desarrollo de los mismos. Los buenos analistas y diseñadores de sistemas aprovechan tanto el arte como la ciencia al dar respuesta a la retroalimentación que reciben, con el fin de desarrollar sistemas adecuados para sus usuarios, sus entornos e incluso la sociedad. El artista que creó la ilustración de nuestra portada, Douglas G. Hamilton, comentó lo siguiente acerca de su pintura, Sydney II (que vimos por primera vez en un maravilloso sitio Web llamado ArtQuest): “Aunque con frecuencia hay diseños premeditados, colores sencillos o límites difíciles, en todo subyace en gran medida el azar. Con frecuencia, las cosas más interesantes ocurren de manera casual cuando nos aventuramos a ir más allá de lo establecido, experimentando y combinando con la aleatoriedad de otros”. Creemos que usted estará de acuerdo en que la creación de una pintura es similar a lo que ocurre al crear nuevos sistemas de información. Usted tiene que aprender y aplicar una gran cantidad de técnicas, métodos, herramientas y enfoques estructurados. Pero cuando llega el momento de interpretar lo que acontece en la organización y de desarrollar sistemas de información significativos desde la aplicación de reglas hasta el análisis, su capacidad se combina con su creatividad para producir un sistema que en cierta forma constituye una sorpresa: de múltiples capas y complejo, de acuerdo con las particularidades de la organización, y que refleja la individualidad de usted como analista de sistemas. Como ocurre con cualquier nueva edición, nuestros estudiantes merecen reconocimiento por habernos ayudado a mejorar de manera continua este libro al compartir con nosotros sus ideas y comentarios. Apreciamos su disposición para enseñarnos nuevas cosas. Deseamos agradecer a Allen Schmidt, coautor, todo el talento, dedicación y humorismo que puso en sus colaboraciones. Es una persona sin igual. También damos un profundo reconocimiento a Peter Schmidt y Jason Reed por sus contribuciones al HyperCase. Asimismo, agradecemos a Richard Baskerville y Raymond Barnes, los otros dos autores originales del HyperCase, por su valiosa aportación. Deseamos hacer patente nuestro agradecimiento a Bob Horan, nuestro editor, quien nos impulsó a hacer de ésta una edición dinámica y sustancial. Kyle Hannon también nos ayudó a realizar una revisión a fondo. Sharon Koch merece nuestro agradecimiento por haber aplicado sus conocimientos de marketing en nuestro texto. Su percepción, visión y capacidad favorecieron que este proyecto cumpliera nuestros objetivos compartidos. Maggie Nickles y Stacey Corbin, nuestros editores de producción en ICC, también merecen muchos elogios por habernos ayudado en la difícil tarea de establecer prioridades y apegarnos a ellas. Gracias a ellos, esta edición fluyó sin problemas. Por último, hubo mucha gente que no conocimos personalmente, pero con la que trabajamos en equipos virtuales en Prentice Hall, como Suzanne Grappi, e incluso otros miembros de ICC y de otras áreas, que nos ayudaron a administrar el proyecto, diseñar el libro, dibujar las ilustraciones, diagramar las páginas y conseguir los permisos correspondientes. Damos las gracias a todos ellos.

xxv

Muchos revisores, compañeros y amigos nos animaron durante el proceso de redacción de este libro. Les damos las gracias por sus comentarios a nuestro trabajo. Entre ellos están: Ayman Abu Hamdieh; Jim y Jan Buffington; Chaomei Chen; Charles J. Coleman; Gordon Davis; Dorothy Dologite; Jim Evans; Bruce Fanning; Paul Gray; Nancy V. Gulick; Andy y Pam Hamingson; Chung Kwong Han; Carolyn Harris; Gail S. Huck; Ken y Nancy Kopecky; Art y Joan Kraft; Lee y Judie Krajewski; Muhammadou y Jainaba Kah; Kathy Kahre-Samuels; Carol Latta; Ken y Jane Laudon; Clifford D. Layton; Bob Mankoff; Sylnovie Merchant; Merrideth Miller; Robert Mockler; Nancy Omaha Boy; Raymond E. Podhorn; Joel y Bobbie Porter; Markita Price; Ron Rice; Bill Rogers; Caryn Schmidt; Marc y Jill Schniederjans; Keng Siau; Jeffery L. Squibb; Eric y Tisha Stahl; Merrill Warkentin; Shaker y Patricia Zahra, y todos nuestros amigos y compañeros en la Association for Information Systems, el Decision Sciences Institute, el IFIP Working Group 8.2, y todos los que participan en el KPMG Ph.D. Project. Gracias de todo corazón a Julia A. Kendall y a la memoria de Edward J. Kendall. Su firme convicción de que el amor, las metas y el trabajo constante constituyen una combinación inigualable continúa impulsando nuestros esfuerzos cotidianos.

xxvi

AGRADECIMIENTOS

EL ROL DEL ANALISTA DE SISTEMAS

1

OBJETIVOS DE APRENDIZAJE Una vez que haya dominado el material de este capítulo, podrá: 1. Recordar los tipos básicos de sistemas de cómputo con los que debe trabajar un analista de sistemas. 2. Entender la manera en que las nuevas tecnologías influyen en la dinámica de un sistema. 3. Reconocer los diversos roles de un analista de sistemas. 4. Conocer los pasos del SDLC y saber cómo aplicarlos a un sistema real. 5. Comprender la función de las herramientas CASE y cómo ayudan a un analista de sistemas. 6. Explorar otras metodologías como el diseño de sistemas orientados a objetos y la elaboración de prototipos.

Desde hace mucho tiempo, las organizaciones han reconocido la importancia de administrar recursos clave como la mano de obra y las materias primas. En la actualidad, la información se ha ganado el legítimo derecho de ser considerada como un recurso clave. Los encargados de la toma de decisiones por fin han comprendido que la información no es tan sólo un producto derivado de la conducción de los negocios, sino un impulsor de los mismos y que puede constituir un factor crucial en el éxito o fracaso de una empresa. Para maximizar la utilidad de la información, una empresa debe administrarla de manera eficiente, como lo hace con los demás recursos. Los administradores deben comprender que los costos tienen una estrecha relación con la producción, distribución, seguridad, almacenamiento y recuperación de toda la información. A pesar de que la información está en todas partes, no es gratuita, y no se debe asumir que se podrá usar estratégicamente para aumentar la competitividad de una empresa. La amplia disponibilidad de computadoras en red, junto con el acceso a Internet y la World Wide Web, han propiciado una explosión de la información en la sociedad en general y en los negocios en particular. La administración de la información generada por computadora difiere en aspectos importantes del manejo de los datos producidos por medios manuales. Por lo general hay una mayor cantidad de información de computadora por manejar. Los costos de organizarla y darle mantenimiento se pueden incrementar a niveles alarmantes, y con frecuencia los usuarios la consideran más precisa que la información obtenida por otros medios. En este capítulo se examinan los aspectos básicos de los diferentes tipos de sistemas de información, los diversos roles de los analistas de sistemas, las fases del ciclo de vida del desarrollo de sistemas (SDLC, Systems Development Life Cycle) y se presentan las herramientas de Ingeniería de Software Asistida por Computadora (CASE, ComputerAided Software Engineering).

1

TIPOS DE SISTEMAS Los sistemas de información se desarrollan con diversos propósitos, según las necesidades de la empresa. Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) funcionan al nivel operativo de una organización, los sistemas de automatización de la oficina (OAS, Office Automation Systems) y los sistemas de trabajo del conocimiento (KWS, Knowledge Work Systems) apoyan el trabajo al nivel del conocimiento. Los sistemas de información gerencial (MIS, Management Information Systems) y los sistemas de apoyo a la toma de decisiones (DSS, Decision Support Systems) se encuentran entre los sistemas de alto nivel. Los sistemas expertos aplican el conocimiento de los encargados de la toma de decisiones para solucionar problemas estructurados específicos. Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) se encuentran en el nivel estratégico de la administración. Los sistemas de apoyo a la toma de decisiones en grupo (GDSS, Group Decision Support Systems) y los sistemas de trabajo corporativo apoyados por computadora (CSCWS, Computer-Supported Collaborative Work Systems), descritos de manera más general, auxilian la toma de decisiones semiestructuradas o no estructuradas a nivel de grupo. En la figura 1.1 se muestra la diversidad de sistemas de información que podrían desarrollar los analistas. Observe que en la figura estos sistemas se representan de abajo hacia arriba, indicando que los TPS apoyan el nivel operativo, o más bajo, de la organización, mientras que los ESS, GDSS y CSCWS soportan el nivel estratégico, o más alto, apoyando la toma de decisiones semiestructuradas o las no estructuradas. En este libro se emplean de manera indistinta los términos sistemas de información gerencial, sistemas de información (IS, Information Systems), sistemas de información computarizados y sistemas de información de negocios computarizados, para denotar sistemas de información computarizados que apoyan el rango de actividades de negocios más amplio mediante la información que producen.

SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) son sistemas de información computarizada creados para procesar grandes cantidades de datos relacionadas con transacciones rutinarias de negocios, como las nóminas y los inventarios. Un TPS elimina el fastidio que representa la realización de transacciones operativas necesarias y reduce el tiempo que una vez fue requerido para llevarlas a cabo de manera manual, aunque los usuarios aún tienen que capturar datos en los sistemas computarizados. Los sistemas de procesamiento de transacciones expanden los límites de la organización dado que le permiten interactuar con entornos externos. Es importante para las operaciones cotidianas de un negocio, que estos sistemas funcionen sin ningún tipo de interrupción, puesto

FIGURA 1.1 Un analista de sistemas podría trabajar con alguno de estos sistemas o con todos ellos.

ESS GDSS CSCWS

Sistemas expertos Sistemas de apoyo a la toma de decisiones Sistemas de información gerencial

Sistemas de trabajo del conocimiento Sistemas de automatización de la oficina

Sistemas de procesamiento de transacciones

2

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

que los administradores recurren a los datos producidos por los TPS con el propósito de obtener información actualizada sobre el funcionamiento de sus empresas.

SISTEMAS DE AUTOMATIZACIÓN DE LA OFICINA Y SISTEMAS DE TRABAJO DEL CONOCIMIENTO Existen dos clases de sistemas en el nivel del conocimiento de una organización. Los sistemas de automatización de la oficina (OAS, Office Automation Systems) apoyan a los trabajadores de datos, quienes por lo general no generan conocimientos nuevos, sino más bien analizan la información con el propósito de transformar los datos o manipularlos de alguna manera antes de compartirlos o, en su caso, distribuirlos formalmente con el resto de la organización y en ocasiones más allá de ésta. Entre los componentes más comunes de un OAS están el procesamiento de texto, las hojas de cálculo, la autoedición, la calendarización electrónica y las comunicaciones mediante correo de voz, correo electrónico y videoconferencia. Los sistemas de trabajo del conocimiento (KWS, Knowledge Work Systems) sirven de apoyo a los trabajadores profesionales, como los científicos, ingenieros y médicos, en sus esfuerzos de creación de nuevo conocimiento y dan a éstos la posibilidad de compartirlo con sus organizaciones o con la sociedad.

SISTEMAS DE INFORMACIÓN GERENCIAL Los sistemas de información gerencial (MIS, Management Information Systems) no reemplazan a los sistemas de procesamiento de transacciones, más bien, incluyen el procesamiento de transacciones. Los MIS son sistemas de información computarizados cuyo propósito es contribuir a la correcta interacción entre los usuarios y las computadoras. Debido a que requieren que los usuarios, el software (los programas de cómputo) y el hardware (las computadoras, impresoras, etc.), funcionen de manera coordinada, los sistemas de información gerencial dan apoyo a un espectro de tareas organizacionales mucho más amplio que los sistemas de procesamiento de transacciones, como el análisis y la toma de decisiones. Para acceder a la información, los usuarios de un sistema de información gerencial comparten una base de datos común. Ésta almacena datos y modelos que ayudan al usuario a interpretar y aplicar los datos. Los sistemas de información gerencial producen información que se emplea en la toma de decisiones. Un sistema de información gerencial también puede contribuir a unificar algunas de las funciones de información computarizadas de una empresa, a pesar de que no existe como una estructura individual en ninguna parte de ésta.

SISTEMAS DE APOYO A LA TOMA DE DECISIONES Los sistemas de apoyo a la toma de decisiones (DSS, Decision Support Systems) constituyen una clase de alto nivel de sistemas de información computarizada. Los DSS coinciden con los sistemas de información gerencial en que ambos dependen de una base de datos para abastecerse de datos. Sin embargo, difieren en que el DSS pone énfasis en el apoyo a la toma de decisiones en todas sus fases, aunque la decisión definitiva es responsabilidad exclusiva del encargado de tomarla. Los sistemas de apoyo a la toma de decisiones se ajustan más al gusto de la persona o grupo que los utiliza que a los sistemas de información gerencial tradicionales. En ocasiones se hace referencia a ellos como sistemas que se enfocan en la inteligencia de negocios.

SISTEMAS EXPERTOS E INTELIGENCIA ARTIFICIAL La inteligencia artificial (AI, Artificial Intelligence) se puede considerar como el campo general para los sistemas expertos. La motivación principal de la AI ha sido desarrollar máquinas que tengan un comportamiento inteligente. Dos de las líneas de investigación de la AI son la comprensión del lenguaje natural y el análisis de la capacidad para razonar un problema hasta su conclusión lógica. Los sistemas expertos utilizan las técnicas de razonamiento de la AI para solucionar los problemas que les plantean los usuarios de negocios (y de otras áreas). Los sistemas expertos conforman una clase muy especial de sistema de información que se ha puesto a disposición de usuarios de negocios gracias a la amplia disponibilidad de EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

3

hardware y software como computadoras personales (PCs) y generadores de sistemas expertos. Un sistema experto (también conocido como sistema basado en el conocimiento) captura y utiliza el conocimiento de un experto para solucionar un problema específico en una organización. Observe que a diferencia de un DSS, que cede al responsable la toma de la decisión definitiva, un sistema experto selecciona la mejor solución para un problema o una clase específica de problemas. Los componentes básicos de un sistema experto son la base de conocimientos, un motor de inferencia que conecta al usuario con el sistema mediante el procesamiento de consultas realizadas con lenguajes como SQL (Structured Query Language, lenguaje de consultas estructurado) y la interfaz de usuario. Profesionales conocidos como ingenieros de conocimiento capturan la pericia de los expertos, construyen un sistema de cómputo que contiene este conocimiento experto y lo implementan. Es muy factible que la construcción e implementación de sistemas expertos se constituya en el trabajo futuro de muchos analistas de sistemas.

SISTEMAS DE APOYO A LA TOMA DE DECISIONES EN GRUPO Y SISTEMAS DE TRABAJO COLABORATIVO APOYADOS POR COMPUTADORA Cuando los grupos requieren trabajar en conjunto para tomar decisiones semiestructuradas o no estructuradas, un sistema de apoyo a la toma de decisiones en grupo (GDSS, Group Decision Support System) podría ser la solución. Este tipo de sistemas, que se utilizan en salones especiales equipados con diversas configuraciones, faculta a los miembros del grupo a interactuar con apoyo electrónico —casi siempre software especializado— y la asistencia de un facilitador especial. Los sistemas de apoyo a la toma de decisiones en grupo tienen el propósito de unir a un grupo en la búsqueda de la solución a un problema con la ayuda de diversas herramientas como los sondeos, los cuestionarios, la lluvia de ideas y la creación de escenarios. El software GDSS puede diseñarse con el fin de minimizar las conductas negativas de grupo comunes, como la falta de participación originada por el miedo a las represalias si se expresa un punto de vista impopular o contrario, el control por parte de miembros elocuentes del grupo y la toma de decisiones conformista. En ocasiones se hace referencia a los GDSS con el término más general sistemas de trabajo colaborativo apoyados por computadora (CSCWS, Computer-Supported Collaborative Work Systems), que pueden contener el respaldo de un tipo de software denominado groupware para la colaboración en equipo a través de computadoras conectadas en red.

SISTEMAS DE APOYO A EJECUTIVOS Cuando los ejecutivos recurren a la computadora, por lo general lo hacen en busca de métodos que los auxilien en la toma de decisiones de nivel estratégico. Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) ayudan a estos últimos a organizar sus actividades relacionadas con el entorno externo mediante herramientas gráficas y de comunicaciones, que por lo general se encuentran en salas de juntas o en oficinas corporativas personales. A pesar de que los ESS dependen de la información producida por los TPS y los MIS, ayudan a los usuarios a resolver problemas de toma de decisiones no estructuradas, que no tienen una aplicación específica, mediante la creación de un entorno que contribuye a pensar en problemas estratégicos de una manera bien informada. Los ESS amplían y apoyan las capacidades de los ejecutivos al darles la posibilidad de comprender sus entornos.

INTEGRACIÓN DE LAS TECNOLOGÍAS DE SISTEMAS Como se aprecia en la figura 1.2, a medida que se adopten y difundan las nuevas tecnologías, parte del trabajo de los analistas de sistemas se dedicará a la integración de los sistemas tradicionales con los nuevos. En esta sección se describen algunas de las nuevas tecnologías de información que los analistas de sistemas utilizarán para empresas que buscan integrar sus aplicaciones de comercio electrónico con sus negocios tradicionales, o bien, iniciar negocios electrónicos completamente nuevos.

4

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

FIGURA 1.2 Los analistas de sistemas deben estar conscientes de que la integración de tecnologías abarca todos los tipos de sistemas.

ESS GDSS

s rico mb á l na

CSCWS

e S is t

ma

si

Sistemas expertos Sistemas de apoyo a la toma de decisiones Sistemas de información gerencial

S

m is t e

as

E RP

Sistemas de trabajo del conocimiento Sistemas de automatización de la oficina

Sistemas de procesamiento de transacciones

Si st

em

eb as W

yd

e

co m

erc

io

APLICACIONES DE COMERCIO ELECTRÓNICO Y SISTEMAS WEB Muchos de los sistemas que se describen en este libro pueden dotarse de una mayor funcionalidad si se migran a la World Wide Web o si desde su concepción se implementan como tecnologías basadas en la Web. En una encuesta reciente la mitad de todas las empresas pequeñas y medianas respondieron que Internet fue su estrategia preferida para buscar el crecimiento de sus negocios. Esta respuesta duplicó a la de aquellos que manifestaron su inclinación por realizar alianzas estratégicas como medio para crecer. Hay muchos beneficios derivados de la implementación de una aplicación en la Web: 1. Una creciente difusión de la disponibilidad de un servicio, producto, industria, persona o grupo. 2. La posibilidad de que los usuarios accedan las 24 horas. 3. La estandarización del diseño de la interfaz. 4. La creación de un sistema que se puede extender a nivel mundial y llegar a gente en lugares remotos sin preocuparse por la zona horaria en que se encuentren.

SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES Muchas organizaciones consideran los beneficios potenciales que se derivan de la integración de los diversos sistemas de información que existen en los diferentes niveles administrativos, con funciones dispares. Esta integración es precisamente el propósito de los sistemas de planeación de recursos empresariales (ERP, Enterprise Resource Planning). El establecimiento de los sistemas ERP implica un enorme compromiso y cambio por parte de la organización. Es común que los analistas de sistemas desempeñen el papel de asesores en los proyectos de ERP que utilizan software patentado. Entre el software más conocido de ERP se encuentran SAP, PeopleSoft y paquetes de Oracle y J.D. Edwards. Algunos de estos paquetes están diseñados para migrar a las empresas a la Web. Por lo general, los analistas y algunos usuarios requieren capacitación, apoyo técnico y mantenimiento por parte del fabricante para diseñar, instalar, dar mantenimiento, actualizar y utilizar de manera apropiada un paquete de ERP en particular.

SISTEMAS PARA DISPOSITIVOS INALÁMBRICOS Y PORTÁTILES Los analistas tienen la exigencia de diseñar una gran cantidad de nuevos sistemas y aplicaciones, muchos de ellos para dispositivos inalámbricos y computadoras portátiles como la EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

5

popular serie de computadoras Palm y otros asistentes personales digitales (PDAs, Personal Digital Assistants). Además, los analistas podrían llegar a diseñar redes de comunicaciones estándar o inalámbricas que integren voz, vídeo y correo electrónico en intranets para una organización o extranets para la industria. El comercio electrónico inalámbrico se conoce como comercio móvil o m-commerce. Las redes inalámbricas de área local (WLANs, Wireless Local Area Networks), las redes de fidelidad inalámbrica, conocidas como WI-FI, y las redes inalámbricas personales que agrupan a muchos tipos de dispositivos dentro del estándar conocido como Bluetooth, constituyen sistemas cuyo diseño podrían solicitarle a usted en su función de analista. (Para ahondar en las redes inalámbricas, véase el capítulo 17.) En un contexto más avanzado, al analista podría solicitársele el diseño de agentes inteligentes, software que puede ayudar a los usuarios a ejecutar tareas mediante el aprendizaje de las preferencias del usuario a través del tiempo y, a continuación, realizando alguna acción sobre éstas. Por ejemplo, en la tecnología de recepción automática, un agente inteligente podría buscar temas de interés para el usuario en la Web, sin necesidad de que éste lo solicite, después de observar durante algún tiempo los patrones de comportamiento del usuario en relación con la información. Un ejemplo de este tipo de software es el que desarrolla Microsoft con base en la estadística bayesiana (donde se utilizan estadísticas para inferir probabilidades) y la teoría de la toma de decisiones, en conjunto con el monitoreo del comportamiento de un usuario que maneja información entrante (como un mensaje de su casa, una llamada telefónica de un cliente, una llamada de celular o el análisis actualizado de su cartera de acciones). El resultado es software de manejo de notificaciones que da un valor monetario a cada pieza de información proveniente de diversas fuentes y también determina la mejor manera de desplegarla. Por ejemplo, con base en la teoría de la toma de decisiones, la probabilidad, la estadística y el propio comportamiento del usuario, a una llamada telefónica proveniente de la casa del usuario se le podría dar el valor de un peso y se desplegaría en la pantalla de la computadora, en tanto que a una llamada cuyo propósito es la venta de algún producto o servicio se le podría asignar el valor de 20 centavos (es decir, un valor inferior) y podría desplegarse como nota en un radiolocalizador.

SOFTWARE DE CÓDIGO ABIERTO El software de código abierto es una alternativa al desarrollo de software tradicional cuyo código patentado se oculta a los usuarios. Representa un modelo de desarrollo y filosofía de distribución de software gratuito y publicación de su código fuente. Bajo este esquema, el código (las instrucciones para la computadora) se puede estudiar y compartir, y muchos usuarios y programadores tienen la posibilidad de modificarlo. Las convenciones que rigen a esta comunidad incluyen que todas las modificaciones que se hagan a un programa deben compartirse con todos aquellos que participan en el proyecto. Entre los ejemplos se encuentran el sistema operativo Linux y el software Apache empleado en servidores que alojan sitios Web. Si el software es de distribución gratuita, ¿cómo ganan dinero las compañías? Para ello, tienen que proporcionar un servicio, personalizar programas para los usuarios y darles seguimiento con un soporte continuo. En un mundo de software de código abierto, el desarrollo de sistemas continuaría su evolución hacia una industria de servicios. Se apartaría del modelo de manufactura en el que los productos se licencian y empacan en cajas vistosas y se envían hasta nuestras puertas, al igual que cualquier otro producto manufacturado. El desarrollo de código abierto es útil para los dispositivos portátiles y el equipo de comunicaciones. Su uso podría estimular el progreso en la creación de estándares para que los dispositivos se comunicaran con más facilidad. El uso generalizado del software de código abierto podría solucionar problemas que pudiera causar la escasez de programadores y algunos problemas complejos podrían resolverse mediante la colaboración de muchos especialistas.

LA NECESIDAD DEL ANÁLISIS Y DISEÑO DE SISTEMAS El análisis y diseño de sistemas, tal como lo realizan los analistas de sistemas, tiene el propósito de analizar sistemáticamente la entrada o el flujo de datos, procesar o transformar da-

6

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

tos, el almacenamiento de datos y la salida de información en el contexto de una empresa en particular. Más aún, el análisis de sistemas se emplea para analizar, diseñar e implementar mejoras en el funcionamiento de las empresas, a través de sistemas de información computarizados. La instalación de un sistema sin una planeación adecuada conduce a una gran decepción y con frecuencia provoca que el sistema deje de utilizarse. El análisis y diseño de sistemas da forma al análisis y diseño de sistemas de información, un esfuerzo muy valioso que de otra manera podría haberse realizado de una manera fortuita. Se le puede considerar como una serie de procesos sistemáticamente emprendidos con el propósito de mejorar un negocio con ayuda de sistemas de información computarizados. Gran parte del análisis y diseño de sistemas implica trabajar con usuarios actuales y ocasionales de los sistemas de información. Es importante que los usuarios intervengan de alguna manera durante el proyecto para completar con éxito los sistemas de información computarizados. Los analistas de sistemas, cuyos roles en la organización se describen a continuación, constituyen el otro componente esencial en el desarrollo de sistemas de información útiles.

ROLES DEL ANALISTA DE SISTEMAS El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente producción de información, con el propósito de mejorar los procesos de una organización. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de sistemas de información computarizados. Esta definición pone énfasis en un enfoque sistemático y metódico para analizar —y en consecuencia mejorar— lo que sucede en el contexto específico creado por un negocio. Nuestra definición de analista de sistemas es amplia. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

7

OPORTUNIDAD DE CONSULTORÍA 1.1

CONTRATACIÓN SANA: SE SOLICITA AYUDA PARA COMERCIO ELECTRÓNICO “Estarán felices de enterarse que logramos convencer a la administración de que debemos contratar un nuevo analista de sistemas que se especialice en el desarrollo de comercio electrónico”, comentó Al Falfa, analista de sistemas de la cadena internacional de tiendas Marathon Vitamin Shops. Actualmente se reúne con su numeroso equipo de analista de sistemas para determinar las cualidades con que debe contar el nuevo miembro de su equipo. Al continúa: “De hecho, mostraron tanto interés por la posibilidad de que nuestro equipo colabore en la estrategia de comercio electrónico de Marathon que me indicaron que comencemos de inmediato nuestra búsqueda por el especialista y no esperemos hasta el otoño”. Ginger Rute, otra analista, muestra su aprobación: “Cuando la economía es saludable, la demanda de desarrolladores de sitios Web rebasa con mucho a la oferta. Debemos actuar con rapidez. Creo que el nuevo analista debe tener conocimientos en herramientas CASE, Visual Basic y JavaScript, por mencionar algunos”. Al se sorprende al escuchar la larga lista de lenguajes que enumera Ginger y replica: “Tienes razón, ésa es una de nuestras opciones. Sin embargo, también me gustaría que el nuevo miembro tuviera algo de experiencia en negocios. La mayoría de los egresados de las escuelas tienen sólidos conocimientos de programación, pero también deberían saber sobre contabilidad, inventarios y distribución de bienes y servicios”. La más nueva en el grupo de analistas de sistemas, Vita Minn, se incorpora al debate: “Una de las razones por las cuales me incliné a trabajar con todos ustedes fue porque considero que nos llevamos bastante bien unos con otros. Como tenía otras opciones, tuve cuidado de ver cómo era el ambiente aquí. Por lo que he visto, conformamos un grupo amistoso. Así que asegurémonos de contratar a alguien que cuente con una personalidad adecuada que se acople al equipo”. Al está de acuerdo y continúa: “Vita tiene razón. El nuevo analista debe ser alguien que se comunique bien con nosotros, lo mismo que con

los clientes de negocios. Siempre nos estamos comunicando de alguna manera, ya sea mediante presentaciones formales, dibujando diagramas o entrevistando a los usuarios. Si entienden por qué se toman las decisiones, su trabajo también se facilitará. Asimismo, Marathon tiene interés en integrar el comercio electrónico en toda la empresa. Requerimos alguien que comprenda al menos la importancia estratégica de la Web. El diseño de páginas es sólo una pequeña parte de esto”. Ginger interviene nuevamente con una buena dosis de sentido práctico: “Deja eso en manos de la administración. Sigo creyendo que la nueva persona debe ser un buen programador”. Luego reflexiona en voz alta: “¿Me pregunto qué tan importante será saber UML para el puesto?” Después de escuchar con paciencia los argumentos de todos, uno de los analistas veteranos, Cal Siem, interviene, bromeando: “¡Mejor deberíamos ver si Superman está disponible!” Mientras todos ríen, Al vislumbra la oportunidad de lograr el consenso y dice: “Hemos tenido la oportunidad de escuchar diferentes cualidades. Tomemos un momento y cada quien haga una lista de las cualidades que considere esenciales en la persona que se encargará del desarrollo del comercio electrónico. Las expondremos y continuaremos el debate hasta que definamos a la persona con suficiente detalle y podamos elaborar un perfil para que el departamento de recursos humanos le dé seguimiento”. ¿Qué cualidades debe buscar el equipo de analistas de sistemas al contratar al nuevo miembro del equipo de desarrollo de comercio electrónico? ¿Es más importante el conocimiento de lenguajes específicos o contar con habilidad para aprender con rapidez lenguajes y paquetes de software? ¿Qué tan importante es que la persona que se contrate tenga algunos conocimientos básicos de negocios? ¿Deberían todos los miembros del equipo contar con habilidades y conocimientos idénticos? ¿Qué rasgos personales y carácter debe tener un analista de sistemas que trabaje en el desarrollo de comercio electrónico?

analista desempeña diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres roles principales del analista de sistemas son el de consultor, experto en soporte técnico y agente de cambio.

EL ROL DE CONSULTOR DEL ANALISTA DE SISTEMAS Con frecuencia, el analista de sistemas desempeña el rol de consultor para un negocio y, por tanto, podría ser contratado de manera específica para enfrentar los problemas de sistemas de información de una empresa. Esta contratación se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual carecen los demás miembros de una organización. También se puede traducir en una desventaja porque alguien externo nunca conocerá la verdadera cultura organizacional. En su función de consultor externo, usted dependerá en gran medida de los métodos sistemáticos que se explican en este libro para analizar y diseñar sistemas de información apropiados para una empresa en particular. Además, tendrá que apoyarse en los usuarios de los sistemas de información para entender la cultura organizacional desde la perspectiva que tienen ellos.

EL ROL DE EXPERTO EN SOPORTE TÉCNICO DEL ANALISTA DE SISTEMAS Otro rol que tendrá que desempeñar es el de experto en soporte técnico dentro de la empresa en la cual labora de manera regular. En este rol el analista recurre a su experiencia

8

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

profesional con el hardware y software de cómputo y al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino más bien la realización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo departamento. Como experto de soporte técnico, usted no está a cargo del proyecto; tan sólo actúa como recurso para aquellos que sí lo están. Si usted es un analista de sistemas contratado por una empresa de manufactura o servicios, gran parte de sus actividades podrían ajustarse a este rol.

EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio, ya sea interno o externo para la empresa. Como analista, usted es un agente de cambio si desempeña cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas (que se explicará en la siguiente sección) y está presente en la empresa durante un largo periodo (de dos semanas a más de un año). Un agente de cambio se puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para el cambio y coopera con los demás para facilitar el cambio. Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar consciente de este hecho y utilizarlo como punto de partida para su análisis. De ahí que tenga que interactuar con los usuarios y la administración (si no son uno solo y el mismo) desde el principio de su proyecto. Sin su colaboración usted no podría entender lo que ocurre en una organización y el cambio real nunca se daría. Si el cambio (es decir, las mejoras al negocio que se pueden concretar mediante los sistemas de información) parece factible después de efectuar el análisis, el siguiente paso es desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de autorizarlo. Una vez que se haya alcanzado el consenso acerca de los cambios por realizar, usted tendrá que interactuar constantemente con quienes vayan a cambiar. En su calidad de analista de sistemas desempeñando la función de agente de cambio, debe promover un cambio que involucre el uso de los sistemas de información. También es parte de su tarea enseñar a los usuarios el proceso del cambio, ya que las modificaciones a un sistema de información no sólo afectan a éste sino que provocan cambios en el resto de la organización.

CUALIDADES DEL ANALISTA DE SISTEMAS De las descripciones anteriores sobre los roles que desempeña el analista de sistemas, se deduce fácilmente que el analista exitoso debe contar con una amplia gama de cualidades. Hay una gran diversidad de personas trabajando como analistas de sistemas, por lo que cualquier descripción que intente ser general está destinada a quedarse corta en algún sentido. No obstante, la mayoría de los analistas de sistemas tienen algunas cualidades comunes. En primer lugar, el analista es un solucionador de problemas. Es una persona que aborda como un reto el análisis de problemas y que disfruta al diseñar soluciones factibles. Cuando es necesario, el analista debe contar con la capacidad de afrontar sistemáticamente cualquier situación mediante la correcta aplicación de herramientas, técnicas y su experiencia. El analista también debe ser un comunicador con capacidad para relacionarse con los demás durante extensos periodos. Necesita suficiente experiencia en computación para programar, entender las capacidades de las computadoras, recabar los requisitos de información de los usuarios y comunicarlos a los programadores. Asimismo, debe tener una ética personal y profesional firme que le ayude a moldear las relaciones con sus clientes. El analista de sistemas debe ser una persona autodisciplinada y automotivada, con la capacidad de administrar y coordinar los innumerables recursos de un proyecto, incluyendo a otras personas. La profesión de analista de sistemas es muy exigente; pero es una profesión en constante evolución que siempre trae nuevos retos. EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

9

EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS A lo largo de este capítulo, nos hemos referido al enfoque sistemático que el analista toma en relación con el análisis y diseño de sistemas de información. Gran parte de este enfoque se incluye en el ciclo de vida del desarrollo de sistemas (SDLC, Systems Development Life Cycle). El SDLC es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo específico de actividades del analista y el usuario. Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el ciclo de vida del desarrollo de sistemas, pero en general alaban su enfoque organizado. Aquí hemos dividido el ciclo en siete fases, como se aprecia en la figura 1.3. A pesar de que cada fase se explica por separado, nunca se realiza como un paso aislado. Más bien, es posible que varias actividades ocurran de manera simultánea, y algunas de ellas podrían repetirse. Es más práctico considerar que el SDLC se realiza por fases (con actividades en pleno apogeo que se traslapan con otras hasta terminarse por completo) y no en pasos aislados.

IDENTIFICACIÓN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del resto del proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un problema que no era el que se debía resolver. La primera fase requiere que el analista observe objetivamente lo que sucede en un negocio. A continuación, en conjunto con otros miembros de la organización, el analista determina con precisión cuáles son los problemas. Con frecuencia los problemas son detectados por alguien más, y ésta es la razón de la llamada inicial al analista. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados. El aprovechamiento de las oportunidades podría permitir a la empresa obtener una ventaja competitiva o establecer un estándar para la industria. La identificación de objetivos también es una parte importante de la primera fase. En primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A continuación, podrá determinar si algunas funciones de las aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase consisten en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos. A continuación, la administración debe decidir si se sigue adelante con el proyecto propuesto. Si el

FIGURA 1.3

1 Identificación de problemas,

Las siete fases del ciclo de vida del desarrollo de sistemas.

oportunidades y objetivos

2 Determinación de los requerimientos de información

3 Análisis de las necesidades del sistema

7 Implementación y evaluación del sistema

4 Diseño del sistema recomendado

6 Pruebas y mantenimiento del sistema

10

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

5 Desarrollo y documentación del software

grupo de usuarios no cuenta con fondos suficientes, si desea atacar problemas distintos, o si la solución a estos problemas no amerita un sistema de cómputo, se podría sugerir una solución diferente y el proyecto de sistemas se cancelaría.

DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN La siguiente fase que enfrenta el analista es la determinación de los requerimientos de información de los usuarios. Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos de oficina, al igual que métodos de amplio alcance como la elaboración de prototipos. El desarrollo rápido de aplicaciones (RAD, Rapid Application Development) es un enfoque orientado a objetos para el desarrollo de sistemas que incluye un método de desarrollo (que abarca la generación de requerimientos de información) y herramientas de software. En este libro se aborda en el capítulo 6, en conjunto con la elaboración de prototipos, porque su enfoque filosófico es similar, aunque su método para crear un diseño con rapidez y obtener una pronta retroalimentación por parte de los usuarios es un poco diferente. (En el capítulo 18 se abunda en los enfoques orientados a objetos.) En la fase de determinación de los requerimientos de información del SDLC, el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Como puede ver, varios de los métodos para determinar los requerimientos de información implican interactuar directamente con los usuarios. Esta fase es útil para que el analista confirme la idea que tiene de la organización y sus objetivos. En ocasiones sólo realizan las dos primeras fases del ciclo de vida del desarrollo de sistemas. Esta clase de estudio podría tener un propósito distinto y por lo general la lleva a la práctica un especialista conocido como analista de información (IA, Information Analyst). Los implicados en esta fase son el analista y los usuarios, por lo general trabajadores y gerentes del área de operaciones. El analista de sistemas necesita conocer los detalles de las funciones del sistema actual: el quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. A continuación el analista debe preguntar la razón por la cual se utiliza el sistema actual. Podría haber buenas razones para realizar los negocios con los métodos actuales, y es importante tomarlas en cuenta al diseñar un nuevo sistema. Sin embargo, si la razón de ser de las operaciones actuales es que “siempre se han hecho de esta manera”, quizá será necesario que el analista mejore los procedimientos. La reingeniería de procesos de negocios podría ser útil para conceptualizar el negocio de una manera creativa. Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

ANÁLISIS DE LAS NECESIDADES DEL SISTEMA La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesidades del sistema. De nueva cuenta, herramientas y técnicas especiales auxilian al analista en la determinación de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma gráfica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, así como sus respectivas especificaciones. Durante esta fase el analista de sistemas analiza también las decisiones estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden determinar las condiciones, las alternativas de condición, las acciones y las reglas de acción. Existen tres métodos principales para el análisis de decisiones estructuradas: español estructurado, tablas y árboles de decisión. EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

11

En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. Si la administración de la empresa considera factible alguna de las recomendaciones, el analista sigue adelante. Cada problema de sistemas es único, y nunca existe sólo una solución correcta. La manera de formular una recomendación o solución depende de las cualidades y la preparación profesional de cada analista.

DISEÑO DEL SISTEMA RECOMENDADO En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos. Además, el analista facilita la entrada eficiente de datos al sistema de información mediante técnicas adecuadas de diseño de formularios y pantallas. La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. Entre los ejemplos de interfaces de usuario se encuentran el teclado (para teclear preguntas y respuestas), los menús en pantalla (para obtener los comandos de usuario) y diversas interfaces gráficas de usuario (GUIs, Graphical User Interfaces) que se manejan a través de un ratón o una pantalla sensible al tacto. La fase de diseño también incluye el diseño de archivos o bases de datos que almacenarán gran parte de los datos indispensables para los encargados de tomar las decisiones en la organización. Una base de datos bien organizada es el cimiento de cualquier sistema de información. En esta fase el analista también interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. Finalmente, el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento; también podría incluir árboles o tablas de decisión, diagramas de flujo de datos, un diagrama de flujo de sistema, y los nombres y funciones de cualquier rutina de código previamente escrita.

DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE En la quinta fase del ciclo de vida del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructura, los diagramas de Nassi-Shneiderman y el pseudocódigo. El analista se vale de una o más de estas herramientas para comunicar al programador lo que se requiere programar. Durante esta fase el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios Web que incluyan respuestas a preguntas frecuentes (FAQ, Frequently Asked Questions) en archivos “Léame” que se integrarán en el nuevo software. La documentación indica a los usuarios cómo utilizar el software y lo que deben hacer en caso de que surjan problemas derivados de este uso. Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo. Si el programa se ejecutará en un entorno de mainframe, se debe crear un lenguaje de control de trabajos (JCL, Job Control Language). Para garantizar la calidad, un programador podría efectuar un repaso estructurado del diseño o del código con el propósito de explicar las partes complejas del programa a otro equipo de programadores.

12

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

PRUEBA Y MANTENIMIENTO DEL SISTEMA Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de las pruebas las realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realiza una serie de pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual. El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan a cabo de manera rutinaria durante toda su vida útil. Gran parte del trabajo habitual del programador consiste en el mantenimiento, y las empresas invierten enormes sumas de dinero en esta actividad. Parte del mantenimiento, como las actualizaciones de programas, se pueden realizar de manera automática a través de un sitio Web. Muchos de los procedimientos sistemáticos que el analista emplea durante el ciclo de vida del desarrollo de sistemas pueden contribuir a garantizar que el mantenimiento se mantendrá al mínimo.

IMPLEMENTACIÓN Y EVALUACIÓN DEL SISTEMA Ésta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas. Además, el analista tiene que planear una conversión gradual del sistema anterior al actual. Este proceso incluye la conversión de archivos de formatos anteriores a los nuevos, o la construcción de una base de datos, la instalación de equipo y la puesta en producción del nuevo sistema. Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en aras del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigido el sistema lo están utilizando realmente. Debe hacerse hincapié en que, con frecuencia, el trabajo de sistemas es cíclico. Cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar al analista a regresar a la fase previa y modificar el trabajo realizado.

IMPACTO DEL MANTENIMIENTO Después de instalar un sistema, se le debe dar mantenimiento, es decir, los programas de cómputo tienen que ser modificados y actualizados cuando lo requieran. En la figura 1.4 se ilustra el tiempo promedio que se invierte en darle mantenimiento a un MIS típico. Según estimaciones, los departamentos invierten en mantenimiento de 48 a 60 por ciento del tiempo total del desarrollo de sistemas. Queda muy poco tiempo para el desarrollo de nue-

FIGURA 1.4 Nuevos sistemas y otras actividades

40% Mantenimiento de sistemas existentes

Algunos investigadores calculan que el tiempo invertido en el mantenimiento de sistemas podría llegar al 60 por ciento del tiempo total invertido en proyectos de sistemas.

60%

EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

13

FIGURA 1.5

Cambios mayores tanto en negocios como en tecnología

Consumo de recursos durante la vida del sistema.

Errores posteriores a la instalación

Cantidad de recursos consumidos, tiempo y dinero

Cambios menores a causa de errores y mejoras

Desarrollo de sistemas Tiempo

Día de instalación

vos sistemas. Conforme se incrementa el número de programas escritos, también lo hace la cantidad de mantenimiento que requieren. El mantenimiento se realiza por dos razones. La primera es la corrección de errores del software. No importa cuán exhaustivamente se pruebe el sistema, los errores se cuelan en los programas de cómputo. Los errores en el software comercial para PC se documentan como “anomalías conocidas”, y se corrigen en el lanzamiento de nuevas versiones del software o en revisiones intermedias. En el software hecho a la medida, los errores se deben corregir en el momento que se detectan. La otra razón para el mantenimiento del sistema es la mejora de las capacidades del software en respuesta a las cambiantes necesidades de una organización, que por lo general tienen que ver con alguna de las siguientes tres situaciones: 1. Con frecuencia, después de familiarizarse con el sistema de cómputo y sus capacidades, los usuarios requieren características adicionales. 2. El negocio cambia con el tiempo. 3. El hardware y el software cambian a un ritmo acelerado. La figura 1.5 ilustra la cantidad de recursos —por lo general tiempo y dinero— que se invierte en el desarrollo y mantenimiento de sistemas. El área bajo la curva representa la cantidad total invertida. Como puede apreciar, es probable que con el paso del tiempo el costo total del mantenimiento rebase el costo de desarrollar el sistema. Pasado un cierto tiempo es más factible realizar un nuevo estudio de sistemas, debido a que, evidentemente, el costo del mantenimiento continuo es mayor que el de la creación de un sistema de información completamente nuevo. En síntesis, el mantenimiento es un proceso continuo durante el ciclo de vida de un sistema de información. Después de instalar el sistema de información, por lo general el mantenimiento consiste en corregir los errores de programación que previamente no se detectaron. Una vez corregidos estos errores, el sistema alcanza un estado estable en el cual ofrece un servicio confiable a sus usuarios. El mantenimiento durante este periodo podría consistir en eliminar algunos errores previamente no detectados y en actualizar el sistema con algunos cambios menores. Sin embargo, conforme pasa el tiempo y los negocios y la tecnología cambian, los esfuerzos de mantenimiento se incrementan de manera considerable.

USO DE HERRAMIENTAS CASE A lo largo de este libro hacemos énfasis en la necesidad de un enfoque sistemático e integral para el análisis, diseño e implementación de sistemas de información. Reconocemos que para ser productivos, los analistas de sistemas deben realizar sus tareas de una manera organizada, precisa y minuciosa. Desde principios de la década de 1990, los analistas empezaron a beneficiarse de las herramientas de productividad, denominadas herramientas de Ingeniería de Software Asistida por Computadora (CASE, Computer-Aided Software Engineering), que

14

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

se crearon explícitamente para mejorar su trabajo rutinario mediante apoyo automatizado. De acuerdo con un estudio reciente, era más probable que los departamentos de sistemas de información con más de 10 empleados adoptaran las herramientas CASE que los departamentos con menos empleados. Los sistemas, procedimientos y prácticas administrativas de las organizaciones podrían restringir la difusión de las herramientas CASE. Los analistas de sistemas se apoyan en estas herramientas, desde el principio hasta el fin del ciclo de vida, para incrementar la productividad, comunicarse de manera más eficiente con los usuarios e integrar el trabajo que desempeñan en el sistema.

RAZONES PARA EL USO DE LAS HERRAMIENTAS CASE Aumento en la productividad del analista Visible Analyst (VA) es una herramienta CASE que da al analista de sistemas la posibilidad de realizar planeación, análisis y diseño por medios gráficos, con el propósito de construir aplicaciones cliente-servidor y bases de datos complejas. Esta herramienta permite modelar los datos, procesos y objetos en diferentes formatos. Visible Analyst genera información sobre el modelo en muchas formas distintas, incluyendo COBOL, C, Visual Basic, SQL y XML. (En el sitio Web de este libro encontrará ejercicios de VA parcialmente terminados para las Experiencias con HyperCase y el Caso de la CPU que se sigue en los capítulos de este libro.) Visible Analyst permite que sus usuarios dibujen y modifiquen diagramas con facilidad. De esta manera, el analista es más productivo tan sólo con la reducción del tiempo considerable que se invierte en dibujar y corregir manualmente diagramas de flujo de datos hasta que tengan una apariencia aceptable. Un paquete de herramientas como Visible Analyst también mejora la productividad de grupos al dar a los analistas la posibilidad de compartir fácilmente el trabajo con otros miembros del equipo, quienes sólo tienen que abrir el archivo en sus PCs y revisar o modificar lo que se haya hecho. Esta facilidad de compartir el trabajo reduce el tiempo necesario para reproducir diagramas de flujo de datos y distribuirlos entre los miembros del equipo. Por tanto, en vez de requerir una distribución rigurosa y un calendario de respuestas con fines de retroalimentación, un paquete de herramientas permite a los miembros del equipo de análisis de sistemas trabajar con los diagramas siempre que lo necesiten. Las herramientas CASE también facilitan la interacción entre miembros de un equipo al hacer que la diagramación sea un proceso iterativo y dinámico más que uno en el cual los cambios causen molestia y se conviertan en un freno para la productividad. En este caso la herramienta CASE para dibujar y grabar diagramas de flujo de datos ofrece un registro de la evolución de las ideas del equipo en lo concerniente a los flujos de datos. Mejora de la comunicación analista-usuario Para que el sistema propuesto se concrete y sea útil en la práctica, es esencial una excelente comunicación entre analistas y usuarios durante todo el ciclo de vida del desarrollo de sistemas. El éxito de la futura implementación del sistema depende de la capacidad de analistas y usuarios para comunicarse de una manera eficiente. Hasta el momento, de las experiencias de analistas que utilizan herramientas CASE se desprende que su uso fomenta una mayor y más eficiente comunicación entre usuarios y analistas. Analistas y usuarios por igual informan que las herramientas CASE ponen a su alcance un medio para comunicar aspectos del sistema durante su conceptualización. A través de apoyo automatizado que incluye salida en pantalla, los clientes pueden apreciar de inmediato cómo están representados los flujos de datos y otros conceptos del sistema, y pueden solicitar correcciones o cambios que hubieran tomado demasiado tiempo con herramientas anteriores. El hecho de que un diagrama en particular sea considerado como útil por los usuarios o los analistas al final del proyecto es cuestionable. Lo importante es que este apoyo automatizado para muchas actividades de diseño del ciclo de vida es un medio para llegar a un fin al fungir como catalizador de la interacción analista-usuario. Los mismos argumentos que se utilizan para apoyar el rol de las herramientas CASE en el incremento de la productividad son igualmente válidos en este escenario; es decir, las tareas de dibujo, reproducción EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

15

y distribución toman mucho menos tiempo, de tal forma que es más sencillo compartir el trabajo en progreso con los demás usuarios. Integración de las actividades del ciclo de vida La tercera razón para el uso de las herramientas CASE es integrar las actividades y proporcionar continuidad de una fase a la siguiente durante todo el ciclo de vida del desarrollo de sistemas. Las herramientas CASE son especialmente útiles cuando una fase en particular del ciclo de vida requiere varias iteraciones de retroalimentación y modificaciones. Recuerde que la intervención de los usuarios puede ser importante en cada una de las fases. La integración de actividades mediante el uso subyacente de tecnologías facilita a los usuarios la comprensión de la manera en que se relacionan y dependen entre sí todas las fases del ciclo de vida. Evaluar de manera precisa los cambios en el mantenimiento La cuarta, y probablemente una de las razones más importantes para el uso de herramientas CASE, es que permiten a los usuarios analizar y evaluar el impacto de los cambios en el mantenimiento. Por ejemplo, el tamaño de un elemento como un número de cliente podría requerir alargarse. La herramienta CASE pueden generar referencias cruzadas de cada pantalla, informe y archivo en el cual sea utilizado el elemento, dando lugar a un plan de mantenimiento integral.

HERRAMIENTAS CASE DE BAJO Y ALTO NIVEL Las herramientas CASE se clasifican como de bajo nivel, de alto nivel e integradas, estas últimas combinando las de alto y bajo nivel en un solo conjunto. A pesar de que los expertos difieren en los criterios que definen con precisión cuáles son las herramientas CASE de alto nivel y cuáles las de bajo nivel, podría ser útil clasificarlas con base en los usuarios a los que dan apoyo. Las herramientas CASE de alto nivel ayudan principalmente a los analistas y diseñadores, en tanto que las de bajo nivel son utilizadas con más frecuencia por programadores y trabajadores que deben implementar los sistemas diseñados con herramientas CASE de alto nivel.

HERRAMIENTAS CASE DE ALTO NIVEL Una herramienta CASE de alto nivel da al analista la posibilidad de crear y modificar el diseño del sistema. Toda la información relacionada con el proyecto se almacena en una enciclopedia denominada depósito CASE, una enorme colección de registros, elementos, diagramas, pantallas, informes e información diversa (véase la figura 1.6). Con la información del depósito se podrían generar informes que muestren dónde está incompleto el diseño o dónde contiene errores. Las herramientas CASE de alto nivel también pueden apoyar la modelación de los requerimientos funcionales de una organización, ayudar a los analistas y usuarios a definir el alcance de un proyecto determinado y a visualizar la forma en que el proyecto se combina con otras partes de la organización. Además, algunas herramientas CASE de alto nivel pueden ayudar en la creación de prototipos de diseños de pantallas e informes.

HERRAMIENTAS CASE DE BAJO NIVEL Las herramientas CASE de bajo nivel se utilizan para generar código fuente de computadora, eliminando así la necesidad de programar el sistema. La generación de código tiene varias ventajas: 1. El sistema se puede generar más rápido que si se tuviera que escribir todos los programas. No obstante, con frecuencia el periodo para familiarizarse con la metodología utilizada por el generador de código es muy largo, por lo que la generación del programa podría ser más lenta al principio. Además, es necesario ingresar por completo el diseño en el conjunto de herramientas, tarea que podría tomar un tiempo considerable. 2. La generación de código reduce el tiempo invertido en el mantenimiento. No hay necesidad de modificar, probar y depurar los programas de computadora. En lugar de eso, al

16

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

AGREGAR CLIENTE NÚMERO XXXXXX NOMBRE CALLE CIUDAD ESTADO CP

XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX XX XXXXX-XXXX

INFORME DE ANÁLISIS DE VENTAS

FIGURA 1.6

DESCRIPCIÓN DEL ELEMENTO XXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXX

El concepto de depósito.

VENTAS TOTALES ZZ,ZZ9 ZZ,ZZ9 ZZ,ZZ9 ZZ,ZZ9 ZZ,ZZ9 ZZ,ZZ9

Diseño de pantallas e informes

Diagramas y modelos del sistema

Artículo = Número + Descripción + Costo + Precio + Cantidad disponible + Cantidad pedida * Punto de reabastecimiento * Ventas mensuales + Ventas anuales

Requerimientos del sistema • Agregar nuevos clientes • Identificar artículos de venta rápida y lenta • Ingresar órdenes de clientes • Consultar saldo de crédito de cliente • Mantener inventario adecuado

DO WHILE NOT Fin de archivo Leer registro de artículo IF artículo tiene poco inventario Imprimir orden de compra

Diccionario de datos y lógica de procesos

Actualizar registro de artículo ENDIF ENDDO

Productos finales • Agregar pantalla de cliente • Informe de análisis de artículos • Pantalla para ingresar órdenes de clientes • Pantalla para investigación de clientes • Programa para órdenes de compra a distribuidores • Pronóstico de temporada

Project Management

modificar el diseño CASE se vuelve a generar el código. Si se invierte menos tiempo en el mantenimiento, se tiene más tiempo para desarrollar nuevos sistemas y aligerar la acumulación de proyectos en espera de desarrollo. 3. Más de un lenguaje de computadora, de tal manera que se facilita la migración de sistemas de una plataforma, digamos de mainframe, a otra, como una PC. Por ejemplo, la edición de VA para corporaciones puede generar código fuente en lenguajes de tercera generación como ANSI, COBOL o C. 4. La generación de código ofrece una forma económica de ajustar los sistemas comerciales de fabricantes de sistemas a las necesidades de la organización. Con frecuencia, la modificación de esta clase de software implica un esfuerzo tan grande que su costo es mayor al de la compra del mismo. Con el software de generación de código, la compra de un diseño CASE y un depósito CASE para la aplicación permite al analista modificar el diseño y generar el sistema de cómputo modificado. 5. El código generado está libre de errores de programación. Los únicos errores potenciales son los de diseño, los cuales se pueden minimizar produciendo informes de análisis CASE para garantizar que el diseño del sistema esté completo y correcto. EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

17

Aspectos de las especificaciones del programa

Aspectos del diseño

Análisis

Diseño Requerimientos

Ciclo de vida del desarrollo de sistemas tradicional

Diseño y codificación del programa

Código fuente del programa

Errores de instalación

Prueba del programa

Instalación Sistema terminado

Defectos e inconsistencias del diseño

Aspectos del diseño

Análisis

Especificaciones del programa

Errores de programación

Diseño Entidades de diseño CASE

Requerimientos

Herramientas CASE de alto nivel

Depósito CASE

Herramientas CASE de bajo nivel (generador de código)

Ciclo de vida del desarrollo de sistemas CASE

Instalación Sistema de cómputo libre de errores

FIGURA 1.7 Ciclos de vida del desarrollo de sistemas CASE y tradicional.

La figura 1.7 ilustra los ciclos de vida del desarrollo de sistemas tradicional y CASE. Observe que las partes de codificación, prueba y depuración del programa se han eliminado en el ciclo de vida CASE.

INGENIERÍA INVERSA Y REINGENIERÍA DE SOFTWARE La ingeniería inversa y la reingeniería de software son métodos para alargar la vida de programas anteriores, conocidos como software heredado. En ambos métodos se emplea software de reingeniería asistida por computadora (CARE, Computer-Assisted Reengineering) para analizar y reestructurar el código de computadora existente. En el mercado hay varios conjuntos de herramientas de ingeniería inversa. Observe que el término reingeniería se utiliza en numerosos contextos diferentes de ingeniería, programación y negocios. Con frecuencia se emplea para denotar “reingeniería de procesos de negocios”, que es una forma de darle una nueva orientación a los procesos clave de una organización. Los analistas de sistemas pueden desempeñar un rol importante en la reingeniería de procesos de negocios, puesto que muchos de los cambios requeridos sólo se pueden lograr mediante el uso de tecnología de información novedosa. La ingeniería inversa es lo opuesto a la generación de código. Como se ilustra en la figura 1.8, el código fuente de la computadora es examinado, analizado y convertido en entidades para el depósito. El primer paso de la ingeniería inversa de software es cargar, en el conjunto de herramientas, el código de programa existente (tal como se haya escrito en COBOL, C o cualquier otro lenguaje de alto nivel). Según el conjunto de herramientas de ingeniería inversa que se utilice, el código es analizado y las herramientas producen algunos o todos los elementos siguientes: 1. Estructuras de datos y elementos que describen los archivos y registros almacenados por el sistema. 2. Diseños de pantallas, si el programa es en línea. 3. Esquemas de informes para programas por lotes. 4. Un diagrama de estructura que muestra la jerarquía de los módulos del programa. 5. Diseño y relaciones de bases de datos.

18

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

DO Procesar registros Agregar 1 a Contador Agregar Cant. a Total ..... ENDDO Código fuente de la computadora: C, COBOL, Xbase... Programas de cómputo existentes cargados en el conjunto de herramientas de ingeniería inversa.

FIGURA 1.8 Conjunto de herramientas de ingeniería inversa

El conjunto de herramientas de ingeniería inversa examina el código fuente de la computadora y produce un depósito CASE.

Conceptos de ingeniería inversa.

Depósito CASE Se crea el depósito CASE, incluyendo diagramas de estructura, descripciones de registros y elementos en el diccionario de datos, esquemas de pantalla y de informes.

El diseño almacenado en el depósito podría modificarse o incorporarse en información de otro proyecto CASE. Cuando se terminan todas las modificaciones, el nuevo código del sistema puede volver a generarse. La reingeniería se refiere al proceso completo de convertir el código de programa al diseño CASE, modificar el diseño y volver a generar el nuevo código de programa. Son varias las ventajas que se consiguen al utilizar un conjunto de herramientas de ingeniería inversa: 1. Reducción del tiempo requerido para el mantenimiento del sistema, con lo cual queda más tiempo para nuevos desarrollos. 2. Se genera documentación, que podría haber sido inexistente o mínima en los programas anteriores. 3. Se crean programas estructurados a partir de código de computadora no estructurado o pobremente estructurado. 4. Los cambios futuros al mantenimiento son más sencillos, porque se pueden realizar al nivel del diseño más que al nivel del código. 5. Es posible analizar el sistema con el fin de eliminar porciones sin utilizar de código de computadora, el cual aún podría estar presente en programas anteriores a pesar de que las revisiones hechas al programa a lo largo de los años lo hayan vuelto obsoleto.

ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADO A OBJETOS El análisis y diseño orientado a objetos es un enfoque cuyo propósito es facilitar el desarrollo de sistemas que deben cambiar con rapidez en respuesta a entornos de negocios dinámicos. El capítulo 19 le ayuda a entender el análisis y diseño de sistemas orientados a objetos, en qué difiere del enfoque estructurado del SDLC y bajo qué circunstancias es apropiado utilizar un enfoque orientado a objetos. Es difícil trabajar bien con técnicas orientadas a objetos en situaciones en las cuales sistemas de información complicados requieren mantenimiento, adaptación y rediseño de manera continua. Los enfoques orientados a objetos utilizan el estándar de la industria para la modelación de sistemas orientados a objetos, el lenguaje unificado de modelación (UML, Unified Modeling Language), para analizar un sistema en forma de modelo de casos de uso. La programación orientada a objetos difiere de la programación tradicional de procedimientos en que la primera examina los objetos que conforman un sistema. Cada objeto es una representación en computadora de alguna cosa o suceso real. Los objetos pueden ser clientes, artículos, pedidos, etc. Los objetos se representan y agrupan en clases, que son óptimas para su reutilización y mantenimiento. Una clase define el conjunto de atributos y comportamientos que comparten los objetos que ésta contiene.

EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

19

PROGRAMACIÓN EXTREMA Y OTRAS METODOLOGÍAS ALTERNAS Aunque este libro se enfoca en la metodología que actualmente se utiliza de manera más amplia, en ocasiones el analista tendrá que reconocer que la organización se podría beneficiar de una metodología alterna. Quizá un proyecto de sistemas con un enfoque estructurado haya fallado, o quizá las subculturas que existen en la organización, compuestas por diferentes grupos de usuarios, parezcan más proclives a utilizar un método alterno. En un espacio tan breve no podríamos analizar adecuadamente estos métodos alternos, que merecen y han sido explicados en sus propios libros e investigaciones. Sin embargo, al mencionarlos aquí esperamos que usted tome conciencia de que, bajo ciertas circunstancias, su organización podría requerir una alternativa o complemento para un análisis y diseño estructurado y para el ciclo de vida del desarrollo de sistemas. La programación extrema (XP, Extreme Programming) es un enfoque para el desarrollo de software que utiliza buenas prácticas de desarrollo y las lleva a los extremos. Se basa en valores, principios y prácticas esenciales. Los cuatros valores son la comunicación, la simplicidad, la retroalimentación y la valentía. Recomendamos a los analistas de sistemas que adopten estos valores en todos los proyectos que emprendan, no sólo cuando recurran a medidas de programación extrema. Durante la fase de terminación de un proyecto, con frecuencia es necesario realizar ajustes en la administración del mismo. En el capítulo 3 veremos que XP puede garantizar la terminación exitosa de un proyecto ajustando recursos importantes como el tiempo, el costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen adecuadamente en la planeación, se propicia un equilibrio entre los recursos y las actividades requeridas para completar el proyecto. El llevar las prácticas de desarrollo al extremo es más recomendable cuando se siguen prácticas propias de XP. En el capítulo 6 describimos cuatro prácticas esenciales de XP: la liberación limitada, la semana de trabajo de 40 horas, alojar a un cliente en el sitio y el uso de la programación en parejas. A primera vista estas prácticas parecen extremas, pero como observará, podemos aprender algunas lecciones valiosas al incorporar muchos de estos valores y prácticas de XP en los proyectos de análisis y diseño de sistemas. La creación de prototipos (que es diferente a la creación de prototipos que veremos en el capítulo 6) es uno de los métodos alternos más populares, junto con ETHICS, el enfoque de usar un campeón del proyecto, la Metodología Soft Systems y Multiview. La creación de prototipos, concebida originalmente en otras disciplinas y aplicada a los sistemas de información, surgió como respuesta a los extensos periodos de desarrollo asociados con el enfoque del ciclo de vida del desarrollo de sistemas y a la incertidumbre que existe con frecuencia en relación con los requerimientos de los usuarios. ETHICS, por su parte, se presentó como una metodología socio-técnica que combina soluciones sociales y técnicas. El enfoque de usar un campeón del proyecto, un concepto tomado de la mercadotecnia, adopta la estrategia de involucrar a una persona clave de cada área donde tiene influencia el sistema para garantizar el éxito del mismo. La Metodología Soft Systems fue concebida como una manera de modelar un mundo muchas veces caótico mediante el uso de “imágenes ricas”, ideogramas que captan los relatos característicos de una organización. Multiview se propuso como una forma de organizar y utilizar elementos de diversas metodologías en competencia.

RESUMEN La información se puede considerar como un recurso organizacional. Como tal, se debe manejar con cuidado, al igual que los demás recursos. La disponibilidad de gran poder de cómputo en las organizaciones ha propiciado una explosión de información y, en consecuencia, se debe prestar mayor atención al manejo de la información generada.

20

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

EXPERIENCIA CON HYPERCASE®

1

“Bienvenido a Maple Ridge Engineering, al que en adelante llamaremos MRE. Esperamos que disfrute su trabajo de consultor de sistemas para nosotros. A pesar de que he trabajado aquí durante cinco años en diferentes actividades, recién fui asignado para fungir como apoyo administrativo para Snowden Evans, el jefe del nuevo Departamento de Capacitación y Administración de Sistemas. Ciertamente somos un grupo heterogéneo. Conforme se familiarice con la compañía, asegúrese de aprovechar todos sus conocimientos, tanto técnicos como relativos a las personas, para entender cómo somos e identificar los problemas y conflictos relacionados con nuestros sistemas de información que usted considere susceptibles de arreglar”. “Para ponerlo al tanto, le diré que Maple Ridge Engineering es una compañía de ingeniería médica de mediano tamaño. El año pasado nuestros ingresos rebasaron 287 millones de dólares. Empleamos alrededor de 335 personas. Hay cerca de 150 empleados administrativos, así como personal directivo y de oficinas, como yo, y aproximadamente 75 profesionistas, como ingenieros, médicos y analistas de sistemas, y cerca de 110 empleados como dibujantes y técnicos”. “Hay cuatro oficinas. A través de HyperCase, usted nos visitará en nuestras oficinas centrales en Maple Ridge, Tennessee. Tenemos otras tres sucursales al sur de Estados Unidos: Atlanta, Georgia; Charlotte, Carolina del Norte; y Nueva Orleáns, Luisiana. Nos dará gusto que nos visite”. “Por el momento, explore HyperCase con Nestcape Navigator o Microsoft Internet Explorer”. “Para aprender más sobre Maple Ridge Engineering como compañía, o para saber cómo entrevistar a nuestros empleados, quién utilizará los sistemas que usted diseñe y cómo son sus oficinas dentro de nuestra compañía, visite el sitio Web de este libro, y seleccione el vínculo HyperCase. Al desplegarse la pantalla de HyperCase, elija Start e ingresará a la recepción de Maple Ridge Engineering. A partir de aquí, puede empezar de inmediato su trabajo de consultoría”. Este sitio Web contiene información útil para el proyecto y archivos que usted puede bajar a su computadora. Uno de los archivos contiene una serie de archivos de datos de Visible Analyst para utilizarse en HyperCase. Estos archivos incluyen una serie parcialmente construida de diagramas de flujo de datos, diagramas de entidad-relación y el depósito CASE. El sitio Web de HyperCase también contiene ejercicios adicionales. HyperCase está diseñado para facilitar su exploración, así que no ignore cualquier objeto o pista que encuentre en la página Web.

Los analistas de sistemas recomiendan, diseñan y dan mantenimiento a diversos tipos de sistemas, como los sistemas de procesamiento de transacciones (TPS), sistemas de automatización de la oficina (OAS), sistemas de trabajo del conocimiento (KWS) y sistemas de información gerencial (MIS). También crean sistemas orientados a la toma de decisiones, como los sistemas de apoyo a la toma de decisiones (DSS), sistemas expertos (ES), sistemas de apoyo a la toma de decisiones en grupo (GDSS), sistemas de trabajo colaborativo apoyados por computadora (CSCWS) y sistemas de apoyo a ejecutivos (ESS). Muchas aplicaciones se conciben originalmente para, o se migran a, la Web para apoyar el comercio electrónico. El diseño y análisis de sistemas es un enfoque sistemático para identificar problemas, oportunidades y objetivos; para analizar los flujos de información de las organizaciones, y para diseñar sistemas de información computarizados destinados a solucionar problemas. Los analistas de sistemas se ven precisados a desempeñar diversos roles durante el transcurso de su trabajo. Algunos de estos roles son: (1) consultor externo para el negocio, (2) experto de apoyo técnico dentro de un negocio y (3) agente de cambio en situaciones tanto internas como externas. EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

21

Los analistas poseen un amplio rango de habilidades. En primer lugar, y más importante, el analista es un solucionador de problemas; alguien que disfruta el reto de analizar un problema e idear soluciones factibles. El analista de sistemas requiere habilidades de comunicación que le permitan relacionarse de manera significativa con diversas clases de gente diariamente, así como habilidades de computación. El involucramiento del usuario final es crítico para el éxito del proyecto. Los analistas actúan de manera sistemática. El marco para este enfoque sistemático lo ofrece el ciclo de vida del desarrollo de sistemas (SDLC). Este ciclo de vida se puede dividir en siete fases secuenciales, aunque en realidad las fases se interrelacionan y con frecuencia se llevan a cabo de manera simultánea. Las siete fases son: identificación de problemas, oportunidades y objetivos; determinación de los requerimientos de información; análisis de las necesidades del sistema; diseño del sistema recomendado; desarrollo y documentación del software; prueba y mantenimiento del sistema, e implementación y evaluación del sistema. Los paquetes de software automatizados, basados en PC, para el análisis y diseño de sistemas se conocen como herramientas de Ingeniería de Software Asistida por Computadora (CASE). Las cuatro razones para adoptar las herramientas CASE son: incrementar la productividad del analista, mejorar la comunicación entre analistas y usuarios, integrar las actividades del ciclo de vida, y analizar y valorar el impacto de los cambios en el mantenimiento. Los analistas también emplean enfoques de reingeniería asistida por computadora (CARE) para realizar ingeniería inversa de software y reingeniería con el propósito de extender la vida útil del software heredado. El análisis orientado a objetos (OOA) y el diseño orientado a objetos (OOD) constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos de la programación orientada a objetos, que han sido codificados en UML, un lenguaje estandarizado de modelación en el cual los objetos generados no sólo incluyen código referente a los datos sino también instrucciones acerca de las operaciones que se realizarán sobre los datos. Cuando la situación particular de una organización así lo requiera, el analista podría dejar el SDLC y probar una metodología alterna. Un enfoque, denominado programación extrema (XP), lleva al límite las prácticas de análisis y diseño. La creación de prototipos, ETHICS, el uso de un campeón del proyecto, la Metodología Soft Systems y Multiview son enfoques de desarrollo que ofrecen perspectivas diferentes.

PALABRAS Y FRASES CLAVE agente de cambio análisis orientado a objetos (OOA) análisis y diseño de sistemas análisis y diseño de sistemas orientado a objetos (O-O) analista de sistemas aplicaciones de comercio electrónico asistente digital personal (PDA) CARE (reingeniería asistida por computadora) ciclo de vida del desarrollo de sistemas (SDLC) comercio móvil consultor de sistemas creación de prototipos depósito CASE desarrollo rápido de aplicaciones (RDA) diseño orientado a objetos (OOD) enfoque de uso de un campeón del proyecto ETHICS

22

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

experto en soporte técnico groupware herramientas CASE información generada por computadora Ingeniería de Software Asistida por Computadora (CASE) ingeniería inversa de software inteligencia artificial (AI) lenguaje unificado de modelación (UML) mantenimiento de generación de código Metodología Soft Systems migración de sistemas Multiview programación extrema (XP) reingeniería sistemas de apoyo a ejecutivos (ESS) sistemas de apoyo a la toma de decisiones (DSS) sistemas de apoyo a la toma de decisiones en grupo (GDSS)

sistemas de automatización de la oficina (OAS) sistemas de información gerencial (MIS) sistemas de planeación de recursos empresariales (ERP) sistemas de procesamiento de transacciones (TPS)

sistemas de trabajo colaborativo apoyado por computadora (CSCWS) sistemas de trabajo del conocimiento (KWS) sistemas expertos sistemas Web software de código abierto software heredado

PREGUNTAS DE REPASO 1. Describa por qué es mejor considerar a la información como un recurso de la organización más que como un subproducto derivado de los negocios. 2. Defina lo que significa un sistema de procesamiento de transacciones. 3. Explique la diferencia entre los sistemas de automatización de la oficina (OAS) y los sistemas de trabajo del conocimiento (KWS). 4. Compare la definición de sistemas de información gerencial (MIS) y la de sistemas de apoyo a la toma de decisiones (DSS). 5. Defina el concepto sistemas expertos. ¿En qué son diferentes los sistemas expertos y los sistemas de apoyo a la toma de decisiones? 6. Enumere los problemas de interacción grupal que están destinados a resolver los sistema de apoyo a la toma de decisiones en grupo (GDSS) y los sistemas de trabajo colaborativo apoyados por computadora (CSCWS). 7. ¿Cuál es el término más común, CSCWS o GDSS? Explique su respuesta. 8. Defina el concepto comercio móvil (m-commerce). 9. Enumere las ventajas de implementar aplicaciones en la Web. 10. ¿Cuál es la razón preponderante para diseñar sistemas ERP? 11. Defina el significado de software de código abierto. 12. Enumere las ventajas de utilizar técnicas de análisis y diseño de sistemas al desarrollar sistemas de información computarizados para negocios. 13. Mencione tres roles que debe desempeñar un analista de sistemas. Dé una definición de cada rol. 14. ¿Qué cualidades personales son de utilidad para el analista de sistemas? Enumérelas. 15. Mencione y describa brevemente las siete fases del ciclo de vida del desarrollo de sistemas (SDLC). 16. ¿En qué consiste el desarrollo rápido de aplicaciones (RAD)? 17. Defina ingeniería inversa de software y reingeniería en el contexto de reingeniería asistida por computadora (CARE). 18. Mencione las cuatro razones para adoptar herramientas CASE. 19. ¿Cuáles son los cuatro valores de la programación extrema? 20. Defina los conceptos análisis orientado a objetos y diseño orientado a objetos. 21. ¿Qué es el UML?

BIBLIOGRAFÍA SELECCIONADA Avison, D. E. y A. T. Wood-Harper, Multiview: An Exploration in Information Systems Development, Oxford: Blackwell Scientific Publications, 1990. Beath, C. M., “Supporting the Information Technology Champion”, MIS Quarterly, vol. 15, núm. 3, septiembre de 1991, pp. 355-372. Checkland, P. B., “Soft Systems Methodology”, Human Systems Management, vol. 8, núm. 4, 1989, pp. 271-289. Coad, P. y E. Yourdon, Object-Oriented Analysis, 2a. ed., Englewood Cliffs, NJ: Prentice Hall, 1991. Davis, G. B. y M. H. Olson, Management Information Systems: Conceptual Foundation, Structure, and Development, 2a. ed., Nueva York: McGraw-Hill, 1985. EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

23

Holsapple, C. W. y A. B. Whinston, Business Expert Systems, Homewood, IL: Irwin, 1987. Jackson, M. A., Systems Development, Englewood Cliffs, NJ: Prentice Hall, 1983. Kendall, K. E., “Behavioral Implications for Systems Analysis and Design: Prospects for the Nineties”, Journal of Management Systems, vol. 3, núm. 1, 1991, pp. 1-4. Kendall, J. E. y K. E. Kendall, “Systems Analysis and Design”, In International Encyclopedia of Business and Management, vol. 5, editado por M. Warner, pp. 4749-4759. Londres: Routledge, 1996. ———, “Information Delivery Systems: An Exploration of Web Push and Pull Technologies”, Communications of AIS, vol. 1, artículo 14, 23 de abril de 1999. Laudon, K. C. y J. P. Laudon, Management Information Systems, 8a. ed., Upper Saddle River, NJ: Prentice Hall, 2004. Markoff, J., “Microsoft Sees Software ‘Agent’ as Way to Avoid Distractions”, New York Times, 17 de julio de 2000, pp. C1, C4. Mumford, E. y M. Weir, Computer Systems in Work Design—The ETHICS Method, Londres: Associated Business Press, 1979. Sahami, M. S., Dumais, D. Heckerman y E. Horvitz, “A Bayesian Approach to Filtering Junk E-Mail”, AAAI Technical Report WS-98-05. AAAI Workshop on Learning for Text Categorization, julio de 1998, Madison, WI. Sharma, S. y A. Rai, “CASE Deployment in IS Organizations”, Communications of the ACM, vol. 43, núm. 1, enero de 2000, pp. 80-88. Stohr, E. A. y S. Viswanathan, “Recommendation Systems”, en Emerging Information Technologies: Improving Decisions, Cooperation, and Infrastructure, editado por K. E. Kendall, pp. 21-44. Thousand Oaks, CA: Sage Publications, 1999. www.visible.com/products/index.html. Última visita el 27 de agosto de 2003. Yourdon, E., Modern Structured Analysis. Englewood Cliffs, NJ: Prentice Hall, 1989.

24

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

CASO DE LA CPU ALLEN SCHMIDT, JULIE E. KENDALL

Y

KENNETH E. KENDALL

EMPIEZA EL CASO

EPISODIO

1

Un día soleado y caluroso de fines de octubre, Chip Puller estacionó su automóvil y se encaminó a su oficina en la Central Pacific University. Era agradable la sensación de comenzar como analista de sistemas, y esperaba con ansia el momento de conocer a sus compañeros. En la oficina, Anna Liszt se presenta a sí misma. “Nos han asignado para trabajar como equipo en un nuevo proyecto. Puedo ponerte al tanto de los detalles y después hacemos un recorrido por las instalaciones.” “Me parece bien”, contesta Chip. “¿Cuánto tiempo llevas trabajando aquí?” “Alrededor de cinco años”, responde Anna. “Empecé como analista programador, pero en los últimos años me he dedicado al análisis y el diseño. Espero que encontremos algunos métodos para incrementar nuestra productividad.” “Háblame acerca del nuevo proyecto”, dice Chip. “Bueno”, contesta Anna, “al igual que muchas organizaciones, tenemos un gran número de microcomputadoras con diferentes paquetes de software instalados. En 1980 había pocas microcomputadoras y una colección dispersa de software, pero se han incrementado rápidamente en los últimos años. El sistema actual utilizado para mantener el software y el hardware ha sido sobrepasado.” “¿Qué hay de los usuarios? ¿A quién debo conocer? ¿Quién crees que sea importante que nos ayude con el nuevo sistema?”, pregunta Chip. “Conocerás a todos, pero recientemente conocí a algunas personas importantes, y te diré lo que aprendí de ellas para que las recuerdes cuando te reúnas con ellas. “Dot Matricks es gerente de todos los sistemas de microcomputadoras de la Central Pacific. Al parecer podemos trabajar bien en conjunto. Ella es muy competente. Realmente le agrada mejorar la comunicación entre usuarios y analistas.” “Será un placer conocerla”, especula Chip. “Luego está Mike Crowe, el experto en mantenimiento de las microcomputadoras. Él es el más amable, pero está demasiado ocupado. Necesitamos ayudarle a aligerar su carga. Cher Ware es compañera de Mike. Ella es muy liberal, pero no me malinterpretes, ella conoce su trabajo”, dice Anna. “Debe ser divertido trabajar con ella”, comenta Chip. “Es probable”, coincide Anna. “También conocerás a la analista financiera, Paige Prynter. Aún no la conozco.” “Tal vez yo pueda ayudarte”, dice Chip. “Por último, deberías —es decir, deberás— conocer a Hy Perteks, quien dirige bastante bien el Centro de Información. A él le encantaría que lográramos integrar las actividades de nuestro ciclo de vida.” “Suena prometedor”, dice Chip. “Creo que la voy a pasar bien aquí.”

EJERCICIO E-1. De la conversación preliminar que sostuvieron Chip y Anna, ¿en cuáles de los elementos que mencionaron se podrían aplicar las herramientas CASE?

EL ROL DEL ANALISTA DE SISTEMAS

CAPÍTULO 1

25

EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN

2

OBJETIVOS DE APRENDIZAJE Una vez que haya dominado el material de este capítulo, podrá: 1. Entender que las organizaciones son sistemas y que el analista debe analizarlas desde una perspectiva sistémica. 2. Describir sistemas de manera gráfica mediante diagramas de flujo de datos de contexto y modelos entidad-relación. 3. Reconocer que los diversos niveles de administración requieren sistemas diferentes. 4. Entender que la cultura organizacional influye en el diseño de los sistemas de información.

Para analizar y diseñar sistemas de información apropiados, los analistas de sistemas tienen que visualizar a las organizaciones donde trabajan como sistemas formados por las interacciones de tres fuerzas principales: los niveles de administración, el diseño de las organizaciones y las culturas organizacionales. Las organizaciones son grandes sistemas compuestos por subsistemas interrelacionados. Los subsistemas reciben la influencia de tres amplios niveles de tomadores de decisiones administrativas (operaciones, administración de nivel medio y administración estratégica) que dividen horizontalmente el sistema organizacional. Todas las culturas y subculturas organizacionales influyen en la forma en que se interrelacionan los individuos de los subsistemas. En este capítulo se tratan estos temas y sus implicaciones para el desarrollo de los sistemas de información.

LAS ORGANIZACIONES COMO SISTEMAS Las organizaciones se consideran como sistemas diseñados para cumplir metas y objetivos predeterminados con la intervención de la gente y otros recursos de que disponen. Las organizaciones se componen de sistemas más pequeños e interrelacionados (departamentos, unidades, divisiones, etc.) que se encargan de funciones especializadas. Entre las funciones comunes están la contabilidad, el marketing, la producción, el procesamiento de datos y la administración. Con el tiempo, las funciones especializadas (sistemas más pequeños) se reintegran a través de diversos mecanismos para dar forma a un todo organizacional eficiente. La importancia de considerar a las organizaciones como sistemas complejos radica en que los principios que se aplican a los sistemas permiten formarse una idea de la manera en que funcionan las organizaciones. Es muy importante considerar a la organización como un todo, con el fin de averiguar adecuadamente los requerimientos de información y de di-

27

señar sistemas de información apropiados. Todos los sistemas se componen de subsistemas (que incluyen a los sistemas de información); por lo tanto, al estudiar una organización, también examinamos cómo influyen los sistemas más pequeños y cómo funcionan.

INTERRELACIÓN E INTERDEPENDENCIA DE LOS SISTEMAS Todos los sistemas y subsistemas se interrelacionan y son interdependientes. Esta situación tiene importantes implicaciones tanto para las organizaciones como para los analistas de sistemas encargados de contribuir a que aquéllas consigan de la mejor manera sus metas. Cuando se cambia o elimina un elemento de un sistema, el resto de los elementos y subsistemas del sistema también experimentan cambios importantes. Por ejemplo, suponga que los administradores de una organización deciden despedir a las secretarias personales y reemplazar sus funciones con PCs conectadas en red. Esta decisión tiene la posibilidad de afectar significativamente no sólo a las secretarias y a los administradores, sino también a todos los miembros de la organización que hayan establecido redes de comunicaciones con las recién despedidas secretarias. Todos los sistemas procesan información proveniente de sus entornos. Por naturaleza, los procesos cambian o transforman esa información entrante en información de salida. Cuando examine un sistema, revise lo que se esté cambiando o procesando. Si nada se está cambiando, quizá lo que esté analizando no sea un proceso. Entre los procesos típicos de un sistema están la revisión, la actualización y la impresión. Otro aspecto que hace a las organizaciones parecidas a los sistemas es que todos los sistemas están delimitados por fronteras que los separan de sus entornos. Las fronteras de una organización existen en un continuo que va de extremadamente permeable a casi impermeable. Para continuar evolucionando y sobrevivir, las organizaciones deben tener primero la capacidad de allegarse gente, materias primas e información al interior de sus fronteras (entradas), y después, de intercambiar sus productos, servicios o información terminados con el mundo exterior (salidas). La retroalimentación constituye un mecanismo de control del sistema. Como sistemas, todas las organizaciones utilizan la planeación y el control para administrar con eficacia sus recursos. La figura 2.1 muestra cómo las salidas del sistema se emplean como retroalimentación para comparar el desempeño con las metas. A su vez, esta comparación es útil para que los administradores establezcan metas más específicas como entradas. Un ejemplo es una compañía que fabrica trajes deportivos con franjas rojas, blancas y azules, al igual que trajes en un solo color, gris metálico. La compañía se percata de que un año después de las olimpiadas se venden muy pocos trajes de franjas. Los gerentes de producción utilizan esta información como retroalimentación para decidir la cantidad que deben producir de cada color. En este ejemplo la retroalimentación es útil en la planeación y el control. Sin embargo, el sistema ideal es aquel que se corrige y regula por sí mismo de tal manera que no es necesario tomar decisiones sobre situaciones comunes. Un ejemplo lo constituye un sistema de información computarizado para planear la producción que toma en cuenta la demanda actual y la proyectada y propone una solución como salida. Un fabricante de ropa italiano que vende sus productos en Estados Unidos tiene un sistema similar a éste. La compañía fabrica la mayoría de sus suéteres en color blanco; averigua, mediante su sistema de información de inventarios computarizado, qué colores se venden más, y a continuación tiñe los suéteres en estos colores inmediatamente antes de embarcarlos.

FIGURA 2.1 Las salidas del sistema sirven como retroalimentación que compara el desempeño con las metas.

Metas

Entradas

Salidas Sistema

28

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

La retroalimentación llega desde el interior de la organización y desde los entornos que la circundan. Cualquier cosa externa a las fronteras de la organización se considera como un entorno. Numerosos entornos, con diversos grados de estabilidad, constituyen el medio en el cual se desenvuelve la organización. Entre estos entornos se encuentran: (1) el entorno de la comunidad en la cual se localiza físicamente la organización, conformado por el tamaño de su población y su perfil demográfico, el cual incluye factores como la educación y el ingreso promedio; (2) el entorno económico, influido por factores de mercado, como la competencia, y (3) el entorno político, controlado por los gobiernos estatales y locales. Aunque la organización puede realizar su planeación tomando en cuenta los cambios en el estado del entorno, con frecuencia no puede controlar directamente estos cambios. El concepto de apertura o cerrazón interna de las organizaciones es similar y está relacionado con la permeabilidad externa de las fronteras. La apertura y la cerrazón también existen en un continuo, ya que no hay una organización que sea absolutamente abierta o completamente cerrada. La apertura se refiere al flujo de información libre dentro de la organización. Los subsistemas como los departamentos creativos o de arte con frecuencia se representan como abiertos, con un flujo de ideas libre entre los participantes y muy pocas restricciones acerca de quién obtiene qué información en un momento determinado cuando un proyecto creativo está en sus etapas tempranas. En el extremo opuesto del continuo podría encontrarse una unidad del departamento de defensa asignada a un proyecto ultra secreto relacionado con la seguridad nacional. Cada persona necesita autorización, la información oportuna es una necesidad y el acceso a la información se realiza sobre la base de “necesidad de saber”. Este tipo de unidad está regida por una gran cantidad de reglas. Al utilizar y enlazar sistemas para comprender las organizaciones podemos entender el concepto de sistemas compuestos de subsistemas; su interrelación e interdependencia; la existencia de fronteras que permiten o impiden la interacción entre diversos departamentos y elementos de otros subsistemas y entornos; y la existencia de entornos internos caracterizados por grados de apertura y cerrazón, que pueden variar entre departamentos, unidades o incluso proyectos.

ORGANIZACIONES VIRTUALES Y EQUIPOS VIRTUALES No todas las organizaciones o partes de éstas se encuentran visibles en una ubicación física. En la actualidad, organizaciones completas o unidades de éstas pueden tener componentes virtuales que les permiten cambiar su configuración para adaptarse a proyectos cambiantes o a demandas del mercado. Las empresas virtuales utilizan redes de computadoras y tecnología de telecomunicaciones para reunir, por medios electrónicos, a individuos con habilidades específicas con el propósito de que trabajen en proyectos que no se localizan físicamente en el mismo lugar. La tecnología de información hace posible la coordinación de los miembros de estos equipos remotos. Con frecuencia, en organizaciones recién establecidas, surgen repentinamente equipos virtuales; sin embargo, en algunos casos, las organizaciones de trabajadores remotos han sido capaces de triunfar sin las inversiones tradicionales en infraestructura. Entre los beneficios potenciales para las organizaciones virtuales se encuentra la posibilidad de reducir costos derivados de instalaciones físicas, una respuesta más rápida a las necesidades de sus clientes y contribuir a que sus empleados virtuales satisfagan sus compromisos familiares con sus hijos o sus padres ancianos. Por cierto, aún está abierto a investigación y discusión qué tan importante será cumplir las necesidades sociales de los trabajadores virtuales. Un ejemplo de una necesidad de identificación tangible con una cultura es el que surge entre los estudiantes de una universidad virtual en línea, sin campus físico (ni equipos deportivos), que insisten en adquirir artículos como sudaderas, tazas para el café y banderines con el logotipo de la universidad virtual. Estos artículos son objetos culturales significativos que las universidades físicas han ofrecido durante mucho tiempo. EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN

CAPÍTULO 2

29

OPORTUNIDAD DE CONSULTORÍA 2.1

LA E DE VITAMINA E SIGNIFICA COMERCIO ELECTRÓNICO “Nuestras tiendas minoristas y nuestra división de ventas por correo son bastante prósperas”, dice Bill Berry, uno de los propietarios de Marathon Vitamin Shops, “pero para luchar contra la competencia debemos establecer un sitio Web de comercio electrónico”. Su padre, y copropietario, exclama: “Estoy de acuerdo, pero, ¿por dónde empezamos?” Por supuesto, el mayor de los Berry sabía que no se trataba tan sólo de establecer un sitio Web y pedirle a los clientes que envien sus pedidos por correo electrónico a la tienda minorista. Identificó ocho partes diferentes para el comercio electrónico y se dio cuenta de que, en conjunto, conformaban un sistema más grande. En otras palabras, todas las partes tenían que funcionar juntas para crear un paquete sólido. La siguiente es su lista de elementos esenciales para el comercio electrónico: 1. Atraer a los clientes a un sitio Web de comercio electrónico. 2. Proporcionar información a los clientes acerca de los productos y servicios que se ofrecen. 3. Dar a los clientes la facilidad de personalizar productos en línea. 4. Completar las transacciones con los clientes. 5. Aceptar diversas formas de pago de los clientes.

6. Dar a los clientes apoyo técnico a través del sitio Web, posterior a la venta. 7. Organizar la entrega de productos y servicios. 8. Personalizar la apariencia del sitio Web para los diversos clientes. Bill Berry leyó la lista y la observó durante unos momentos. “Es evidente que el comercio electrónico es más complejo de lo que creí”, dijo. Usted puede ayudar de las siguientes maneras a los propietarios de Marathon Vitamin Shops: 1. Elabore una lista de los elementos que se interrelacionen o sean interdependientes. 2. Determine las fronteras del sistema. Es decir, redacte un párrafo con su opinión sobre cuáles elementos son críticos para Marathon Vitamin Shops y cuáles se pueden dejar para una posterior exploración. 3. Sugiera cuáles elementos deberían manejarse de manera interna y cuáles podrían subcontratarse a otra empresa que tenga mejores recursos para manejarlos. Justifique sus sugerencias en dos párrafos, uno para las tareas internas y otro para las subcontratadas.

En la actualidad, muchos equipos de análisis y diseño de sistemas tienen capacidad para trabajar de manera virtual, y de hecho, muchos de ellos abrieron el camino para que otros tipos de empleados imitaran esta forma virtual de realizar el trabajo. Algunas aplicaciones dan la facilidad al analista que ofrece asistencia técnica a través de la Web para “ver” la configuración de software y hardware del usuario que solicita la asistencia, generando de esta manera un equipo virtual temporal integrado por el analista y el usuario.

ADOPCIÓN DE UNA PERSPECTIVA DE SISTEMAS El hecho de adoptar una perspectiva de sistemas da a los analistas de sistemas la oportunidad de empezar a clarificar y comprender los diversos aspectos con los que se enfrentarán. Es importante que los miembros de los subsistemas se den cuenta de que su trabajo está interrelacionado. En la figura 2.2 se puede apreciar que las salidas de los subsistemas de producción sirven como entradas para marketing, y que las salidas de marketing son nuevas entradas para producción. Ninguno de los subsistemas podría alcanzar cabalmente sus metas sin el otro. Los problemas surgen cuando cada gerente tiene un concepto diferente de la importancia de su subsistema funcional. En la figura 2.3 se ilustra cómo la perspectiva individual del gerente de marketing concibe que este departamento es el motor del negocio, y que las demás áreas funcionales están interrelacionadas pero no tienen una importancia fundamental. De igual manera, la perspectiva de un gerente de producción coloca a este departamento como el centro del negocio, y que impulsa a las demás áreas funcionales. La relativa importancia de las áreas funcionales tal como la ven los gerentes desde su perspectiva individual cobra mayor relevancia cuando éstos ascienden en la jerarquía y llegan al estatus de gerentes estratégicos. En esa posición pueden provocar problemas si le dan mayor importancia a los requerimientos de información de sus áreas funcionales que a las necesidades más amplias que tienen como gerentes estratégicos. Por ejemplo, si un gerente de producción es ascendido pero continúa dedicando mucho tiempo a la calendarización de la producción y al desempeño de los trabajadores, los aspec-

30

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

FIGURA 2.2

Las salidas de san marketing pa as ad tr en o com a producción.

Las salidas de un departamento sirven como entradas para otro, de tal manera que estos subsistemas se interrelacionan.

Marketing Producción

de Las salidas pasan producción as como entrad . a marketing

tos más amplios de la elaboración de pronósticos y políticas pueden verse afectados. Esta tendencia es peligrosa en toda clase de negocios: en aquellos en que los ingenieros ascienden poco a poco hasta la administración de empresas aeroespaciales, los profesores universitarios que pasan de algún departamento para convertirse en decanos o los programadores que llegan a ejecutivos de empresas de software. Con frecuencia, su estrecha visión provoca problemas al analista de sistemas que se esfuerza por separar los requerimientos de información reales de los deseos de un tipo particular de información.

stribuci

arketin

g

M

Compras

ón

Di

ón

P

FIGURA 2.3 roducci

Esta ilustración de las perspectivas personales de los gerentes de áreas funcionales muestra que ellos consideran que sus áreas son la parte fundamental de la organización.

anza Fin s

i nan z

as

F

Forma en la que un gerente de marketing ve a la organización

stribuci

ón

Di

Compras

arketi

ng

M

duc Pro ción

Forma en la que un gerente de producción ve a la organización

EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN

CAPÍTULO 2

31

PLANEACIÓN DE RECURSOS EMPRESARIALES: LA ORGANIZACIÓN COMO SISTEMA Un sistema de planeación de recursos empresariales (ERP, Enterprise Resource Planning) es un término que se emplea para describir un sistema de información organizacional (empresarial) integrado. El ERP es software que ayuda al flujo de información entre las áreas funcionales de la organización. Es un sistema personalizado que, en lugar de que se desarrolle de manera interna, generalmente se compra a alguna de las compañías conocidas que desarrollan software, como SAP, Oracle, PeopleSoft o J.D. Edwards. Después de la compra, el producto se personaliza para ajustarlo a los requerimientos de una compañía en particular. Es común que el fabricante requiera un compromiso por parte de la organización, como usuarios especializados o capacitación de los analistas. Muchos paquetes ERP están diseñados para ejecutarse en la Web. El ERP evolucionó a partir de la planeación de requerimientos de materiales (MRP, Materials Requirements Planning), los sistemas de información diseñados para mejorar la manufactura en general y el ensamble en particular. En la actualidad, los sistemas ERP incluyen componentes de manufactura y en consecuencia son útiles en la planeación de la capacidad, la programación de la producción y la elaboración de pronósticos. Aparte de la manufactura (y su contraparte de servicios), el ERP incluye planeación de ventas y operaciones, distribución y manejo de la cadena de abastecimiento. Por lo tanto, influye significativamente en todas las áreas de la organización, como contabilidad, finanzas, administración, marketing y los sistemas de información. La implementación de una solución ERP puede resultar desgastante porque es difícil analizar un sistema en uso y después ajustar el modelo ERP a dicho sistema. Además, las compañías por lo general diseñan sus procesos de negocios antes de implementar el ERP. Esta labor de rediseño se denomina reingeniería de los procesos de negocios (BRP, Business Process Reengineering). Lamentablemente, con frecuencia este proceso se realiza de prisa y el modelo de negocios propuesto no siempre coincide con la funcionalidad del ERP. Los resultados son personalizaciones adicionales, periodos de implementación extendidos, costos más altos y, con frecuencia, la pérdida de confianza del usuario. Los analistas deben tener presente la magnitud del problema que enfrentan al implementar paquetes ERP.

DESCRIPCIÓN GRÁFICA DE SISTEMAS Un sistema, o subsistema, tal como existe dentro de una organización, se puede describir gráficamente de varias maneras. Los diversos modelos gráficos muestran las fronteras y la información que se utiliza en el sistema.

SISTEMAS Y EL DIAGRAMA DE FLUJO DE DATOS DE CONTEXTO El primer modelo es el diagrama de flujo de datos de contexto (también denominado modelo del entorno). Los diagramas de flujo se enfocan en el flujo de datos que entran y salen del sistema y en el procesamiento de los datos. Estos componentes básicos de cada programa de cómputo se pueden describir en detalle y utilizar para analizar la precisión y plenitud del sistema. Como se muestra en la figura 2.4, el diagrama de flujo de datos de contexto sólo emplea tres símbolos: (1) un rectángulo con esquinas redondeadas, (2) un cuadrado con dos bordes sombreados y (3) una flecha. Los procesos transforman los datos entrantes en información de salida, y el nivel de contenido sólo tiene un proceso, que representa el sistema completo. La entidad externa representa cualquier entidad que proporciona o recibe información del sistema pero que no forma parte del mismo. La entidad podría ser una persona, un grupo de personas, un puesto o departamento de una corporación, u otros sistemas. Las líneas que conectan a las entidades externas con el proceso se denominan flujos de datos, y representan datos. En la figura 2.5 se ofrece un ejemplo de diagrama de flujo de datos de contexto, que representa los elementos más básicos de un sistema de reservaciones de una aerolínea. El pasajero (una entidad) llena una solicitud de viaje (el flujo de datos). El diagrama de contexto no muestra suficientes detalles para indicar con exactitud lo que sucede (ése no es su propósito), pero podemos apreciar que las preferencias del pasajero y los vuelos disponibles se

32

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

FIGURA 2.4 Los símbolos básicos de un diagrama de flujo.

Un proceso denota la ejecución de alguna acción o grupo de acciones.

Una entidad es una persona, un grupo, un departamento o cualquier sistema que recibe o emite información o datos.

Un flujo de datos muestra que la información se emite o se recibe de un proceso.

envían al agente de viajes, quien a su vez envía información sobre la venta de boletos al proceso. También podemos ver que la reservación del pasajero se envía a la aerolínea. En el capítulo 7 veremos que un flujo de datos contiene una cantidad considerable de información. Por ejemplo, la reservación del pasajero contiene el nombre de éste, la aerolínea, el (los) número(s) de vuelo, la (las) fecha(s) de viaje, el precio, el asiento preferido, etc. Sin embargo, por el momento únicamente nos interesa analizar la manera en que el diagrama de contexto define las fronteras del sistema. En el ejemplo anterior, tan sólo las reservaciones forman parte del proceso. Algunas decisiones relacionadas que podría tomar la aerolínea (como la compra de aviones, el cambio de programación de vuelos, la fijación de precios) no forman parte de este sistema.

SISTEMAS Y EL MODELO DE ENTIDAD-RELACIÓN Una forma en que un analista de sistemas puede definir fronteras de sistema apropiadas es mediante el uso de un modelo de entidad-relación. Los elementos que conforman un sis-

Preferencias y vuelos disponibles Pasajero

FIGURA 2.5 Agente de viajes

Un diagrama de flujo de datos de contexto para un sistema de reservaciones de una aerolínea.

0

Solicitud de vuelo

Sistema de reservaciones de la aerolínea

Información sobre la venta de boletos

Reservación del pasajero

Aerolínea

EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN

CAPÍTULO 2

33

FIGURA 2.6

Empleado

Un diagrama de entidad-relación que muestra una relación uno a uno. Una SIÓN EN ICA EXT EFÓN tra L E T regis e de . se ombr ADO a n MPLE E un

e r eg ra a ombre a a de

s

s

ist

n

e si

E e ele

Un ADO PLE ado M E asign s e a una IÓN . S EN ICA EXT EFÓN TEL

gna

xt nsión

t

fónic

a

tema organizacional se pueden denominar entidades. Una entidad podría ser una persona, un lugar o una cosa, como el pasajero de una aerolínea, un destino o un avión. Asimismo, una entidad podría ser un evento, como un fin de mes, un periodo de ventas o la descompostura de una máquina. Una relación es la asociación que describe la interacción entre las entidades. Existen diversas convenciones para dibujar diagramas de entidad relación, o E-R (con nombres como notación de pata de cuervo, Flecha o Bachman). En este libro utilizamos la notación de pata de cuervo. Por el momento, daremos por sentado que una entidad es un rectángulo plano. La figura 2.6 muestra un diagrama de entidad-relación sencillo. Dos entidades se conectan mediante una línea. En este ejemplo, los extremos de la línea se marcan con dos líneas paralelas cortas (||), lo cual denota que esta relación es de uno a uno. De esta manera, exactamente un empleado es asignado a una extensión telefónica. Nadie más comparte la extensión telefónica en esta oficina. Las flechas no forman parte del diagrama de entidad-relación. Su propósito es demostrar cómo se debe leer el diagrama de entidad-relación. La frase del lado derecho de la línea se lee de la siguiente manera, de arriba hacia abajo: “Un EMPLEADO es asignado a una EX-

FIGURA 2.7 S DO LEA e un P M d s E bros TO. N cho Mu n miem TAME so PAR DE

Diagrama de entidad-relación que muestra una relación muchos a uno.

Empleado

TO EN TAM chos R PA mu DE S. e Un ntien ADO o LE c P EM

34

PARTE I

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS

e m em ro e s

i

b

contiene

d

Departamento

TENSIÓN TELEFÓNICA”. Del lado izquierdo, al leer de abajo hacia arriba, la flecha dice: “Una EXTENSIÓN TELEFÓNICA se registra a nombre de un EMPLEADO”. De igual manera, en la figura 2.7 se muestra otra relación. La notación de pata de cuer—+) es evidente en este diagrama, que ilustra una relación muchos a uno. Al leer de izvo (> quierda a derecha, la flecha significa: “Muchos EMPLEADOS son miembros de un DEPARTAMENTO”. Al leer de derecha a izquierda, indica: “Un DEPARTAMENTO contiene muchos EMPLEADOS”. Observe que cuando se presenta una relación muchos a uno, la gramática cambia de “es” a “son”, aun cuando el singular “es” se escribe sobre la línea. La pata de cuervo y la línea paralela corta no significan literalmente que este extremo de la relación debe ser un “muchos” obligatorio. Más bien, implica que este extremo puede ser de uno o de muchos. En la figura 2.8 se dan más detalles de este esquema, con varias relaciones comunes entre entidades. La primera, “Un EMPLEADO es asignado a una OFICINA”, es una relación uno a uno. La segunda es una relación uno a muchos. “Un AVIÓN DE CARGA dará servicio a uno o más CENTROs DE DISTRIBUCIÓN”. El tercero es ligeramente distinto porque tiene un círculo en uno de sus extremos. Se puede leer como “Un ANALISTA DE SISTEMAS podría ser asignado a MUCHOS PROYECTOS”, lo que significa que el analista podría ser asignado a ningún proyecto [eso es lo que significa el círculo (O), de cero], a uno o a muchos proyectos. De igual manera, el círculo (O) indica que en la relación próxima cabe la posibilidad de que no haya nada. Por lo tanto, podemos leer de la siguiente manera: “Una MÁQUINA podría o no recibir MANTENIMIENTO PROGRAMADO”. Observe que en

Empleado

es asignado a es ocupada por

FIGURA 2.8 Oficina

craft Avión de carga

dará servicio a recibirá servicio de

Centro de distribución

Analista de sistemas

es asignado a será desarrollado por

Proyecto

Máquina

recibe se da a

Mantenimiento programado

Agente de ventas

es asignado a es llamado por

Cliente

Oficina en casa

tiene es asignado a

Empleado

Pasajero

vuela a será visitado por

Destino

EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIÓN

Ejemplos de diversos tipos de relaciones en diagramas E-R.

CAPÍTULO 2

35

la línea se escribe “recibe”, pero las marcas al final de la línea indican que en realidad no se recibe mantenimiento (O) o sí se recibe mantenimiento (|). La siguiente relación indica: “Uno o muchos AGENTES DE VENTAS (plural de AGENTE DE VENTAS) son asignados a uno o muchos CLIENTEs”. Es la clásica relación muchos a muchos. La siguiente relación se puede leer así: “La OFICINA EN CASA puede tener uno o muchos EMPLEADOS”, o “Uno o muchos EMPLEADOs podrían ser o no asignados a la OFICINA EN CASA”. Una vez más, la | y el O juntos implican un caso booleano, es decir, uno o cero. La última relación que se muestra puede leerse como: “Muchos PASAJEROs vuelan a 0 dido 8 Cantidad de B MM/DD/AA l pago ante 9 AA rior Cantidad to D Formato: 9 tal por paga 5 (7) V99 r Comentario D Formato: 9 9 (7) V99 D Formato: 9 60 (7) V99 Comentario Imprima un B s a página pa ra cada clie en la página nte. Si hay , continúe más artícu en una segu los de los qu nda página . e caben

260

PARTE III

EL PROCESO DE ANÁLISIS

OPORTUNIDAD DE CONSULTORÍA 8.1

¿QUIERE HACERLA EN GRANDE EN EL TEATRO? ¡MEJORE SU DICCIÓN(ARIO)! Cuando usted cruza la puerta de Merman’s, Annie Oaklea lo saluda calurosamente: “Estoy encantada con el trabajo que hiciste con los diagramas de flujo de datos. Me gustaría que siguieras desempeñando el rol de analista de sistemas de Merman’s y ver si con el tiempo puedes tejer un nuevo sistema de información para nuestro inventario de disfraces. Desgraciadamente, algunos de los términos que utilizas no concuerdan muy bien con el lenguaje de Shakespeare. Supongo que es cuestión de resolver ese pequeño problema de traducción”. Aprovechando los elogios iniciales de Annie, usted no se desanima por las últimas palabras de ella. Usted considera que un diccionario de datos basado en los diagramas de flujo de datos del proceso de renta y devolución, podrían resultar un “éxito de taquilla”.

Empiece por redactar entradas para un sistema manual con tanto detalle como sea posible. Prepare dos entradas de proceso de datos, dos entradas de flujo de datos, dos entradas de almacén de datos, una entrada de estructura de datos y cuatro entradas de elementos de datos usando los formatos de este capítulo. La descripción precisa de los elementos de datos interrelacionados dará como resultado “buenos comentarios de los críticos de obras teatrales”. (Refiérase a la Oportunidad de consultoría 7.1.)

2. El contacto del usuario responsable para la clarificación de detalles adicionales, retro-

alimentación del diseño y aprobación final. 3. Si los datos son de entrada o salida. 4. El formato del flujo de datos. En la fase del diseño lógico, el formato podría ser inde-

terminado. 5. Elementos que indican la secuencia de los datos en un informe o pantalla (quizás en

columnas). 6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o derivados y

sus criterios de edición. Una vez que se haya completado el formulario, cada elemento se debe analizar para determinar si se repite, si es opcional o si se excluye mutuamente con otro elemento. Los elementos que hay en un grupo o que regularmente se combinan con algunos otros elementos en muchas estructuras se deben agrupar en un registro estructural. Estas consideraciones se pueden ver en el formulario de análisis de entrada y salida terminado para la División de Catálogos de World’s Trend (véase la figura 8.14). En este ejemplo de ESTADO DE FACTURACIÓN DEL CLIENTE, el NOMBRE DEL CLIENTE, APELLIDO DEL CLIENTE e INICIAL DEL SEGUNDO NOMBRE DEL CLIENTE se deben agrupar en un registro estructural.

DESARROLLO DE ALMACENES DE DATOS Otra actividad relativa a la creación del diccionario de datos es el desarrollo de los almacenes de datos. Hasta ahora, hemos determinado qué datos necesitan fluir de un proceso a otro. Esta información se describe en estructuras de datos. Sin embargo, la información podría estar almacenada en diversos lugares, y el almacén de datos podría ser diferente en cada lugar. Mientras que los flujos de datos representan datos en movimiento, los almacenes de datos representan datos en reposo. Por ejemplo, cuando un pedido llega a World’s Trend (véase la figura 8.15), contiene en su mayor parte información temporal, es decir, la información necesaria para surtir ese pedido particular, pero parte de la información podría estar almacenada permanentemente. Ejemplos de esta última incluyen información de los clientes (para poder enviarles catálogos) e información de los artículos (debido a que dichos artículos aparecerán en muchos otros pedidos de clientes). Los almacenes de datos contienen información de una naturaleza permanente o semipermanente (temporal). NÚMERO DEL ARTÍCULO, DESCRIPCIÓN y COSTO DEL ARTÍCULO son ejemplos de información relativamente permanente. Al igual que la TASA ANÁLISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS

CAPÍTULO 8

261

FIGURA 8.15 Almacenes de datos derivados de un pedido pendiente de la División de Catálogos de World’s Trend.

Maestro d

e clientes =

Maestro d

e artículos

Registro d

=

Número del cliente + Nombre del cliente + Dirección + Teléfono + Número de tarjeta de cr édito corp Fecha de ex orativa + piración Número del artículo + Precio + Cantidad d isponible

el pedido =

Artículos d isp para el ped onibles ido =

Forma de p

ago =

Tipo de tarj eta de crédito =

Número del cliente + Número del catálogo + Fecha del p edido + {Artículos disponible s para el p Total de la edido} + s mercancí as + (Impuesto )+ Gastos de envío + Total del p edido + Forma de p ago + (Tipo de ta rjeta de créd ito) + (Número d e tarjeta de crédito) + (Fecha de expiración )

Número del artículo + Cantidad p edida + Cantidad en viada + Precio actu al [Cheque C rédito Giro postal

]

[World’s Tr en

d Americ an

Express M asterCard Visa]

DE IMPUESTO. Sin embargo, cuando el COSTO DEL ARTÍCULO se multiplica por la TASA DE IMPUESTO, el IMPUESTO COBRADO se calcula (o deriva). Los valores derivados no se tienen que almacenar en un almacén de datos. Cuando los almacenes de datos se crean para un solo informe o pantalla, nos referimos a ellos como “vistas del usuario”, porque representan la manera en que el usuario quiere ver la información.

USO DEL DICCIONARIO DE DATOS El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la organización, se agregan elementos de datos al diccionario de datos. Por otro lado, el diccionario de datos no es un fin en sí mismo y nunca debe serlo. Para evitar desviarse del propósito principal con la construcción de un diccionario de datos completo, el analista de sistemas debe verlo como una actividad paralela al análisis y diseño de sistemas. Para maximizar su potencial, el diccionario de datos se debe vincular a varios programas de sistemas para que cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo mismo en la base de datos. El diccionario de datos se vuelve simplemente una curiosidad histórica si no se mantiene actualizado. El diccionario de datos se podría usar para crear pantallas, informes y formularios. Por ejemplo, examine la estructura de datos para el LISTADO DE SELECCIÓN DE PEDIDOS

262

PARTE III

EL PROCESO DE ANÁLISIS

FIGURA 8.16

Listado de selecció n de pedidos =

Selección de artícu los para el pedido =

Nombre del clien

te =

Dirección =

Teléfono =

Número del pedid o+ Fecha del pedido + Número del clien te + Nombre del clien te + Dirección del clien te + Teléfono del clien te + {Selección de art ículos para el pedid o} + Número de artícu los

Estructura de datos para un listado de selección de pedidos de la División de Catálogos de World’s Trend.

Número del artícu lo + Descripción del art ículo + Descripción de la talla + Descripción del co lor + Sección del almac én + Número de estan te + Cantidad pedida + Cantidad seleccio nada Nombre + (Inicial del segund o nombre) + Apellido

Calle + (Departamento) + Ciudad + Estado + Código postal + (Expansión del có digo postal) + (País) Código de área + Número local

de World’s Trend en la figura 8.16. Debido a que se han definido los elementos necesarios y sus longitudes, el proceso de crear documentos físicos consiste en organizar los elementos de una forma agradable y funcional siguiendo lineamientos de diseño y el sentido común. Los grupos de repetición se convierten en columnas y los registros estructurales se agrupan en la pantalla, informe o formulario. En la figura 8.17 se muestra el diseño del informe para el LISTADO DE SELECCIÓN DE PEDIDOS de World’s Trend. Observe que NOMBRE y APELLIDO se agrupan en NOMBRE y que CANTIDAD (SELECCIONADA y PEDIDA), SECCIÓN, NÚMERO DE ESTANTE, NÚMERO DEL ARTÍCULO, DESCRIPCIÓN DEL ARTÍCULO, TAMAÑO y COLOR forman una serie de columnas, debido a que son los elementos de repetición. La estructura de datos y los elementos de un almacén de datos se usan normalmente para generar el código fuente correspondiente en lenguaje de computadora que posteriormente se integra en los programas de cómputo. El diccionario de datos se podría usar en conjunto con un diagrama de flujo de datos para analizar el diseño del sistema, detectar fallas y áreas que se necesitan aclarar. Algunas consideraciones son: 1. Todos los elementos base en un flujo de datos de salida deben estar presentes en un flujo de datos de entrada en el proceso que produce la salida. Los elementos base se teclean y nunca deben ser creados por un proceso. ANÁLISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS

CAPÍTULO 8

263

Número del pedido: Número del cliente:

World’s Trend Formulario de selecc

ión de pedidos

999999 999999

Fecha del pedido Z9/ 99/9999

Nombre: XX XX XX XX XX XX XX XX XX XX XX XX XX XX Calle: XX X XX XX XX XX XX XX XX XX XX XX XX XX XX XX Departamento: XX XX XX XX Ciudad, estado, cód. postal: XX XX XX XX XX XX XX XX XX XX País: XX XX XX XX , XX 999 99-ZZZ Z XX XX XX XX XX XX XX XX XX XX XX XX XX XX Teléfono: (99 9) 999 -99 99

---- Cantidad ---Seleccionada Ped

ida

ZZZZ9 ZZZZ9 ZZZZ9 ZZZZ9 ZZZZ9 ZZZZ9 ZZZZ9 ZZZZ9 Número de artículos:

Sección

Número Número de estante del artícul o Descripción del artícul

o

XX XX X XX XX X XX XX X XX XX X XX XX X XX XX X XX XX X XX XX X

99999 99999 99999 99999 99999 99999 99999 99999

999999 999999 999999 999999 999999 999999 999 999 999 999

XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

Z9

Talla XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

Color XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

FIGURA 8.17 Listado de selección de pedidos creado a partir del diccionario de datos.

2. Un elemento derivado debe ser creado por un proceso y debe ser la salida de por lo me-

nos un proceso en el cual no es entrada. 3. Los elementos que están presentes en un flujo de datos que entran o salen de un almacén

de datos se deben contener en el almacén de datos. Si se empieza temprano, un diccionario de datos puede ahorrar bastante tiempo en las fases de análisis y diseño. El diccionario de datos es la fuente común en la organización para contestar preguntas y arreglar controversias acerca de cualquier aspecto de la definición de los datos. Un diccionario de datos actualizado puede servir como una referencia excelente para los esfuerzos de mantenimiento en los sistemas desconocidos. Los diccionarios de datos automatizados pueden servir de referencia para las personas y los programas.

USO DE LOS DICCIONARIOS DE DATOS PARA CREAR XML El Lenguaje de Marcación Extensible (XML) es un lenguaje que se puede usar para intercambiar datos entre los negocios. Es similar a HTML, el lenguaje de marcación usado para crear páginas Web, pero es más poderoso. HTML se ocupa principalmente de dar formato a un documento; XML aborda el problema de compartir datos cuando los usuarios tienen diferentes sistemas de cómputo y software. Si todos usáramos el mismo software, XML no sería tan necesario. Una vez que se ha creado un documento de XML, los datos se podrían transformar en varios formatos de salida diferentes y desplegarse en muchas formas distintas, incluyendo impresiones, páginas Web, salida para un dispositivo portátil y archivos de formato de documento portable (PDF). Por tanto, los datos, que son el contenido del documento, están separados del formato de salida. El contenido de XML se define una vez como datos y después se transforma cuantas veces sea necesario.

264

PARTE III

EL PROCESO DE ANÁLISIS

La ventaja de usar un documento de XML es que el analista podría seleccionar sólo los datos que un departamento interno o un socio externo necesitan para funcionar. Esto garantiza la confidencialidad de los datos. Por ejemplo, una compañía transportadora podría recibir sólo el nombre del cliente, su dirección, el número del artículo y la cantidad por enviar, pero no información de la tarjeta de crédito u otros datos financieros. Este enfoque eficaz también reduce la sobrecarga de información. Por lo tanto, XML es una forma de definir, ordenar, filtrar y traducir datos en un lenguaje universal de datos que cualquiera puede usar. XML se podría crear desde bases de datos, un formulario, programas de software o tal vez teclearse directamente en un documento, editor de texto o en un programa de captura de XML. El diccionario de datos es un punto de partida ideal para desarrollar contenido de XML. La clave para usar XML es crear una definición estándar de los datos. Esto se logra utilizando un conjunto de etiquetas, o nombres de datos, que se incluyen antes y después de cada elemento de datos o estructura. Las etiquetas son los metadatos, o datos sobre los datos. Los datos se podrían subdividir en elementos más pequeños y estructuras hasta que todos los elementos se hayan definido. La figura 8.18 ilustra un diccionario de datos que contiene información del cliente, del pedido y del pago. Cada cliente podría hacer muchos pedidos. La estructura se define en las dos columnas izquierdas y el código de XML aparece en la columna derecha. Como puede ver, CLIENTE está conformado por NÚMERO, NOMBRE, DIRECCIÓN, SALDO ACTUAL, varias entradas de INFORMACIÓN DE PEDIDO y un PAGO. Algunas de éstas son estructuras que se subdividen aún más. El documento de XML tiende a reflejar la estructura del diccionario de datos. La primera entrada (aparte de la línea de XML que identifica el documento) es , la cual define toda la colección de información del cliente. Los símbolos de menor que () se usan para identificar los nombres de la etiqueta (similar a HTML). La última línea del documento de XML es una etiqueta de cierre, , que significa el final de la información del cliente. La etiqueta de número, , se define a continuación porque es la primera entrada en el diccionario de datos, seguida por el número real y la etiqueta de cierre, . NOMBRE es una estructura que consiste en APELLIDO, NOMBRE y una INICIAL DEL SEGUNDO NOMBRE opcional. En el documento de XML, esta estructura empieza con seguida por , e . Debido a que no se permiten espacios en los nombres de etiquetas de XML, por lo regular se usa un guión bajo para separar las palabras. La etiqueta de cierre significa el final del grupo de elementos. La sangría se usa para mostrar qué estructuras contienen elementos. Observe que es similar a , pero cuando llegamos a hay una gran diferencia. Hay múltiples entradas para , cada una contiene , , y . Debido a que el pago se hace ya sea mediante cheque o tarjeta de crédito, sólo uno de éstos podría estar presentar. En nuestro ejemplo, el pago se realiza con cheque. Con frecuencia la estructura de elementos del contenido de XML se establece mediante una definición del tipo de documento (DTD). Una DTD se usa para determinar si el contenido del documento de XML es válido; es decir, si se apega al orden y tipo de datos que se deben presentar en el documento. La DTD es fácil de crear y bien apoyada por el software estándar. Una vez que se haya completado la DTD, se podría usar para validar el documento de XML usando herramientas estándar de XML. La ventaja de usar XML para definir datos es que, en el formato de XML, los datos se almacenan en un formato de texto puro y no dependen de ningún software patentado. Los grupos u organizaciones de diferentes industrias se podrían involucrar en la definición de una estructura de XML específica de su gremio de modo que todas las partes involucradas entiendan el significado de los datos. Esto es muy importante cuando el ANÁLISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS

CAPÍTULO 8

265

Diccionario

Cliente =

Nombre =

de datos

XML

Número + Nombre + Dirección + Saldo actual + {Información del pedido} + Pago

xml version= cliente numero 5 8 /numero nombre apellido Núñez /apellido nombre Sandra /nombre inicial_segundo_nombre L /inic ial_segundo_nombre /nombre Apellido + dire ccion Nombre + calle Octavio Sentíes 4 /calle (Inicial del segundo nombre ) apartamento Interior 6 /apartam ento ciudad Distrito Federal /ciudad e s tado D F / e stado Calle + zip 9 6 /zip (Departamento) + pai s M éxico /pais Ciudad + /direccion Estado + s aldo_actual 23 45 /saldo_actu Código postal + al informacion_pedido País numero_pedido 23 /numero_pedido fecha_pedido 2 4- 8- 5 /fech a_pedido fech a _ en v io 2 4- 8- 9 /fecha_envio Número del pedido + tota l 34 5 89 /total Fecha del pedido + /informacion_ pedido Fecha de envío + info rmacion_pedido Total numero_pedido 27 /numero_pedido fecha_pedido 2 4- 8- 8 /fech fecha_envio 2 4- 8- 2 /fecha a_pedido _envio tota l 24 /total [Cheque Tarjeta de crédito] + /informacion_ pedido Fecha de pago + pago Monto del pago cheque numero_cheque 7234 /numero _cheque /cheque Número de cheque fecha_pago 2 4- 9- 4 /fecha monto_pago 585 89 /monto_ _pago pago /pago Número de tarjeta de crédito + / clien te Fecha de expiración





1




00







>




>

1









0







>

>1

.




0


0


>




>


001


00


00




0

0.00