Ld-Analisis y Diseno de Sistemas - Kendall-8va
Ld-Analisis y Diseno de Sistemas - Kendall-8va
Ld-Analisis y Diseno de Sistemas - Kendall-8va
com
ANÁLISIS Y DISEÑO
DE SISTEMAS
O C TAVA E D I C I Ó N
KENNETH E. KENDALL
JULIE E. KENDALL
Rutgers University
School of Business–Camden
Camden, New Jersey
TRADUCTOR
Alfonso Vidal Romero Elizondo
Ingeniero en Sistemas Computacionales
Tecnológico de Monterrey - Monterrey
REVISORES TÉCNICOS
Humberto Cárdenas Anaya
Departamento de Tecnologías
de Información y Computación
División de Ingeniería y Arquitectura
ITESM - Campus Estado de México
Prentice Hall
www.xlibros.com
Datos de catalogación bibliográfica
KENDALL, KENNETH E. Y KENDALL, JULIE E. A la memoria de Julia A. Kendall y de Edward J. Kendall,
Análisis y diseño de sistemas. cuyos ejemplos de vida y trabajo conjunto siempre nos han inspirado.
Octava edición
Authorized translation from the English language edition entitled Systems Analysis and Design, 8th edition, by Kenneth Kendall & Julie Kendall,
published by Pearson Education, Inc., publishing as PRENTICE HALL, INC., Copyright © 2011. All rights reserved.
ISBN 9780136089162.
Traducción autorizada de la edición en idioma inglés titulada Systems Analysis and Design, 8ª edición, por Kenneth Kendall y Julie Kendall,
publicada por Pearson Education, Inc., publicada como PRENTICE HALL, INC., Copyright © 2011. Todos los derechos reservados.
Edición en español
Editor: Luis Miguel Cruz Castillo
e-mail: luis.cruz@pearsoned.com
Editor de desarrollo: Bernardino Gutiérrez Hernández
Supervisor de producción: Rodrigo Romero Villalobos
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 recu-
peració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.
PRIMERA IMPRESIÓN
Impreso en México. Printed in Mexico.
1 2 3 4 5 6 7 8 9 0 - 13 12 11 10
Prentice Hall
es una marca de
www.xlibros.com
MARCAS REGISTRADAS
DE LAS EMPRESAS
Apple y Macintosh son marcas registradas de Apple Computer. 1Password es marca registrada de Agile Web
Solutions. Bento es marca registrada de FileMaker. Dragon NaturallySpeaking es marca registrada de Nuance.
Dreamweaver, Adobe Flash y FormFlow son marcas registradas de Adobe Systems Incorporated. DEVONagent y
DEVONthink Professional Office son marcas registradas de DEVONtechnologies. Firefox es marca registrada de
Mozilla Foundation. Freeway Pro es marca registrada de Softpress Systems. HyperCase es marca registrada
de Raymond J. Barnes, Richard L. Baskerville, Julie E. Kendall y Kenneth E. Kendall. Microsoft Windows,
Microsoft Access, Microsoft Word, Microsoft PowerPoint, Microsoft Project, Microsoft Excel y Microsoft Visio
son marcas registradas de Microsoft Corporation. OmniFocus es marca registrada de The Omni Group. OmniGraffle
y OmniPlan son marcas registradas de The Omni Group. OmniPage es marca registrada de Nuance. Palm es marca
registrada de Palm, Inc. ProModel y Service Model son marcas registradas de ProModel Corporation. Things es
marca registrada de Cultured Code. VMware Fusion es marca registrada de VMware. Visible Analyst es marca
registrada de Visible Systems Corporation. WinFax Pro y Norton Internet Security son marcas registradas de
Symantec. Yojimbo es marca registrada de Bare Bones Software. Los demás productos y nombres de empresas que
se mencionen en este libro pueden ser marcas registradas de sus respectivos propietarios. Las empresas, nombres
y/o datos utilizados en las pantallas y resultados de ejemplo son ficticios, a menos que se indique lo contrario.
www.xlibros.com
RESUMEN
DE CONTENIDO
GLOSARIO 557
ACRÓNIMOS 565
ÍNDICE 566
vi
www.xlibros.com
CONTENIDO
www.xlibros.com
viii CONTENIDO
3 ADMINISTRACIÓN DE PROYECTOS 56
Iniciación del proyecto 56
Problemas en la organización 57 / Definición del problema 57
Oportunidad de consultoría 3.1 El sonido más dulce que haya sorbido 58
Selección de proyectos 61
Determinación de la viabilidad 62
Determinar si es posible o no 62
Determinación de las necesidades de hardware y software 63
Hacer un inventario del hardware computacional 64 / Estimación de las cargas de trabajo 64 / Evaluación
del hardware computacional 65 / Adquisición del equipo computacional 66 / Evaluación de software 68
OPORTUNIDAD DE CONSULTORÍA 3.2 Veni, Vidi, Vendi (Vine, vi y vendí) 70
Identificación, pronóstico y comparación de los costos y beneficios 72
Pronósticos 72 / Identificación de los beneficios y costos 72
Oportunidad de consultoría 3.3 Vamos a ver a los magos 73
Comparación de los costos y beneficios 74
Planeación y control de actividades 77
Estimación del tiempo requerido 77
www.xlibros.com
CONTENIDO ix
www.xlibros.com
x CONTENIDO
www.xlibros.com
CONTENIDO xi
www.xlibros.com
xii CONTENIDO
www.xlibros.com
CONTENIDO xiii
www.xlibros.com
xiv CONTENIDO
www.xlibros.com
CONTENIDO xv
RESUMEN 392
EXPERIENCIA DE HYPERCASE® 12 393
PALABRAS CLAVE Y FRASES 394
PREGUNTAS DE REPASO 394
PROBLEMAS 395
PROYECTOS EN GRUPO 397
BIBLIOGRAFÍA SELECCIONADA 398
EPISODIO 12 CASO DE LA CPU Formando pantallas y visualizando formularios 399
www.xlibros.com
xvi CONTENIDO
www.xlibros.com
CONTENIDO xvii
www.xlibros.com
xviii CONTENIDO
GLOSARIO 557
ACRÓNIMOS 565
ÍNDICE 566
www.xlibros.com
PREFACIO
Las figuras tienen una apariencia estilizada para ayudar a que los estu- Cliente D1 Precios Cliente
diantes capten con mayor facilidad el tema en cuestión. Artículos por Precios
Pago
comprar Recibo
tuales están codificados por colores para que sus funciones se distingan Cliente
D1 Archivo de precios UPC D2
Archivo de trans.
temporal Cliente
claramente y los estudiantes puedan identificar sus elementos con faci- Artículos Código UPC Descripción y precios
del artículo
Artículos y
precios Artículos, precios
Efectivo,
cheque o
Recibo
a pagar y subtotales de la caja
www.xlibros.com
xx PREFACIO
NOMBRE PROY
. OAK. FC
rios mejorados permite a los analistas asegurar datos precisos y completos
# 562
POTENCIAL RENT
A
Renta Refri-
base gerado Mue- A/C Ser-
855
r bles de entrada y salida. Los formularios mejorados también ayudan a optimizar
1175/0 81299
ma renta
POTENCIAL
DEPÓ
vicios HMSR T.V. Muca- Total Segu- SITO
Lim-
A CLAVE FIRM
PRORRATEO 15.00
55 ridad pieza 31175/0
81299 31700 121.32
REGISTRO
Sólo memo
DE PAGO: Tot. los nuevos flujos de trabajo internos que se producen debido a las aplica-
910
31175/0 + 81299
+ Renta = 910
H/S dep. H/S
200 115
Imp. Días Tarifa
diaria
rent
4 30.33
1.30
Totales
5. 20
910
Fecha
Fecha Recibo Depósitos 31.63 39
venc. Pago TOTAL DE PAGO
/28 8/28 1066
10/1 10
ciones de negocio a consumidor (B2C) recién automatizadas para el comer-
TV 10/3 MO! 8 pago Núm. medioaldía renta Total Segu-
42 9/30 1031 32
/3 107503 10
/
. 202 115
Lim-
ridad pieza 31700 31175
Imp.
44.20 25
/0 81299
INICIAL REQU
Fechas Monto Otros
ERIDO:
Descr. Mont. Monto
pagado
340
1430.52
Saldo
C1H/S9-16
11/1 11
/1 10935 11 31 910 414.82 15 1430 52 restante
Cobrar 1 MES 11
Prorrateado
11/17 11
/24
/8 11200
cio electrónico en la Web.
/ 16 485.28
11/23
212.31 910
485.28
.
0
0
0
Fecha original
EDIFICIO #
en que se mudó
8-28 especial, o cuando es necesario organizar o clasificar información. También
d igual
Exp.
1 ero
1
o.
simplificar el trabaj
mayoría de los analistas encuentra que las tablas son una forma útil de or-
ganizar los números y el texto en una “instantánea” significativa.
El siguiente ejemplo de una tabla del capítulo 3 muestra la forma en que los analistas pueden refinar sus planes
de actividad para el análisis si los desglosan en tareas más pequeñas y luego
Semanas
estiman el tiempo requerido para completarlas. La filosofía subyacente de Actividad Actividad detallada requeridas
nuestro libro es que el análisis y diseño de sistemas es un proceso que inte- Recopilación de datos Realizar entrevistas
Administrar cuestionarios
3
4
Leer informes de la compañía 4
gra el uso de muchas herramientas con los talentos únicos del analista de Introducir el prototipo
Observar las reacciones al prototipo
5
3
sistemas para mejorar de manera sistemática la actividad comercial, a tra- Análisis de flujo de datos y decisiones Analizar el flujo de datos 8
vés de la implementación o modificación de los sistemas de información Preparación de la propuesta Realizar el análisis de costo-beneficio
Preparar la propuesta
3
2
Presentar la propuesta 2
computarizados. Los analistas de sistemas pueden mejorar en su trabajo al Descom ués
éstos poner y desp el
asumir nuevos retos de TI y mantenerse actualizados en su profesión me- in
aún m cluso
ás
ar
estim requerido.
tiempo
Parte I:
Fundamentos del
análisis de sistemas
Parte II:
Parte V: Análisis de requerimientos
Aseguramiento de de información
calidad e implementación
www.xlibros.com
PREFACIO xxi
Por lo general, el análisis y diseño de sistemas se enseña en uno o dos semestres; nuestro libro se puede utilizar en
cualquiera de las dos situaciones. El texto es apropiado para los planes de estudios de licenciatura (de dos o cuatro
años) en carreras universitarias de cuatro años, escuelas de graduados o colegios comunitarios. El nivel y la longi-
tud del curso pueden variar y se pueden suplementar mediante proyectos reales, HyperCase u otros materiales
disponibles en el Centro de recursos para el profesor.
El texto se divide en cinco partes principales: Fundamentos del análisis de sistemas (parte I), Análisis de re-
querimientos de información (parte II), El proceso de análisis (parte III), Fundamentos del diseño (parte IV) y
Aseguramiento de calidad e implementación (parte V).
La Parte I (capítulos 1 al 3) hace énfasis en los fundamentos que necesitan conocer los estudiantes sobre lo
que hace un analista; además ofrece una introducción a las tres principales metodologías del ciclo de vida del de-
sarrollo de sistemas (SDLC), las metodologías ágiles y el análisis
Empezar el análisis y
orientado a objetos con UML, junto con los motivos y las situaciones diseño orientado a objetos
incluye material sobre los equipos y las organizaciones virtuales, y Crear diagramas Desarrollar diagramas
de clases de secuencia
se introduce el concepto de HCI. Se presenta además el concepto del
software de código fuente abierto (OSS). El capítulo 2 indica cómo
empezar a trabajar con una organización, para lo cual se dibujan los diagramas de flujo de datos a nivel de contexto, se
utilizan los modelos de entidad-relación y se desarrollan casos de uso y escenarios de casos de uso. En el capítulo 3
se introduce material extendido sobre la creación de los estatutos del proyecto y se introduce la propuesta de siste-
mas en las primeras etapas del proceso, sin importar qué método de análisis y diseño se haya elegido. También se
incluye una cobertura más extensa sobre la evaluación del software y hardware, y cuándo usar COTS (software
comercial de venta a través de los canales convencionales). Aquí se enseñan varios métodos para pronosticar los
costos y beneficios, lo cual es necesario para el análisis sobre la adquisición de software y hardware. Asimismo,
este capítulo ayuda a los estudiantes a evaluar el software, para lo cual compara las ventajas y desventajas entre la
creación de software personalizado, la compra de software comercial directo de los distribuidores (COTS) o
la subcontratación con un proveedor de servicios de aplicaciones (ASP). También veremos cómo crear la defi-
nición de un problema y presentar una propuesta de sistemas efectiva, en la que se incorporen figuras y gráficos
para comunicarse con los usuarios.
La parte II (capítulos 4 al 6) enfatiza el uso de las metodologías sistemáticas y estructuradas para realizar el
análisis de los requerimientos de información. Esto permite a los analistas asegurarse de tratar con el problema
correcto antes de diseñar el sistema. El capítulo 4 introduce un grupo
de métodos interactivos, incluyendo las entrevistas, el diseño de apli-
caciones conjuntas (JAD) y la construcción de cuestionarios. El capí- Nombre del obser
vador
Formulario de evalu
Michael Cerveris
ación del prototipo
Nombre del sistem Fecha 1/06/2010
a o proyecto
tulo 5 presenta un grupo de métodos discretos para establecer los re- Centro de datos
Nombre o núme
de computación
ro de programa
en nube
Empresa o ubica
ción
Aquarius Water
Mant. Prev. Filters
querimientos de información de los usuarios. Estos métodos incluyen el Nombre de usuar
io
Periodo de observación
Usuario 1
Andy H.
Pam H.
Versión
Usuario 2 Usuario 3
1
Usuario 4
1/06/2010
muestreo, la investigación de datos duros y los datos de archivo, y la Reacciones de los
usuarios
Favorable en
general, se
1/06/2010
¡Excelente!
www.xlibros.com
xxii PREFACIO
salida sobre los usuarios y cómo diseñar buenos formularios y pantallas. En Suscripción
de video
www.xlibros.com
PREFACIO xxiii
para mejorar el diseño y el mantenimiento del software. Además incluye de datos aplicaciones
CARACTERÍSTICAS PEDAGÓGICAS
Cada capítulo de esta edición contiene:
䊉 Objetivos de aprendizaje al inicio de cada capítulo.
䊉 Resúmenes que enlazan los puntos principales de cada capítulo y proporcionan una excelente fuente de
repaso para los exámenes.
䊉 Palabras clave y frases.
䊉 Preguntas de revisión.
䊉 Problemas.
䊉 Proyectos en grupo que ayudan a los estudiantes a trabajar en conjunto en un equipo de sistemas para re-
solver problemas importantes que se resuelven mejor a través de la interacción en un grupo.
䊉 Oportunidades de consultoría: ahora con más de 60 mini casos a lo largo del libro.
www.xlibros.com
xxiv PREFACIO
䊉 Atractivo Mac: columnas que informan a los estudiantes sobre el software de diseño disponible en la
Mac y el iPhone.
䊉 Experiencias de HyperCase.
䊉 Episodios del caso de la CPU: partes de un caso continuo esparcidas por todo el libro.
OPORTUNIDADES DE CONSULTORÍA
La octava edición presenta más de 60 oportunidades de consultoría.
Muchas de ellas tratan sobre temas relevantes y emergentes que han INFORME DEL EXAMEN AUDIOLÓGICO
Apellido paterno del paciente Primer nombre Inicial segundo nombre
surgido en el campo, incluyendo el diseño de sistemas desde una pers- Estación de inspección
Número de paciente
Fecha del examen
Número de seguro social
Primer examen Número de reclamación
pectiva de HCI, aplicaciones de comercio electrónico para la Web, soft- Oído derecho
CONDUCCIÓN DE AIRE
Oído izquierdo
ware COTS y el uso de UML para modelar sistemas de información 500 1000 2000 4000 6000 500 1000 2000 4000 6000
CONDUCCIÓN ÓSEA
desde una perspectiva orientada a objetos. Las oportunidades de consul- 500
Oído derecho
1000 2000 4000 6000 500 1000
Oído izquierdo
2000 4000 6000
toría se pueden utilizar para estimular debates en la clase o se pueden SECCIÓN DE AUDIOMETRÍA VOCAL Comentarios [
UMBRAL DE RECEPCIÓN DE VOZ
asignar como tareas o preguntas de examen para resolver en casa. Oído derecho [ ]
Oído izquierdo [ ] Referido por [ ]
DISCR. OÍDO DERECHO. Motivo de referencia
Debido a que no todos los sistemas son proyectos extendidos de dos % [ ] Enmascaramiento [ ] Audiólogo examinador
DISCRIM. OÍDO IZQUIERDO Número de audiólogo examinador
% [ ] Enmascaramiento [ ] Siguiente solicitante
o tres años, nuestro libro contiene muchas oportunidades de consultoría
que se pueden resolver con rapidez en 20 o 30 minutos en grupo o por
escrito en forma individual. El objetivo de estos minicasos, que están es-
critos con un toque de humor para alegrar un poco el momento, es que los estudiantes sinteticen lo que han apren-
dido hasta ese punto del curso, que maduren en cuanto a su juicio profesional y ético, y que articulen el razona-
miento que condujo a sus decisiones sobre los sistemas.
EXPERIENCIAS DE HYPERCASE
En cada capítulo se presentan Experiencias de HyperCase®, que plan-
tean desafiantes ejercicios para los estudiantes. En esta octava edición se
incluyen nuevos escenarios, gráficos y problemas para acompañar la
versión 2.8 de HyperCase. Este software cuenta con problemas organi-
zacionales basados en sistemas con tecnología de punta. HyperCase re-
presenta a una organización virtual original que permite a los estudiantes
que acceden a ella sumergirse de inmediato en la vida organizacional.
Los estudiantes entrevistarán personas, observarán los entornos de ofi-
cina, analizarán sus prototipos y revisarán la documentación de sus sis-
temas existentes. HyperCase 2.8 es un software interactivo basado en
Web que presenta a una organización llamada Maple Ridge Engineering
(MRE) en un entorno colorido con gráficos tridimensionales. HyperCase
permite a los profesores abordar la clase sobre el análisis y diseño de
sistemas con apasionante material multimedia. Al observar cuidadosa-
mente la manera en que utilizan el tiempo y administran varios métodos,
los estudiantes utilizan las herramientas de hipertexto de HyperCase en la Web para crear sus propias rutas indivi-
duales por la organización.
Maple Ridge Engineering se basa en las experiencias de consultoría reales de los autores de la versión original
(Raymond Barnes, Richard Baskerville, Julie E. Kendall y Kenneth E. Kendall). Allen Schmidt se unió al proyecto
para la versión 2.0 y ha permanecido en él. Peter Schmidt fue el programador de HTML y Jason Reed creó las
imágenes para la versión Web inicial.
En cada capítulo hay Experiencias de HyperCase recién actualizadas que incluyen asignaturas (e incluso al-
gunas pistas) para ayudar a los estudiantes a resolver los difíciles problemas organizacionales, incluyendo el desa-
rrollo de nuevos sistemas, la fusión de departamentos, la contratación de empleados, la seguridad, el comercio
electrónico y la planificación de recuperación de desastres, todo lo cual pueden encontrar en MRE. HyperCase se
ha probado totalmente en salones de clases y resultó ganador de un premio en la competencia de Instrucción
Innovadora del Instituto de Ciencias de la Decisión (Decision Sciences Institute Innovative Instruction).
www.xlibros.com
PREFACIO xxv
www.xlibros.com
www.xlibros.com
AGRADECIMIENTOS
Durante la redacción de esta octava edición de Análisis y diseño de sistemas ocurrieron cambios rápidos y consi-
derables en la tecnología de la información. Nos deleita saber que esta edición se publica en el momento adecuado
para reflejar muchos de estos avances en el desarrollo de sistemas.
Uno de los principales cambios es el surgimiento de tres metodologías principales para el desarrollo: SDLC,
metodologías ágiles y el análisis y diseño de sistemas orientado a objetos. La presente obra muestra dónde y en qué
situaciones le puede servir cada una de estas metodologías a usted, como analista de sistemas.
Otro de los grandes cambios es el rápido aumento en el uso de la Web como plataforma para sistemas de in-
formación. La arquitectura orientada a servicios y la computación en nube están cambiando la forma en que el
analista debe abordar el diseño de soluciones de sistemas. Además de la Web, los analistas se ven presionados a
diseñar para un amplio espectro de tecnologías de información emergentes, como las inalámbrica y móvil, los
sistemas empresariales y los contextos virtuales tales como equipos y organizaciones virtuales.
Otro de los cambios importantes reflejados en esta edición es la habilidad de los usuarios para personalizar sus
escritorios, espacios de trabajo y páginas Web, e incluso de alterar los diseños profesionales de los analistas de
sistemas. A diferencia de los usuarios, los analistas ven todo el panorama y siempre deben estar conscientes de los
impactos organizacionales que se producen al cambiar los sistemas.
A través de este libro usted aprenderá y aplicará numerosas técnicas, métodos, herramientas y metodologías.
Pero llegado el momento de interpretar lo que ocurre en la organización y desarrollar sistemas de información re-
presentativos con base en las reglas que usted aplique en su análisis, lo que aprendió deberá combinarse con la
creatividad para producir un sistema que puede ser en cierto modo una sorpresa: es estructurado pero intuitivo;
basado en multiniveles y complejo para estar en armonía con el carácter de la organización, y además debe reflejar
su personalidad como analista de sistemas y ser humano.
Nuestros estudiantes merecen crédito por esta nueva edición, ya que brindaron retroalimentación y sugerencias
para mejorar, además de pedir una cobertura más detallada sobre ciertos temas. Los estudiantes nos dijeron que
pusieron rápidamente en uso el nuevo material sobre el análisis y diseño de sistemas orientados a objetos, así como
el de modelado ágil. Su afán por enseñarnos nuevas cosas mantuvo la frescura de este libro. Queremos agradecer
a nuestro coautor Allen Schmidt, quien una vez más trabajó con nosotros en los Episodios del caso de la CPU y en
HyperCase 2.8, por todo su gran esfuerzo, dedicación y humor durante el tiempo que estuvimos colaborando con
él. Es una persona maravillosa. También ofrecemos nuestro agradecimiento a Peter Schmidt y Jason Reed por
mejorar el software HyperCase anterior. Y queremos agradecer a los otros dos autores originales de HyperCase,
Richard Baskerville y Raymond Barnes por su enorme contribución.
Damos la gracias al equipo de producción de la octava edición, en especial a nuestro director ejecutivo Bob
Horan, cuya sabiduría y tranquilidad siempre brindan inspiración. También agradecemos a Kelly Loftus, nuestra
extremadamente habilidosa editora asistente, por su ecuánime competencia y su optimismo para mantener el pro-
yecto en constante avance. Ana Jankowsi, nuestra editora de producción, también merece una mención especial por
ayudarnos a convertir este proyecto en una revisión sólida, completa y precisa. Su ayuda y entusiasmo facilitaron
el proceso de completar el proyecto sin problemas y a tiempo.
También queremos agradecer el estímulo y el apoyo de toda la comunidad Rutgers, incluyendo a nuestro mi-
nistro Wendell Prittchett, nuestros colegas en la Escuela de Negocios de Camden y en todo Rutgers, a nuestro
personal y al Consejo de Administración. Todos han mostrado mucho entusiasmo sobre esta edición, y sobre las
diversas traducciones de este libro disponibles en español, chino e indonesio.
xxvii
www.xlibros.com
xxviii AGRADECIMIENTOS
Julie y Ken Kendall agradecen personalmente a Shrek (Brian d’Arcy James) y a todos nuestros queridos
amigos en el teatro y las artes escénicas.
Todos los revisores de la octava edición merecen también nuestro agradecimiento. Sus considerados comen-
tarios y sugerencias ayudaron a fortalecer el libro. Ellos son:
Stephen T. Brower, Raritan Valley Community College
Robert F. Cope III, Southeastern Lousiana University
Junhua Ding, East Carolina University
Jon Gant, University of Illinois
Cliff Layton, Rogers State University
Keng Siau, University of Nebraska-Lincoln
Muchos de nuestros colegas y amigos nos alentaron al momento de escribir este libro. Queremos agradecer sus
comentarios sobre nuestro trabajo a Ayman Abu Hamdieh, Macedonio Alanis, Michel Avital, los Ciupek, Charles J.
Coleman, Roger T. Danforth, Gordon Davis, EgoPo, Paul Gray, Nancy V. Gulick, Andy y Pam Hamingson, Blake
Ives, Richard Kalina, Carol Latta, Ken y Jane Laudon, Richard Levao, Joel y Bobbie Porter, Caryn Schmidt, Marc y
Jill Schniederjans, Gabriel Shanks, Detmar W. Straub, Jr., los Vargo, Merrill Warkentin, Jeff y Bonnie Weil, Ping
Zhang, a todos nuestros amigos y colegas en la Asociación para Sistemas de Información, el Instituto de Ciencias de
la Decisión, el Grupo de trabajo 8.2 del IFIP y a todos aquellos involucrados en el Proyecto PhD (financiado por la
Fundación KPMG), que atiende a estudiantes de minorías en doctorados en sistemas de información.
Agradecemos de corazón a la memoria de Julia A. Kendall y a la memoria de Edward J. Kendall. Su convicción
de que el amor, las metas y el trabajo duro son una combinación invencible sigue influyendo en todos nuestros
esfuerzos.
www.xlibros.com
C A P Í T U L O 1 PA RT E I
Fundamentos del
análisis de sistemas
Sistemas, roles y
metodologías de desarrollo
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Recordar los tipos básicos de sistemas de computación que un analista debe conocer.
2. Comprender la forma en que los usuarios de las nuevas tecnologías pueden modificar
la dinámica de un sistema.
3. Conocer los distintos roles de un analista de sistemas.
4. Comprender los fundamentos de tres metodologías de diseño: SDL, la metodología ágil
y el análisis y diseño de sistemas orientado a objetos.
5. Aprender sobre las herramientas CASE y cómo pueden ayudar a un analista de
sistemas.
www.xlibros.com
2 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
TIPOS DE SISTEMAS
Los sistemas de información se desarrollan para distintos fines, dependiendo de las necesidades de los usuarios
humanos y la empresa. Los sistemas de procesamiento de transacciones (TPS) funcionan en el nivel operacional
de la organización; los sistemas de automatización de oficinas (OAS) y los sistemas de trabajo de conocimiento
(KWS) brindan soporte para el trabajo a nivel del conocimiento. Entre los sistemas de nivel superior se encuen-
tran los sistemas de información administrativa (MIS) y los sistemas de soporte de decisiones (DSS)∗. Los siste-
mas expertos aplican la experiencia de los encargados de tomar decisiones para resolver problemas específicos y
estructurados. En el nivel estratégico de la administración se encuentran los sistemas de soporte para ejecutivos
(ESS). Los sistemas de soporte de decisiones en grupo (GDSS) y los sistemas de trabajo colaborativo asistido
por computadora (CSCWS), que se describen en forma más general, ayudan en el proceso de toma de decisiones,
a nivel de grupo, de la variedad semiestructurada o no estructurada.
En la figura 1.1 se muestra la variedad de sistemas de información que pueden desarrollar los analistas.
Observe que la figura presenta estos sistemas de arriba hacia abajo, indicando que el nivel operacional de la or-
ganización (el más bajo) cuenta con apoyo (soporte) de los sistemas TPS, mientras que el nivel estratégico de
decisiones semiestructuradas y no estructuradas (el más alto) cuenta con soporte de los sistemas ESS, GDSS
y CSCWS en la parte superior. En este libro utilizamos los términos sistemas de información administrativa,
sistemas de información (IS), sistemas de información computarizados y sistemas de información de negocios
computarizados para indicar los mismos sistemas de información computarizados que ofrecen soporte para el
rango más amplio de interacciones de los usuarios con las tecnologías y actividades comerciales por medio de la
información que producen en contextos organizacionales.
Sistemas de procesamiento de transacciones
Los sistemas de procesamiento de transacciones (TPS) son sistemas de información computarizados que se de-
sarrollaron para procesar grandes cantidades de información para las transacciones de negocios rutinarias, como
nóminas e inventario. Un TPS elimina el tedio de las transacciones operacionales necesarias y reduce el tiempo
que se requería para realizarlas en forma manual, aunque la mayoría de las personas aún deben introducir los
datos en forma manual en los sistemas computarizados.
Los sistemas de procesamiento de transacciones son sistemas que atraviesan límites y permiten que la organi-
zación interactúe con los entornos externos. Como los administradores analizan los datos generados por el TPS para
obtener información actualizada sobre lo que ocurre en sus empresas, es imprescindible que estos sistemas funcionen
sin problemas ni interrupciones para sustentar las operaciones diarias de estas compañías.
Sistemas de automatización de oficinas y sistemas de trabajo de conocimiento
En el nivel de conocimiento de la organización hay dos clases de sistemas. Los sistemas de automatización de
oficinas (OAS) brindan apoyo a las personas que trabajan con datos no para crear conocimiento sino para anali-
FIGURA 1.1
Un analista de sistemas puede
involucrarse con cualquiera o con
todos estos sistemas. ESS
GDSS
CSCWS
Sistemas expertos
Sistemas de soporte de decisiones
Sistemas de información administrativa
* Esta traducción es la más aceptada por la mayoría de los académicos, aunque una mejor traducción de estas siglas sería: Sistemas de apoyo a la
toma de decisiones, y sistemas de apoyo a la toma de decisiones en grupo, para las siglas GDSS.
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 3
zar la información y transformar los datos o manipularlos de cierta forma antes de compartirlos o diseminarlos de
manera formal a través de la organización y, algunas veces, más allá. Los aspectos más conocidos de los sistemas
OAS son el procesamiento de palabras, las hojas de cálculo, el diseño gráfico por computadora, la planificación
electrónica y la comunicación a través de correo de voz, correo electrónico (e-mail) y teleconferencias.
Los sistemas de trabajo de conocimiento (KWS) brindan apoyo a profesionales como científicos, ingenieros y
médicos, ayudándoles a crear conocimiento (a menudo en equipos) y a integrarlo a su organización o la sociedad.
www.xlibros.com
4 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
de los miembros del grupo con facilidad de palabra y la toma de decisiones mediante el “pensamiento grupal”.
Algunas veces los sistemas GDSS se consideran bajo el término más general de sistemas de trabajo colaborativo
asistido por computadora (CSCWS), que podría incluir el soporte de software conocido como groupware para
colaborar en equipo mediante computadoras conectadas en red. Los sistemas de soporte de decisiones en grupo
también se pueden utilizar en un ambiente virtual.
FIGURA 1.2
Los analistas de sistemas necesitan
estar conscientes de que al integrar
tecnologías se ven afectados todos
ESS
los tipos de usuarios y sistemas.
os
GDSS ri c
mb
CSCWSinalá
as
em
Sist
Sistemas expertos
Sistemas de soporte de decisiones
ones
ia les
re sar
Sistemas de información administrativa
p
em
m as
e
Sist de conocimiento
Sistemas de trabajo
co
Sistemas de automatización
a de oficinas ó ni
le ctr
oe
e rci
om
ec
Sistemas de procesamiento dee transacciones
d
by
s We
a
em
Sist
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 5
Sistemas empresariales
Muchas organizaciones preveen beneficios potenciales derivados de la integración de diversos sistemas de
información existentes en distintos niveles administrativos y dentro de diferentes funciones. Algunos autores
describen la integración como arquitectura orientada a servicios (SOA), la cual existe en capas. Los sistemas
empresariales conformarían la capa superior. Estos sistemas, también conocidos como sistemas de planificación
de recursos empresariales (ERP), están diseñados para llevar a cabo esta integración. Para establecer un ERP se
requiere de un enorme compromiso y cambios en la organización. A menudo, los analistas de sistemas actúan
como consultores para los proyectos de ERP que utilizan software propietario. Dentro del software ERP popular
están los sistemas de SAP y Oracle. Algunos de estos paquetes están orientados hacia el proceso de migrar las
empresas a la Web. Por lo general, los analistas y algunos usuarios requieren capacitación, soporte y manteni-
miento por parte del distribuidor para diseñar, instalar, mantener, actualizar y utilizar de manera apropiada un
paquete ERP específico.
www.xlibros.com
6 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 7
O P O R T U N I D A D D E C O N S U LT O R Í A 1 . 1
negocios. A menudo este trabajo no es un verdadero proyecto de sistemas, sino que supone una pequeña modifi-
cación o decisión que afecta a un solo departamento.
Como experto en soporte usted no administra el proyecto; simplemente actúa como recurso para quienes lo
administran. Si usted es un analista de sistemas empleado por una organización de manufactura o de servicios,
tal vez muchas de sus actividades diarias correspondan a este rol.
www.xlibros.com
8 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Si el cambio (es decir, las mejoras que se pueden realizar en la empresa por medio de los sistemas de infor-
mación) parece garantizado después del análisis, el siguiente paso es desarrollar un plan junto con las personas
que deben llevarlo a cabo. Una vez que se llega a un consenso en cuanto al cambio que se debe realizar, usted
debe interactuar en forma constante con todos los que vayan a cambiar.
En el rol de agente de cambio, un analista de sistemas aboga por una vía particular de cambio involucrada
con el uso de sistemas de información. También enseña a los usuarios el proceso del cambio, ya que los cambios
en el sistema de información no ocurren por separado, sino que producen cambios consecuentes en el resto de la
organización.
3 Análisis de las
necesidades
7 Implementación del sistema
y evaluación
del sistema
4 Diseño
del sistema
recomendado
6 Prueba 5 Desarrollo
y mantenimiento y documentación
del sistema del software
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 9
www.xlibros.com
10 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
resultados. El resultado de esta fase es un informe de viabilidad, el cual contiene la definición de un problema y
sintetiza los objetivos. Después, la administración de la empresa debe tomar una decisión en cuanto a proceder o
no con el proyecto propuesto. Si el grupo de usuarios no tiene suficientes fondos en su presupuesto o desea hacer
frente a problemas que no están relacionados, o si los problemas no requieren un sistema computacional, tal vez
se pueda recomendar una solución distinta y el proyecto de sistemas no continúe.
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 11
las cualidades individuales y la capacitación profesional de cada analista, y de su interacción con los usuarios en
el contexto de su entorno laboral.
www.xlibros.com
12 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
ATRACTIVO DE LA MAC
En el hogar y en nuestras visitas a los campus de universidades y empresas en todo el mundo hemos observado que cada
vez más estudiantes y las organizaciones muestran un interés por la Mac. Por ello pensamos que sería interesante mos-
trar algunas de las opciones que tiene un diseñador de sistemas al respecto de esta plataforma. Al momento de escribir
este libro, aproximadamente una de cada siete computadoras personales que se compran en los Estados Unidos es Mac.
Las Mac son equipos de calidad basados en procesadores Intel que ejecutan un competente sistema operativo nativo,
pero también pueden ejecutar Windows, por lo que en definitiva cualquier cosa que se pueda hacer en una PC se puede
hacer también en una Mac. Una forma de ejecutar Windows es arrancar directamente la Mac con el sistema Windows
(una vez instalado); otra forma es usar software de virtualización como VM Fusion, el cual mostramos en la figura
1.MAC.
Los seguidores de las Mac citan muchas razones por las cuales las utilizan, incluyendo una mejor seguridad inte-
grada en el sistema operativo de la Mac, respaldos inteligentes mediante la máquina de tiempo integrada, la multitud de
aplicaciones ya incluidas, la confiabilidad de la configuración y el trabajo en red, y la capacidad de sincronizar las Mac
con otros equipos Mac y con el iPhone. Para nosotros, la razón más convincente es su diseño en sí.
FIGURA 1.MAC
Windows ejecutándose en una Mac mediante el software de virtualización conocido como VM Fusion.
La evaluación se incluye como parte de esta fase final del SDLC principalmente por cuestiones informativas.
En realidad, la evaluación se realiza durante cada fase. El criterio clave que debemos satisfacer es si los usuarios
previstos están utilizando el sistema.
Hay que tener en cuenta que a menudo el trabajo relacionado con los sistemas es cíclico. Cuando un analista
termina una fase del desarrollo de sistemas y continúa con la siguiente, al descubrir un problema tal vez se vea
obligado a regresar a la fase anterior y modificar el trabajo que realizó ahí.
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 13
FIGURA 1.4
Algunos investigadores estiman
Nuevos sistemas
que la cantidad de tiempo
y otras actividades invertido en el mantenimiento de
40% sistemas puede ser hasta del 60
Mantenimiento de los por ciento del tiempo total
sistemas existentes invertido en los proyectos de
60% sistemas.
El mantenimiento se lleva a cabo por dos razones. La primera es para corregir los errores de software. Sin
importar qué tan minuciosas sean las pruebas en el sistema, se pueden infiltrar errores o ‘bugs’ en los programas
computacionales. Los ‘bugs’ en el software comercial de PC se documentan comúnmente como “anomalías co-
nocidas” y se corrigen al momento de liberar nuevas versiones, o liberando una versión provisional. En el soft-
ware personalizado (también conocido como software hecho a la medida), los ‘bugs’ se deben corregir a medida
que se van detectando.
La otra razón de realizar mantenimiento en los sistemas es para mejorar las capacidades del software en
respuesta a las necesidades cambiantes de la organización, que por lo general implica una de las siguientes tres
situaciones:
1. Con frecuencia los usuarios solicitan características adicionales a medida que se familiarizan con el sistema
computacional y sus capacidades.
2. La empresa cambia con el tiempo.
3. El hardware y el software cambian a un ritmo acelerado.
La figura 1.5 muestra la cantidad de recursos (por lo general tiempo y dinero) que se invierten en el de-
sarrollo y mantenimiento de sistemas. El área bajo la curva representa la cantidad total invertida en dólares.
Podemos ver que, a través del tiempo, es probable que el costo total del mantenimiento exceda al costo del
desarrollo de sistemas. En cierto punto es más factible realizar un nuevo estudio de sistemas, debido a que el
costo de continuar con el mantenimiento es sin duda mayor que el de crear un sistema de información total-
mente nuevo.
En resumen, el mantenimiento es un proceso continuo que se realiza a lo largo del ciclo de vida de un sis-
tema de información. Una vez que se instala el sistema de información, por lo general el mantenimiento implica
corregir los errores del programa que no se habían detectado antes. Una vez corregidos, el sistema se acerca a un
estado estable para proveer un servicio confiable a sus usuarios. Durante este periodo, el mantenimiento puede
consistir en eliminar unos cuantos ‘bugs’ que no se detectaron antes y actualizar el sistema con mejoras menores.
Sin embargo, a medida que pasa el tiempo y evolucionan tanto la empresa como la tecnología, el esfuerzo de
mantenimiento aumenta en forma considerable.
Desarrollo
Cantidad
de sistemas
de recursos Tiempo
consumidos,
tiempo
y dinero
Día de la
instalación
www.xlibros.com
14 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
LA METODOLOGÍA ÁGIL
Aunque este texto tiende a enfocarse en el SDLC —la metodología más utilizada en la práctica—, el analista
deberá reconocer algunas veces que la organización podría beneficiarse de una metodología alternativa. Tal vez
recientemente un proyecto de sistemas en el que se utilizaba una metodología estructurada falló o quizás las
subculturas de la organización, compuestas por varios grupos de usuarios distintos, parecen identificarse más con
el uso de un método alternativo. Es imposible hacer justicia a estos métodos en un espacio pequeño; cada uno
merece y ha inspirado sus propios libros e investigaciones. Sin embargo, mencionamos estas metodologías con la
esperanza de que tome conciencia de que, bajo ciertas circunstancias, tal vez su organización quiera considerar
una alternativa o suplemento al análisis y diseño estructurado y al SDLC.
La metodología ágil es una metodología de desarrollo de software que se basa en valores, principios y prác-
ticas básicas. Los cuatro valores son comunicación, simpleza, retroalimentación y valentía. Recomendamos que
los analistas de sistemas adopten estos valores en todos los proyectos que emprendan y no sólo cuando adopten
la metodología ágil.
Para poder terminar un proyecto, a menudo hay que realizar ciertos ajustes en la administración del mismo.
En el capítulo 6 veremos que los métodos ágiles pueden asegurar que un proyecto se complete con éxito me-
diante un ajuste en los importantes recursos de tiempo, costo, calidad y alcance. Cuando se incluyen estas cuatro
variables de control en forma apropiada en la planificación, hay un estado de equilibrio entre los recursos y las
actividades necesarias para completar el proyecto.
Es más notable llevar las prácticas de desarrollo al extremo cuando se persiguen prácticas únicas para el de-
sarrollo ágil. En el capítulo 6 hablaremos sobre cuatro prácticas ágiles básicas: liberaciones de versiones cortas,
la semana de trabajo de 40 horas, hospedar un cliente en el sitio y utilizar programación en pareja. A primera
vista estas prácticas parecen extremas, pero como veremos más adelante, podemos aprender ciertas lecciones
importantes al incorporar muchos de los valores y prácticas de la metodología ágil a los proyectos de análisis y
diseño de sistemas.
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 15
Diagramas y modelos
de sistemas
Artículo = Número +
Descripción + DO WHILE NOT fin de archivo
Costo + Leer registro del artículo
Precio + IF artículo está bajo en existencias
Cantidad en existencia + Diccionario de datos
Imprimir orden de compra y lógica de procesos
Cantidad en pedido +
Actualizar registro del artículo
Punto para reabastecer +
Ventas mensuales + ENDIF
Ventas del año a la fecha ENDDO
www.xlibros.com
16 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 1.7
Las cinco etapas del proceso de
desarrollo de modelado ágil Exploración
muestran que las iteraciones
frecuentes son esenciales para un
desarrollo exitoso del sistema.
Iteraciones para
Planeación la liberación de la
primera versión
Los mét
involucraodos ágiles
en much n al cliente
antes d as iteraciones
e
la prime liberar
ra versió Puesta en producción
n…
el
Mantenimiento mentan
…e incre iteraciones
e
ritmo d que se libera
una vez cto.
el produ
las tecnologías potenciales necesarias para crear el sistema. Durante esta etapa debe practicar con la estimación
del tiempo necesario para realizar varias tareas. En la exploración, los clientes también experimentan escribiendo
historias de los usuarios. El punto es hacer que el cliente refine una historia con el detalle suficiente como para
que usted pueda estimar en forma competente la cantidad de tiempo necesaria para crear la solución y convertirla
en el sistema que está planeando. Todo en esta etapa tiene que ver con adoptar una actitud juguetona y curiosa
hacia el entorno de trabajo, sus problemas, tecnologías y personas.
PLANEACIÓN La siguiente etapa del proceso de desarrollo ágil se llama planeación. Al contrario de la primera
etapa, la planeación tal vez sólo requiera de unos cuantos días. En esta etapa, usted y sus clientes se ponen de
acuerdo en una fecha, que puede ser cualquier día a partir de dos meses hasta medio año después de la fecha
en curso, para entregar soluciones a sus problemas empresariales más estresantes (usted se concentrará en el
conjunto más pequeño y valioso de historias). Si sus actividades de exploración fueron suficientes, esta etapa
debe ser muy corta.
Todo el proceso de planeación ágil se ha caracterizado mediante la idea de un juego de planeación según
la idea de Beck. El juego de planeación establece reglas que pueden ayudar a formular la relación del equipo de
desarrollo ágil con sus clientes empresariales. Aunque las reglas forman una idea de cómo quiere usted que actúe
cada una de las partes durante el desarrollo, no están diseñadas para sustituir una relación. Son la base para crear
y mantener una relación.
Entonces, utilizamos la metáfora de un juego. Para ello hablaremos en términos del objetivo del juego,
la estrategia a perseguir, las piezas a mover y los jugadores involucrados. El objetivo del juego es maximizar
el valor del sistema producido por el equipo ágil. Para poder averiguar el valor, usted debe deducir los costos
de desarrollo y el tiempo, los gastos y la incertidumbre requeridos para que el proyecto de desarrollo pueda
continuar.
La estrategia que persigue el equipo de desarrollo ágil siempre tiene una incertidumbre limitante (minimiza-
ción del riesgo). Para hacer esto, el equipo diseña la solución más simple posible, pone el sistema en producción
tan pronto como sea posible, obtiene retroalimentación del cliente empresarial sobre lo que está funcionando y
adapta su diseño a partir de ahí.
Las tarjetas de historias se convierten en las piezas del juego de planeación que describen con brevedad la
tarea, proveen anotaciones y un área para rastrear las tareas.
Hay dos jugadores principales en el juego de planeación: el equipo de desarrollo y el cliente empresarial. No
siempre es fácil decidir qué grupo empresarial en particular será el cliente empresarial, ya que el proceso ágil es
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 17
un rol excepcionalmente exigente para el cliente. Los clientes deciden qué debe abordar primero el equipo de de-
sarrollo. Sus decisiones establecerán prioridades y revisarán la funcionalidad durante todo el proceso.
ITERACIONES PARA LA LIBERACIÓN DE LA PRIMERA VERSIÓN La tercera etapa en el proceso de desarrollo ágil
está compuesta por las iteraciones para la liberación de la primera versión. Por lo general éstas son iteraciones
(ciclos de prueba, retroalimentación y modificación) de aproximadamente tres semanas de duración. Usted se
esforzará en bosquejar toda la arquitectura del sistema, aun y cuando sólo esté en forma de bosquejo o esqueleto.
Uno de los objetivos es realizar pruebas funcionales escritas por el cliente al final de cada iteración. Durante
la etapa de las iteraciones también debe preguntarse si hay que alterar el itinerario de trabajo o si está lidiando
con demasiadas historias. Convierta cada iteración exitosa en pequeños rituales e involucre en ellos tanto a los
clientes como a los desarrolladores. Celebre siempre su progreso aunque éste sea pequeño, debido a que esto
forma parte de la cultura de motivar a todos a que trabajen lo más duro que puedan en el proyecto.
PUESTA EN PRODUCCIÓN Durante esta fase se llevan a cabo varias actividades. El ciclo de retroalimentación se
agiliza de manera que en vez de recibir retroalimentación por una iteración cada tres semanas, las revisiones de
software se entregan en una semana. Puede instituir sesiones informativas diarias para que todos sepan lo que
los demás están haciendo. El producto se libera durante esta fase, pero se puede mejorar si se le agregan otras
características. Poner un sistema en producción es un suceso emocionante; disponga de tiempo para celebrar
con sus compañeros de equipo la ocasión. Uno de los lemas de la metodología ágil con el que todos estamos
sinceramente de acuerdo es que ¡desarrollar sistemas debe ser divertido!
MANTENIMIENTO Una vez liberado el sistema, debe seguir funcionando sin problemas. Es posible agregar
características, considerar las sugerencias más riesgosas de los clientes y a rotar los miembros del equipo. La
actitud que usted debe tomar en este punto del proceso de desarrollo es más conservadora que en cualquier otro.
Ahora tiene que desempeñar el papel de “guardián de la llama” en vez de ser el juguetón y curioso de la fase de
exploración.
www.xlibros.com
18 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Desarrollar y
Dibujar diagramas
documentar
de caso de uso
el sistema
cada caso de uso, los cuales muestran la secuencia de actividades y su sincronización. Ésta es una
oportunidad para regresar y revisar los casos de uso, replantearlos y modificarlos si es necesario.
3. Continuar en la fase de análisis, desarrollar diagramas de clases.
Los sustantivos en los casos de uso son objetos que se pueden agrupar potencialmente en clases. Por
ejemplo, todo automóvil es un objeto que comparte características con otros automóviles. En conjunto
conforman una clase.
4. Aún en la fase de análisis, dibujar diagramas de estado.
Los diagramas de clases se utilizan para dibujar diagramas de estado, los cuales ayudan a comprender
procesos complejos que no se pueden derivar completamente mediante los diagramas de secuencia. Los
diagramas de estado son en extremo útiles para modificar los diagramas de clases, por lo que continúa el
proceso iterativo de modelado de UML.
5. Empezar el diseño de sistemas mediante la modificación de los diagramas de UML; después, completar las
especificaciones.
El diseño de sistemas significa modificar el sistema existente, para lo cual hay que modificar los
diagramas que se dibujaron en la fase anterior. Es posible usar estos diagramas para derivar clases, sus
atributos y métodos (éstos son simplemente operaciones). El analista tendrá que escribir especificaciones de
clase para cada una de las clases e incluir los atributos, métodos y sus descripciones. También desarrollará
especificaciones de los métodos en las que se detallen los requerimientos de entrada y salida para cada
método, junto con una descripción detallada del procesamiento interno del método.
6. Desarrollar y documentar el sistema.
UML es, obviamente, un lenguaje de modelado. Un analista podrá crear modelos maravillosos, pero
si el sistema no se desarrolla no tiene mucho sentido crearlos. La documentación es imprescindible. Entre
más completa sea la información que usted proporcione al equipo de desarrollo por medio de la
documentación y los diagramas de UML, más rápido será el desarrollo y más sólido será el sistema de
producción final.
A menudo las metodologías orientadas a objetos se enfocan en iteraciones pequeñas y rápidas de desarro-
llo, a lo que algunas veces se le conoce como el modelo de espiral. El análisis se lleva a cabo en una parte pe-
queña del sistema, en donde por lo general se empieza con un elemento de alta prioridad o tal vez con uno que
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 19
FIGURA 1.9
Seleccione Cuando
Cómo decidir qué método de
La metodología • los sistemas se hayan desarrollado y documentado mediante el uso de SDLC desarrollo utilizar.
del ciclo de vida del • sea importante documentar cada paso del proceso
desarrollo de • la administración de nivel superior se sienta más cómoda o segura
sistemas (SDLC) si utiliza SDLC
• haya los recursos y el tiempo adecuados para completar el SDLC
completo
• sea importante la comunicación en relación con la forma en que funcionan
los nuevos sistemas
represente el mayor riesgo. A esto le sigue el diseño y la implementación. El ciclo se repite con el análisis de la
siguiente parte, el diseño y algo de implementación, y esto se repite hasta completar el proyecto. Es normal re-
diseñar los diagramas y los componentes mismos. El UML es una potente herramienta de modelado que puede
mejorar en forma considerable la calidad del análisis y diseño de sistemas, así como del producto final.
RESUMEN
Podemos considerar a la información como un recurso organi- consecuencia, hay que poner más atención para lidiar con la in-
zado, de igual forma que consideramos a los humanos. Como tal, formación que se genera.
se debe administrar con cuidado, al igual que los demás recursos. Los analistas de sistemas recomiendan, diseñan y mantienen
La disponibilidad de poder de cómputo asequible para las orga- muchos tipos de sistemas para los usuarios, incluyendo los de pro-
nizaciones ha provocado una explosión de información y, en cesamiento de transacciones (TPS), los de automatización de ofi-
www.xlibros.com
20 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
EXPERIENCIA DE HYPERCASE® 1
cinas (OAS), los de trabajo de conocimiento (KWS) y los de se conoce como ciclo de vida del desarrollo de sistemas (SDLC).
información administrativa (MIS). También crean sistemas orien- Este ciclo de vida se puede dividir en siete fases secuenciales,
tados a decisiones para usuarios específicos. Entre estos sistemas aunque en realidad las fases están interrelacionadas y a menudo
están los de soporte de decisiones (DSS), los sistemas expertos se llevan a cabo en forma simultánea. Las siete fases son: iden-
(ES), los de soporte de decisiones en grupo (GDSS), los de trabajo tificación de los problemas, oportunidades y objetivos; deter-
colaborativo asistido por computadora (CSCWS) y los de soporte minación de los requerimientos de información del factor
para ejecutivos (ESS). Muchas aplicaciones están migrando o se humano; análisis de las necesidades del sistema; diseño del sis-
están originando en la Web para ofrecer soporte para el comercio tema recomendado; desarrollo y documentación del software;
electrónico y muchas otras funciones empresariales. prueba y mantenimiento del sistema; e implementación y evalua-
El análisis y diseño de sistemas es una metodología sistemática ción del sistema.
para identificar problemas, oportunidades y objetivos; para analizar La metodología ágil es una metodología de desarrollo de
los flujos de información humana y generada por computadora en software basada en valores, principios y prácticas básicas. Los
las organizaciones, y para diseñar sistemas de información compu- sistemas que se diseñan mediante métodos ágiles se pueden
tarizados para resolver un problema. Los analistas de sistemas desarrollar con rapidez. Las etapas en el proceso de desarrollo
deben desempeñar muchos roles durante el curso de su trabajo. ágil son exploración, planeación, iteraciones para la liberación
Algunos de estos roles son: 1) como consultor externo para la em- de la primera versión, puesta en producción y mantenimiento.
presa, 2) como experto de soporte dentro de una empresa y 3) como Hay una tercera metodología para el desarrollo de sistemas,
agente de cambio en situaciones tanto internas como externas. conocida como análisis y diseño orientado a objetos. Estas téc-
Los analistas poseen un amplio rango de habilidades. Antes nicas se basan en conceptos de programación orientada a objetos
que nada el analista es un solucionador de problemas, alguien que que se han codificado en el UML, un lenguaje de modelado es-
disfruta el reto de analizar un problema e idear una solución tandarizado en el que los objetos que se crean no sólo incluyen
funcional. Los analistas de sistemas requieren habilidades de código sobre los datos, sino también instrucciones sobre las
comunicación, que les permitan relacionarse de manera signifi- operaciones que se van a realizar en los datos. Los diagramas
cativa con muchos tipos de personas a diario, así como habilida- clave ayudan a analizar, diseñar y comunicar los sistemas desa-
des computacionales. Comprender a los usuarios y relacionarse rrollados mediante UML. Por lo general, estos sistemas se de-
bien con ellos es imprescindible para su éxito. sarrollan como componentes y el proceso de replantear estos
Los analistas proceden de manera sistemática. El marco de componentes muchas veces es una actividad normal en el análi-
trabajo para su metodología sistemática se proporciona en lo que sis y diseño orientado a objetos.
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 21
PREGUNTAS DE REPASO
1. Compare los procesos de tratar la información como un recurso y tratar a los humanos como un recurso
2. Liste las diferencias entre OAS y KWS.
3. Defina el significado de MIS.
4. ¿Cuál es la diferencia entre MIS y DSS?
5. Defina el término sistemas expertos. ¿Cuál es la diferencia entre los sistemas expertos y los sistemas de soporte de
decisiones?
6. Enliste los problemas de interacción grupal para los cuales se diseñaron los sistemas de soporte de decisiones en grupo
(GDSS) y los sistemas de trabajo colaborativo asistido por computadora (CSCWS).
7. ¿Cuál es el término más general, CSCWS o GDSS? Explique.
8. Defina el término comercio-m.
9. Liste las ventajas de montar aplicaciones en la Web.
10. ¿Cuál es la razón dominante para diseñar sistemas empresariales (o ERP)?
11. Proporcione un ejemplo de un proyecto de software de código fuente abierto.
12. Liste las ventajas de utilizar las técnicas de análisis y diseño de sistemas para trabajar con los sistemas de información
computarizados para empresas.
13. Liste tres roles que el analista de sistemas debe desempeñar. Proporcione una definición para cada uno de ellos.
14. ¿Qué cualidades personales son útiles para el analista de sistemas? Haga una lista.
15. Liste y defina brevemente las siete fases del ciclo de vida del desarrollo de sistemas (SDLC).
16. ¿Para qué se utilizan las herramientas CASE?
17. ¿Cuál es la diferencia entre las herramientas CASE superiores e inferiores?
18. Defina qué significa la metodología ágil.
19. ¿Cuál es el significado de la frase “el juego de planeación”?
20. ¿Cuáles son las etapas en el desarrollo ágil?
21. Defina el término análisis y diseño orientado a objetos.
22. ¿Qué es UML?
BIBLIOGRAFÍA SELECCIONADA
Coad, P. y E. Yourdon. Object-Oriented Analysis, 2da. ed. Englewood Cliffs, NJ: Prentice Hall, 1991.
Davis, G.B. y M. H. Olson. Management Information Systems: Conceptual Foundation, Structure, and Development, 2da. ed.
Nueva York: McGraw-Hill, 1985.
Feller, J., P. Finnegan, D. Kelly y M. MacNamara. “Developing Open Source Software: A Community-Based Analysis of Re-
search”: En IFIP International Federation for Information Processing, Vol. 208, Social Inclusion: Societal and Organiza-
tional Implications for Information Systems. Editado por E. Trauth, D. Howcroft, T. Butler, B. Fitzgerald y J. DeGross, pp.
261-278. Boston: Springer, 2006.
www.xlibros.com
22 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Kendall, J.E. y K. E. Kendall. “Information Delivery Systems: An Explanation of Web Push and Pull Technologies”, Commu-
nications of AIS, Vol. 1, artículo 14, abril 23, 1999.
Kendall, J.E., K.E. Kendall y S. Kong. “Improving Quality Through the Use of Agile Methods in Systems Development: People
and Values in the Quest for Quality”. En Measuring Information Systems Delivery Quality. Editado por E.W. Duggan y H.
Reichgelt, pp. 201-222. Hershey, PA: Idea Group Publishing, 2006.
Laudon, K.C. y J.P. Laudon. Management Information Systems, 11va. ed. Upper Saddle River, NJ: Pearson Prentice Hall,
2010.
Verma, S. “Software Quality and the Open Source Process”. En Measuring Information Systems Delivery Quality. Editado por
E.W. Duggan y H. Reichgelt, pp. 284-303. Hershey, PA: Idea Group Publishing, 2006.
www.visible.com/Products/index.htm. Último acceso: marzo 23, 2009.
Yourdon, E. Modern Structured Analysis Englewood Cliffs, NJ: Prentice Hall, 1989.
Zhang, P., J. Carey, D. Te’eni y M. Tremaine. “Integrating Human-Computer Interaction Development into the Systems Deve-
lopment Life Cycle: A Methodology”. Communications of the Association for Information Systems, Vol. 15, 2005, pp.
512-543.
www.xlibros.com
CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 23
EPISODIO 1
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Se abre el caso
En un día cálido y soleado de finales de octubre, Chip Puller estaciona su automóvil y camina hacia su oficina en la Central
Pacific University. Se sentía bien empezar como analista de sistemas y estaba esperando conocer al resto del personal.
En la oficina, Anna Liszt se presenta a sí misma. “Nos han asignado para trabajar como equipo en un nuevo proyecto. ¿Por
qué no te pongo al corriente con los detalles y después damos un paseo por las instalaciones?”
“Me parece bien”, responde Chip. “¿Cuánto tiempo llevas trabajando aquí?”
“Aproximadamente cinco años”, le responde Anna. “Empecé como analista programador pero durante los últimos años me
he dedicado al análisis y diseño. Espero que encontremos formas de aumentar nuestra productividad”, continúa Anna.
“Cuéntame sobre el nuevo proyecto”, dice Chip.
“Bien”, le responde Anna, “al igual que muchas organizaciones, tenemos una gran cantidad de microcomputadoras con
distintos paquetes de software instalados en ellas. Hasta donde sé, en la década de 1980 había pocas computadoras personales
y una colección dispersa de software. Esto se expandió con rapidez en la década de 1990 y ahora todos usan computadoras.
Algunos miembros del cuerpo docente utilizan más de una. El sistema actual que utilizamos para dar mantenimiento al software
y hardware, que en un principio era bastante útil, ahora es obsoleto y está bastante abrumado”.
“¿Qué hay sobre los usuarios? ¿A quién debo conocer? ¿Quién crees que será importante para ayudarnos con el nuevo
sistema?”, pregunta Chip.
“Vas a conocer a todos, pero hay personas clave que acabo de conocer y te diré lo que he aprendido para que las recuerdes
cuando las conozcas”.
“Dot Matricks es gerente de todos los sistemas de microcomputadoras en Central Pacific. Al parecer nos llevamos bien en
el trabajo. Es muy competente. Realmente le gustaría poder mejorar la comunicación entre los usuarios y los analistas”.
“Será un placer conocerla”, especula Chip.
“Y también está Mike Crowe, experto en mantenimiento de computadoras. Realmente parece el tipo más amable, pero está
demasiado ocupado. Necesitamos ayudar a aligerar su carga. La contraparte de Mike encargada del software es Cher Ware. Es
un espíritu libre, pero no me malentiendas: conoce su trabajo”, dice Anna.
“Tal vez sea divertido trabajar con ella”, reflexiona Chip.
“Podría ser”, asiente Anna. “También conocerás al analista financiero, Paige Prynter. Todavía no puedo entenderla bien”.
“Tal vez yo te pueda ayudar”, dice Chip.
“Por último, deberías —más bien dicho, tienes que— conocer a Hy Perteks, quien hace un excelente trabajo como encar-
gado del Centro de información. A él le gustaría que pudiéramos integrar nuestras actividades del ciclo de vida”.
“Suena prometedor”, dice Chip. “Creo que me va a gustar trabajar aquí”.
EJERCICIO
E-1. De la conversación de presentación que compartieron Chip y Anna, ¿cuáles de los elementos mencionados podrían su-
gerir el uso de herramientas CASE?
www.xlibros.com
24 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
CAPÍTULO 2
Comprensión y modelado de
los sistemas organizacionales
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender que las organizaciones y sus miembros son sistemas, y que como analista
debe asumir una perspectiva de sistemas.
2. Describir los sistemas en forma gráfica mediante el uso de diagramas de flujo de datos a
nivel de contexto, modelos entidad-relación, casos de uso y escenarios de casos de uso.
3. Reconocer que los distintos niveles de la administración requieren distintos sistemas.
4. Comprender que la cultura organizacional afecta al diseño de los sistemas de información.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 25
FIGURA 2.1
Objetivos Las salidas del sistema sirven
como retroalimentación para
comparar el rendimiento con los
objetivos.
Entradas Salidas
Sistema
www.xlibros.com
26 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
O P O R T U N I D A D D E C O N S U LT O R Í A 2 . 1
Marathon Vitamin Shops, “pero para ser más competitivos debemos Bill Berry leyó la lista y la contempló por unos instantes. “Es
establecer un sitio Web de comercio electrónico”. Su padre, copropie- obvio que el comercio electrónico es más complejo de lo que pen-
tario, responde: “Estoy de acuerdo, pero ¿dónde empezamos?” Barry saba”, dijo. Usted puede ayudar a los propietarios de Marathon
padre sabía, desde luego, que no era sólo cuestión de establecer un Vitamin Shops en varias formas:
sitio Web y pedir a sus clientes que enviaran por correo electrónico sus 1. Elabore una lista de los elementos interrelacionados o
pedidos a la tienda de ventas al público; ya había identificado ocho interdependientes. Después escriba un párrafo para indicar
elementos constitutivos del comercio electrónico y sabía que todas las por qué es imprescindible supervisar estos elementos con
partes tenían que trabajar en conjunto dado que formaban un sistema detenimiento.
mayor. Para que el comercio electrónico se realizara era necesario: 2. Decida cuáles serán los límites y el alcance máximo del
1. Atraer clientes a un sitio Web de comercio electrónico. sistema. Es decir, escriba un párrafo en el que exprese su
2. Informar a los clientes sobre los productos y servicios ofrecidos. opinión sobre qué elementos son imprescindibles para
3. Permitir a los clientes personalizar sus productos en línea. Marathon Vitamin Shop y cuáles se pueden explorar después.
4. Completar las transacciones con los clientes. 3. Sugiera los elementos que es necesario manejar dentro de la
5. Aceptar varias formas de pago. empresa y los que se puedan asignar a otra compañía capaz
6. Brindar soporte a los clientes después de la venta a través del de hacerse cargo del trabajo de una manera más eficiente.
sitio Web. Justifique sus sugerencias en dos párrafos, uno para las tareas
7. Hacer los arreglos correspondientes para entregar los internas a la empresa y otras para las tareas que se deben
productos y servicios. asignar a otras empresas (outsourcing).
El concepto de apertura o cerrazón interna de las organizaciones está relacionado y es similar al concepto de
permeabilidad de los límites externos. La apertura y cerrazón también existen en un continuo, ya que no hay tal
cosa como una organización completamente abierta o una totalmente cerrada.
La apertura se refiere al flujo libre de información dentro de la organización. Los subsistemas como los de-
partamentos creativos o artísticos a menudo se caracterizan como abiertos, con un flujo libre de ideas entre los
participantes y muy pocas restricciones en cuanto a quién recibe la información y en qué momento, cuando un
proyecto creativo está en su infancia.
En el extremo opuesto del continuo podría haber una unidad del departamento de defensa que trabaje en
un proyecto ultrasecreto de planeación que afecte la seguridad nacional. Cada persona debería entonces tener
autorización de acceso, la información oportuna sería indispensable y el acceso a la información se otorgaría
sólo a quien fuera estrictamente necesario incluir. Una unidad tal deberá funcionar bajo muchas restricciones.
Si utilizamos la superposición de sistemas para comprender a las organizaciones, podremos reconocer la
idea de que los sistemas están compuestos por subsistemas, su capacidad de interrelación e interdependen-
cia, la existencia de límites que permiten o evitan la interacción entre varios departamentos y elementos de
otros subsistemas y entornos, y la existencia de entornos internos que se caracterizan con base en un grado
de apertura y cerrazón que podría diferir entre los departamentos, las unidades o, incluso, los proyectos de
sistemas.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 27
Hay varios beneficios potenciales para las organizaciones virtuales, como la posibilidad de reducir los cos-
tos derivados de instalaciones físicas, una respuesta más rápida a las necesidades de los clientes y la capacidad
de ayudar a los empleados virtuales a cumplir con sus obligaciones familiares de criar a sus hijos o a sus padres
que están envejeciendo. Lo que aún sigue abierto a investigación y debate es qué tan importante será cumplir
con las necesidades sociales de los trabajadores virtuales. Un ejemplo de necesidad de identificación tangible con
una cultura surgió cuando ciertos estudiantes inscritos en una universidad en línea sin campus físico (ni equipos
deportivos), pedían continuamente artículos como sudaderas, tazas de café y banderines que tuvieran impreso
el logotipo de la universidad virtual. Estos artículos son artefactos culturales significativos que las escuelas con-
vencionales siempre han proporcionado a sus alumnos.
Muchos analistas de sistemas y equipos de diseño ahora pueden trabajar en forma virtual y, de hecho, mu-
chos de ellos marcaron el camino que otros tipos de empleados empezaron a seguir para realizar su trabajo en
forma virtual. Algunas aplicaciones permiten que los analistas que ofrecen asistencia técnica a través de la Web
puedan “ver” la configuración de software y hardware del usuario que solicita ayuda, con lo cual se crea un
equipo virtual ad hoc compuesto por el analista y el usuario.
FIGURA 2.2
to
l departamen Las salidas de un departamento
Las salidas de nv ier te n
se co
de marketing sirven como entradas para otro,
as para el
en las entrad de tal forma que los subsistemas
de producción.
departamento están interrelacionados.
Marketing
Producción
ento
del departam
Las salidas ie rt en
ón se conv
de producci pa ra el
as
en las entrad ting.
to de marke
departamen
www.xlibros.com
28 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 2.3
uc
Una descripción de la perspectiva ro d ci
s t r i b u ci
ón
P
personal de los gerentes
Di
ón
funcionales muestra que
mpra
consideran que su propia área Co
rketi n
s
funcional es la que controla a la Ma
g
organización.
an
Fin za
s
La forma en que el gerente de marketing puede ver a la organización
anza
F in
s
uc
ro d ci rketi n
Ma
ón
P
g
mpra
Co s t r i b u ci
s
Di
ón
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 29
se pierde la confianza del usuario. Los analistas necesitan estar conscientes de la magnitud del problema al que se
enfrentan al tratar de implementar paquetes de ERP.
FIGURA 2.4
Los símbolos básicos de un
diagrama de flujo de datos.
Un proceso significa que se llevan
a cabo una o varias acciones.
www.xlibros.com
30 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 2.5
Preferencias
Un diagrama de flujo a nivel y vuelos disponibles Agente
de contexto para el sistema de Pasajero
de viajes
reservación de una aerolínea.
0
Información
Solicitud de viaje sobre los boletos
Sistema de
reservación
de la aerolínea
Reservación
del pasajero
Aerolínea
FIGURA 2.6
Diagrama Entidad-Relación que Empleado
muestra una relación uno-a-uno.
Una IÓN Un DO
S A
EN ICA PLE a
E T EFÓN a
X se se EM asign
t
TEL enlis n se una N
se ra u O. enlista asigna a SIÓ
a
p EAD EN CA.
PL para a EXT FÓNI
EM T E L E
Extensión
telefónica
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 31
Las flechas rojas no forman parte del diagrama de entidad-relación; aparecen sólo para indicar cómo leerlo.
La frase del lado derecho de la línea se lee de arriba hacia abajo de la siguiente manera: “Un EMPLEADO se
asigna a una EXTENSIÓN TELEFÓNICA”. Del lado izquierdo, leyendo de abajo hacia arriba, la flecha dice:
“Una EXTENSIÓN TELEFÓNICA se enlista para un EMPLEADO”.
De manera similar, en la figura 2.7 se muestra otra relación. Es obvio que en este diagrama se utiliza la no-
tación tipo pata de cuervo (>—+), y este ejemplo específico contiene una relación de varios a uno. Si leemos de iz-
quierda a derecha, la flecha indica: “Varios EMPLEADOS son miembros de un DEPARTAMENTO”. Si leemos
de derecha a izquierda, implica: “Un DEPARTAMENTO contiene varios EMPLEADOS”.
Observe que cuando hay una relación de varios a uno, la gramática cambia de “es” a “son” aún y cuando
se escribe el “es” en singular en la línea. La notación tipo pata de cuervo y la marca individual no indican lite-
ralmente que este extremo de la relación tenga que ser de “varios” en forma obligatoria. Lo que implican es que
este extremo puede ser cualquier cosa: uno o varios.
La figura 2.8 muestra más detalles sobre este esquema. Aquí enlistamos varias relaciones de entidades comunes.
La primera, “Un EMPLEADO se asigna a una OFICINA” es una relación de uno a uno. La segunda es una relación
de uno a varios: “Una AERONAVE DE CARGA servirá a uno o más CENTROs DE DISTRIBUCIÓN”. La tercera
es ligeramente distinta, ya que tiene un círculo en un extremo. Se puede leer así: “Un ANALISTA DE SISTEMAS
se puede asignar a VARIOS PROYECTOS”, lo cual significa que el analista se puede asignar a ningún proyecto [el
círculo (O) indica cero], a uno o a varios proyectos. De igual forma, el círculo (O) indica que es posible no tener
ningún mantenimiento programado en la siguiente relación. Recuerde que la marca corta significa uno. Por lo tanto,
podemos leerlo de la siguiente forma: “Una MÁQUINA puede o no tener asignado un MANTENIMIENTO PRO-
GRAMADO”. Observe que la línea se escribe como “tiene asignado”, pero las marcas de los extremos de la línea
indican que no se va a realizar ningún mantenimiento (O) o que se va a realizar un mantenimiento (I).
La siguiente relación establece que: “Uno o más VENDEDORES (plural de VENDEDOR) se asignan a uno
o más CLIENTEs”. Ésta es la clásica relación de varios a varios. La siguiente relación se puede leer así: “La
OFICINA PRINCIPAL puede tener uno o varios EMPLEADOs”, o “Uno o más EMPLEADOs pueden asignarse
o no a la OFICINA PRINCIPAL”. Una vez más, los símbolos I y O juntos implican una situación booleana; en
otras palabras, uno o cero.
La relación final que se muestra en esta figura se puede leer así: “Varios PASAJEROs van a volar a varios
DESTINOs”. Algunas personas prefieren usar este símbolo [> —+] para indicar una condición de “varios” obliga-
toria (¿sería posible tener sólo un pasajero o sólo un destino?). Aún así, algunas herramientas CASE como Vi-
sible Analyst no ofrecen esta posibilidad, ya que es suficiente con la condición opcional de uno o varios que se
muestra en la relación VENDEDOR-CLIENTE.
Hasta ahora hemos modelado todas nuestras relaciones mediante un solo rectángulo simple y una línea. Este
método funciona bien cuando examinamos las relaciones de cosas reales, como personas, lugares y cosas. Pero
FIGURA 2.7
OS Un diagrama de entidad-relación
AD
M PLE de un que muestra una relación de varios
E ros
ios b TO. a uno.
Var miem AMEN
n
so PAR T
DE
es miembro de
Empleado Departamento
contiene
NTO
TA ME s
o
PAR ari
DE ne v S.
Un ontie ADO
c PLE
EM
www.xlibros.com
32 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 2.8
se asigna a
En los diagramas E-R se utilizan Empleado Oficina
es ocupada por
tres tipos distintos de entidades.
Analista de es asignado a
Proyecto
sistemas será desarrollado por
se asigna a
Vendedor Cliente
es llamado por
tiene
Oficina principal Empleado
se asigna a
va a volar a
Pasajero Destino
será visitado por
algunas veces creamos elementos en el proceso de desarrollo de un sistema de información. Algunos ejemplos
son facturas, recibos, archivos y bases de datos. Por ejemplo, cuando queremos describir la forma en que se rela-
ciona una persona con un recibo, es conveniente indicar el recibo de una manera distinta, como se muestra en la
figura 2.9, en forma de entidad asociativa.
Una entidad asociativa puede existir sólo si está conectada con por lo menos otras dos entidades. Por esta
razón algunos la llaman gerundio, cruce, intersección o entidad concatenada. Esta formulación tiene sentido, ya
que un recibo no sería necesario a menos que hubiera un cliente y un vendedor para realizar la transacción.
La entidad atributiva es otro tipo de entidad. Cuando un analista quiere mostrar datos que dependen por com-
pleto de la existencia de una entidad fundamental, hay que utilizar una entidad atributiva. Por ejemplo, si una bi-
FIGURA 2.9
Tres tipos diferentes de entidades
Entidad Por lo general una entidad real:
utilizadas en diagramas E-R fundamental una persona, lugar o cosa
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 33
FIGURA 2.10
Cliente El primer intento para dibujar un
diagrama E-R.
í va
obtiene Aqu imer
hace una r
una mi p to.
reservación n Ken
reservación in e
t
para
para
Concierto/Show
blioteca tiene varias copias del mismo libro, se puede utilizar una entidad atributiva para designar qué copia del
libro se va a sacar. La entidad atributiva es útil para mostrar grupos de datos repetitivos. Por ejemplo, suponga que
vamos a modelar las relaciones que existen cuando un patrocinador obtiene boletos para un concierto o show. Al
principio las entidades parecen obvias: “Un CLIENTE y un CONCIERTO/SHOW”, como se muestra en la figura
2.10. ¿Qué tipo de relación existe? A primera instancia, el CLIENTE obtiene una reservación para un CON-
CIERTO/SHOW y se puede decir que el CONCIERTO/SHOW hizo una reservación para un CLIENTE .
Desde luego que el proceso no es tan simple, por lo que el diagrama E-R tampoco necesita ser así de simple.
En realidad el CLIENTE hace una RESERVACIÓN, como se muestra en la figura 2.11. La RESERVACIÓN es
para un CONCIERTO/SHOW. El CONCIERTO/SHOW contiene la RESERVACIÓN y la RESERVACIÓN está
a nombre del CLIENTE. Agregamos una entidad asociativa en este caso ya que se creó una RESERVACIÓN de-
bido a que el sistema de información requiere que se relacionen el CLIENTE y el CONCIERTO/SHOW.
FIGURA 2.11
Cliente Cómo mejorar el diagrama E-R al
agregar una entidad asociativa
llamada RESERVACIÓN.
está a
nombre hace
de
gué
Agre ntidad
a e
un ativa.
i Julie
Reservación a c
s o
es
tiene para un
Concierto/Show
www.xlibros.com
34 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Podemos ver de nuevo que este proceso es bastante simple, pero como los conciertos y shows tienen varias
presentaciones, en la figura 2.12 dibujamos una vez más el diagrama E-R. Ahora agregamos una entidad atribu-
tiva para manejar las diversas presentaciones del CONCIERTO/SHOW. En este caso se hace la RESERVACIÓN
para una PRESENTACIÓN específica y la PRESENTACIÓN es una de varias que pertenecen a un CONCIERTO/
SHOW específico. A su vez, el CONCIERTO/SHOW tiene varias presentaciones y una PRESENTACIÓN tiene
una RESERVACIÓN que está a nombre de un CLIENTE específico.
A la derecha de este diagrama E-R hay un conjunto de atributos de datos que conforman cada una de las en-
tidades. Algunas entidades pueden tener atributos en común. Es posible realizar búsquedas con los atributos que
están subrayados. Los atributos se denominan claves y los describiremos en el capítulo 13.
A menudo los diseñadores de sistemas utilizan diagramas E-R para ayudar a modelar el archivo o la base de
datos. Sin embargo, es aun más importante que el analista de sistemas comprenda lo más pronto posible tanto
las entidades como las relaciones en el sistema organizacional. Al realizar bosquejos de algunos diagramas E-R
básicos, el analista necesita:
1. Enlistar las entidades en la organización para obtener una mejor comprensión de la misma.
2. Elegir las entidades clave para reducir el alcance del problema a una dimensión manejable y significativa.
está
a nombre hace
de
Reservación-número
Cliente-nombre
Reservación
Presentación-número
Concierto/Show
Fecha
Hora
Ubicación
se Precio
tiene hace
para
Presentación-número
Concierto/Show
Presentación
Fecha
Hora
Ubicación
Precio-opciones
tiene pertenece a
Concierto/Show
Concierto-detalles
Concierto/Show
Fechas-del-evento
Ubicación
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 35
ATRACTIVO DE LA MAC
Microsoft Visio facilita al analista de sistemas la tarea de dibujar diagramas E-R, así como la mayoría de los diagramas
que se encuentran en este libro, pero está disponible sólo para PC. Los usuarios de equipos Mac tienen una alternativa:
OmniGraffle Professional. Este paquete de software es más fácil de usar que Microsoft Visio, ya que su interfaz es
más uniforme e intuitiva, y se opera arrastrando y colocando.
También incluye una “guía inteligente” que utiliza marcadores de distancia desplegables para ayudar a colocar
los símbolos en los lugares correctos. OmniGraffle tiene integrados muchos símbolos como los que se utilizan en los
diagramas E-R, pero también permite al usuario acceder a una biblioteca de terceros conocida como Graffletopia
para buscar símbolos de UML y otros especializados.
FIGURA 2.MAC
OmniGraffle de Omni Group es un paquete de dibujo poderoso y fácil de usar.
www.xlibros.com
36 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
hace; es decir, es un modelo lógico del sistema (en el capítulo 7 veremos más detalles sobre los modelos lógi-
cos o conceptuales). El modelo de caso de uso presenta al sistema desde la perspectiva de un usuario fuera del
mismo (por ejemplo, los requerimientos del sistema).
Un analista desarrolla casos de uso en un esfuerzo de cooperación con los expertos de negocios que ayudan
a definir los requerimientos del sistema. El modelo de caso de uso provee un medio efectivo de comunicación
entre el equipo de negocios y el equipo de desarrollo. Un modelo de caso de uso particiona la forma en que tra-
baja el sistema en comportamientos, servicios y respuestas (los casos de uso) que sean importantes para los usua-
rios del sistema.
Desde la perspectiva de un actor (o usuario), un caso de uso debe producir algo de valor. Por lo tanto, el ana-
lista debe determinar qué es importante para el usuario y debe recordar incluirlo en el diagrama del caso de uso.
Por ejemplo, ¿introducir una contraseña es algo de valor para el usuario? Tal vez se deba incluir si al usuario le
preocupa la seguridad o si es algo imprescindible para el éxito del proyecto.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 37
FIGURA 2.13
Relación Símbolo Significado
Algunos componentes
Para conectar un actor con un caso de uso se utiliza una línea de los diagramas de
Comunica
sin puntas de flecha. caso de uso que
muestran a los actores,
<< Incluye >> Un caso de uso contiene un comportamiento común para los casos de uso y las
Incluye
más de un caso de uso. La flecha apunta al caso de uso relaciones para un
común. ejemplo de inscripción
de estudiantes.
<< Extiende >> Un caso de uso distinto maneja las excepciones del caso
Extiende
de uso básico. La flecha apunta del caso de uso extendido
al básico.
se utilizan para dibujar diagramas de cada uno de los cuatro tipos de relaciones de comportamiento. A continua-
ción describiremos estas cuatro relaciones.
COMUNICACIÓN Esta relación de comportamiento se utiliza para conectar un actor con un caso de uso. Recuerde
que la tarea del caso de uso es proporcionar cierto tipo de resultado que sea benéfico para el actor en el sistema.
Por lo tanto, es importante documentar estas relaciones entre los actores y los casos de uso. En nuestro primer
ejemplo, un Estudiante se comunica con Inscribir en el curso. En los diagramas de casos de uso de la figura
2.14 se muestran ejemplos de algunos componentes de un ejemplo de inscripción de estudiantes.
INCLUSIÓN Esta relación (también conocida como relación de usos) describe la situación en la que un caso de
uso contiene comportamiento común para más de un caso de uso. En otras palabras, el caso de uso común
se incluye en los otros casos de uso. Una flecha punteada que apunta al caso de uso común indica la relación de
inclusión. Un ejemplo sería un caso de uso Pagar cuotas de estudiantes que se incluye en Inscribir en el curso
y Hacer arreglos de hospedaje, ya que en ambos casos los estudiantes deben pagar sus cuotas. Varios casos de
uso pueden usar esto. La flecha apunta hacia el caso de uso común.
FIGURA 2.14
Ejemplos de casos de uso y
Inscribir relaciones de comportamiento
lu ye >> en el curso
<< inc para la inscripción de estudiantes.
Inscribir
en el Pagar cuotas
curso de estudiantes
<< inclu
ye >>
Hacer arreglos
de hospedaje
Estudiante
Relación de Relación
comunicación de inclusión
Estudiante de Estudiante
medio tiempo
Relación de Relación
generalización de extensión
www.xlibros.com
38 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
EXTENSIÓN Esta relación describe la situación en la que un caso de uso posee el comportamiento que permite al
nuevo caso de uso manejar una variación o excepción a partir del caso de uso básico. Por ejemplo, el caso de uso
extendido Seguro médico de estudiantes extiende el caso de uso básico Pagar cuotas de estudiantes. La flecha
va del caso de uso extendido al caso de uso básico.
GENERALIZACIÓN Esta relación implica que una cosa es más común que otra. Esta relación puede existir entre
dos actores o dos casos de uso. Por ejemplo, un Estudiante de medio tiempo generaliza a un Estudiante.
De manera similar, algunos de los empleados de la universidad son profesores. La flecha apunta a la cosa
general.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 39
FIGURA 2.15
Un diagrama de caso de uso que
Planear
la provisión representa al sistema utilizado
de alimentos para planear una conferencia.
Proveedor
de alimentos Organizar
orador
Presidente
Reservaciones
de hotel
Registrarse
para la conferencia
<<
ex
tie
nd
e>
>
Organizar la
traducción
de idiomas
Participante
describen variaciones sobre el comportamiento. Los escenarios de casos de uso pueden describir lo que ocurre al
comprar un artículo agotado, o si una empresa de tarjetas de crédito rechaza la compra solicitada por un cliente.
No hay un formato estandarizado para los casos de uso, por lo que cada organización tiene que especificar
los estándares a incluir. A menudo, los casos de uso se documentan mediante una plantilla de documento de caso
de uso predeterminada por la organización, que facilita la lectura de los casos de uso y provee información estan-
darizada para cada caso de uso en el modelo.
www.xlibros.com
40 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
lapso de 2 a 20 minutos. Algunos ejemplos son registrar un estudiante que desea continuar, agregar un nuevo
cliente, colocar un artículo en un carrito de compras y pasar a pagar.
4. Índigo o pez es un caso de uso que muestra muchos detalles, a menudo a un nivel funcional o subfuncional.
Algunos ejemplos son elegir una clase, pagar las cuotas académicas, buscar el código de aeropuerto para una
ciudad y producir una lista de clientes después de introducir un nombre.
5. Negro o almeja, como en el fondo del océano. Éstos son los casos de uso más detallados, a un nivel de sub-
función. Algunos ejemplos podrían ser validar un inicio de sesión seguro, agregar un nuevo campo mediante
HTML dinámico o usar Ajax para realizar una pequeña parte de una página Web.
En la figura 2.16 se muestra un ejemplo de escenario de caso de uso. Algunas de las áreas que se incluyen
son opcionales y tal vez no todas las organizaciones las utilicen. Las tres áreas principales son:
1. Un encabezado de área que contiene los identificadores e iniciadores del caso.
2. Los pasos realizados.
3. Un área de pie de página que contiene precondiciones, suposiciones, preguntas y demás información relacionada.
FIGURA 2.16
Un escenario de caso de uso se
divide en tres secciones: Nombre del caso de
uso: Registrarse para la
identificación e iniciación; pasos conferencia
Área:
realizados; y condiciones, Planeación de la con ID Único: Conf RG 003
ferencia
Actor(es):
suposiciones y preguntas. Participante
Interesados:
Patrocinador de la
conferencia, oradores
Nivel: de la conferencia
Azul
Descripción:
Permitir que el par
ticipante de la con
Evento desencadenad ferencia se registre
or: El participante utiliza en línea mediante
y hace clic en el botó el sitio Web de registro para la conferencia un sitio Web seguro
n .
Tipo de desencadenad de inic io de sesión. , introduce su ID de
or: usuario y su contraseña
Externo ,
Temporal
Pasos realizados (rut
a principal)
1. El participante inic Información para los
ia sesión mediante pasos
el servidor Web seg
2. Se lee el registro uro. ID de usuario, contras
del participante y se eña
verifica su contraseña
3. Se muestra la info . Registro del partici
rmación del partici pante, ID de usuario
en la página Web de pante y la sesión , contraseña
registro. Registro del partici
pante, registro de la
4. El participante intr sesión
oduce su información
Web de registro y hac en el formulario
e clic en el botón Env Formulario Web de
iar. registro
5. Se valida la info
rmación de registro
en el servidor Web.
6. Se muestra la pág Formulario Web de
ina Confirmación de registro
la información de regi registro para confirm
stro. ar Página Web de con
firmación
7. Se hace un carg
o a la tarjeta de créd
a las cuotas de regi ito equivalente
stro.
Página Web segura
8. Se escribe el regi para tarjeta de créd
stro en el Diario de ito
agregar registros.
9. Se actualiza el regi Página Web de con
stro en el Archivo mae firmación
stro de registros.
10. Se actualiza el Página Web de confirm
registro de la sesión ación, registro del proc
seleccionada en el para cada sesión eso de registro
Archivo maestro de Pág ina Web de confirm
sesiones. ación, registro de la
11. Se actualiza el sesión
registro para el par
maestro de participan ticipante en el Arc
tes. hivo Página Web de con
firmación, registro
12. Se envía la pág de participantes
ina Web de Confirm
al participante. ación de registro exit
oso Número de confirmació
n del registro en el proc
Precondiciones: eso de registro
El participante ya se
registró y creó una
Postcondiciones: cue nta de usuario.
El participante se regi
stró con éxito para
Suposiciones: la conferencia.
El participante tien
e un navegador Web
Garantía de éxito: , además de un ID
de usuario y contras
El participante se regi eña válidos.
stró para la confere
Garantía mínima: ncia y está inscrito
El participante pud en todas las sesione
o iniciar sesión. s seleccionadas.
Requerimientos cum
plidos: Permitir que
los participantes de
Cuestiones pendien la conferencia se regi
tes: stren mediante un
¿Cómo se debe man sitio Web seguro.
ejar una tarjeta de
crédito rechazada?
Prioridad:
Alta
Riesgo:
Medio
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 41
La primer área (identificadores e iniciadores del caso de uso) orienta al lector y contiene el nombre del
caso de uso junto con un ID único: el área de aplicación o sistema al que pertenece este caso de uso; los actores
involucrados en el caso de uso; y los interesados que tienen un alto nivel de interés en el caso de uso. Algunos
interesados nunca interactúan en forma directa con el sistema, como los accionistas, el consejo de directores o el
gerente de ventas. Cada actor principal es un interesado, pero no se enlista en el área de interesados. Se incluye
el nivel (azul, cometa, etc.) y una breve descripción de lo que logra el caso de uso.
El encabezado concluye con el evento iniciador (desencadenador); es decir, lo que ocasionó que empezara
el caso de uso, junto con el tipo de desencadenador, ya sea externo o temporal. Los eventos externos son los
que inicia un actor, ya sea una persona u otro sistema que solicita información, como el sistema de reserva-
ciones de una aerolínea que solicita información sobre los vuelos de un sistema de aerolíneas. Los eventos
temporales son aquellos que se desencadenan o empiezan debido al tiempo. Hay eventos que ocurren a una
hora específica, como enviar correo electrónico sobre ofertas especiales una vez a la semana los domingos en
la tarde, enviar facturas en un día específico o generar estadísticas gubernamentales en una fecha especificada
cada trimestre.
La segunda área del caso de uso incluye los pasos realizados y la información requerida para cada uno de
ellos. Estos enunciados representan el flujo estándar de eventos y los pasos que se llevaron a cabo para completar
con éxito el caso de uso. Es conveniente escribir un caso de uso para la ruta principal y después escribir uno para
cada una de las rutas alternativas por separado, en vez de utilizar instrucciones IF...THEN. Los pasos se enume-
ran con un entero y pueden provenir de una entrevista detallada con los usuarios, o se pueden derivar de historias
de modelado ágil (como veremos en el capítulo 6). Hay que revisar estos pasos con los usuarios para aclarar todo
el proceso.
El analista debe examinar cada uno de los pasos y determinar la información requerida para cada uno. Si
no puede determinar la información, debe programar una entrevista de seguimiento con el usuario. Algunas des-
cripciones de casos de uso incluyen extensiones o escenarios alternativos, con las excepciones como secciones
adicionales que siguen el flujo estándar de eventos. Éstas se enumeran con un entero, un punto decimal y otro
entero, como 3.1, 3.2, 3.3, etcétera (estos pasos pueden o no utilizarse). Los analistas y los usuarios pueden orga-
nizar lluvias de ideas para ver qué puede fallar en la ruta principal y tal vez para descubrir detalles y condiciones
importantes. Es necesario trabajar con los usuarios para determinar qué hacer cuando ocurran estas condiciones.
Esto ayuda a detectar errores en las primeras etapas del ciclo de vida.
La figura 2.17 muestra cómo se pueden incluir escenarios lógicos y alternativos en la sección intermedia de
un caso de uso. En este ejemplo de la aerolínea podemos observar que el paso 1 está compuesto de pasos más pe-
queños, a muchos de los cuales se les antepone un “si”. Estos pasos siguen en la ruta principal, pero ocurren sólo
si se cumple la condición. Por ejemplo, si hay muchos aeropuertos que dan servicio a una cuidad, entonces se
mostrarán todos los aeropuertos. Aquí también pueden aparecer las extensiones o escenarios alternos. Para esta
aerolínea, otros escenarios incluyen la selección de vuelos, la selección de asientos y la selección de comidas.
Los casos de uso pueden incluir también pasos iterativos o de ciclos.
La tercera área del caso de uso incluye:
Precondiciones, o la condición del sistema antes de que se pueda llevar a cabo el caso de uso, que puede ser
otro caso de uso. Un ejemplo podría ser, “El espectador inició sesión con éxito en el sistema”, o podría ser la
terminación exitosa de otro caso de uso.
Postcondiciones, o el estado del sistema después de que termine el caso de uso, incluyendo los resultados
que recibieron las personas, las transmisiones a otros sistemas y los datos que se hayan creado o
actualizado. Las postcondiciones se relacionan con los objetivos o requerimientos de los usuarios a partir
de una definición del problema (como veremos en el capítulo 3) o de historias ágiles (como veremos en el
capítulo 6).
Las suposiciones que podrían afectar al método del caso de uso y que podrían estipular la tecnología
requerida, como los requerimientos mínimos de tecnología en un navegador Web o incluso una versión
específica o más reciente del mismo. Una suposición podría ser que estén habilitadas las cookies o el
JavaScript. El analista debe determinar qué hacer si no se cumplen las suposiciones. Al usar Google Maps,
el navegador Web debe tener habilitado el JavaScript. Si no está habilitado, el mapa no se mostrará. Netflix
requiere el uso de cookies. Las buenas páginas Web detectarán que no se ha cumplido una suposición y lo
notificarán al espectador mediante un mensaje, incluyendo la información sobre cómo activar las cookies o
el JavaScript para los distintos navegadores Web.
La garantía mínima es el mínimo que se prometió a los usuarios. Tal vez ellos no estén contentos con este
resultado y puede ser que no ocurra nada.
La garantía de éxito es lo que dejaría a los usuarios satisfechos: por lo general, que se haya cumplido el
objetivo del caso de uso.
Hay que atender cualquier cuestión o responder pregunta pendiente antes de implementar el caso de uso.
www.xlibros.com
42 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Selección de asientos
1. Se muestra una lista de vuelo
s
2. El cliente selecciona un vuelo
3. Se envía la solicitud a la aerolí
nea
4. Se obtienen las reservacion
es de asien
tos
5. Se muestra el gráfico de asien
tos
6. El cliente no puede encon
trar un asiento aceptable
Selección de comidas para
los vuelos internacionales
1. El cliente selecciona la comid
a de la lista desplegable
2. Lista de comidas disponible
Se actualiza el registro con s de la aerolínea
la selección de comida
Registro de comida del client
e
FIGURA 2.17
Los casos de uso pueden incluir pasos condicionales
así como extensiones o escenarios alternativos.
Una declaración opcional de prioridad del caso de uso, que puede provenir de una definición del problema o
de los requerimientos de los usuarios.
Una declaración opcional del riesgo involucrado al crear el caso de uso.
El área “requerimientos cumplidos” enlaza el caso de uso con los requerimientos u objetivos del usuario a
partir de una definición del problema. Una vez que desarrolle los casos de uso, asegúrese de repasar sus resulta-
dos con los expertos de negocios para verificar y refinar los casos de uso si es necesario.
En este escenario de caso de uso específico llamado Registrarse para la conferencia, el único actor invo-
lucrado es el Participante. El área general es Planeación de la conferencia y el caso de uso se desencadena
debido al inicio de sesión del participante en la página Web de registro. El área Pasos realizados muestra
una lista de la secuencia de eventos que deben ocurrir para un registro exitoso en la conferencia. Observe que la infor-
mación necesaria para realizar cada uno de los pasos se muestra del lado derecho, y puede incluir páginas Web y
formularios, tablas y registros de las bases de datos.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 43
El área de Precondiciones, en la sección del pie de página del escenario del caso de uso, muestra una lista
de lo que debe ocurrir antes de que el participante pueda registrarse para una conferencia. En este ejemplo, el
participante debe haber iniciado sesión ya como miembro de la sociedad, además de contar con un ID de usua-
rio y contraseña válidos. El área Postcondiciones muestra una lista de lo que ha logrado el caso de uso. El área
Suposiciones muestra una lista de las premisas básicas que el analista supone han sido cumplidas por el actor de
antemano. El área Requerimientos cumplidos muestra por qué este caso de uso es importante y necesario para
que el área de negocios pueda tener éxito. La prioridad es una indicación de los casos de uso que se deben desa-
rrollar primero y los que se pueden postergar. El riesgo es una evaluación aproximada en relación con la posibili-
dad de que surjan problemas o dificultades al desarrollar el caso de uso. En este caso, el riesgo es medio debido a
que el caso de uso de registro requiere un servidor seguro y acepta información de tarjetas de crédito.
NIVELES DE ADMINISTRACIÓN
La administración en las organizaciones existe en tres amplios niveles horizontales: control operacional, planea-
ción y control administrativo (administración de nivel medio), y administración estratégica, como se muestra en
FIGURA 2.18
• Los casos de uso comunican los requerimientos del sistema con efectividad, ya que los
diagramas se mantienen simples. Las principales razones de escribir
• Los casos de uso permiten a las personas contar historias. casos de uso son su efectividad
• Las historias de los casos de uso tienen sentido para las personas sin conocimientos técnicos. para comunicarse con los usuarios
• Los casos de uso no dependen de un lenguaje especial. y su capacidad para capturar las
• Los casos de uso pueden describir la mayoría de los requerimientos funcionales (como las historias de los usuarios.
interacciones entre los actores y las aplicaciones).
• Los casos de uso pueden describir los requerimientos no funcionales (como el rendimiento
y la capacidad de mantenimiento) a través del uso de estereotipos.
• Los casos de uso ayudan a los analistas a definir los límites.
• Los casos de uso se pueden rastrear para que los analistas puedan identificar los enlaces
entre los casos de uso y otras herramientas de diseño y documentación.
www.xlibros.com
44 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
O P O R T U N I D A D D E C O N S U LT O R Í A 2 . 2
la figura 2.19. Cada nivel acarrea sus propias responsabilidades y todo el trabajo para lograr las metas y objetivos
de la organización a su propio modo.
El control operacional forma el nivel inferior de la administración de tres niveles. Los gerentes de opera-
ciones toman decisiones mediante el uso de reglas predeterminadas que tienen resultados predecibles cuando se
implementan en forma correcta.
Ellos toman decisiones que afectan a la implementación en los itinerarios de trabajo, el control de inventa-
rios, los embarques, la recepción y el control de procesos como el de producción. Los gerentes de operaciones
supervisan los detalles operativos de la organización.
La administración de nivel medio forma el segundo nivel (intermedio) del sistema de administración de tres
niveles. Los gerentes de este nivel toman decisiones de planeación y control de corto plazo en relación con la
mejor forma de asignar los recursos para cumplir con los objetivos de la organización.
Sus decisiones van desde pronosticar los requerimientos de recursos a futuro, hasta resolver los problemas
de los empleados que amenazan la productividad. El dominio de la toma de decisiones de los gerentes del nivel
FIGURA 2.19
La administración en las
organizaciones existe en tres
niveles horizontales: control
operacional, planeación y control Administración
administrativo, y administración estratégica
estratégica.
Planeación y
control administrativo
Control operacional
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 45
medio puede caracterizarse de una manera conveniente como parcialmente operacional y parcialmente estraté-
gico, con fluctuaciones constantes.
La administración estratégica es el tercer nivel del control administrativo de tres niveles. Los gerentes estra-
tégicos ven hacia el futuro, más allá de la organización, y toman decisiones que guiarán a los gerentes del nivel
medio y de operación en los meses y años por venir.
Los gerentes estratégicos trabajan en un entorno de toma de decisiones muy incierto. Mediante declaracio-
nes de los objetivos y la determinación de estrategias y políticas para lograrlos, los gerentes estratégicos definen
la organización como un todo. Ellos tienen la visión más amplia, ya sea que la empresa decida desarrollar nuevas
líneas de productos, deshacerse de empresas conjuntas no rentables, adquirir otras empresas compatibles o in-
cluso permitir su propia adquisición o fusión.
Existen marcados contrastes entre las personas que toman decisiones en varias dimensiones. Por ejemplo,
los gerentes estratégicos tienen varios objetivos de decisión, mientras que los gerentes de operaciones tienen uno
solo. A menudo es difícil que los gerentes de nivel superior identifiquen los problemas, pero esto es fácil para los
gerentes de operación. Los gerentes estratégicos se enfrentan a problemas semiestructurados, mientras que
los gerentes de nivel inferior lidian la mayor parte del tiempo con problemas estructurados.
Las soluciones alternativas para un problema al que se enfrentan los gerentes estratégicos a menudo son difí-
ciles de articular, pero las alternativas con las que trabajan los gerentes de operaciones son por lo general fáciles
de enumerar. La mayoría del tiempo los gerentes estratégicos toman decisiones de una sola vez, mientras que las
decisiones que toman los gerentes de operaciones tienden a ser repetitivas.
CULTURA ORGANIZACIONAL
La cultura organizacional es un área establecida de investigación que ha crecido en forma notable en la última
generación. Así como es apropiado pensar que las organizaciones incluyen muchas tecnologías, es igual de apro-
piado verlas como anfitrionas de varias subculturas competentes.
Aún no se ha llegado a un buen acuerdo en cuanto a qué es exactamente lo que constituye una subcultura or-
ganizacional. Sin embargo, hay consenso en cuanto a que las subculturas competentes pueden estar en conflicto
al tratar de ganar partidarios de lo que consideran que debe ser la organización. Se está realizando una investiga-
ción para determinar los efectos de las organizaciones y los equipos virtuales en cuanto a la creación de subcul-
turas cuando los miembros no comparten un espacio de trabajo físico pero sí comparten tareas.
En vez de considerar la cultura como un todo, es más conveniente pensar acerca de los factores determinan-
tes que se pueden investigar sobre las subculturas, como el simbolismo verbal y no verbal. El simbolismo verbal
incluye el lenguaje compartido que se utiliza para construir, transmitir y preservar los mitos, metáforas, visiones
y humor de las subculturas. El simbolismo no verbal incluye los artefactos, ritos y ceremonias que se comparten;
www.xlibros.com
46 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
O P O R T U N I D A D D E C O N S U LT O R Í A 2 . 3
El poder de la pirámide
mendaron la creación de comités de enlace para los empleados entre
“En realidad lo admiramos”, dice Paul LeGon. Como analista
de sistemas, usted recibió una invitación para ayudar a Pyramid,
los departamentos de contabilidad, producción y marketing, de
manera que pudiéramos compartir el inventario recién computari-
Inc., una empresa editorial pequeña e independiente que se especia- zado y las cifras de ventas entre toda la organización. Ellos argu-
liza en libros de portada rústica que están fuera de la corriente do- mentaban que los comités de este tipo podrían reducir la duplicación
minante en la industria editorial. innecesaria de los resultados, y que cada área funcional se integraría
Paul continúa: “Manejamos lo que algunos consideran temas de una mejor manera con el resto de la empresa”.
marginales. Usted sabe, el poder de la pirámide, las profecías del fin Paul entra en la historia y dice: “Estuvo bien —por lo menos
del mundo y cómo vivir en forma más saludable si pensamos en el durante un tiempo y los empleados compartieron información, pero la
color rosa. Algunas veces cuando las personas ven nuestros libros, razón por la que usted está aquí es que los empleados decían que no
sólo sacuden su cabeza y dicen: ‘Hmm… un tema poco común’. tenían tiempo para las reuniones de los comités y no se sentían cómo-
Pero no somos esclavos de ninguna filosofía en especial, y hemos dos al compartir información con las personas de otros departamen-
tenido mucho éxito. Tanto así que como tengo 24 años, la gente me tos que estaban más arriba de lo que ellos estaban aquí en Pyramid”.
llama el ‘niño rey’”. Paul se detiene para descifrar su reacción. De acuerdo con Paul y Ceil, ¿cuáles fueron los efectos de
Paul continúa: “Estoy en la cima como presidente y las áreas instalar un sistema de información administrativa en Pyramid, Inc.
funcionales como editorial, contabilidad, producción y marketing en el que las personas tenían que compartir información en formas
están bajo mi cargo”. que no eran consistentes con su estructura? Proponga algunas for-
Ceil Toom, asistente de Paul, quien ha estado escuchando en mas generales de resolver este problema, de manera que los emplea-
silencio hasta ahora, irrumpe con sus comentarios: “Los últimos dos de Pyramid puedan obtener las cifras de ventas e inventario que
expertos en sistemas que hicieron un proyecto para nosotros reco- necesitan.
la ropa de los que toman decisiones y los trabajadores; el uso, la ubicación y decoración de las oficinas; y los ritua-
les para celebrar los cumpleaños, promociones y retiros de los miembros.
Las subculturas coexisten dentro de las culturas organizacionales “oficiales”. La cultura con sanciones ofi-
ciales puede prescribir un código de vestimenta, formas adecuadas de dirigirse a los superiores y a los compañe-
ros trabajadores, y formas apropiadas de lidiar con el público. Las subculturas pueden ser factores determinantes
poderosos de los requerimientos de información, disponibilidad y uso.
Los miembros de la organización pueden pertenecer a una o más subculturas dentro de la organización. Las
subculturas pueden ejercer una poderosa influencia en el comportamiento de sus miembros, incluyendo las
sanciones a favor o en contra del uso de los sistemas de información.
La acción de comprender y reconocer las subculturas organizacionales predominantes puede ayudar a los
analistas de sistemas a vencer la resistencia al cambio que surge al momento de instalar un nuevo sistema de in-
formación. Por ejemplo, el analista podría idear cierto tipo de capacitación para lidiar con cuestiones específicas
de las subculturas organizacionales. También puede ser útil identificar las subculturas para el diseño de los siste-
mas de soporte de decisiones que se ajustan a la interacción con grupos de usuarios específicos.
RESUMEN
Hay tres amplios fundamentos organizacionales que debemos tes; los sistemas cerrados no permiten el flujo libre de entradas o
considerar en el análisis y diseño de sistemas de información: el salidas. Las organizaciones y los equipos también se pueden
concepto de las organizaciones como sistemas, los diversos ni- organizar en forma virtual, de manera que sus miembros se co-
veles de administración y la cultura organizacional en general. necten por medios electrónicos sin necesidad de estar en el
Las organizaciones son sistemas complejos compuestos de mismo espacio de trabajo físico. Los sistemas de planificación
subsistemas interrelacionados e interdependientes. Además, los de recursos son sistemas de información organizacional (empre-
sistemas y subsistemas se caracterizan debido a que sus entornos sarial) integrados que se desarrollan mediante software persona-
internos existen en un continuo, desde los más abiertos hasta los lizado y propietario, para ayudar al flujo de información entre las
más cerrados. Un sistema abierto permite el paso libre de los re- áreas funcionales de la organización. Soportan una perspectiva
cursos (personas, información, materiales) a través de sus lími- de sistemas de la organización.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 47
EXPERIENCIA DE HYPERCASE® 2
www.xlibros.com
48 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
PREGUNTAS DE REPASO
1. ¿Cuáles son los tres grupos de fundamentos organizacionales que conllevan implicaciones para el desarrollo de los
sistemas de información?
2. ¿Qué significa decir que los subsistemas organizacionales están interrelacionados y son interdependientes?
3. Defina el término límite organizacional.
4. ¿Cuáles son los dos principales propósitos de la retroalimentación en las organizaciones?
5. Defina la apertura en un entorno organizacional.
6. Defina la cerrazón en un entorno organizacional.
7. ¿Cuál es la diferencia entre una organización tradicional y una virtual?
8. ¿Cuáles son los potenciales beneficios y una desventaja de una organización virtual?
9. Dé un ejemplo de la forma en que los analistas de sistemas podrían trabajar con los usuarios como un equipo virtual.
10. ¿Qué son los sistemas empresariales?
11. ¿Qué es ERP y cuál es su propósito?
12. ¿A qué problemas se enfrentan con frecuencia los analistas cuando tratan de implementar un paquete ERP?
13. ¿Cuáles son los dos símbolos en un diagrama de caso de uso y qué representan?
14. ¿Qué es un escenario de caso de uso?
15. ¿Cuáles son las tres partes principales de un escenario de caso de uso?
16. ¿Cuáles son los cuatro pasos para elaborar descripciones de casos de uso?
17. ¿Cuáles son las cinco metáforas de altitud para describir un caso de uso en distintos niveles? ¿Qué representan?
18. ¿Qué representa un proceso en un diagrama de flujo de datos a nivel de contexto?
19. ¿Qué es una entidad en un diagrama de flujo de datos?
20. ¿Qué significa el término diagrama de entidad-relación?
21. ¿Qué símbolos se utilizan para dibujar diagramas E-R?
22. Enliste los tipos de diagramas E-R.
23. ¿Cuál es la diferencia entre una entidad, una entidad asociativa y una entidad atributiva?
24. Liste los tres niveles amplios horizontales de administración en las organizaciones.
25. ¿Cómo puede ayudar la comprensión de las subculturas organizacionales en el diseño de los sistemas de información?
PROBLEMAS
1. “Es difícil determinar qué queremos. Veo lo que están haciendo nuestros competidores, las tiendas de conveniencia, y
pienso que deberíamos copiarlos. Después entran cien clientes y escucho a cada uno de ellos decir que debemos seguir
igual, con nuestra pequeña tienda, empleados amigables y cajas registradoras antiguas. Luego, cuando leo un ejemplar
del Supermarket News, dicen que la ola del futuro son las supertiendas de abarrotes, sin precios individuales etiquetados
y donde los escáneres de UPC sustituyen a los empleados. Me inclino hacia tantas direcciones que no puedo definir
realmente una estrategia para nuestra tienda de abarrotes”, admite Geoff Walsham, propietario y gerente de Jiffy Geoff’s
Grocery Store.
Aplique en un párrafo el concepto de límites organizacionales permeables para analizar el problema de Geoff en
cuanto a enfocarse en los objetivos organizacionales.
2. Escriba siete enunciados que expliquen las relaciones de derecha a izquierda en la figura 2.8.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 49
PROYECTOS EN GRUPO
1. Haga grupos de cinco personas. Asigne una persona para que actúe como el diseñador del sitio Web, una para que
escriba la copia del producto de una empresa, otra para que lleve el registro de los pagos de los clientes, una más para
que supervise la distribución y otra para atender a los clientes que tengan preguntas sobre el uso del producto. Después
seleccione un producto simple (que no tenga muchas versiones). Algunos ejemplos adecuados son una cámara digital, un
reproductor de DVD, un GPS una caja de dulces o una gorra de viaje especializada (a prueba de lluvia o para bloquear el
sol). Ahora invierta 20 minutos en tratar de explicar al diseñador del sitio Web qué debe incluir en éste. Describa en unos
tres párrafos la experiencia que tuvo su grupo en cuanto a la coordinación. Proporcione más información sobre la
capacidad de interrelación de los subsistemas en la organización (su grupo).
2. En un pequeño grupo, desarrolle un caso de uso y un escenario de caso de uso para hacer reservaciones aéreas, de hotel
y de automóvil para viajar a nivel nacional.
3. Cambie su respuesta en el Proyecto en grupo 2 para incluir viajes internacionales. ¿Cómo cambian el caso de uso y el
escenario de caso de uso?
4. Dibuje con su grupo un diagrama de flujo de datos a nivel de contexto del sistema de registro de su escuela o
universidad. Identifique cada una de las entidades y los procesos. Discuta con sus compañeros por qué parece haber
distintas formas de dibujar el diagrama; llegue a un consenso con ellos en cuanto a la mejor forma de dibujar el
diagrama y defienda su elección en un párrafo. Ahora trabaje con los miembros de su grupo y siga los pasos
apropiados para desarrollar un diagrama E-R y cree uno para el sistema de registro de su escuela o universidad.
Asegúrese de que su grupo indique si la relación que describe es de uno a uno, de uno a varios, de varios a uno o de
varios a varios.
www.xlibros.com
50 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
BIBLIOGRAFÍA SELECCIONADA
Bleeker, S.E. “The Virtual Organization”. Futurist, Vol. 28, Núm. 2, 1994, pp. 9-14.
Chen, P. “The Entity-Relationship Model—Towards a Unified View of Data”. ACM Transactions on Database Systems, Vol. 1,
marzo de 1976, pp. 9-36.
Ching, C., C. W. Holsapple y A. B. Whinston. “Toward IT Support for Coordination in Network Organizations”. Information
Management, Vol. 30, Núm. 4, 1996, pp. 179-199.
Cockburn, A. “Use Case Icons”, http://alistair.cockburn.us/Use+case+icons?version=8339&diff=8339&with=6296. Último
acceso en marzo 18, 2009.
Davis, G.B. y M. H. Olson. Management Information Systems: Conceptual Foundation, Structure, and Development, 2da. ed.
Nueva York: McGraw-Hill, 1985.
Galbraith, J. R. Organizational Design, Reading, MA: Addison-Wesley, 1977.
Kendall, K. E., J. R. Buffington y J.E. Kendall. “The Relationship of Organizational Subcultures to DSS User Satisfaction”.
Human Systems Management, marzo 1987, pp. 31-39.
Kulak, D. y E. Guiney. Use Cases: Requirement in Context, 2da. ed. Boston: Pearson Education, 2004.
PeopleSoft. Disponible en: www.peoplesoft.com/corplen/public_index.jsp. Acceso en junio 3, 2003.
Warkentin, M., L. Sayeed y R. Hightower. “Virtual Teams versus Face-to-Face Teams: An Exploratory Study of a Web-Based
Conference System”. En Emerging Information Technologies: Improving Decisions, Cooperation, and Infrastructure.
Editado por K. E. Kendall, pp. 241-262. Thousand Oaks, CA: Sage Publications, 1999.
Yager, S.E. “Everything’s Coming Up Virtual”. Disponible en: www.acm.org/crossroads/xrds4-1/organ.html. Acceso en junio
3, 2003.
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 51
EPISODIO 2
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
EE 3
Se reparó computadora
Mantenimiento
Contexto
Sistema de
inventario de
computadoras
EE 2 EE 2
Pregunta de software Respuesta a pregunta
Cuerpo Cuerpo
docente docente
1
Para obtener más detalles sobre cómo empezar a usar Visible Analyst, vea la obra de Allen Schmidt, Working with
Visible Analyst, 2da. edición (Upper Saddle River, NJ: Prentice Hall, 2004).
www.xlibros.com
52 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA E2.2
Sistema operativo Distribuidor
Diagrama de entidad-relación del tiene provee garantía
sistema actual.
se encuentra
dentro de tiene
Cuarto Software
FIGURA E2.3
Diagrama de caso de uso para el
sistema de cómputo de la CPU.
Agregar
nueva computadora
Departamento de Mantenimiento
embarques/recepción
Agregar software
Producir informe de
inversión de hardware
Crear categoría
de software
Producir informe de
referencia cruzada
de hardware y software
Consultar clases
de capacitación
Administración
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 53
clic en el símbolo del caso de uso para mostrar la descripción del caso de uso en el repositorio que aparece
en la figura E2.4.
“Ya tienes un buen comienzo aquí”, continúa Chip a medida que echa un vistazo a la descripción del
caso de uso. “Esto nos ayuda a comprender las actividades que se realizan. Vamos a trabajar y ver qué hay
que hacer ahora”.
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver e imprimir el diagrama de flujo de datos a nivel de
contexto para el sistema de inventario de computadoras, como lo hicieron Chip y Anna.
E-2. Use la característica Repository (Repositorio) o la página Web Repository (Repositorio Web) para ver
la entrada para el proceso central.
E-3. Use Microsoft Visio o Visible Analyst para ver e imprimir el diagrama de entidad-relación para el
sistema de inventario de computadoras.
E-4. Explique por qué las entidades externas en el diagrama a nivel de contexto no se encuentran en el
diagrama de entidad-relación. FIGURA E2.4
Escenario de caso de uso para el
sistema computacional de la CPU.
www.xlibros.com
54 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
E-5. Explique por qué las entidades ADMINISTRACIÓN y CUERPO DOCENTE se encuentran en ambos lados del proceso
en el diagrama a nivel de contexto.
E-6. Use Microsoft Visio o Visible Analyst para ver e imprimir el diagrama de caso de uso para el sistema de inventario de
computadoras.
E-7. Agregue los siguientes actores y casos de uso al diagrama de casos de uso:
a. El actor CUERPO DOCENTE al lado izquierdo del diagrama de casos de uso.
b. Conectar el actor CUERPO DOCENTE con el caso de uso CONSULTAR CLASES DE CAPACITACIÓN.
c. Como las computadoras pueden tener software instalado para un laboratorio computacional específico, el personal
de soporte de oficina puede hacerse cargo de instalar software en las. Conecte el actor SOPORTE DE OFICINA al
caso de uso AGREGAR SOFTWARE.
d. Agregue dos nuevos casos de uso debajo del caso de uso CONSULTAR CLASES DE CAPACITACIÓN: CONSUL-
TAR EXPERTO DE SOFTWARE y debajo de éste, CONSULTAR INFORMACIÓN DE SOFTWARE.
e. Conecte el actor CUERPO DOCENTE a los casos de uso CONSULTAR EXPERTO DE SOFTWARE y CONSUL-
TAR INFORMACIÓN DE SOFTWARE.
f. Conecte el actor ADMINISTRACIÓN al caso de uso CONSULTAR EXPERTO DE SOFTWARE.
E-8. Agregue el caso de uso INSTALAR COMPUTADORA DE ESCRITORIO al área superior derecha del diagrama. Este
caso de uso extiende al caso de uso AGREGAR COMPUTADORA.
E-9. Agregue una descripción para el caso de uso AGREGAR SOFTWARE. Esta descripción debe contener la siguiente in-
formación:
a. Obtenga el nombre del caso de uso y los actores del diagrama de casos de uso. Los interesados y el nivel son los
mismos que en la figura E2.3.
b. La descripción debe ser: Agregar nuevo software a la tabla Software de la base de datos e imprimir un listado de
instalación.
c. La actividad empieza (se desencadena) cuando el usuario hace clic en el elemento de menú Add Software (Agregar
software).
d. Los pasos realizados y la información para los pasos son:
e. Las precondiciones son el software que se recibió. Las postcondiciones son que el software se agregó a la base de
datos y se crearon los informes. Las suposiciones son que el usuario inició sesión con éxito y tiene acceso a la pan-
talla Add Software (Agregar software). Una garantía de éxito es que se haya agregado el software a la base de datos
y se haya impreso el informe requerido. Una garantía mínima es que se haya recibido el software. Los objetivos
cumplidos son agregar e instalar nuevo software. La cuestión pendiente es cómo determinar qué software instalar en
cuáles equipos. La prioridad es alta y el riesgo es medio.
E-10. Escriba la descripción para el caso de uso PRODUCIR INFORME DE REFERENCIA CRUZADA DE HARDWARE Y
SOFTWARE. Use el diagrama de casos de uso para determinar la información del encabezado y haga todas las suposi-
ciones razonables. Los pasos serían leer un registro de software, usar esa información para leer la tabla relacional de
hardware-software y después leer el registro de hardware. Use el registro de hardware para imprimir una línea en la que
se acumulen los totales. Imprima subtotales y totales generales. Ésta es una actividad de nivel medio y bajo riesgo. Las
precondiciones son que la información se debe haber agregado antes a las tablas de base de datos apropiadas. Las postcon-
diciones son que se imprimió el informe. Las suposiciones son que toda la información en las tablas de base de datos es
correcta. Una garantía de éxito sería que se haya creado el informe con éxito. Una garantía mínima sería que no se haya
podido imprimir el informe. Los objetivos cumplidos son producir información sobre el software instalado en cada má-
quina. Las cuestiones pendientes son: ¿Qué pasa si el software es antiguo y no está instalado actualmente en ninguna
máquina? ¿Cómo se debe producir el informe: impreso, en un archivo PDF o habría que consultar qué paquete de soft-
ware se debe utilizar?
www.xlibros.com
CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 55
E-11. Escriba la descripción para el caso de uso PRODUCIR INFORME DE INVERSIÓN DE HARDWARE. Use el diagrama
de casos de uso para definir la información del encabezado. Los pasos implican leer cada registro de hardware, contar el
número de equipos y calcular el monto total invertido en ellos para cada modelo de computadora. Calcular subtotales
para cada marca de computadora y un gran total al final del informe. Toda la información proviene de la tabla de base de
datos Hardware Master (Archivo maestro de hardware). Haga todas las suposiciones razonables en cuanto a las precon-
diciones, postcondiciones, suposiciones, garantía de éxito, garantía mínima, objetivos cumplidos, cuestiones pendientes,
prioridad y riesgo.
E-12. Escriba la descripción para el caso de uso CONSULTAR CLASES DE CAPACITACIÓN. Use el diagrama de casos de
uso para definir la información del encabezado. Los pasos implican introducir información en el formulario Web, validar
la información y almacenar los datos en una tabla de base de datos llamada Training Request (Solicitud de capacitación).
Haga todas las suposiciones razonables en cuanto a las precondiciones (por ejemplo, si el software tiene que estar com-
prado de antemano), postcondiciones, suposiciones, garantía de éxito, garantía mínima, objetivos cumplidos, cuestiones
pendientes, prioridad (ésta sería una tarea de alta prioridad) y riesgo.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios. O también pueden resolver muchos de los ejercicios a mano si no tienen el software a su dis-
posición.
www.xlibros.com
56 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
CAPÍTULO 3
Administración de proyectos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender cómo se inician y seleccionan los proyectos, definir un problema de
negocios y determinar la viabilidad de un proyecto propuesto.
2. Hacer un inventario y valorar los componentes actuales y propuestos de hardware y
software, y determinar la forma en que brindan soporte a las interacciones de los
humanos con la tecnología.
3. Evaluar las soluciones considerando ventajas y desventajas de crear software personalizado,
comprar software COTS y subcontratar un proveedor de servicios de aplicaciones.
4. Pronosticar y analizar los costos y beneficios tangibles e intangibles.
5. Planear un proyecto al identificar las actividades y programarlas.
6. Administrar los miembros del equipo y las actividades de análisis y diseño, de manera
que se cumplan los objetivos del proyecto sin exceder el tiempo programado.
7. Escribir y presentar en forma profesional una propuesta de sistemas efectiva, con
énfasis tanto en el contenido como en el diseño.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 57
yectos de sistemas por dos amplios tipos de razones: 1) porque experimentan problemas que se prestan por sí
solos a las soluciones de sistemas y 2) porque reconocen oportunidades para mejorar mediante la actualización o
modificación de los sistemas existentes, o la instalación de sistemas nuevos. Ambas situaciones pueden surgir a
medida que la organización se adapta y hace frente a los cambios naturales y evolucionarios.
Problemas en la organización
A los gerentes no les gusta que su organización tenga problemas y mucho menos hablar sobre ellos o compar-
tirlos con alguien externo. Sin embargo, los buenos gerentes están conscientes de que es imprescindible reconocer
los síntomas de los problemas o, en una etapa posterior, diagnosticar los problemas en sí y luego confrontarlos, si
quieren que su empresa siga funcionando con el mayor potencial posible.
Los problemas salen a la superficie de muchas formas. Una manera de conceptualizar qué son los problemas
y cómo surgen es considerarlos como situaciones en las que nunca se cumplieron los objetivos o dejaron de cum-
plirse en algún punto. La retroalimentación práctica proporciona información sobre el hueco entre el rendimiento
actual y el esperado, y, de esta forma, ayuda a destacar los problemas.
En algunos casos, los problemas que requieren de los servicios de los analistas de sistemas se descubren
debido a que no se están cumpliendo las medidas de rendimiento. Los problemas (o síntomas de ellos) con pro-
cesos que no son visibles en el proceso de salida y que podrían requerir la ayuda de un analista de sistemas; in-
cluyen errores excesivos y un trabajo que se desempeña con mucha lentitud, en forma incompleta, incorrecta o
que simplemente no se lleva a cabo. Otros síntomas de los problemas se hacen evidentes cuando las personas no
cumplen con los objetivos de rendimiento de referencia. Los cambios en el comportamiento de los empleados,
como niveles altos e inusuales de ausentismo, una gran inconformidad en el trabajo o mucha rotación de personal
son factores que alertan a los gerentes sobre problemas potenciales. Cualquiera de estos cambios, por sí solos o
combinados, podría ser motivo suficiente para solicitar la ayuda de un analista de sistemas.
Aunque las dificultades como las que acabamos de describir ocurren en la organización, la retroalimenta-
ción acerca de la forma en que la organización cumple con los objetivos designados puede provenir del exterior,
en forma de quejas o sugerencias de los clientes, distribuidores o proveedores, además de la pérdida de ventas o
una reducción inesperada en las mismas. Esta retroalimentación proveniente del entorno externo es en extremo
importante y no debe ignorarse.
En la figura 3.1 se muestra un resumen de síntomas de problemas y metodologías útiles para detectarlos.
Note que revisar la salida, observar o investigar el comportamiento de los empleados y escuchar la retroalimen-
tación de las fuentes externas son valiosas herramientas para detectar problemas. Al reaccionar a las historias de
los problemas en la organización, el analista de sistemas desempeña los roles de consultor, experto de soporte y
agente de cambio, como vimos en el capítulo 1. Como podría esperar, los roles para el analista de sistemas cam-
bian sutilmente cuando se inician los proyectos, ya que el enfoque está en las oportunidades de mejorar en vez de
estar en la necesidad de resolver los problemas.
FIGURA 3.1
Para identificar los problemas Busque estas señales específicas:
Comprobar la salida, observar el
Revisar la salida y compararla con los Demasiados errores comportamiento de los empleados
criterios de rendimiento. El trabajo se completa con lentitud y escuchar la retroalimentación
El trabajo se hace en forma incorrecta son todas formas de ayudar al
El trabajo se hace en forma incompleta analista a destacar los problemas y
No se hace ningún trabajo oportunidades de sistemas.
www.xlibros.com
58 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
O P O R T U N I D A D D E C O N S U LT O R Í A 3 . 1
Por lo general, la definición de un problema contiene cierta clase de declaración del mismo, sintetizada en
uno o dos párrafos. A ésta le siguen una serie de cuestiones o piezas independientes importantes del problema.
Estas cuestiones van seguidas de una serie de objetivos o metas que coincidan con cada uno de los puntos es-
tablecidos en las cuestiones. Las cuestiones son la situación actual; los objetivos son la situación deseada. Los
objetivos pueden ser muy específicos o se pueden redactar mediante una declaración general.
He aquí algunos ejemplos de preguntas de negocios relacionadas con los objetivos de una empresa:
Sobra decir que el analista de sistemas debe comprender la forma en que funciona la empresa.
La última parte de la definición del problema contiene los requerimientos, las cosas que se deben lograr,
junto con las posibles soluciones y las restricciones que limitan el desarrollo del sistema. La sección de requeri-
mientos puede incluir seguridad, capacidad de uso, requerimientos gubernamentales, etcétera. A menudo las res-
tricciones incluyen la palabra no para indicar una limitación, y pueden contener restricciones en el presupuesto o
límites de tiempo.
La definición del problema se produce después de terminar con las entrevistas, las observaciones y el aná-
lisis de los documentos con los usuarios. El resultado de recopilar esta información es una enorme cantidad de
hechos y opiniones importantes que debe sintetizarse. El primer paso para producir la definición del problema es
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 59
encontrar varios puntos que se puedan incluir en una cuestión. Los puntos importantes se pueden identificar en la
entrevista de distintas formas:
1. Los usuarios pueden identificar una cuestión, asunto o tema que se repita varias veces; en ocasiones pueden
ser distintas personas en varias entrevistas.
2. Los usuarios pueden comunicar las mismas metáforas, como decir que la empresa es un viaje, un juego de
guerra, un organismo, una máquina, etcétera.
3. Los usuarios pueden hablar mucho sobre un tema.
4. Los usuarios le pueden decir abiertamente: “Éste es un problema importante”.
5. Los usuarios pueden comunicar la importancia mediante el lenguaje corporal o hablar tajantemente sobre
una cuestión.
6. El problema puede ser lo primero que mencione el usuario.
Una vez creadas las cuestiones hay que declarar los objetivos. A veces, el analista debe realizar una entre-
vista de seguimiento para obtener información más precisa sobre los objetivos. Una vez declarados éstos, hay
que determinar la importancia relativa de las cuestiones o de los objetivos. Si no hay suficientes fondos para de-
sarrollar el sistema completo, primero es necesario completar los objetivos más críticos. Los usuarios son quie-
nes pueden identificar mejor los objetivos más críticos (con la ayuda de los analistas), ya que son expertos de
dominio en su área de negocios y saben cómo trabajar mejor con las tecnologías en la organización.
Una de las técnicas es pedir a los usuarios que asignen una ponderación para cada cuestión u objetivo del
primer borrador de la definición del problema. Es un juicio subjetivo por parte del usuario, pero si varios de
ellos asignan ponderaciones y se obtiene un promedio de todas, el resultado podría reflejar mejor la situación.
Después de determinar las ponderaciones se modifica la secuencia del orden de las cuestiones y objetivos de la
definición del problema en orden de mayor a menor importancia. Existe software como Expert Choice (www.
expertchoice.com) y otros paquetes de software de soporte de decisiones que pueden ayudar con los procesos de
pesar y asignar prioridades a los objetivos.
Además de analizar los datos y entrevistar personas, trate de presenciar el problema por su cuenta. Al anali-
zar la misma situación, tal vez un empleado pueda ver un problema en forma muy distinta a un analista de siste-
mas. Esto también ofrece a los analistas la oportunidad de confirmar sus hallazgos. De esta forma utilizan varios
métodos, con lo cual fortalecen el caso para tomar la acción apropiada.
UN EJEMPLO DE DEFINICIÓN DE PROBLEMA: EL SERVICIO DE BANQUETES CATHERINE. El Servicio de banquetes
Catherine es una pequeña empresa que provee servicios de alimentos, recepciones y banquetes para reuniones de
negocios y sociales como comidas formales y bodas. El amor de Catherine por la cocina y su talento para preparar
platillos finos inspiraron este negocio. Al principio era una pequeña empresa con unos cuantos empleados que
trabajaban en pequeños proyectos. Catherine se reunía con los clientes para determinar el número de personas,
el tipo de alimentos y demás información necesaria para dar servicio a un evento. Su reputación como excelente
proveedora de banquetes de alta calidad hizo aumentar su volumen de negocios. Gracias a la construcción de un
nuevo centro de convenciones y a la próspera comunidad comercial en la ciudad, aumentó el número de eventos
de servicio de banquetes.
Catherine administraba el negocio mediante el uso de hojas de cálculo y un procesador de palabras, pero se
le dificultaba estar al tanto de las interminables llamadas telefónicas sobre los tipos de comida disponibles, los
cambios en el número de invitados que iban a asistir al evento y la disponibilidad de artículos especiales, como
platillos de comida vegetariana, bajos en calorías o en carbohidratos, etc. La decisión de Catherine de contratar
varios empleados de medio tiempo para cocinar y ayudar en los eventos complicó la programación del personal,
proceso que estaba abrumando al nuevo gerente de recursos humanos. Catherine decidió contratar una empresa
de consultoría de TI y negocios para ayudarla a lidiar con los problemas a los que se enfrentaba su empresa de
servicio de banquetes.
Después de realizar varias entrevistas y observar al personal clave, los consultores encontraron las siguientes
cuestiones:
1. El chef principal hacía un pedido de provisiones por evento. Los proveedores podrían ofrecer descuentos si
se pidieran cantidades mayores de una sola vez para todos los eventos que se llevaran a cabo en cierto
periodo.
2. A menudo los clientes llamaban para cambiar el número de invitados para un evento, y algunos de esos
cambios se realizaban sólo uno o dos días antes del día programado para el evento.
3. Catherine y su personal requerían demasiado tiempo para atender cada solicitud de servicio;
aproximadamente el 60 por ciento de las llamadas terminaba contratando los servicios.
4. Algunas veces no había disponibilidad de empleados por conflictos de horario, y algunos eventos no
contaban con el suficiente personal. Las quejas sobre la puntualidad del servicio se estaban haciendo más
frecuentes.
www.xlibros.com
60 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
5. Catherine no tiene información sintetizada en cuanto al número de eventos y los tipos de comidas. Sería
conveniente contar con información sobre las tendencias para ayudarle a guiar a sus clientes a la hora de
elegir sus platillos.
6. Por lo general, los eventos se llevan a cabo en hoteles u otros salones que proveen servicios de vajilla, mesas y
sillas. Hay problemas en cuanto a tener suficientes meseros debido a los cambios en el número de invitados.
La figura 3.2 muestra la definición del problema. Observe las ponderaciones a la derecha, las cuales repre-
sentan un promedio de las asignadas por cada empleado. Los objetivos coinciden con los problemas. Cada obje-
tivo se utiliza para crear los requerimientos de los usuarios.
FIGURA 3.2
Definición del problema para Servicio de
banquetes Catherine, desarrollado con la
ayuda de algunos usuarios.
Definición del
problema
El Servicio de ba
nquetes Cather
de los clientes, ine está experim
así como para co entan
en el número de ordinarse con los do problemas para atender el nú
personal de med proveedores ex mero de llamad
io tiempo está pr ternos de produc as de rutina
ovocando conflic tos e instalacion
Problema tos en los horario es. El aumento
s y eventos suba
1. El contacto de tendidos.
l cliente toma un
2. Administrar a ex or bit an te cantidad de tie
empleados de m mpo en las preg Ponderacione
3. Es difícil ten edio tiempo cons untas de rutina. s
er en cuenta los ume mucho tiem
cambios de últim po y pr ov oc a conflictos en 10
4. Se piden prov o minuto en los los horarios.
isiones para cada eventos. 9
5. Con frecuen evento. A menud
cia hay problem o los envíos se
as para comunicar re cib en va ria s veces al día. 7
6. Hay poca inf los cambios a las
ormación histó instalaciones de 6
rica sobre los cli los eventos.
entes y las com
Objetivos idas. 5
1. Proveer un sis 3
tema Web para
2. Crear o com que los clientes
prar un sistema ob ten ga n información so
de recursos hum bre los precios
3. Una vez que anos con un co y coloquen sus
los clientes haya mponente para pedidos.
n firmado un co programar hora
los medios para ntrato para un ev rios.
que actualicen el ento, proveerles
4. Proveer los número de invita con acceso Web
medios para de dos. Notificar a a su cuenta y
terminar las cant la administración
concurrente de idades de provisi sobre estos cam
ntro de un perio ones requeridas bios.
5. Proveer un sis do dado. por eventos que
tema para comun ocurran en form
icar los cambio a
6. Almacenar to s al personal cla
dos los datos de ve en las instalac
los eventos y ten iones de los even
Requerimientos er información tos.
sintetizada dispo
1. El sistema de nible en varios
formatos.
be ser seguro.
2. Los gerentes
de los eventos
3. Debe haber deben introducir
un medio para la retroalimentac
qu e las instalacion ión al momento
4. El sistema de es de los evento de cerrar cada ev
be ser fácil de us s puedan cambia ento.
ar para personas r a la persona qu
sin conocimien e servirá como co
Restricciones tos técnicos. ntacto.
1. Los costos de
desarrollo no de
2. El sitio Web ben exceder de
inicial para los $50,000.
pedidos de los
puedan atender clientes deberá
las solicitudes de estar listo para
fiestas de gradua el 1 de marzo, de
ción y bodas. manera que se
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 61
Después, estos requerimientos se utilizan para crear casos de uso y un diagrama de casos de uso, o procesos
del diagrama de flujo de datos. Cada objetivo puede crear uno o más requerimientos de usuario o varios objetivos
pueden crear uno o tal vez ningún caso de uso (no es común crear casos de uso para informes simples), o cada
requerimiento puede crear un proceso de diagrama de flujo de datos. Los requerimientos de los usuarios para el
Servicio de banquetes de Catherine son:
1. Crear un sitio Web dinámico para permitir que los clientes actuales y potenciales obtengan información y
precios de los servicios y productos ofrecidos.
2. Permitir que los clientes actuales y potenciales envíen una solicitud con sus elecciones de servicio de
banquete, y que la solicitud se canalice a un gerente de cuentas.
3. Agregar clientes a la base de datos de clientes, asignarles un ID de usuario y una contraseña para que tengan
acceso a sus proyectos.
4. Crear un sitio Web para que los clientes puedan ver y actualizar el número de invitados para un evento, y restringir
los cambios al número de invitados cuando falten menos de cinco días para que se lleve a cabo el evento.
5. Obtener o crear software para comunicarse directamente con el personal de las instalaciones de los eventos.
6. Crear o comprar un sistema de recursos humanos para programar los horarios de los empleados de medio tiempo,
de manera que la administración pueda agregar empleados y programarlos mediante el uso de varias restricciones.
7. Proveer consultas o informes con información sintetizada.
Cada requerimiento se puede utilizar para crear un plan de prueba preliminar. Como al inicio hay pocos de-
talles disponibles, el plan de prueba se revisará a medida que avance el proyecto.
El siguiente podría ser un plan de prueba simple para el Servicio de banquetes de Catherine:
1. Diseñar datos de prueba que permitan a los clientes ver cada uno de los distintos tipos de productos.
2. Probar que efectivamente se haya introducido una solicitud de servicio de banquete con datos válidos, así
como cada una de las posibles condiciones de datos inválidos (definiremos los datos más adelante).
Asegúrese de que la solicitud se canalice al gerente de cuentas apropiado.
3. Probar que todos los campos de datos pasen todos los criterios de validación para cada campo. Probar datos
reales para asegurar que se agreguen los clientes a la base de datos de clientes y que se les asigne un ID de
usuario y una contraseña correctamente.
4. Crear un plan de prueba para verificar que los clientes puedan ver la información de los eventos. Probar que
no se puedan realizar actualizaciones cuando falten 5 días o menos para el evento. Diseñar datos de prueba
que permitan verificar que se actualice en forma correcta el número de invitados para un evento.
5. Probar que el software funcione correctamente para comunicarse en forma directa con el personal de las
instalaciones de los eventos.
6. Probar el sistema de recursos humanos para programar los horarios de los empleados de medio tiempo y
verificar que éstos se agreguen correctamente, además de verificar que se detecten y reporten todos los
valores inválidos para cada campo. Verificar que el software de programación de horarios realice
actualizaciones válidas y detectar las entradas inválidas.
7. Verificar que todas las consultas o informes funcionen correctamente y contengan la información de
resumen correcta.
Selección de proyectos
Los proyectos tienes orígenes distintos y se inician por muchas razones. No todos se deben seleccionar para
continuar su estudio. Como analista, usted debe tener razones muy claras para recomendar un estudio de siste-
mas en un proyecto que parezca resolver un problema o que pudiera dar lugar a una mejora. Tome en cuenta la
motivación detrás de una propuesta para el proyecto. Necesita estar seguro de que el proyecto en consideración
no se proponga sólo por mejorar su propia reputación o su poder ni el de la persona o grupo que lo propone, ya
que hay una buena probabilidad de que dicho proyecto sea mal concebido y que en un momento dado no sea
muy bien aceptado.
Como vimos en el capítulo 2, hay que examinar los proyectos que se tengan como prospectos desde una
perspectiva de sistemas, de tal forma que consideremos el impacto del cambio propuesto en toda la organización.
Recuerde que los diversos subsistemas de la organización están interrelacionados y son interdependientes, por lo
que un cambio en un subsistema podría afectar a los demás. Incluso cuando los encargados de tomar las decisio-
nes que están directamente involucrados son los que en última instancia establecen los límites para el proyecto
de sistemas, no podemos contemplar o seleccionar un proyecto de sistemas aislados del resto de la organización.
Además de estas consideraciones generales tenemos cinco criterios específicos para la selección de proyectos:
1. Contar con el respaldo de la administración.
2. Que sea el momento oportuno para comprometerse con el proyecto.
www.xlibros.com
62 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
DETERMINACIÓN DE LA VIABILIDAD
Una vez que reducimos el número de proyectos de acuerdo con los criterios antes descritos, todavía falta deter-
minar si los proyectos seleccionados son viables. Nuestra definición de viabilidad va mucho más allá del uso
común del término, ya que existen tres formas principales para evaluar la viabilidad de los proyectos de sistemas:
en base a su operación, a su capacidad técnica y a su economía. El estudio de viabilidad no es un estudio deta-
llado de sistemas, sino que se utiliza para recopilar datos más generales para los miembros de la administración,
lo cual a su vez les permite tomar una decisión en cuanto a si deben continuar o no con un estudio de sistemas.
Los datos para el estudio de viabilidad se pueden recuperar a través de entrevistas, las cuales veremos con
detalle en el capítulo 4. El tipo de entrevista requerida está relacionado de manera directa con el problema u
oportunidad que se sugiere. Por lo general, el analista de sistemas entrevista a las personas que piden ayuda y
a las que están relacionadas en forma directa con el proceso de toma de decisiones, que generalmente son los
administradores. Aunque es importante abordar el problema correcto, el analista de sistemas no debe invertir
mucho tiempo en realizar estudios de viabilidad, ya que se solicitarán muchos proyectos y se podrán o deberán
llevar a cabo sólo unos cuantos. El estudio de viabilidad debe tardar el menor tiempo posible, procurando abarcar
varias actividades en un periodo de tiempo corto.
Determinar si es posible o no
Una vez que el analista determina objetivos razonables para un proyecto, necesita determinar si es posible que
la organización y sus miembros puedan ver el proyecto hasta su terminación. Por lo general, el proceso de eva-
luación de la viabilidad es efectivo para descartar proyectos inconsistentes con los objetivos de la empresa, que
requieran una capacidad técnica imposible o que no tengan ningún mérito económico.
Aunque es meticuloso, el estudio de la viabilidad es algo que vale la pena ya que ahorra tiempo y dinero a
las empresas y a los analistas de sistemas. Para que el analista pueda recomendar que se continúe con el desarro-
llo de un proyecto, éste debe mostrar que es viable en las tres siguientes formas: técnica, económica y operacio-
nal, como se muestra en la figura 3.3.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 63
FIGURA 3.3
Los tres elementos clave de la viabilidad
Los tres elementos clave de la
Viabilidad técnica viabilidad: técnica, económica y
Complemento para el sistema actual operacional.
Tecnología disponible para satisfacer las necesidades de los usuarios
Viabilidad económica
Tiempo del analista de sistemas
Costo del estudio de sistemas
Costo del tiempo de los empleados para el estudio
Costo estimado del hardware
Costo del software empaquetado o del desarrollo de software
Viabilidad operacional
Si el sistema funcionará o no cuando se instale
Si el sistema se utilizará o no
VIABILIDAD TÉCNICA El analista debe averiguar si es posible desarrollar el nuevo sistema teniendo en cuenta los
recursos técnicos actuales. De no ser así, ¿se puede actualizar o complementar el sistema de tal forma que pueda
cumplir con lo que se requiere? Si no es posible complementar o actualizar los sistemas existentes, la siguiente
pregunta es si existe o no la tecnología que cumpla con las especificaciones.
Al mismo tiempo, el analista puede preguntar si la organización cuenta con el personal que tenga la habili-
dad técnica suficiente para lograr los objetivos. De no ser así, la pregunta es si pueden o no contratar programa-
dores, probadores, expertos o demás personal adicional que pueda tener habilidades de programación distintas a
las del personal existente, o si tal vez pueden subcontratar un tercero para que se haga cargo del proyecto. Otra
de las preguntas es si hay o no paquetes de software disponibles que puedan lograr sus objetivos, o si hay que
personalizar el software para la organización.
VIABILIDAD ECONÓMICA La viabilidad económica es la segunda parte de la determinación de recursos. Los
recursos básicos a considerar son el tiempo de usted como analista y el tiempo de su equipo de análisis de
sistemas, el costo de realizar un estudio de sistemas completo (incluyendo el tiempo de los empleados con los
que usted va a trabajar), el costo del tiempo del empleado de la empresa, el costo estimado del hardware y el
costo estimado del software o del desarrollo de software.
La empresa afectada debe ser capaz de ver el valor de la inversión que está considerando antes de compro-
meterse con un estudio de sistemas completo. Si los costos a corto plazo no se ven eclipsados por las ganancias a
largo plazo o no producen una reducción inmediata en los costos de operación, entonces el sistema no es econó-
micamente viable y el proyecto no debe continuar.
VIABILIDAD OPERACIONAL Suponga por un instante que tanto los recursos técnicos como económicos se
consideran adecuados. El analista de sistemas debe aún considerar la viabilidad operacional del proyecto
solicitado. La viabilidad operacional depende de los recursos humanos disponibles para el proyecto e implica la
acción de pronosticar si el sistema funcionará y se utilizará una vez instalado.
Si los usuarios están prácticamente casados con el sistema actual, no ven problemas con él y por lo general
no están involucrados en el proceso de solicitar un nuevo sistema, habrá mucha resistencia a la implementación
del nuevo. Las probabilidades de que se vuelva funcional en algún momento dado serán bajas.
Por otro lado, si los mismos usuarios han expresado la necesidad de un sistema que sea funcional por más
tiempo, de una forma más eficiente y accesible, hay más probabilidades de que el sistema solicitado se llegue a
utilizar en un momento dado. Gran parte del arte de determinar la viabilidad operacional recae en las interfaces
de usuario elegidas, como veremos en el capítulo 14.
www.xlibros.com
64 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Estimar las
cargas de trabajo
Renta Crear
Evaluar Evaluar Comprar
Compra Opciones Opciones
hardware software COTS
Usar
Arrendamiento ASP
Elegir el
distribuidor
Adquirir el
equipo de
cómputo
usuarios interactúan con las tecnologías en el entorno organizacional al determinar el hardware necesario. Las
opciones en cuanto al hardware se pueden considerar sólo hasta que los analistas de sistemas, los usuarios y
la administración tengan una buena comprensión sobre los tipos de tareas que hay que llevar a cabo.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 65
Sistema existe
nte
Tarea Sistema propue
Comparar el re sto
ndimiento de los
almacenes de dis Comparar el re
tribución ndimiento de los
mediante la eje almacenes de dis
cución del tribución en el
programa para tablero de cont
sintetizar dato rol basado en We
s b
Método Se ejecutan los
programas de
computadora cu Las actualizacio
ando es necesa nes ocurren de
el procesamiento rio; inmediato; el pr
se realiza desde ocesamiento se
la estación de tra realiza en línea
bajo
Personal
Gerente de dis
tribu ción
Cuándo y cómo Gerente de dis
tribución
A diario:
Introducir los em A diario:
barques en hojas
de cálculo de Ex Introducir los em
cel, verificar la barques en el
precisión de las sistema basado
hojas de datos en Web mediant
en forma manual cuadros despleg e
y después ables. Los datos
almacenar los ar se respaldan en
chivos en medio forma automátic
de respaldo s en la ubicación rem a
ota
Por mes: Por mes:
Ejecutar un prog Comparar almac
rama que sintetic enes en línea
los registros dia e mediante el ta
rios y e imprima blero de contro
informe, obtener un de rendimiento l
el informe y hace ; imprimir sólo
evaluaciones r es necesario si
Requerimientos
de A diario: 20 mi
tiempo humano nutos
Por mes: 30 mi A diario: 10 minu
nutos tos
Requerimientos Por mes: 10 minu
de A diario: 20 mi tos
tiempo de nu
Por mes: 30 mi tos
computadora nutos A diario: 10 minu FIGURA 3.5
Por mes: 10 minu tos
tos Comparaciones de las cargas de
trabajo entre los sistemas
existentes y los propuestos.
Si las estimaciones se realizan en forma apropiada, la empresa no tendrá que reemplazar hardware sólo debido
a un crecimiento imprevisto en el uso del sistema (sin embargo, otros eventos como las innovaciones tecnológicas
superiores pueden dictar el reemplazo de hardware, si la empresa desea mantener su ventaja competitiva).
Por necesidad, las cargas de trabajo se muestrean en vez de pasarlas a través de varios sistemas computacio-
nales. Los lineamientos que se proporcionan en el capítulo 5 se pueden usar en este caso también, ya que en el
muestreo de cargas de trabajo, el analista de sistemas toma una muestra de las tareas necesarias y los recursos
computacionales requeridos para completarlas.
La figura 3.5 comparara los tiempos requeridos por un sistema de información existente y uno propuesto,
los cuales deben manejar cierta carga de trabajo. Hay que tener en cuenta que en la actualidad la empresa utiliza
un sistema computacional antiguo para preparar un resumen de los embarques a sus almacenes de distribución
y que se está sugiriendo un tablero de control basado en Web. La comparación de la carga de trabajo analiza
cuándo y cómo se realiza cada proceso, cuánto tiempo humano se requiere y cuánto tiempo de computadora
se necesita. Hay que tener en cuenta que el sistema recién propuesto debería reducir en forma considerable el
tiempo humano y de computadora requeridos.
www.xlibros.com
66 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
parezcan cumplir con las necesidades proyectadas. La información de los distribuidores sobre los posibles sis-
temas y sus configuraciones se vuelve más pertinente en esta etapa, por lo cual hay que revisarla junto con la
administración y los usuarios.
Además, se pueden simular y ejecutar las cargas de trabajo en distintos sistemas, incluyendo los que la orga-
nización ya esté usando. Este proceso se conoce como “benchmarking”.
Los criterios que deben usar los analistas de sistemas y los usuarios para evaluar el rendimiento de distintos
sistemas en el hardware son:
1. El tiempo requerido para las transacciones promedio (incluyendo el tiempo requerido para introducir los
datos y cuánto se tarda en recibir la salida).
2. La capacidad del volumen total del sistema (cuánto se puede procesar al mismo tiempo antes de que surja un
problema).
3. El tiempo de inactividad de la CPU o red.
4. El tamaño de memoria provisto.
Algunos criterios se mostrarán en las demostraciones formales; otros no se pueden simular y hay que dedu-
cirlos de las especificaciones de los fabricantes. Es importante ser claro en cuanto a las funciones requeridas y
deseadas antes de involucrarse demasiado en los alegatos de los distribuidores durante las demostraciones.
Una vez que se conocen los requerimientos funcionales y se comprenden los productos actuales disponibles,
además de compararlos con lo que ya existe en la organización, los analistas de sistemas toman decisiones en
conjunto con los usuarios y la administración acerca de si es o no necesario obtener nuevo hardware. Podemos
considerar que las opciones existen en un continuo: desde usar sólo equipo que ya esté disponible en la empresa
hasta obtener equipo totalmente nuevo. Entre estos dos extremos existen varias opciones para realizar modifica-
ciones menores o mayores al sistema computacional existente.
TAMAÑO Y USO DE LAS COMPUTADORAS El rápido avance de la tecnología establece que el analista de sistemas
debe investigar los tipos de computadoras disponibles en el momento específico en que se escriba la propuesta de
sistemas. Los tamaños de las computadoras varían en forma considerable, desde los teléfonos celulares en
miniatura hasta las supercomputadoras del tamaño de un cuarto. Cada una tiene distintos atributos que debemos
considerar a la hora de decidir cómo implementar un sistema computacional.
FIGURA 3.6
Ventajas Desventajas
Comparación de las ventajas y
desventajas de comprar, arrendar y Comprar • Más económico que arrendar o • El costo inicial es alto
rentar equipo de cómputo. rentar a largo plazo • Riesgo de obsolescencia
• Habilidad de cambiar el sistema • Riesgo de quedar trabado si
• Provee ventajas fiscales por la la elección fue incorrecta
depreciación acelerada • Responsabilidad total
• Control total
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 67
FIGURA 3.7
Comparación de las alternativas
Renta para la adquisición de
Renta mensu computadoras.
al $ 170
× 36 meses
Costo total po
r 3 años $6,120 Compra
mpra $6,000
Precio de co – 500
al
Valor residu $ 5,500
or 3 años
Arren
damien Costo total p
t o
Arren
damie
× 36 nto m
ensu
Subto meses al $
tal 150
Pago
inicia
Costo l 5,400
total
por 3 500
años
$5,90
0
Comprar implica que la empresa será dueña del equipo. Uno de los principales factores determinantes para
comprar o no es la vida proyectada del sistema. Si el sistema se va a utilizar por más de cuatro o cinco años (y
se calcula que los demás factores se mantendrán constantes), la decisión por lo general será comprar. Observe en
el ejemplo de la figura 3.7 que el costo de comprar después de tres años es menor que el de arrendar o rentar.
A medida que los sistemas se hacen más pequeños y potentes, y menos costosos, y a medida que los sistemas
distribuidos se hacen más populares, cada vez más empresas deciden comprar equipo.
Arrendar el hardware de computadora en vez de comprarlo es otra de las posibilidades. Arrendar equipo al
distribuidor o a una empresa de arrendamiento de terceros es más práctico cuando la vida proyectada del sistema
es menor a cuatro años. Además, si se pronostican cambios considerables en la tecnología, arrendar es mejor
opción, ya que también permite a la empresa invertir su dinero en otro lado, donde pueda trabajar para ésta en
vez de estar invertido en equipos de capital. Sin embargo, durante un periodo extenso el arrendamiento no es una
manera económica de adquirir equipo de cómputo.
Rentar hardware de computadora es la tercera opción principal para adquirir computadoras. Una de las
principales ventajas de rentar es que no se tiene que invertir el capital de la empresa y, por ende, no se requiere
financiamiento. Además, al rentar el hardware computacional es más fácil cambiar el hardware del sistema. Por
último, es común que se incluyan el mantenimiento y el seguro en los contratos de renta. No obstante, debido a
los altos costos involucrados y al hecho de que la empresa no será dueña del equipo rentado, esta opción se debe
contemplar sólo como un movimiento a corto plazo para manejar las necesidades no recurrentes o limitadas de
computadoras, o en tiempos en los que la tecnología sea muy cambiante.
EVALUACIÓN DEL SOPORTE DE LOS DISTRIBUIDORES EN RELACIÓN CON EL HARDWARE DE COMPUTADORA Hay
que evaluar varias áreas clave al ponderar los servicios de soporte disponibles para las empresas por parte de los
distribuidores. La mayoría de los distribuidores ofrecen la prueba del hardware al momento de la entrega y una
garantía de 90 días que cubre cualquier defecto de fábrica, pero hay que averiguar qué más ofrece el distribuidor.
Con frecuencia, lo que distingue a los distribuidores de calidad es la amplia variedad de servicios de soporte que
ofrecen.
En la figura 3.8 se muestra una lista de los criterios clave que conviene verificar al evaluar el soporte de los
distribuidores. La mayoría de los servicios adicionales de soporte de los distribuidores que se muestran en esa
lista se negocian por separado de los contratos de arrendamiento o compra de hardware.
Los servicios de soporte incluyen el mantenimiento de rutina y preventivo del hardware, el tiempo de res-
puesta especificado (en menos de seis horas o al siguiente día hábil, por ejemplo) en caso de descomposturas del
equipo, el préstamo de equipo en caso de que haya que reemplazar el hardware de manera permanente o si se
requiere una reparación fuera del sitio, y la capacitación en el lugar de trabajo o seminarios de grupo fuera del
lugar de trabajo para los usuarios. Examine con detenimiento la descripción de servicios de soporte incluidas en
la compra o el arrendamiento del equipo, y recuerde involucrar al personal legal apropiado antes de firmar con-
tratos de equipos o servicios.
Desafortunadamente, evaluar el hardware de computadora no es tan simple como el hecho de comparar
costos y elegir la opción menos costosa. Algunas otras eventualidades que surgen comúnmente por parte de los
www.xlibros.com
68 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 3.8
Servicios del distribuidor Detalles específicos que los
Lineamientos para seleccionar
distribuidores ofrecen comúnmente
distribuidores.
Soporte de hardware Línea completa de hardware
Productos de calidad
Garantía
Evaluación de software
Los analistas y las organizaciones se enfrentan cada vez más con la decisión de crear, comprar o subcontratar al
evaluar software para los proyectos de sistemas de información, en especial cuando se contemplan actualizacio-
nes a sistemas existentes o antiguo.
Ya vimos las decisiones que toman los analistas entre rentar, comprar o arrendar hardware. Parte del proceso
de toma de decisiones relacionado con la compra de software comercial para venta en los canales convencionales
(COTS), la “renta” del software a un proveedor de servicios de aplicación (ASP) o la creación de software perso-
nalizado para el proyecto es análogo al proceso de decisión sobre el hardware.
Hay que recalcar que sin importar que usted desarrolle el software o compre un producto COTS para un pro-
yecto en especial, es imperativo completar primero un análisis de los requerimientos de información de los usua-
rios y los sistemas que utilizan (como vimos en los capítulos anteriores). Como analista, parte de la experiencia
que usted desarrolle consiste en formular juicios sólidos al decidir entre el desarrollo de software y comprar soft-
ware COTS para sistemas nuevos y existentes. En las siguientes secciones veremos cuándo es conveniente crear
su propio software, cuándo hay que comprar paquetes COTS y cuándo es mejor usar un ASP. En la figura 3.9 se
sintetizan las ventajas y desventajas de cada una de estas opciones.
CUÁNDO DEBEMOS CREAR SOFTWARE PERSONALIZADO Varias situaciones demandan la creación de software
original o de ciertos componentes de software. El caso más probable es cuando no existe software COTS o no se
puede identificar para la aplicación deseada. La alternativa es que el software tal vez exista, pero sea demasiado
costoso o no se pueda comprar o adquirir licencias con facilidad.
Hay que crear software original cuando la organización trata de obtener una ventaja competitiva por medio
del aprovechamiento de los sistemas de información. Éste es comúnmente el caso cuando una organización crea
aplicaciones de comercio electrónico u otras aplicaciones innovadoras sin que existiera algo así antes. También
es posible que la organización sea de las “primeras” en utilizar una tecnología específica o de su industria especí-
fica. Las organizaciones que tienen requerimientos muy especializados o que existen en industrias especializadas
también se pueden beneficiar del software original.
Las ventajas de crear su propio software incluyen ser capaz de responder a las necesidades especializadas de
usuarios y empresas, obtener una ventaja competitiva al crear software innovador, tener personal interno disponi-
ble para dar mantenimiento al software y el orgullo de poseer algo que usted ha creado.
Las desventajas de desarrollar su propio software incluyen el potencial de un costo inicial considerablemente
alto en comparación con la compra de software COTS o la subcontratación de un ASP, la necesidad de contratar
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 69
FIGURA 3.9
Ventajas Desventajas
Comparación de las ventajas y
Creación de software • Respuesta específica a las • Puede tener un costo inicial desventajas de crear software
personalizado necesidades especializadas de considerablemente alto en personalizado, comprar paquetes
la empresa comparación con el software COTS y subcontratar un ASP.
• La innovación puede dar a la COTS o un ASP
empresa una ventaja competitiva • Es necesario contratar o trabajar
• Personal interno disponible para con un equipo de desarrollo
dar mantenimiento al software • Mantenimiento continuo
• Orgullo de propiedad
o trabajar con un equipo de desarrollo y el hecho de que usted sea responsable del mantenimiento continuo por
ser el creador del software.
CUÁNDO DEBEMOS COMPRAR SOFTWARE COTS El software comercial de venta en los canales convencionales
incluye productos como la suite de Microsoft Office, que a su vez incluye el programa Word para el
procesamiento de palabras, Excel para las hojas de cálculo, Access para crear bases de datos y otras aplicaciones.
Hay otros tipos de software COTS disponibles para sistemas a nivel organizacional en vez de uso personal o de
oficina. Algunos autores incluyen paquetes ERP populares (pero costosos) como Oracle y SAP en sus ejemplos
de software COTS. Estos paquetes tienen diferencias radicales en cuanto al grado de personalización, soporte y
mantenimiento requerido en comparación con Microsoft Office. El software COTS también se puede referir a los
componentes u objetos de software (también conocidos como bloques de construcción) que se pueden comprar
para proveer cierta funcionalidad necesaria en un sistema.
Considere el uso de software COTS cuando pueda integrar con facilidad las aplicaciones o paquetes a los
sistemas existentes o planeados, y cuando no haya identificado ninguna necesidad inmediata o continua de mo-
dificarlos o personalizarlos para los usuarios. Sus pronósticos deben demostrar que la organización para la cual
está diseñando el sistema muestra pocas probabilidades de pasar por cambios importantes después de la compra
propuesta de software COTS como un aumento considerable en los clientes o grandes expansiones físicas.
Hay algunas ventajas de comprar software COTS que usted debe tener en cuenta al momento de ponderar
las alternativas. Una de ellas es que estos productos se han refinado a través del proceso del uso y la distribución
comercial, por lo que a menudo se ofrecen funcionalidades adicionales. Otra ventaja es que por lo general, el
software empaquetado se prueba en forma exhaustiva y, por ende, es en extremo confiable.
A menudo el software COTS ofrece una funcionalidad mejorada, ya que es probable que un producto comer-
cial cuente con productos afiliados, características complementarias y actualizaciones que mejoren su atractivo.
Además, los analistas descubren con frecuencia que el costo inicial del software COTS es menor que el costo de
desarrollar software dentro de la empresa o usar un ASP.
Otra ventaja de comprar paquetes COTS es que muchas otras compañías también lo usan, por lo que los analis-
tas no tienen que experimentar con sus clientes a través de aplicaciones de software únicas. Por último, el software
www.xlibros.com
70 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
O P O R T U N I D A D D E C O N S U LT O R Í A 3 . 2
COTS cuenta con una ventaja en cuanto a la ayuda y la capacitación que se incluyen en la compra del software
empaquetado.
Como ejemplo del uso de software COTS, analicemos el caso de una compañía teatral, una organización sin
fines de lucro (generalmente, este tipo de asociaciones en especial las de artes escénicas tienden a atrasarse en
comparación con sus contrapartes con fines comerciales al adoptar tecnologías de comunicación de la informa-
ción (ICT)). Como es de esperarse, la compañía teatral se tardó en adoptar la Web. Cuando deseaban crear apli-
caciones de comercio electrónico, se vieron en la necesidad de contratar diseñadores externos para ello. En vista
de los gastos y la falta de experiencia interna, muchas organizaciones sin fines de lucro simplemente no pasaron
la parte comercial de sus organizaciones a la Web, y se quedaron en espera de paquetes de COTS como el soft-
ware de taquilla basado en PC, o ASP como las agencias de venta de boletos en línea que ya contaban con la au-
tomatización requerida, para poner estos servicios a disposición de los clientes. El desarrollo de software interno
estaba fuera de consideración para la mayoría de estos grupos, que por lo general tienen poco o nada de personal
de TI y un presupuesto reducido o inexistente, además de una mínima experiencia de TI interna.
Hay una desventaja en el uso de software COTS. Como no está diseñado para ser totalmente personalizado,
la compañía teatral no pudo incluir características clave en su base de datos de donadores con las que los usua-
rios contaban. Además, el software COTS también puede incluir errores que podrían exponer a la organización a
problemas legales relacionados con fallas en el servicio.
Hay que considerar otras desventajas en cuanto a la compra del software COTS, incluyendo el hecho de
que los paquetes están enfocados en la programación y no en los usuarios humanos que trabajan en una em-
presa. Además los usuarios deben acoplarse a las características existentes en el software, sin importar que sean
apropiadas o no. Una desventaja que surge de esto es la capacidad limitada de personalización de la mayoría del
software empaquetado. Otras desventajas incluyen la necesidad de investigar la estabilidad financiera del distri-
buidor del software y la sensación reducida de propiedad y compromiso que es inevitable cuando el software se
considera un producto y no un proceso.
Para obtener cierta perspectiva sobre los sistemas que se van a desarrollar, usted debe reconocer que más
de la mitad de los proyectos se construyen desde cero (en donde dos terceras partes utilizan métodos tradiciona-
les como SDLC y los prototipos, y una tercera parte utiliza tecnologías ágiles u orientadas a objetos). La mayor
parte de ellos se desarrollan mediante el uso de un equipo interno de análisis de sistemas. Los programadores
pueden ser internos o subcontratados.
Menos de la mitad de los proyectos se desarrollan a partir de aplicaciones o componentes ya existentes. La
gran mayoría se modifican, algunos en forma extensa. Menos del 5 por ciento del software es comercial que se
vende por canales convencionales y no requiere ningún tipo de modificación.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 71
FIGURA 3.10
Requerimientos de software Características específicas del software
Lineamientos para la evaluación
Efectividad en el rendimiento Poder realizar todas las tareas requeridas del software.
Poder realizar todas las tareas deseadas
Pantallas de visualización bien diseñadas
Capacidad adecuada
Eficiencia del rendimiento Tiempo de respuesta rápido
Entrada eficiente
Salida eficiente
Almacenamiento de datos eficiente
Respaldo eficiente
www.xlibros.com
72 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Evalúe el software usando datos de prueba de la empresa que lo está considerando y examine la documen-
tación que lo acompaña. No basta confiar sólo en las descripciones de los distribuidores. Por lo general, éstos
certifican que el software es funcional al momento en que sale de su establecimiento, pero no garantizarán que
esté libre de errores en cualquier situación o que no fallará cuando los usuarios realicen acciones incorrectas.
También es obvio que no garantizarán su software si se utiliza en conjunto con hardware defectuoso.
Pronósticos
Los analistas de sistemas deben ser capaces de predecir ciertas variables clave antes de enviar su propuesta al
cliente. En cierto grado, un analista de sistemas tiene que depender de un análisis del tipo “qué pasaría si”. Por
ejemplo: “¿Qué pasaría si los costos de mano de obra aumentan sólo un 5 por ciento al año durante los próximos
tres años, en lugar de aumentar un 10 por ciento?”. Sin embargo, el analista de sistemas debe tener en cuenta que
no puede depender totalmente de estos análisis si quiere que su propuesta sea creíble, significativa y valiosa.
El analista de sistemas tiene a su disposición muchos modelos de pronósticos. La principal condición para
elegir un modelo es la disponibilidad de datos históricos. Si no hay datos disponibles, el analista debe recurrir a
uno de los siguientes métodos de juicio: estimaciones de la fuerza de ventas, encuestas para estimar la demanda
de los clientes, estudios Delphi (un pronóstico por consenso que un grupo de expertos desarrolla de manera inde-
pendiente a través de una serie de rondas), crear escenarios o bosquejar analogías históricas.
Si hay datos históricos disponibles, la siguiente diferenciación entre las clases de técnicas implica diferen-
ciar entre un pronóstico condicional o uno incondicional. En un pronóstico condicional hay una asociación entre
las variables en el modelo o de tal forma que exista una relación causal. Los métodos comunes en este grupo in-
cluyen: correlación, regresión, indicadores importantes, econometría y modelos de entrada/salida.
En el pronóstico incondicional el analista no tiene que buscar o identificar relaciones causales. En conse-
cuencia, los analistas de sistemas opinan que estos métodos son alternativas de bajo costo, fáciles de implemen-
tar. En este grupo se incluyen: el juicio gráfico, las medias móviles y el análisis de los datos en series de tiempo.
Como estos métodos son simples, confiables y efectivos en costo, en el resto de esta sección nos concentraremos
en ellos.
ESTIMACIÓN DE LAS TENDENCIAS Podemos estimar las tendencias de varias maneras. Una de ellas es mediante
el uso de una media móvil. Este método es útil debido a que es posible ajustar la consistencia de ciertos patrones
estacionales, cíclicos o aleatorios de forma que quede el patrón de tendencias. El principio detrás de las medias
móviles es calcular la media aritmética de los datos a partir de un número fijo de periodos; una media móvil de
tres meses es simplemente la media de los últimos tres meses. Por ejemplo, el promedio de las ventas para enero,
febrero y marzo se utiliza para predecir las de abril. Después se utilizan las ventas promedio de febrero, marzo y
abril para predecir las de mayo, y así sucesivamente.
Al momento de graficar los resultados podemos ver con facilidad que los datos con amplias fluctuaciones se
vuelven consistentes. El método de la media móvil es útil debido a su habilidad de uniformar los datos, pero al
mismo tiempo presenta muchas desventajas. Las medias móviles se ven afectadas más fuertemente debido a los
valores extremos que cuando se utiliza el método del juicio gráfico o cuando se realizan estimaciones mediante
otros métodos, como el de los mínimos cuadrados. El analista debe aprender a pronosticar con destreza, ya que a
menudo se obtiene información valiosa que puede incluso justificar todo el proyecto completo.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 73
O P O R T U N I D A D D E C O N S U LT O R Í A 3 . 3
tareas. Y todavía quedan muchos ejemplos más. Aunque no siempre es fácil, podemos medir los beneficios
tangibles en términos de ahorro de dinero, recursos o tiempo.
BENEFICIOS INTANGIBLES Algunos beneficios que se acumulan en la organización debido al uso del sistema
de información son difíciles de medir pero no dejan de ser importantes. A estos se les conoce como beneficios
intangibles.
Entre los beneficios intangibles figuran un proceso de toma de decisiones mejorado, una mejoría en la preci-
sión, la empresa se vuelve más competitiva en el servicio al cliente, mantiene una buena imagen comercial y au-
menta la satisfacción en el trabajo para los empleados al eliminar las tareas tediosas. Como podemos ver en esta
lista, los beneficios intangibles son en extremo importantes y pueden tener implicaciones de largo alcance para la
empresa, ya que se relacionan con personas tanto en el exterior como en el interior de la organización.
Aunque los beneficios intangibles de un sistema de información son factores importantes que debemos con-
siderar al momento de decidir si continuamos con un proyecto de sistemas o no, un sistema que se construya
www.xlibros.com
74 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
teniendo en cuenta sólo sus beneficios intangibles no tendrá éxito. Usted debe hablar sobre los beneficios tan-
gibles e intangibles en su propuesta, ya que esto permitirá a los encargados de tomar las decisiones realizar una
decisión bien informada en relación con el sistema propuesto.
COSTOS TANGIBLES Los conceptos de costos tangibles e intangibles son paralelos a los conceptos de los
beneficios tangibles e intangibles que vimos antes. Los costos tangibles son aquellos que el analista de sistemas
y el personal contable de la empresa pueden pronosticar con precisión.
Entre los costos tangibles se incluye el costo del equipo como las computadoras y terminales, el costo de los
recursos, el costo del tiempo del analista de sistemas, el costo del tiempo de los programadores y los salarios de
los demás empleados relacionados. Por lo general, estos costos están bien establecidos o se pueden descubrir con
mucha facilidad, y son los que requerirán un desembolso de efectivo por parte de la empresa.
COSTOS INTANGIBLES Los costos intangibles son difíciles de estimar y tal vez no se conozcan. Entre éstos se
incluyen perder la ventaja competitiva, perder la reputación de ser el primero con una innovación o el líder en
un campo, reducir la imagen de la empresa debido al aumento en la inconformidad de los clientes, y un proceso
inefectivo de toma de decisiones debido a que la información pertinente se recibe después de tiempo o no se
tiene acceso a ella. Como podrá imaginar, es casi imposible pronosticar un monto de dinero para los costos
intangibles de una manera precisa. Para ayudar a los encargados de la toma de decisiones que desean ponderar
el sistema propuesto y todas sus implicaciones, usted debe incluir los costos intangibles incluso cuando no sean
cuantificables.
50,000
Punto de
equilibrio
40,000
Costo
Sistema
($)
propuesto
30,000
20,000
10,000
0
0 200 400 600 800 1,000 1,200
Unidades vendidas
Costo del sistema Costo del
propuesto sistema actual
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 75
buena suma de dinero al inicio, pero los costos incrementales por un volumen mayor serían bastante bajos. La
gráfica muestra que el sistema computacional sería efectivo en costo para la empresa si vendiera aproximada-
mente 600 unidades por semana.
El análisis del punto de equilibrio es útil cuando una empresa está creciendo y el volumen es una variable
clave en los costos. Una desventaja de este análisis es que se basa en la suposición de que los beneficios perma-
necen iguales, sin importar el sistema que se utilice. Con base en nuestro estudio de los beneficios tangibles e
intangibles sabemos que en definitiva no puede ser así.
El análisis del punto de equilibrio también puede determinar cuánto tiempo tardarán los beneficios del sis-
tema en retribuir los costos de su desarrollo. En la figura 3.12 se muestra un sistema con un periodo de retribu-
ción de tres y medio años.
ANÁLISIS DEL FLUJO DE EFECTIVO En este análisis se examina la dirección, el tamaño y el patrón del flujo de
efectivo asociado con el sistema de información propuesto. Si usted va a proponer el reemplazo de un antiguo
sistema de información por uno nuevo y el nuevo sistema no generará efectivo adicional para la empresa, sólo
hay desembolsos de efectivo asociados con el proyecto. En tal caso no podrá justificar el nuevo sistema con base
en la generación de nuevos ingresos y deberá examinarlo de cerca para encontrar otros beneficios tangibles si
desea que su propuesta tenga éxito.
En la figura 3.13 se muestra un análisis de flujo de efectivo para una pequeña empresa que provee servicios
de correo a otras pequeñas compañías en la ciudad. Las proyecciones de los ingresos son de sólo $5,000 en el
primer trimestre, pero después del segundo, los ingresos aumentarán con una tasa fija. Los costos serán mayores
en los primeros dos trimestres y luego se estabilizarán. El análisis de flujo de efectivo se utiliza para determinar
cuándo empezará una empresa a obtener ganancias (en este caso es en el tercer trimestre, con un flujo de efectivo
de $7,590) y cuándo “saldrá de la red”; es decir, cuando los ingresos compensan la inversión inicial (en el primer
trimestre del segundo año, cuando el flujo de efectivo acumulado cambia de un monto negativo a una cantidad
positiva de $10,720).
El sistema propuesto debe traer consigo un aumento en los ingresos como contraparte de los desembolsos de
efectivo. Por tanto, hay que analizar el tamaño del flujo de efectivo junto con los patrones asociados con la com-
pra del nuevo sistema. Hay que averiguar cuándo ocurrirán los desembolsos de efectivo y los ingresos, no sólo
para la compra inicial sino durante toda la vida del sistema de información.
ANÁLISIS DEL VALOR PRESENTE Este análisis ayuda al analista de sistemas a presentar, a los encargados de tomar
las decisiones en la empresa, el valor en tiempo de la inversión en el sistema de información así como el flujo de
efectivo (como vimos en la sección anterior). El valor presente es una forma de evaluar todos los desembolsos
económicos y los ingresos del sistema de información durante su vida económica, y de comparar los costos
actuales con los futuros, al igual que los beneficios actuales con los beneficios futuros.
En la figura 3.14, el total de costos del sistema es de $272,000 durante seis años y el total de beneficios es
de $280,700. Por lo tanto, podríamos concluir que los beneficios sobrepasan a los costos. Sin embargo, los bene-
ficios empezaron a sobrepasar a los costos hasta después del cuarto año y el monto en el sexto año no podrá ser
equivalente al monto en el primer año.
FIGURA 3.12
El análisis del punto de equilibrio
70,000 muestra un periodo de retribución
Beneficios acumulados de tres años y medio.
del sistema propuesto
60,000
Beneficios
Costos acumulados
50,000 del sistema propuesto
Periodo de
40,000 retribución Costos Beneficios
Costo Costos Año Costo acumulados Beneficios acumulados
($) ($) ($) ($) ($)
30,000
0 30,000 30,000 0 0
20,000 1 1,000 31,000 12,000 12,000
2 2,000 33,000 12,000 24,000
3 2,000 35,000 8,000 32,000
10,000
4 3,000 38,000 8,000 40,000
5 4,000 42,000 10,000 50,000
0 6 4,000 46,000 15,000 65,000
0 1 2 3 4 5 6
Año
www.xlibros.com
76 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 3.13
Año 1 Año 2
Análisis de flujo de efectivo para Trimestre 1 Trimestre 2 Trimestre 3 Trimestre 4 Trimestre 1
el sistema de correos
computarizado. Ingresos $5,000 $20,000 $24,960 $31,270 $39,020
Costos
Desarrollo
de software 10,000 5,000
Personal 8,000 8,400 8,800 9,260 9,700
Capacitación 3,000 6,000
Arrendamiento
de equipo 4,000 4,000 4,000 4,000 4,000
Provisiones 1,000 2,000 2,370 2,990 3,730
Mantenimiento 0 2,000 2,200 2,420 2,660
Flujo de efectivo
acumulado –21,000 –28,400 –20,810 –8,210 10,720
FIGURA 3.14
Año
Sin considerar el valor presente,
1 2 3 4 5 6 Total
los beneficios parecen sobrepasar
a los costos. Costos $40,000 42,000 44,100 46,300 48,600 51,000 272,000
Por ejemplo, una inversión en dólares al 7 por ciento actual valdría $1.07 al final del año y se duplicaría en
aproximadamente 10 años. Por lo tanto, el valor actual es el costo del beneficio calculado en dólares actuales y
depende del costo del dinero. El costo del dinero es el costo de oportunidad, o la tasa que se obtendría si el di-
nero invertido en el sistema propuesto se invirtiera en otro proyecto (relativamente seguro).
Para calcular el valor presente de $1.00 a una tasa de descuento de i se determina el siguiente factor:
1
11 + i 2 n
en donde n es el número de periodos. Después se multiplica el factor por la cantidad en dólares para obtener el
valor presente, como se muestra en la figura 3.15. En este ejemplo, nos basamos en la suposición de que el costo
del dinero —la tasa de descuento— es de 0.12 (12 por ciento) durante todo el horizonte de planificación. Se calcu-
lan multiplicadores para cada periodo: n ⫽ 1, n ⫽ 2, …, n ⫽ 6. Después se calculan los valores presentes de los
Año
1 2 3 4 5 6 Total
Costos $40,000 42,000 44,100 46,300 48,600 51,000
Multiplicador .89 .80 .71 .64 .57 .51
Valor presente de los costos 35,600 33,600 31,311 29,632 27,702 26,010 183,855
FIGURA 3.15
Tomando en cuenta el valor presente, la conclusión es que los costos son mayores que los beneficios. Nos basamos en la suposición de que la
tasa de descuento i es de 0.12 para calcular los multiplicadores en esta tabla.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 77
costos y los beneficios mediante estos multiplicadores. Después de realizar ese paso, los beneficios totales (me-
didos en dólares actuales) son de $179,484 y por ende son menores que los costos (también medidos en dólares
actuales). La conclusión que obtenemos es que el sistema propuesto no vale la pena si tenemos en cuenta el valor
presente.
Aunque este ejemplo en el que se utilizaron factores de valor presente es útil para explicar el concepto, todas
las hojas de cálculo electrónicas incluyen la función del valor presente. El analista puede calcular directamente el
valor presente mediante esta función.
LINEAMIENTOS PARA EL ANÁLISIS El uso de los métodos descritos en las subsecciones anteriores depende de los
métodos empleados y aceptados en la misma organización. Sin embargo, como lineamientos generales podemos
decir lo siguiente:
1. Use el análisis del punto de equilibrio si hay que justificar el proyecto en términos de costos y no de
beneficios, o si los beneficios no mejoran en forma considerable con el sistema propuesto.
2. Use la retribución cuando el aumento en los beneficios tangibles forme un argumento convincente para el
sistema propuesto.
3. Use el análisis de flujo de efectivo cuando el proyecto sea costoso con relación al tamaño de la empresa o
cuando ésta se vea afectada en forma considerable si hay que desembolsar una gran cantidad de fondos
(incluso si esto es temporal).
4. Use el análisis del valor presente cuando el periodo de retribución sea largo o cuando el costo de pedir
dinero prestado sea alto.
Cualquiera que sea el método elegido, es importante recordar que el análisis de costo-beneficio se debe abordar
de una manera sistemática que se pueda explicar y justificar a los gerentes, quienes decidirán en última instancia
si van a comprometer o no los recursos en el proyecto de sistemas. Ahora veamos la importancia de comparar
muchas alternativas de sistemas.
FIGURA 3.16
Fase Actividad
Para empezar a planear un
Análisis Recopilación de datos proyecto hay que descomponerlo
Análisis de flujo de datos y decisiones ner en tres actividades principales.
ompo
Preparación de la propuesta Desc incipales
r
las p ades en
id
Diseño Diseño de la entrada de datos ac v más
t i
t ra s
Diseño de las entradas o .
eñas
Diseño de las salidas pequ
Organización de los datos
Implementación Implementación
Evaluación
www.xlibros.com
78 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
O P O R T U N I D A D D E C O N S U LT O R Í A 3 . 4
“nasRpersonas.
ealmente podríamos hacer algunos cambios. Sacudir a algu-
Hacerles saber que estamos con eso. Me refiero al
Malcolm dice: “No creo que con sólo lanzar una moneda aquí
entre nosotros dos vayamos a resolver algo. Revísalo y volvemos a
aspecto tecnológico”, dice Malcolm Warner, vicepresidente de All- discutirlo. ¿No sería maravilloso?”.
Fine Foods, un distribuidor de productos lácteos al mayoreo. “Hay Una semana después, Kim entra en la oficina de Malcolm con
que revisar y reparar ese antiguo sistema. Pienso que deberíamos varias páginas de notas de entrevistas en la mano. “Hablé con la mayor
decir al personal que es tiempo de cambiar”. parte de las personas que tienen mucho contacto con el sistema. Están
“Sí, pero ¿qué deberíamos estar mejorando?” pregunta Kim felices, Malcolm. Y no sólo hablan por hablar. Saben lo que hacen”.
Han, asistente del vicepresidente. “Es decir, no hay problemas sus- “Estoy seguro de que a los gerentes les gustaría tener un sis-
tanciales con la entrada o salida del sistema que pueda ver”. tema más reciente que nuestros amigos de Quality Foods”, res-
Malcolm chasquea los dedos y dice: “Kim, estás ignorando ponde Malcolm. “¿Hablaste con ellos?”.
deliberadamente mi punto de vista. Afuera las personas nos ven Kim le contesta: “Sí. Y están satisfechos”.
como una empresa aburrida. Un nuevo sistema computacional po- “¿Y qué hay sobre los de sistemas? ¿Te dijeron que la tecnolo-
dría cambiar eso. Cambiar la apariencia de nuestras facturas. Enviar gía para actualizar nuestro sistema está ahí afuera?”, pregunta
informes más llamativos a los propietarios de las cafeterías y res- Malcolm con insistencia.
taurantes. Destacar como líderes en la distribución de alimentos y “Sí. Claro que se puede hacer. Pero eso no significa que se
las computadoras”. deba hacer”, dice Kim con firmeza.
“Bueno, con base en lo que he visto a través de los años”, Como analista de sistemas para AllFine Foods, ¿cómo evalua-
Kim responde sin alterar la voz, “un nuevo sistema es muy perju- ría usted la viabilidad del proyecto de sistemas que propone Mal-
dicial, incluso si la empresa realmente lo necesita. A las personas colm? Con base en lo que dijo Kim sobre los gerentes, usuarios y
les disgustan los cambios, y si el sistema está funcionando como encargados de sistemas, ¿cuál parece ser la viabilidad operacional
debe, tal vez haya otras cosas que debamos hacer para actualizar del proyecto propuesto? ¿Qué hay sobre la viabilidad económica?
nuestra imagen sin que todos se vuelvan locos en el proceso. Ade- ¿Y la viabilidad tecnológica? Con base en lo que discutieron Kim y
más, estás hablando de muchos billetes verdes para un nuevo truco Malcolm, ¿recomendaría usted que se realizara un estudio detallado
publicitario”. de sistemas? Escriba su respuesta en un párrafo.
fase de análisis se descompone aún más en recopilación de datos, análisis de flujo de datos y decisiones, y la prepa-
ración de la propuesta. El diseño se descompone en diseño de la entrada de datos, diseño de las entradas y las sali-
das y organización de los datos. La fase de implementación se divide en implementación y evaluación.
En los pasos subsiguientes, el analista de sistemas necesita considerar cada una de estas tareas y descom-
ponerlas más, de manera que se pueda llevar a cabo la planeación y programación de las mismas. En la figura 3.17
FIGURA 3.17
Semanas
Para refinar la planeación y Actividad Actividad detallada requeridas
programación de las actividades
de análisis hay que agregar tareas Recopilación de datos Realizar entrevistas 3
detalladas y establecer el tiempo Administrar cuestionarios 4
requerido para completarlas. Leer informes de la compañía 4
Introducir el prototipo 5
Observar las reacciones al prototipo 3
Desco ués
m
éstos poner y desp el
a r
aún m
inclus
o estim requerido.
ás m p o
tie
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 79
se muestra una descripción más detallada de la fase de análisis. Por ejemplo, la recopilación de datos se des-
compone en cinco actividades, desde realizar entrevistas hasta observar las reacciones al prototipo. Este pro-
yecto en especial requiere un análisis del flujo de datos pero no de las decisiones, por lo que el analista de
sistemas escribió “analizar el flujo de datos” como el paso individual en la fase media. Por último se descom-
pone la preparación de la propuesta en tres pasos: realizar un análisis de costo-beneficio, preparar la propuesta
y presentarla.
Desde luego que el analista de sistemas tiene la opción de descomponer los pasos incluso aún más. Por
ejemplo, podría especificar cada una de las personas a entrevistar. El grado de detalle necesario depende del pro-
yecto, pero todos los pasos críticos deben aparecer en los planes.
Algunas veces la parte más difícil de la planeación de un proyecto es el paso crucial de estimar el tiempo
requerido para completar cada tarea o actividad. Cuando se les preguntó sobre los motivos de retrasarse en un
proyecto específico, los miembros del equipo del proyecto hablaron sobre las malas estimaciones en la progra-
mación de los tiempos que obstaculizaron el éxito del proceso desde su inicio. No hay sustituto para la experien-
cia al estimar los requerimientos de tiempo; los analistas de sistemas que han tenido la oportunidad de aprender
sobre ello son afortunados.
Los planificadores han intentado reducir la incertidumbre inherente al determinar las estimaciones de
tiempo mediante una proyección de las estimaciones más probables, pesimistas y optimistas, para después
utilizar una fórmula de promedio ponderado con el fin de determinar el tiempo esperado que una actividad
requerirá. Sin embargo, esta metodología apenas si ofrece algo más de confianza. Tal vez la mejor estrategia
para el analista de sistemas sea adherirse a una metodología estructurada para identificar las actividades y
describirlas con el suficiente detalle. De esta forma, el analista de sistemas podrá por lo menos limitar las sor-
presas desagradables.
Introducir prototipo
Observar reacciones
Realizar análisis de costo-beneficio
Preparar la propuesta
Presentar la propuesta
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Semanas
Semana actual
www.xlibros.com
80 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 3.19
Comparación entre los gráficos de A
Gantt y los diagramas PERT para
B
programar actividades.
C
2 4 6 8 10 12 14 16
20
A, 4 C, 5
E, 6
10 40 50
B, 2 D, 3
30
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 81
20
FIGURA 3.20
La precedencia de las actividades
A, 9
es importante para determinar la
longitud del proyecto al utilizar un
Actividad
10 40 Proyecto 1 diagrama PERT.
simulada
B, 2 C, 5
30
20 Actividad
A, 9 simulada
10 40 Proyecto 2
B, 2 C, 5
30
ya que todas las flechas que entran a un nodo deben completarse antes de salir del nodo. Sin embargo, en el pro-
yecto 2 la actividad C sólo requiere que se complete la actividad B y, por lo tanto, puede empezar mientras la
actividad A se esté llevando a cabo.
El proyecto 1 tarda 14 días en completarse, mientras que el proyecto 2 requiere sólo 9 días. Sin duda, la ac-
tividad simulada en el proyecto 1 es necesaria, ya que indica una relación de precedencia crucial. Por otra parte,
la actividad simulada en el proyecto 2 no se requiere, por lo que la actividad A se podría dibujar del nodo 10 al
nodo 40 para eliminar por completo el evento 20.
Existen muchas razones para utilizar un diagrama PERT en vez de un gráfico de Gantt. El diagrama PERT
permite:
1. Identificar con facilidad el orden de precedencia.
2. Identificar con facilidad la ruta crítica y, en consecuencia, las actividades críticas.
3. Determinar con facilidad el tiempo de inactividad.
UN EJEMPLO DE PERT Suponga que un analista de sistemas trata de establecer un programa de horarios realista
para las fases de recopilación de datos y propuesta del ciclo de vida del análisis y diseño de sistemas. El analista
de sistemas analiza la situación y hace una lista de las actividades que hay que realizar a lo largo del camino.
Esta lista, que se muestra en la figura 3.21, también muestra que algunas actividades deben realizarse antes que
otras. Las estimaciones de tiempo se determinaron según lo descrito en una sección anterior de este capítulo.
DIBUJAR EL DIAGRAMA PERT Para construir el diagrama PERT, el analista primero se basa en las actividades
que no requieren actividades predecesoras; en este caso A (realizar entrevistas) y C (leer los informes de la
compañía). En el ejemplo de la figura 3.22, el analista optó por enumerar los nodos como 10, 20, 30 y así en lo
sucesivo, y dibujó dos flechas saliendo del nodo inicial 10. Estas flechas representan las actividades A y C, y
se identifican como tales. Los nodos enumerados como 20 y 30 se dibujan al final de estas respectivas flechas.
FIGURA 3.21
Actividad Predecesor Duración
Listado de las actividades que
A Realizar entrevistas Ninguno 3 se utilizará en el dibujo de un
B Administrar cuestionarios A 4 diagrama PERT.
C Leer informes de la compañía Ninguno 4
D Analizar el flujo de datos B, C 8
E Introducir el prototipo B, C 5
F Observar las reacciones al prototipo E 3
G Realizar un análisis de costo-beneficio D 3
H Preparar la propuesta F, G 2
I Presentar la propuesta H 2
www.xlibros.com
82 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 3.22
20
Un diagrama PERT completo para
A, 3 B, 4
la fase de análisis de un proyecto
de sistemas.
C, 4 D, 8 G, 3 H, 2 I, 2
10 30 50 60 70 80
E, 5 F, 3
40
El siguiente paso es buscar una actividad que sólo requiera a A como predecesor; la tarea B (administrar
cuestionarios) es la única, por lo que se puede representar mediante una flecha dibujada desde el nodo 20
hasta el nodo 30.
Como las actividades D (analizar el flujo de datos) y E (introducir el prototipo) requieren que las ac-
tividades B y C se completen para poder empezar, las flechas etiquetadas como D y E se dibujan desde el
nodo 30, el evento que reconoce que se completaron las actividades B y C. Este proceso continúa hasta que
se completa todo el diagrama PERT. Observe que el proyecto completo termina en un evento identificado
como el nodo 80.
IDENTIFICAR LA RUTA CRÍTICA Una vez dibujado el diagrama PERT, para identificar la ruta crítica se calcula
la suma de los tiempos de las actividades en cada ruta y se elige la ruta más larga. En este ejemplo hay cuatro
rutas: 10-20-30-50-60-70-80, 10-20-30-40-60-70-80, 10-30-50-60-70-80 y 10-30-40-60-70-80. La ruta más larga
es 10-20-30-50-60-70-80, que tarda 22 días. Es esencial que el analista de sistemas supervise con cuidado las
actividades en la ruta crítica para poder mantener el proyecto completo a tiempo o incluso reducir la longitud del
proyecto, si se puede garantizar.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 83
ATRACTIVO DE LA MAC
La codificación de colores ayuda a un gerente de proyectos a poner en orden las fases, tareas y recursos similares.
OmniPlan, disponible para la Mac, aprovecha la codificación de colores para establecer un proyecto, identificar las
tareas, identificar la ruta crítica y marcar las situaciones imposibles.
FIGURA 3.MAC
El software de administración de proyectos OmniPlan de The Omni Group.
Ensamblar un equipo
Es conveniente ensamblar un equipo. Si el gerente del proyecto tiene la oportunidad de crear el equipo ideal
compuesto por personas experimentadas para desarrollar un sistema, ¿a quién debería escoger? En general, los
gerentes de proyectos necesitan buscar a otros que compartan sus valores de trabajo en equipo guiados por el
deseo de producir un sistema de alta calidad a tiempo y dentro del presupuesto. Otras características deseables
incluyen una buena ética laboral, honestidad, competencia, la disposición de asumir el liderazgo con base en la
experiencia, la motivación, el entusiasmo por el proyecto y la confianza de sus compañeros de equipo.
El gerente del proyecto necesita conocer los principios de negocios, pero no está de más contar con alguna
otra persona en el equipo que comprenda la forma en que opera una empresa. Tal vez esta persona debería ser
un especialista en la misma área que la del sistema que se va a desarrollar. Al desarrollar un sitio de comercio
electrónico, los equipos pueden conseguir la ayuda de alguien en marketing; los que desarrollen un sistema de
inventarios pueden preguntar a una persona con experiencia en producción y operaciones para que comparta su
experiencia.
Lo ideal sería que un equipo tuviera dos analistas de sistemas. De esta forma se pueden ayudar entre sí, re-
visar uno el trabajo del otro y equilibrar sus cargas de trabajo según se requiera. Sin duda existe la necesidad de
www.xlibros.com
84 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
tener en el equipo personas con habilidades de programación. La codificación es importante, pero las personas
que sepan cómo realizar recorridos, revisiones, pruebas y documentar sistemas son también importantes. Algu-
nas personas son buenas para ver la idea general mientras que otras tienen un buen desempeño cuando las tareas
se descomponen en otras más pequeñas. Cada equipo debe tener ambos tipos de individuos.
Además de lo básico, un gerente de proyectos debe buscar personas con experiencia y entusiasmo. La expe-
riencia es en especial importante cuando tratamos de estimar el tiempo requerido para completar un proyecto. La
experiencia en programación puede referirse a que el código se podría desarrollar cinco veces más rápido que si
lo desarrollara un equipo inexperto. También es útil contar con un experto de capacidad de uso en el equipo.
El equipo debe estar motivado. Una forma de mantener la orientación positiva del mismo durante todo el
proceso es seleccionar a las personas adecuadas desde el inicio. Busque entusiasmo, imaginación y la habilidad
de comunicarse con distintos tipos de personas. Estos atributos básicos contienen el potencial para el éxito. Tam-
bién es conveniente contratar buenos redactores y oradores elocuentes que puedan presentar propuestas y traba-
jar directamente con los clientes.
La confianza es una parte importante de un equipo. Todos los miembros del proyecto deben actuar respon-
sablemente y comprometer su mejor esfuerzo para completar su parte del proyecto. Tal vez las personas tengan
estilos de trabajo distintos, pero todos necesitan estar de acuerdo en trabajar en conjunto hacia la obtención de
una meta común.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 85
O P O R T U N I D A D D E C O N S U LT O R Í A 3 . 5
del grupo. Ambos son necesarios para el equipo. Otros investigadores han etiquetado a estos individuos respec-
tivamente como líder de tareas y líder socioemocional. Cada equipo está sujeto a tensiones que surgen del hecho
de buscar un equilibrio entre realizar las tareas y mantener las relaciones entre los miembros del equipo.
Para que el equipo pueda preservar su efectividad hay que resolver las tensiones en forma continua. Si sólo
minimizamos o ignoramos las tensiones, el equipo se volverá inefectivo y al final se desintegrará. Gran parte de
la liberación necesaria de la tensión se puede lograr a través del uso habilidoso de la retroalimentación por parte
de todos los miembros del equipo. Sin embargo, todos los miembros tienen que estar de acuerdo en que la
forma de interactuar (es decir, el proceso) es lo suficientemente importante como para merecer algo de tiempo.
En una sección posterior veremos los objetivos de productividad para los procesos.
Para asegurar que todos estén de acuerdo en la interacción apropiada de los miembros, hay que crear nor-
mas de equipo explícitas e implícitas (expectativas, valores y formas de comportamiento colectivas) para guiar
a los miembros en sus relaciones. Las normas de un equipo le pertenecen a éste y no necesariamente se pueden
transferir a otro. Estas normas cambian a través del tiempo y se pueden considerar más como un proceso de in-
teracción que un producto.
Las normas pueden ser funcionales o disfuncionales. Sólo porque un comportamiento específico sea una
norma para un equipo no significa que esté ayudándolo a lograr sus objetivos. Por ejemplo, la expectativa de que
los miembros más recientes tengan que realizar toda la programación de tiempos de los proyectos puede ser una
norma de equipo. Al adherirse a ésta, el equipo está colocando mucha presión en los nuevos miembros y no está
aprovechando por completo la experiencia del mismo. Es una norma que, si se lleva a cabo, podría hacer que los
miembros del equipo desperdicien recursos valiosos.
Los miembros del equipo necesitan explicitar las normas y evaluar en forma periódica si son funcionales o
disfuncionales para ayudar a que el equipo logre sus objetivos. La expectativa primordial para su equipo debe ser
que el cambio es la norma. Pregúntese si las normas del equipo ayudan o dificultan el progreso del equipo.
www.xlibros.com
86 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Los analistas de sistemas están acostumbrados a pensar acerca de los objetivos de productividad para los
empleados que muestran salidas tangibles, como el número de pantalones de mezclilla que se cosen por hora, el
número de entradas introducidas por minuto o el número de artículos que se escanean por segundo. Sin embargo
y a medida que aumenta la productividad de la manufactura, es cada vez más claro que la productividad adminis-
trativa debe mantener el ritmo. Es con este propósito en mente que se establecen los objetivos de productividad
para el equipo de análisis de sistemas.
El equipo necesita formular los objetivos y estar de acuerdo en ellos; además se deben basar en la experien-
cia de los miembros del equipo, el desempeño en proyectos anteriores y la naturaleza del proyecto específico. Los
objetivos variarán un poco para cada proyecto que se emprenda, ya que algunas veces se instalará todo un sistema
mientras que otros proyectos podrían involucrar modificaciones limitadas a una parte de un sistema existente.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 87
www.xlibros.com
88 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 3.23
Podemos utilizar un diagrama de esqueleto de
pescado (fishbone) para identificar todo lo que
puede salir mal en el desarrollo de un sistema.
LA PROPUESTA DE SISTEMAS
Organización de la propuesta de sistemas
Aunque el propósito de los estatutos del proyecto es identificar los objetos, determinar el alcance y asignar res-
ponsabilidades, el analista también necesita preparar una propuesta de sistemas en la que se incluya la mayor
cantidad de detalles sobre las necesidades, opciones y recomendaciones del sistema. En esta sección veremos el
contenido y el estilo que se utilizan para formular una propuesta de sistemas.
QUÉ DEBEMOS INCLUIR EN LA PROPUESTA DE SISTEMAS Hay diez secciones principales que conforman una
propuesta de sistemas por escrito. Cada una de estas partes tiene una función específica, por lo que en última
instancia la propuesta se debe ordenar de la siguiente manera:
1. Carta de presentación.
2. Portada del proyecto.
3. Índice de contenido.
4. Resumen ejecutivo (incluyendo las recomendaciones).
5. Esquema del estudio de sistemas con la documentación apropiada.
6. Resultados detallados del estudio de sistemas.
7. Alternativas de sistemas (tres o cuatro posibles soluciones).
8. Recomendaciones de los analistas de sistemas.
9. Resumen de la propuesta.
10. Apéndices (documentación variada, resumen de fases, correspondencia, etcétera).
En la propuesta de sistemas debemos incluir una carta de presentación para los gerentes y la fuerza de tra-
bajo de TI. Esta carta debe enlistar a las personas que hicieron el estudio e incluir un resumen de los objetivos
del mismo. La carta de presentación debe ser concisa y amigable.
En la portada debe incluir el nombre del proyecto, los nombres de los miembros del equipo de análisis de
sistemas y la fecha en que se envía la propuesta. El título de la misma debe expresar con precisión su contenido,
aunque también puede incluir algo de imaginación. El índice de contenido puede ser útil para los que leen pro-
puestas extensas. Si la propuesta tiene menos de 10 páginas puede omitir el índice de contenido.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 89
El resumen ejecutivo puede tener de 250 a 375 palabras. En él se informa el quién, qué, cuándo, dónde, por
qué y cómo de la propuesta, de igual forma que lo haría el primer párrafo en un artículo de noticias. También
debe incluir las recomendaciones del analista de sistemas y la acción deseada por parte de la administración, ya
que algunas personas tendrán tiempo de leer sólo el resumen. Debe escribirse al último, después de completar el
resto de la propuesta.
El esquema del estudio de sistemas provee información sobre los métodos que se utilizaron en el estudio, y
quién o qué fue lo que se estudió. En esta sección se deben incluir los cuestionarios, las entrevistas, las muestras
de datos de archivo, los procesos de observación o creación de prototipos que se hayan utilizado en el estudio de
sistemas.
La sección de resultados detallados describe lo que descubrió el analista de sistemas en relación con las ne-
cesidades humanas y de sistemas por medio de todos los métodos descritos en la sección anterior. Aquí debemos
incluir las conclusiones sobre los problemas que experimentan los trabajadores al interactuar con tecnologías y
sistemas que pasan a primer plano a través del estudio. También hay que incluir los problemas o sugerir las opor-
tunidades que presentan las alternativas que presentaremos en la siguiente sección.
En la sección de la propuesta acerca de las alternativas de sistemas, el analista debe presentar dos o tres so-
luciones alternativas que hagan frente de manera directa a los problemas antes mencionados. Las alternativas que
se presenten aquí deben incluir una en la que se recomiende dejar el sistema como está. Hay que explorar cada
alternativa por separado. Además hay que describir los costos y beneficios de cada situación. Como por lo gene-
ral hay puntos de conflicto involucrados en cualquier solución, asegúrese de incluir las ventajas y desventajas de
cada una.
Cada alternativa debe indicar con claridad lo que deben hacer los usuarios y gerentes para implementarla. La
redacción debe ser lo más clara posible, como “Comprar computadoras portátiles para todos los gerentes de nivel
medio”, “Comprar software empaquetado para respaldar a los usuarios en el manejo del inventario” o “Modificar
el sistema existente mediante el financiamiento de esfuerzos internos de programación”.
Una vez que el analista de sistemas haya sopesado las alternativas, tendrá una opinión profesional definida so-
bre la solución que sea más funcional. La sección de recomendaciones del analista de sistemas expresa la solución
recomendada. Aquí hay que incluir las razones que respaldan la recomendación del equipo, para que sea fácil com-
prender por qué se recomienda. Esta recomendación debe fluir en forma lógica del análisis previo de las soluciones
alternativas; además debe relacionar claramente los hallazgos sobre la interacción humano-computadora con la op-
ción que se ofrece.
El resumen de la propuesta es un enunciado corto que refleja el contenido del resumen ejecutivo. En él se
informan los objetivos del estudio y la solución recomendada. El analista debe enfatizar una vez más la impor-
tancia y viabilidad del proyecto, junto con el valor de las recomendaciones para cumplir con los objetivos de los
usuarios y mejorar la empresa. Concluya la propuesta con una observación positiva.
El apéndice es la última parte de la propuesta de sistemas, y puede incluir cualquier información que el ana-
lista de sistemas considere de interés para ciertos individuos, pero que no sea esencial para comprender el estudio
de sistemas y lo que se está proponiendo.
Una vez que termine de escribir la propuesta de sistemas, seleccione cuidadosamente quiénes van a recibir
el informe. Entregue el informe personalmente a las personas que seleccionó. Su visibilidad es importante para la
aceptación y el éxito en última instancia del sistema.
www.xlibros.com
90 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
FIGURA 3.24
Lineamientos para crear tablas
Cantidad de Tabla 4
efectivas. conjun
y color dura tos de mancuernas
nte los años que se vend
Hay de 2004 a ieron por pe
que 2009, incl so
las f etiq uyéndolos
ilas u
y co etar
lumn Red
as a
des cte un
crip títu
de u ti lo
n cu vo. El us
la a a d r o
p o
tabl ariencia mejora
a. de la
Tipo de conj
unto 2004
40 kg, gris 2005 2006 20
3.5 07 2008
48 kg, gris 3.4 3.7 2009
55 kg, gris 5.9 5.5 3.0 2.5
3.9 5. 1 4.6 2.0
68 kg, gris 4.8 5. 2.0 2.
1. 0 5 3. 5 0
100 kg, gris 1.9 4.2
1. 2 2.2 2. 5.5
55 kg, r,b,a 1.8 5 1.3
* – 1.5 0.7 1.2
100 kg, r,b – 1.2
,a – – 3. 1.5
– 4 6.5
* r,b,a sign – 0.8 2.6
ifica rojo, bl 1.8
anco y azul 1.2
3. Enumere y asigne un título a la tabla en la parte superior de la página. El título debe ser descriptivo y
representativo.
4. Etiquete cada fila y columna. Use más de una línea para un título, de ser necesario.
5. Use una tabla cuadriculada si hay espacio para ello. Las rayas verticales en las columnas mejoran la
legibilidad.
6. Use notas al pie si es necesario para explicar la información detallada contenida en la tabla.
En las secciones anteriores presentamos varios métodos para comparar costos y beneficios. Hay que poner los
resultados de esas comparaciones en tablas y mostrarlos así en la propuesta de sistemas. Si realiza un análisis
de punto de equilibro, debe incluir una tabla en la que se ilustren los resultados del análisis. La retribución
se puede mostrar en tablas que sirvan como apoyo adicional para los gráficos. También podría incluir en la pro-
puesta de sistemas una tabla pequeña en la que se comparen los sistemas computacionales o las opciones.
USO EFECTIVO DE LOS GRÁFICOS Hay muchos tipos de gráficos: de línea, de columna, de barras y de pastel, por
mencionar unos cuantos. Los gráficos de línea, de columna y de barra comparan variables, mientras que los de
barras y de áreas ilustran la composición del 100 por ciento de una entidad.
A continuación le mostramos los lineamientos para incluir gráficos efectivos en una propuesta (consulte la
figura 3.25):
1. Seleccione un estilo de gráfico que transmita de manera efectiva el significado que desea.
2. Integre el gráfico en el cuerpo de la propuesta.
3. Asigne al gráfico un número de figura secuencial y un título representativo.
4. Etiquete los ejes y las líneas, columnas, barras o piezas del pastel en el gráfico.
5. Incluya una clave para identificar y diferenciar las líneas de colores, las barras sombreadas o las áreas con
patrones cuadriculados.
Gran parte de los detalles que se incluyen en una propuesta de sistemas se obtienen de las entrevistas, los
cuestionarios, los muestreos, el descubrimiento de otros datos rigurosos y mediante la observación. En los si-
guientes dos capítulos hablaremos sobre estos temas.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 91
FIGURA 3.25
Lineamientos para dibujar gráficos
de líneas efectivos.
70,000
60,000
50,000
Punto de
40,000 equilibrio
Costo
($)
30,000
20,000
10,000
clave.
Incluya una
2006 ejes
2007 2008
2009 Etiquete los
2010
Año
Incluya un
vo
representati
RESUMEN
Los cinco fundamentos más importantes de la administración dio de viabilidad los analistas recopilan datos que permiten a la
de proyectos que debe manejar el analista de sistemas son administración decidir si se puede o no continuar con un estu-
1) inicio del proyecto: definición del problema, 2) determinar la dio de sistemas completo. Mediante un inventario ordenado del
viabilidad del proyecto, 3) planeación y control de actividades, equipo con el que ya se cuenta, los analistas de sistemas podrán
4) programación de fechas y tiempos del proyecto y 5) admi- determinar con más efectividad si deben recomendar o no hard-
nistración de los miembros del equipo de análisis de sistemas. ware computacional nuevo, modificado o actual.
Al enfrentarse a las cuestiones sobre cómo pueden las empresas El hardware computacional se puede adquirir mediante
cumplir con sus objetivos y resolver problemas de sistemas, el compra, arrendamiento o renta. Los distribuidores ofrecen
analista crea una definición del problema. Esta definición es servicios de soporte como mantenimiento preventivo y capa-
un enunciado formal del problema, en el que se incluyen 1) las citación para los usuarios, que por lo general se negocian por
cuestiones de la situación presente, 2) los objetivos para cada separado. El software se puede crear como un producto perso-
cuestión, 3) los requerimientos que se deben incluir en todos nalizado, se puede comprar como un paquete de software co-
los sistemas propuestos y 4) las restricciones que limitan el mercial de venta en canales convencionales (COTS) o se puede
desarrollo de los sistemas. subcontratar un proveedor de servicios de aplicación (ASP)
Seleccionar un proyecto es una decisión difícil, ya que se para que lo desarrolle.
solicitarán más proyectos de los que realmente se puedan llevar Para preparar una propuesta de sistemas hay que identifi-
a cabo. Cinco criterios importantes de selección son 1) que el car todos los costos y beneficios de varias alternativas. El ana-
proyecto solicitado esté respaldado por la administración, lista de sistemas cuenta con varios métodos a su disposición
2) que se sincronice en forma apropiada para comprometer los para pronosticar a futuro los costos, beneficios, volúmenes de
recursos, 3) que ayude a que la empresa avance hacia la obten- transacciones y variables económicas que afectan a los costos
ción de sus objetivos, 4) que sea práctico y 5) que sea lo bas- y beneficios. Éstos pueden ser tangibles (cuantificables) o in-
tante importante como para considerarlo por encima de otros tangibles (no son cuantificables y es difícil compararlos direc-
proyectos. tamente). Un analista de sistemas tiene muchos métodos a su
Si un proyecto solicitado cumple con estos criterios, se disposición para analizar costos y beneficios, entre los cuales
puede realizar un estudio de viabilidad en cuanto a sus méritos están el análisis de punto de equilibrio, el método de retribu-
operacionales, técnicos y económicos. Por medio de este estu- ción y el análisis de flujo de efectivo.
www.xlibros.com
92 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
“A lgunas veces, las personas que han estado aquí durante cierto
tiempo se sorprenden al ver cuánto hemos crecido. Admito que no
sistemas que encuentre. Sugerencia: Cree un formulario de
inventario para simplificar su tarea.
es fácil llevar la cuenta de lo que hace cada persona, o incluso de las 2. Use los lineamientos de evaluación de software que vimos en
compras que ha realizado cada departamento en cuanto al hardware el libro para realizar una breve evaluación de GEMS, paquete
y software. Pero estamos trabajando en eso. A Snowden le gustaría de software utilizado por los empleados de sistemas
ver más rendición de cuentas en las compras de computadoras. administrativos (Management Systems). Elabore una breve
Desea asegurarse de que sepamos lo que tenemos, en dónde y por crítica de un párrafo de este software personalizado y
qué lo tenemos, quién lo usa y si está impulsando la productividad compárelo con el software comercial de venta en los canales
de MRE o, dicho con sus propias palabras, ‘si sólo se trata de un convencionales como Microsoft Project.
juguete costoso’ del cual podamos deshacernos”. 3. Enliste los costos y beneficios intangibles de GEMS, según
lo que informan los empleados de MRE.
4. Describa brevemente las dos alternativas que considera Snowden
Preguntas de HYPERCASE para el sistema de rastreo e informes de proyectos propuesto.
1. Complete un inventario de equipo de cómputo para la unidad 5. ¿Qué factores organizacionales y políticos debe considerar
de capacitación y sistemas administrativos (Training and Snowden al proponer su nuevo sistema a MRE? (Describa
Management Systems Unit) en el que describa todos los tres conflictos centrales en un párrafo corto.)
FIGURA 3.HC1
La sala de recepción se asemeja a la de una empresa común. Busque el
directorio en esta pantalla de HyperCase si desea visitar a alguien.
La planeación de un proyecto incluye la estimación del Hay otra técnica conocida como Técnicas de evaluación
tiempo requerido para cada una de las actividades del analista, y revisión de programas (PERT), la cual muestra las activida-
la programación de tiempos y fechas de estas actividades, y la des como flechas en una red. PERT ayuda al analista a determi-
manera de agilizarlas en caso de ser necesario para asegurar nar la ruta crítica y el tiempo de inactividad, lo que constituye
que el proyecto se termine a tiempo. Una técnica disponible la información requerida para el control efectivo del proyecto.
para que el analista de sistemas pueda programar tareas es el Se recomienda la creación de un documento en el que se
gráfico de Gantt, el cual muestra las actividades como barras incluyan los estatutos del proyecto, el cual contiene las ex-
en un gráfico. pectativas de los usuarios y los productos que el analista debe
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 93
entregar, ya que los tiempos de entrega poco realistas exigidos El analista de sistemas debe realizar tres pasos principales
por la administración, el agregar personal innecesario a un pro- para elaborar una propuesta efectiva de sistemas: organizar el
yecto en el que se intenta cumplir con un tiempo de entrega contenido de la propuesta en forma efectiva, escribir la pro-
poco realista y el no permitir que los equipos de desarrollo puesta en un estilo de negocios apropiado y presentar en forma
busquen ayuda de expertos fuera de su grupo inmediato, fueron oral una propuesta de sistemas informativa. Para que sea efec-
factores citados por los programadores como razones por las tiva, la propuesta se debe escribir en forma clara y compren-
que los proyectos fracasaban. Por lo general podemos evitar es- sible; además hay que dividir su contenido en diez secciones
tos fracasos si examinamos las motivaciones para los proyectos funcionales. Son importantes las consideraciones visuales a la
solicitados, así como los motivos que tenga nuestro equipo para hora de elaborar una propuesta.
recomendar o evitar un proyecto específico.
PREGUNTAS DE REPASO
1. ¿Cuáles son los cinco fundamentos principales de un proyecto?
2. Mencione tres formas de averiguar sobre los problemas o las oportunidades potencialmente asociados con una solución
de sistemas.
3. Enliste los cinco criterios para la selección de proyectos de sistemas.
4. Defina viabilidad técnica.
5. Defina viabilidad económica.
6. Defina viabilidad operacional.
7. Mencione cuatro criterios para evaluar el hardware de sistemas.
8. ¿Cuáles son las tres opciones principales para la adquisición de hardware computacional?
9. ¿Qué significa COTS?
10. ¿Qué implica un ASP, en términos de entrega de software?
11. Defina los costos y beneficios tangibles. Dé un ejemplo de cada uno.
12. Defina los costos y beneficios intangibles. Dé un ejemplo de cada uno.
13. Enliste cuatro técnicas para comparar los costos y beneficios de un sistema propuesto.
14. ¿Cuándo es útil el análisis de punto de equilibrio?
15. ¿Cuáles son las tres desventajas de usar el método de retribución?
16. ¿Cuándo se utiliza el análisis del flujo de efectivo?
17. Como lineamiento general, ¿cuándo se debe utilizar el análisis del valor presente?
18. ¿Qué es un gráfico de Gantt?
19. ¿Cuándo es útil un diagrama PERT para los proyectos de sistemas?
20. Mencione tres ventajas de usar un diagrama PERT en vez de un gráfico de Gantt para programar tiempos y fechas de los
proyectos de sistemas.
21. Defina el término ruta crítica.
22. ¿Cómo evalúa un gerente de proyectos el riesgo de que las cosas salgan mal y de tener eso en cuenta al planear el tiempo
requerido para completar el proyecto?
23. Mencione los dos tipos de líderes de equipo.
24. ¿Qué implica una norma de equipo disfuncional?
25. ¿Qué implica el proceso de equipo?
26. ¿Cuáles son tres razones por las que el establecimiento de objetivos parece motivar a los miembros del equipo de análisis
de sistemas?
27. ¿Cuáles son las cuatro formas en las que la administración de proyectos de comercio electrónico difiere de la
administración de proyectos tradicionales?
www.xlibros.com
94 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
PROBLEMAS
1. Williwonk’s Chocolates de St. Louis fabrica varios tipos de dulces y novedades de chocolate. La empresa tiene seis
tiendas en la ciudad: cinco en los principales aeropuertos metropolitanos y una pequeña sucursal de pedidos por correo.
Williwonk’s tiene un pequeño sistema de información computarizado que rastrea el inventario en su planta, ayuda a
programar la producción y algunas otras cosas más, pero este sistema no está enlazado directamente con ninguna de sus
tiendas de menudeo. El sistema de pedidos por correo se administra en forma manual.
Hace poco, varias tiendas de Williwonk’s experimentaron una erupción de quejas de los clientes de pedidos por
correo, debido a que los dulces llegaban echados a perder, que no llegaban cuando se les prometía o que nunca llegaban;
la empresa también recibió varias cartas en las que se quejaban de que los dulces en varios aeropuertos sabían rancios.
Williwonk’s ha estado vendiendo una nueva forma dietética de chocolate bajo en calorías, formulada con un edulcorante
artificial. Las ventas han sido activas, pero han surgido problemas por enviar el tipo incorrecto de chocolate a la
dirección en la que vive una persona diabética. Hubo varias quejas, por lo que Williwonk’s envió varias cajas gratis de
chocolate como desagravio.
A la gerencia le gustaría vender productos a través de Web, pero cuentan con sólo algunas páginas Web con
información sobre la compañía y un formulario de pedidos que se puede imprimir. No existen los pedidos a través de
Web. A uno de los ejecutivos principales le gustaría vender chocolates personalizados con el nombre de una persona en
cada pieza. Aunque el área de producción aseguró a la gerencia que esto se podría hacer fácilmente, no hay un método
para pedir tales chocolates personalizados.
Otro de los ejecutivos principales mencionó que Williwonk’s se asoció con varios fabricantes de chocolate
europeos y que importará chocolate de varios países. En la actualidad hay que hacer esto a través del teléfono, por
correo electrónico o por correo convencional. El ejecutivo desea un sitio Web interno que permita a los empleados
realizar pedidos directamente a las empresas asociadas. Todo esto ha provocado que varios gerentes soliciten un análisis
de tendencias. Cuando hay inventario en exceso algunos chocolates se arrancian, mientras que otras veces hay escasez de
ciertos tipos de chocolate.
Las tendencias de variación por temporadas y días festivos podrían ayudar a Williwonk’s a mantener un inventario
adecuado. El gerente de control de inventario insiste en que es necesario implementar todos los cambios antes de la
siguiente temporada festiva. “Hay que tener una fecha absoluta definida para que todo esté terminado”, recalcó Candy,
una de los gerentes de nivel superior. “Debemos asegurarnos de que todo esté trabajando perfectamente antes de que el
sitio se haga público”, continuó. “¡No quiero clientes que reciban los chocolates incorrectos!”. Además, el gerente de
procesamiento de pedidos mencionó que el sistema debe ser seguro.
Usted llevaba trabajando dos semanas con Williwonk’s en varias modificaciones para su sistema de información de
inventario cuando escuchó a dos gerentes discutir sobre estas cuestiones. Haga una lista de las posibles oportunidades o
problemas que se podrían convertir en proyectos de sistemas.
2. ¿De dónde proviene la mayor parte de la retroalimentación sobre los problemas con los productos de Williwonk’s en el
problema 1? ¿Qué tan confiables son las fuentes? Explique en un párrafo.
3. Después de conocerlos mejor, usted se acerca a los ejecutivos de la administración de Williwonk’s con sus ideas sobre
las posibles mejoras de sistemas que podrían hacerse cargo de algunos de los problemas o las oportunidades que se
mencionan en el problema 1.
a. Escriba en dos párrafos sus sugerencias para los proyectos de sistemas. Haga todas las suposiciones realistas que sea
necesario.
b. ¿Hay problemas u oportunidades descritas en el problema 1 que no sean adecuadas? Explique su respuesta.
4. Cree la definición de un problema para Williwonk’s, según lo que se describe en el problema 1. Estime las
ponderaciones de importancia. Incluya por lo menos un requerimiento y una restricción.
5. Cree una lista de requerimientos de los usuarios para la definición del problema que creó en el problema 4.
6. Delicato, Inc., un fabricante de instrumentos precisos de medición para fines científicos, le presentó una lista de
atributos que sus gerentes consideran que probablemente sean importantes para seleccionar un distribuidor de hardware
y software de computadora. Los criterios no se listan en orden de importancia.
1. Bajo precio.
2. Software escrito precisamente para aplicaciones de ingeniería.
3. El distribuidor realiza mantenimiento de rutina en el hardware.
4. Capacitación para los empleados de Delicato.
a. Critique la lista de atributos en un párrafo.
b. Use la entrada inicial para ayudar a Delicato, Inc., a generar una lista más adecuada de criterios para seleccionar
distribuidores de hardware y software.
7. SoftWear Silhouettes es una empresa de ventas por correo que está creciendo con rapidez y se especializa en ropa de
algodón. A la gerencia le gustaría expandir sus ventas al entorno Web mediante la creación de un sitio de comercio
electrónico. La empresa tiene dos analistas de sistemas que trabajan tiempo completo y un programador. Las oficinas de
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 95
la empresa se encuentran en una pequeña ciudad aislada en Nueva Inglaterra y los empleados que se hacen cargo del
negocio tradicional de pedidos por correo no conocen mucho de computadoras.
a. Considerando la situación de la empresa, dibuje una lista de atributos de software en los que SoftWear Silhouettes
debería hacer énfasis a la hora de seleccionar el software para crear un sitio Web e integrar el negocio de pedidos por
correo con el negocio del sitio Web.
b. ¿Recomendaría usted software COTS, software personalizado o la subcontratación de un ASP? Indique su opción y
defiéndala en un párrafo.
c. Liste las variables que contribuyeron a su respuesta en el inciso b.
8. A continuación le presentamos la demanda de 12 años de Viking Village, un juego disponible en la actualidad para
equipos de bolsillo y teléfonos inteligentes (smartphones).
Año Demanda
1998 20,123
1999 18,999
2000 20,900
2001 31,200
2002 38,000
2003 41,200
2004 49,700
2005 46,400
2006 50,200
2007 52,300
2008 49,200
2009 57,600
a. Use el análisis de punto de equilibrio para determinar el año en el que Interglobal Paper se
equilibrará.
b. Grafique los costos y muestre el punto de equilibrio.
www.xlibros.com
96 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
11. A continuación se muestran los beneficios de sistemas para Interglobal Paper Company (del problema 10):
Año Beneficios
1 $55,000
2 75,000
3 80,000
4 85,000
a. Use los costos del sistema propuesto de Interglobal Paper del problema 10 para determinar el periodo de retribución
(use el método de retribución).
b. Grafique los beneficios contra los costos e indique el periodo de retribución.
12. Glenn’s Electronics, una empresa pequeña, estableció un servicio de computadoras. La tabla que se muestra a
continuación muestra los ingresos esperados durante los primeros cinco meses de operación, además de los costos por
remodelación de oficinas, etcétera. Determine el flujo de efectivo y el flujo de efectivo acumulado para la empresa.
¿Cuándo se espera que Glenn’s muestre una ganancia?
13. Alamo Foods de San Antonio desea introducir un nuevo sistema computacional para su almacén de productos
perecederos. Los costos y beneficios de este sistema son:
a. Dada una tasa de descuento del 8 por ciento (.08), realice un análisis del valor presente con los datos para Alamo
Foods (sugerencia: use la fórmula
1
111 + i 2 n
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 97
FIGURA 3.EX1
Descripción Tarea Va después de Tiempo (semanas)
Datos para ayudar en la
Dibujar el flujo de datos A Ninguna 5 organización de un proyecto de
Dibujar árbol de decisiones B A 4 diseño para crear un sistema
Revisar árbol C B 10 de información que rastrea los
Escribir proyecto D C, I 4 envíos de comida congelada a los
Organizar diccionario de datos E A 7 almacenes.
Realizar prototipo de salida F Ninguna 2
Revisar diseño de salida G F 9
Escribir casos de uso H Ninguna 10
Diseñar base de datos I H, E y G 8
19. Además de un gráfico de Gantt usted dibuja también un diagrama PERT para Brian, de forma que le pueda comunicar la
necesidad de mantener vigilada la ruta crítica. Consulte la figura 3.EJ2, que se derivó de los datos de la figura 3.EJ1.
Liste todas las rutas, calcule e identifique la ruta crítica.
B FIGURA 3.EX2
20 40 C
E D
El diagrama PERT de la empresa
A
60 70 de comida congelada de Brian.
H I
10 50
F G
30
20. Cherry Jones es propietaria de una empresa de medicina homeopática llamada Fainthealers. Ella vende vitaminas y otros
productos relativamente no perecederos para quienes desean opciones relacionadas con la medicina alternativa. Cherry
está desarrollando un nuevo sistema en el que hay que volver a capacitar al personal. Dada la información de la figura
3.EJ3, realice un diagrama PERT para ella e identifique la ruta crítica. Si Cherry pudiera encontrar la forma de ahorrar
tiempo en la fase “escribir casos de uso”, ¿sería útil? ¿Por qué sí o por qué no?
21. Angus McIndoe quiere modernizar su popular restaurante, para lo cual piensa adaptarlo más a las preferencias de sus
clientes frecuentes: llevar el registro de lo que les gusta y disgusta. Por ende le interesa toda la información sobre los
lugares en los que les gusta sentarse, qué prefieren comer y a qué hora llegan por lo general, ya que piensa que de esta
forma podrá atender mejor a sus clientes. Angus le ha pedido a usted que desarrolle un sistema para él que le ayude a
mantener felices a sus clientes y, consecuentemente, mejorar su negocio.
Usted ha escuchado lo que Angus dijo sobre sus clientes. Sin duda hay más preferencias que puede rastrear.
Desarrolle la definición del problema para Angus, en forma similar a la que desarrolló para el Servicio de banquetes
de Catherine en este capítulo.
22. Hace poco, dos analistas recién egresados se unieron a su grupo de analistas de sistemas en la recién formada empresa
Mega Phone. Cuando hablaron con usted sobre el grupo, mencionaron que algunas cosas les parecen extrañas. Una de
ellas es que, aparentemente, los miembros del grupo admiran a dos líderes, Bill y Penny, y no sólo a uno.
www.xlibros.com
98 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Lo que observan es que Bill parece bastante relajado, mientras que Penny siempre está planeando y programando
actividades. También observaron que todos “simplemente parecen saber qué hacer” cuando entran a una reunión, incluso
cuando no se proporcionan instrucciones. Por último, resaltaron la apertura del grupo en cuanto a lidiar con los
problemas a medida que van surgiendo, en vez de dejar que las cosas se salgan de control.
a. A modo de explicación para los nuevos miembros del equipo, identifique los tipos de líderes que parecen ser Bill y
Penny, respectivamente.
b. Explique el enunciado de “todos simplemente parecen saber qué hacer”. ¿Qué es lo que guía su comportamiento?
c. ¿Qué concepto describe de una mejor manera la apertura del grupo que mencionaron los nuevos miembros del
equipo?
23. “Pienso que es justo escribir todas las alternativas que has considerado”, dice Lou Cite, un supervisor de personal
para Day-Glow Paints. “Después de todo, has estado trabajando en esta cosa de los sistemas durante un buen tiempo y
creo que tanto a mi jefe como a los demás les interesaría ver lo que averiguaste”. Usted está hablando con Lou al
tiempo que se prepara para elaborar la propuesta final de sistemas que su equipo presentará a la gerencia de nivel
superior.
a. En un párrafo explique a Lou por qué su propuesta no contendrá (y no debe hacerlo) todas las alternativas que su
equipo ha considerado.
b. En un párrafo hable sobre los tipos de alternativas que deben aparecer en la propuesta final de sistemas.
PROYECTOS EN GRUPO
1. Weil Smile Clinic es una clínica dental operada por los doctores Bonnie y Jeff; ellos necesitan mantener a salvo los datos
necesarios sobre sus pacientes y los seguros médicos. Investigaron sobre los respaldos en línea como SOS Online, Spare
Backup, Mozy Remote Backup y Data Deposit Box. Analice el costo de estos u otros servicios para después ayudar a los
doctores Bonnie y Jeff a tomar una decisión. ¿Cuáles son los costos y beneficios intangibles al respaldar información de
esta forma? ¿Deberían usar un sistema de respaldo o buscar alguna otra forma? Defienda su análisis y sus
recomendaciones.
2. Explore cuatro o cinco proveedores de voz sobre IP (VoIP). Haga una lista de los costos, incluyendo la cuota de
instalación, el costo mensual del plan básico, el costo mensual del plan ilimitado y el costo de un adaptador o cualquier
otra cuota requerida. Después elabore una lista de atributos como las llamadas gratis en la red, llamadas internacionales,
números telefónicos virtuales, teleconferencias, soporte para ID de llamadas, etcétera. Explique cómo podría utilizar una
persona toda la información cuantitativa y cualitativa para tomar una decisión informada sobre el proveedor de VoIP
adecuado. ¿Hay algunas otras variables importantes? ¿Recomendaría algún tipo de software para que ayude a comparar
estos servicios?
3. Seleccione un proveedor de VoIP con base en el análisis del proyecto en grupo 2.
4. Con los miembros de su equipo, explore el software de administración de proyectos como Microsoft Project. ¿Qué
características hay disponibles? Trabaje con su grupo para hacer una lista de ellas. Haga que su grupo evalúe la utilidad
del software para administrar un proyecto del equipo de análisis y diseño de sistemas. Indique en un párrafo si el
software que va a evaluar facilita la comunicación de los miembros el equipo y la administración de las actividades,
tiempo y recursos del equipo. Indique las características específicas que respaldan estos aspectos de cualquier proyecto.
Observe si el software no alcanza a cumplir estos criterios en cualquier aspecto.
5. Dibuje un diagrama de esqueleto de pescado sobre los posibles problemas que pueden ocurrir al construir un sitio Web
para una agencia de viajes que desea vender paquetes vacacionales en línea para el siguiente periodo extenso de
vacaciones (ya sea diciembre o junio).
BIBLIOGRAFÍA SELECCIONADA
Alter, S. Information Systems: The Foundation of E-Business, 4ta. Edición, Upper Saddle River, NJ: Prentice Hall, 2002.
Bales, R.F. Personality and Interpersonal Behavior, Nueva York: Holt, Rinehart y Winston, 1970.
Carnegie-Mellon Software Engineering Institute, “CBS Overview”. Disponible en: www.sei.cmu.edu/cbs/overview.html. Úl-
timo acceso: 15 de julio de 2009.
Construx Software Builders. Disponible en: www.construx.com. Último acceso: 15 de julio de 2009.
Sitio Web de Costar. Disponible en: www.softstarsystems.com. Último acceso: 15 de julio de 2009.
Glass, R. “Evolving a New Theory of Project Success”, Communications of the ACM, Vol. 42, Núm. 11, 1999, pp. 17-19.
Levine, D. M., P. R. Ramsey y M. L. Berenson. Business Statistics for Quality and Productivity. Upper Saddle River, NJ: Pren-
tice Hall, 1995.
Linberg, K. R. “Software Perceptions About Software Project Failure: A Case Study”. Journal of Systems and Software, Vol.
49, Núm. 2 y 3, 1999, pp. 177-92.
Longstreet Consulting, www.ifpug.org. Último acceso: 15 de julio de 2009.
McBreen, P. Questioning Extreme Programming. Boston: Addison-Wesley Co., 2003.
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 99
Schein, E. H. Process Consultation: Its Role in Organization Development. Reading, MA: Addison-Wesley, 1969.
Shtub, A., J. F. Bard y S. Globerson. Project Management: Processes, Methodologies, and Economics, 3era. Edición. Upper
Saddle River, NJ: Pearson, 2005.
Software Product Research. Disponible en www.spr.com. Último acceso: 15 de julio de 2009.
Stefik, M., G. Foster, D. G. Bobrow, K. Kahn, S. Lanning y L. Suchman. “Beyond the Chalkboard: Computer Support for Co-
llaboration and Problem Solving in Meetings”. Communications of the ACM, Vol. 30, Núm. 1, enero 1987, pp. 32-47.
Vigder, M. R, W. M. Gentleman y J. C. Dean. “Using COTS Software in Systems Development”, http://www.nrc-cnrc.gc.ca/
eng/projects/iit/commercial-software.html. Último acceso: 15 de julio de 2009.
Walsh, B. “Your Network’s Not Ready for E-Commerce”, Network Computing. Disponible en: www.networkcomputing.
com/922/022colwalsh.html. Último acceso: 15 de julio de 2009.
www.xlibros.com
100 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
EPISODIO 3
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Llegar a conocerte
Chip entra a la oficina de Anna un día y dice: “Creo que el proyecto será uno bueno, incluso aunque se está
tardando mucho en empezar”.
Anna quita la mirada de la pantalla y le sonríe. “Me gusta lo que has hecho para organizarnos”, dice.
“No sabía que Microsoft Visio y Visible Analyst podrían ayudarnos tanto con la administración del proyecto.
He decidido realizar un diagrama PERT para la parte de recolección de los datos del proyecto. Esto nos
ayudará a planear nuestro tiempo y trabajar como equipo en actividades paralelas”.
“¿Puedo dar un vistazo al diagrama PERT?”, pregunta Chip.
Anna le muestra una pantalla con un diagrama PERT (vea la figura E3.1) y comenta: “Esto nos ayudará
inmensamente. Es mucho más fácil que planear al azar”.
“Acabo de ver que tienes Recopilar informes, Recopilar registros y formularios de captura de datos, y
Recopilar documentos cualitativos como tareas paralelas”, observa Chip al tiempo que mira la pantalla.
“Sí”, le responde Anna. “Pensé que podríamos dividir el tiempo requerido para recopilar la informa-
ción. También podemos dividir la tarea de analizar lo que aprendimos”.
“Observé que tienes un número bastante extenso de días asignados para entrevistar a los usuarios”,
comenta Chip.
“Sí”, le responde Anna. “Esta actividad también incluye la creación de preguntas, ordenarlas en secuen-
cia y otras tareas, como tomar notas del entorno de oficina y analizarlas. También supuse un estándar de seis
horas productivas por día”.
“Después de entrevistar a los usuarios será conveniente crear una definición del problema para el sis-
tema, en donde se enlisten las cuestiones y objetivos”, continúa Anna. “Una vez terminada, haremos que los
usuarios la revisen y asignen ponderaciones. Al terminar, el siguiente paso es crear una lista de requerimien-
tos de los usuarios”.
“Parece un buen plan”, contesta Chip después de una pausa reflexiva. “¿Deberíamos empezar con una
lista de preguntas?”
Anna mira su reloj. “Ahora no; se está haciendo tarde. Creo que hemos progresado mucho en cuanto a
establecer nuestro proyecto. Terminemos por este día, o ¿debería decir por esta tarde? Recuerda que conse-
guí boletos para el juego de fútbol americano”.
Chip responde: “No lo había olvidado. Voy por mi abrigo y caminaremos juntos al estadio”.
Al caminar por el campus más tarde, Chip dice: “Estoy emocionado. Es mi primer juego aquí en la
CPU. Por cierto ¿cuál es la mascota del equipo?”
“Ardillas, por supuesto”, dice Anna.
“¿Y los colores del equipo?” pregunta Chip al momento en que entran al estadio.
“Azul y blanco”, le responde Anna.
“Oh, entonces esa es la razón por la que todos gritan, ‘¡Vamos, Gran Azul!’” dice Chip, al escuchar el
rugido de la multitud.
“Exacto”, dice Anna.
FIGURA E3.1 20
Un diagrama PERT para Central
Pacific University que se utiliza A, 4 D, 6
para recopilar información.
B, 5 F, 4 G, 15 I, 4 K, 15
10 30 50 60 80 90
C, 1 E, 2 H, 14 J, 3
40 70
www.xlibros.com
CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 101
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver el diagrama PERT de recopilación de información
(Gathering Information).
E-2. Haga una lista de todas las rutas; además calcule y determine la ruta crítica para el diagrama PERT
de recopilación de información.
E-3. Use Microsoft Visio o Visible Analyst para crear el diagrama PERT que se muestra en la figura E3.2. Este
diagrama representa las actividades involucradas en las entrevistas a los usuarios y observar sus oficinas.
70 I, 2 FIGURA E3.2
Un diagrama PERT para Central
80
8
F, 4 Pacific University que se utiliza
G, 2 para la fase de entrevistas a los
H, 1 usuarios.
A, 1 B, 1 C, 2 E, 3
10 20 30 40 60
A Escribir objetivos D, 1
B Determinar a quién entrevistar Actividad simulada
C Escribir preguntas
D Preparar al entrevistado
E Entrevistar a la administración superior 50
F Entrevistar a la administración de operaciones
G Registrar y analizar las observaciones
H Sintetizar las entrevistas a la administración
I Sintetizar las entrevistas al personal de operaciones
E-4. Elabore una lista de todas las rutas; además calcule y determine la ruta crítica para el diagrama PERT
de entrevistas a los usuarios (Interviewing Users).
E-5. Use Visio o Visible Analyst para crear un diagrama PERT que genere prototipos de sistemas. La in-
formación de actividades se muestra en la figura E3.3.
FIGURA E3.3
Actividad Predecesor Duración
Una lista de actividades y tiempos
A Determinar pantallas e informes Ninguno 2 de duración estimados para el
del prototipo general proyecto de la CPU.
B Determinar contenidos de informes y pantallas A 4
C Crear prototipos de los informes B 3
D Crear prototipos de las pantallas B 4
E Obtener retroalimentación de los prototipos de C 1
los informes
F Obtener retroalimentación de los prototipos de D 2
las pantallas
G Modificar prototipos de los informes E 2
H Modificar prototipos de las pantallas F 4
I Obtener la aprobación final G, H 2
E-6. Cree la definición del problema para el caso de la CPU. Lea la entrevista con Hy Perteks en el caso
de la CPU que se encuentra en el capítulo 4, así como las entrevistas en el sitio Web de soporte para
el libro. Vaya a www.pearsonhighered.com/kendall y haga clic en el vínculo CPU Student Exercise
(ejercicio de la CPU para estudiantes) para el libro de la 8va. edición. Después haga clic en el primer
vínculo llamado CPU Interviews (entrevistas de la CPU). Tendrá que leer las cinco entrevistas adi-
cionales. Hay un vínculo Next (Siguiente) en la esquina inferior derecha de la página Web para pasar
a la siguiente entrevista.
E-7. Escriba los requerimientos de los usuarios para el caso de la CPU.
E-8. Diseñe un plan de prueba para los requerimientos creados en el ejercicio E-7.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.
pearsonhighered.com/kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Ana-
lyst, Microsoft Project o Microsoft Access que pueden usar para completar los ejercicios.
www.xlibros.com
www.xlibros.com
PARTE II
CAPÍTULO 4 Análisis
de los requerimientos
Recopilación de información: de información
métodos interactivos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Reconocer el valor de los métodos interactivos para recopilar información.
2. Elaborar preguntas para conocer mediante entrevistas los requerimientos humanos de
información.
3. Estructurar las entrevistas de una manera significativa para los usuarios.
4. Comprender el concepto de JAD y cuándo hay que usarlo.
5. Redactar preguntas efectivas para entrevistar a los usuarios sobre su trabajo.
6. Diseñar y administrar cuestionarios efectivos.
Hay tres métodos interactivos clave que puede usar para obtener los requeri-
mientos humanos de información de los miembros de la organización: entre-
vistas, diseño de aplicaciones conjuntas (JAD) y encuestas aplicadas a las
personas mediante cuestionarios. Aunque son distintos en su implementación,
estos métodos tienen muchas cosas en común. La base de sus propiedades
compartidas es hablar con las personas en la organización y escucharlas para comprender sus in-
teracciones con la tecnología, a través de una serie de preguntas cuidadosamente elaboradas.
Cada uno de los tres métodos interactivos para recopilar información cuenta con su propio
proceso establecido; usted debe seguirlo para interactuar con los usuarios. La observancia de
estas metodologías sistemáticas ayudan a asegurar el diseño y la implementación apropiados
de las entrevistas, los talleres de trabajo de JAD y los cuestionarios; además respaldarán un
análisis lúcido de los datos resultantes. En un capítulo posterior veremos los métodos discretos
(muestreo, investigación y observación del comportamiento del encargado de tomar las deci-
siones junto con su entorno físico) que no requieren el mismo grado de interactividad entre
analistas y usuarios. El uso de métodos interactivos con métodos no discretos le permitirá ob-
tener una descripción más completa de los requerimientos de información de la organización.
ENTREVISTAS
Es conveniente que se entreviste a usted mismo antes de hacerlo con alguien más. Necesita
reconocer sus predisposiciones y la forma en que éstas afectarán a sus percepciones. Su educa-
ción, intelecto, crianza, emociones y marco ético constituyen filtros relevantes para lo que usted
escuchará en sus entrevistas.
Piense en el proceso completo de la entrevista antes de llevarla a cabo. Visualice por qué la hará,
las preguntas que formulará y qué la convertirá en una entrevista exitosa de acuerdo con su criterio.
Además debe planear cómo hacer de la entrevista un suceso satisfactorio para el entrevistado.
Una entrevista para recopilar información es una conversación dirigida con un propósito
específico, en la cual se usa un formato de preguntas y respuestas. En la entrevista hay que ob-
tener las opiniones del entrevistado y lo que siente sobre el estado actual del sistema, los obje-
tivos de la organización y los personales, y los procedimientos informales para interactuar con
las tecnologías de la información.
103
www.xlibros.com
104 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Sobre todo busque las opiniones del entrevistado. Éstas pueden ser más importantes y reveladoras que los
hechos. Por ejemplo, suponga que pregunta a la propietaria de una tienda convencional, quien acaba de instau-
rar una tienda en línea, cuántos clientes piden comúnmente el reembolso de sus transacciones vía Web cada
semana. Ella le responde: “Entre 20 y 25 por semana”. Cuando usted supervisa las transacciones y descubre
que el promedio es de sólo 10.5 por semana, tal vez concluya que la propietaria está exagerando los hechos y
el problema.
Ahora imagine que en vez de lo anterior pregunta a la propietaria cuáles son sus principales preocupaciones
y ella le contesta: “En mi opinión, las devoluciones de los clientes que compran artículos a través del sitio Web
son demasiado altas”. Al buscar opiniones en vez de hechos, descubrió un problema clave que la propietaria de-
sea solucionar.
Además de las opiniones hay que tratar de capturar los sentimientos del entrevistado. Recuerde que éste
conoce mejor la organización que usted. Para que usted pueda entender mejor la cultura de organización debe
escuchar los sentimientos del que responde a la entrevista.
Los objetivos son información importante que podemos obtener de las entrevistas. Los datos “duros” pueden
explicar el desempeño en el pasado, pero los objetivos proyectan el futuro de la organización. Trate de averiguar
a través de las entrevistas la mayor cantidad posible de objetivos de la organización, pues tal vez no pueda deter-
minarlos mediante los otros métodos de recopilación de datos.
La entrevista también es un valioso momento para explorar las cuestiones sobre HCI (interacción humano-
computadora), incluyendo los aspectos ergonómicos, la capacidad de uso del sistema, qué tan placentero y diver-
tido es el sistema, y qué tan útil es para apoyar las tareas individuales.
En la entrevista debemos establecer una relación con un extraño. Hay que generar confianza y compren-
sión rápidamente y, al mismo tiempo, mantener el control de la entrevista. También necesitamos vender el
sistema, para lo cual hay que proveer información necesaria al entrevistado. Planear previamente la entrevista
le facilitará dirigirla. Por fortuna podemos aprender a realizar entrevistas en forma efectiva. A medida que
practique, usted mismo podrá ver cómo va mejorando. Más adelante en el capítulo hablaremos sobre el diseño
de aplicaciones conjuntas (JAD), que nos puede servir como alternativa a las entrevistas cara a cara en ciertas
situaciones.
FIGURA 4.1
Pasos para planear la entrevista
Pasos que debe seguir el analista
de sistemas para planear la
1. Leer el material sobre los antecedentes.
entrevista.
2. Establecer los objetivos de la entrevista.
3. Decidir a quién entrevistar.
4. Preparar al entrevistado.
5. Decidir sobre los tipos de preguntas y su estructura.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 105
Tipos de preguntas
PREGUNTAS ABIERTAS Las preguntas abiertas son del tipo: “¿Qué piensa en cuanto a poner a todos los
gerentes en una intranet?”, “Por favor explique cómo toma una decisión sobre la programación de tiempos
y fechas.”, “¿En qué formas extiende el sistema su capacidad de realizar tareas que no sería posible realizar
mediante algún otro medio?”. Abiertas describe las opciones que tiene el entrevistado para responder. La
respuesta puede constar de dos palabras o de dos párrafos. En la figura 4.2 se muestran algunos ejemplos de
preguntas abiertas.
Los beneficios de utilizar preguntas abiertas son muchos, entre los cuales tenemos:
1. El entrevistado baja la guardia.
2. El entrevistador puede percibir el vocabulario del entrevistado, lo cual refleja su educación, valores, posturas
y creencias.
3. Se proveen muchos detalles.
4. Se descubren vías de cuestionamiento adicionales que de otra manera no se hubieran explotado.
5. El entrevistado encuentra el proceso más interesante.
6. Se permite una mayor espontaneidad.
www.xlibros.com
106 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 4.3
Preguntas cerradas en entrevistas
Las preguntas cerradas en las
entrevistas limitan las opciones del • ¿Cuántas veces por semana se actualiza el repositorio del proyecto?
que responde. Los ejemplos se • En promedio, ¿cuántas llamadas recibe el centro de atención al mes?
seleccionaron de distintas • ¿Cuál de las siguientes fuentes de información es más valiosa para usted?
entrevistas y no se muestran en ° Formularios completos de quejas de los clientes
ningún orden específico. ° Quejas por correo electrónico de los consumidores que visitan el sitio Web
° Interacción cara a cara con los clientes
° Mercancía devuelta
• Enliste sus dos principales prioridades para mejorar la infraestructura de tecnología.
• ¿Quién recibe esta entrada?
FIGURA 4.4
Preguntas bipolares en entrevistas
Las preguntas bipolares en las
entrevistas son un tipo especial de • ¿Usa la Web para proveer información a los distribuidores?
pregunta cerrada. Los ejemplos se • ¿Está de acuerdo o en desacuerdo en cuanto a que el comercio
seleccionaron de distintas electrónico en Web carece de seguridad?
entrevistas y no se muestran en
• ¿Desea recibir un documento impreso de su estado de cuenta cada mes?
ningún orden específico.
• ¿Mantiene su sitio Web una página de preguntas frecuentes (FAQ) para
los empleados con preguntas sobre su nómina?
• ¿Está completo este formulario?
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 107
Sin embargo, las desventajas de usar preguntas cerradas son substanciales. Entre las más comunes tenemos:
1. Son aburridas para el entrevistado.
2. No proporcionan detalles adicionales (debido a que el entrevistador provee el marco de referencia para el
entrevistado).
3. Se pierden las ideas principales por la razón anterior.
4. No se puede generar una buena comunicación entre el entrevistador y el entrevistado.
Por lo tanto, como entrevistador usted debe considerar con cuidado los tipos de preguntas que piensa utilizar.
Tanto las preguntas abiertas como las cerradas tienen ventajas y desventajas, como se muestra en la figura
4.5. Tenga en cuenta que se deben hacer ciertas concesiones al elegir un tipo de respuesta en vez del otro; aunque
una pregunta abierta ofrece amplitud y profundidad en la respuesta, este tipo de respuestas son más difíciles de
analizar.
SONDEOS El tercer tipo de pregunta es el sondeo o seguimiento. El sondeo más sólido es el más simple: la
pregunta “¿Por qué?”. Otros sondeos son: “¿Me puede dar un ejemplo de un momento en el que el sistema no
le haya parecido confiable?” y “¿Podría explicarme eso?”. En la figura 4.6 se muestran ejemplos de preguntas
de sondeo. El propósito del sondeo es ir más allá de la respuesta inicial para obtener más detalles significativos,
aclarar la información, y ampliar el punto del entrevistado. Los sondeos pueden ser preguntas abiertas o
cerradas.
Es imprescindible realizar sondeos. La mayoría de los entrevistadores principiantes son reticentes en cuanto
a realizar sondeos y con frecuencia aceptan respuestas superficiales. Por lo general están más agradecidos por el
hecho de que los entrevistados hayan concedido las entrevistas y se sienten en parte obligados a aceptar declara-
ciones sin argumentos con amabilidad.
FIGURA 4.6
Sondeos
Los sondeos permiten al analista
• ¿Por qué? de sistemas dar seguimiento a las
• Mencione un ejemplo de cómo se ha integrado el comercio electrónico en preguntas para obtener respuestas
sus procesos de negocios. más detalladas. Los ejemplos se
• Ilustre el tipo de problemas de seguridad que experimenta con su sistema seleccionaron de distintas
de pagos de facturas en línea. entrevistas y no se muestran en
• Mencionó una solución tanto de intranet como de extranet. Por favor muestre ningún orden específico.
un ejemplo de la forma en que piensa que difiere cada una de estas soluciones.
• ¿Qué lo hace sentir así?
• Dígame paso a paso qué ocurre después de que un cliente hace clic en el
botón “Enviar” en el formulario de registro Web.
www.xlibros.com
108 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U LT O R Í A 4 . 1
USO DE UNA ESTRUCTURA DE PIRÁMIDE La organización inductiva de las preguntas de la entrevista se puede
visualizar en forma de pirámide. El entrevistador empieza con preguntas muy detalladas, a menudo cerradas. Después
expande los temas al permitir preguntas abiertas y respuestas más generalizadas, como se muestra en la figura 4.7.
Utilice una estructura de pirámide si cree que su entrevistado necesita entrar en calor en cuanto al tema.
También es conveniente usar una estructura de pirámide para las secuencias de preguntas si desea una determina-
FIGURA 4.7
La estructura de pirámide para las ras
Las estructu
entrevistas pasa de preguntas empiezan
de pirámide
unta
específicas a generales. con una preg ¿Cuál es
espe cí fic a…
el problema
específico que está
experimentando
con su firewall?
con
… y terminan
una pregunta
general.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 109
ción final sobre el tema. Tal es el caso en la pregunta final: “En general, ¿cómo se siente en cuanto a la seguridad
de los datos en comparación con la importancia del acceso a Internet?”.
USO DE UNA ESTRUCTURA DE EMBUDO En el segundo tipo de estructura, el entrevistador usa un enfoque
deductivo al empezar con preguntas generalizadas y abiertas, para después reducir la cantidad de respuestas
posibles mediante el uso de preguntas cerradas. Esta estructura de entrevista se puede representar en forma
de embudo, como se muestra en la figura 4.8. El método de la estructura de embudo ofrece una manera fácil
y amigable de empezar una entrevista. También es conveniente usar una secuencia de preguntas en forma de
embudo cuando el entrevistado está relacionado sentimentalmente con el tema y necesita libertad para expresar
esos sentimientos.
USO DE UNA ESTRUCTURA EN FORMA DE DIAMANTE A menudo es mejor utilizar una combinación de las
dos estructuras anteriores, a lo cual se le conoce como estructura de entrevista en forma de diamante. En esta
estructura la entrevista empieza de una manera muy específica y después se examinan las cuestiones generales,
para finalmente llegar a una conclusión muy particularizada, como se muestra en la figura 4.9.
El entrevistador empieza con preguntas fáciles y cerradas que permiten al entrevistado entrar en calor; a
la mitad se le pregunta lo que opina sobre temas amplios que obviamente no tienen sólo una respuesta “co-
rrecta”. Después, el entrevistador restringe incluso más las preguntas para obtener respuestas específicas, con
lo cual se produce un cierre tanto para el entrevistado como para el entrevistador. La estructura de diamante
combina las ventajas de los otros dos métodos pero tiene la desventaja de que toma más tiempo que las otras
dos estructuras.
El final de la entrevista parecería un punto lógico para hacer una pregunta clave —“¿Hay algo de lo que no
hayamos hablado que usted considere importante?”—, pero como el entrevistado la considera una pregunta de
fórmula, la mayor parte de las ocasiones la respuesta será “No”. Por ende, usted debe identificar las coyunturas
en que esta pregunta pueda soltarle la lengua al entrevistado.
Al concluir la entrevista, haga un resumen y provea retroalimentación sobre sus impresiones en general. In-
forme al entrevistado sobre los pasos a seguir, y lo que harán usted y los demás miembros del equipo a continua-
ción. Pregunte al entrevistado con quién debería usted hablar en adelante. Establezca citas para dar seguimiento a
las entrevistas, agradezca al entrevistado por su tiempo y despídase de mano.
Cómo escribir el informe de la entrevista
Aunque la entrevista esté completa, apenas empieza su trabajo sobre los datos que obtuvo. Necesita capturar la
esencia de la entrevista por medio de un informe escrito. Es imperativo que escriba el informe tan pronto como
sea posible después de la entrevista. Este paso es otra manera en la que puede asegurar la calidad de los datos
obtenidos de la entrevista: entre más tiempo espere para escribir su entrevista, más borrosa se volverá la calidad
de sus datos.
FIGURA 4.8
¿Cuáles son sus reacciones en cuanto al nuevo La estructura de embudo para las
sistema de adquisiciones basado en Web?
entrevistas empieza con preguntas
¿Qué departamen
amplias y después se restringe a
tos están involucrados en su preguntas específicas.
implementación?
ras de
Las estructu ¿Qué artículos se podrán comprar
em pi ezan
embudo en el sitio Web?
unta
con una preg
gene ra l …
¿Hay algún artículo esencial
que se haya excluido
del sitio?
con
… y terminan
una pregunta
específica.
www.xlibros.com
110 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U LT O R Í A 4 . 2
Un vistazo a la superficie
Después de este resumen inicial, elabore otro más detallado donde exprese los puntos principales de la en-
trevista y sus propias opiniones. Revise el informe con el entrevistado en una reunión de seguimiento. Este paso
ayuda a aclarar el significado que tenía el entrevistado en mente y le hace saber que usted tiene el suficiente inte-
rés como para tomarse el tiempo de comprender su punto de vista y sus percepciones.
FIGURA 4.9
ras
La estructura en forma de Las estructu
de di am an te
diamante para las entrevistas n una
empiezan co
combina las estructuras de pecífica …
pregunta es
pirámide y de embudo.
¿Cuáles son
los cinco tipos de
información que rastrea el
servicio gratuito de uso de
sitios Web que usted utiliza?
… pasan a
preguntas
¿Cuáles son las actividades promocionales que
generales …
usted ofrece en su sitio a cambio de este servicio?
con
… y terminan
una pregunta
específica.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 111
www.xlibros.com
112 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 4.HC1
Al colocar el puntero en una pregunta de HyperCase se revelará una respuesta.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 113
O P O R T U N I D A D D E C O N S U LT O R Í A 4 . 3
var a cabo una reunión de orientación de medio día, cuando menos una semana antes del taller para que los que
estén involucrados sepan lo que se espera de ellos. Dicha reunión previa le permitirá avanzar con rapidez y actuar
con confianza una vez que se convoque la verdadera reunión.
www.xlibros.com
114 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
guna otra actividad en forma concurrente ni postergar actividades, como se realiza comúnmente en las entrevistas
cara a cara.
El segundo obstáculo se produce cuando la preparación para las sesiones JAD es inadecuada en cualquier as-
pecto, o si el informe de seguimiento y la documentación de las especificaciones están incompletos. En estos ca-
sos, los diseños resultantes podrían ser insatisfactorios. Es necesaria la conjunción de muchas variables correctas
para que el JAD sea exitoso; en contraste, muchas cosas podrían salir mal. El éxito de los diseños que resultan de
las sesiones JAD es menos predecible que el que se logra mediante las entrevistas estándar.
Por último, tal vez las habilidades necesarias de la organización y su cultura no estén lo bastante desarrolla-
das como para permitir el esfuerzo concertado requerido para ser productivos en un entorno JAD. Al final tendrá
que juzgar si la organización realmente está comprometida y preparada para esta metodología.
USO DE CUESTIONARIOS
El uso de cuestionarios es una técnica de recopilación de información que permite a los analistas de sistemas
estudiar las posturas, las creencias, el comportamiento y las características de varias personas clave en la organi-
zación que se pueden ver afectadas por los sistemas actual y propuesto. Las posturas son lo que las personas en
la organización dicen desear (en un nuevo sistema, por ejemplo); las creencias son lo que las personas dan por
cierto; el comportamiento es lo que hacen los miembros de la organización, y las características son las propie-
dades de las personas u objetos.
Las respuestas obtenidas a través de cuestionarios (también conocidos como encuestas) en los que se utili-
zan preguntas cerradas se pueden cuantificar. Si encuesta personas a través del correo electrónico o Web, puede
usar software para convertir las respuestas electrónicas directamente en tablas de datos para analizarlas mediante
una aplicación de hoja de cálculo o paquetes de software estadísticos. Las respuestas a los cuestionarios en los
que se utilizan preguntas abiertas se analizan e interpretan de otras formas. Las respuestas a las preguntas sobre
posturas y creencias son sensibles a las palabras elegidas por el analista de sistemas.
Por medio del uso de cuestionarios, el analista puede buscar cuantificar lo que encontró en las entrevistas.
Además, es posible usar cuestionarios para determinar qué tan difundido o limitado está realmente un senti-
miento expresado en una de las entrevistas. Por lo contrario, se pueden utilizar cuestionarios para encuestar a una
muestra grande de usuarios de sistemas con el fin de detectar problemas o llevar a la mesa de discusión cuestio-
nes importantes antes de programar las entrevistas.
En este capítulo vamos a comparar y contrastar los cuestionarios con las entrevistas. Hay muchas similitudes
entre las dos técnicas y tal vez lo ideal sería utilizarlas en conjunto, ya sea para dar seguimiento a las respuestas
confusas de un cuestionario con una entrevista, o para diseñar el primero con base en lo que se descubrió en la
entrevista. Sin embargo, cada técnica tiene sus propias funciones específicas, por lo que no siempre es necesario
o conveniente utilizar ambas.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 115
4. Desea estar seguro de que se identifiquen y consideren los problemas con el sistema actual en las entrevistas
de seguimiento.
Una vez que haya determinado que tiene buenos motivos para usar un cuestionario y después de que haya
señalado los objetivos a cumplir por medio de éste, podrá empezar a formular las preguntas.
www.xlibros.com
116 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 4.10
Preguntas abiertas que se utilizan
para los cuestionarios.
53. ¿Cuáles so
n los proble
experimen m
ta con la sa as más frecuentes qu
lida de la co e
A. mputadora
?
B.
s abiertas
Las pregunta
en pe di r al
C. pued
que haga
encuestado
listas…
54. De los prob
lemas que
¿cuál es el enlistó en la
más difícil pregunta an
de resolver terior,
?
as
… o respuest
de ta lla da s …
A continuac
ión hay pre
… o respuest
as en blanco guntas so
lo mejor q bre usted.
ue pueda. Llene los es
cortas. 67. pacios
¿Cuánto ti
empo lleva
trabajando
años y para esta
empresa?
68. m eses
¿Cuánto ti
empo lleva
trabajando
años y en la mism
meses a industria?
69. ¿En qué o
tras indust
rias ha trab
ajado?
Los encuestados aprecian los esfuerzos de alguien que se molesta en escribir un cuestionario que refleje su
propio uso del lenguaje. Por ejemplo, si la empresa utiliza el término supervisores en vez de gerentes, o unidades
en vez de departamentos, al incorporar los términos preferidos al cuestionario los encuestados se relacionan me-
jor con el significado de las preguntas. Será más fácil interpretar las respuestas con precisión y los encuestados
serán más entusiastas en general.
Para verificar que el lenguaje utilizado en el cuestionario sea el de los encuestados, pruebe varias preguntas
de muestra en un grupo piloto (de prueba). Pídales que pongan especial atención en cuanto a la precisión de las
palabras y que cambien cualquier palabra que no suene adecuada.
He aquí algunos lineamientos que puede utilizar al elegir el lenguaje para su cuestionario:
1. Use el lenguaje de los encuestados siempre que sea posible. Mantenga un vocabulario simple.
2. Concéntrese en ser específico en vez de utilizar palabras imprecisas. Evite también las preguntas demasiado
específicas.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 117
FIGURA 4.11
Las preguntas cerradas en los
Responda a cuestionarios ayudan a asegurar
las pregunta las respuestas.
s 23 y 24 m
arcando la ca
silla apropiad
23. A continuaci a.
ón se muest
disponibles ran los seis
en este mom paquetes de
ento. Marqu softw
de software
que utiliza pe e el (los) paqu are
rsonalmente ete(s)
con más frec
[ ] Microso uencia
ft Excel
[ ] Microso [ ] Microso
ft PowerPoin ft Access
[ ] Oracle t [ ] Micro
SCM soft Window tas cerradas
[ ] Visible s Live Mail Las pregun
Analyst r al
24. pueden pedi
“Por lo gene
ral las cifras es ta do que marque
de ventas es encu
[ ] De acue tán retrasad una casi lla …
rdo as".
Responda a [ ] En desa
las pregunta cuerdo
apropiado. s 25 y 26 en
cerrando en
un círculo el
25. número
“Cuando los
servicios de
cifras de ve datos de có
ntas, se retr mputo prep
asan". aran las
Nunca
Raras veces
1 A veces
2 A menudo
3 Siempre
4
5
... o que encierre
un número …
Responda
a las
respuesta ap preguntas 45-48 ence
ropiada. rrando en un círcul
45. o la
La división
en la que m
e encuentro
en la actual
Inversiones idad se llam
a
Operaciones
Marketing
46. Mis antece
ar dentes acad
… o encerr como émicos se
uesta. pueden desc
toda la resp ribir mejor
Preparatori
a
Estudios un
iversitarios
Licenciatura parciales
Maestría o
superior
Mi género
es
Masculino
Femenino
www.xlibros.com
118 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
MEDICIÓN Hay dos formas de escalas de medición que los analistas de sistemas utilizan por lo general:
1. Escalas nominales
2. Escalas de intervalo
Las escalas nominales se utilizan para clasificar cosas. Una pregunta tal como:
¿Qué tipo de software utiliza más?
1 ⫽ Un procesador de palabras
2 ⫽ Una hoja de cálculo
3 ⫽ Una base de datos
4 ⫽ Un programa de correo electrónico
utiliza una escala nominal. En definitiva, las escalas nominales son las formas más débiles de medición. Por lo
general, todo lo que el analista puede hacer con ellas es obtener los totales de cada clasificación.
Las escalas de intervalo poseen la característica de que los intervalos entre cada uno de los números son
iguales. Debido a ello, se pueden realizar operaciones matemáticas con los datos del cuestionario para obtener un
análisis más completo. Las escalas Fahrenheit y Celsius son ejemplos de escalas de intervalo, las cuales miden
la temperatura.
El ejemplo antes mencionado del Centro de información no es en definitiva el de una escala de intervalo,
pero si anclamos la escala en uno de sus extremos, tal vez el analista quiera suponer que el encuestado percibe
que los intervalos son iguales:
¿Qué tan útil es el soporte proporcionado por el Grupo de soporte técnico?
VALIDEZ Y CONFIABILIDAD Al construir escalas podemos usar dos medidas de rendimiento: validez y
confiabilidad. El analista de sistemas debe estar consciente de estas dos cuestiones.
La validez es el grado con el que la pregunta mide lo que el analista requiere. Por ejemplo, si el propósito
del cuestionario es determinar si la organización está lista o no para un cambio importante en las operaciones de
cómputo, ¿los cuestionarios miden eso?
La confiabilidad implica consistencia. Si el cuestionario se aplicó una vez y después se volvió a aplicar bajo
las mismas condiciones, y se obtuvieron los mismos resultados en ambas ocasiones, se dice que el instrumento
tiene consistencia externa. Si el cuestionario contiene subpartes y éstas tienen resultados equivalentes, se dice
que el instrumento tiene consistencia interna. Es importante tener consistencia externa e interna.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 119
CONSTRUCCIÓN DE ESCALAS La construcción de escalas es una tarea seria. Si construye las escalas con poco
cuidado se producirá uno de los siguientes problemas:
1. Indulgencia.
2. Tendencia central.
3. Efecto halo.
La indulgencia es un problema que provocan los encuestados que califican en forma superficial. Para evitar
el problema de la indulgencia, el analista de sistemas puede desplazar la categoría “promedio” a la izquierda
(o derecha) del centro.
La tendencia central es un problema que ocurre cuando los encuestados califican todo como promedio. Para
mejorar la escala, el analista puede 1) hacer las diferencias más pequeñas en los dos extremos, 2) ajustar la soli-
dez de los descriptores o 3) crear una escala con más puntos.
El efecto halo es un problema que surge cuando la impresión que se forja en una pregunta se acarrea hasta
la siguiente. Por ejemplo, si va a calificar un empleado del que tiene una impresión favorable, tal vez le otorgue
una calificación alta en todas las categorías o rasgos, sin importar que sea o no realmente una de sus mejores ca-
racterísticas. La solución es colocar un rasgo y varios empleados en cada página, en vez de un empleado y varios
rasgos en una página.
Casilla de Se utiliza para obtener una respuesta del tipo sí-no (por
verificación ejemplo, ¿Desea que lo incluyamos en la lista de correo?)
Botón de Se utiliza para obtener una respuesta del tipo sí-no o
opción verdadero-falso
Se utiliza para obtener resultados más consistentes (el
Menú encuestado puede elegir la respuesta apropiada de una
desplegable lista predeterminada; por ejemplo, una lista de abreviaturas
de estados)
Se utiliza con frecuencia para una acción (por ejemplo,
Botón el encuestado hace clic en un botón marcado como
“Enviar” o “Borrar”)
www.xlibros.com
120 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U LT O R Í A 4 . 4
El cuestionario insoportable
Circule el núme
ro apropiado para
cada fuente de
1. Informes ind información de
ustriales scrita.
Menos Aproximadam
ente
1 igual
2 Más
3
2. Análisis de 4
tendencias 5
Menos Aproximadam
ente
1 igual Necesitam
os
2 Más te
3 cambiar es
3. Gráficos ge 4
nerados por co 5 cuestionar
io.
mputadora
Menos Aproximadam
ente
1 igual
2 Más
3
4. Servicios de 4
5
asesoría en inv
ersiones
Menos Aproximadam
ente
1 igual
2 Más
3
4
5
5. Gráficos
de puntos
y figuras
Menos Aproximad
amente
1 igual
2
3 Más
6. Análisis 4
de cartera 5
de clientes
computariz
ada
Menos Aproximad
amente
1 igual
2
3 Más
7. Informac 4
ión actualiz 5
ada
Menos Aproximad
amente
1 igual
2
3 Más
4
5
FIGURA 4.C1
Cuestionario desarrollado para la casa de bolsa Carbon, Carbon & Rippy, por Rich Kleintz.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 121
O P O R T U N I D A D D E C O N S U LT O R Í A 4 . 5
CUESTIONARIO PARA TODOS LOS GERENTES DE SPAS MEDICINALES ¿Cuál es el mayor problema que tiene al comunicar sus
*** URGENTE *** LLENE EL CUESTIONARIO DE INMEDIATO Y requerimientos de información a las oficinas generales?
SU SIGUIENTE NÓMINA HASTA QUE SE CONFIRME QUE LO ENTREGÓ. ¿Cuánto tiempo de inactividad en las computadoras
En 10 palabras o menos, ¿qué quejas ha presentado en relación con el experimentó el año pasado?
¿Hay otras personas que se sientan igual que usted en su sucursal? Descripción Número de serie
¿Quiénes? Haga una lista de sus nombres y puestos. ¿Desea que se lo lleven? De acuerdo Neutral En desacuerdo
FIGURA 4.C2
Cuestionario desarrollado para los gerentes de Global Health Spas, por Tennys Courts.
ORDEN DE LAS PREGUNTAS No existe una forma de ordenar las preguntas en el cuestionario que sea la mejor
de todas. Una vez más, al ordenar preguntas debe tener en cuenta sus objetivos al usar el cuestionario y después
determinar la función de cada pregunta para ayudarle a obtener sus objetivos. También es importante ver el
cuestionario a través de los ojos del encuestado. Algunos lineamientos para ordenar preguntas son:
1. Coloque primero las preguntas que sean importantes para los encuestados.
2. Agrupe elementos de contenido similar.
3. Introduzca primero las preguntas menos controversiales.
Es conveniente que los encuestados no se sientan amenazados y que se interesen en las preguntas lo más que se
pueda, sin que se alteren por alguna cuestión específica.
www.xlibros.com
122 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
RESUMEN
Este capítulo aborda tres de los métodos interactivos clave la entrevista, decidir a quiénes entrevistar, preparar al entrevis-
para recopilar información y que el analista de sistemas puede tado y decidir sobre los tipos y la estructura de las preguntas.
utilizar: entrevistas, JAD y cuestionarios. Durante el proceso de Las preguntas son de dos tipos básicos: abiertas o cerradas.
la entrevista, los analistas esperan escuchar cuestiones de HCI Las preguntas abiertas permiten todas las opciones de respuesta
relacionadas con la ergonomía, la estética, la capacidad de uso para el entrevistado. Las preguntas cerradas limitan las posibles
y la utilidad, así como los objetivos, sentimientos, opiniones y opciones de respuesta. Las preguntas de sondeo o de seguimiento
procedimientos informales en las entrevistas con los encarga- pueden ser cerradas o abiertas, pero le piden al entrevistado una
dos de tomar las decisiones en la organización. Las entrevistas contestación más detallada.
son diálogos planeados de preguntas y respuestas entre dos Las entrevistas se pueden estructurar en tres formas: pirá-
personas. Los analistas utilizan la entrevista para desarrollar mide, embudo o diamante. Las estructuras de pirámide empiezan
su relación con un cliente, observar el entorno de trabajo y con preguntas cerradas detalladas y se amplían con preguntas
recolectar datos. Es preferible llevar a cabo las entrevistas en más generalizadas. Las estructuras de embudo empiezan con
persona. preguntas abiertas generales y después se restringen a preguntas
Los cinco pasos a seguir para planear la entrevista son leer cerradas más específicas. Las estructuras en forma de diamante
el material sobre los antecedentes, establecer los objetivos de combinan las ventajas de las otras dos estructuras, pero se requiere
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 123
“llenarTcuestionarios
al vez ya se haya dado cuenta de que no todos disfrutan de
en MRE. Al parecer recibimos más cuestiona-
Preguntas de HYPERCASE
1. ¿Qué evidencia de cuestionarios ha encontrado en MRE? Sea
rios que la mayoría de las empresas. Creo que es porque muchos de específico sobre lo que encontró y dónde lo hizo.
los empleados, en especial los de la Unidad de capacitación ante- 2. Critique el cuestionario que Snowden hizo circular. ¿Qué se
rior, valoran las contribuciones de los datos de los cuestionarios en puede hacer para mejorar su confiabilidad, validez y tasa de
nuestro trabajo con los clientes. Cuando examine el cuestionario respuesta? Mencione tres sugerencias prácticas.
que distribuyó Snowden, tal vez no sólo quiera ver los resultados 3. Escriba un cuestionario corto para dar seguimiento a algunos
sino también criticar los métodos. Siempre he pensado que real- aspectos de la fusión entre los departamentos de Sistemas
mente podemos mejorar nuestro rendimiento interno para, en un administrativos y la Unidad de capacitación en MRE que
momento dado, atender mejor a nuestros clientes. La próxima vez todavía le intriguen. Asegúrese de observar todos los
que construyamos un cuestionario queremos ser capaces de mejorar lineamientos para el buen diseño de cuestionarios.
tres cosas: la confiabilidad de los datos, la validez de los datos y la 4. Rediseñe el cuestionario que escribió en la pregunta 3, de
tasa de respuestas que recibimos”. forma que se pueda utilizar en una encuesta Web.
más tiempo para llevarlas a cabo. Hay concesiones implicadas al Una vez que se establecen los objetivos para la encuesta, el
decidir la estructura para hacer las preguntas de las entrevistas y analista puede empezar a escribir preguntas abiertas o cerradas.
las secuencias de esas preguntas. Lo ideal sería que las preguntas fueran simples, específicas,
Para reducir tanto el tiempo como el costo de las entrevis- cortas, sin predisposiciones ni condescendencias, con precisión
tas personales, tal vez los analistas quieran considerar el diseño técnica, dirigidas a personas que tengan conocimientos apro-
de aplicaciones conjuntas (JAD) como alternativa. Mediante piados y escritas en un nivel de lectura apropiado. Tal vez el
el uso de JAD los analistas pueden analizar los requerimientos analista de sistemas quiera usar escalas, ya sea para medir las
humanos de información y diseñar una interfaz de usuario con posturas o características de los encuestados o hacer que éstos
los usuarios en un ambiente de grupo. Una evaluación cuida- actúen como jueces en relación con el tema del cuestionario.
dosa de la cultura específica de la organización ayudará al ana- Escalar es el proceso de asignar números u otros símbolos a un
lista a juzgar si es adecuado usar JAD. atributo o característica.
Mediante el uso de cuestionarios (encuestas), los analistas El control consistente del formato y estilo de los cuestiona-
de sistemas pueden recopilar datos sobre cuestiones de HCI, rios puede producir una mejor tasa de respuesta. Podemos dise-
posturas, creencias, comportamiento y características de las ñar las encuestas Web para fomentar respuestas consistentes.
personas clave en la organización. Las encuestas son útiles si Además, es importante ordenar y agrupar las preguntas de una
las personas en la organización están dispersas en una zona forma significativa para ayudar a los encuestados a entender el
amplia, si hay muchas personas involucradas con el proyecto cuestionario. Se pueden administrar las encuestas de varias for-
de sistemas, si se requiere un trabajo exploratorio antes de re- mas; por ejemplo vía electrónica a través del correo electrónico
comendar alternativas o si existe la necesidad de detectar pro- o Web, o estando el analista presente entre un grupo de usua-
blemas antes de llevar a cabo las entrevistas. rios.
www.xlibros.com
124 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
PREGUNTAS DE REPASO
1. ¿Qué tipos de información hay que buscar en las entrevistas?
2. Liste los cinco pasos necesarios en la preparación para una entrevista.
3. Defina lo que significa preguntas abiertas en una entrevista. Mencione ocho beneficios y cinco desventajas de usarlas.
4. ¿Cuándo es apropiado usar preguntas abiertas en las entrevistas?
5. Defina lo que implica el uso de preguntas cerradas en una entrevista. Mencione seis beneficios y cuatro desventajas de
usarlas.
6. ¿Cuándo es apropiado usar preguntas cerradas en las entrevistas?
7. ¿Qué es una pregunta de sondeo? ¿Cuál es el propósito de usar una pregunta de sondeo en las entrevistas?
8. Defina lo que significa estructura de pirámide. ¿Cuándo es útil emplearla en las entrevistas?
9. Defina lo que significa estructura de embudo. ¿Cuándo es útil emplearla en las entrevistas?
10. Defina lo que significa estructura en forma de diamante. ¿Cuándo es útil emplearla en las entrevistas?
11. Defina diseño de aplicación conjunta (JAD).
12. Haga una lista de las situaciones que garantizan el uso de JAD en vez de las entrevistas personales en la organización.
13. Haga una lista de los beneficios potenciales de usar el diseño de aplicación conjunta.
14. Haga una lista de tres posibles desventajas de usar JAD como alternativa para las entrevistas personales.
15. ¿Qué tipos de información busca el analista de sistemas mediante el uso de cuestionarios o encuestas?
16. Haga una lista de cuatro situaciones en las que se utilicen los cuestionarios en forma apropiada.
17. ¿Cuáles son los dos tipos básicos de preguntas que se utilizan en los cuestionarios?
18. Haga una lista de dos razones por las que un analista de sistemas usaría una pregunta cerrada en un cuestionario.
19. Haga una lista de dos razones por las que un analista de sistemas usaría una pregunta abierta en un cuestionario.
20. ¿Cuáles son los siete lineamientos para elegir el lenguaje para el cuestionario?
21. Defina lo que significa escalar.
22. ¿Cuáles son los dos tipos de información o de escalas que utilizan los analistas de sistemas con más frecuencia?
23. ¿Para qué se utilizan las escalas nominales?
24. Mencione un ejemplo de una escala de intervalo.
25. ¿Cuándo debe el analista usar escalas de intervalo?
26. Defina confiabilidad en relación con la construcción de escalas.
27. Defina validez en relación con la construcción de escalas.
28. Haga una lista de tres problemas que pueden ocurrir debido a la acción de construir escalas sin cuidado.
29. ¿Cuáles son las cuatro acciones que se pueden tomar para asegurar que el formato del cuestionario produzca una buena
tasa de respuesta?
30. ¿Qué preguntas hay que colocar primero en el cuestionario?
31. ¿Por qué hay que agrupar preguntas sobre temas similares?
32. ¿Cuál sería una ubicación apropiada para las preguntas controversiales?
33. Haga una lista de cinco métodos para administrar el cuestionario.
34. ¿Qué consideraciones son necesarias cuando los cuestionarios están basados en Web?
PROBLEMAS
1. Como parte de su proyecto de análisis para actualizar las funciones de contabilidad automatizadas para Xanadu
Corporation, una empresa fabricante de cámaras digitales, usted entrevistará a Leo Blum, el jefe de contabilidad. Escriba
de cuatro a seis objetivos de la entrevista relacionados con la forma en que Leo utiliza las fuentes de información, los
formatos de la información, la frecuencia con que toma decisiones, las calidades deseadas de información y el estilo de
toma de decisiones.
a. Escriba en un párrafo cómo se acercará a Leo para programar una entrevista.
b. Indique la estructura que elegirá para esta entrevista. ¿Por qué?
c. Leo tiene cuatro subordinados a su cargo que también utilizan el sistema. ¿Los entrevistaría también? ¿Sí o no, y
por qué?
d. ¿Trataría usted también de entrevistar clientes (visitantes del sitio Web)? ¿Hay mejores formas de obtener las
opiniones de los clientes? ¿Sí o no, y por qué?
e. Escriba tres preguntas abiertas que enviará por correo electrónico a Leo antes de su entrevista. Escriba un enunciado
en el que le explique por qué es preferible realizar una entrevista en persona, en vez de hacerlo por correo
electrónico.
2. He aquí cinco preguntas escritas por uno de los miembros de su equipo de análisis de sistemas. La persona a la que va a
entrevistar es el gerente local de LOWCO, un punto de venta de una cadena nacional de descuento, quien le ha pedido
que trabaje en un sistema de información de administración para proveer información sobre el inventario. Revise estas
preguntas para el miembro de su equipo.
1. ¿Cuándo fue la última vez que pensó seriamente en su proceso de toma de decisiones?
2. ¿Quiénes son los empleados problemáticos en su tienda? Es decir, los que mostrarán más resistencia a los cambios
en el sistema que propuse.
3. ¿Hay decisiones sobre las que necesite más información para tomarlas?
4. No tiene problemas graves con el sistema de control de inventario actual, ¿o sí?
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 125
www.xlibros.com
126 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
1 2 3 4
FIGURA 4.EX1
Cuestionario desarrollado por Di
Wooly.
Hola a tod
os los emple
¿Qué hay de ados
nuevo? Según
He aquí algu lo que escuch
nas pregunta é, estamos pe
a. ¿Cuánto tie s que me gu nsando com
mpo ha utili staría que co prar una nuev
b. ¿Con qué zado la com nsiderara ca a computado
frecuencia se putadora an da uno de us ra.
c. ¿Quién la in hibe? te ri or ? tedes.
repara por us
d. ¿Cuándo ted?
fue la última
empezado a vez que sugi
usar? ¿Qué rió una mejor
e. ¿Cuándo sugirió? a al sistema
fue la última de cómputo
haya utilizado vez que sugi que se haya
? ¿Q ri ó un a m ej or
f. ¿Usa una ué su girió? a al sistema de có
VDT, una im mputo que nu
g. ¿Qué tan presora o am nca se
rápido pued bas?
h. ¿Cuántas e teclear?
personas ne
¿Hay alguien cesitan acce
que no esté so a la base
utilizando la de datos con
computadora regularidad
ahora y que en su sucurs
quisiera hace al?
rlo?
a. Elabore una crítica en un enunciado para cada una de las preguntas anteriores.
b. Critique en un párrafo la distribución y el estilo en términos del espacio en blanco utilizado, el espacio para las
respuestas, la facilidad de responder, etcétera.
13. Con base en las conjeturas que usted obtuvo, la Srta. Wooly intenta comprender el cuestionario, reformular y ordenar las
preguntas (use preguntas abiertas y cerradas) de manera que sigan las buenas prácticas y produzcan información útil para
los analistas de sistemas. Indique en seguida de cada pregunta que escriba si es abierta o cerrada; además escriba un
enunciado en el que indique por qué escribió la pregunta de esa manera.
14. Rediseñe el cuestionario que creó para la Srta. Wooly en el problema 13 para usarlo en correo electrónico. Escriba un
párrafo en el que diga qué cambios se necesitaron para ajustarse a los usuarios de correo electrónico.
15. Rediseñe el cuestionario que creó para la Srta. Wooly en el problema 13 como una encuesta Web. Escriba un párrafo en
el que diga qué cambios se necesitaron para ajustarse a los usuarios Web.
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 127
PROYECTOS EN GRUPO
1. Con los miembros de su grupo haga una pequeña representación de una serie de entrevistas con varios usuarios de
sistemas en Maverick Transport. Cada miembro de su grupo deberá elegir uno de los siguientes roles: presidente de la
empresa, director de tecnología de la información, despachador, agente de servicio al cliente o conductor de camión. Los
miembros del grupo que desempeñen roles de empleados de Maverick Transport deben tratar de describir con brevedad
sus responsabilidades, objetivos y necesidades de información en su trabajo.
El resto de los miembros del grupo deben desempeñar los roles de analistas de sistemas e idear preguntas de
entrevistas para cada empleado. Si hay suficientes personas en su grupo, a cada analista se le puede asignar la entrevista
de un empleado distinto. Los que desempeñen los roles de analistas de sistemas deben trabajar juntos para desarrollar
preguntas comunes, así como preguntas dirigidas a cada empleado individual. Asegúrese de incluir preguntas abiertas,
cerradas y de sondeo en sus entrevistas.
Maverick Transport trata de cambiar su tecnología obsoleta y poco confiable por una tecnología más reciente y
confiable. La empresa busca migrar de las terminales tontas conectadas a un equipo mainframe, ya que desea usar PC
de alguna forma y también le interesa investigar un sistema de satélite para rastrear los fletes y los conductores. Además
la empresa está interesada en buscar formas de reducir los inmensos requerimientos de almacenamiento y mejorar el
acceso a los problemáticos formularios de varias hojas escritos a mano que se incluyen en cada envío.
2. Lleve a cabo las cinco entrevistas en un ejercicio de juegos de rol. Si hay más de 10 personas en su grupo, permita que
dos o más analistas hagan las preguntas.
3. Escriba con su grupo un plan para una sesión JAD que sustituya a las entrevistas personales. Incluya los participantes
relevantes, el ambiente sugerido, etcétera.
4. Use los datos de las entrevistas que obtuvo del ejercicio en grupo del proyecto 1 sobre Maverick Transport para reunirse
con su grupo y transformar el diseño de un cuestionario para los cientos de conductores de camiones que trabajan para
Maverick Transport. Recuerde que a Maverick le interesa implementar un sistema de satélite para rastrear los fletes y los
conductores. Hay otros sistemas que podrían afectar a los conductores también. A medida que su grupo construya el
cuestionario, considere el nivel de educación que pueda tener el conductor y cualquier restricción de tiempo que le
impida completar dicho formulario.
5. Use los datos de las entrevistas que obtuvo del ejercicio en grupo del proyecto 1 sobre Maverick Transport para reunirse
con su grupo y diseñar un cuestionario Web o de correo electrónico para encuestar a los 20 programadores de la empresa
(15 de los cuales se contrataron el año pasado) sobre sus habilidades, ideas para sistemas nuevos o mejorados, etcétera.
Investigue las opciones de encuestas Web disponibles en SurveyMonkey.com. A medida que su grupo construya la
encuesta para los programadores, considere lo que aprendió sobre los usuarios en las otras entrevistas, así como la visión
que tiene el director de tecnología de la información con respecto a la empresa.
BIBLIOGRAFÍA SELECCIONADA
Ackroyd, S. y J. A. Hughes. Data Collection Context, 2da. edición. Nueva York: Addison-Wesley, 1992.
Cash, C. J. y W. B. Stewart, Jr. Interviewing Principles and Practices, 12va. edición. Nueva York: McGrawHill/Irwin, 2007.
Cooper, D. R. y P. S. Schindler. Business Research Methods, 10a. edición. Nueva York: McGrawHill/Irwin, 2007.
Deetz, S. Transforming Communication, Transforming Business: Building Responsive and Responsible Workplaces. Cresskill,
NJ: Hampton Press, 1995.
Emerick, D., K. Round y S. Joyce. Exploring Web Marketing and Project Management. Upper Saddle River, NJ: Prentice Hall
PTR, 2000.
Gane, C. Rapid System Development, Nueva York: Rapid System Development, 1987.
Georgia Tech’s Graphic, Visualization, and Usability Center. “GVU WWW Survey through 1998”. Disponible en: http://www.
cc.gatech.edu/gvu/user_surveys/survey-1998-10/. Último acceso: 15 de julio de 2009.
Hessler, R. M. Social Research Methods. Nueva York: West, 1992.
Joint Application Design. GUIDE Publication GPP-147. Chicago: GUIDE International, 1986.
Peterson, R. A. Constructing Effective Questionnaires. Thousand Oaks, CA: Sage Publications, 1999.
Strauss, J. y R. Frost. E-Marketing, 5ta. edición. Upper Saddle River, NJ: Pearson Prentice Hall, 2008.
Wansink, B., S. Sudman y N. M. Radburn. Asking Questions: The Definitive Guide to Questionnaire Design—For Market Re-
search, Political Polls, and Social and Health Questionnaires. Nueva York: Wiley, 2004.
www.xlibros.com
128 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EPISODIO 4
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
www.xlibros.com
CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 129
“La única otra cosa que me preocupa son los problemas que se producen cuando un miembro del cuerpo docente o del
personal no utiliza el software”, responde Hy.
“¿Qué quiere decir?”, pregunta Chip.
“Bueno, supongan que una persona tiene el software pero lo instaló en forma incorrecta o aparece algún tipo de mensaje
de seguridad o relacionado con los derechos de acceso”, responde Hy. “He recibido algunas consultas sobre esta cuestión re-
cientemente. Una persona dijo que estaban trabajando con Windows Vista y tenían su información en una unidad USB, y no les
concedía derechos de acceso. Rhoda Booke es miembro del cuerpo docente en matemáticas y ha demostrado de manera con-
sistente un interés en las cuestiones de hardware y software. Le he ayudado varias veces; siempre es amigable y agradecida.
Creo que deberían entrevistarla”.
“Gracias una vez más por toda su ayuda”, dice Chip. “Más adelante nos contactaremos con usted sobre los resultados de
la encuesta”.
Anna programa una reunión con Rhoda para explicarle la naturaleza del proyecto y por qué fue seleccionada como
representante del cuerpo docente. La reunión se sostuvo en una pequeña sala de conferencias en el departamento de ma-
temáticas.
“Nos gustaría conocer la perspectiva del cuerpo docente sobre los problemas relacionados con las computadoras y el soft-
ware asociado”, dice Anna. “Nuestro objetivo es ofrecer al cuerpo docente los mejores recursos posibles con el menor número
de problemas”.
“Estoy realmente encantada de formar parte del proyecto”, exclama Rhoda. “He utilizado software en el salón de clases
durante 10 años aproximadamente, ¡y ha sido toda una experiencia de aprendizaje! Gracias a Dios que Hy está disponible como
recurso. Le he robado horas de su tiempo, pero ha valido bien la pena. Me siento mucho más productiva y los estudiantes utili-
zan software que les ayuda a comprender el material con más detalle”.
“Eso es bueno. Ahora, ¿ha estado experimentando algunas dificultades?”, pregunta Chip.
“Bueno, es todo un reto familiarizarse con el software. Invertí una buena parte del verano pasado, cuando no estaba traba-
jando en mi libro, en aprender cómo usar parte del software del salón de clases para álgebra y cálculo. Es grandioso pero quedé
atrapada varias veces y tuve que pedir ayuda. Es necesario entender el software para preparar los planes de las lecciones y ex-
plicar a los estudiantes cómo usarlo”.
“¿Qué hay sobre problemas al instalar el software o hardware?”, pregunta Anna.
“¡Oh si!”, exclama Rhoda. “Traté de instalar el software y todo salió bien hasta llegar a la parte en donde tenía que recibir
actualizaciones de su sitio Web y hubo algunos problemas con el registro”, se ríe Rhoda.
“Después hubo problemas de instalación”, continúa Rhoda. “Necesitaba averiguar qué instalar en la red y qué incluir en
el disco duro local. En algunas laptops obtuvimos mensajes de error del tipo “Memoria insuficiente” y descubrimos que nunca
se habían actualizado. El cuerpo docente del departamento de física tuvo el mismo problema”.
“¿Hay alguna otra cuestión que usted considere importante para incluirla en nuestra encuesta para el personal docente y
de investigación?”, pregunta Chip.
“Sería conveniente saber quién utiliza el mismo software en distintos departamentos y qué software suministra cada dis-
tribuidor. Tal vez si compramos muchos paquetes de un distribuidor podríamos obtener un mayor descuento por el software. El
presupuesto de software del departamento ya está sobrecargado”, dice Rhoda.
“Gracias por toda su ayuda”, dice Anna. “Si llega a pensar en alguna pregunta adicional que debamos incluir en la encuesta,
no dude en llamarnos”.
De vuelta en su oficina, los analistas empiezan a compilar una lista de las cuestiones que debe contener la encuesta.
“En definitiva necesitamos preguntar sobre el software en uso y las necesidades de capacitación”, comenta Anna. “También
deberíamos tratar con los problemas que están ocurriendo”.
“De acuerdo”, responde Chip. “Creo que deberíamos incluir preguntas sobre los paquetes de software, distribuidores,
versiones, nivel de experiencia y cuestiones relacionadas con la capacitación. De lo que no estoy muy seguro es de cómo obte-
ner información sobre los problemas a los que se enfrenta el personal docente y de investigación. ¿Cómo deberíamos abordar
esas cuestiones?”
“Bueno”, responde Anna, “deberíamos enfocarnos en las cuestiones con las que estén familiarizados. Podríamos
hacer preguntas sobre el tipo de problemas que están ocurriendo, pero que en definitiva no sean técnicos. Y la encuesta
no debería hacer preguntas cuyas respuestas pudiéramos encontrar con facilidad, como “¿Quién es el distribuidor del
software?”
“Entiendo”, responde Chip. “Dividamos las preguntas en categorías. Algunas serán preguntas cerradas y otras abiertas.
Después hay que ver qué estructura debemos usar”.
“Usaremos Zoomerang para administrar la encuesta en Web”, continúa Anna. “También usaremos recordatorios vía correo
electrónico sobre la fecha de terminación de la encuesta”.
www.xlibros.com
130 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EJERCICIOS
En los primeros tres ejercicios tendrá que visitar el sitio Web para obtener el texto de las entrevistas con los miembros del per-
sonal de la CPU. Visite el sitio Web en www.pearsonhighered.com/kendall y busque las entrevistas de la CPU (“CPU Inter-
views”).
E-1. Analice las cinco entrevistas. En un párrafo describa el tipo de estructura que tenía cada entrevista.
E-2. Elabore una lista de todas las entrevistas, de 1 a 5, y después escriba un párrafo para cada una de ellas en el que describa
las formas en que Anna podría mejorar sus entrevistas para la próxima vez.
E-3. Analice las preguntas utilizadas en las cinco entrevistas. Describa en un párrafo los tipos de preguntas utilizadas y si
fueron o no apropiadas para obtener la información necesaria.
E-4. De la lista de asuntos presentada anteriormente en el capítulo, seleccione las cuestiones que quedarían mejor como pre-
guntas cerradas.
E-5. De la lista de asuntos, seleccione las cuestiones que quedarían mejor como preguntas abiertas.
E-6. En base a los ejercicios E-4 y E-5, diseñe un cuestionario que se envíe al cuerpo docente y al personal de investigación.
E-7. Haga una prueba piloto de su cuestionario; deje que otros estudiantes de la clase lo llenen. En base a la retroalimentación
de los estudiantes y a la capacidad que usted tenga de analizar los datos que reciba, revise su cuestionario.
www.xlibros.com
CAPÍTULO 5
Recopilación de información:
métodos discretos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Reconocer el valor de los métodos discretos para recopilar información.
2. Comprender el concepto del muestreo para el análisis de los requerimientos humanos
de información.
3. Construir muestreos útiles de personas, documentos y eventos para determinar los
requerimientos humanos de información.
4. Crear un guión (playscript) para que el analista pueda observar las actividades de toma
de decisiones.
5. Aplicar la técnica STROBE para observar e interpretar el entorno del encargado de las
decisiones y su interacción con las tecnologías.
MUESTREO
El muestreo es el proceso de seleccionar sistemáticamente elementos representativos de una
población. Cuando se examinan con detalle estos elementos seleccionados, se asume que el
análisis revela información útil sobre la población en general.
El analista de sistemas debe decidir con respecto a dos cuestiones clave. En primer lugar
hay muchos informes, formularios, documentos de resultados, memos y sitios Web que las
personas en la organización han generado. ¿A cuáles de ellos debe el analista poner atención y
cuáles debe ignorar?
En segundo lugar, muchos empleados se pueden ver afectados por el sistema de informa-
ción propuesto. ¿A quiénes debería entrevistar el analista de sistemas?, ¿de quienes debería
buscar información por medio de cuestionarios?, ¿a quienes debería observar en el proceso de
llevar a cabo sus roles de toma de decisiones?
131
www.xlibros.com
132 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
DETERMINAR LOS DATOS A RECOLECTAR O DESCRIBIR El analista de sistemas necesita elaborar un plan realista
en cuanto a lo que debe hacer con los datos después de recolectarlos. Si se recopilan datos irrelevantes se
desperdicia tiempo y dinero en la recolección, el almacenamiento y el análisis de datos inútiles.
Los deberes y responsabilidades del analista de sistemas en esta etapa consisten en identificar las variables,
atributos y elementos de datos asociados a recopilar en la muestra. Hay que considerar los objetivos del estudio,
así como el tipo de método de recopilación de datos (investigación, entrevistas, cuestionarios, observación) a uti-
lizar. Éste y los siguientes capítulos describen con más detalle los tipos de información que debe buscar al usar
cada uno de estos métodos.
ELEGIR EL TIPO DE MUESTRA. Como se indica en la figura 5.1, el analista de sistemas puede usar uno de cuatro
tipos principales de muestras: de conveniencia, intencionada, simple y compleja. Las de conveniencia son
muestras sin restricciones ni probabilidades. Una muestra de este tipo resultaría de que el analista de sistemas
publicara un aviso en la intranet de la empresa para pedir que los interesados en trabajar con los nuevos informes
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 133
FIGURA 5.1
No se basa en la probabilidad Se basa en la probabilidad
Cuatro tipos principales de
Los elementos de la muestras disponibles para el
muestra se seleccionan De conveniencia Simple aleatoria analista.
directamente sin
restricciones
Los elementos de la
Compleja aleatoria
muestra se seleccionan
Intencionada (sistemática, estratificada
de acuerdo a ciertos
y de conglomerados)
criterios
El analista de
usar
sistemas debe
mpleja
una muestra co
at or ia si fu era
ale
posible.
de rendimiento de ventas fueran a una reunión a la 1 P.M. el martes 12. Sin duda es la más fácil de preparar, pero
es también la menos confiable. Una muestra intencionada se basa en el juicio.
El analista de sistemas puede elegir un grupo de individuos que parezcan expertos y estén interesados
en el nuevo sistema de información. Aquí, el muestreo se basa en los criterios de conocimiento e interés
sobre el nuevo sistema, pero de todas formas es un muestreo sin probabilidad. Por ende, el muestreo in-
tencionado es confiable sólo en un nivel moderado. Si elige realizar un muestreo aleatorio simple, necesita
obtener una lista numerada de la población para asegurar que cada documento o persona en la población
tenga la misma probabilidad de ser seleccionada. A menudo este paso no es práctico, en especial cuando el
muestreo involucra documentos e informes. Las muestras aleatorias complejas más apropiadas para el ana-
lista de sistemas se obtienen mediante 1) muestreo sistemático, 2) muestreo estratificado y 3) muestreo de
conglomerados.
Por ejemplo, en el método más simple de muestreo de probabilidad –el sistemático–, el analista de sistemas
debe elegir entrevistar a cada k-ésima persona en una lista de empleados de la empresa. Este método tiene
ciertas desventajas: no es conveniente utilizarlo para seleccionar cada k-ésimo día para una muestra, debido al
potencial problema de periodicidad; tampoco sería apropiado aplicarlo a una lista ordenada (por ejemplo, una
lista de bancos, desde el más pequeño hasta el más grande), ya que habría una predisposición.
El muestreo estratificado tal vez sea el más importante para el analista de sistemas. La estratificación
es el proceso de identificar subpoblaciones o estratos, para después seleccionar objetos o personas con los
que se realicen muestras de estas subpoblaciones. A menudo, la estratificación es esencial si el analista de
sistemas desea recopilar datos con eficiencia. Por ejemplo, si desea buscar opiniones de un amplio rango
de empleados en distintos niveles de la organización, el muestreo sistemático seleccionaría un número despro-
porcionado de empleados del nivel de control operacional. Una muestra estratificada compensaría esta situa-
ción. También se utiliza la estratificación cuando el analista de sistemas desea usar distintos métodos para
recolectar datos de distintos subgrupos. Por ejemplo, tal vez quiera utilizar una encuesta para recopilar datos
de los gerentes de nivel medio, pero podría preferir usar entrevistas personales para recopilar datos similares de
los ejecutivos.
Algunas veces el analista de sistemas debe seleccionar un grupo de personas o documentos para estudiarlos.
A este proceso se le conoce como muestreo de conglomerados. Suponga que una organización tiene 20 centros
de soporte esparcidos en todo el país. Tal vez usted quiera seleccionar uno o dos de estos centros de soporte bajo
la suposición de que son comunes con el resto.
DECIDIR SOBRE EL TAMAÑO DE LA MUESTRA En definitiva, si todos en la población vieran el mundo de la
misma forma, o si cada uno de los documentos de una población tuviera exactamente la misma información
que cualquier otro, sería suficiente una muestra con tamaño de uno. Como no es así, es necesario establecer un
tamaño de muestra mayor, pero menor que el de la población.
Es importante recordar que, en el muestreo, el número absoluto es más importante que el porcentaje
de la población: es posible obtener resultados satisfactorios muestreando 20 personas tanto de 200 como de
2,000,000.
www.xlibros.com
134 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
i
p =
z
7. Determinar el tamaño de muestra necesario, n, mediante la siguiente fórmula:
p11 - p 2
n = 2
+ 1
p
Desde luego, el primer paso es determinar el atributo a muestrear; después puede averiguar dónde se almacenan
estos datos: una base de datos, un formulario, un informe, etcétera.
Es importante estimar p, la proporción de la población que tiene el atributo, para establecer el tamaño de
muestra apropiado. Muchos libros de texto sobre análisis de sistemas sugieren utilizar un heurístico de 0.25 para
p(1 - p). Este valor casi siempre produce muestra de tamaño mayor que el necesario, ya que 0.25 es el valor
máximo de p(1 - p), que ocurre sólo cuando p = 0.50. Cuando p = 0.10, como es más comúnmente el caso,
p(1 - p) se convierte en 0.09, con lo cual se obtiene un tamaño de muestra mucho menor.
Los pasos 4 y 5 implican decisiones subjetivas. La estimación de intervalo aceptable de ±10 significa que
está dispuesto a aceptar un error de no más de 0.10 en cualquier dirección de la proporción actual, p. El nivel de
confianza es el grado deseado de certidumbre; por ejemplo, del 95 por ciento. Una vez elegido el nivel de con-
fianza, puede buscar el coeficiente de confianza (también conocido como valor z) en una tabla como la que se
encuentra en este capítulo.
Los pasos 6 y 7 completan el proceso al recibir los parámetros de los pasos 3 al 5 e introducirlos en dos
ecuaciones para resolver el tamaño de muestra requerido.
Ejemplo
Vamos a ilustrar con un ejemplo los pasos mencionados. Suponga que la empresa A. Sembly, que se
dedica a la fabricación de productos de estantería, le pide determinar el porcentaje de pedidos que
contienen errores. Usted acepta hacer este trabajo y lleva a cabo los siguientes pasos:
1. Determina que va a buscar pedidos con errores en nombres, direcciones, cantidades o números de
modelos.
2. Localiza las copias de los formularios de pedido de los últimos seis meses.
3. Examina algunos de los formularios de pedido y concluye que sólo cerca del 5 por ciento (0.05)
contiene errores.
4. Juzga que la estimación de intervalo aceptable será de ±0.02.
5. Selecciona un nivel de confianza de 95 por ciento. Busque el coeficiente de confianza (valor z) en la
figura 5.2. El valor z es igual a 1.96.
6. Calcula p de la siguiente manera:
i 0.02
p = = = 0.0102
z 1.96
7. Determina el tamaño de muestra necesario n de la siguiente manera:
p11 - p 2 0.0510.95 2
n = + 1 = + 1 = 458
2
p 10.0102 2 10.0102 2
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 135
O P O R T U N I D A D D E C O N S U LT O R Í A 5 . 1
Entonces, la conclusión es establecer el tamaño de la muestra en 458. En definitiva, un nivel mayor de confianza o
una estimación de intervalo aceptable menor requerirían una muestra mayor. Si mantenemos igual la estimación
del intervalo aceptable pero aumentamos el nivel de confianza al 99 por ciento (con un valor z de 2.58), el
tamaño de muestra necesario se convierte en 1.827, una cifra mucho mayor que los 458 pedidos que habíamos
decidido muestrear en un principio.
FIGURA 5.2
Nivel de Coeficiente
que Podemos utilizar una tabla del
Primero hay confianza de confianza
e el (valor z) área bajo una curva normal para
decidir sobr
ianza…
nivel de conf buscar un valor, una vez que el
99% 2.58 analista de sistemas decida sobre
98 2.33 el nivel de confianza.
97 2.17
96 2.05
95 1.96
90 1.65
80 1.28
50 0.67
s hay
… despué
ar el
que busc
valor z.
www.xlibros.com
136 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
DETERMINACIÓN DEL TAMAÑO DE LAS MUESTRAS PARA ENTREVISTAS No hay fórmulas mágicas para ayudar al
analista de sistemas a establecer el tamaño de la muestra para entrevistas; la variable primordial en este caso es
el tiempo que tarda una entrevista. Una entrevista profunda y una de seguimiento consumen mucho tiempo, tanto
del entrevistador como del participante.
Una buena regla general es entrevistar a por lo menos tres personas en todos los niveles de la organización, y
a por lo menos una de cada una de las áreas funcionales (como vimos en el capítulo 2) que trabajen directamente
con un sistema nuevo o actualizado. Recuerde también que no es necesario entrevistar a más personas sólo por-
que se trate de una empresa más grande. Si el muestreo estratificado se lleva a cabo en forma apropiada, pocos
individuos representarán de manera adecuada a toda la organización.
INVESTIGACIÓN
Investigar es descubrir y analizar información. Al investigar la evidencia en una organización, el analista actúa
como Sherlock Holmes, el famoso detective.
A medida que el analista de sistemas trabaja para entender a los usuarios, su organización y sus requerimien-
tos de información, debe examinar los distintos tipos de datos “duros” que ofrecen información no disponible por
cualquier otro medio de recopilación. Estos datos revelan dónde ha estado la organización y hacia dónde creen
sus miembros que se dirige. Para formarse una imagen precisa, el analista necesita examinar datos tanto cuanti-
tativos como cualitativos.
INFORMES PARA LA TOMA DE DECISIONES El analista de sistemas requiere acceso a algunos de los documentos
utilizados para dirigir la empresa. A menudo consisten en informes sobre el estado del inventario, las ventas o la
producción. Muchos de ellos son simples y su función es dar apoyo a una acción rápida. Por ejemplo, un informe
de ventas puede sintetizar la cantidad que se vendió y el tipo de ventas. Además, los informes de ventas podrían
incluir resultados gráficos para comparar los ingresos y las entradas durante ciertos periodos. Dichos informes
permiten que el encargado de tomar las decisiones reconozca fácilmente las tendencias.
Los informes de producción incluyen los costos recientes, el inventario actual, la mano de obra reciente y la
información de la planta. Además de estos informes clave, los encargados de tomar las decisiones utilizan mu-
chos informes sintetizados para proveer información de apoyo, detectar las excepciones a las ocurrencias norma-
les y obtener vistas generales estratégicas de los planes de la organización.
INFORMES DE RENDIMIENTO La mayoría de los informes de rendimiento consisten en una comparación entre el
rendimiento actual y el esperado. Una función importante de ellos es medir la brecha entre el rendimiento actual
y el esperado. También es importante poder determinar si ese hueco se está ensanchando o estrechando como
una tendencia general en cualquier rendimiento en evaluación. En la figura 5.3 se muestra una clara mejoría en el
rendimiento de las ventas durante un periodo de dos a tres meses. Es probable que el analista quiera observar si
hay una medición del rendimiento disponible y adecuada para las áreas clave de la organización.
REGISTROS Los registros proveen actualizaciones periódicas de lo que ocurre en la empresa. Si el encargado del
registro es cuidadoso y lo actualiza en forma oportuna, puede proveer mucha información útil para el analista.
En la figura 5.4 se muestra un registro de pagos que se llenó a mano para la renta de un apartamento. Hay varias
formas en que el analista puede inspeccionar un registro, muchas de las cuales son indicativas de su capacidad
de uso:
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 137
O P O R T U N I D A D D E C O N S U LT O R Í A 5 . 2
FIGURA 5.3
Un informe de rendimiento que
muestra mejorías.
Número de
Semana Número de
lotes Porcentaje Monto qu
producidos lotes e se
rechazados rechazado aleja del
2/2 objetivo del
245 5%
2/9 19
229 7.8
2/16 19 2.8
219 8.3
2/23 14 3.3
252 6.3
3/2 13 1.3
245 5.2
3/9 13 0. 2
260 5.3
3/16 13 0.3
275 5.0
3/23 14 ***
260 5.1
3/30 13 0.1
260 5.0
4/6 13 ***
244 5.0
4/13 12 *** de
242 4.9 Los informes
4/20 11 ***
249 4.5 rendimiento
4/27 11 *** s
249 4.4 muestran lo
11 *** obje ti vo s …
* * * indica 4. 4
que se cum ***
plió o excedi
ó el objetivo
de < 5%
encias
… y las tend
www.xlibros.com
138 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 5.4
Un registro de pago que se llenó a
mano. Verifiq
ue los e
rrores Busqu
. e
oportu
n
mejora idades de
r el dis
eño.
NOMBRE PR
OY. OAK. FC
# 562
POTENCIAL RE
NTA FIRMA CLAVE
Renta Refri- 1175/0
81299 POTENCIAL
base gerad Mue-
or bles A/C Ser- HM DE PÓSITO
vicios SR T.V. Muca- Total Se
855 ma renta gu- Lim PRORRATEO 15.00
55 ridad pieza- 31175/0
81299 31700 121.32
910 Imp. Días Tarifa
REGISTRO H/S dep. H/S diaria Totales
DE PAGO: Tot. 200 115 re nt
4 30.33 5. 20
31175/0 + 81 910
299 + Renta = 91 1.30
Sólo memo Fecha Fecha 0 Depósitos 31 63 39
venc. pago Re cibo Pa
Núm. mego al Total Se TOTAL DE PA . 340
TV 10/3 MO ! diodía renta gu- Lim GO IN IC IAL REQUER
8/28 8
/28 106642 9 ridad pieza- 31700 31 81
IDO: 1430.52
/30 1031.32 20 Imp. 175/0 299 Otros
10/1 10
/3 107503 10 2 115 44.20 Fechas Monto
Descr. Mo Monto Sa
/ 25 nt. pagado resldo
C1H/S9-16
11/1 11
/1 10935 11 31 910 414.82 15 tante
11/17 11 / 16 485.28 14 30.52 0
Cobrar 1 MES /8 11200 11
11/24 /23 212.31 910 0
Prorrateado 485.28
Hay que crear H/ 0
S 212.31
0
para reembolsa
r
depósito.
Fecha origina
l en que se mudó
8- 28
EDIFICIO # d igual
Exp.
NOMBRE Kendall x# 1
mero y 1 ero
Observe el nú
de transa cciones Trate de detectar
tipo la
los lugares donde
a
computadora pued
ica r el tra ba jo.
simplif
uno de los miembros de su equipo recopilen y clasifiquen una copia en blanco de cada formulario (oficial y no
oficial) en uso (algunas veces las empresas ya cuentan con alguien encargado de administrar los formularios; esta
persona será su primera fuente para saber qué formularios se utilizan).
Podemos comparar los formularios en blanco, junto con sus instrucciones de llenado y distribución, con los
formularios llenos, para detectar alguna consistencia en cuanto a los elementos de datos que se hayan dejado en
blanco, verificar si las personas que se supone deben recibir los formularios en realidad los están recibiendo y
determinar si siguen los procedimientos estándar para usar, almacenar y desechar los formularios. Recuerde im-
primir cualquier formulario basado en Web que los usuarios tengan que imprimir. Como alternativa puede iden-
tificar y almacenar las versiones electrónicas de los formularios que se puedan enviar a través de Web o correo
electrónico, para almacenarlas en una base de datos e inspeccionarlas después.
Una vez que haya creado un catálogo de formularios que lo ayuden a entender el flujo de información que se
utiliza en la empresa en ese momento, lo que debe hacer a continuación es:
1. Recolectar ejemplos de todos los formularios en uso, sin importar que estén aprobados o no por la empresa
(formularios oficiales vs. formularios clandestinos).
2. Observar el tipo de formulario (impreso dentro de la empresa, escrito a mano, generado por computadora
dentro de la empresa, formularios en línea, formularios para llenar en Web, formularios que se imprimen y
compran de manera externa, etcétera).
3. Documentar el patrón de distribución deseado.
4. Comparar el patrón de distribución deseado con quienes realmente recibieron el formulario.
Aunque este procedimiento lleva tiempo, es útil. Otra metodología es muestrear los formularios de captura
de datos que ya estén llenos. Recuerde verificar las bases de datos que almacenan los datos de los consumidores
al muestrear la entrada de las transacciones de comercio electrónico. El analista debe tener en cuenta muchas
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 139
FIGURA 5.5
Preguntas por hacer sobre los
formularios oficiales y
Reabastecim clandestinos que ya estén llenos.
iento de prod
lácteos con uctos
poca existenc
ia
Fecha
Nombre de la
tienda
Nombre de la
Producto tienda
Unidades
Producto
Leche (1/2 ga Unidades
lones)
Entera Leche (litros) io oficial
2% Un formular
Entera ab rum ar a las
1% puede
2% pedir
Descremada 1% personas al
Suero de lech dem as iada
e Descremada
Chocolate Suero de lech información.
e
Yogurt Chocolate
Natural
Vainilla Piña
Durazno Manzana hola
Arándano ndesa
Plátano
Mora Fruta mixta ulario
Fresa Frambuesa Tal vez el form
teng a un orden
Limón no
Helado lógico.
Cuartos de lit
ro de lujo
1/2 galones de Litros de lujo
lu
Miniaturas desc jo Cuartos Prem
remadas ium
Litros Premiu
Solicitado por m
(número de em
Razón de la ba pleado)
ja existencia Total de cajas or
denadas
Número de co
nductor
Número de ru
ta
Tienda
Fecha
Producto ag
otado Conductor ¿Se requiere
Cajas necesa realmente el
rias total?
Iniciales del
gerente de lácteos
arios
Surgen formul
nd estinos ” para
“cla
simplifica r el
problema.
preguntas específicas, como se muestra en la figura 5.5. Éstas incluyen los siguientes aspectos de HCI en rela-
ción con la capacidad de uso, la estética y la utilidad:
1. ¿Se llenó el formulario en su totalidad? Si no fue así, ¿qué elementos se omitieron?, ¿hubo consistencia en
los elementos omitidos? ¿Por qué?
2. ¿Hay formularios que nunca se usaron? ¿Por qué? (Revise el diseño y la precisión de cada formulario en
cuanto a su supuesta función).
3. ¿Se enviaron todas las copias de los formularios a las personas apropiadas o se archivaron en forma
apropiada? De no ser así, ¿por qué no? Las personas que deben acceder a los formularios en línea, ¿pueden
hacerlo?
4. Si hay un formulario en papel que se ofrece como alternativa a un formulario basado en Web, compare las
tasas de compleción de ambos.
5. ¿Se utilizan formularios “no oficiales” con regularidad? (Su uso podría indicar un problema en los
procedimientos estándar o batallas políticas en la organización).
www.xlibros.com
140 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 5.6
El análisis de los memos ayuda a
conocer las metáforas que guían el
pensamiento de la organización.
MEMO
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 141
de los sistemas de correo electrónico a grupos de trabajo e individuos. Los memos revelan un diálogo activo y
continuo en la organización. El análisis del contenido de los memos le proveerá una clara idea de los valores,
posturas y creencias de los miembros de la organización.
ANUNCIOS O PANCARTAS EN TABLEROS DE ANUNCIOS O EN ÁREAS DE TABAJO Aunque los anuncios pueden
parecer secundarios en comparación con lo que pasa en la organización, sirven como refuerzos sutiles de valores
para quienes los leen. Los lemas como “Calidad por siempre” o “La seguridad es primero” dan al analista una
idea de la cultura oficial de la organización.
SITIOS WEB CORPORATIVOS El analista también debe examinar los sitios Web que se utilizan para el comercio
de negocio a consumidor (B2C), así como los que se utilizan para las transacciones de negocio a negocio
(B2B). Examine el contenido de las metáforas, el humor, el uso de las características de diseño (color, gráficos,
animación e hipervínculos), además del significado y la claridad de los mensajes que se proporcionen. Piense en
el sitio Web desde tres perspectivas distintas: técnica, estética y gerencial. ¿Hay discrepancias entre los objetivos
establecidos de la organización y lo que se presenta al espectador? ¿Qué grado de personalización hay disponible en el
sitio Web para cada usuario? ¿Qué tanto se puede personalizar el sitio Web? Si no va a diseñar sitios de comercio
electrónico para la organización, ¿en qué afecta lo que usted ve en su sitio o sitios Web a los sistemas que está
investigando? Recuerde tomar notas del nivel de interactividad del sitio o sitios Web, la accesibilidad de los
mensajes y el nivel de seguridad.
MANUALES Los manuales de la organización son otros documentos cualitativos que el analista debe examinar.
Entre éstos se incluyen los manuales para los procedimientos de operación del equipo de cómputo y los manuales
en línea. Hay que analizar los manuales con base en los cinco lineamientos mencionados anteriormente. Recuerde
que los manuales presentan lo “ideal”, la forma en que se espera que se comporten las máquinas y las personas.
Es importante recordar que raras veces se mantienen actualizados los manuales impresos y, de hecho, algunas
veces quedan relegados en alguna repisa.
MANUALES DE POLÍTICAS El último tipo de documento cualitativo que consideraremos es el manual de políticas.
Aunque por lo general estos documentos abarcan amplias áreas de comportamiento de los empleados y la
empresa, usted se debe enfocar principalmente en aquellos que traten sobre las políticas relacionadas con los
servicios de cómputo, su uso, acceso, seguridad y cuotas. Al examinar las políticas, el analista de sistemas puede
obtener una buena idea de los valores, posturas y creencias que guían a la empresa.
www.xlibros.com
142 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 143
FIGURA 5.7
Una página de muestra del guión
del analista, en la que se describe
Análisis de Em el proceso de toma de decisiones.
presa: Solid
guión Analista: L.
Steel Shelvi
ng Escenario
Bracket : Aseguramient
Fecha: o de calidad
1/3/2010
Encargado de to
mar
decisiones (acto
r)
Actividad relacio
nada con la info
rmación (guión
Gerente de as )
eguramiento
de calidad Pi de al supervisor
informe diar de piso de la
io de produc tienda el
Supervisor de ción
piso Imprime el in
de la tienda forme diario
computarizad de producción
o
Habla sobre
los problema
tiradas de pr s recurrente
oducción con s en las
Gerente de as as eg uramiento de el gerente de
eguramiento Le calidad (QA)
de calidad e el informe
de producción
Compara el in
forme actual
informes de con los demá
la misma sema s
Introduce lo na
s datos de la
diaria en el tirada de pr
modelo de QA oducción
Observa los en la comput
resultados en adora
de QA pantalla del
modelo
Llama a los
proveedores
sobre las de de acero para
sviaciones de hablar
Supervisor de ca li da d los estándar
es de
piso Asiste a la
de la tienda reunión sobr
especificaci e las nuevas
ones de cali
aseguramient dad con el ge
o de calidad rente de
de producción y el vicepres
Gerente de as idente
eguramiento Ha
de calidad ce un borrad
or de la cart
los proveedo a para inform
res sobre la ar a
de calidad ac s nuevas espe
ordadas en la cificaciones
Envía el borr reunión
ador al vice
electrónico presidente ví
a correo
Vicepresiden
te de
producción Lee el borrad
or de la cart
Devuelve las a
correcciones
correo electr y comentario
Gerente de as ónico s vía
eguramiento Le
de calidad e la carta co
rregida en el
Vuelve a escr correo electr
ibir la cart ónico
cambios a para reflej
ar los
que observar de manera explícita siete elementos concretos que se encuentran comúnmente en las oficinas. En la
figura 5.8 se muestran los siete elementos observables y algunas de las preguntas clave que pueden surgir. Estos
elementos pueden revelar mucho sobre la forma en que un encargado de tomar decisiones recopila, procesa, al-
macena y comparte información, así como sobre su credibilidad en el lugar de trabajo.
UBICACIÓN DE LA OFICINA Uno de los primeros elementos que debe observar un analista de sistemas es la ubica-
ción de la oficina de un encargado de tomar decisiones con respecto a las demás oficinas. Las oficinas accesibles
tienden a incrementar la frecuencia de interacción y los mensajes informales, mientras que las oficinas
inaccesibles tienden a reducir la frecuencia de interacción y aumentan los mensajes orientados a tareas. Las
oficinas distribuidas a lo largo del perímetro del edificio por lo general ocasionan que se retenga un informe o
memo en una de las oficinas, mientras que los conglomerados de oficinas fomentan la difusión de información.
También es probable que las personas cuyas oficinas estén separadas de los demás tengan la tendencia de ver a la
www.xlibros.com
144 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 5.8
Elemento observable Preguntas que un analista podría investigar
Siete elementos concretos
observables de STROBE y ¿Quién tiene la oficina de la esquina? ¿Están
ejemplos de preguntas que tal vez Ubicación de la oficina dispersos en pisos separados los encargados de
un analista quiera hacer. tomar decisiones?
organización de una manera distinta y, por ende, se aparten de los demás miembros de la organización en cuanto
a sus objetivos.
COLOCACIÓN DEL ESCRITORIO La colocación de un escritorio en la oficina puede ofrecer pistas en cuanto a la
forma en que el encargado de tomar decisiones ejerce su poder. Los ejecutivos que encierran a un visitante en
un espacio estrecho con la espalda del visitante dando a la pared mientras se permiten a sí mismos un amplio
espacio, se colocan por sí solos en la más alta posición de poder posible. Es probable que un ejecutivo que coloca
su escritorio de cara a la pared con una silla a un lado para el visitante fomente la participación e intercambios
equitativos de información. El analista de sistemas debe observar la disposición de los muebles de la oficina y
en especial la colocación del escritorio. La figura 5.9 muestra un ejemplo de la colocación de un escritorio, así
como muchos de los otros elementos de STROBE, como los accesorios, el equipo de oficina estacionario, la
iluminación, el color y las fuentes externas de información.
FIGURA 5.9
Observe la oficina del encargado
de tomar decisiones para obtener Iluminación
Discos CD-RW
pistas concernientes a su fluorescente
almacenamiento personal,
procesamiento y difusión de la
Publicaciones especializadas
información.
en el librero
PC en el
*
SEKR
escritorio
Archivero
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 145
O P O R T U N I D A D D E C O N S U LT O R Í A 5 . 3
No confíes en su autoestima
o no todo se refleja en un espejo
Director Director
administrativo médico
FIGURA 5.C1
Cuadro organizacional del centro de sangre regional.
EQUIPO DE OFICINA ESTACIONARIO Los archiveros, libreros y demás equipo grande para
almacenar artículos se incluyen en la categoría de equipo de oficina estacionario. Si no hay tal
equipo, es probable que el encargado de tomar decisiones almacene muy pocos elementos de
información personalmente. Si hay mucho equipo de este tipo, es posible que el encargado
de tomar decisiones almacene y valore mucha información.
ACCESORIOS El término accesorios (props en inglés, una abreviación del término propiedades
utilizado en el teatro/cine) se refiere a todo el equipo pequeño empleado para procesar
www.xlibros.com
146 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
información, incluyendo teléfonos inteligentes, calculadoras, PC, plumas, lápices y reglas. La presencia de
equipos de bolsillo, calculadoras y PC en la oficina del encargado de tomar decisiones sugiere que es más
probable que los utilice en forma personal que alguien que deba salir de la oficina para usarlos.
FUENTES EXTERNAS DE INFORMACIÓN Un analista de sistemas necesita saber el tipo de información que utiliza
el encargado de tomar decisiones. Al observar el tipo de publicaciones almacenadas en su oficina es posible
averiguar si el encargado de tomar decisiones busca información externa (la que encuentra en publicaciones
especializadas, artículos de noticias sobre otras empresas en la industria, etc.) o si confía más en la información
interna (informes de la empresa, correspondencia entre oficinas, manuales de políticas). El analista también debe
observar si el encargado de tomar decisiones prefiere obtener información externa a través de Web.
ILUMINACIÓN Y COLORES DE LA OFICINA La iluminación y el color desempeñan un papel importante en la
forma en que el encargado de tomar decisiones recopila información. Una oficina con iluminación cálida e
incandescente indica la tendencia hacia una comunicación más personal. Un ejecutivo en una oficina con
iluminación cálida recopilará más información de manera informal, mientras que algún otro miembro de la
organización que trabaje en una oficina con mucha iluminación y colores fuertes tal vez recopile información por
medios más formales, como memos e informes oficiales.
VESTIMENTA DE LOS ENCARGADOS DE LAS DECISIONES Mucho se ha escrito sobre la vestimenta que utilizan
los ejecutivos y demás personas con autoridad. El analista de sistemas puede obtener un entendimiento de la
credibilidad que exhiben los gerentes en la organización al observar la ropa que utilizan en el trabajo. El traje de
dos piezas para un hombre, o con falda para una mujer, representa la máxima autoridad, de acuerdo con algunos
investigadores que han estudiado las percepciones de la apariencia de los ejecutivos. Cuando los líderes visten
ropa casual pueden dar cabida a un proceso de toma de decisiones más participativo, pero dicha vestimenta a
menudo provoca cierta pérdida de credibilidad en la organización, si la cultura predominante valora la vestimenta
tradicional y conservadora.
Mediante el uso del método STROBE, el analista de sistemas puede obtener una mejor comprensión de la
forma en que los gerentes recopilan, procesan, almacenan y utilizan la información. En la figura 5.10 se muestra
un resumen de las características que exhiben los encargados de tomar decisiones y los correspondientes elemen-
tos observables.
FIGURA 5.10
Características de los encargados Elementos correspondientes en
Un resumen de las características
de tomar decisiones el entorno físico
de los encargados de tomar
decisiones, las cuales
Recopila información de manera informal Iluminación incandescente y colores cálidos
corresponden a los elementos
observables en el entorno físico. Busca información fuera de la organización Había publicaciones especializadas en la oficina
Procesa los datos en forma personal Había PC o computadoras tipo tableta en la oficina
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 147
ATRACTIVO DE LA MAC
Recolectar datos en forma discreta parece algo sencillo, hasta que nos damos cuenta de que debemos organizar, alma-
cenar y recuperar todos los datos recolectados para llevar a cabo el análisis. La solución más simple es un paquete de
software llamado Yojimbo de la compañía Bare Bones. Es económico y fácil de usar. Sólo hay que arrastrar los elemen-
tos que deseamos recolectar hacia Yojimbo y buscarlos después. Una metodología más estructurada sería usar una
aplicación como DEVONthink Professional Office. La metáfora de una oficina es un poco ambiciosa, ya que usar esta
aplicación es como arrojar todo tipo de datos en el cajón de un escritorio y después averiguar cómo organizarlo. DE-
VONthink acepta archivos de Microsoft Word, Excel y PowerPoint, así como cualquier objeto de iWork. Puede llevar
el registro de sitios favoritos y páginas Web, imágenes y archivos PDF. Un lector OCR integrado ayuda a introducir
páginas en forma directa.
Cuando llega el momento de acceder a la información, DEVONthink puede ayudar al analista de sistemas a reali-
zar búsquedas, clasificar y mostrar relaciones entre los elementos gracias a la inteligencia artificial. DEVONthink no
ayuda a un analista a determinar el tamaño de las muestras o a llevar la cuenta de los errores, pero sí ayuda a recolectar,
almacenar, recuperar, usar y compartir la información recopilada por el analista.
FIGURA 5.MAC
DEVONthink Professional Office de DEVONtechnologies.
3. Un óvalo o símbolo en forma de ojo sirve como pista para que el analista de sistemas busque más detalles.
4. Un cuadrado indica que la observación de los elementos STROBE modifica la narrativa.
5. Un círculo indica que la narrativa se complementa con lo que se observó.
Al implementar el método STROBE de esta forma, el primer paso es anotar los temas clave de la or-
ganización que surjan de las entrevistas. Después se observan y registran los elementos de STROBE. Más
adelante, al comparar la narrativa y las observaciones, se utiliza uno de los cinco símbolos apropiados para
caracterizar la relación. Así, el analista crea una tabla que primero documenta y después ayuda a analizar las
observaciones.
www.xlibros.com
148 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 5.11
Lista anecdótica con símbolos,
para la implementación de
Lista de anécdo
STROBE. tas con símbolo
s para aplicar ST
Narrativa descrit ROBE
a por los Iluminación, color
miembros de la Ubicación de y
organización Vestimenta del
oficina y equipo elementos gráfico
s encargad
La información
fluye de manera de la oficina o de tomar
activa en todos
los niveles. decisiones
Clave
Confirma la narra
tiv a
Pista para buscar
Niega o invierte más detalles
la narrativa
Modifica la narra
tiva
Complementa la
narrativa
RESUMEN
En este capítulo conocimos los métodos discretos para recopi- documentos como facturas, informes de ventas y memos, o
lar información: el muestreo, la investigación de datos cualita- tal vez seleccionar y entrevistar, repartir encuestas u observar
tivos y cuantitativos en formularios actuales y archivados, y la miembros de la organización. El muestreo puede reducir los
observación de las actividades del encargado de las decisiones costos, agilizar el proceso de recopilación de datos, mejorar
por medio del guión del analista, así como la observación del la efectividad del estudio y reducir la predisposición en el
entorno físico del encargado de las decisiones mediante el uso mismo.
de STROBE. Un analista de sistemas debe seguir cuatro pasos para dise-
Al proceso de seleccionar en forma sistemática los ele- ñar una buena muestra: determinar la población, decidir sobre
mentos representativos de una población se le conoce como el tipo de muestra, calcular el tamaño de la misma y planear los
muestreo. El propósito del muestreo es seleccionar y estudiar datos que es necesario recolectar o describir.
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 149
“hecho,
E stamos orgullosos de nuestro edificio aquí en Tennessee. De
pedimos a la firma arquitectónica I. M. Paid que usara el
Preguntas de HYPERCASE
1. Use el método STROBE para comparar y contrastar las
mismo tema para mezclarnos con el paisaje local y, al mismo oficinas de Evans y Ketcham. ¿A qué conclusión puede llegar
tiempo, identificarnos con nuestros clientes en todas las sucursales. con sus observaciones de la manera en que cada persona
Recibimos muchas personas que entran sólo para admirar el edifi- utiliza la tecnología de la información? ¿Qué tan compatibles
cio, una vez que se dan cuenta dónde se ubica exactamente. De parecen ser Evans y Ketcham en términos de los sistemas que
hecho, para los estándares de Tennessee, recibimos tantos visitan- utilizan? ¿Qué otras pistas en cuanto al almacenamiento, al
tes, ¡que bien podríamos compararnos con las pirámides! Bueno, uso y a la difusión de la información puede descubrir después
usted podrá averiguarlo por su cuenta a medida que lo recorra. El de haber observado sus oficinas?
Atrio este (East Atrium) es mi lugar favorito: entra mucha luz a 2. Examine con cuidado la oficina de Kathy Blandford. Use el
través del enorme tragaluz del techo. Además siempre me ha fasci- método STROBE para confirmar, invertir o negar lo que supo
nado el hecho de que el edificio y su mobiliario podrían contar una durante su entrevista con ella. Haga una lista de todo lo que
historia muy distinta a la que cuentan sus ocupantes”. encuentre sobre la Srita. Blandford después de observar su
“Algunas veces los empleados se quejan de que todas las ofici- oficina, que no haya averiguado en la entrevista.
nas se ven iguales. Pero las salas públicas son espectaculares. Incluso 3. Examine con cuidado el contenido del área de recepción de
el comedor es atractivo. La mayoría de las personas no pueden decir MRE mediante el método STROBE. ¿Qué cosas puede
lo mismo de las cafeterías de su lugar de trabajo. De todas formas inferir sobre la organización? Elabore una lista. ¿Qué
puede observar que todos personalizamos nuestras oficinas. Así que, preguntas le gustaría hacer en las entrevistas después de
aunque éstas fueran iguales, las personalidades de sus ocupantes se haber observado el área de recepción? Haga una lista de las
adueñan de ellas después de un tiempo de ocuparlas. ¿Qué ha visto personas a las que le gustaría entrevistar y las preguntas que
usted? ¿Hubo algo que lo sorprendiera hasta ahora?”. haría a cada una de ellas.
FIGURA 5.HC1
Hay pistas ocultas en HyperCase. Use el método STROBE para descubrirlas.
Los tipos de muestras útiles para un analista de siste- de muestreo sistemático y muestreo estratificado. Hay varios
mas son: de conveniencia, intencionadas, simples aleatorias y lineamientos a seguir para determinar el tamaño de las mues-
complejas aleatorias. El último tipo incluye las subcategorías tras.
www.xlibros.com
150 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Los analistas de sistemas necesitan investigar los datos y adapta el sistema al usuario. Uno de los métodos para ello es la
formularios actuales y archivados, los cuales revelan dónde Observación estructurada del entorno (STROBE). Un analista
ha estado la organización y hacia dónde creen sus miembros de sistemas utiliza el método STROBE de la misma forma en
que se dirige. Hay que analizar tanto los documentos cuantita- que un crítico de cine utiliza un método conocido como análisis
tivos como los cualitativos. Debido a que los documentos son de puesta en escena (mise-en-scène) para analizar una toma en
mensajes persuasivos, debe tomar en cuenta que modificarlos una película.
puede también cambiar a la organización. Es posible observar e interpretar varios elementos concre-
Los analistas utilizan la observación como una técnica de tos en el entorno del encargado de tomar decisiones: 1) ubi-
recopilación de información; por medio de ella llegan a enten- cación de la oficina, 2) colocación de su escritorio, 3) equipo
der lo que en realidad ocurre cuando los usuarios interactúan de oficina estacionario, 4) accesorios como dispositivos de
con la tecnología de la información. Una manera de describir la bolsillo y PC, 5) fuentes externas de información como pu-
forma en que se comportan los encargados de tomar decisiones blicaciones especializadas y el uso de Web, 6) iluminación y
es mediante el uso de un guión del analista, en el que se docu- colores de la oficina y 7) vestimenta que utiliza el encargado
menta cada una de las actividades de los principales actores. de tomar decisiones. Se puede utilizar el método STROBE para
Además de observar el comportamiento del encargado de comprender mejor la verdadera forma en que los encargados de
las decisiones, el analista de sistemas debe observar su entorno tomar decisiones recopilan, procesan, almacenan y comparten
en busca de pistas importantes que le indiquen qué tan bien se la información para poder llevar a cabo su trabajo.
PREGUNTAS DE REPASO
1. Defina lo que significa muestreo.
2. Mencione cuatro razones por las que sería conveniente para el analista de sistemas muestrear datos o seleccionar
personas representativas para las entrevistas.
3. ¿Cuáles son los cuatro pasos a seguir para diseñar una buena muestra?
4. Mencione las tres metodologías para el muestreo complejo aleatorio.
5. Defina lo que significa estratificación de las muestras.
6. ¿Qué efecto sobre el tamaño de la muestra se produce al usar un mayor nivel de confianza a la hora de muestrear los
datos de los atributos?
7. ¿Cuál es la variable primordial que determina a cuántas personas debe el analista de sistemas entrevistar a profundidad?
8. ¿Qué información sobre el encargado de tomar decisiones busca obtener el analista a partir de la observación?
9. Mencione cinco pasos para ayudar al analista a observar las actividades comunes del encargado de tomar decisiones.
10. En la técnica conocida como guión del analista, ¿quién es el actor?
11. En el guión del analista, ¿qué información sobre los gerentes se registra en la columna de la derecha?
12. Teniendo en cuenta que la idea de STROBE provino originalmente del mundo cinematográfico, ¿a qué se asemeja el
papel del analista de sistemas?
13. Haga una lista de los siete elementos concretos del entorno físico del encargado de tomar decisiones que el analista de
sistemas puede observar mediante el uso de STROBE.
PROBLEMAS
1. A Cheryl Stake le preocupa que se estén llenando demasiados formularios de manera incorrecta. Ella cree que
aproximadamente un 8 por ciento de los formularios tienen errores.
a. ¿Qué tan grande debe ser el tamaño de muestra que utilice la Srita. Stake para estar un 99 por ciento segura de que
estará dentro del 0.02?
b. ¿Qué tan grande debe ser el tamaño de muestra que utilice la Srita. Stake para estar un 90 por ciento segura de que
estará dentro del 0.02?
c. Explique la diferencia entre las partes a y b.
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 151
d. Suponga que la Srita. Stake aceptará un nivel de confianza del 95 por ciento de que estará dentro del 0.02. ¿Cuál
deberá ser ahora el tamaño de la muestra de los formularios?
2. “Veo que tiene muchos papeles ahí. ¿Qué es todo eso?”, pregunta Betty Kant, jefa de la fuerza de trabajo de MIS que
constituye el grupo de enlace entre el grupo de sistemas que usted encabeza y la empresa Sawder’s Furniture Company.
Usted se encuentra lidiando con un gran paquete de papeles en el momento en que se prepara para salir del edificio.
“Bueno, tengo algunos estados de cuenta financieros, informes de producción de los últimos seis meses y algunos
informes de rendimiento que me dio Sharon sobre los objetivos y el rendimiento laboral durante los últimos seis meses”,
le contesta usted al tiempo que algunos de los papeles caen al piso. “¿Por qué?”
Betty toma los papeles que trae usted y los coloca en el escritorio más cercano. Después le responde: “Por que no
necesita toda esta basura. Está aquí para una cosa: hablar con nosotros, los usuarios. Apuesto a que nada de ese altero es
trascendente”.
a. La única forma de convencer a Betty de la importancia de cada documento es decirle lo que busca en cada uno.
Explique en un párrafo qué tipo de documento contribuye para que el analista de sistemas pueda entender el
funcionamiento de la empresa.
b. Mientras habla con Betty se da cuenta de que también necesita otros documentos cuantitativos. Haga una lista de
ellos.
3. Recientemente, usted obtuvo muestras de los mensajes de correo electrónico que se han enviado a varios gerentes de
nivel medio de Sawder’s Furniture Company, que distribuye muebles de aglomerado del tipo “hágalo usted mismo” en
todo el país. He aquí una que repite un mensaje que se encontró en varios memos más:
Para: Sid, Ernie, Carl
De: Imogene
Re: Provisiones de computadora/impresora
Fecha: Noviembre 10, 2009
Me han hecho saber que estoy en una guerra contra las solicitudes de provisiones de computadora e impresora (CD
grabables, tóner, papel, etc.) que están fuera de proporción en cuanto a lo que se había negociado con base en el
presupuesto actual. Como todos aquí somos buenos soldados, espero que acepten lo que su sargento de provisiones les
indique que sea lo normal. Por favor, no más “requisiciones a medianoche” para compensar la escasez en existencia.
Gracias por su lealtad, soldados; esto facilita la batalla para todos nosotros.
a. ¿Qué metáfora(s) se está(n) usando? Haga una lista de la metáfora dominante y otras frases que se relacionen con
ese tema.
b. Si encontró evidencia repetida de esta idea en otros mensajes de correo electrónico, ¿qué interpretación tendría? Use
un párrafo para explicar.
c. Describa en un párrafo la forma en que las personas en su grupo de análisis de sistemas pueden usar la información
de los mensajes de correo electrónico para dar forma a su proyecto de sistemas para Sawder’s.
d. En entrevistas con Sid, Ernie y Carl, no ha habido mención de problemas para obtener suficientes provisiones de
computadora e impresora. Describa en un párrafo por qué dichos problemas tal vez no surjan en las entrevistas y
hable sobre el valor de adicionalmente examinar los mensajes de correo electrónico y otros memos.
4. “He aquí el manual principal de políticas en el que hemos trabajado durante todos estos años para los usuarios del
sistema”, dice Al Bookbinder, al tiempo que sopla el polvo del manual y se lo entrega. Al se encarga de guardar los
documentos para el departamento de sistemas de Prechter and Gumbel, un gran fabricante de productos para el cuidado
de la salud y de belleza. “Todo lo que necesita saber cualquier usuario de cualquier parte del sistema está en lo que yo
llamo el Libro Azul. Es decir, está abarrotado de políticas. Es tan grande. Yo soy el único con un ejemplar completo.
Cuesta demasiado reproducirlo”. Usted agradece a Al y se lleva el manual. Al leerlo se asombra de su contenido. La
mayoría de las páginas empiezan con un mensaje tal como: “Esta página sustituye a la página 23.1 en el Vol. II del
manual. Deseche los insertos anteriores; no usar”.
a. Haga una lista de sus observaciones sobre la frecuencia de uso del Libro Azul.
b. ¿Qué tan amigables para los usuarios son las actualizaciones en el manual? Escriba un enunciado en el que explique
su respuesta.
c. Escriba un párrafo en el que comente sobre la sabiduría de tener todas las políticas importantes para todos los
usuarios del sistema en un solo libro.
d. Sugiera una solución que incorpore el uso de manuales de políticas en línea para algunos usuarios.
5. “Creo que podré recordar casi todo lo que él hace”, dice Ceci Awll. Ceci está a punto de entrevistar a Biff Welldon,
vicepresidente de planeación estratégica de OK Corral, una cadena de restaurantes de bisteces con 130 sucursales. “Es
decir, tengo buena memoria. De todas formas, creo que es mucho más importante escuchar lo que dice que observar lo
que hace”. Como miembro del equipo de analistas de sistemas que usted dirige, Ceci ha estado hablando con usted
sobre la conveniencia de anotar sus observaciones de la oficina de Biff y sus actividades durante la entrevista.
a. En un párrafo, persuada a Ceci de que no basta con escuchar en las entrevistas, sino que también es importante
observar y registrar esas observaciones.
b. Parece que Ceci ha aceptado su idea de que es importante la observación, pero aún no sabe cómo realizarla. Haga
una lista de elementos y comportamientos a observar, y en un enunciado junto a cada comportamiento indique el
tipo de información que Ceci debe obtener.
www.xlibros.com
152 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
6. “Somos una empresa progresista, siempre buscando estar delante de la curva de energía. Probaremos cualquier cosa con
tal de que podamos adelantarnos a la competencia, y eso nos incluye a todos”, dice I. B. Daring, un ejecutivo de la
empresa Michigan Manufacturing (2M). Usted lo está entrevistando como un paso preliminar en un proyecto de
sistemas en el que sus subordinados han expresado interés. A medida que escucha a I. B., echa una ojeada en su oficina y
descubre que la mayor parte de la información que tiene almacenada en las repisas se puede clasificar como manuales de
procedimientos internos. Además observa que hay una PC en una mesa en la parte posterior de la oficina de I. B. La
pantalla está cubierta de polvo y los manuales apilados a un lado de la PC aún tienen la envoltura original. Aunque usted
sabe que 2M utiliza una intranet, no puede ver cables que entren o salgan de la PC de I.B. En la pared detrás del enorme
escritorio de caoba se aprecian cinco retratos al óleo, enmarcados, de los fundadores de 2M, todos agrupados alrededor
de una placa dorada que porta el lema de la corporación: “Asegúrese de estar en lo correcto y después, siga adelante”.
a. ¿Cuál es la narrativa organizacional o argumento según lo que describe I. B. Daring? Reformule con sus propias
palabras.
b. Haga una lista de los elementos de STROBE que haya observado durante su entrevista con I.B.
c. Escriba, al lado de cada elemento de STROBE que haya observado, un enunciado sobre cómo lo interpretaría.
d. Construya una tabla con el lema de la organización del lado inferior izquierdo de la página y los elementos de
STROBE en la parte superior. Use los símbolos de la aplicación de la “lista de anécdotas” de STROBE para indicar
la relación entre el argumento de la organización según lo descrito por I.B. y cada elemento que usted haya
observado (es decir, indique si cada elemento de STROBE confirma, invierte, lo obliga a buscar más detalles,
modifica o complementa la narrativa).
e. Con base en sus observaciones de STROBE y su entrevista, declare en un párrafo los problemas que puede anticipar
en cuanto a obtener un nuevo sistema aprobado por I.B. y los demás. En una oración o dos describa cómo hubiera
podido ser distinto su diagnóstico si sólo hubiera hablado con I.B. por teléfono, o si hubiera leído sus comentarios
escritos en una propuesta de sistemas.
PROYECTOS EN GRUPO
1. Suponga que su grupo servirá como equipo de análisis y diseño de sistemas en un proyecto diseñado para computarizar
o mejorar la computarización de todos los aspectos de negocios de una empresa de transportes estadounidense a nivel
nacional con una trayectoria de 15 años, conocida como Maverick Transport. Esta empresa se especializa en embarques
menores a un camión completo (LTL). Los empleados de la administración trabajan con base en la filosofía de justo a
tiempo (JIT), a partir de la cual han creado una sociedad en la que se incluye el emisor, el destinatario y el transportista
(Maverick Transport) para el propósito de transportar y entregar los materiales que se requieren justo a tiempo para
usarlos en la línea de producción. Maverick mantiene 626 camiones para transportar carga y cuenta con 45,000 pies
cuadrados de espacio de bodega, además de 21,000 pies cuadrados de espacio de oficina.
a. Desarrolle junto a los miembros de su grupo una lista de recursos de datos de archivo que se deban verificar al
analizar los requerimientos de información de Maverick.
b. Cuando la lista esté completa, idee un esquema de muestreo que permita a su grupo obtener una imagen clara de la
empresa sin tener que leer todos los documentos generados en su historial de 15 años.
2. Haga los arreglos para visitar una organización local que esté en expansión o que esté mejorando de alguna forma sus
sistemas de información. Para que su grupo pueda practicar los diversos métodos de observación descritos en este
capítulo, asigne uno de estos dos métodos a cada miembro del equipo: 1) desarrollar el guión del analista o 2) usar
STROBE. Es posible emplear muchas de estas estrategias durante las entrevistas de uno a uno, mientras que otras
requieren reuniones formales en la organización. Trate de cumplir con varios objetivos durante su visita a la
organización; prográmela a una hora apropiada que permita a todos los miembros del equipo probar su método de
observación asignado. Usar varios métodos como las entrevistas y la observación (la mayor parte de las veces al mismo
tiempo) es la única forma efectiva en costo de obtener una imagen verdadera y oportuna de los requerimientos de
información de la organización.
3. Los miembros de su grupo se deben reunir y discutir sobre sus hallazgos después de completar el proyecto 2. ¿Hubo
sorpresas? ¿La información recopilada por medio de la observación confirmó, invirtió o negó lo que se aprendió en las
entrevistas? ¿Hubo conflictos directos entre algunos de los hallazgos de los métodos de observación? Trabaje con su
grupo para desarrollar una lista de formas de lidiar con cualquier tipo de información desconcertante (por ejemplo,
mediante la realización de entrevistas de seguimiento).
www.xlibros.com
CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 153
BIBLIOGRAFÍA SELECCIONADA
Cooper, D. R. y P. S. Schindler. Business Research Methods. Nueva York: McGraw-Hill/Irwin, 2007.
Edwards, A. y R. Talbot. The Hard-Pressed Researcher. Nueva York: Longman, 1994.
Kendall, J. E. “Examining the Relationship Between Computer Cartoons and Factors in Information Systems Use, Success and
Failure; Visual Evidence of Met and Unmet Expectations”. The DATA BASE for Advances in Information Systems, Vol. 28,
Núm. 2, primavera de 1997, pp. 113-126.
Kendall, J. E. y K. E. Kendall. “Metaphors and Methodologies: Living Beyond the Systems Machine”. MIS Quarterly, Vol. 17,
Núm. 2, junio 1993, pp. 149-171.
Kendall, J. E. y K. E. Kendall. “Metaphors and Their Meaning for Information Systems Development”. European Journal of
Information Systems, 1994, pp. 37-47.
Kendall K. E. y J. E. Kendall. “Observing Organizational Environments: A Systematic Approach for Information Analysts”.
MIS Quarterly, Vol. 5, Núm. 1, 1981, pp. 43-55.
Kendall K. E. y J. E. Kendall. “STROBE: A Structured Approach to the Observation of the Decision-Making Environment”.
Information and Management, Vol. 7, Núm. 1, 1984, pp. 1-11.
Kendall, K. E. y J. E. Kendall. “Structured Observation of the Decision-Making Environment: A Validity and Reliability
Assessment”. Decision Sciences, Vol. 15, Núm. 1, 1984, pp. 107-118.
Markus, M. L. y A. S. Lee. “Special Issue on Intensive Research in Information Systems: Using Qualitative, Interpretive and Case
Methods to Study Information Technology—Second Installment”. MIS Quarterly, Vol. 24, Núm. 1, marzo de 2000, p.1.
Schultze, U. “A Confessional Account of an Ethnography About Knowledge Work”. MIS Quarterly, Vol. 24, Núm. 1, marzo de
2000, pp. 3-41.
Shultis, R. L. “‘Playscript’—A New Tool Accountants Need”. NAA Bulletin, Vol. 45, Núm. 12, agosto de 1964, pp- 3-10.
Webb, E. J., D. T. Campbell, R. D. Schwartz y L. Sechrest. Nonreactive Measures in the Social Sciences, 2da. edición. Stanford,
CT: CENGAGE Learning, 1981.
www.xlibros.com
154 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EPISODIO 5
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Ver es creer
“Chip, sé que las entrevistas tardaron mucho tiempo, pero valieron la pena”, dice Anna en tono defensivo mientras Chip entra
a su oficina con una mirada de preocupación en su rostro.
“Estoy seguro de ello”, dice Chip. “En realidad les dejaste una buena impresión. Las personas me han detenido en el pa-
sillo para decirme que están felices de que estemos trabajando en el nuevo sistema. No me preocupan las entrevistas en sí. Lo
que me preocupa es que no tuvimos tiempo para hablar sobre las observaciones antes de que hicieras las entrevistas”.
“Pierde cuidado, fui toda ojos”, se ríe Anna. “Utilicé una técnica llamada STROBE, Observación estructurada del entorno,
para ver de una manera sistemática los hábitats de nuestra persona encargada de tomar las decisiones. De seguro le interesarán
las notas que escribí para cada persona que entrevisté”, dice Anna, mientras entrega a Chip por escrito sus observaciones orga-
nizadas de cada una de las entrevistas.
EJERCICIOS
Para hacer estos ejercicios tiene que visitar el sitio Web para obtener las observaciones de las oficinas de los encargados de tomar
decisiones. Visite el sitio Web en www.pearsonhighered.com/kendall y busque la sección “CPU Observations of Decision Mak-
ers’ Offices” (Observaciones de la CPU sobre las oficinas de los encargados de tomar decisiones).
E-1. Con base en la observación que hizo Anna sobre la oficina y las vestimentas de Dot, use el método STROBE para anali-
zar a Dot como encargado de tomar decisiones. En dos párrafos, compare y contraste lo que aprendió en la entrevista de
Dot con lo que aprendió por medio del método STROBE.
E-2. Después de examinar las observaciones por escrito de Anna sobre la oficina de Mike Crowe, use el método STROBE
para analizar a Mike como encargado de tomar decisiones. ¿Qué diferencias (si las hay) puede ver entre la entrevista de
Mike y las observaciones de Anna sobre Mike? Responda en dos párrafos.
E-3. Use el método STROBE para analizar las observaciones por escrito de Anna sobre Cher Ware y Paige Prynter. Use dos
párrafos para comparar y contrastar el estilo de toma de decisiones de cada persona, según lo que revelen sus oficinas y
su vestimenta.
E-4. Use el método STROBE para analizar las observaciones por escrito de Anna sobre Hy Perteks. Ahora compare su análisis
con la entrevista de Hy. Use dos párrafos para discutir si STROBE confirma, niega, invierte o sirve como pista para buscar
más detalles en la narrativa de Hy (incluya preguntas adicionales que desee hacer a Hy para aclarar su interpretación).
www.xlibros.com
CAPÍTULO 6
Modelado ágil
y prototipos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender las raíces del modelado ágil en prototipos y los cuatro tipos principales
de éstos.
2. Usar prototipos para recopilar requerimientos humanos de información.
3. Comprender el concepto de RAD para usarlo en la recopilación de los requerimientos
humanos de información y el diseño de interfaces.
4. Comprender el modelado ágil y las prácticas básicas que lo diferencian de otras
metodologías de desarrollo.
5. Conocer la importancia de los valores fundamentales para el modelado ágil.
6. Comprender cómo mejorar la eficiencia, para trabajadores expertos, mediante el uso
de métodos estructurados o modelado ágil.
155
www.xlibros.com
156 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
PROTOTIPOS
Como analista de sistemas que va a presentar un prototipo del sistema de información, a usted le interesan
mucho las reacciones que tendrán los usuarios y la administración con respecto al prototipo. Debe anticipar
con precisión cómo reaccionarán al trabajar con el prototipo y qué tan bien se adaptarán a sus necesidades las
características del sistema previstas. Las reacciones se recopilan a través de la observación, entrevistas y hojas
de retroalimentación (posiblemente cuestionarios) diseñadas para obtener la opinión de cada persona sobre el
prototipo a medida que interactúa con él.
La información que se recopila en la fase de prototipos permite al analista establecer prioridades y redirigir
los planes sin sufrir repercusiones graves, con un mínimo de interrupción. Debido a esta característica, la crea-
ción de prototipos y la planeación van de la mano.
Tipos de prototipos
La palabra prototipo se utiliza en muchas formas; en vez de intentar una definición sintetizada de ellos, o de tra-
tar de forzar una metodología correcta para este tema controversial, vamos a ilustrar cómo se puede aplicar con
éxito cada una de las diversas concepciones de los prototipos en una situación específica, como se muestra en la
figura 6.1.
PROTOTIPO DE PARCHES El primer tipo alude a la construcción de un sistema funcional, parchado o construido
totalmente con parches. En ingeniería, a esta metodología se le conoce como “breadboarding”: crear un modelo
funcional de un circuito integrado (cuya forma final será microscópica) uniendo partes.
En términos de sistemas de información, se trata de un modelo funcional, con todas las características ne-
cesarias, pero que es ineficiente. En esta instancia del prototipo, los usuarios pueden interactuar con el sistema
y acostumbrarse a la interfaz y a los tipos de salidas disponibles. Sin embargo, los procesos de recuperación y
almacenamiento de información pueden ser ineficientes debido a que los programas se escribieron con rapidez,
con el objetivo de que fuera funcional en vez de eficiente.
FIGURA 6.1
Cuatro tipos de prototipos (en el
sentido de las manecillas del
reloj, empezando en la esquina
Entrada Proceso Salida
superior izquierda).
Instalación 3
Instalación 2
Instalación 1
Característica 1
Característica 3
Característica 5
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 157
www.xlibros.com
158 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
se podrían solucionar algunos de los problemas implicados con la identificación precisa de los requerimientos de
información de los usuarios.
Una desventaja de sustituir el SDLC con la creación de prototipos deriva de dar forma al sistema antes de
comprender perfectamente el problema o la oportunidad pertinente. Además, al usar los prototipos como alter-
nativa se podría producir un sistema que sea aceptado por ciertos grupos específicos de usuarios, pero que sea
inadecuado para las necesidades del sistema en general.
El método por el que abogamos en este libro es usar prototipos como parte del SDLC tradicional. Así po-
demos considerar a los prototipos como un método adicional especializado para averiguar los requerimientos de
información de los usuarios a medida que interactúan con los prototipos y proveen retroalimentación para el
analista.
DESARROLLO DE UN PROTOTIPO
Los prototipos son un medio excelente para obtener retroalimentación sobre el sistema propuesto y el grado en
que cumple con las necesidades de información de sus usuarios, como se muestra en la figura 6.2. El primer paso
de la creación de un prototipo es estimar los costos involucrados en la construcción de un módulo del sistema.
Si los costos del tiempo de los programadores y del analista, así como los costos del equipo están dentro del
presupuesto, se puede continuar con la construcción del prototipo. Ésta es una excelente manera de facilitar la
integración del sistema de información en la cultura y sistema, más extensos, de la organización.
FIGURA 6.2
Los analistas deben modificar los
diseños de sus pantallas originales
con base en las reacciones de los
usuarios al prototipo.
diseño
Modifique su
en la s
con base
su
reacciones a
prototipo
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 159
O P O R T U N I D A D D E C O N S U LT O R Í A 6 . 1
www.xlibros.com
160 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U LT O R Í A 6 . 2
el concepto de RAD, podrá ver de nuevo la importancia de la creación rápida de sistemas. Además, el modelado
ágil también se basa en la práctica de tiempos de entrega cortos.
MODIFICAR EL PROTOTIPO Un tercer lineamiento para desarrollar el prototipo es que su construcción debe admitir
modificaciones. Para lograr esto hay que crearlo en módulos que no tengan un alto grado de interdependencia. Si
cumplimos con este lineamiento encontraremos menos resistencia cuando haya que modificar el prototipo.
Por lo general el prototipo se modifica varias veces, para lo cual pasa a través de varias iteraciones. Los
cambios en el prototipo deben acercar más el sistema a lo que los usuarios dicen que es importante. Cada modi-
ficación requiere de otra evaluación por parte de los usuarios.
El prototipo no es un sistema terminado. Entrar a la fase de creación del prototipo con la idea de que reque-
rirá modificaciones es una postura útil que demuestra a los usuarios qué tan necesaria es su retroalimentación
para mejorar el sistema.
HACER ÉNFASIS EN LA INTERFAZ DE USUARIO La interfaz del usuario con el prototipo (y con el sistema, en
última instancia) es muy importante. Como lo que realmente tratamos de lograr con el prototipo es hacer que
los usuarios articulen con más detalle sus requerimientos de información, deben ser capaces de interactuar con
facilidad con el prototipo del sistema. También deben ser capaces de ver cómo el prototipo les permitirá realizar
sus tareas. Para muchos usuarios, la interfaz es el sistema. No debe ser un obstáculo.
Aunque muchos aspectos del sistema quedarán sin desarrollarse en el prototipo, la interfaz de usuario debe
estar lo suficientemente desarrollada como para que los usuarios puedan acoplarse al sistema con rapidez y no
desanimarse. Los sistemas interactivos en línea que utilizan interfaces de GUI se adaptan de manera ideal a los
prototipos. En el capítulo 14 describiremos con detalle las consideraciones importantes en el diseño de HCI.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 161
O P O R T U N I D A D D E C O N S U LT O R Í A 6 . 3
Incubar un pez
un prototipo como sistema completo cuando todavía es inadecuado y aunque nunca haya tenido la intención de
servir como sistema terminado. Los analistas necesitan trabajar para asegurarse de que la comunicación con los
usuarios sea clara en cuanto a la agenda para interactuar con el prototipo y mejorarlo.
El analista debe comparar estas desventajas contra las ventajas conocidas al decidir si va a crear un proto-
tipo, cuándo se va a crear y qué tanto del sistema se va a incluir en el prototipo.
www.xlibros.com
162 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U LT O R Í A 6 . 4
costo relativamente bajo tales como los productos Microsoft Office, hay otros paquetes de software COTS ela-
borados y costosos, pero muy útiles. Como ejemplo de implementación rápida de software COTS tenemos la
forma en que la Catholic University utiliza el paquete de software COTS ERP conocido como People Soft, que
se encarga de muchas de sus funciones basadas en Web.
La Catholic University, junto con un grupo de consultoría en educación superior y PeopleSoft, emprendieron
con éxito la implementación rápida de un módulo de reclutamiento y admisiones de su software COTS. Lanzaron
la implementación en abril de 1999 y para octubre de ese año habían implementado con éxito el reclutamiento
y las admisiones para los estudiantes universitarios. Para noviembre de ese mismo año, habían implementado
las mismas funciones para los estudiantes de postgrado. Otros módulos el software COTS de PeopleSoft que se
implementan en la Catholic University son un catálogo de cursos completo en línea, el registro en línea y la ca-
pacidad para que los estudiantes revisen sus calificaciones, transcripciones, cuentas y pagos de ayuda financiera
en línea, desde cualquier parte.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 163
FIGURA 6.3
Un paso importante en la creación
de prototipos es registrar en forma
Formulario de ev adecuada las reacciones de los
Nombre del obser aluación del proto
vador Michael Cerveris tipo usuarios, sus sugerencias,
Nombre del sistem Fecha 1/06/ innovaciones y planes de revisión.
a o proyecto 2010
Centro de datos Empresa o ubica
de computación ción
Nombre o núme en nube Aquarius Water
ro de programa Filters
Mant. Prev.
Versión
Usuario 1 1
Nombre de usua Us uario 2
rio Andy H. Usuario 3
Periodo de observac Pam H. Usuario 4
ión 1/06/2010
Reacciones de los 1/06/2010
Favorable en
usuarios ¡Excelente!
general, se
emocionó sobre
el proyecto.
Sugerencias de
los usuarios
Ag regar la fecha
Colocar un número
en que se realizó
de formulario en la
el mantenimiento
. parte superior pa
ra
referencia. Colocar
la palabra SEMANA
L
Innovaciones en el título.
Planes de revisió
n Modificar el
1/08/2010
Revisar con
Andy y Pam.
Los usuarios deben tener la libertad de experimentar con el prototipo. A diferencia de una simple lista de ca-
racterísticas del sistema, el prototipo permite a los usuarios interactuar en forma práctica con el sistema. Montar
un prototipo en un sitio Web interactivo es una forma de facilitar esta interacción.
Otro aspecto del papel de los usuarios en los prototipos es que se requiere que expresen reacciones abiertas
al mismo. Los analistas tienen que estar presentes por lo menos parte del tiempo cuando ocurre la experimenta-
ción. De esta forma pueden observar las interacciones de los usuarios con el sistema y llegar a ver interacciones
que nunca planearon. En la figura 6.3 se muestra un formulario lleno para observar la experimentación del usua-
rio con el prototipo. Algunas de las variables a observar son las reacciones de los usuarios al prototipo, sus sugeren-
cias para cambiar o expandir el prototipo, sus innovaciones para usar el sistema en formas completamente nuevas
y cualquier plan de revisión para el prototipo que ayude a establecer las prioridades.
El tercer aspecto del papel que desempeñan los usuarios en los prototipos es su disposición para sugerir
elementos que se puedan agregar o quitar en base a las características que hayan experimentado. La función del
analista es obtener tales sugerencias al asegurar a los usuarios que la retroalimentación que ellos proveen se toma
en serio, al observar a los usuarios a medida que interactúan con el sistema y al llevar a cabo entrevistas cortas
y específicas con los usuarios en relación con sus experiencias con el prototipo. Aunque se pedirá a los usua-
rios que articulen sugerencias e innovaciones para el prototipo, al final es responsabilidad del analista ponderar
esta retroalimentación y traducirla en cambios funcionales en donde sea necesario. Para facilitar el proceso de
creación del prototipo, el analista debe comunicar con claridad los propósitos de la creación de prototipos a los
usuarios, junto con la idea de que los prototipos son valiosos sólo cuando los usuarios se involucran en forma
significativa.
www.xlibros.com
164 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
la creación de prototipos, es mucho más fácil entender los aspectos básicos de RAD, que se puede considerar
como una implementación específica de la creación de prototipos.
Algunos desarrolladores consideran a RAD como una metodología útil para los nuevos entornos de comer-
cio electrónico basado en Web, donde el denominado estatus del primer participante de un negocio podría ser
importante. En otras palabras, para implementar una aplicación en Web antes que sus competidores, tal vez sea
conveniente para las empresas que sus equipos de desarrollo experimenten con RAD.
Fases de RAD
Hay tres amplias fases para RAD en las que se involucra tanto a los usuarios como a los analistas en la evalua-
ción, el diseño y la implementación. En la figura 6.4 se describen estas tres fases. Observe que RAD involucra
a los usuarios en cada parte del esfuerzo de desarrollo, con una intensa participación en la parte comercial del
diseño.
FASE DE PLANEACIÓN DE LOS REQUERIMIENTOS En esta fase, los usuarios y analistas se reúnen para identificar
los objetivos de la aplicación o el sistema, y para identificar los requerimientos de información que surgen a
partir de estos objetivos. En esta fase se requiere una participación intensa de ambos grupos, y no consiste sólo
en la firma de una propuesta o documento. Además, es probable que se involucren usuarios de distintos niveles
de la organización (como vimos en el capítulo 2). En la fase de planeación de los requerimientos, cuando
todavía se está lidiando con los requerimientos de información, usted tal vez esté trabajando con el CIO (si es
una organización extensa) y con los planeadores estratégicos, en especial si elabora una aplicación de comercio
electrónico diseñada para ampliar las miras estratégicas de la organización. La orientación en esta fase es hacia la
solución de problemas de negocios. Aunque la tecnología de información y los sistemas puedan incluso impulsar
algunas de las soluciones propuestas, el enfoque siempre permanecerá en alcanzar los objetivos de negocios.
TALLER DE DISEÑO RAD Se trata de una fase de diseño y refinación que se puede caracterizar mejor como un
taller. Al imaginar un taller, usted sabe que la participación es intensa, no pasiva, y que por lo general implica
poner manos a la obra. Comúnmente, los participantes se sientan en mesas redondas o en configuración de U, con
los escritorios unidos, y cada participante puede ver a los demás y hay espacio para trabajar en una computadora
portátil. Si es lo bastante afortunado como para tener disponible una sala de sistemas de soporte de decisiones en
grupo (GDSS) en la empresa o por medio de una universidad local, úsela para realizar cuando menos parte de su
taller de diseño RAD.
Durante el taller de diseño RAD, los usuarios responden a los prototipos funcionales reales y los analistas
refinan los módulos diseñados (mediante el uso de algunas de las herramientas de software que mencionaremos
más adelante) con base en las respuestas de los usuarios. El formato del taller es muy estimulante, y si están pre-
sentes usuarios y analistas experimentados, no hay duda de que este esfuerzo creativo puede impulsar el desarro-
llo con un ritmo acelerado.
FASE DE IMPLEMENTACIÓN En la figura anterior puede ver que, durante el taller, los analistas trabajan
intensivamente con los usuarios para diseñar los aspectos de negocio o los aspectos no técnicos del sistema. Tan
pronto como se llega a un consenso sobre estos aspectos, y se crean y refinan los sistemas, se prueban los nuevos
sistemas o las nuevas partes de los mismos y después se introducen a la organización. Como RAD se puede usar
para las nuevas aplicaciones de comercio electrónico para las cuales no hay un sistema anterior, a menudo no hay
necesidad ni posibilidad de ejecutar los sistemas anterior y nuevo en paralelo antes de la implementación.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 165
Para este momento, el taller de diseño RAD debe haber generado emoción, la sensación de que los usuarios
son propietarios de la nueva aplicación y aceptación de la misma. Por lo general, el cambio que se produce de
esta forma es menos traumático que cuando un sistema se entrega y el usuario tuvo poca o nula participación.
FIGURA 6.5
Comparación entre los métodos
del taller de diseño RAD y SDLC.
Identificar objetivos
Retroalimentación
Determinar
de los usuarios
requerimientos de
información;
Trabajar con los desarrollar
Construir
usuarios para diagramas E-R
el sistema
diseñar el sistema
Analizar las
necesidades del
Usar la entrada de
sistema; desarrollar
los usuarios
DFD y repositorios
de datos
Introducir
el sistema
D
El método RA
sarrollo
permite un de
Fases de diseño, desarrollo y documentación
Diseñar el
rápido.
sistema
recomendado
Desarrollar y
documentar el
sistema
Probar el
sistema
LC
El método SD r de
permite realiza ática
manera sistemanálisis,
y cuidadosa el entación Introducir el
m
diseño y docu .
de los sistem
as sistema
www.xlibros.com
166 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
La fase del taller de diseño RAD es una desviación de las fases de diseño estándar del SDLC, debido a que
se utilizan herramientas de software RAD para generar pantallas y exhibir el flujo en general de la ejecución de
la aplicación. De esta forma, cuando los usuarios aprueban el diseño, lo hacen con base en una representación
visual del modelo y no sólo un diseño conceptual representado en papel, como es comúnmente el caso.
La fase de implementación de RAD es en muchas formas menos extenuante que otros métodos, debido a
que los usuarios ayudaron a diseñar los aspectos de negocios del sistema y están bien conscientes de los cambios que
ocurrirán. Hay pocas sorpresas y el cambio es algo que se espera con agrado. Al usar el SDLC, a menudo hay
un extenso periodo durante el desarrollo y el diseño en que los analistas están separados de los usuarios. Durante
este periodo los requerimientos pueden cambiar y tal vez los usuarios no estén conscientes de que el producto
final será distinto al que se esperaba muchos meses atrás.
CUÁNDO USAR RAD Como analista, es conveniente que aprenda sobre todas las metodologías y herramientas
que le sea posible para facilitar el proceso de hacer su trabajo de la manera más apropiada. El trabajo en algunas
aplicaciones y sistemas requerirá el uso de ciertas metodologías. Considere usar RAD cuando:
1. Su equipo incluya programadores y analistas que tengan experiencia con este método y se dé cualquiera de
las siguientes condiciones.
2. La empresa tenga motivos para presionar de manera que se pueda agilizar cierta parte del desarrollo de una
aplicación.
3. Cuando trabaje con una aplicación original de comercio electrónico y su equipo de desarrollo crea que la
empresa puede obtener una ventaja considerable frente a sus competidores por ser innovadora si esta
aplicación está entre las primeras en aparecer en Web.
4. Cuando los usuarios sean sofisticados y se involucren mucho con los objetivos organizacionales de la
empresa.
DESVENTAJAS DE RAD Al igual que con otros tipos de creación de prototipos, las dificultades con RAD surgen
debido a que los analistas de sistemas tratan de apurar demasiado el proyecto. Suponga que se contratan dos
carpinteros para construir dos cobertizos de almacenamiento para dos vecinos. El primer carpintero sigue la
filosofía del SDLC, mientras que el segundo sigue la filosofía RAD.
El primer carpintero es sistemático, hace un inventario de todas las herramientas, podadoras de césped y pie-
zas de muebles de jardín para determinar el tamaño correcto del cobertizo, diseña un plano del cobertizo y escribe
especificaciones para cada pieza de madera y accesorios de ferretería. El carpintero construye el cobertizo sin
desperdiciar muchos recursos y cuenta con documentación precisa sobre cómo construyó el cobertizo, en caso de
que alguien desee construir otro igual, repararlo o pintarlo usando el mismo color.
El segundo carpintero empieza de inmediato con el proyecto mediante una estimación del tamaño del cober-
tizo, consigue un camión lleno de madera y accesorios de ferretería, construye una estructura y habla sobre ella
con el dueño de la propiedad a medida que se hacen modificaciones cuando no hay ciertos materiales disponi-
bles, y hace un viaje para devolver la madera que no se utilizó. El cobertizo se construye con mayor rapidez, pero
si no se dibuja un plano, la documentación nunca existirá.
MODELADO ÁGIL
Los métodos ágiles son una colección de metodologías innovadoras para el desarrollo de sistemas, las cuales se
centran en los usuarios. En esta sección aprenderá sobre valores y principios, actividades, recursos, prácticas,
procesos y herramientas asociadas con las metodologías ágiles. A estos métodos se les acreditan muchos proyec-
tos exitosos de desarrollo de sistemas y en muchos casos también se les acredita el haber rescatado empresas de
un sistema fallido diseñado mediante el uso de una metodología estructurada.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 167
FIGURA 6.6
Simpleza
Los valores son imprescindibles
ón
ic aci para la metodología ágil.
un
m s
Valore
Co
ión
ágiles
ac
t
en
lim
etro a
R
Valor
Empecemos con la comunicación. En todo esfuerzo humano existe la posibilidad de una mala comunica-
ción. Los proyectos de sistemas que requieren de una constante actualización y diseño técnico son especialmente
propensos a dichos errores. Si aunamos a ello tiempos de entrega ajustados, jerga especializada y el estereotipo
de que los programadores prefieren hablar con las máquinas en vez de las personas, terminamos con el potencial de
toparnos con serios problemas de comunicación. Los proyectos pueden sufrir retrasos; se puede resolver el pro-
blema incorrecto; los programadores reciben castigo incluso hasta por llevar los problemas a los gerentes; la
gente sale o se une a mitad del proyecto sin las actualizaciones apropiadas, y la letanía continúa.
Las prácticas ágiles comunes como la programación en pareja (dos programadores que colaboran entre sí;
describiremos esta práctica más adelante en el capítulo), la estimación de tareas y la prueba de unidades depen-
den mucho de la buena comunicación. Los problemas se corrigen con rapidez, los orificios se tapan y el pensa-
miento débil se fortalece rápidamente por medio de la interacción con otros miembros del equipo.
El segundo valor de la metodología ágil es la simpleza. Cuando trabajamos en un proyecto de desarrollo de
software, nuestra primera tendencia es abrumarnos con la complejidad y tamaño de la tarea. Sin embargo, no po-
demos correr sino hasta aprender a caminar, ni podemos caminar hasta no aprender a erguirnos. La simpleza para
el desarrollo de software significa que debemos empezar con la cosa más simple que podamos hacer.
El valor ágil de la simpleza nos pide hacer la cosa más sencilla hoy, a sabiendas de que tal vez mañana ten-
gamos que cambiarla un poco. Para ello debemos estar enfocados claramente en los objetivos del proyecto, lo
cual es en realidad un valor básico.
La retroalimentación es el tercer valor básico importante cuando usamos una metodología de programa-
ción extrema. Al considerar la retroalimentación en este contexto, es bueno tener en cuenta que está implicada
con el concepto del tiempo. Una buena retroalimentación concreta que sea útil para el programador, el analista
y el cliente puede ocurrir en cuestión de segundos, minutos, días, semanas o meses, dependiendo de lo que se
requiera, de quién se esté comunicando y de lo que se pretenda hacer con la retroalimentación. Un compañero
programador podría pasarle un caso de prueba que quebrante el código que usted acaba de escribir, pero esa
retroalimentación es invaluable en términos de poder cambiar lo que no funciona antes de que se acepte y se in-
cruste en el sistema.
La retroalimentación ocurre cuando los clientes crean pruebas funcionales para todas las historias que hayan
implementado posteriormente los programadores (más adelante en el capítulo podrá ver más sobre las historias
de los usuarios). La retroalimentación crítica sobre la programación de fechas y tiempos proviene de los clientes
que comparan el objetivo del plan con el progreso realizado hasta ese momento. La retroalimentación ayuda a
los programadores a realizar ajustes y permite a la empresa empezar a experimentar con mucha antelación lo que
será el nuevo sistema una vez que sea completamente funcional.
La valentía es el cuarto valor en la programación ágil. El valor de la valentía tiene que ver con un nivel de
confianza y confort que debe existir en el equipo de desarrollo. Significa no tener miedo de desperdiciar una
tarde o un día de programación y empezar de nuevo si no todo está bien. Significa poder estar en contacto con
los instintos de uno mismo (y los resultados de prueba) en relación con lo que funciona y lo que no.
Valentía también significa responder a la retroalimentación concreta, actuando con base en las corazonadas
de sus compañeros de equipo cuando ellos piensan que tienen una forma más simple y mejor de obtener su ob-
jetivo. La valentía es un valor de alto riesgo y un gran nivel de recompensa, el cual fomenta la experimentación
que puede llevar al equipo a obtener su objetivo con más rapidez de una manera innovadora. Valentía significa que
usted y los miembros de su equipo confían entre sí y en sus clientes lo suficiente como para actuar en formas
que mejoren de manera continua lo que se está llevando a cabo en el proyecto, incluso si esto implica descartar
código, reformular las soluciones o simplificar más las metodologías. La valentía también implica que usted,
como analista de sistemas, aplique con entusiasmo las prácticas de la metodología ágil.
Los analistas pueden reflejar de una mejor forma los cuatro valores por medio de una postura de humildad.
A través de la historia, el software de computadora se desarrolló por expertos que a menudo pensaban que sabían
www.xlibros.com
168 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
cómo operar una empresa de una mejor forma que los clientes locales, que eran los verdaderos expertos. Con fre-
cuencia, a los expertos de computadora se les denominaba “gurús”. Algunos de los gurús exhibían grandes egos
e insistían en su infalibilidad, incluso cuando sus clientes no lo creían así. Muchos gurús carecían de la virtud de
la humildad.
Es imprescindible mantener una postura humilde durante el desarrollo de sistemas. Usted debe hacerse a la
idea de que si el usuario está expresando una dificultad, entonces hay que lidiar con ella. No podemos ignorarla.
Los modeladores ágiles son analistas de sistemas que hacen sugerencias, expresan opiniones pero nunca insisten
en que tienen la razón el 100 por ciento del tiempo. Los modeladores ágiles poseen la suficiente confianza en sí
mismos como para permitir que sus clientes cuestionen, critiquen y, algunas veces, se quejen sobre el sistema
que están desarrollando. Los analistas aprenden de sus clientes, quienes han estado en el negocio durante un
buen tiempo.
LOS PRINCIPIOS BÁSICOS DEL MODELADO ÁGIL En un mundo perfecto, los clientes y su equipo de desarrollo
de software se verían directamente a los ojos y no sería necesaria ninguna otra forma de comunicación. Todos
estaríamos de acuerdo en todo momento. Sabemos que el mundo ideal no existe, Pero ¿cómo podemos acercar
nuestros proyectos de desarrollo de software a ese ideal? Parte del por qué no ocurrirá esto se debe a que
hasta ahora estamos tratando de operar con base en un sistema impreciso de valores compartidos. Son un buen
principio, pero en realidad no se ponen en la práctica hasta el punto en que nos sea posible medir nuestro éxito
significativamente. Por lo tanto, trabajamos para derivar los principios básicos que pueden ayudarnos a verificar
que lo que realmente estamos haciendo en nuestro proyecto de software sea estar a la altura de los valores que
compartimos.
Los principios ágiles son reflejos y especificaciones de los valores ágiles. Sirven como lineamientos que los de-
sarrolladores pueden seguir al desarrollar sistemas. También sirve para diferenciar a las metodologías ágiles de las
metodologías más tradicionales basadas en planes como SDL, así como las metodologías orientadas a objetos.
Beck y sus colaboradores fueron los primeros en describir los principios ágiles, que han evolucionado desde
entonces. Estos principios se pueden expresar en una serie de dichos tales como:
1. Satisfacer al cliente por medio de la entrega de software funcional.
2. Adoptar el cambio, incluso si se introduce en las últimas etapas del desarrollo.
3. Seguir entregando software funcional en incrementos y con frecuencia.
4. Fomentar a los clientes y analistas a que trabajen juntos a diario.
5. Confiar en los individuos motivados para que realicen su trabajo.
6. Promover la conversación cara a cara.
7. Concentrarse en hacer que el software funcione.
8. Fomentar el desarrollo continuo, regular y sostenible.
9. Adoptar la agilidad con especial atención en un diseño lúcido.
10. Apoyar a los equipos autoorganizados.
11. Proveer retroalimentación rápida.
12. Fomentar la calidad.
13. Revisar y ajustar el comportamiento de vez en cuando.
14. Adoptar la simpleza.
Con frecuencia escuchará a los desarrolladores ágiles a medida que comunican su opinión por medio de
dichos como los antes mencionados, o incluso frases más simples tales como “modelar con un propósito”, “el
software es su objetivo primario” y “viaje ligero”, una forma de decir que es suficiente con poca documentación.
Escuche estos dichos con cuidado. En el capítulo 16 hablaremos más sobre ellos (algunos los llaman proverbios)
bajo una herramienta de análisis y documentación conocida como FOLKLORE. Las frases pegajosas son fáciles
de entender, memorizar y repetir. Son muy efectivas.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 169
compruebe si la idea era lógica. El código también se puede usar para comunicar ideas que, de otra manera,
permanecerían borrosas o deformes; cuando examine su código, tal vez incluso le surjan nuevas ideas. El código
fuente es la base de un sistema viviente. Es esencial para el desarrollo.
La prueba es la segunda actividad básica del desarrollo. La metodología ágil considera que las pruebas
automatizadas son imprescindibles. La metodología ágil aboga por la escritura de pruebas para verificar codi-
ficación, funcionalidad, rendimiento y cumplimiento. El modelado ágil se basa en las pruebas automatizadas;
existen extensas bibliotecas de pruebas para la mayoría de los lenguajes de programación. Estas pruebas necesitan
actualizarse según se requiera durante el progreso del proyecto.
Hay razones tanto de largo como de corto plazo para las pruebas. Las pruebas a corto plazo nos ofrecen
una confianza extrema sobre lo que estamos construyendo. Si las pruebas se cumplen a la perfección, podemos
continuar con una confianza renovada. A largo plazo, las pruebas mantienen vivo a un sistema y permiten rea-
lizar cambios durante un periodo más extenso del que hubiera sido posible si no se hubieran escrito o realizado
pruebas.
Escuchar es la tercera actividad básica del desarrollo. En el capítulo 4 aprendimos sobre la importancia de
escuchar durante las entrevistas. En la metodología ágil, el proceso de escuchar se lleva al extremo. Los desa-
rrolladores utilizan la escucha activa para oír a su socio de programación. En el modelado ágil hay menos de-
pendencia de la comunicación formal por escrito, por lo que escuchar se convierte en una habilidad de suma
importancia.
El desarrollador también utiliza la escucha activa con el cliente. Los desarrolladores asumen que no saben
nada sobre las empresas a las que están ayudando, por lo que deben escuchar con cuidado a los empresarios para
obtener las respuestas a sus preguntas. El desarrollador necesita llegar a comprender lo que es la escucha efec-
tiva. Si usted no escucha, no sabrá qué codificar o probar.
La cuarta actividad básica en el desarrollo es el diseño, que es una forma de crear una estructura para orga-
nizar toda la lógica en el sistema. El diseño es evolutivo, y por ende los sistemas que se diseñan mediante el mé-
todo ágil se conceptualizan como sistemas que siempre están en evolución y siempre están siendo diseñados.
A menudo es simple lograr un buen diseño. Éste debe permitir también cierto grado de flexibilidad. Diseñar
bien permite extender el sistema realizando cambios en un solo lugar. El diseño efectivo posiciona la lógica cerca
de los datos sobre los cuales va a operar. Por encima de todo, el diseño debe ser útil para todos aquellos que lo
necesiten a medida que avanza el esfuerzo de diseño, incluyendo clientes y programadores.
CUATRO VARIABLES DE CONTROL DE RECURSOS DEL MODELADO ÁGIL Es admirable completar todas las
actividades en el proyecto a tiempo y dentro de todas las restricciones pero, como probablemente habrá
averiguado para estos momentos, para lograr esto es imprescindible administrar el proyecto correctamente.
Y esto implica no sólo reunir todas las tareas y recursos; también significa que el analista sacrifique algunas
ventajas por otras. Algunas veces el costo puede estar predeterminado, mientras que otras veces el tiempo puede
llegar a ser el factor más importante. A continuación hablaremos sobre estas variables de control de recursos
(tiempo, costo, calidad y alcance).
TIEMPO Hay que asignar tiempo suficiente para completar el sistema, y entender que lo necesita para varias
actividades distintas: escuchar a los clientes, diseñar, codificar y probar.
Uno de nuestros amigos es propietario de un restaurante de comida china. Hace poco se quedó sin uno de los
miembros de su confiable equipo, quien regresó a Hong Kong para casarse. El dueño ocupó el lugar en la cocina
para que la comida se sirviera a tiempo, pero dejó de estar al frente dando la bienvenida a sus clientes de la forma
usual. Sacrificó la actividad de escucha para cumplir con otra actividad, pero en este caso se percató de que esto
dañaba su negocio. Los clientes querían la atención.
Lo mismo ocurre en el desarrollo de sistemas. Puede crear software de calidad, pero fracasar a la hora de
escuchar. Puede elaborar un diseño perfecto, pero no asignar el tiempo suficiente como para probarlo. El tiempo
es difícil de manejar. Si se agota el tiempo, ¿qué debe hacer?
El método ágil desafía la noción de que más tiempo nos dará los resultados que queremos. Tal vez el cliente
prefiera que usted termine a tiempo en vez de extender el tiempo de entrega para agregar otra característica.
A menudo descubrimos que los clientes son felices si parte de la funcionalidad está trabajando a tiempo. Nuestra
experiencia muestra que con frecuencia un cliente está un 80 por ciento satisfecho con el primer 20 por ciento
de la funcionalidad. Esto significa que cuando completemos el otro 80 por ciento del proyecto, el cliente tal vez
sólo esté un poco más feliz de lo que estaba cuando habíamos completado sólo el 20 por ciento. La moraleja aquí
es que debe tener cuidado de no extender su tiempo de entrega. El método ágil insiste en terminar a tiempo.
COSTO El costo es la segunda variable que podríamos ajustar. Suponga que las actividades de codificación,
diseño, prueba y escucha están sobrecargando el proyecto y los recursos que invertimos en el tiempo, alcance y la
www.xlibros.com
170 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
calidad no son suficientes, incluso aunque dediquemos una cantidad normal al costo para equilibrar el proyecto.
En esencia, tal vez tengamos que contribuir más recursos que requieran dinero para balancear el proyecto.
La forma más sencilla de aumentar el gasto (y por ende los costos) es contratar más personal. Esto puede
parecer la solución perfecta. Si contratamos más programadores terminaremos más rápido. ¿Cierto? No nece-
sariamente. Imagine contratar dos personas para reparar un techo y aumentar el número a cuatro. Pronto los
trabajadores estarán chocando entre sí. Lo que es más, necesitan preguntarse unos a otros qué es lo que queda
por hacer. Y si aparece una tormenta eléctrica, nadie estará trabajando. Pasar de dos a cuatro no significa que se
requerirá la mitad del tiempo. Considere el aumento requerido en la comunicación y otros costos intangibles a
la hora de decidir si va a contratar más personal. Recuerde que cuando se unen nuevos miembros a un equipo,
no conocen el proyecto ni al equipo. Van a hacer más lentos a los miembros originales debido a que éstos deben
dedicar parte del tiempo para ayudar a que los nuevos miembros se pongan al corriente.
El tiempo extra no ayuda mucho tampoco. Aumenta el costo, pero no siempre aumenta la productividad.
Los programadores cansados son menos efectivos que los programadores que se mantienen alertas, tardan mucho
tiempo en completar una tarea y también cometen errores que cuestan incluso más tiempo corregir.
¿Hay algo más en lo que podamos gastar nuestro dinero? Tal vez. A medida que lea los capítulos siguientes,
conocerá varias herramientas que ofrecen soporte para los analistas y programadores. A menudo estas herramien-
tas son una inversión sabia. Por ejemplo, los analistas utilizan paquetes gráficos tales como Microsoft Visio para
comunicar ideas sobre el proyecto a los demás, y las herramientas CASE tales como Visible Analyst también
ayudan a agilizar los proyectos.
Incluso el nuevo hardware podría ser un gasto que valga la pena. Las computadoras portátiles y los teléfo-
nos inteligentes mejoran la productividad cuando está uno alejado de la oficina. Las pantallas de mayor tamaño,
los teclados y ratones con capacidad para Bluetooth y tarjetas gráficas más potentes también pueden mejorar la
productividad.
CALIDAD La tercera variable de control de recursos es la calidad. Si los sistemas ideales son perfectos, ¿por qué
hay que poner tanto esfuerzo en dar mantenimiento a los sistemas? ¿Acaso estamos practicando ya el desarrollo
ágil al sacrificar la calidad en el desarrollo de software? En el capítulo 16 veremos la importancia de la calidad y
los métodos (como TQM y Seis Sigma) que ayudan a asegurar un alto grado de calidad en el software.
Sin embargo, la filosofía ágil permite al analista ajustar este recurso y tal vez hacer un menor esfuerzo por
mantener la calidad que si se utilizara otro método. La calidad se puede ajustar en forma externa e interna: la in-
terna involucra la prueba de software con base en factores tales como la funcionalidad (¿Qué es lo que se supone
que debe hacer un programa?) y el cumplimiento (¿Cumple el software con ciertos estándares de conformidad y
se puede mantener?). Por lo general no es redituable experimentar con la calidad interna.
Eso nos deja con la calidad externa, o la forma en que el cliente percibe el sistema. Al cliente le interesa el
rendimiento. Algunas de las preguntas que un cliente puede hacer son: ¿Actúa el programa en forma confiable
(o aún existen errores en el software)? ¿Es efectiva la salida?, ¿llega a tiempo? ¿Se ejecuta el software sin es-
fuerzo? ¿Es la interfaz de usuario fácil de comprender y usar?
En el extremo de la filosofía del desarrollo ágil es permisible sacrificar ciertas cuestiones de calidad exter-
nas. Para que el sistema se pueda liberar a tiempo, tal vez el cliente tenga que lidiar con algunos errores en el
software. Si queremos cumplir nuestro tiempo de entrega, tal vez la interfaz de usuario no sea perfecta. Podre-
mos mejorarla en una próxima versión.
Los fabricantes de software comercial de venta en canales convencionales sacrifican la calidad: podemos
debatir si es o no es la metodología correcta. Por lo tanto, no le sorprenda cuando las aplicaciones de software de
su PC (sin mencionar su sistema operativo y explorador Web) se actualicen con frecuencia, si los desarrolladores
utilizan la programación extrema como una de sus prácticas ágiles.
ALCANCE Por último tenemos el alcance. En la metodología ágil, para determinar el alcance hay que escuchar a
los clientes y hacer que escriban sus historias, que se examinan después para determinar cuánto se puede hacer
en un tiempo dado para satisfacerlos. Las historias deben ser breves y fáciles de comprender. Más adelante en
el capítulo describiremos estas historias con más detalle; mientras tanto, he aquí un breve ejemplo que muestra
cuatro historias de un sistema en línea de viajes en avión. Cada una de las historias se muestra en negrita:
Mostrar vuelos alternativos
Preparar una lista de los cinco vuelos más económicos.
Ofrecer alternativas más económicas
Sugerir a los clientes que viajen otro día, que tomen un especial de fin de semana, promociones
especiales o que utilicen otros aeropuertos alternos.
Comprar un boleto
Permitir al cliente comprar boletos directamente con una tarjeta de crédito (verificar validez).
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 171
www.xlibros.com
172 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
ora
sp
s
actividades y valores del modelado ga
tre
ágil.
En
io
sit
l
ne
og nt ee
Pr
ra mac Clie
ión en pareja
Prueba
n
ció
ca
Costo
d ifi
Co
o
mp
Tie ha
uc
Esc
d Diseño
li da
Ca
Alcanc
e
Actividades ágiles
Recursos ágiles
Simpleza
ón
aci
u nic
m
Co
n
ció
ta
en
lim
roa
Valent Ret
ía
Valores ágiles
4. Desarrollar algunos prototipos de visualización. Para ello hay que mostrar a los clientes el tipo de interfaz
que tendrán.
5. Usar la retroalimentación de los prototipos y los diagramas del flujo de trabajo lógico para desarrollar el
sistema hasta crear un modelo físico de datos.
Ágil es la otra palabra clave en el modelado ágil. Ágil implica capacidad de maniobrar. Los sistemas ac-
tuales, en especial los que están basados en Web, imponen demandas gemelas: entregar el software tan pronto
como sea posible y seguir mejorándolo para agregar nuevas características. El analista de sistemas necesita tener
la capacidad y los métodos para crear aplicaciones dinámicas, sensibles al contexto, escalables y evolutivas. El
modelado ágil como tal es un método que adopta el cambio.
ESCRIBIR LAS HISTORIAS DE LOS USUARIOS Incluso cuando el título de esta sección es “Escribir las historias
de los usuarios”, el énfasis en la creación de las historias de los usuarios está en la interacción oral entre los
desarrolladores y los usuarios, y no en la comunicación escrita. En las historias de los usuarios, el desarrollador
busca principalmente obtener de los usuarios requerimientos de negocios pertinentes. Por lo general, los usuarios
se involucran en conversaciones a diario con los desarrolladores en relación con el significado de las historias de
usuario que escribieron. Estas conversaciones frecuentes son interacciones intencionales que tienen como meta
evitar malos entendidos o malas interpretaciones en cuanto a los requerimientos de los usuarios. Por lo tanto, las
historias de usuarios sirven como recordatorios para los desarrolladores de que deben sostener conversaciones
dedicadas a esos requerimientos.
A continuación se muestra como ejemplo una serie de historias escritas para una aplicación de comercio
electrónico de un comerciante de libros, CD y demás medios. Las historias proporcionan una imagen bastante
completa de lo que se necesita en cada una de las etapas del proceso de compras, además de ser muy cortas y
fáciles de comprender. El objetivo aquí es sacar a la luz todas las necesidades y preocupaciones relacionadas con
la tienda en línea. Aunque no se puede obtener suficiente información de una historia como para empezar a pro-
gramar, un desarrollador ágil podría empezar a ver la imagen general con la suficiente claridad para empezar a
estimar lo que se requiere para completar el proyecto. Las historias son:
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 173
ATRACTIVO DE LA MAC
Así como las metodologías ágiles representan una alternativa para el SDLC, OmniFocus es una alternativa a Microsoft
Project u otros métodos para realizar gráficos de Gantt o diagramas PERT.
Un observador casual podría pensar que los métodos ágiles carecen de estructura debido a que los sistemas se
construyen sin especificar detalles ni documentación. Un estudiante de los métodos ágiles descubre que en realidad hay
un buen grado de estructura en la metodología ágil. Los principios incluyen apegarse a la semana de trabajo de 40 horas
y la coordinación por medio de la programación en parejas. Un analista que adopte las técnicas ágiles necesita una forma
de establecer los objetivos, mantenerse dentro del presupuesto, establecer prioridades para las características y averi-
guar cómo hacer las cosas.
OmniFocus se basa en un sistema alternativo de administración de tareas desarrollado por David Allen, al cual se le
conoce como Getting Things Done. Este principio primordial trata sobre liberar la mente de recordar cosas, de manera que
podamos concentrarnos en llevarlas a cabo. Un analista que utilice este sistema tiene que efectuar cinco acciones: recolec-
tar, procesar, organizar, revisar y hacer.
Los analistas de sistemas que utilicen OmniFocus tienen que recolectar elementos de su navegador Web, su libreta
de direcciones o su calendario, o de la mayoría de las aplicaciones en una Mac. El analista puede categorizar estos
elementos o asignarlos a un proyecto más grande. OmniFocus incluye un modo de planeación para que el analista pueda
ver qué tarea forma parte de un proyecto más grande, así como un modo de contexto para organizar las tareas de manera
que el analista conozca todas las tareas que haya que realizar vía telefónica, navegando en Web o mediante el correo
electrónico. OmniFocus también está disponible como aplicación para iPhone.
FIGURA 6.MAC
OmniFocus de The Omni Group.
www.xlibros.com
174 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 175
FIGURA 6.8
Las historias de los usuarios se pueden registrar en tarjetas. La historia de usuario debe ser lo bastante
breve como para que un analista pueda determinar las características de sistemas que se necesitan
sobre los detalles. Por eso el juego táctico se deja a los miembros del equipo, como si estuvieran en el campo de
juego. El equipo de sistemas trabaja dentro de un estricto periodo (30 días para el desarrollo), de igual forma que
un equipo de rugby juega dentro de un tiempo estrictamente limitado.
Podemos describir los componentes de la metodología de scrum así:
1. Acumulación (backlog) de productos, en donde se deriva una lista a partir de las especificaciones de los
productos.
2. Acumulación de corrida (sprint), una lista que cambia en forma dinámica sobre las tareas que se van a
completar en la siguiente corrida.
3. Corrida, un periodo de 30 días en donde el equipo de desarrollo transforma la acumulación en software que
se puede demostrar.
4. Scrum diaria, una reunión breve en donde la comunicación es la regla número uno. Los miembros del equipo
necesitan explicar lo que hicieron desde la última reunión, si se toparon con obstáculos y lo que planean
hacer antes de la siguiente scrum diaria.
5. Demo, software funcional que se puede demostrar al cliente.
Sin duda, scrum es una metodología de alta intensidad, y es sólo una de las filosofías que el modelado ágil
adopta.
www.xlibros.com
176 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 6.9
Hay seis lecciones vitales que se
pueden aprender de la metodología Las entregas
ágil para los sistemas. pequeñas permiten a
los sistemas
evolucionar
Lecciones que se
obtienen al adoptar
los métodos ágiles
La semana de trabajo
de 40 horas mejora
la efectividad
una buena comunicación, lograr identificarse con el cliente, enfocarse en los aspectos más valiosos del proyecto
primero, evaluar todo el código a medida que se desarrolla e integrar el nuevo código una vez que pase las pruebas
con éxito.
La tercera lección es que los clientes en el sitio son benéficos tanto para la empresa como para el equipo de
desarrollo ágil. Los clientes actúan como una referencia preparada y una comprobación de la realidad; además
siempre se mantiene el enfoque del diseño del sistema a través de su presencia: los clientes se hacen más pareci-
dos a los desarrolladores y éstos se identifican mejor con los clientes.
La cuarta lección es que la semana de trabajo de 40 horas mejora la efectividad. Incluso los desarrolladores
más resistentes son susceptibles a errores y agotamiento si trabajan demasiado por un periodo muy extenso. Sin
embargo, cuando el equipo de desarrollo está unido, cada momento cuenta. Es mucho más conveniente trabajar a
un ritmo sostenible durante la vida del proyecto, la vida del sistema y ¡la vida del trabajador! Todos conocemos
la parábola de la liebre y la tortuga.
La quinta lección que obtenemos de la metodología ágil es que los recursos y las actividades equilibradas
apoyan los objetivos del proyecto. Administrar un proyecto no significa sólo reunir todos los recursos y tareas.
También significa que el analista tiene que lidiar con varias concesiones. Algunas veces el costo puede estar
predeterminado, mientras que otras veces el tiempo puede llegar a ser el factor más importante. Las variables de
control de recursos de tiempo, costo, calidad y alcance necesitan estar balanceadas en forma apropiada con las
actividades de codificación, diseño, prueba y escucha.
La última lección que obtenemos de las metodologías de modelado ágil es que los valores ágiles son impres-
cindibles para el éxito. Es esencial para el éxito en general del proyecto que los analistas adopten sin reservas
los valores de comunicación, simpleza, retroalimentación y valentía en todo el trabajo que realicen. Este tipo de
compromiso personal y con el equipo permite al analista triunfar en donde fracasarán otros que posean compe-
tencias técnicas similares pero carezcan de los valores. La verdadera dedicación a estos valores es fundamental
para un desarrollo exitoso.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 177
Mejorar la eficiencia en el trabajo del conocimiento: comparación entre SDLC y el método ágil
Los investigadores (Davis y Naumann, 1999) desarrollaron una lista de siete estrategias que pueden mejorar la
eficiencia del trabajo del conocimiento: reducir el tiempo y los errores de la interfaz; reducir el tiempo de apren-
dizaje del proceso y las pérdidas duales de procesamiento; reducir el tiempo y esfuerzo requeridos para estruc-
turar tareas y aplicar formato a las salidas; reducir la expansión improductiva del trabajo; reducir la búsqueda de
datos y de conocimiento, junto con el tiempo de almacenamiento y los costos; reducir la comunicación, el tiempo
de coordinación y los costos; y reducir las pérdidas debido a la sobrecarga humana de información. Ellos creen
que esto es importante, ya que con base en el estudio que hicieron de un grupo de programadores, afirman que
los mejores programadores son de cinco a diez veces más productivos que los peores. Además señalan que esta
proporción es sólo de dos a uno para los trabajadores que desempeñan labores de oficina o físicas. Su sugerencia
es que el software puede ayudar a mejorar muchas situaciones.
Utilizamos la metodología estándar y tradicional de desarrollo de sistemas de los métodos estructurados para
comparar y contrastar la forma en que las metodologías estructuradas y las metodologías ágiles implementarían
las siete estrategias propuestas para mejorar la eficiencia de los trabajadores del conocimiento.
Aunque el hecho de adoptar más software puede en definitiva mejorar también el rendimiento, es razonable
sugerir que si cambiamos una metodología también podría mejorar el rendimiento. En consecuencia examinare-
mos minuciosamente cada aspecto de la productividad del trabajo del conocimiento, tanto de las metodologías
estructuradas como de las ágiles. La figura 6.10 muestra una lista de las siete estrategias originales para mejorar
la productividad y después explica qué métodos se utilizan para mejorar la eficiencia del desarrollo de sistemas,
tanto para las metodologías ágiles como para las estructuradas.
En las siguientes secciones compararemos y contrastaremos las metodologías estructuradas con la meto-
dología ágil. Una observación primordial sobre la metodología ágil es que es una metodología orientada a los
humanos que permite a las personas crear soluciones matizadas que son imposibles de crear por medio de espe-
cificaciones formales de proceso.
REDUCCIÓN DE LOS TIEMPOS Y ERRORES DE LA INTERFAZ Los analistas de sistemas y los programadores
necesitan analizar, diseñar y desarrollar sistemas mediante el uso de herramientas de trabajo que varían desde
Microsoft office hasta herramientas CASE, que son costosas y sofisticadas. También necesitan realizar la
documentación a medida que desarrollan sistemas. Es importante que los analistas y los programadores sean
capaces de comprender la interfaz que utilizan. Necesitan saber cómo clasificar, codificar, almacenar y escribir
sobre los datos que recopilan. Los desarrolladores de sistemas también necesitan acceder con rapidez a un
programa, escribir la información requerida y recuperarla cuando la necesiten de nuevo.
FIGURA 6.10
Cómo se pueden implementar las estrategias de Davis y Naumann para mejorar la
eficiencia mediante el uso de dos metodologías de desarrollo distintas.
Reducir el tiempo y los errores de Adoptar estándares organizacionales para Adoptar la programación
la interfaz codificar, asignar nombres, etc.; usar formularios en pareja
Reducir el tiempo de aprendizaje del Administrar las entregas de las actualizaciones, Creación de prototipos
proceso y las pérdidas duales de para que el usuario no tenga que aprender y ad hoc y desarrollo
procesamiento usar el software al mismo tiempo rápido
Reducir el tiempo y esfuerzo requeridos Usar herramientas y diagramas CASE; usar Fomentar las entregas
para estructurar las tareas y aplicar código escrito por otros programadores pequeñas
formato a las salidas
Reducir la expansión improductiva Administración del proyecto; establecer Limitar el alcance en
del trabajo tiempos de entrega cada entrega
Reducir el tiempo y costos del Usar técnicas estructuradas de recopilación Permitir un cliente en
almacenamiento, la investigación de de datos, como las entrevistas, la el sitio
datos y del conocimiento observación y el muestreo
Reducir el tiempo y costos de Separar los proyectos en tareas más Usar cajas de tiempo
la comunicación y la coordinación pequeñas; establecer barreras (timeboxing)
Reducir las pérdidas debido a la Aplicar técnicas de filtrado para proteger Apegarse a una semana
sobrecarga humana de información a los analistas y programadores de trabajo de 40 horas
www.xlibros.com
178 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Las metodologías estructuradas fomentan la adopción de estándares para todo. Las reglas establecidas in-
cluyen elementos como. “Todos deben usar Microsoft Word en vez de Word Perfect”. Puede haber instrucciones
más detalladas para asegurar datos limpios tales como: “Use siempre M para Masculino y F para Femenino”, con
lo cual se asegura que los analistas no seleccionen sus propios códigos sin estandarizar, como 0 para Masculino
y 1 para Femenino. Así, estas reglas se convierten en parte del repositorio de datos. Los formularios también
son útiles, pues requieren que todo el personal documente sus procedimientos de manera que otro programador
pueda hacerse cargo si es necesario.
En una metodología ágil, los formularios y procedimientos funcionan bien también, pero se añade otro ele-
mento. La práctica adicional de la programación en pareja asegura que un programador verificará el trabajo del
otro, con lo cual se reduce el número de errores. Programar en pareja significa que se comparte la autoría del diseño
o del mismo software como una sociedad. Ambos socios (en donde por lo general uno de ellos es programador, a
menudo experimentado) dirán que eligieron un socio de programación que deseara tener un producto de calidad
libre de errores. Como trabajan dos personas en el mismo diseño y código, el tiempo de la interfaz no representa
un problema; es una parte integral del proceso. Los autores han observado que los programadores son bastante
emotivos cuando se menciona el tema de la programación en pareja.
REDUCIR EL TIEMPO DE APRENDIZAJE DEL PROCESO Y LAS PÉRDIDAS DUALES DE PROCESAMIENTO Los analistas
y los programadores aprenden técnicas específicas y lenguajes de software requeridos para completar un
proyecto actual. A menudo se producen ineficiencias cuando algunos analistas y programadores ya conocen los
productos que se van a utilizar, mientras que otros aún necesitan aprender a usarlos. Por lo general pedimos que
los desarrolladores aprendan a usar estos productos al mismo tiempo que los utilizan para construir el sistema.
Esta capacitación en el trabajo ralentiza de manera considerable el proyecto de desarrollo de sistemas en su
totalidad.
Un proyecto tradicional y estructurado requiere más aprendizaje. Si se utilizaran herramientas CASE, un
analista tendría que aprender a usar las herramientas CASE propietarias que se utilizan en la organización. Lo
mismo se aplica al uso de un lenguaje de computadora específico. La documentación también es una cuestión
importante.
Mediante el uso de una filosofía ágil, la habilidad de lanzar proyectos sin usar herramientas CASE y docu-
mentación detallada permite a los analistas y programadores invertir la mayor parte de su tiempo en el desarrollo
del sistema, en vez aprender a usar herramientas específicas.
REDUCCIÓN DEL TIEMPO Y ESFUERZO REQUERIDOS PARA ESTRUCTURAR TAREAS Y APLICAR FORMATO A LAS
SALIDAS Cada vez que un proyecto se inicia, los desarrolladores necesitan determinar los límites. En otras
palabras, necesitan saber cuál será el producto entregable y cómo organizarán el proyecto de manera que puedan
completar todas las tareas necesarias.
Una metodología tradicional incluiría el uso de herramientas CASE, dibujar diagramas (como los diagramas
E-R y los de flujo de datos), usar software de administración de proyectos (como Microsoft Project), descripcio-
nes de trabajo muy detalladas, usar y reutilizar formularios y plantillas, y reutilizar el código escrito por otros
programadores.
El desarrollo de sistemas mediante una metodología ágil hace frente a la necesidad de estructurar tareas me-
diante la programación de entregas pequeñas. La filosofía ágil sugiere que los desarrolladores de sistemas deben
crear una serie de tiempos de entrega para muchas versiones del sistema. Las primeras entregas poseerán menos
características pero, en cada nueva entrega se agregarán características adicionales.
REDUCCIÓN DE LA EXPANSIÓN IMPRODUCTIVA DEL TRABAJO La ley de Parkinson establece que “el trabajo se
expande para poder llenar el tiempo disponible para completarlo”. Si no hay tiempos de entrega específicos, es
posible que el trabajo del conocimiento continúe su expansión.
Con las metodologías estructuradas tradicionales, al principio los tiempos de entrega parecen estar muy
alejados hacia el futuro. Los analistas pueden utilizar técnicas de administración de proyectos para tratar de pro-
gramar las actividades, pero hay una predisposición integrada en cuanto a extender las primeras tareas más de lo
necesario y después tratar de acortarlas en una etapa posterior del desarrollo. Los analistas y los programadores
se preocupan menos por los tiempos de entrega distantes que por los que ya están próximos.
Una vez más, la metodología ágil hace énfasis en las entregas pequeñas. Se pueden entregar versiones en
el tiempo prometido, tal vez con menos de las características que se prometieron en un principio. Al considerar
todos los tiempos de entrega inminentes se destaca una expectativa realista en cuanto a la terminación (cuando
menos parcial) del proyecto.
REDUCCIÓN DEL TIEMPO Y COSTOS DE ALMACENAMIENTO Y DE LA INVESTIGACIÓN DE LOS DATOS Y DEL
CONOCIMIENTO Los desarrolladores de sistemas necesitan recopilar información sobre la organización, los
objetivos, las prioridades y los detalles acerca de los sistemas de información actuales antes de proceder con el
desarrollo de un nuevo sistema. Los métodos de recopilación de datos incluyen las entrevistas, la administración de
cuestionarios, la observación y la investigación mediante el análisis de los informes y memos.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 179
Las metodologías estructuradas fomentan los métodos estructurados de recopilación de datos. Por lo gene-
ral se utilizan técnicas estructuradas para estructurar las entrevistas y diseñar el proceso de las mismas. Hay que
desarrollar los cuestionarios de una manera estructurada; además las técnicas observacionales estructuradas tales
como STROBE podrán animar al analista a observar de manera específica los elementos clave para formar con-
clusiones con base en las observaciones del entorno físico. Se determinaría un plan de muestreo en forma cuanti-
tativa, para que el analista de sistemas pudiera seleccionar los informes y memos que va a examinar.
Las búsquedas de conocimiento son menos estructuradas en el entorno del modelado ágil. La práctica de
tener un cliente en el sitio mejora en forma considerable el acceso a la información. El cliente en el sitio está
presente para responder preguntas sobre la misma organización, sus objetivos, las prioridades de sus miembros
y cualquier conocimiento necesario sobre los sistemas de información existentes. A medida que el proyecto
avanza, se hace más clara la imagen de los requerimientos del cliente. Esta metodología parece estar libre de
errores ya que, cuando los desarrolladores de sistemas desean saber algo, simplemente tienen que preguntar. Sin
embargo, la desventaja es que el representante en el sitio tal vez invente información si no la conoce o si no está
a su disposición, o tal vez evite decir la verdad por algún otro motivo oculto.
REDUCCIÓN DE LOS TIEMPOS Y COSTOS DE LA COMUNICACIÓN Y LA COORDINACIÓN La comunicación entre
analistas y usuarios, así como entre los mismos analistas, es la base del desarrollo de sistemas. Sin duda una
mala comunicación es la raíz de múltiples problemas de desarrollo. Sabemos que la comunicación aumenta
cuando se unen más personas al proyecto. Cuando dos personas trabajan en un proyecto, existe la oportunidad de
entablar una conversación cara a cara; cuando hay tres involucradas, hay tres posibilidades; cuando hay cuatro,
hay seis posibilidades y así sucesivamente. Los miembros inexpertos del equipo necesitan tiempo para ponerse al
corriente y pueden ralentizar un proyecto incluso aunque traten de ayudar a agilizarlo.
El desarrollo estructurado tradicional fomenta la separación de tareas extensas en tareas más pequeñas. Esto
permite que haya grupos más unidos y reduce el tiempo que se invierte en la comunicación. Otra metodología im-
plica establecer barreras. Por ejemplo, tal vez los clientes no tengan acceso a los programadores. Ésta es una prác-
tica común en muchas industrias. Sin embargo, un aumento en la eficiencia a menudo implica una reducción en la
eficacia, y se ha descubierto que al dividir grupos y establecer barreras se introducen errores con frecuencia.
Por otra parte, los métodos ágiles limitan el tiempo en vez de las tareas. En las metodologías ágiles se utiliza
el concepto de cajas de tiempo (timeboxing) para fomentar la terminación de actividades en periodos más cortos.
Usar una caja de tiempo es simplemente establecer un límite de tiempo de una o dos semanas para completar una
característica o módulo. Scrum, del método ágil, impone una prima sobre el tiempo, mientras que los desarrolla-
dores se comunican de manera efectiva como equipo. Como la comunicación es uno de los cuatro valores de la
filosofía ágil, los costos de comunicación tienden a aumentar en vez de disminuir.
REDUCCIÓN DE LAS PÉRDIDAS DEBIDO A LA SOBRECARGA HUMANA DE INFORMACIÓN Desde hace tiempo
sabemos que las personas no reaccionan bien en situaciones de sobrecarga de información. Cuando los teléfonos
eran una tecnología emergente, los operadores de los conmutadores conectaban en forma manual las llamadas
entre dos partes. Se llegó a demostrar que este sistema funcionaría hasta que ocurriera una sobrecarga de
información, punto en el cual todo el sistema fallaba. Cuando llegaban demasiadas llamadas, el abrumado
operador del conmutador simplemente dejaba de trabajar y se rehusaba a realizar las conexiones. Una situación
de sobrecarga parecida le puede ocurrir a cualquier persona en cualquier momento, incluyendo a los analistas de
sistemas y a los programadores.
Una metodología tradicional sería tratar de filtrar información para proteger a los analistas y programadores
de las quejas de los clientes. Esta metodología permite a los desarrolladores seguir trabajando en el problema sin
la interferencia y subjetividad que existirían en una situación normal.
Mediante el uso de una filosofía ágil, los analistas y programadores se deben apegar a una semana de trabajo
de 40 horas. Algunos podrían ver esto como una práctica cuestionable. ¿Podrán terminar alguna vez con todo el
trabajo? No obstante, la filosofía ágil establece que el trabajo de calidad se realiza por lo general durante un ho-
rario de rutina, y es sólo al momento de agregar tiempo extra cuando entran a la escena los problemas de diseño
y programación de mala calidad. Al apegarse a un programa de una semana de trabajo de 40 horas, la metodolo-
gía ágil afirma que en un momento dado usted saldrá adelante.
www.xlibros.com
180 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
FIGURA 6.11
Para adoptar nuevos sistemas de
información hay que buscar el
Cultura de
equilibrio entre varios riesgos.
la organización
Derechos
Sincronización
individuales
Riesgos
inherentes a la
innovación
organizacional
Medición del
Costo
impacto
Reacciones de
los clientes
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 181
métodos requeridos por la metodología ágil también son una consideración clave. Algunos clientes reaccionan de
manera alegre una vez que se les describen los beneficios de la conveniencia en tiempo y la participación. Otros
no quieren que los utilicen para los “experimentos” de sistemas con resultados inciertos. La relación entre cliente
y analista debe ser lo bastante elástica como para absorber y adaptarse a los cambios en los comportamientos
esperados. Por ejemplo, la presencia de un cliente en el sitio durante el desarrollo es un compromiso importante,
por lo que las personas que piensen adoptar metodologías ágiles deben comprenderlo con claridad y estar
completamente de acuerdo.
MEDICIÓN DEL IMPACTO Otra consideración para las organizaciones que adoptan metodologías ágiles es cómo
certificar y medir que los nuevos métodos van a facilitar el desarrollo exitoso de sistemas. Las fortalezas y
debilidades de los métodos estructurados tradicionales que se utilizan para desarrollar sistemas de información
son muy conocidas.
Aunque hay mucha evidencia anecdótica para establecer que las metodologías ágiles son superiores para el
desarrollo bajo ciertas condiciones, su historial es corto y aún no se cuenta con soporte empírico. Por lo tanto, la
adopción de metodologías ágiles conlleva el riesgo de que los sistemas creados con este tipo de metodologías no
sean exitosos, o que no se puedan interconectar en forma adecuada con los sistemas heredados. Ha empezado el
proceso de medir el impacto en cuanto al uso de las metodologías ágiles, pero las organizaciones necesitan estar
alertas al proponer las mediciones del impacto junto con la adopción de nuevos métodos.
LOS DERECHOS INDIVIDUALES DE LOS PROGRAMADORES/ANALISTAS Los desarrolladores (analistas y programa-
dores) de sistemas exitosos ejercen creatividad en cuanto a la forma de llevar a cabo su trabajo, por lo cual
merecen el derecho de trabajar en la configuración más fructífera posible. Es posible que los requerimientos de
trabajo de los nuevos métodos ágiles (por ejemplo, la programación en pareja) vayan en detrimento de ciertos
derechos básicos de las personas creativas de trabajar por su cuenta o en grupos, según lo que dicte el trabajo
de diseño. No hay una “mejor manera” de diseñar un sistema, módulo, interfaz, formulario o página Web. En el
caso de los desarrolladores de sistemas, hay que comparar la creatividad, la subjetividad y el derecho de lograr
los objetivos de diseño por medio de numerosas rutas individuales con las metodologías innovadoras que adopta
la organización, como las metodologías ágiles.
Como podemos ver, la adopción de innovaciones organizacionales es un proceso que impone muchos ries-
gos tanto para la organización como para los individuos. Aquí examinamos los riesgos para la organización en
general, así como los riesgos que corre el analista de sistemas individual que se ve atrapado en el deseo de la
organización de innovar.
RESUMEN
La creación de prototipos es una técnica de recopilación de tos con tres fases: planeación de requerimientos, taller de diseño
información útil para complementar el SDLC tradicional; tanto RAD e implementación.
los métodos ágiles como la interacción humano-computadora El modelado ágil es una metodología de desarrollo de soft-
comparten sus raíces en los prototipos. Cuando los analistas de ware que define un plan general con rapidez, desarrolla y entrega
sistemas utilizan prototipos buscan reacciones de los usuarios, el software rápidamente y después revisa el software en forma
sugerencias, innovaciones y planes de revisión para realizar continua para agregar características adicionales. Los valores
mejoras al prototipo y por ende modificar los planes del sistema de la metodología ágil que comparten tanto el cliente como el
con un mínimo de costo y de interrupciones. Los cuatro linea- equipo de desarrollo son comunicación, simpleza, retroalimenta-
mientos principales para desarrollar un prototipo son: 1) trabajar ción y valentía. Las actividades ágiles son codificación, prueba,
en módulos administrables, 2) crear el prototipo con rapidez, escucha y diseño. Los recursos disponibles son tiempo, costo,
3) modificar el prototipo y 4) hacer énfasis en la interfaz de usuario. calidad y alcance.
Aunque no siempre es necesario o conveniente usar prototi- Las prácticas ágiles diferencian a los métodos ágiles, in-
pos, hay que tener en cuenta que existen tres ventajas principales cluyendo un tipo de método ágil conocido como programación
interrelacionadas en cuanto a su uso: 1) el potencial de cambiar extrema (XP), de los otros procesos de desarrollo de sistemas.
el sistema durante las primeras etapas de su desarrollo, 2) la Las cuatro prácticas básicas de la metodología ágil son 1) entre-
oportunidad de detener el desarrollo en un sistema que no está gas pequeñas, 2) semana de trabajo de 40 horas, 3) cliente en el
funcionando y 3) la posibilidad de desarrollar un sistema que sitio y 4) programación en pareja. El proceso de desarrollo ágil
se acerque más a las necesidades y expectativas de los usuarios. incluye elegir una tarea que esté directamente relacionada con
Éstos tienen que desempeñar un papel definido en el proceso de una de las características deseadas del cliente con base en las his-
creación de prototipos, por lo que los analistas de sistemas deben torias de usuarios, elegir un socio de programación, seleccionar y
trabajar en forma sistemática para obtener y evaluar las reaccio- escribir los casos de prueba apropiados, escribir el código, ejecu-
nes de los usuarios en relación con el prototipo. tar los casos de prueba, depurar el código hasta que se ejecuten
Un uso específico de los prototipos es el desarrollo rápido de todos los casos de prueba, implementarlo con el diseño existente
aplicaciones (RAD). Ésta es una metodología orientada a obje- e integrarlo a lo que ya existe.
www.xlibros.com
182 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
E X P E R I E N C I A D E H Y P E R C A S E® 6
FIGURA 6.HC1
Una de las diversas pantallas de prototipos que se incluyen en HyperCase.
En las últimas secciones de este capítulo comparamos sincronización del proyecto, el costo de la capacitación para los
cómo las metodologías SDLC y ágil manejan el proceso de analistas de sistemas, las reacciones desfavorables de los clien-
mejorar la eficiencia en el trabajo del conocimiento de una tes en cuanto a las nuevas expectativas de comportamiento, las
manera distinta. Después vimos varios peligros inherentes para dificultades para medir el impacto y la posibilidad de compro-
las organizaciones que adoptan metodologías innovadoras, in- meter los derechos creativos individuales de los programadores
cluyendo una cultura organizacional incompatible, una mala y analistas.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 183
PREGUNTAS DE REPASO
1. ¿Cuáles son los cuatro tipos de información que busca el analista por medio de la creación de prototipos?
2. ¿Qué significa el término prototipo de parches?
3. Defina un prototipo que sea un modelo a escala no funcional.
4. Dé un ejemplo de un prototipo que sea un primer modelo a escala completa.
5. Defina lo que significa un prototipo que es un modelo con ciertas características esenciales, pero no todas.
6. Haga una lista de las ventajas y desventajas de usar prototipos para sustituir el SDLC tradicional.
7. Describa cómo se pueden usar los prototipos para mejorar el SDLC tradicional.
8. ¿Cuáles son los criterios para decidir si debemos crear el prototipo de un sistema?
9. Haga una lista de los cuatro lineamientos que debe observar el analista al desarrollar un prototipo.
10. ¿Cuáles son los dos principales problemas implicados en la creación de prototipos?
11. Haga una lista de las tres principales ventajas de usar prototipos.
12. ¿Cómo puede un prototipo montado en un sitio Web interactivo facilitar el proceso de creación del mismo? Responda en
un párrafo.
13. ¿Cuáles son las tres formas en que puede ayudar un usuario en el proceso de creación del prototipo?
14. Defina lo que significa RAD.
15. ¿Cuáles son las tres fases del RAD?
16. ¿Cuáles son los cuatro valores que deben compartir el equipo de desarrollo y los clientes de la empresa al utilizar una
metodología ágil?
17. ¿Qué son los principios ágiles? Mencione cinco ejemplos.
18. ¿Cuáles son las cuatro prácticas básicas de la metodología ágil?
19. Mencione las cuatro variables de control de recursos que se utilizan en la metodología ágil.
20. Describa los pasos comunes en un episodio de desarrollo ágil.
21. ¿Qué es una historia de usuario? ¿Debe ser escrita o hablada? Indique su opción y después defienda su respuesta con un
ejemplo.
22. Haga una lista de las herramientas de software que pueden ayudar al desarrollador a realizar una variedad de pruebas de
código.
23. ¿Qué es la scrum?
24. Nombre las siete estrategias para mejorar la eficiencia en el trabajo del conocimiento.
25. Identifique seis riesgos al adoptar una innovación organizacional.
PROBLEMAS
1. Como parte de un proyecto grande de sistemas, el banco Clone Bank de Clone, Colorado, quiere que usted los ayude a
establecer un nuevo formulario de informes mensual para sus clientes de las cuentas de cheques y de ahorros. El
presidente y vicepresidente están muy de acuerdo con lo que dicen los clientes en la comunidad: piensan que sus clientes
desean un resumen de su cuenta de cheques que se parezca al que ofrecen los otros tres bancos de la ciudad. Sin
embargo, no están dispuestos a comprometerse a realizar ese formulario sin un resumen formal de retroalimentación de
los clientes que respalde su decisión. La retroalimentación no se utilizará para cambiar el prototipo del formulario de
ninguna manera. Ellos quieren que usted envíe un prototipo de un formulario a un grupo y que envíe el formulario
anterior a otro grupo.
a. En un párrafo describa por qué tal vez no valga la pena crear un prototipo del nuevo formulario bajo estas
circunstancias.
b. En un segundo párrafo describa una situación en la que sería conveniente crear un prototipo de un nuevo formulario.
www.xlibros.com
184 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
2. C. N. Itall ha sido analista de sistemas para la empresa Tun-L Vision Corporation durante muchos años. Cuando usted
llegó para formar parte del equipo de análisis de sistemas y sugirió la creación de prototipos como parte del SDLC para
un proyecto actual, C.N. dijo: “Seguro, pero no puedes poner atención a lo que dicen los usuarios. No tienen idea de lo
que quieren. Voy a crear el prototipo, pero no voy a ‘observar’ a los usuarios”.
a. Con el mayor tacto posible para no molestar a C. N. Itall, haga una lista de las razones que respaldan la importancia
de observar las reacciones de los usuarios, las sugerencias y las innovaciones en el proceso de creación del prototipo.
b. En un párrafo describa qué podría ocurrir si se crea el prototipo de una parte de un sistema y no se incorpora
retroalimentación de los usuarios al sistema sucesivo.
3. “Cada vez que creo que he terminado de capturar los requerimientos de información de los usuarios, ya cambiaron de
nuevo. Es como tratar de pegarle a un objetivo móvil. Creo que, la mitad del tiempo, ni ellos mismos saben lo que
quieren”, exclama Flo Chart, analista de sistemas para 2 Good 2 Be True, una empresa que realiza encuestas sobre el uso
de los productos para las divisiones de marketing de varias empresas de manufactura.
a. En un párrafo explique a Flo Chart cómo le pueden ayudar los prototipos para definir mejor los requerimientos de
información de los usuarios.
b. En un párrafo comente acerca de la observación de Flo: “Creo que, la mitad del tiempo, ni ellos mismos saben lo
que quieren”. Asegúrese de explicar cómo pueden los prototipos ayudar a que los usuarios comprendan mejor y
articulen sus propios requerimientos de información.
c. Sugiera cómo podría un prototipo integrado en un sitio Web interactivo resolver las preocupaciones de Flo acerca de
cómo capturar los requerimientos de información de los usuarios. Use un párrafo.
4. Harold, gerente de distrito para la cadena de varias tiendas de nombre Sprocket’s Gifts, piensa que construir un prototipo
sólo puede significar una cosa: un modelo a escala no funcional. También cree que este método es demasiado torpe para
crear prototipos de sistemas de información y por lo tanto se rehúsa a usarlo.
a. Haga una breve comparación (en dos o tres párrafos) y contraste los otros tres tipos de creación de prototipos
posibles, de manera que Harold pueda comprender bien lo que significa la creación de un prototipo.
b. Harold tiene la opción de implementar un sistema, probarlo y después instalarlo en otras cinco ubicaciones de
Sprocket si tiene éxito. Nombre un tipo de prototipo que se ajustaría bien a esta metodología; defienda su elección
en un párrafo.
5. “¡He tenido la idea del siglo!” proclama Bea Kwicke, un nuevo analista de sistemas en el grupo de sistemas que usted
dirige. “Saltemos toda esta basura del SDLC y hagamos un prototipo de todo. Nuestros proyectos avanzarán más rápido,
ahorraremos tiempo y dinero, y todos los usuarios se sentirán como si les pusiéramos atención en vez de alejarnos por
meses sin hablarles”.
a. Haga una lista de las razones que usted (como miembro del mismo equipo que Bea) daría a Bea para persuadirla de
desechar el SDLC y crear un prototipo de cada proyecto.
b. Bea está muy decepcionada con lo que usted dijo. Para animarla, use un párrafo para explicar las situaciones que
usted considere que se presten para crear un prototipo.
6. El siguiente comentario se escuchó en una reunión entre los gerentes y el equipo de análisis de sistemas en la empresa
de mallas y cercas Fence-Me-In: “Ustedes nos dijeron que el prototipo estaría terminado hace tres semanas. ¡Todavía lo
estamos esperando!”.
a. Comente en un párrafo sobre la importancia de la entrega rápida del prototipo de una parte de un sistema de
información.
b. Haga una lista de los tres elementos del proceso de creación de prototipos que haya que controlar para asegurar una
entrega oportuna del prototipo.
c. ¿Cuáles son algunos elementos del proceso de creación de prototipos que sean difíciles de manejar? Haga una lista.
7. Prepare una lista de actividades a realizar por un equipo de desarrollo de sistemas para un agente de viajes en línea que
quiere establecer un sitio Web para sus clientes. Ahora suponga que se le acaba el tiempo. Describa algunas de sus
opciones. Describa las concesiones que tendrá qué realizar para poder entregar el sitio Web a tiempo.
8. Dada la situación para los chocolates de WilliWonk’s (problema 1 en el capítulo 3), ¿cuáles de las cuatro variables de
recursos de modelado ágil se pueden ajustar?
9. Examine la colección de historias de usuarios del comerciante en línea que aparece anteriormente en el capítulo. A la
tienda de medios en línea le gustaría ahora que usted agregara algunas características a su sitio Web. Con base en el
formato que se mostró anteriormente en este capítulo en la figura 6.9, escriba una historia de usuario para las
características que se enlistan a continuación:
a. Incluir anuncios desplegables.
b. Ofrecer al cliente la posibilidad de compartir con sus amigos los detalles de sus compras.
c. Extender la oferta de comprar otros artículos.
10. Vaya al sitio Web de herramientas de Palm en www.palmgear.com. Explore el sitio Web y escriba una docena de
historias de usuario breves para mejorar el sitio Web.
11. Vaya al sitio Web de iTunes y escriba una docena de historias de usuario breves para mejorar el sitio Web.
12. Use las historias que escribió para el problema 9; recorra las cinco etapas del proceso de desarrollo ágil y describa lo que
ocurre en cada una de las etapas.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 185
PROYECTOS EN GRUPO
1. Divida a su grupo en dos subgrupos más pequeños. Haga que el grupo 1 siga los procesos especificados en este capítulo
para crear prototipos. Mediante el uso de una herramienta CASE o un procesador de texto, el grupo 1 debe idear dos
pantallas para un prototipo no operacional en las que utilice la información recolectada en las entrevistas con los
empleados de Maverick Transport que se realizaron en el ejercicio en grupo del capítulo 4. Haga todas las suposiciones
necesarias para crear dos pantallas para los despachadores de camiones. El grupo 2 (que representará a los
despachadores) debe reaccionar a las pantallas del prototipo y proveer retroalimentación sobre los elementos que desean
agregar y los que desean quitar.
2. Los miembros del grupo 1 deberían revisar las pantallas del prototipo con base en los comentarios que recibieron de los
usuarios. Los del grupo 2 deberán responder con comentarios sobre qué tan bien se resolvieron las cuestiones iniciales
con los prototipos refinados.
3. Como grupo unido, escriba un párrafo en el que describa sus experiencias con la creación de prototipos para obtener los
requerimientos de información.
4. Dentro de su grupo, asigne uno de los roles que desempeñan las personas en el desarrollo ágil. Asegúrese de que una
persona sea un cliente en el sitio y que por lo menos dos personas sean programadores. Asigne otros roles, según le parezca
apropiado. Simule la situación de desarrollo de sistemas que describimos en el problema 7, o haga que la persona que
actúe como cliente en el sitio seleccione una empresa de comercio electrónico que le sea familiar. Suponga que el cliente
desea agregar cierta funcionalidad a su sitio Web. Monte una escena en la que muestre lo que haría cada persona si esto
se fuera a manejar con los métodos ágiles. Escriba un párrafo en el que describa las restricciones a las que se enfrenta
cada persona en cuanto a desempeñar su papel.
BIBLIOGRAFÍA SELECCIONADA
Alavi, M. “An Assessment of the Prototyping Approach to Information Systems Development”. Communications of the ACM,
Vol. 27, Núm. 6, junio 1984, pp. 556-563.
Avison, D. y D. N. Wilson. “Controls for Effective Prototyping”. Journal of Management Systems, Vol. 3, Núm. 1, 1991.
Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley Publishing Co., 2000.
Beck, K y M. Fowler. Planning Extreme Programming. Boston: Addison-Wesley Publishing Co., 2001.
Cockburn, A. Agile Software Development. Boston: Addison-Wesley Publishing Co., 2002.
Davis, G. B. y J. D. Naumann. “Knowledge Work Productivity”. En Emerging Information Technologies: Improving Decisions,
Cooperation, and Infrastructure. Editado por K. E. Kendall, pp. 343-357. Thousand Oaks, CA: Sage, 1999. 42.
Davis, G. B. y M. H. Olson. Management Information Systems: Conceptual Foundations, Structure, and Development, 2da.
Edición. Nueva York: McGraw-Hill, 1985.
Fitzgerald, B. y G. Hartnett. “A Study of the Use of Agile Methods Within Intel”. En Business Agility & IT Diffusion. Editado
por L. Matthiassen, J. Pries-Heje y J. DeGross, pp. 187-202. Proc Conference, Atlanta, mayo 2005. Nueva York: Springer,
2005.
Ghione, J. “A Web Developer’s Guide to Rapid Application Development Tools and Techniques”. Netscape World, junio de
1997.
Gremillion, L. L. y P. Pyburn. “Breaking the Systems Development Bottleneck”. Harvard Business Review, marzo-abril 1983,
pp. 130-137.
Harrison, T. S. “Techniques and Issues in Rapid Prototyping”. Journal of Systems Management. Vol. 36, Núm. 6, junio de 1985,
pp. 8-13.
Kendall, J. E. y K. E. Kendall. “Agile Methodologies and the Lone Systems Analyst: When Individual Creativity and Organi-
zational Goals Collide in the Global IT Environment”. Journal of Individual Employment Rights, Vol. 11, Núm. 4, 2004-
2005, pp. 333-347.
Kendall, J. E., K. E. Kendall y S. Kong. “Improving Quality Through the Use of Agile Methods in Systems Development: People
and Values in the Quest for Quality”. En Measuring Information Systems Delivery Quality. Editado por E. W. Duggan y
H. Reichgelt, pp. 201-222. Hershey, PA: Idea Group Publishing, 2006.
Liang, D. Rapid Java Application Development Using JBuilder 3. Upper Saddle River, NJ: Prentice Hall, 2000.
McBreen, P. Questioning Extreme Programming. Boston: Addison-Wesley Publishing Co., 2003.
Naumann, J.D. y A. M. Jenkins. “Prototyping: The New Paradigm for Systems Development”, MIS Quarterly, septiembre 1982,
pp. 29-44.
www.xlibros.com
186 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EPISODIO 6
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Tiempo de reacción
“Necesitamos conocer parte de la salida que necesitan los usuarios”, comenta Anna. “Nos ayudará a reafirmar algunas de nues-
tras ideas sobre la información que requieren”.
“De acuerdo”, contesta Chip. “También nos ayudará a determinar la entrada necesaria. A partir de ahí podemos diseñar las
correspondientes pantallas de entrada de datos. Vamos a crear informes y pantallas del prototipo para obtener retroalimentación
de los usuarios. ¿Por qué no usamos Microsoft Access para crear rápidamente pantallas e informes? Yo estoy bastante familia-
rizado con el software. Empecemos por escribir algunas historias ágiles para sintetizar lo que se necesita y después desarrollar
algunos prototipos. También podemos usar los requerimientos de los usuarios y deberíamos crear un prototipo para cada línea
‘se comunica con’ que conecta a un actor con un caso de uso”.
Anna sonríe y comenta, “Ya escribí las siguientes historias ágiles para el problema del mantenimiento preventivo”. Éstas
son:
1. No hay forma de saber cuándo realizar mantenimiento preventivo en las computadoras de escritorio.
2. Por lo general vamos de sala en sala.
3. Al completar una sala, lo anotamos en una lista.
Anna empieza por desarrollar el prototipo INFORME DE MANTENIMIENTO PREVENTIVO. Con base en las historias
ágiles, se pone a trabajar en la creación del prototipo del informe que, piensa, Mike Crowe necesitará.
“Este informe se debe usar para predecir cuando los equipos deben tener un mantenimiento preventivo”, piensa Anna. “Me
parece que Mike necesitaría saber cuál equipo necesita el servicio, así como cuándo se debe programar éste. Veamos: ¿qué
información identificaría claramente al equipo? El número de inventario, la marca y el modelo; imagino que debemos incluir
la sala y el campus para poder localizarlo rápidamente. Una fecha de mantenimiento calculada indicaría a Mike cuándo hay que
completar el trabajo. ¿En qué secuencia debería estar el informe? Tal vez la más útil sería por ubicación”.
El prototipo del INFORME DE MANTENIMIENTO PREVENTIVO con el informe completo se muestra en la figura
E6.1. Observe que se utilizan los caracteres Xxxxxxx y fechas genéricas para indicar la posición en la que se deben imprimir
los datos. Se incluyen ubicaciones reales de los campus y las salas, así como números de inventario. Son necesarios para que
Microsoft Access pueda realizar la impresión en grupo.
El prototipo del informe se termina pronto. Después de imprimir la copia final, Anna lleva el reporte tanto a Mike Crowe
como a Dot Matricks. Mike Crowe está entusiasmado con el proyecto y desea saber cuándo estará el informe en producción.
Dot está impresionada de manera similar.
Surgen varios cambios. Mike desea un área para escribir la fecha de terminación del mantenimiento preventivo, para poder
usar el informe para reescribir las fechas en la computadora. También sugiere que se cambie el título del informe a INFORME
DE MANTENIMIENTO PREVENTIVO SEMANAL. Los siguientes pasos son modificar el informe del prototipo para reflejar
los cambios recomendados y después hacer que Mike y Dot revisen el resultado.
El informe se modifica y se imprime fácilmente. Dot está complacida con el resultado final. “Éste es en realidad un excelente
método para diseñar el sistema”, comenta. “Es tan agradable sentir que formamos parte del proceso de desarrollo y que nuestras
opiniones cuentan. Estoy empezando a sentirme confiada de que el sistema final será justo lo que siempre hemos querido”.
Mike tiene elogios similares, y comenta: “Esto hará que nuestro trabajo fluya con más uniformidad. Elimina la parte de
tener que adivinar sobre los equipos a los que hay que dar mantenimiento. Y usar la secuencia de sala en sala es una excelente
idea. No tenemos que invertir tanto tiempo en regresar a las salas para trabajar en los equipos”.
Chip hace una observación sobre cada una de estas modificaciones en un Formulario de evaluación del prototipo (como la
figura 6.3 del capítulo). Este formulario ayuda a Chip a organizarse y documenta el proceso de creación del prototipo.
Después, Chip y Anna concentran su atención en la creación de prototipos de las pantallas. “Como me gusta el aspecto de
hardware del sistema, ¿por qué no empezamos a trabajar en el diseño de la pantalla AGREGAR NUEVA COMPUTADORA?”,
pregunta Chip.
“Me parece bien”, responde Anna. “Me enfocaré en los aspectos de software”.
Chip analiza los resultados de las entrevistas detalladas con Dot y Mike. Compila una lista de elementos que cada usuario
necesitaría a la hora de agregar una computadora. Otros elementos, como la información sobre la ubicación y el mantenimiento,
actualizarían el ARCHIVO MAESTRO DE COMPUTADORAS después de instalar el equipo.
“No cabe duda de que definir las tablas de la base de datos ayuda a crear prototipos rápidos”, comenta Chip. “No me tardé
mucho en completar la pantalla. ¿Te gustaría verme probar el prototipo?”.
“Seguro”, le responde Anna. “Ésta es mi parte favorita de la creación de prototipos”.
Chip ejecuta el diseño de la pantalla mientras Anna, Mike y Dot observan. Las listas desplegables y las casillas de verifi-
cación facilitan la introducción de datos precisos.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 187
FIGURA E6.1
Prototipo para el INFORME DE
MANTENIMIENTO
PREVENTIVO. Hay que revisar
Informe de mantenimie este informe.
nto preventivo
“Esto me gusta mucho”, dice Dot. “¿Puedo tratar de agregar algunos datos?”.
“Adelante”, contesta Chip. “Trata de agregar datos tanto válidos como inválidos. Y observa los mensajes de ayuda que
aparecen en la parte inferior de la pantalla para indicar lo que se debe introducir. ¿Por qué no pruebas este prototipo por uno o
dos días y regresas conmigo? Entonces realizaré los cambios que recomiendes y te daré el prototipo modificado para que lo
revises”.
Anna regresa a su escritorio y crea el diseño de la pantalla AGREGAR REGISTRO DE SOFTWARE.
Cuando Anna termina el diseño de la pantalla, pide a Cher que pruebe el prototipo. Cher introduce información, revisa los
valores de las listas desplegables y observa los mensajes de ayuda.
“Me gusta mucho el diseño de esta pantalla y su apariencia”, comenta Cher. “Aunque le faltan algunos de los campos que
se incluirían por lo general para introducir un paquete de software, como el tipo de computadora en la que se ejecuta el software,
la memoria requerida y la velocidad del procesador. También me gustarían unos botones para guardar el registro y salir”.
“Puedo hacer todos esos cambios. Una vez que los termine, regresaré contigo”, responde Anna mientras hace algunas
anotaciones para sí misma.
Poco tiempo después. Cher vuelve a probar la pantalla AGREGAR REGISTRO DE SOFTWARE. Ésta incluye todas las
características que requiere. Se puede ver el diseño de la pantalla completa mediante Microsoft Access. Cher observa que hay
una línea que separa la información de software de las entradas de hardware.
Unos cuantos días más tarde, Dot visita a Anna con los cambios sugeridos para el prototipo de AGREGAR NUEVA COMPU-
TADORA. “Revisé esto con Mike y nos gusta lo que vimos, pero tenemos unas sugerencias”, comenta Dot. “Una de las cosas
que faltan es el sistema operativo. Tenemos varias personas técnicas que utilizan varios sistemas operativos. Muchos de los
usuarios de los equipos Mac tienen Windows instalado también, y algunos de los usuarios de Windows tienen sistemas tipo
Linux instalados. Necesitamos incluir varios sistemas operativos en la pantalla AGREGAR NUEVA COMPUTADORA”.
www.xlibros.com
188 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
“Vamos a requerir algo de tiempo para actualizar las tablas y los prototipos”, comenta Chip después de una larga pausa.
“Pero esta es la razón por la que usamos ciclos cortos para desarrollar, probar y obtener retroalimentación. Modificaré el pro-
totipo y me pondré en contacto con ustedes cuando termine”.
Después de idear y rediseñar las tablas de la base de datos, el prototipo se modifica y se envía a Mike para su aprobación.
Unos cuantos días después. Mike llega con algo de retroalimentación. “¡Se ve excelente!”, exclama Mike. “Sin embargo, me di
cuenta de que hay algunos requerimientos adicionales que olvidé decirles. Tenemos un programa de renovación en el que se
reemplazan las computadoras después de cierto periodo, que varía según el tipo de equipo y la fecha en que se compró. Cuando
compramos el equipo, estimamos el intervalo de renovación. ¿Podemos agregar el intervalo de renovación a la base de datos y
al prototipo? Podríamos usarlo para calcular la fecha de renovación y explorar en forma periódica el Archivo maestro de compu-
tadoras para detectar todas las computadoras que necesiten renovación”.
Chip empieza a trabajar en las modificaciones. “Este desarrollo ágil es interesante”, dice al tiempo que le sonríe a Anna.
“Puedo ver por qué se utiliza para descubrir los requerimientos”.
La versión final del prototipo de AGREGAR NUEVA COMPUTADORA que se creó con Access se muestra en la figura
E6.2. En la parte superior de la pantalla se colocaron la fecha y hora actuales, así como un título centrado en la pantalla. Las
leyendas de los campos están alineadas a la izquierda en la pantalla. Se incluyeron casillas de verificación para el campo de la garan-
tía, así como una lista desplegable para el tipo de unidad óptica. Se incluyó un subformulario del sistema operativo para selec-
cionar varios sistemas operativos en la porción inferior derecha de la pantalla. Se incluyeron los botones “Agregar registro”
(Add Record) e “Imprimir”.
“Chip, estuve hablando con Dot y mencionó que hay financiamiento para incluir parte de la información en la Web, como
parte del sitio Web para soporte de tecnología en la CPU”, comenta Anna, quitando su vista de la computadora. “He estado
ocupada creando un prototipo para los menús de la página Web y la primera pantalla, una para reportar problemas tecnológicos.
Como resolver problemas es el área de Mike, lo invité junto con Dot para revisar el prototipo. ¿Quieres unirte a la sesión?”.
“Seguro”, responde Chip. “Estoy interesado en trabajar en el diseño de algunas de las páginas Web”.
Poco tiempo después, Mike, Dot y Chip están reunidos con Anna mientras ella demuestra la página Web que se ilustra en
la figura E6.3.
“Me gusta mucho el estilo del menú”, comenta Dot. “El menú principal incluye submenús desplegables en la parte superior
que son fáciles de usar; además me gusta la forma en que se despliegan y cómo cambian de color los elementos del menú al
mover el ratón sobre ellos”.
“Sí, y al tener submenús desplegables debajo del principal para las características de cada opción nos ayuda a encontrar lo
que estamos buscando”, agrega Mike. “Ahora, tengo algunas sugerencias para la página Web en la que se reportan los problemas.
Sería más útil si se moviera el área de selección Categoría del problema (Problem Category) a la parte superior de la página.
Cada tipo de problema se asigna a un técnico distinto, uno que sea más o menos experto en esa área. Necesitamos una casilla
de verificación adicional para identificar si es equipo Macintosh, Windows o software con el que estemos trabajando. El campo
Número de etiqueta (Tag Number) ayuda también. Muchas personas no saben que cada pieza de equipo tiene una pequeña
etiqueta metálica de identificación con un número único de inventario. Hmmm… esa gran área azul parece resaltar demasiado.
Después de todo, es sólo ayuda. Creo que sería mejor reemplazarla con una pequeña imagen”.
FIGURA E6.2
Prototipo para la pantalla
AGREGAR NUEVA
COMPUTADORA (Add New
Computer). Se utilizó Microsoft
Access como la herramienta para
crear el prototipo. Se pueden hacer
mejoras en esta etapa.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 189
FIGURA E6.3
Prototipo para la página Web
SISTEMA DE REPORTE DE
PROBLEMAS. Esta página Web
necesita algunas mejoras.
www.xlibros.com
190 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EJERCICIOS
Elabore una crítica de los prototipos de informes y pantallas para los siguientes ejercicios (E-1 al E-10). Registre los cambios
en una copia del Formulario de evaluación de prototipos Use Microsoft Access para ver los prototipos y después modifique los
prototipos de informes y pantallas con los cambios sugeridos. Imprima los prototipos finales.
Use los siguientes lineamientos como ayuda en el análisis:
1. Alineación de los campos en los informes. ¿Están alineados los campos en forma correcta? ¿Están alineados los encabeza-
dos de las columnas de los informes en forma correcta sobre las columnas? Si el informe tiene leyendas a la izquierda de
los campos de datos, ¿están alineadas en forma correcta (por lo general a la izquierda)? ¿Están alineados los datos en forma
correcta dentro de cada campo de entrada?
2. Contenido del informe. ¿Contiene el informe todos los datos necesarios? ¿Están presentes los totales y subtotales apro-
piados y útiles? ¿Hay totales o datos adicionales que no deban estar en el informe? ¿Están impresos las claves o los sig-
nificados de éstas en el informe (hay que evitar claves, ya que tal vez no presenten información al usuario en forma
clara)?
3. Revise la apariencia visual del informe. ¿Se ve agradable? ¿Se imprimen en grupo los campos repetitivos (es decir, los
datos sólo se deben imprimir una vez, al principio del grupo)? ¿Hay suficientes líneas en blanco entre los grupos para
identificarlos con facilidad?
4. Alineación de datos y leyendas en la pantalla. ¿Están alineadas las leyendas en forma correcta en la pantalla? ¿Están
los datos alineados en forma correcta? ¿Están alineados correctamente los datos dentro de un campo?
5. Apariencia visual de la pantalla. ¿Tiene la pantalla una apariencia visual placentera? ¿Hay suficiente espaciamiento
vertical entre los campos? ¿Hay suficiente espaciamiento horizontal entre las columnas? ¿Están agrupados todos los cam-
pos en forma lógica? ¿Están agrupadas las características como los botones y las casillas de verificación?
6. ¿Contiene la pantalla todos los elementos funcionales necesarios? Busque botones faltantes que podrían ayudar al
usuario a trabajar sin problemas con la pantalla; busque también datos faltantes, datos o campos adicionales innecesarios
que se deban sustituir por una casilla de verificación o lista desplegable.
E-1. El LISTADO DE INVENTARIO DE HARDWARE muestra todas las computadoras personales, ordenadas por campus
y sala.
E-2. El INFORME DE INVERSIÓN DE SOFTWARE se utiliza para calcular el monto total invertido en software.
E-3. El INFORME DE COMPUTADORAS INSTALADAS muestra la información de los equipos instalados.
E-4. El prototipo para el INFORME DE PROBLEMAS DE COMPUTADORAS muestra una lista de todos los equipos orde-
nados en base al costo total de las reparaciones e incluye el número de reparaciones (algunos equipos no tienen un costo
alto, ya que aún se encuentran bajo garantía). Este prototipo se utiliza para calcular el costo total de las reparaciones para
toda la universidad, así como para identificar los equipos con problemas.
E-5. El INFORME DE NUEVO SOFTWARE INSTALADO muestra el número de equipos con cada paquete de software que
están instalados en cada sala de cada campus.
E-6. El INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE muestra una lista de todas las ubicaciones para cada
versión de cada paquete de software.
E-7. La pantalla ELIMINAR REGISTRO DE COMPUTADORA se utiliza para seleccionar las computadoras que se van a
eliminar del sistema. El área de entrada es el campo Número de inventario de hardware (Hardware Inventory Number).
Los demás campos sólo son para fines de visualización, para identificar el equipo. A los usuarios les gustaría la habilidad
de imprimir cada registro antes de eliminarlo. También quieren desplazarse a los registros anterior y siguiente. Sugeren-
cia: examine los campos que se muestran en el informe LISTADO DE INVENTARIO DE HARDWARE.
E-8. Una pantalla INFORMACIÓN DE MANTENIMIENTO DE ACTUALIZACIONES permite a Mike Crowe cambiar la
información de mantenimiento sobre las computadoras personales. Algunas veces éstos son cambios de rutina, como
la FECHA DEL ÚLTIMO MANTENIMIENTO PREVENTIVO o el NÚMERO DE REPARACIONES, pero también
pueden ocurrir otros cambios en forma esporádica, como la expiración de una garantía. Se introduce el NÚMERO DE
INVENTARIO DE HARDWARE y se encuentra el REGISTRO DE COMPUTADORA que coincida. Se muestran la
MARCA y el MODELO para fines de retroalimentación. Así el operador puede cambiar los campos GARANTÍA, IN-
TERVALO DE MANTENIMIENTO, NÚMERO DE REPARACIONES, FECHA DE ÚLTIMO MANTENIMIENTO
PREVENTIVO y COSTO TOTAL DE REPARACIONES. A Mike le gustaría imprimir la información en pantalla, así
como realizar cualquier cambio con facilidad.
E-9. La pantalla PETICIÓN DE UBICACIÓN DE SOFTWARE muestra información sobre las salas y los equipos que contie-
nen software seleccionado. Se introducen el TÍTULO, NÚMERO DE VERSIÓN y SISTEMA OPERATIVO. La porción
de salida de la pantalla debe mostrar la UBICACIÓN DEL CAMPUS, UBICACIÓN DE LA SALA, NÚMERO DE
INVENTARIO DE HARDWARE, NOMBRE DE MARCA y MODELO. Los botones permiten al usuario avanzar al
siguiente registro, al registro anterior, cerrar y salir de la pantalla.
www.xlibros.com
CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 191
FIGURA E6.4
Prototipo para la página Web
ACTUALIZAR IMAGEN DE
LABORATORIO. Esta página
Web necesita algunas mejoras.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar una base de datos de muestra de Microsoft Access y de Visible Analyst Project para completar los
ejercicios.
www.xlibros.com
www.xlibros.com
PARTE III
CAPÍTULO 7 El proceso de análisis
Uso de diagramas
de flujo de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender la importancia del uso de diagramas de flujo de datos (DFD) lógicos y físicos para
describir gráficamente el movimiento de datos para humanos y sistemas en una organización.
2. Crear, usar y expandir los DFD lógicos para capturar y analizar el sistema actual por medio
de niveles padre e hijo.
3. Desarrollar y expandir DFD lógicos que ilustren el sistema propuesto.
4. Producir DFD físicos con base en los DFD lógicos que desarrolle.
5. Comprender y aplicar el concepto de particionamiento de DFD físicos.
www.xlibros.com
194 PARTE III • EL PROCESO DE ANÁLISIS
Tal vez la mayor ventaja recaiga en la libertad conceptual que se obtiene al usar los cuatro símbolos (re-
conocerá tres de ellos del capítulo 2; la próxima subsección sobre las convenciones de los DFD aborda todos).
Ninguno de estos símbolos especifica los aspectos físicos de la implementación. Los DFD se enfocan en el
procesamiento de los datos o en la transformación de los mismos a medida que avanzan a través de varios
procesos. En los DFD lógicos no hay distinción entre los procesos manuales o los automatizados. Tampoco se
describen en forma gráfica los procesos en orden cronológico, sino que, en última instancia, se agrupan entre sí
cuando un análisis posterior indique que es conveniente hacerlo. Se agrupan los procesos manuales; también los
automatizados pueden asociarse entre sí. En una sección posterior veremos más detalles sobre este concepto,
conocido como particionamiento.
FIGURA 7.1
Los cuatro símbolos básicos que Símbolo Significado Ejemplo
se utilizan en los diagramas de
flujo de datos, sus significados y
ejemplos.
Entidad Estudiante
Información
nuevo estudiante
Flujo de datos
2.1
Archivo maestro
D3
Almacén de datos de estudiantes
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 195
trabajo que se realiza en el sistema y se deben denominar mediante el uso de uno de los siguientes formatos. Un
nombre claro facilita la acción de entender lo que el proceso lleva a cabo.
1. Al denominar un proceso de alto nivel, asigne al proceso el nombre de todo el sistema. Por ejemplo,
SISTEMA DE CONTROL DE INVENTARIO.
2. Al denominar un subsistema importante, use un nombre tal como SUBSISTEMA DE INFORME DE
INVENTARIOS o SISTEMA DE CUMPLIMIENTO CON CLIENTES DE INTERNET.
3. Al denominar procesos detallados, use una combinación verbo-sustantivo-adjetivo. El verbo describe el tipo
de actividad, como CALCULAR, VERIFICAR, PREPARAR, IMPRIMIR o AGREGAR. El sustantivo
indica cuál es el resultado principal del proceso, como INFORME o REGISTRO. El adjetivo ilustra la
salida específica que se produce, como PEDIDO PENDIENTE o INVENTARIO. Algunos ejemplos de
nombres de procesos completos son CALCULAR IMPUESTO DE VENTAS, VERIFICAR ESTADO DE
CUENTA DE CLIENTE, PREPARAR FACTURA DE ENVÍO, IMPRIMIR INFORME DE PEDIDOS
PENDIENTES, ENVIAR CONFIRMACIÓN POR EMAIL AL CLIENTE, VERIFICAR SALDO DE
TARJETA DE CRÉDITO y AGREGAR REGISTRO DE INVENTARIO.
Un proceso también debe recibir un número de identificación único que indique su nivel en el diagrama. Más ade-
lante en el capítulo hablaremos sobre esta organización. Puede haber varios flujos de datos que entren y salgan de
cada proceso. Examine los procesos que tengan sólo un flujo entrante y saliente para determinar si no hacen falta
más flujos de datos.
El último símbolo básico que se utiliza en los diagramas de flujo de datos es un rectángulo con un extremo
abierto, el cual representa a un almacén de datos. El rectángulo se dibuja con dos líneas paralelas que se cierran
mediante una línea corta del lado izquierdo y cuyo extremo derecho está abierto. Estos símbolos se dibujan con
la anchura suficiente como para permitir una leyenda de identificación entre las líneas paralelas. En los diagra-
mas de flujo de datos lógicos no se especifica el tipo de almacenamiento físico. En este punto, el símbolo del
almacén de datos muestra sólo un depósito de datos que permite examinar, agregar y recuperar los datos.
El almacén de datos puede representar un almacén manual como un archivero, o un archivo o una base de
datos computarizada. Como los almacenes de datos representan a una persona, lugar o cosa, se denominan con
un sustantivo. Los almacenes de datos temporales, como el papel de borrador o un archivo temporal de computa-
dora, no se incluyen en el diagrama de flujo de datos. Hay que dar a cada almacén de datos un número de refe-
rencia único, como D1, D2, D3, por ejemplo.
www.xlibros.com
196 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 7.2
Pasos para desarrollar diagramas
de flujo de datos.
Cómo desarro
llar diagramas
datos mediant de flujo de
e una metodol
ogía arriba-ab
ajo
1. Hacer una
lista de las activ
los siguientes idades de la em
elementos: presa y usarla
para determinar
• Entidades ex
ternas
• Flujos de dato
s
• Procesos
• Almacenes de
datos
2. Crear un di
agrama de cont
los flujos de da exto que muest
tos que entran re las entidades
procesos detalla y salen del siste externas y
dos ni almacen ma. No debe m
es de datos. ostrar
3. Dibujar el
Diagrama 0, el
pero debe man siguiente nivel.
tenerlos en un Puede m
los almacenes nivel general. En ostrar los procesos
de datos. este nivel pued
e mostrar
4. Crear un di
agrama hijo pa
ra cada uno de
los procesos en
5. Verificar lo el Diagrama 0.
s errores y aseg
proceso y flujo urarse de que
de datos sean las etiquetas qu
significativas. e asigne a cada
6. Desarrolla
r un diagrama
flujo de datos ló de flujo de dato
gico. Establecer s físico a partir
y los automatiza la diferencia en del diagrama de
dos, describir tre los procesos
nombre y agre los archivos e manuales
gar controles pa informes actuale
o se produzcan ra indicar cuan s por
errores. do se completen
los procesos
7. Particiona
r el diagrama de
agrupación de flujo de datos fís
partes del diag ico mediante la
implementació rama para facil separación o
n. itar la program
ación y la
el diagrama de contexto, así como el flujo de datos principal que entra y sale de ellas. El diagrama no contiene
almacenes de datos y es bastante simple de crear una vez que los analistas conocen las entidades externas y el
flujo de datos que entra y sale de ellas.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 197
FIGURA 7.3
Los diagramas de contexto
Entidad
(superior) se pueden “expandir” en
1 0
un Diagrama 0 (inferior). Observe
Entrada A
el mayor detalle en el Diagrama 0.
Salida C Entidad
Nombre del
sistema 3
Entrada B
Entidad
2
1 2
Flujo de
Entrada A Proceso datos B Proceso Salida C
Entidad general general Entidad
1 AAA Flujo de BBB 3
datos C
Registro A Registro E
Registro A Registro E
3 4
Flujo de
Entrada B datos D
Entidad Proceso Proceso
2 general general
CCC DDD
1. Empezar con el flujo de datos proveniente de una entidad en el lado de entrada. Haga preguntas tales como:
“¿Qué ocurre con los datos que entran al sistema?”, “¿Se guardan?”, “¿Constituyen la entrada para varios
procesos?”.
2. Trabaje en sentido inverso desde un flujo de datos de salida. Examine los campos de salida en un documento
o pantalla (este método es más sencillo si se crearon prototipos). Para cada campo en la salida pregunte lo
siguiente: “¿De dónde proviene?” o “¿Se calcula o se guarda en un archivo?”. Por ejemplo, cuando la salida
es un CHEQUE DE NÓMINA, el NOMBRE DE EMPLEADO y la DIRECCIÓN se ubicarían en un archivo
de EMPLEADO, las HORAS TRABAJADAS estarían en un REGISTRO DE TIEMPO y se calcularían el
SUELDO BRUTO y las DEDUCCIONES. Cada archivo y registro estaría conectado al proceso que produce
el cheque de nómina.
3. Examine el flujo de datos que entra o sale de un almacén de datos. Pregunte: “¿Qué procesos colocan
datos en el almacén?” o “¿Qué procesos utilizan los datos?”. Tenga en cuenta que un almacén de datos
que se utilice en el sistema en el que usted esté trabajando puede ser producido por un sistema distinto.
Por ende, desde su posición de ventaja, tal vez no haya ningún flujo de datos que entre al almacén de
datos.
4. Analice un proceso bien definido. Examine los datos de entrada que necesita el proceso y la salida que
produce. Después conecte la entrada y la salida a los almacenes de datos y las entidades apropiadas.
5. Tome nota de cualquier área confusa en donde no esté seguro de lo que se debería incluir o de la entrada o
salida requerida. Al estar consciente de las áreas problemáticas podrá formular una lista de preguntas para
las entrevistas de seguimiento con los usuarios clave.
www.xlibros.com
198 PARTE III • EL PROCESO DE ANÁLISIS
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 199
D1 Almacén de datos 1
s que
Flujo de dato
Registro A coincide .
3 4
Flujo de
Entidad Entrada B Proceso datos D Proceso
2 general general
CCC DDD
tos Almacén
El flujo de da D1
o padre de datos 1
de l proc es
hijo
al diagrama
dir.
debe coinci Registro A
3.1 3.2
Registro de Registro de
Entrada B Proceso transacciones 1 Archivo de transacciones 1 Proceso
D5
detallado transacciones 1 detallado
XXX YYY
Flujo
Error de datos
detallado Z
regar
Se pueden ag
ansacción 3.3
archivos de tr
regar de niveles
Se pueden ag a di ag ra m as
er ro r en un
línea s de más bajos. Proceso
diagram a hi jo
detallado
detallado. ZZZ
lida Flujo de
El flujo de sa
in ci di r con datos D
debe co
o
el del proces
padr e.
FIGURA 7.4
Diferencias entre el diagrama padre (superior) y el diagrama hijo (inferior).
5. Omitir el flujo de datos. Examine su diagrama en busca de flujo lineal; es decir, un flujo de datos en el que
cada proceso sólo tiene una entrada y una salida. Excepto en el caso de los diagramas de flujo con datos de
diagramas hijos muy detallados, el flujo de datos lineal ocurre raras veces. Por lo general su presencia indica
que faltan flujos de datos en el diagrama. Por ejemplo, el proceso CALCULAR MONTO DE RETENCIÓN
necesita el número de dependientes que tiene un empleado y las TASAS DE RETENCIÓN como entrada.
Además, no se puede calcular el SUELDO NETO sólo con base en la RETENCIÓN, y el CHEQUE DE
PAGO DEL EMPLEADO no se puede crear sólo a partir del SUELDO NETO; también hay que incluir un
NOMBRE DE EMPLEADO así como las cifras de nómina actuales y del año a la fecha, además del
MONTO DE RETENCIÓN.
6. Crear una descomposición (o expansión) desbalanceada en los diagramas hijos. Cada diagrama hijo debe
tener el mismo flujo de datos de entrada y salida que el proceso padre. La excepción a esta regla es la salida
menor, como las líneas de error que se incluyen sólo en el diagrama hijo. El diagrama de flujo de datos de la
www.xlibros.com
200 PARTE III • EL PROCESO DE ANÁLISIS
no tiene
El proceso 2
Archivo maestro flu jo de
Empleado D1 entrada. El
de empleados s S ue ld o bruto
dato
cc ió n
El proceso 1 no va en dire
Registro de tiene salida. equivocada.
empleado
Horas
trabajadas
1 2 3
Registro de tiempo
Archivo de tiempo de empleado Calcular Sueldo bruto Calcular Retención
D2 Calcular
de empleados sueldo monto de sueldo neto
bruto retención
Sueldo
neto
externa
Una entidad 4
be co nectar
no se de Registro de
recta a
de manera di empleado Imprimir
datos. Archivo maestro
un almacén de D1
cheque de pago
de empleados
de empleado
datos
Un almacén de
se de be co nectar Registro de Cheque de pago
no
cta a reconciliación de empleado
de manera dire
de de cheques
otro almacén
datos.
FIGURA 7.5
Reconciliación de
Errores comunes que pueden D3 Empleado
cheques
ocurrir en un diagrama de flujo de
datos (ejemplo de nómina).
figura 7.6 está dibujado en forma correcta. Observe que, aunque el flujo de datos no es lineal, podemos
seguir con claridad una ruta directamente desde la entidad de origen hasta la entidad de destino.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 201
Empleado
Horas
trabajadas
1
Número de Tasas de
Crear registro dependientes retención
Archivo maestro Tablas de
de tiempo de D1 D4
de empleados retención
empleado
Registro de
Registro de tiempo empleado
de empleado
Registro 2 3
de tiempo
Archivo de tiempo de empleado Calcular Sueldo bruto
Calcular D3
Reconciliación
D2
de empleados sueldo monto de de cheques
bruto retención
Registro de
Monto de reconciliación
retención de cheques
Monto de
retención
4 6
Sueldo
neto
Sueldo Información de
bruto cheque de pago
5
Registro de Cheque de pago
Archivo maestro empleado Imprimir de empleado
D1
de empleados cheque de
empleado Empleado
FIGURA 7.6
El diagrama de flujo de datos correcto para el ejemplo de la nómina.
des, procesos de salida, de entrada y datos almacenados. Esta metodología ofrece un medio para asegurar que
se retengan las características esenciales del sistema anterior en el nuevo sistema. Además, al utilizar el modelo
lógico del sistema actual como base para el sistema propuesto podemos realizar una transición gradual hacia el
diseño del nuevo sistema. Una vez desarrollado el modelo lógico del nuevo sistema, podemos usarlo para crear
un diagrama de flujo de datos físico para este nuevo sistema.
En la figura 7.9 aparece un diagrama de flujo de datos lógico y un diagrama de flujo de datos físico para
un cajero de una tienda de abarrotes. El CLIENTE lleva los ARTÍCULOS a la caja registradora; se BUSCAN
los PRECIOS de todos los ARTÍCULOS y después se obtiene el total; después se proporciona el PAGO al ca-
jero; por último, el CLIENTE obtiene un RECIBO. El diagrama de flujo de datos lógico ilustra los procesos
involucrados sin entrar en los detalles sobre la implementación física de las actividades. El diagrama de flujo
de datos físico muestra que se utiliza un CÓDIGO DE BARRAS del código de producto universal (UPC) que
se encuentra en la mayoría de los artículos de la tienda de abarrotes. Además, el diagrama de flujo de datos
físico menciona procesos manuales tales como la exploración, explica que se utiliza un archivo temporal para
www.xlibros.com
202 PARTE III • EL PROCESO DE ANÁLISIS
Controles del sistema Muestra los controles Muestra los controles para validar los datos de
de la empresa entrada, para obtener un registro (estado de
registro encontrado), para asegurar que se
complete un proceso con éxito y para la seguridad
del sistema (ejemplo: registros del diario)
mantener un subtotal de artículos e indica que el PAGO se puede realizar mediante EFECTIVO, CHEQUE o
TARJETA DE DÉBITO. Por último, hace referencia al recibo por su nombre, RECIBO DE CAJA REGIS-
TRADORA.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 203
1 2 3 4
Archivo de trans.
D1 Archivo de precios UPC D2
Cliente temporal Cliente
Artículos y Efectivo,
Artículos Código UPC Descripción y precios Artículos, precios Recibo FIGURA 7.9
precios cheque o
a pagar del artículo y subtotales de la caja
tarjeta de El diagrama de
registradora
débito flujo de datos
1 2 3 4 físico (inferior)
Código de Códigos y precios Monto calculado muestra ciertos
Pasar barras UPC Buscar código Recibir dinero
de artículos Calcular a pagar detalles que no se
artículo por y precio en y dar
el archivo costo encuentran en el
el escáner recibo
total diagrama de flujo
(manual) (manual)
de datos lógico
(superior).
Es más fácil usar un modelo lógico al momento de comunicarnos con los usuarios del sistema, ya que se centra
en las actividades de la empresa. En consecuencia, los usuarios están familiarizados con las actividades esencia-
les y con muchos de los requerimientos humanos de información de cada actividad.
Los sistemas que se forman mediante el uso de un diagrama de flujo de datos lógico son a menudo más es-
tables, ya que se basan en eventos de negocios y no en una tecnología o método de implementación específico.
Los diagramas de flujo de datos lógicos representan las características de un sistema que existirían sin importar
cuáles sean los medios físicos de las actividades de negocios. Por ejemplo, las actividades tales como solicitar la
tarjeta de membresía de una tienda de video, revisar un DVD y devolver un DVD se llevarían a cabo sin importar
que la tienda tuviera un sistema automatizado, manual o híbrido.
www.xlibros.com
204 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 7.10
Contenido de los diagramas de flujo de datos físicos
Los diagramas de flujo de datos
físicos contienen muchos • Procesos manuales
elementos que no se encuentran en • Procesos para agregar, eliminar, modificar y actualizar registros
los diagramas de flujo de datos • Procesos para introducir y verificar datos
lógicos. • Procesos de validación para asegurar que se introduzcan los datos con
precisión
• Secuenciar procesos para reorganizar el orden de los registros
• Procesos para producir todas las salidas únicas del sistema
• Almacenes de datos intermedios
• Se utilizan los nombres de archivo reales para guardar datos
• Controles para indicar que se completaron las tareas o condiciones de error
A menudo los diagramas de flujo de datos físicos son más complejos que los diagramas de flujo de datos lógi-
cos simplemente debido a que hay muchos datos presentes en un sistema. Con frecuencia se utiliza el acrónimo
CRUD para Crear, Leer, Actualizar y Eliminar (Create, Read, Update y Delete), las actividades que deben estar
presentes en un sistema para cada archivo maestro. Una matriz CRUD es una herramienta para representar en
dónde ocurren cada uno de estos procesos en un sistema. La figura 7.11 es una matriz CRUD para un escaparate
en Internet. Cabe mencionar que algunos de los procesos incluyen más de una actividad. Los procesos de entrada
de datos tales como teclear y verificar también forman parte de los diagramas de flujo de datos físicos.
Los diagramas de flujo de datos físicos también tienen almacenes de datos intermedios, a menudo compues-
tos por un archivo de transacciones o una tabla de una base de datos temporal. Con frecuencia los almacenes de
datos intermedios consisten en archivos de transacciones que se utilizan para guardar datos entre procesos. Como
es poco probable que la mayoría de los procesos que requieren acceso a un conjunto dado de información se
ejecuten en el mismo instante, los archivos de transacciones deben contener los datos de un proceso al siguiente.
Podemos encontrar un ejemplo de fácil comprensión sobre este concepto en las experiencias diarias de las com-
pras de abarrotes, la preparación de comidas y la acción de comer. Las actividades son:
1. Seleccionar artículos de los estantes.
2. Pasar a pagar a una caja.
3. Transportar los abarrotes hasta la casa.
4. Preparar una comida.
5. Comer.
FIGURA 7.11
Actividad Cliente Artículo Pedido Detalle del pedido
Una matriz CRUD para un
escaparate en Internet. Se puede
Inicio de sesión del cliente R
usar esta herramienta para
representar en dónde ocurren cada
Información sobre un artículo R
uno de los cuatro procesos (Crear,
Leer, Actualizar y Eliminar
– Create, Read, Update y Delete) Selección de un artículo R C C
dentro de un sistema.
Pasar a pagar el pedido U U U R
Agregar cuenta C
Agregar artículo C
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 205
Cada una de estas cinco actividades estaría representada por un proceso separado en un diagrama de flujo de datos
físico y cada una ocurre en un momento distinto. Por ejemplo, no sería común transportar los abarrotes a la casa y
comerlos al mismo tiempo. Por lo tanto, se requiere un “almacén de datos de transacciones” para vincular cada
tarea. Al seleccionar elementos, el almacén de datos de transacciones es el carrito de compras. Después del si-
guiente proceso (pasar a pagar), el carrito ya no es necesario. El almacén de datos de transacciones que vincula los
procesos de pasar a pagar y transportar los abarrotes a la casa es la bolsa de compras (¡es más económico que dejar
que usted se lleve el carrito a su casa!). Las bolsas son una manera ineficiente de almacenar los abarrotes una vez que
están en la casa, por lo que se utilizan las alacenas y un refrigerador como almacén de datos de transacciones entre
la actividad de transportar los artículos a la casa y preparar la comida. Por último, un plato, un tazón y un vaso
constituyen el vínculo entre los procesos de preparar y comer los alimentos.
También se puede incluir información de sincronización. Por ejemplo, un DFD físico puede indicar que
se debe ejecutar un programa de edición antes de un programa de actualización. Las actualizaciones se deben
realizar antes de producir un informe de resumen o se debe introducir un pedido en un sitio Web antes de poder
verificar con la institución financiera la cantidad que se va a cargar a una tarjeta de crédito. Cabe mencionar que
debido a tales consideraciones, un diagrama de flujo de datos físico tal vez parezca más lineal que un modelo
lógico.
Para crear el diagrama de flujo de datos físico para un sistema hay que analizar sus salidas y entradas. Al
crear un diagrama de flujo de datos físico, al flujo de datos de entrada que proviene de una entidad externa se
le denomina algunas veces desencadenador, debido a que empieza las actividades de un proceso; al flujo de
datos de salida de una entidad externa se le denomina algunas veces respuesta, ya que se envía como resultado
de alguna actividad. Hay que determinar cuáles campos de datos o elementos hay que teclear. Estos campos se
denominan elementos base y se deben almacenar en un archivo. Los elementos que no se teclean, sino que cons-
tituyen el resultado de un cálculo o una operación lógica, se denominan elementos derivados.
Algunas veces no queda claro cuántos procesos hay que colocar en un diagrama y cuándo se debe crear un
diagrama hijo. Una sugerencia es examinar cada proceso y contar el número de flujos de datos que entran y salen
de él. Si el total es mayor que cuatro, el proceso es un buen candidato para un diagrama hijo. Más adelante en
este capítulo ilustraremos los diagramas de flujo de datos físicos.
MODELADO DE EVENTOS Y DIAGRAMAS DE FLUJO DE DATOS Una metodología práctica para crear diagramas de flujo
de datos físicos es la creación de un fragmento de diagrama de flujo de datos simple para cada evento único del sistema.
Los eventos provocan que el sistema haga algo y actúan como desencadenador para el sistema. Los desen-
cadenadores inician actividades y procesos, los que a su vez utilizan datos o producen salida. Un ejemplo de un
evento es cuando un cliente reserva un vuelo en Web; a medida que se envía cada formulario Web se activan
procesos tales como validar y guardar los datos, o aplicar formato a la siguiente página Web y mostrarla.
Por lo general los eventos se sintetizan en una tabla de respuesta a eventos. En la figura 7.12 se muestra un
ejemplo de una tabla de respuesta a eventos para una empresa con un escaparate en Internet. Un fragmento de
diagrama de flujo de datos se representa mediante una fila en la tabla. Cada fragmento de DFD es un proceso in-
dividual en un diagrama de flujo de datos. Después se combinan todos los fragmentos para formar el Diagrama 0.
Las columnas desencadenador y respuesta se convierten en los flujos de datos de entrada y salida; la actividad se
convierte en el proceso. El analista debe determinar los almacenes de datos requeridos para el proceso mediante
un análisis de los flujos de datos de entrada y salida. En la figura 7.13 se ilustra una parte del diagrama de flujo
de datos para las primeras tres filas de la tabla de respuesta a eventos.
La ventaja de crear diagramas de flujo de datos con base en eventos es que los usuarios están familiari-
zados con los eventos que se llevan a cabo en su área de negocios y saben cómo estos eventos impulsan otras
actividades.
CASOS DE USO Y DIAGRAMAS DE FLUJO DE DATOS En el capítulo 2 presentamos el concepto de un caso de uso.
Utilizamos esta noción de un caso de uso para crear diagramas de flujo de datos. Un caso de uso sintetiza un
evento y tiene un formato similar para procesar las especificaciones (lo cual se describe en el capítulo 9). Cada
caso de uso define una actividad junto con su desencadenador, su entrada y su salida. En la figura 7.14 se ilustra
un caso de uso para el proceso 3, Agregar artículo del cliente.
Este método permite al analista trabajar con los usuarios para comprender la naturaleza de los procesos y
actividades, para después crear un fragmento individual del diagrama de flujo de datos. Al crear casos de uso,
primero hay que hacer un intento por definir los casos de uso sin entrar en detalles. Este paso provee una vista
general del sistema y conduce a la creación del Diagrama 0. Debemos decidir cuáles serán los nombres y proveer
una breve descripción de la actividad. Hay que hacer una lista de las actividades, entradas y salidas de cada uno.
Asegúrese de documentar los pasos utilizados en cada caso de uso. Éstos deben estar en la forma de reglas de
negocios que listen o expliquen las actividades humanas y del sistema que se completaron para cada caso
de uso. Si acaso es posible, liste las actividades en la secuencia en la que normalmente se ejecutarían. Después deter-
mine los datos utilizados en cada paso. Este paso es más fácil si se ha completado un diccionario de datos. Por
www.xlibros.com
206 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 7.12
Una tabla de respuesta a eventos para un escaparate en Internet.
El cliente coloca Cliente Compra del artículo Almacenar datos en el Página Web Cliente
el artículo en el (número y cantidad) Registro detallado del pedido. de artículos
carrito de compras Calcular costo de envío comprados
del escaparate mediante las tablas de envío.
Web Actualizar el total del cliente.
Actualizar la cantidad del
artículo disponible.
El cliente pasa Cliente Hace clic en el botón Mostrar página Web Página Web
a pagar “Pasar a pagar” en la del pedido del cliente. de verificación
página Web
Obtener pago Cliente Información de tarjeta Verificar el monto de la tarjeta Datos de tarjeta Compañía de
del cliente de crédito de crédito con la compañía de crédito tarjetas
de tarjetas de crédito. Retroalimentación de crédito
Enviar. del cliente Cliente
último, pida a los usuarios que revisen y sugieran modificaciones de los casos de uso. Es importante que éstos
se escriban en forma clara (en el capítulo 10 encontrará una discusión más detallada sobre el UML, los casos de
uso y los diagramas de casos de uso).
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 207
FIGURA 7.13
Número y contraseña Diagramas de flujo de datos para
1
del cliente
las primeras tres filas de la tabla
Obtener inicio Registro del cliente Archivo maestro de respuesta a eventos del
Cliente D1
Página Web de bienvenida de sesión del cliente escaparate en Internet.
del cliente
2
Información del artículo
Tarifas de envío
D8 Tablas de envíos
3. Tareas similares Si dos procesos realizan tareas similares, se pueden agrupar en un programa de
computadora.
4. Eficiencia Se pueden combinar varios procesos en un programa para un procesamiento eficiente. Por
ejemplo, si varios informes necesitan usar los mismos archivos de entrada extensos, al producirlos en
conjunto podríamos ahorrar una cantidad considerable de tiempo de ejecución de la computadora.
5. Consistencia de los datos Los procesos se pueden combinar en un programa para lograr la consistencia de
los datos. Por ejemplo, una compañía de tarjetas de crédito puede tomar una “instantánea” y producir una
variedad de informes al mismo tiempo, de manera que las cifras sean consistentes.
6. Seguridad Los procesos se pueden particionar en distintos programas por cuestiones de seguridad. Se puede
colocar una línea punteada alrededor de las páginas Web que estén en un servidor seguro para separarlas
de las páginas Web en un servidor que no esté seguro. Por lo general, una página Web que se utiliza para
obtener la identificación y contraseña del usuario se particiona para separarla de las páginas de introducción
de pedidos o de otras páginas con actividades de negocios.
www.xlibros.com
208 PARTE III • EL PROCESO DE ANÁLISIS
Nombre del
caso de uso:
Agregar art
ículo del clie
Descripción
nte
: Agrega el ID del proces
artículo para o: 3
el pedido de
Desencadena un cliente po
dor: El client r Internet.
e coloca un
artículo que
Tipo de dese desea pedir
ncadenador en el carrito
: Externo de compras.
Temporal
Nombre de
entrada
Origen
Nombre de
Artículo com salida
prado Destino
(número y
cantidad) Cliente Página Web
de
confirmación
de
artículos Cliente
comprados
Pasos realiz
ados
1. Buscar el
registro del
encontró el artículo med Información
artículo, colo iante el núm para los paso
comprados. car un mensa ero del mism s
je en la pági o. Si no se
na Web de ar Número de
tículos artíc
2. Almacenar registro de ar ulo,
los datos de tículo
l artículo en
el Registro de
3. Usar el nú detalles del pe
mero de clie dido. Registro de
nte para busc detalles
ar el registro del pedido
4. Calcular el del cliente.
Costo de en
del artículo de vío mediante Número de
l Registro de el uso de tabl cliente,
as de envíos
para buscar
el Costo de
l artículo y el
Código post . Usar el Peso registro del cliente
envío en las al del Registr Código post
Tablas de en o del cliente al, Peso del
5. Modificar víos. artículo, Tabl
el Total del cl a de envíos
Precio del ar iente mediant
tículo. Agrega e el uso de la
r el Costo de Cantidad co
envío. Actual mprada y el
izar el Regis Registro de
tro del client
FIGURA 7.14 6. Modificar e. Cantidad artículo,
la Cantidad de comprada,
l artículo disp Costo de en
Un formulario de onible y actu vío, Registro
alizar el Regis de l cliente
caso de uso para el tro del artícul
o. Cant
idad ordena
escaparate en Internet Registro de da,
describe la actividad l artículo
Agregar artículo del
cliente junto con sus
desencadenadores,
entrada y salida.
desarrollemos el diagrama de nivel 0 y los diagramas hijos) podremos usar la lista para definir los procesos,
flujos de datos y almacenes de datos.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 209
FIGURA 7.15
Un resumen de las actividades
de negocios para la División de
World’s Tren d
catálogos de World’s Trend.
1000 Intern
ational Lane
Cornwall, C
T 06050
World’s Tren
d es un prov
clientes ha eedor de pe
cen sus pe
cada catálo didos por te didos por correo de
go o lo hace léfono, enví ropa de mod
n a través an un form a y alta calid
ulario de pe
del sitio W
eb. dido que se ad. Los
Resumen incluye con
de las actividad
1. Cuando es de neg
entran ocios
como el arch los pedidos de los clie
ivo maestro nt es, se actual
departamen de clientes. iza tanto el
to de contro Si archivo mae
l de inventar un artículo no está en stro de artíc
io existencia, ul
2. Si el
pedido prov
. se notifica al os
iene de un
nuevo client
3. Se pr e, se crea un
oducen lista registro en
s de selecc el archivo m
ión de pedi aestro de cl
4. Se pr do para el pe ientes.
epara un es dido del clie
tado de cu nte y se enví
enta del en an al almac
5. El proc vío. én.
eso de envi
cotejar el es ar el pedido de
tado de cu un cliente
y enviar to enta del en implica ob
do al client vío del clie tener los ar
e. nte, obtene tícul
r la direcció os del almacén y
6. Se ge n correcta
nera el esta del cliente
al cliente un do de cuen
a vez al mes ta del cliente
. y se envía
un estado
7. Se en de cuenta
vía un info de facturac
rme de cuen ión
tas por cobr
ar al depart
amento de
contabilida
d.
FIGURA 7.16
Artículo en pedido pendiente y
Departamento Un diagrama de flujo de
de control datos a nivel de contexto
de inventario
para el sistema de
procesamiento de pedidos
en World’s Trend.
0
Pedido del cliente Pedido enviado
Información del nuevo cliente Sistema de Estado de cuenta de facturación del cliente
Cliente procesamiento Cliente
Número o descripción del artículo de pedidos Información de artículo
www.xlibros.com
210 PARTE III • EL PROCESO DE ANÁLISIS
y cinco entidades externas (las dos entidades separadas que se llaman CLIENTE son en realidad una misma).
También se muestran los flujos de datos que salen y entran en las entidades externas (por ejemplo, PEDIDO
DEL CLIENTE y LISTA DE SELECCIÓN DE PEDIDO).
FIGURA 7.17 3
Diagrama 0 del Pedido Lista de
Departamento
y Archivo maestro pendiente Producir selección del pedido
sistema de de control D2 de artículos listas de
procesamiento de inventarios selección
de pedidos para la
División de
Registro
catálogos Pedido
Artículo en pedido pendiente de artículo
de World’s Trend. pendiente
1 4
Pedido
Pedido del cliente Agregar pendiente Estado de
Cliente
pedido cuenta de Almacén
del cliente envío del
cliente
Información
Preparar estado
del nuevo
Registro de cuenta de
cliente
de cliente envío
Artículos que cumplen
2 5 con el pedido
Registro
Agregar de cliente Archivo maestro Enviar
D1
registro de de clientes pedido del Pedido enviado
cliente cliente
Nombre y dirección
del cliente
Registro
de cliente Archivo maestro
D1 Cliente
del cliente
Registro
del cliente
8 7 6
Pedido Pedido Estado de cuenta de
Consultar Producir pendiente pendiente facturación del cliente
Crear estado
información cuentas por de cuenta
de artículo cobrar del cliente
Número o Informe de
Información
descripción cuentas por
del artículo
del artículo cobrar
Departamento
Cliente de
contabilidad
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 211
más (después podrá agregar más detalles). Cuando termine de dibujar los siete procesos, dibuje flujos de datos
entre ellos y hacia las entidades externas (las mismas entidades externas que se muestran en el diagrama a nivel
de contexto). Si cree que debe haber almacenes de datos como ARCHIVO MAESTRO DE ARTÍCULOS o AR-
CHIVO MAESTRO DE CLIENTES, dibújelos y conéctelos a los procesos mediante el uso de flujos de datos.
Ahora tómese el tiempo de enumerar los procesos y almacenes de datos. Ponga atención especial al momento de
asignar etiquetas significativas. Compruebe los errores y corríjalos antes de continuar.
FIGURA 7.18
Error: no se Diagrama 1 del sistema de
encontró el cliente procesamiento de pedidos para la
División de catálogos de World’s
1.1
Pedido del Trend.
cliente Validar
Información válida del cliente
cuenta del
Información válida del cliente
cliente
Pedido del
cliente
Registro
del cliente
1.6 1.7
Pedido
Archivo maestro Registro del cliente Actualizar Crear
pendiente
D1 de clientes registro Totales Totales pedido
del cliente del pedido del pedido pendiente
1.5
Precio y peso
Archivo maestro del artículo Calcular
D2
de artículos totales del Artículo
pedido disponible
Artículo
disponible
www.xlibros.com
212 PARTE III • EL PROCESO DE ANÁLISIS
también con los almacenes de datos cuando sea apropiado. Los subprocesos no tienen que estar conectados a en-
tidades externas, ya que siempre podemos hacer referencia al diagrama de flujo de datos padre (o de nivel 0) para
identificar estas entidades. Asigne etiquetas a los subprocesos como 1.1, 1.2, 1.3, etcétera. Tómese el tiempo de
revisar errores y asegurarse de que las etiquetas tengan sentido.
FIGURA 7.19 D2
Archivo maestro
de artículos
Un diagrama hijo de flujo de
datos físico para la División
de catálogos de World’s Trend. Ubicación de recipiente
y sección del artículo
3.1 3.2
Información de Registro de artículo
Registro de pedido artículo del pedido Crear del pedido Archivo de artículos
Leer D6
registro de del pedido
registro de
artículo del
artículo
pedido
Registro de
artículo del
pedido
3.3
Ordenar
Archivo maestro artículo por
D1
de clientes ubicación
dentro del
almacén
Registro
del cliente
Registro del
artículo
ordenado
3.4
Registro del
artículo
Nombre, dirección ordenado
y teléfono del cliente
Lista de
selección del
pedido
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 213
tros, crear y actualizar archivos. La secuencia de actividades es importante en los DFD físicos, ya que se hace
énfasis en la forma en que trabajará el sistema y en qué orden ocurrirán los eventos.
Al etiquetar un modelo físico debe tener cuidado en describir el proceso con mucho detalle. Por ejemplo, el
subproceso 3.3 en un modelo lógico podría ser simplemente ORDENAR ARTÍCULO, pero en el modelo físico
sería mejor etiquetarlo como ORDENAR ARTÍCULO POR UBICACIÓN DENTRO DEL CLIENTE. Al escribir
una etiqueta para un almacén de datos, haga referencia al archivo o base de datos real, como ARCHIVO MAES-
TRO DE CLIENTES o ARCHIVO DE ARTÍCULOS ORDENADOS. Al describir los flujos de datos describa
el formulario, informe o pantalla real. Por ejemplo, al imprimir una lista de selección de pedido puede asignar al
flujo de datos el nombre LISTA DE SELECCIÓN DE PEDIDO.
www.xlibros.com
214 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 7.20 o
es un proces
El proceso 3
Particionamiento del diagrama de lot es, ya qu e tiene una
por la
mputadora,
flujo de datos (se muestra parte salida de co n de pedido
de se lec ció
del Diagrama 0). Lista dora
a de computa
y una entrad .
es ar ch ivo s)
(los tr
to
particionamien
Para indicar el os
y que ro dear los proces
ha a
solo program
Departamento Archivo maestro incluidos en un eada. El Archivo maestro
ea pu nt
de control de D2 con un a lín ento D1
de artículos garía al mom de clientes
cliente se agre
inventario loc ar un pe dido.
de co
Registro Nombre y
Registro de artículos pendientes del artículo dirección del
cliente
1 3 Lista de
Pedido del Registro selección
cliente Pendiente del pedido de pedido
Agregar D3 Archivo de pedidos Producir
Cliente Almacén
pedido del listas de
cliente selección
Información Registro
del nuevo
del pedido
cliente
Registro Registro
del cliente del artículo
Nuevo
2 4
registro Registro Registro
del cliente del cliente Preparar del artículo
Agregar Archivo maestro Archivo maestro
D1 D2
registro del de clientes estado de de artículos
cliente cuenta
de envío
Estado de cuenta
de envío del 5
Artículos del
cliente pedido
Nombre y dirección del cliente Enviar
pedido del
Detalles del envío cliente
3y4
os número
Los proces lote pero se
os en
son proces ogramas
icionar en pr
deben part e se realizan
ya qu
Cliente separados, s.
s momento
en distinto
La selección de vuelos disponibles (proceso 2) utiliza una base de datos interna, pero esta base de datos no
tiene información sobre la disponibilidad de asientos, ya que las aerolíneas reciben reservaciones de muchas or-
ganizaciones de servicios de viajes. Esto significa que debe haber un proceso separado y un pequeño programa
particionados para determinar si los asientos están disponibles y para reservar asientos específicos.
Como hay muchos procesos de entrada de usuario, se diseñan formularios para manejar todas las peticiones
relacionadas. Tener formularios separados implica que los formularios serán menos complejos, por lo que los
usuarios los encontrarán más atractivos y fáciles de llenar. Este diseño cumple con los criterios de capacidad de
uso y utilidad importantes al diseñar sitios Web para la interacción humano-computadora. También significa que
el procesamiento se realizará con más rapidez, pues una vez que seleccione el vuelo, en el siguiente paso rela-
cionado con la selección de asientos, el usuario ya no tendrá que introducir —ni ver— los detalles del vuelo otra
vez. La mayoría de los sitios Web de las aerolíneas utilizan ahora ventanas desplegables en las que los clientes
apuntan su selección de asientos.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 215
FIGURA 7.21
1
El particionamiento es
Fechas y importante para los sistemas
aeropuertos basados en Web, como lo
Cliente Seleccionar D1 Vuelo
días de vuelo demuestra este diagrama de flujo
y aeropuertos de datos físico de un sistema de
compra de boletos en línea.
8 2
Aerolínea
Producir Mostrar D2 Detalles de vuelos
boleto-e del vuelos Detalles de
cliente disponibles vuelos
disponibles
Precio y
disponibilidad de
los vuelos
Detalles de vuelos
disponibles
4 3
Selección
de vuelos
Información de vuelos
Información de Confirmación
tarjeta de crédito del crédito
Información de
7 6 tarjeta de crédito
Compra
del vuelo Hacer cargo a Sistema de
Aerolínea Actualizar tarjetas de
la tarjeta de Estado del crédito
vuelos de crédito
crédito del
aerolínea
cliente
Otro de los motivos del particionamiento es para mantener la transacción segura. Una vez seleccionado el
asiento, el cliente debe confirmar la reservación y suministrar la información de su tarjeta de crédito. Para ello se
utiliza una conexión segura, a través de la cual la compañía de tarjetas de crédito se involucra en el proceso de
validación del monto de la compra. Para la conexión segura hay que usar un proceso separado. Una vez confir-
mada la tarjeta de crédito es necesario incluir dos procesos adicionales: uno para dar formato a la confirmación
y enviarla por correo electrónico junto con un boleto-e para el cliente, y otro para enviar la notificación de la
compra del vuelo a la aerolínea.
www.xlibros.com
216 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U LT O R Í A 7 . 1
Vestuarios en
D1 y
el inventario
Pedido del
D3
cliente
Aprobación
de crédito Detalles
del pedido
Información
D2 2
del cliente
Recopilar
envío de
vestuarios
de renta
Dirección Información
del cliente de envío
3
Factura
Procesar de envío
facturas de Clientes
envío
FIGURA 7.C1
Un diagrama de flujo de datos para la empresa Merman’s Costume Rentals.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 217
La tienda (que se puede visualizar mejor como un almacén) Ahora cree a la medida la porción de devolución de renta del
abarca tres pisos llenos de estantes de vestuarios que contienen diagrama de flujo de datos anterior. Recuerde que es imprescindible
miles de disfraces colgados en conjunto por periodo histórico, para que las entregas sean oportunas para el óptimo funcionamiento de
después agruparlos con base en el género y por último con base en Merman’s.
la talla1. La mayoría de las compañías de teatro pueden ubicar con 1
Se dice que la empresa Western Costume Company en Hollywood, California,
precisión lo que necesitan por medio de la hábil ayuda de Annie. tiene más de 1 millón de vestuarios con un valor aproximado de $40 millones.
Hay que particionar todo el procedimiento en una serie de procesos relacionados, cada uno de los cuales
debe tener su correspondiente página Web o interactuar con un sistema externo. Cada vez que se utiliza un nuevo
almacén de datos para obtener datos adicionales, hay que incluir un proceso para dar formato a los datos u obte-
nerlos. Cada vez que se involucra una empresa o sistema externo, hay que particionar un proceso en un programa
separado. La tarea de revisar procesos o formularios no es primordial. El tamaño pequeño de los programas faci-
lita su modificación. De esta forma el sitio Web será seguro, eficiente y más fácil de mantener.
RESUMEN
Para comprender mejor el movimiento lógico de los datos a de datos lógico de nivel 0. Se muestran los procesos y se agre-
través de una empresa, el analista de sistemas dibuja diagramas gan los almacenes de datos. A continuación, el analista crea un
de flujo de datos (DFD). Estos diagramas son herramientas es- diagrama hijo para cada uno de los procesos en el Diagrama 0.
tructuradas de análisis y diseño, las cuales permiten al analista Las entradas y salidas permanecen constantes, pero los almace-
comprender el sistema y los subsistemas en forma visual, como nes de datos y los orígenes cambian. Al expandir el diagrama de
un conjunto de flujos de datos interrelacionados. flujo de datos original, el analista de sistemas se puede concen-
Las representaciones gráficas del almacenamiento y la trans- trar en descripciones más detalladas del movimiento de datos en
formación del movimiento de los datos se dibujan mediante el el sistema. Después, el analista desarrolla un diagrama de flujo
uso de cuatro símbolos: un rectángulo redondeado para describir de datos físico a partir del diagrama de flujo de datos lógico y lo
el procesamiento o las transformaciones de los datos, un cua- particiona para facilitar la programación. Se analiza cada proceso
drado doble para mostrar una entidad de datos externa (origen o para determinar si debe ser manual o automatizado.
receptor de los datos), una flecha para describir el flujo de datos Las seis consideraciones para particionar diagramas de
y un rectángulo con un extremo abierto para mostrar un almacén flujo de datos son: 1) que distintos grupos de usuarios realicen
de datos. los procesos, 2) que los procesos se ejecuten en los mismos
El analista de sistemas extrae los procesos, orígenes, alma- tiempos, 3) que los procesos realicen tareas similares, 4) que se
cenes y flujos de datos de las narrativas o historias de la orga- puedan combinar procesos en lote para un procesamiento efi-
nización que contaron los usuarios o que revelaron los datos, ciente, 5) que se puedan combinar los procesos en un programa
y utiliza una metodología arriba-abajo para dibujar primero un para lograr la consistencia de los datos, o 6) que los procesos
diagrama de flujo de datos a nivel de contexto del sistema con se puedan particionar en distintos programas por cuestiones de
una vista más amplia. Después se dibuja un diagrama de flujo seguridad.
www.xlibros.com
218 PARTE III • EL PROCESO DE ANÁLISIS
EXPERIENCIA DE HYPERCASE® 7
FIGURA 7.EH1
En HyperCase podemos hacer clic en los elementos de un diagrama de flujo de datos.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 219
PREGUNTAS DE REPASO
1. ¿Cuál es uno de los principales métodos disponibles que el analista puede usar para analizar sistemas orientados a datos?
2. ¿Cuáles son las cuatro ventajas de usar una metodología de flujo de datos en vez de las explicaciones narrativas del
movimiento de los datos?
3. ¿Cuáles son los cuatro elementos de datos que se pueden simbolizar en los diagramas de flujo de datos?
4. ¿Qué es un diagrama de flujo de datos a nivel de contexto? Compárelo con un DFD de nivel 0.
5. Defina la metodología arriba-abajo y su relación con la acción de dibujar diagramas de flujo de datos.
6. Describa qué significa “expandir” diagramas de flujo de datos.
7. ¿Cuáles son las concesiones implicadas en el proceso de decidir cómo se deben expandir los flujos continuos de datos?
8. ¿Por qué es tan importante etiquetar los diagramas de flujo de datos? ¿Qué pueden lograr las etiquetas efectivas en los
diagramas de flujo de datos para aquellos que no están familiarizados con el sistema?
9. ¿Cuál es la diferencia entre los diagramas de flujo de datos físico y lógico?
10. Mencione tres razones para crear un diagrama de flujo de datos lógico.
11. Mencione cinco características que se incluyen en un diagrama de flujo de datos físico y que no se encuentran en un
diagrama de flujo de datos lógico.
12. ¿Cuándo se requieren los archivos de transacciones en el diseño del sistema?
13. ¿Cómo se puede utilizar una tabla de eventos para crear un diagrama de flujo de datos?
14. Mencione las principales secciones de un caso de uso.
15. ¿Cómo se puede utilizar un caso de uso para crear un diagrama de flujo de datos?
16. ¿Qué es el particionamiento y cómo se utiliza?
17. ¿Cómo puede determinar un analista cuándo se requiere una interfaz?
18. Mencione tres formas de determinar el particionamiento en un diagrama de flujo de datos.
19. Mencione tres formas de usar los diagramas de flujo de datos completos.
PROBLEMAS
1. Hasta este punto parece tener una excelente relación de comunicación con Kevin Cahoon, el propietario de una empresa
de fabricación de instrumentos musicales. Cuando usted le mostró un conjunto de diagramas de flujo de datos que
dibujó, él no pudo ver cómo estaba descrito en los diagramas el sistema representado.
a. En un párrafo escriba en términos generales cómo podría explicar un diagrama de flujo de datos a un usuario.
Asegúrese de incluir una lista de símbolos y su significado.
b. Se requiere cierto esfuerzo para educar a los usuarios sobre los diagramas de flujo de datos. ¿Vale la pena
compartirlos con los usuarios? ¿Por qué sí o por qué no? Defienda su respuesta en un párrafo.
c. Compare los diagramas de flujo de datos con los casos de uso y los escenarios de los casos de uso. ¿Qué
muestran los diagramas de flujo de datos que los diagramas de casos de uso tienen muchas dificultades para
explicar?
2. Su proyecto más reciente es combinar dos sistemas utilizados por la empresa Producers Financial. El sistema
de aplicación de préstamos de Angie Schworer es bastante reciente, pero no tiene documentación. El sistema de
administración de préstamos de Scott Wittman es más antiguo, requiere de una buena revisión y los registros están
codificados de manera independiente al otro sistema. El sistema de aplicación de préstamos acepta solicitudes, las
procesa y recomienda los préstamos que se pueden aprobar. El sistema de administración de préstamos recibe los
préstamos que se aprobaron y les da seguimiento hasta su disposición final (pagado, vendido o moroso). Dibuje un
diagrama de contexto y un diagrama de flujo de datos de nivel 1 que muestre cómo se vería un sistema combinado
idealizado.
3. Una experiencia común que comparten todos los estudiantes en todos los colegios y universidades es la de inscribirse en
un curso universitario.
a. Dibuje un diagrama de flujo de datos de nivel 1 del movimiento de datos para inscribirse en un curso universitario.
Use una sola hoja y etiquete cada elemento de datos con claridad.
b. Expanda uno de los procesos en su diagrama de flujo de datos original en subprocesos; agregue flujos y almacenes
de datos.
c. Haga una lista de las partes del proceso de inscripción que estén “ocultas” para el observador externo y sobre las
cuales haya tenido que hacer suposiciones para completar un diagrama de segundo nivel.
4. La figura 7.EJ1 es un diagrama de flujo de datos de nivel 1 del movimiento de datos en una agencia de paseos por las
cataratas del Niágara llamada Marilyn’s Tours. Léalo y revise cualquier inconsistencia.
a. Haga una lista y enumere los errores que haya encontrado en el diagrama.
b. Vuelva a dibujar y etiquetar el diagrama de flujo de datos de Marilyn’s para corregirlo. Asegúrese de que su nuevo
diagrama emplee los símbolos en forma apropiada para reducir las repeticiones y duplicaciones en donde sea
posible.
www.xlibros.com
220 PARTE III • EL PROCESO DE ANÁLISIS
Revisar Determinar
crédito paseo
AGENTE DE deseado
VIAJES DE
AEROLÍNEA
TURISTA
TURISTA
CON TURISTA
CON PAGO
TARJETA DE
EN EFECTIVO
CRÉDITO
3
D2 FOLLETOS DE VIAJES
Hacer
reser-
vaciones
D3 ITINERARIO DE VIAJE
D4 HISTORIAL CREDITICIO
5. Perfect Pizza desea instalar un sistema para registrar los pedidos de pizzas y alitas de pollo. Cuando los clientes
frecuentes llaman a Perfect Pizza por teléfono, se les pide su número telefónico. Cuando se introduce el número en una
computadora aparecen de manera automática el nombre, la dirección y la fecha del último pedido en la pantalla. Una vez
que se toma el pedido se calcula el total, incluyendo impuestos y envío. Después se pasa el pedido al cocinero. Luego se
imprime un recibo. Algunas veces se imprimen ofertas especiales, de manera que el cliente pueda obtener un descuento.
Los repartidores que hacen las entregas dan a los clientes una copia del recibo y un cupón (si hace falta). Se mantienen
los totales semanales para compararlos con el desempeño del año anterior. Escriba un resumen de las actividades de
negocios para tomar un pedido en Perfect Pizza.
6. Dibuje un diagrama de flujo de datos a nivel de contexto para Perfect Pizza (problema 5).
7. Expanda el diagrama a nivel de contexto en el problema 6 para mostrar todos los procesos importantes. Asigne a este
diagrama el nombre Diagrama 0. Debe ser un diagrama de flujo de datos lógico.
8. Dibuje un diagrama hijo lógico para el Diagrama 0 del problema 7, para el proceso que agrega un nuevo cliente si no se
encuentra en la base de datos (que nunca haya pedido algo de Perfect Pizza antes).
9. Dibuje un diagrama de flujo de datos físico para el problema 7.
10. Dibuje un diagrama de flujo de datos físico para el problema 8.
11. Particione el diagrama de flujo de datos físico en el problema 7; agrupe y separe los procesos según lo considere
apropiado. Explique por qué particionó el diagrama de flujo de datos de esa manera (recuerde que no tiene que
particionar todo el diagrama completo, sólo las partes que considere necesario particionar).
12. a. Dibuje un diagrama hijo lógico para el proceso 6 de la figura 7.17.
b. Dibuje un diagrama hijo físico para el proceso 6 de la figura 7.17.
13. Dibuje un diagrama de flujo de datos físico para el proceso 1.1 de la figura 7.18.
14. Cree un diagrama de contexto para un agente de bienes raíces que trate de crear un sistema que relacione a los
compradores con las casas que se adapten mejor a sus requerimientos.
15. Dibuje un diagrama de flujo de datos lógico que muestre los procesos generales para el problema 14. Asigne a este
diagrama el nombre Diagrama 0.
16. Cree un diagrama a nivel de contexto para facturar en un consultorio dental. Las entidades externas incluyen a los
pacientes y las compañías de seguros.
17. Dibuje un diagrama de flujo de datos lógico que muestre los procesos generales para el problema 16. Denomine a este
diagrama Diagrama 0.
18. Cree una tabla de respuestas a eventos para las actividades enlistadas para el sistema de procesamiento de pedidos de
World’s Trend.
19. Cree un caso de uso para la lista de siete procesos para el sistema de procesamiento de pedidos de World’s Trend.
20. Cree una matriz CRUD para los archivos de World’s Trend.
21. Use los principios del particionamiento para determinar cuáles procesos del problema 18 se deben incluir en programas
separados.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 221
22. Cree un diagrama hijo de flujo de datos físico para la siguiente situación: el Grupo de usuarios de PC local sostiene
reuniones una vez al mes donde hay oradores informativos, premios de entrada y sesiones para grupos de interés
especial. Se lleva una computadora portátil a las reuniones, la cual se utiliza para agregar los nombres de los nuevos
miembros del grupo. El diagrama representa un proceso en línea y es el hijo del proceso 1, AGREGAR MIEMBROS
NUEVOS. Se incluyen las siguientes tareas:
a. Introducir la información del nuevo miembro.
b. Validar la información. Los errores se muestran en pantalla.
c. Cuando toda la información sea válida, aparecerá una pantalla de confirmación. El operador debe confirmar de
manera visual que todos los datos son correctos y debe aceptar o cancelar la transacción.
d. Las transacciones aceptadas agregan nuevos miembros al ARCHIVO MAESTRO DE MEMBRESÍAS, el cual se
guarda en el disco duro de la computadora portátil.
e. Las transacciones aceptadas se envían a un archivo DIARIO DE MEMBRESÍAS, el cual se guarda en un disco duro
secundario.
PROYECTOS EN GRUPO
1. Reúnase con su grupo para desarrollar un diagrama de flujo de datos a nivel de contexto para Maverick Transport (que
vimos por primera vez en el capítulo 4). Use los datos que haya generado posteriormente con su grupo sobre Maverick
Transport. (Sugerencia: concéntrese en una de las áreas funcionales de la empresa, en vez de tratar de modelar toda la
organización).
2. Use el diagrama a nivel de contexto que desarrolló en el problema 1 para desarrollar con su grupo un diagrama de flujo
de datos lógico de nivel 0 para Maverick Transport. Haga las suposiciones necesarias para dibujarlo. Elabore una lista de
ellas.
3. Seleccione con su grupo un proceso clave y expándalo en un diagrama hijo lógico. Haga las suposiciones necesarias para
dibujarlo. Elabore una lista de las preguntas de seguimiento y sugiera otros métodos para obtener más información sobre
los procesos que aún no le queden claros.
4. Use el trabajo que haya realizado su grupo a la fecha para crear un diagrama de flujo de datos físico de una parte del
nuevo sistema que piensa proponer a Maverick Transport.
BIBLIOGRAFÍA SELECCIONADA
Ambler, S. W. y L. L. Constantine (Eds.). The Unified Process Inception Phase: Best Practices for Implementing the Up.
Lawrence, KS: CMP Books, 2000.
Gane, C. y T. Sarson. Structured Systems Analysis and Design Tools and Techniques. Englewood Cliffs, NJ: Prentice Hall,
1979.
Hoffer, J. A., M. Prescott y H. Topi. Modern Database Management, 9ª. Edición. Upper Saddle River: Prentice Hall, 2009.
Kotonya, G. e I. Sommerville. Requirements Engineering: Processes and Techniques. Nueva York: John Wiley & Sons, 1999.
Lucas, H. Information Systems Concepts for Management, 3ª. Edición. Nueva York: McGraw-Hill, 1986.
Martin, J. Strategic Data-Planning Methodologies. Englewood Cliffs, NJ: Prentice Hall, 1982.
Thayer, R. H., M. Dorfman y D. Garr. Software Engineering: Vol. 1: The Development Process, 2ª. Edición. Nueva York: Wiley-
IEEE Computer Society Press, 2002.
www.xlibros.com
222 PARTE III • EL PROCESO DE ANÁLISIS
EPISODIO 7
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Siguiendo el flujo
Después de recopilar y analizar los resultados de las entrevistas, cuestionarios y prototipos, Anna y Chip pasan a la siguiente etapa:
modelar el sistema. Su estrategia es crear un conjunto en capas de diagramas de flujos de datos y después describir los componentes.
Anna dice: “Vamos a agregar a los diagramas de flujo de datos lógicos actuales todos los requerimientos y características
deseadas del nuevo sistema. También podemos eliminar cualquiera de las características innecesarias que no se implementarían
en el nuevo sistema”.
A continuación, Anna agrega al diagrama a nivel de contexto (que se muestra en el caso de la CPU en el capítulo 2)
muchos de los informes, consultas y demás información que se incluirá en el nuevo sistema. En la figura E7.1 se muestra el
Listado de instalación
Informe de instalaciones
Listado de instalaciones completadas 0
Informes administrativos
ID de computadora eliminada
Mantenimiento Sistema de Respuestas a consultas Administración
Información de modificación inventario de
Informe de referencias
computadoras
de computadora cruzadas de software
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 223
diagrama a nivel de contexto terminado. Observe los múltiples flujos nuevos de datos. En el sistema propuesto, el personal
de MANTENIMIENTO de computadoras recibirá los informes que no están disponibles en la actualidad. Por ejemplo, el
informe LISTADO DE INSTALACIÓN ayuda a automatizar la instalación de nuevas computadoras y otro informe adminis-
trativo llamado INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE muestra el software que se encuentra en cada
máquina.
Anna continúa: “Vamos a expandir esto en el Diagrama 0 para el nuevo sistema. Será un diagrama de flujo de datos lógico
debido a que nos enfocaremos en las necesidades de la empresa. Tal vez sería mejor si trabajáramos en equipo para este
diagrama”.
Después de trabajar durante varias horas esa tarde y una buena parte de la mañana siguiente, completan el diagrama. Lo
revisan y realizan pequeñas modificaciones. El Diagrama 0 terminado se muestra en la figura E7.2 y en la figura E7.3. Como
D6
Pedidos de computadoras FIGURA E7.2
pendientes
Diagrama 0: Sistema
Listado de instalación propuesto de inventario
Departamento Pedido
de envío/ Mantenimiento
pendiente de computadoras de la
recepción
CPU (parte 1).
2
Administración Nueva
Actualización de Soporte
computadora
instalación de oficina
Archivo maestro
D4 de computadoras
Informe de
instalación Registro de
computadora
5
9
Instalar
computadora Producir
Computadora Informe de referencias
informe
modificada cruzadas de software
de referencias
cruzadas de Administración
Listado de
instalaciones hardware/
completas software
6
Registro
Modificar
de software
computadora
Archivo maestro de
D5
software
Información de Nuevo
modificación software
de computadora
1
Formulario de software
recibido Departamento
Mantenimiento Agregar
de envío/
registro de
recepción
software
Lista de
instalación
de software
www.xlibros.com
224 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA E7.3 ID de 4
Diagrama 0: Sistema propuesto de computadora ID de computadora
eliminada eliminada
inventario de la CPU (parte 2). Eliminar
Mantenimiento
computadora
Informes de
mantenimiento
Archivo maestro de
D4
computadoras
3
Soporte Informe detallado
Registro de hardware
de oficina Subsistema
de informes Registro de software
Informes
administrativos
Administración Archivo maestro
D5
de software
Respuestas a
7
consultas
Registro de software
Consultas de la Subsistema
administración de consultas
Registro de hardware
Archivo maestro
D4
de computadoras
Consulta de Respuesta
software a consulta
Cuerpo
docente
es un diagrama lógico, no muestra ningún método físico de entrada de datos ni operaciones de validación; tampoco muestra
almacenes de datos temporales o archivos de transacciones. La sincronización no es un problema (un ejemplo es el proceso
AGREGAR COMPUTADORA NUEVA, en donde parece que los pedidos se actualizan y los informes se producen al mismo
tiempo).
“Por fin esto se ve bien”, reflexiona Chip. “Todos los procesos importantes, los flujos de datos y los almacenes de datos
están incluidos. Y el diagrama en general no se ve muy complicado”.
“Fue útil colocar todas las consultas en un subsistema y todos los informes en otro. ¿Recuerdas lo complicado que era el
diagrama original?”, pregunta Anna.
“Desde luego”, responde Chip. “Hasta llegué a pensar que estábamos tratando de abarcar mucho con este sistema. Por lo
menos ahora es más manejable. Ya que lo terminamos, ¿cuál es el siguiente paso?”.
“Necesitamos describir el Diagrama 0 con más detalle”, comenta Anna. “Para ello vamos a dibujar un diagrama de
nivel 1 para cada uno de los procesos en el Diagrama 0. Así como un padre puede tener muchos hijos, puede haber muchos
diagramas de nivel 1 para un diagrama específico de nivel 0. Por esta razón, muchos analistas los llaman diagramas padres
e hijos”.
“He estado trabajando en el Diagrama 1, una expansión del proceso 1 que se llama AGREGAR REGISTRO DE SOFT-
WARE. Tal vez te gustaría revisar el resultado final”, comenta Anna. En la figura E7.4 se muestra este Diagrama 1.
Chip y Anna utilizan Visible Analyst para verificar que la sintaxis del diagrama de flujo de datos sea correcta. Visible
Analyst también comprobará el balance de los niveles entre los procesos del diagrama de flujo de datos y los diagramas
hijos.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 225
D5
Archivo maestro FIGURA E7.4
de software
Diagrama 1: AGREGAR
Registro REGISTRO DE
de software SOFTWARE del sistema
computarizado propuesto
1.2
para la CPU.
Formulario de 1.1
software recibido Software tecleado
Teclear Validar
registro de registro de
software software
Software
válido
1.3
Software confirmado Software confirmado
Confirmar
nuevo
software
1.4
1.5
Crear archivo Agregar
de registros nuevo
de software registro de
software
Entrada en el
Nuevo
registro de
software
software
Entrada en el
registro de
software
1.6
Listado de instalación
Crear listado de software
de instalación
de software
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver el diagrama a nivel de contexto para el sistema computarizado propuesto. Si
utiliza Visible Analyst, experimente con los controles Zoom en la barra de herramientas inferior para cambiar de la vista
global a una vista detallada del diagrama. Haga doble clic en el proceso central para examinar la entrada en el repositorio
para éste. Haga clic en Exit para regresar al diagrama. Haga clic con el botón derecho en el proceso central para mostrar el
menú de objetos para el proceso central. Use la opción Explode para mostrar el Diagrama 0, el cual representa los detalles
del proceso central. Maximice la ventana y haga doble clic en algunos de los almacenes y flujos de datos para examinar sus
entradas en el repositorio. Haga clic en Exit para regresar al diagrama. Haga un acercamiento al 100 por ciento y desplácese
por la pantalla para ver las distintas regiones del diagrama; después imprima el diagrama usando una orientación panorá-
mica. Haga clic en FILE, NEST y PARENT para regresar al diagrama a nivel de contexto. Maximice la ventana.
E-2. Modifique el Diagrama 0 del sistema computarizado propuesto. Agregue el proceso 10, ACTUALIZAR REGISTRO DE
SOFTWARE. Tendrá que mover la entidad externa ADMINISTRACIÓN más abajo en el diagrama; colóquela a la iz-
quierda del proceso 7, SUBSISTEMA DE CONSULTAS. Cree una entrada en el repositorio para el proceso y después
haga clic en Exit para regresar al diagrama. Imprima el diagrama usando una orientación panorámica.
www.xlibros.com
226 PARTE III • EL PROCESO DE ANÁLISIS
E-5. Modifique el Diagrama 6, MODIFICAR REGISTRO DE COMPUTADORA. Éste es un programa en línea para modifi-
car la información de la computadora. Agregue los siguientes tres procesos. Cree entradas en el repositorio para cada uno
de los procesos, así como para el flujo de datos. Al terminar, haga un acercamiento al 100 por ciento y modifique las
flechas de flujo de datos que no estén derechas; además desplace las etiquetas de flujo de datos para obtener un gráfico
con apariencia profesional. Imprima el diagrama; use la orientación panorámica.
a. Proceso 6.6, VALIDAR MODIFICACIONES. Este proceso edita cada campo de modificación para verificar su
validez. La entrada es CAMBIOS TECLEADOS. Los campos de salida son ERRORES DE MODIFICACIÓN (flujo
de interfaz) y MODIFICACIONES VÁLIDAS (al proceso 6.7).
b. Proceso 6.7, CONFIRMAR MODIFICACIONES. Este proceso es una confirmación visual de las modificaciones.
El operador tiene la oportunidad de rechazar las modificaciones o aceptarlas. La entrada es MODIFICACIONES
VÁLIDAS. Los campos de salida son MODIFICACIONES RECHAZADAS (flujo de interfaz) y MODIFICA-
CIONES CONFIRMADAS (al proceso 6.8).
c. Proceso 6.8, REESCRIBIR ARCHIVO MAESTRO DE COMPUTADORAS. Este proceso reescribe el registro del
ARCHIVO MAESTRO DE COMPUTADORAS con las modificaciones realizadas al mismo. La entrada es MODI-
FICACIONES CONFIRMADAS. El flujo de salida es el registro del ARCHIVO MAESTRO DE COMPUTADO-
RAS, al almacén de datos ARCHIVO MAESTRO DE COMPUTADORAS.
E-6. Cree el diagrama de flujo de datos hijo para el proceso 4, ELIMINAR COMPUTADORA. La siguiente tabla sintetiza la
entrada, el proceso y la salida. Describa cada proceso y flujo de datos en el repositorio. Al terminar haga un acercamiento
al 100 por ciento, mueva las líneas de flujo de datos que no estén alineadas en forma correcta, desplace las etiquetas de
flujo de datos para obtener un gráfico con apariencia profesional e imprima el diagrama.
www.xlibros.com
CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 227
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
CAPÍTULO 8
Análisis de sistemas mediante
el uso de diccionarios de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Entender la manera en que los diccionarios de datos se emplean para analizar sistemas
orientados a objetos.
2. Crear entradas en el diccionario de datos para los procesos de datos, almacenes, flujos
y estructuras, además de los elementos lógicos y físicos de los sistemas que se
estudian, con base en los DFD.
3. Comprender el concepto de un repositorio para la información de los proyectos de los
analistas y el rol de las herramientas CASE en cuanto a su creación.
4. Reconocer las funciones de los diccionarios de datos para ayudar a los usuarios a
actualizar y dar mantenimiento a los sistemas de información.
EL DICCIONARIO DE DATOS
El diccionario de datos es una versión especializada de los diccionarios que se utilizan como
referencias en la vida cotidiana. El diccionario de datos es una obra de consulta de información
sobre los datos (es decir, metadatos); es compilado por los analistas de sistemas para guiarse
a través del análisis y diseño. Como documento, el diccionario de datos recopila y coordina
términos de datos específicos, además de confirmar lo que significa cada término para distintas
personas en la organización. Los diagramas de flujo de datos que vimos en el capítulo 7 son un
excelente punto de partida para recolectar entradas para el diccionario de datos.
Una razón importante para tener un diccionario es con el fin de mantener limpios los datos;
es decir, para conservarlos consistentes. Si usted almacena datos sobre el sexo de un hombre
como “M” en un registro, “Masculino” en un segundo registro y como el número “1” en un tercer
registro, los datos no están “limpios”. En este aspecto el diccionario de datos le será muy útil.
Los diccionarios de datos automatizados (parte de las herramientas CASE que menciona-
mos antes) son valiosos por su capacidad de realizar referencias cruzadas con los elementos de
datos para permitir los cambios necesarios en todos los programas que compartan un elemento
común. Gracias a esta característica ya no hay necesidad de modificar los programas al azar ni
esperar hasta que el programa no se ejecute debido a un cambio que no se implementó en todos
los programas que compartan el elemento actualizado. Es evidente que los diccionarios de datos
automatizados son importantes para los sistemas extensos que producen varios miles de elemen-
tos de datos para clasificarlos y usarlos en referencias cruzadas.
228
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 229
EL REPOSITORIO DE DATOS
Aunque el diccionario de datos contiene información sobre los datos y procedimientos, hay una colección más
grande de información sobre el proyecto: el repositorio. El concepto de repositorio es uno de las muchas implica-
ciones de las herramientas CASE y puede contener lo siguiente:
1. Información sobre los datos que mantiene el sistema, incluyendo flujos de datos, almacenes de datos,
estructuras de registros, elementos, entidades y mensajes.
2. Lógica de procedimiento y casos de uso.
3. Diseño de pantallas e informes.
4. Relaciones de datos, como la forma en que una estructura de datos está vinculada con otra.
5. Requerimientos del proyecto y entregables finales del sistema.
6. Información administrativa del proyecto, como calendarios de entrega, logros, cuestiones que hay que
resolver y usuarios del proyecto.
Para crear el diccionario de datos hay que examinar y describir el contenido de los flujos de datos, los almacenes de
datos y los procesos, como se muestra en la figura 8.1. Hay que definir cada almacén y flujo de datos, para des-
pués expandirlo de manera que incluya los detalles de los elementos que contiene. Debemos describir la lógica
FIGURA 8.1
Cómo se relacionan los diccionarios de datos con los diagramas de flujo de datos.
www.xlibros.com
230 PARTE III • EL PROCESO DE ANÁLISIS
de cada proceso mediante el uso de los datos que entran o salen del proceso. Hay que identificar y resolver las
omisiones y otros errores de diseño.
Hay que desarrollar las cuatro categorías del diccionario de datos (flujos de datos, estructuras de datos, ele-
mentos de datos y almacenes de datos) para promover la comprensión de los datos del sistema. En el capítulo 9
presentaremos la lógica de procedimiento, en el capítulo 13 hablaremos sobre las entidades y los capítulos 2 y 10
corresponden a los mensajes y casos de uso.
Para ilustrar la forma en que se crean las entradas en el diccionario de datos, vamos a usar un ejemplo para
la División de catálogos de World’s Trend. Esta empresa vende ropa y otros artículos por correo mediante el uso
de un sistema de pedidos vía telefónica (el formulario de pedido por correo también se puede enviar vía fax), y
a través de Internet por medio de formularios Web personalizados. Sin importar dónde se origine el pedido, los
datos subyacentes capturados por el sistema son iguales para los tres métodos.
El formulario de pedido de World’s Trend que se muestra en la figura 8.2 proporciona algunas pistas sobre
lo que se debe introducir en un diccionario de datos. En primer lugar hay que capturar y almacenar nombre, di-
rección y número telefónico de la persona que está haciendo el pedido. Después hay que tratar con los detalles
del pedido: la descripción del artículo, el tamaño, color, precio, cantidad, etcétera. También hay que determinar
el método de pago del cliente. Una vez hecho todo esto, podemos guardar estos datos para usarlos en el futuro.
Usaremos este ejemplo en todo el capítulo para ilustrar cada una de las partes del diccionario de datos.
FIGURA 8.2
Un pedido en línea de la División
de catálogos de World’s Trend.
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 231
Una vez más podemos usar nuestro ejemplo de la División de catálogos de World’s Trend del capítulo 7 para
ilustrar un formulario completo. La figura 8.3 es un ejemplo de la descripción del flujo de datos que representa
la pantalla utilizada para agregar un nuevo PEDIDO DEL CLIENTE y para actualizar los archivos de clientes y
artículos. Cabe mencionar que la entidad externa CLIENTE es el origen y que PROCESO 1 es el destino, que
provee un vínculo de vuelta al diagrama de flujo de datos. La casilla marcada como “Pantalla” indica que el flujo
representa una pantalla de entrada. Podría ser cualquier pantalla, como una página Web, una interfaz gráfica de
usuario (GUI), un teléfono celular o tal vez una pantalla de mainframe. La descripción detallada del flujo de datos
podría aparecer en este formulario, o se podría representar como una estructura de datos.
Hay que describir primero los flujos de datos para todas las entradas y salidas, ya que por lo general repre-
sentan la interfaz humana; después, los flujos de datos intermedios y los flujos de datos que entran y salen de los
almacenes de datos. Para describir los detalles de cada flujo de datos usamos elementos (a los que algunas veces
se les denomina campos), una estructura de datos o un grupo de elementos.
Podemos describir un flujo de datos simple mediante el uso de un solo elemento, como el número de cliente
que utiliza un programa de consulta para buscar el correspondiente registro de cliente.
FIGURA 8.3
Ejemplo de estructura de datos
para agregar el pedido de un
cliente en la División de catálogos
Descripción de World’s Trend.
de fl ujo de datos
ID
Nombre Pedido
del cliente
Descripción Contie
actualizar el ne la informac
archivo mae ión del pe
usa para prod stro del client dido de un cliente y se
ucir un regist e y al archivo utiliza para
ro de pedido de artículos;
. además se
Origen
Cliente Destino
Tipo de flujo Proceso 1
de datos
Archivo
Pantalla
Informe
Estructura de Formulario
datos que viaj Interno
Información a con el flujo
del pedido
Volumen/Tiem
po
Comentarios 10/hora
Información
El pedido se de l registro de pe
puede recibir dido para un
También es po a través de pedido del cl
sible que el cl Web, por corr iente.
departamen iente llame po eo electrónic
to de proces r teléfono di o o FAX.
amiento de pe rectamente
didos. al
www.xlibros.com
232 PARTE III • EL PROCESO DE ANÁLISIS
4. Los corchetes [ ] representan una situación del tipo cualquiera/o (either/or). Puede estar presente cualquier
elemento u otro, pero no ambos. Los elementos que se enlistan entre corchetes son mutuamente excluyentes.
5. Los paréntesis ( ) representan un elemento opcional. Los elementos opcionales se pueden dejar en blanco en
las pantallas de entrada de datos y pueden contener espacios o ceros para los campos numéricos en las
estructuras de archivos.
La figura 8.4 es un ejemplo de la estructura de datos para agregar el pedido de un cliente en la División de catálogos
de World’s Trend. Cada pantalla CLIENTE NUEVO consiste en las entradas que se encuentran del lado derecho de
los signos de igual. Algunas de las entradas son elementos, pero otras, como NOMBRE DEL CLIENTE, DIREC-
CIÓN y TELÉFONO, son grupos de elementos o registros estructurales. Por ejemplo, NOMBRE DEL CLIENTE
está compuesto por PRIMER NOMBRE, INICIAL SEGUNDO NOMBRE y APELLIDO PATERNO. Hay que
definir cada registro estructural de una manera más detallada hasta que todo el conjunto se descomponga en sus ele-
mentos básicos. Cabe mencionar que, después de la definición para la pantalla PEDIDO DEL CLIENTE, están las
definiciones para cada registro estructural. Incluso un campo tan simple como NÚMERO TELEFÓNICO se define
como una estructura para que el código de área se pueda procesar por separado.
FIGURA 8.4
Ejemplo de estructura de datos
Pedido del clien
para agregar el pedido de un te = Número del cli
cliente en la División de catálogos ente +
Nombre del cli
ente +
de World’s Trend. Dirección +
Teléfono +
Número de ca
tálogo +
Fecha del pedi
do +
(Artículos del
pedido dispon
Total de merca ibles) +
ncía +
(Impuestos) +
Envío y manejo
+
Total del pedido
+
Método de pa
go +
(Tipo de tarjeta
de crédito) +
(Número de ta
rjeta de crédito
(Fecha de expi )+
ración)
Nombre del cli
ente = Primer nombr
e+
(Inicial segund
o nombre) +
Apellido patern
o
Dirección =
Calle +
(Departamento
)+
Ciudad +
Estado +
CP +
(Expansión CP
)+
(País)
Teléfono =
Código de área
+
Número local
Artículos del pe
dido Cantidad orde
disponibles = nada +
Número de ar
tículo +
Descripción de
artículo +
Tamaño +
Color +
Precio +
Total de artícul
o
Método de pa
go = [Cheque | Créd
ito | Giro post
al]
Tipo de tarjeta
de [World’s Trend
crédito = | American Expr
ess | MasterC
ard | Visa]
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 233
Los registros estructurales y elementos que se utilizan en muchos sistemas reciben un nombre específico que
no es del sistema como calle, ciudad y código postal, lo cual no refleja el área funcional en la que se utilizan.
Este método permite al analista definir estos registros una vez y usarlos en muchas aplicaciones. Por ejemplo,
una ciudad puede ser la ciudad de un cliente, un proveedor o un empleado. Observe el uso de los paréntesis para
indicar que (INICIAL SEGUNDO NOMBRE), (DEPARTAMENTO) y (EXPANSIÓN CP) son información op-
cional de PEDIDO (pero no más de uno). Para indicar la condición O hay que encerrar las opciones en corchetes
y separarlas con el símbolo .
FIGURA 8.5
Elementos físicos agregados a una
Estado de cuenta
de Fecha actual + estructura de datos.
facturación de cli
ente = Número de clien
te +
Nombre del clien
te +
Dirección +
5
1 {Línea de pedid
o} +
(Monto de pago
anterior) +
Total monto deud
or +
(Comentario)
Línea de pedido
= Número de pedid
o+
Fecha de pedido
+
Total del pedido
www.xlibros.com
234 PARTE III • EL PROCESO DE ANÁLISIS
Elementos de datos
Cada elemento de datos se debe definir una vez en el diccionario de datos y también se puede introducir previa-
mente en el formulario de descripción de un elemento, como el que se muestra en la figura 8.6. Las característi-
cas que se incluyen comúnmente en el formulario de descripción de elemento son:
1. ID de elemento. Esta entrada opcional permite al analista crear entradas automatizadas en el diccionario de
datos.
2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en la manera común en que la
mayoría de los programas o el usuario principal llamen a ese elemento.
3. Los alias, que son sinónimos u otros nombres para el elemento. Los alias son nombres que utilizan distintos
usuarios en distintos sistemas. Por ejemplo, un NÚMERO DE CLIENTE también se puede llamar
NÚMERO DE CUENTA POR COBRAR o NÚMERO DE CONSUMIDOR.
4. Una descripción corta del elemento.
5. Si el elemento es base o derivado. Un elemento base es el que se teclea al sistema en un principio, como el
nombre de un cliente, la dirección o ciudad. Los elementos base se deben almacenar en archivos. Los
elementos derivados se crean a través de los procesos como resultado de un cálculo o una serie de
instrucciones de toma de decisiones.
6. La longitud de un elemento. Algunos elementos tienen longitudes estándar. Por ejemplo, en los Estados
Unidos todas las longitudes para las abreviaturas de los nombres de estados, códigos postales y números
telefónicos son iguales. Para otros elementos, las longitudes pueden variar, por lo que el analista y la
FIGURA 8.6
La descripción de un elemento
de la División de catálogos de
World’s Trend.
Formulario
de descripc
ión de elem
ID ento
Nombre Número
de cliente
Alias Número de
consumidor
Alias Número de
cuenta por
Descripción Iden cobrar
transacció tifica en fo
n de negoci rma única
os durante a un cliente
los últimos que haya re
cinco años alizado una
.
Característic
Longitud as del elem
6 ento
Formato de Punto dec.
entrada 9 (6)
Formato de Alfabético
salida 9 (6)
Valor predet Alfanuméric
erminado o
Continuo o Fecha
Discreto
Numérico
Base o
Criterios de Derivado
Continuo validación
Discreto
Límite
superior <99999 Valor
Significado
9
Límite
inferior >0
Comentario El
s número de
módulo-11. cliente debe
Es derivado pasar una
de bido a que prueba de dí
agrega un dí es generado po gito de veri
gito de veri r computado ficación
ficación. ra y se
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 235
comunidad de usuarios deben decidir en conjunto sobre la longitud final con base en las siguientes
consideraciones:
a. Para determinar las longitudes de cantidades numéricas hay que averiguar el número más grande que
puede llegar a contener esa cantidad y después permitir un espacio razonable de expansión.
b. Los campos de nombres y direcciones pueden recibir longitudes con base en la siguiente tabla. Por
ejemplo, el campo de un apellido de 11 caracteres puede alojar al 98 por ciento de los apellidos paternos
en los Estados Unidos.
c. Para otros campos, a menudo es conveniente examinar o sacar una muestra de los datos históricos que se
encuentran en la organización para determinar una longitud de campo apropiada.
Si el elemento es demasiado pequeño, se truncarán los datos que se introduzcan. El analista debe decidir
cómo afectará eso a las salidas del sistema. Por ejemplo, si se trunca el apellido paterno de un cliente, de
todas formas se entregaría el correo; pero si se trunca la dirección de correo electrónico, se devolverá como
no encontrado.
7. El tipo de datos: numérico, fecha, alfabético, carácter variable (varchar) o carácter, que algunas veces se
denomina alfanumérico o datos de texto. Los datos de caracteres variables (varchar) pueden contener
cualquier número de caracteres, hasta un límite establecido por el software de base de datos. Al usar
caracteres variables es opcional especificar la longitud. En la figura 8.7 se muestran varios de estos
formatos. Los campos de caracteres pueden contener una mezcla de letras, números y caracteres especiales.
Si el elemento es una fecha, hay que determinar su formato (por ejemplo, MMDDAAAA). Si el elemento es
numérico, hay que determinar su tipo de almacenamiento.
Los formatos de computadora personal, como moneda, número o científico, dependen de la forma en
que se vayan a utilizar los datos. Los formatos de números se pueden clasificar como entero, entero largo,
precisión simple, precisión doble, etcétera. Hay muchos otros tipos de formatos utilizados con los sistemas
FIGURA 8.7
Tipo de datos Significado
Algunos ejemplos de formatos de
Bit Un valor de 1 o 0, un valor de verdadero/falso datos utilizados en sistemas de PC.
Currency, money, smallmoney Números monetarios con precisión de cuatro lugares decimales
Cursor, timestamp, uniqueidentifier Un valor que siempre es único dentro de una base de datos
www.xlibros.com
236 PARTE III • EL PROCESO DE ANÁLISIS
de PC. Unicode es un sistema de codificación estandarizado para definir símbolos gráficos, como los
caracteres chinos o japoneses. En un capítulo posterior describiremos Unicode con más detalle. Hay tres
formatos estándar para computadoras mainframe: decimal por zonas, decimal empaquetado y binario. El
formato decimal por zonas se utiliza para imprimir y visualizar datos. El formato decimal empaquetado se
utiliza comúnmente para ahorrar espacio en las distribuciones de los archivos y para elementos que
requieren un alto nivel de operaciones aritméticas. El formato binario es adecuado para los mismos fines que
el formato decimal empaquetado, pero se utiliza con menos frecuencia.
8. Hay que incluir los formatos de entrada y salida mediante el uso de símbolos de codificación especiales para
indicar cómo se deben presentar los datos. En la figura 8.8 se muestran estos símbolos y sus usos. Cada
símbolo representa un carácter o dígito. Si se repite el mismo carácter varias veces, el carácter seguido de un
número entre paréntesis para indicar cuántas veces se repite el número se sustituye por el grupo. Por
ejemplo, XXXXXXXX se representaría como X(8).
9. Los criterios de validación para asegurar que el sistema capture datos precisos. Los elementos pueden ser
discretos para indicar que tienen ciertos valores fijos, o continuos con un rango uniforme de valores. He aquí
los criterios comunes de edición:
a. Un rango de valores es apropiado para los elementos que contienen datos continuos. Por ejemplo, en
Estados Unidos, un promedio de puntos de calificación para un estudiante puede ser del 0.00 al 4.00. Si
sólo hay un límite superior o inferior para los datos, se utiliza un límite en vez de un rango.
b. Se indica una lista de valores si los datos son discretos. Algunos ejemplos son los códigos que
representan los colores de los artículos que se venden en el catálogo de World’s Trend.
c. Una tabla de códigos es apropiada si la lista de valores es extensa (por ejemplo, abreviaciones de
estados, códigos telefónicos de países o códigos de área de teléfonos en los EE.UU.).
d. Para elementos clave o índice, a menudo se incluye un dígito de verificación.
10. Cualquier valor predeterminado que pueda tener el elemento. El valor predeterminado se muestra en las
pantallas de entrada y se utiliza para reducir la cantidad de información que tenga que teclear el operador.
Por lo general, varios campos en cada sistema tienen valores predeterminados. Cuando se emplean listas de
GUI o listas desplegables, el valor predeterminado es el que ya está seleccionado y resaltado. Al usar
botones de opción, está seleccionada la opción para el valor predeterminado, y al usar casillas de
verificación, el valor predeterminado (“sí” o “no”) determina si la casilla de verificación tendrá o no una
marca inicial en ella.
11. Un área adicional para comentarios. Ésta se podría usar para indicar el formato de la fecha, la validación
especial requerida, el método de dígito de verificación utilizado (lo cual explicaremos en el capítulo 15),
etcétera.
Tal vez las descripciones de los elementos de datos como NÚMERO DE CLIENTE se llamen NÚMERO DE
CONSUMIDOR en cualquier otra parte del sistema (es probable que debamos actualizar el código anterior es-
crito con este alias).
El elemento alfabético es otro tipo de elemento de datos. En la División de catálogos de World’s Trend, los
códigos se utilizan para describir colores: por ejemplo, BL para azul, WH para blanco y GR para verde. Al im-
plementar este elemento se necesitará una tabla para que los usuarios busquen los significados de estos códigos
(en el capítulo 15 hablaremos con más detalle sobre la codificación).
Almacenes de datos
Todos los elementos base deben estar guardados en el sistema. Los elementos derivados, como el sueldo bruto
del empleado del año a la fecha, también se pueden guardar en el sistema. Se crean almacenes de datos para cada
entidad de datos distinta que se piense guardar. Es decir, cuando se agrupan los elementos base del flujo de datos
para formar un registro estructural, se crea un almacén de datos para cada registro estructural único.
FIGURA 8.8
Carácter de formato Significado
Códigos de formato de caracteres.
X Puede introducir o visualizar/imprimir cualquier carácter
9 Se pueden introducir o visualizar sólo números
Z Visualiza los ceros a la izquierda como espacios
, Inserta comas al visualizar números
· Inserta un punto al visualizar un número
/ Inserta barras diagonales al visualizar un número
- Inserta un guión corto al visualizar un número
V Indica una posición decimal (cuando no se incluye el punto decimal)
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 237
Como tal vez un flujo de datos muestre sólo parte de los datos colectivos que contenga un registro estructu-
ral, tal vez tenga que examinar muchas estructuras de flujo de datos para obtener una descripción completa de un
almacén de datos.
La figura 8.9 es el formulario común que se utiliza para describir un almacén de datos. La información que
se incluye en el formulario es la siguiente:
1. El ID del almacén de datos. A menudo el ID es una entrada obligatoria para evitar que el analista guarde
información redundante. Un ejemplo sería D1 para el ARCHIVO MAESTRO DE CLIENTES.
2. El nombre del almacén de datos, que es descriptivo y único.
3. Un alias para la tabla, como ARCHIVO MAESTRO DE CONSUMIDORES para el ARCHIVO MAESTRO
DE CLIENTES.
4. Una descripción corta del almacén de datos.
5. El tipo de archivo, ya sea de computadora o manual.
6. El formato designa si el archivo es una tabla de base de datos o si tiene el formato de un simple archivo
plano (en el capítulo 13 describiremos con detalle los formatos de archivos).
7. El número máximo y promedio de registros en el archivo, así como el crecimiento por año. Esta información
ayuda al analista a predecir la cantidad de espacio en disco requerida para la aplicación; además es necesario
para planear la adquisición de hardware.
8. El nombre del archivo o conjunto de datos especifica el nombre del archivo, si se conoce. En las etapas de
diseño iniciales, podemos dejar este elemento en blanco. En la figura 8.10 se muestra un formulario
electrónico producido mediante el uso de Visible Analyst. Este ejemplo muestra que ARCHIVO MAESTRO
DE CLIENTES (CUSTOMER MASTER) se almacena en una computadora en la forma de una base de
FIGURA 8.9
Un ejemplo de formulario de des-
cripción de almacén de datos de la
Formulario División de catálogos de World’s
de descripc
ión de alm Trend.
acén de da
ID D1 tos
Nombre Archi
vo maestro
Alias Archivo mae de clientes
Descripción stro de co
Contiene un nsumidores
registro pa
ra cada clie
nte.
www.xlibros.com
238 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 8.10
Pantalla de Visible Analyst en la
que se muestra la descripción de
un almacén de datos.
datos con un número máximo de 45,000 registros (en el capítulo 13 explicaremos los detalles sobre los
registros y las claves que se utilizan para ordenar la base de datos).
9. La estructura de datos debe usar un nombre que se encuentre en el diccionario de datos y que provea un
vínculo a los elementos para este almacén de datos. Como alternativa se podrían describir los elementos de
datos en el formulario de descripción del almacén de datos o en la pantalla de la herramienta CASE para el
almacén de datos. Las claves primaria y secundarias deben ser elementos (o una combinación de ellos) que
se encuentren en la estructura de datos. En el ejemplo, el NÚMERO DE CLIENTE es la clave primaria y
debe ser único. El NOMBRE DEL CLIENTE, CP y MONTO COMPRADO DEL AÑO A LA FECHA son
claves secundarias que se utilizan para registrar las secuencias en los informes y localizar registros en forma
directa (en el capítulo13 hablaremos sobre las claves). Los comentarios se utilizan para la información que
no se ajusta en ninguna de las categorías anteriores; pueden incluir cuestiones sobre la sincronización de la
actualización o los respaldos, seguridad u otro tipo de consideraciones.
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 239
FIGURA 8.11
Dos diagramas de flujo de datos y sus correspondientes entradas en el diccionario
de datos para producir el sueldo de nómina de un empleado.
Es importante que los nombres de los flujos de datos en el diagrama de flujo de datos hijo estén contenidos
como elementos o registros estructurales en el flujo de datos del proceso padre. Volviendo al ejemplo, INFOR-
MACIÓN DE SALARIO (entrada en el proceso 5.3, CALCULAR MONTOS DE PAGO ACTUALES) es un
registro estructural contenido en el REGISTRO DE EMPLEADO (entrada para el proceso 5). De manera similar,
SUELDO BRUTO (salida del proceso 5.3.4, un proceso de nivel más bajo que no se muestra en la figura) está
contenido en el registro estructural MONTOS DE PAGO ACTUALES (salida del proceso padre 5.3, CALCU-
LAR MONTOS DE PAGO ACTUALES).
www.xlibros.com
240 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U LT O R Í A 8 . 1
combinan con regularidad con otros elementos en muchas estructuras se deben colocar juntos en un registro es-
tructural.
Estas consideraciones se pueden ver en el Formulario de análisis de entrada y salida para la División de catá-
logos de World’s Trend (vea la figura 8.12). En este ejemplo de un ESTADO DE CUENTA DE FACTURACIÓN
Formulari
o de análi
Nombre d sis de entr
e entrada/ ada y sali
Contacto d salida Estado de da
FIGURA 8.12 e usuario Susa
n H
cu en ta de fact
ur
Tipo de ar a n a ci ón d el cliente
Un ejemplo de un formulario de chivo
Formato d Salida
análisis de entrada/salida para la e archivo Entrada
Informe
División de catálogos de World’s Elemento(s Pantalla
) de secuen
cia Código post Indetermin
Trend. al (secuenc ado
Nombre d Número de ia de página
e elemento pe dido )
Fecha act
ual Longitud
Número de B/D Criterios d
cliente 6 e edición
Primer nom B (Sum
bre del clie 6 inistrada po
Apellido d nte D (incluye d r el sistem
el cliente 20 a)
Inicial segu B Sin es ígito de verificación
ndo nombr 15 pa ci os )
Calle e del client B Sin es
e 1 pacios
Departam B A a la
ento 20 Z o Espaci
Ciudad B Sin es o
20 pacios
Estado B Sin es
20 pacios
CP B Sin es
2 pacios
Número de B Abrev
pedido 9 iación de es
Fecha del B Num . do válid
ta
pedido 6 érico, últim a
Total del pe D > 0 as 4 opc.
dido 8
Monto de B MM/D
pago anter 9 D/AAAA
Monto tota ior D Form
l deudor 5 ato: 9 (7)V
Comentari D Form 99
o 9 ato: 9 (7)V
D Form 99
Comentari 60 ato; 9 (7)V
os Imprimir una pá B 99
los que pu gina para
edan ajust cada client
arse en un e. Si hay m
a página, ás elemen
continua.r tos de
en una segu
nda página
.
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 241
DEL CLIENTE, los elementos PRIMER NOMBRE DEL CLIENTE, APELLIDO DEL CLIENTE e INICIAL
SEGUNDO NOMBRE DEL CLIENTE se deben agrupar en un registro estructural.
FIGURA 8.13
Los almacenes de datos derivados
Archivo m
aestro de un pedido pendiente en la
de clientes Número de
= cliente + División de catálogos de World’s
Nombre de
l cliente + Trend.
Dirección
+
Teléfono +
Número de
tarj
Fecha de ex eta de crédito corpor
piración ativa +
Archivo m
aest
de artículos ro Número de
= artículo +
Precio +
Cantidad en
existencia
Registro
de pedido Número de
= cliente +
Número de
ca
Fecha del pe tálogo +
dido +
{Artículos
del pedido
Total de m disponible
ercancía + s} +
(Impuesto
s) +
Envío y man
ej
Total del pe o +
dido +
Método de
pago +
(Tipo de ta
rjet
(Número de a de crédito) +
tarjeta de cr
(Fecha de édito) +
expiración
)
Artículos de
l pedido
disponible Número de
s= artículo +
Cantidad or
denada +
Cantidad en
viada +
Precio actu
al
Método de
pago =
[Cheque
Crédito G
Tipo de tarj iro postal ]
eta
de crédito [World’s Tr
= en d Americ
an Ex press Mas
terCard Visa ]
www.xlibros.com
242 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 8.14
Estructura de datos para una lista
de selección de pedido en la
División de catálogos de World’s Lista de selecció
n de pedido =
Trend. Número de pedid
o+
Fecha del pedido
+
Número de cliente
+
Nombre del clien
te +
Dirección del clien
te +
Teléfono del clien
te +
{Selección de art
ículos del pedido}
Número de artícu +
los
Selección de artícu
los del pedido =
Número de artícu
lo +
Descripción del art
ículo +
Descripción del tam
año +
Descripción del co
lor +
Sección de almac
én +
Número de repisa
+
Cantidad ordenada
+
Cantidad seleccio
nada
Nombre del clien
te =
Primer nombre +
(Inicial segundo
nombre) +
Apellido paterno
Dirección =
Calle +
(Departamento)
+
Ciudad +
Estado +
CP +
(Expansión de CP
)+
(País)
Teléfono
Código de área +
Número local
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 243
World’s Trend
Número de pedido: Lista de selección de
999999 pedido
Número de cliente:
999999
Fecha del pedido Z9/99/
Nombre: 9999
XXXXXXXXXXXXXXXX
Calle: XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX
Departamento: XXXXXXXXXXXX
XXXXXXXX
Ciudad, estado, CP
XXXXXXXXXXXXXXXX
País: XXXXXXXXXXXX, XX
XXXXXXXXXXXXXXXX 99999-ZZZZ
Teléfono: XXXXXXXXXXXX
(999) 999-9999
---- Cantidad ----
Seleccionada Ordenada Número Número
Sección de repisa de artícu
lo Descripción del art
ículo
ZZZZ9 XXXXX Tamaño
99999 999999 Color
ZZZZ9 XXXXX XXXXXXXXXXXXXXXX
99999 999999 XXXXXXXXXXXX
ZZZZ9 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXX 99999 XXXXXXXXXXXX XXXXXXXX
ZZZZ9 999999 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXX 99999 XXXXXXXXXXXX XXXXXXXX
ZZZZ9 999999 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXX 99999 XXXXXXXXXXXX XXXXXXXX
ZZZZ9 999999 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXX 99999 XXXXXXXXXXXX XXXXXXXX
ZZZZ9 999999 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXX 99999 XXXXXXXXXXXX XXXXXXXX
ZZZZ9 999999 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXX 99999 XXXXXXXXXXXX XXXXXXXX
999999 XXXXXXXXXXXXXXXX XXXXXXXXXXXX
XXXXXXXXXXXX XXXXXXXX
XXXXXXXXXXXX
Número de artículos XXXXXXXX
: Z9
FIGURA 8.15
Lista de selección de pedido creada a
partir del diccionario de datos.
REPISA, NÚMERO DE ARTÍCULO, DESCRIPCIÓN DEL ARTÍCULO, TAMAÑO y COLOR forman una se-
rie de columnas, ya que son los elementos repetitivos.
La estructura de datos y los elementos para un almacén de datos se utilizan comúnmente para generar el
correspondiente código fuente en lenguaje de computadora, el cual se incorpora a su vez en los programas de
computadora. Podemos utilizar el diccionario de datos junto con el diagrama de flujo de datos para analizar el
diseño del sistema, detectar fallas y áreas que necesiten aclaración. 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
para el proceso que produce la salida. Los elementos base se teclean; nunca deben ser creados por un proceso.
2. Un elemento derivado debe ser creado por un proceso y debe estar en la salida de por lo menos un proceso
del cual no sea entrada.
3. Los elementos presentes en un flujo de datos entrante o saliente de un almacén de datos deben estar
contenidos en el almacén de datos.
Si se empieza en las primeras etapas de las fases de análisis y diseño, el diccionario de datos nos puede ahorrar
muchas horas. Éste es la única fuente común en la organización para responder preguntas y resolver disputas sobre
cualquier aspecto de la definición de datos. Un diccionario de datos actualizado puede constituir un excelente marco
de referencia para los esfuerzos de mantenimiento en sistemas con los que no estemos familiarizados. Los dicciona-
rios de datos automatizados pueden servir como referencias tanto para las personas como para los programas.
www.xlibros.com
244 PARTE III • EL PROCESO DE ANÁLISIS
tacionales y distinto software, o distintos sistemas de administración de bases de datos (por ejemplo, cuando una
empresa utiliza Oracle y otra utiliza DB2 de IBM). Si todos usaran el mismo software o sistema de administra-
ción de bases de datos, el XML se utilizaría muy poco.
Una vez creado un documento de XML, podemos transformar los datos en varios formatos de salida, para
visualizarlos en muchas formas, incluyendo la salida impresa, páginas Web, la salida para un dispositivo portátil
y archivos de formato de documento portable (PDF). Por ende, el contenido de datos del documento se separa
del formato de salida. El contenido de XML se define una vez como datos y después se transforma todas las ve-
ces que sea necesario.
La ventaja de usar un documento de XML es que el analista puede seleccionar sólo los datos que necesitan
un departamento interno o un socio interno para poder funcionar. Esto ayuda a asegurar la confidencialidad de
los datos. Por ejemplo, una empresa de embarques puede recibir sólo el nombre del cliente, la dirección, el nú-
mero de artículo y la cantidad a enviar, pero no la información sobre la tarjeta de crédito u otros datos financie-
ros. Este eficiente método también reduce la sobrecarga de información.
Por lo tanto, el XML es una forma de definir, ordenar, filtrar y traducir datos en un lenguaje de datos univer-
sal que todos puedan utilizar. El XML se puede crear a partir de bases de datos, un formulario o programas de
software, o se puede teclear directamente en un documento, editor de texto o programa para introducir XML.
El diccionario de datos es un punto de inicio ideal para desarrollar contenido de XML. La clave para usar el
XML es crear una definición estándar de los datos. Para lograr esto hay que usar un conjunto de etiquetas o nom-
bres de datos que se incluyan antes y después de cada elemento o estructura de datos. Las etiquetas se convierten
en los metadatos, o datos sobre los datos. Éstos se pueden seguir dividiendo en elementos y estructuras de menor
tamaño hasta que se definan todos los elementos. Los elementos de XML también pueden incluir atributos: una
pieza de datos adicional que se incluye con la etiqueta y describe algo sobre el elemento de XML.
La figura 8.16 muestra un diccionario de datos que contiene información sobre cliente, pedido y pago. La
colección general de clientes se incluye en lo que se denomina elemento raíz: clientes. Un documento de XML
puede contener sólo un elemento raíz, por lo que a menudo es el plural de los datos contenidos en el documento
de XML. Cada cliente puede colocar muchos pedidos. La estructura se define en las dos columnas izquierdas
y el código de XML aparece a la derecha. Como puede ver, CLIENTE consiste en NOMBRE, DIRECCIÓN,
SALDO ACTUAL, varias entradas INFORMACIÓN DE PEDIDO y un PAGO. Algunas de estas estructuras se
subdividen todavía más.
El documento de XML tiende a reflejar la estructura del diccionario de datos. La primera entrada (además de
la línea de XML que identifica el documento) es <cliente>, la cual define la colección completa de información
del cliente. Los símbolos menor que (<) y mayor que (>) se utilizan para identificar los nombres de las etiquetas
(en forma similar al HTML). La última línea del documento de XML es una etiqueta de cierre, </cliente>, que in-
dica el final de la información del cliente.
El cliente se define primero y contiene un atributo, el número de cliente. A menudo hay un debate en cuanto
a si debemos almacenar los datos como un elemento o un atributo. En este caso se almacenan como atributo.
La etiqueta de nombre <nombre> se define a continuación, ya que es la primera entrada en el diccionario de
datos. NOMBRE es una estructura que consiste en APELLIDO PATERNO, PRIMER NOMBRE y una INICIAL
DE SEGUNDO NOMBRE opcional. En el documento de XML esta estructura empieza con <nombre> y va se-
guida de <apellidopaterno>, <primernombre> y <inicialsegundonombre>. Como no se permiten espacios en los
nombres de las etiquetas de XML, por lo general se utiliza un guión bajo para separar las palabras. La etiqueta de
cierre </nombre> indica el final del grupo de elementos. Al utilizar una estructura como nombre podemos ahorrar
tiempo y código si la transformación muestra el nombre completo. Cada uno de los elementos hijos estará en una
línea separada por un espacio. El nombre también contiene un atributo, ya sea I de individuo o C de corporación.
Se utiliza la sangría para mostrar qué estructuras contienen elementos. Cabe mencionar que <direccion> es
similar a <cliente>, pero cuando llegamos a <informacion_pedido> hay una gran diferencia.
Hay varias entradas para <informacion_pedido>, cada una de las cuales contiene un <numero_pedido>, <fe-
cha_pedido>, <fecha_envio> y <total>. Como el pago se hace por cheque o tarjeta de crédito, puede haber sólo
una de estas dos opciones presentes. En nuestro ejemplo, el pago se hace por cheque. Las fechas tienen un atri-
buto conocido como formato, el cual indica si la fecha aparece como mes, día año; como año, mes, día; o como
día, mes, año. Si se utiliza una tarjeta de crédito para hacer un pago, un atributo TIPO contiene una M, V, A, D, o
una O para indicar el tipo de tarjeta de crédito (MasterCard, Visa u otro tipo).
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 245
Diccionario de da
tos
XML
Cliente =
Nombre +
Dirección + <?xml version="1
.0">
Saldo actual + <clientes>
{Información de pe <cliente numero=
dido} + "C15008">
Pago <nombre tipo="I">
<apellidopaterno>S
tadler</apellidopate
<primernombre>K rno>
aren</primernom
<inicial_segundon bre>
Nombre = ombre>L</inicial_s
Apellido paterno </nombre> egundonombre>
+
Primer nombre + <direccion>
(Inicial segundo no <calle>123 Oak Str
mbre) eet</calle>
<departamento>Su
ite 16</departam
<ciudad>Madison< ento>
Dirección = /ciudad>
Calle + <estado>WI</estad
o>
(Departamento) + <cp>43704</cp>
Ciudad + <pais>Estados Un
idos</pais>
Estado + </direccion>
CP + <saldo_actual>123
.45</saldo_actua
País <pedido numero_ l>
cliente="C15008">
<numero_pedido
>00123</numero
<fecha_pedido for _pedido>
Información mato="aaaammdd
Número de pedid <fe ch a_ en vio ">2008-06-23</fe
de pedido = o+ formato="aaaamm cha_pedido>
Fecha de pedido + <total>1345.89</to dd">2008-06-25<
tal> /fecha_pedido>
Fecha de envío + </p edido>
Total <pedido numero_
cliente="C15008">
<numero_pedido
>00127</numero
<fecha_pedido for _pedido>
mato="aaaammdd
<fecha_envio forma ">2008-09-18</fe
Pago = to="aaaammdd">2 cha_pedido>
[Cheque Tarjeta de <total>240.00</tota 008-09-26</fecha_
crédito] + l> pedido>
Fecha de pago + </p edido>
Monto de pago <pago>
<cheque>
Cheque = <numero_cheque>
Número de cheque 7234</numero_c
</cheque> heque>
<fecha_pago forma
to="aaaammdd">2
<monto_pago>158 008-09-30</fecha_
Tarjeta de crédito = 5.89</monto_pago pago>
Número de tarjeta <pago> >
de crédito +
Fecha de expiració <cliente>
n
</clientes>
FIGURA 8.16
Uso de una entrada en el diccionario de datos para desarrollar contenido de XML. El
documento de XML refleja la estructura del diccionario de datos.
DTD si se ha completado un diccionario de datos, ya que significa que el analista trabajó con los usuarios y tomó
decisiones en cuanto a la estructura de los datos.
La figura 8.17 ilustra la definición de tipo de documento para el documento de XML llamado Cliente. Las
palabras clave tales como !DOCTYPE, que indica el inicio de la DTD, deben estar todas en mayúsculas. !ELE-
MENT describe un elemento y !ATTLIST describe un atributo; se enlista el nombre del elemento seguido por el
nombre del atributo. Un elemento con la palabra clave #PCDATA (Parsed Character Data, o datos tipo carácter
analizados) es un elemento primitivo que ya no se define con más detalle. Un elemento que tiene una serie de
otros elementos entre paréntesis indica que son elementos hijos y deben estar en el orden listado. La instrucción
<!ELEMENT nombre (apellidopaterno, primernombre, inicial_segundonombre?)> indica que el nombre debe
tener el apellido paterno, seguido del primer nombre, seguido de la inicial del segundo nombre. El signo de
www.xlibros.com
246 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 8.17
Una definición de tipo de
documento para el documento
de XML cliente.
interrogación después de “inicial_segundonombre” significa que el elemento es opcional y se puede omitir del
documento para un cliente específico. Un signo positivo indica que hay uno o más elementos que se pueden
repetir. Los clientes deben contener por lo menos una etiqueta de cliente, pero pueden contener muchas de estas
etiquetas. Un asterisco significa que hay cero o más de los elementos. Cada cliente puede tener cero o más pe-
didos. Una barra vertical separa dos o más elementos hijos que son mutuamente excluyentes. El pago contiene
ya sea cheque o tarjeta de crédito como opción.
La definición de la lista de atributos para un número de cliente contiene un ID de palabra clave (en letras ma-
yúsculas). Esto significa que el atributo número debe aparecer sólo una vez en el documento de XML como atri-
buto para un elemento con un ID. Esto es algo similar a una clave primaria; la diferencia es que, si el documento
tuviera distintos elementos, cada uno con un atributo ID, el ID dado (C15008 en este ejemplo) podría aparecer
sólo una vez. Un ID debe empezar con una letra o guión bajo y no puede ser únicamente un número. La razón
para poner el número de cliente como ID es para asegurar que no se repita en un documento más extenso. La pala-
bra clave #REQUIRED significa que el atributo debe estar presente. La palabra clave #IMPLIED significa que el
atributo es opcional. Un documento también puede tener un atributo IDREF, el cual vincula un elemento con otro
que sea ID. La etiqueta PEDIDO tiene un atributo numero_cliente definido como IDREF y el valor C15008 debe
estar presente en un ID en alguna parte del documento. Una lista de atributos que contenga valores entre parénte-
sis significa que el atributo debe contener uno de los valores. La definición de DTD <!ATTLIST tarjeta_credito
tipo (M|V|A|D|O) #REQUIRED> significa que el tipo de tarjeta de crédito debe ser M, V, A, D u O.
Esquemas de XML
Un esquema es otra manera más precisa de definir el contenido de un documento de XML. Los esquemas pueden
incluir el número exacto de veces que puede ocurrir un elemento, así como el tipo de datos dentro de los elemen-
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 247
EXPERIENCIA DE HYPERCASE® 8
FIGURA 8.HC1
En HyperCase podemos ver el
diccionario de datos que se
mantiene en MRE.
tos, como los valores tipo carácter o numérico, incluyendo la longitud del elemento, los límites sobre los datos y
el número de lugares a la izquierda y derecha de un número decimal.
Un diccionario de datos es un excelente punto de partida para desarrollar un documento de XML y un tipo
de documento de definición o esquema. La ventaja de usar XML para definir datos es que, en el formato de
XML, los datos se almacenan en texto puro y no dependen de ningún software propietario. El documento se
puede validar y transformar fácilmente en muchos formatos distintos de salida.
Los grupos u organizaciones industriales pueden estar involucrados en la definición de una estructura de
XML específica de la industria, de manera que todas las partes involucradas comprendan lo que significan los
datos. Esto es muy importante cuando el nombre de un elemento puede tener distintos significados. Un ejemplo
www.xlibros.com
248 PARTE III • EL PROCESO DE ANÁLISIS
es “estado”, el cual puede significar la abreviación de un estado postal, o el estado de un pedido o cuenta. En el
sitio Web www.xml.org encontrará ejemplos de definiciones de tipo de documento y esquemas de XML.
RESUMEN
Mediante el uso de una metodología arriba-abajo, el analista de y los entregables finales del sistema; además de la información
sistemas utiliza los diagramas de flujo de datos para empezar a administrativa del proyecto.
compilar un diccionario de datos, una obra de consulta que con- Cada entrada en el diccionario de datos contiene el nombre del
tiene datos sobre los datos, o metadatos, de todos los procesos, elemento, una descripción en español, los alias, los elementos de
almacenes, flujos y estructuras de datos, además de todos los datos relacionados, el rango, la longitud, la codificación y la infor-
elementos lógicos y físicos del sistema que se está estudiando. mación de edición necesaria. El diccionario de datos es útil en todas
Una manera de empezar es incluir todos los elementos de datos las fases de análisis, diseño y en última instancia, de documenta-
de los diagramas de flujo de datos. ción, ya que es la fuente de autoridad que describe cómo se usa un
Un repositorio es una colección más grande de información elemento de datos y cómo lo definen los usuarios en el sistema.
sobre el proyecto. Las herramientas CASE permiten al analista Muchos sistemas grandes incluyen diccionarios de datos compu-
crear un repositorio que pueda incluir información sobre flujos tarizados que realizan referencias cruzadas en todos los programas
de datos, almacenes, estructuras de registros y elementos; sobre en la base de datos que utilizan un elemento de datos específico. El
el diseño de pantallas e informes de la lógica de procedimiento; diccionario de datos también se puede usar para crear XML que
y sobre las relaciones de los datos. Un repositorio también puede permita a las empresas con distintos sistemas, software o sistemas
contener información sobre los requerimientos de los proyectos de administración de bases de datos, intercambiar información.
PREGUNTAS DE REPASO
1. Defina diccionario de datos y metadatos.
2. ¿Cuáles son las cuatro razones para compilar un diccionario de datos completo?
3. ¿Qué información está contenida en el repositorio de datos?
4. ¿Qué es un registro estructural?
5. Haga una lista de las ocho categorías específicas que debe contener cada entrada en el diccionario de datos. Mencione
una definición breve de cada categoría.
6. ¿Cuáles son las diferencias básicas entre las entradas en el diccionario de datos preparadas para los almacenes de datos,
las estructuras de datos y los elementos de datos?
7. ¿Por qué se utilizan registros estructurales?
8. ¿Cuál es la diferencia entre estructuras de datos lógicas y físicas?
9. Describa la diferencia entre elementos base y derivados.
10. ¿Cómo se relacionan las entradas en el diccionario de datos con los niveles en un conjunto de diagramas de flujo de
datos?
11. Haga una lista de los cuatro pasos que se deben llevar a cabo para compilar un diccionario de datos.
12. ¿Por qué la compilación del diccionario de datos no se debe ver como un final en sí?
13. ¿Cuáles son los principales beneficios de usar un diccionario de datos?
14. ¿Qué describe el lenguaje de marcado extensible (XML)?
15. ¿Qué es una definición de tipo de documento?
16. ¿Cómo ayuda una definición de tipo de documento a asegurar que un documento de XML contenga todos los elementos
necesarios?
17. ¿Cuándo se deben usar atributos en un documento de XML?
18. ¿Qué asegura un atributo ID?
19. ¿Qué valida un atributo IDREF?
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 249
PROBLEMAS
1. Con base en la figura 7.EJ1 del capítulo 7, Joe, uno de los miembros de su equipo de análisis de sistemas, hizo la
siguiente entrada en el diccionario de datos que utiliza Marilyn’s Tours:
ELEMENTO DE DATOS = TURISTA* * * * PAGO
ALIAS = PAGO TURISTA
CARACTERES = 12-24
RANGO = $5.00-$1,000
VARIABLES = $5.00, $10.00, $15.00 hasta $1,000, y cualquier cosa entre ese rango en dólares y centavos.
PARA CALCULAR = COSTO TOTAL DE TODOS LOS PASEOS, CUALQUIER IMPUESTO APLICABLE DEL
ESTADO DE N.Y., menos los DEPÓSITOS DE RESERVACIÓN realizados.
a. ¿Es éste un verdadero elemento de datos? ¿Por qué sí o por qué no?
b. Vuelva a escribir la entrada en el diccionario de datos para PAGO DE TURISTA y reclasifíquela si es necesario. Use
la forma apropiada para la clasificación que elija.
2. Sue Kong, la analista de sistemas, ha realizado un progreso considerable para comprender el movimiento de datos en
Shanghai Megabank. Para compartir lo que ha hecho con los demás miembros de su equipo, así como con el jefe de
operaciones regionales, está formando un diccionario de datos.
a. Escriba una entrada en el diccionario de datos de Sue para tres de los flujos de datos en la banca regional. La entrada
deberá estar lo más completa que sea posible.
b. Escriba una entrada en el diccionario de datos de Sue para tres de los almacenes de datos en la banca regional. La
entrada deberá estar lo más completa que sea posible.
3. Jorge Alvarez, el gerente de la librería con la que su equipo de análisis de sistemas ha estado trabajando para crear un
sistema de inventario computarizado, siente que uno de los miembros de su equipo está convirtiéndose en una verdadera
molestia al hacerle preguntas en extremo detalladas sobre los elementos de datos utilizados en el sistema. Por ejemplo,
pregunta: “Jorge, ¿cuánto espacio, en caracteres, ocupa el listado de un ISBN?”.
a. ¿Cuáles son los problemas que se crean al ir directamente con el gerente y hacerle preguntas relacionadas con las
entradas en el diccionario de datos? Use un párrafo para listar los problemas que pueda ver con el método del
miembro de su equipo.
b. Explique en un párrafo al miembro de su equipo cómo puede obtener información de una mejor manera para el
diccionario de datos.
4. Michael Bush es propietario de una tienda especializada en ropa y accesorios de viaje. Los fabricantes tienen su propia
codificación, pero hay muchos fabricantes. Establezca elementos de datos para seis distintos sombreros de viaje de tres
distintos proveedores.
5. Michael (del problema 4) también ensambla paquetes de kits para acampar. Cada kit es un grupo de cuatro productos
separados que se venden en un paquete. Cada paquete (conocido como PRODUCTO) se construye mediante el uso de
muchas piezas, las cuales varían de un producto a otro. A través de las entrevistas con el jefe de piezas se obtuvo una
lista de elementos para la página Web PIEZAS DE PRODUCTO, la cual muestra qué piezas se utilizan en la fabricación
de cada producto. En la figura 8.EJ1 se muestra un prototipo de la página Web PRODUCTO-PIEZA (PRODUCT-
PART). Cree una entrada de estructura de datos en el diccionario para PRODUCTO-PIEZA.
FIGURA 8.EJ1
Un prototipo de la página Web
PRODUCTO-PIEZA (PRODUCT-
PART).
www.xlibros.com
250 PARTE III • EL PROCESO DE ANÁLISIS
6. Analice los elementos encontrados en la página Web PRODUCTO-PIEZA y cree la estructura de datos para los
almacenes de datos ARCHIVO MAESTRO DE PRODUCTO y ARCHIVO MAESTRO DE PIEZA.
7. ¿Cuáles de los elementos en la página Web PRODUCTO-PIEZA son elementos derivados?
8. La empresa Pacific Holiday Company hace los arreglos para las vacaciones en crucero de duraciones variables en
diversas ubicaciones. Cuando los clientes llaman para verificar la disponibilidad de un crucero se utiliza una
CONSULTA DE DISPONIBILIDAD DE CRUCERO, la cual se muestra en la página 8.EJ2, para proveerles la
información. Cree la estructura del diccionario de datos para la CONSULTA DE DISPONIBILIDAD DE CRUCERO.
FIGURA 8.EJ2
Una pantalla que muestra la
disponibilidad de un crucero.
INFORMACIÓN DE CRUCERO
BARCO CRUCERO XXXXXXXXXXXXXXXXXXX
UBICACIÓN XXXXXXXXXXXXXXXXXXX
FECHA DE INICIO Z9-ZZZ-9999 FECHA DE TERMINACIÓN Z9-ZZZ-9999
NÚMERO DE DÍAS ZZ9
COSTO ZZ,ZZZ.99
DESCUENTOS ACEPTADOS XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXXX
VACANTES DISPONIBLES ZZ ZZ9
9. Haga una lista de los archivos maestros que serían necesarios para implementar la CONSULTA DE DISPONIBILIDAD
DE CRUCERO.
10. Los siguientes puertos de parada están disponibles para la empresa Pacific Holiday Company:
Cree el elemento PUERTO DE PARADA. Examine los datos para determinar la longitud y el formato del elemento.
11. Raúl Esparza, gerente de comercio electrónico de Moonlight Mugs, una empresa que vende tazas de café personalizadas,
desea enviar información a otra empresa que mantiene el almacén y provee servicios de envío. La información de los
pedidos se obtiene a través de un sitio Web seguro, incluyendo el número de cliente, nombre y dirección, número
telefónico, dirección de correo electrónico, número y cantidad de producto, así como la información de la tarjeta de
crédito. Puede haber distintos productos que se envíen en un pedido. La empresa de envío maneja artículos para otros
negocios pequeños también. Defina un documento de XML que incluya sólo la información que necesite la empresa de
envío para enviar los artículos al cliente.
12. Una vez enviado el pedido del problema 11, la empresa de envío devuelve la información a Moonlight Mugs, incluyendo
el nombre y la dirección del cliente, el número de rastreo del envío, los datos enviados, la cantidad ordenada, la cantidad
enviada y la cantidad pendiente. Defina un documento de XML que incluya la información que se envía a Moonlight
Mugs.
13. Cree una definición de tipo de documento para el problema 11.
14. Western Animal Rescue es una organización sin fines de lucro que brinda apoyo para la adopción temporal y permanente
de animales, como gatos, perros y aves. Las personas se pueden registrar para adoptar animales. Otros se registran y
agregan animales para adopción. Cree la estructura de diccionario de datos que represente a una persona que se registre
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 251
para adoptar un animal. Incluya el nombre, la dirección (calle, ciudad, estado o provincia, código postal o código de correo),
número telefónico, dirección de correo electrónico, fecha de nacimiento, mascotas actuales (tipo, raza, edad de la
mascota) y referencias. Cada persona puede tener varias mascotas y debe tener por lo menos tres referencias. Éstas
deben incluir el nombre, la dirección, número telefónico, dirección de correo electrónico y cómo conocen a la persona
que se registró para adoptar un animal. Asegúrese de incluir la notación para los elementos repetitivos y los elementos
opcionales.
15. Defina la longitud, el tipo de datos y los criterios de validación para cada uno de los elementos del problema 14.
16. Haga una lista de los almacenes de datos que se requerirían para implementar a la persona que se registra en el problema 14.
17. Cree un documento de XML con datos de muestra para una persona que se registre para adoptar a un animal.
PROYECTOS EN GRUPO
1. Reúnase con su grupo y use una herramienta CASE o un procedimiento manual para desarrollar entradas en el
diccionario de datos para un proceso, flujo de datos, almacén de datos y estructura de datos con base en los diagramas de
flujo que completó para Maverick Transport en los ejercicios en grupo del capítulo 7. Como grupo, lleguen a un acuerdo
en cuanto a las suposiciones necesarias para realizar entradas completas para cada elemento de datos.
2. Su grupo deberá desarrollar una lista de métodos para ayudarle a realizar entradas completas en el diccionario de datos
para este ejercicio, así como para futuros proyectos. Por ejemplo, estudiar los informes existentes, basarse en diagramas
de flujo de datos nuevos o existentes, etcétera.
BIBLIOGRAFÍA SELECCIONADA
Baskerville, R. y J. Pries-Heje. “Short Cycle Time Systems Development”. Information Systems Journal, Vol. 14, 2004, pp.
237-264.
Conboy, K. y B. Fitzgerald. “Toward a Conceptual Framework of Agile Methods: A Study of Agility in Different Disciplines”,
WISER ’04, 5 de noviembre de 2004, Newport Beach, CA, pp. 37-44.
Davis, G. B. y M. H. Olson. Management Information Systems, Conceptual Foundations, Structure, and Development, 2ª. Edi-
ción. Nueva York: McGraw-Hill, 1985.
Gane, C. y T. Sarson. Structured Systems Analysis and Design Tools and Techniques. Englewood Cliffs, NJ: Prentice Hall,
1979.
Hoffer, J. A., M. Prescott y H. Topi. Modern Database Management, 9ª. Edición. Upper Saddle River, NJ: Prentice Hall,
2009.
Lucas, H. Information Systems Concepts for Management, 3ª. Edición. Nueva York: McGraw-Hill, 1986.
Martin, J. Strategic Data-Planning Methodologies. Englewood Cliffs, NJ: Prentice Hall, 1982.
Sagheb-Tehrani, M. “Expert Systems Development and Some Ideas of Design Process”. ACM SIGSOFT Software Engineering
Notes, Vol. 30, Núm. 2, marzo de 2005, pp. 1-5.
Schmidt, A. Working with Visible Analyst Workbench for Windows. Upper Saddle River, NJ: Prentice Hall, 1996.
Subramaniam, V. y A. Hunt. Practices of an Agile Developer. Raleigh, NC: Pragmatic Bookshelf, 2006.
www.xlibros.com
252 PARTE III • EL PROCESO DE ANÁLISIS
EPISODIO 8
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 253
FIGURA E8.1
Pantalla de descripción de
registros, ARCHIVO MAESTRO
Archivo maestro de software
DE SOFTWARE.
Almacén de datos
“¡Excelente!” piensa Anna para sí misma. “Es muy fácil introducir los detalles, y al usar este método no olvidaré describir
un elemento”.
Chip también está impresionado con la simpleza en la creación del diccionario de datos. Con base en un proceso similar
al de Anna, crea una descripción de registro para el ARCHIVO MAESTRO DE COMPUTADORAS, que contiene una tabla de
cinco tableros internos y dos registros estructurales, EQUIPO PERIFÉRICO e INFORMACIÓN DE MANTENIMIENTO. El
área Composition para introducir los nombres de los registros o elementos es una región desplazable, lo que significa que se
pueden teclear más líneas de las que caben en el área de visualización. A medida que se agregan entradas a la parte inferior de
la región, las entradas de la parte superior se desplazan fuera del área.
A medida que se agregan elementos al registro, Chip decide describir cada uno con detalle. La pantalla de descripción de
elemento para NÚMERO DE INVENTARIO DE HARDWARE se muestra en la figura E8.2. Observe las áreas para introducir
los atributos de los elementos. Es posible incluir varios alias junto con una definición. Un área llamada Notes (Notas) contiene
FIGURA E8.2
Pantalla de descripción de
elemento, NÚMERO DE
Número de inventario de hardware
INVENTARIO DE HARDWARE.
www.xlibros.com
254 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA E8.3
NÚMERO DE INVENTARIO DE
HARDWARE, visualización de las
Número de inventario de hardware
características del elemento.
cualquier otra información útil sobre el elemento. Chip y Anna emplean esta área para agregar más criterios de edición y demás
notación útil. La descripción para el NÚMERO DE INVENTARIO DE HARDWARE detalla la forma en que se utiliza este
número para llevar un rastro físico de las máquinas.
Al hacer clic en la ficha Physical Characteristics (Características físicas) aparece una segunda pantalla para NÚMERO
DE INVENTARIO DE HARDWARE, que se muestra en la figura E8.3. Esta pantalla contiene un área que muestra las estruc-
turas dentro de las que está contenido el elemento, así como un área para el tipo de datos, la longitud y la imagen utilizada para
describir el formato de los datos. Cada imagen es una entrada codificada que indica cuál debe ser el formato del elemento. Al-
gunos ejemplos de los códigos son:
Chip tiene cuidado de incluir entradas completas para estas áreas, incluyendo los valores predeterminados y si la entrada
puede ser nula o no.
Anna y Chip repiten este proceso para todos los elementos que se encuentran en cada registro. El esfuerzo lleva mucho
tiempo pero vale la pena. Después de crear los primeros registros se vuelve más fácil la creación del resto de las estructuras de
registros. Visible Analyst cuenta con una herramienta de búsqueda que provee listas de los elementos contenidos en el diseño.
“Creo que hemos diseñado un conjunto completo de elementos”, dice Chip en una reunión de revisión.
“Sí”, responde Anna. “Hay informes que nos mostrarán los detalles de las estructuras de datos y nos ayudarán a detectar
los elementos duplicados y las omisiones. Pongamos a Visible Analyst a trabajar para que produzca las distribuciones de los
registros por nosotros”.
Se utilizó la herramienta Reports (Informes) para imprimir las distribuciones de los registros para todos los almacenes de
datos maestros.
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 255
FIGURA E8.4
Vista previa del resumen de los
elementos.
Fecha: 4/27/2010 Proyecto: CPU Página: 1
Hora: 2:03:54 PM
Listado sintetizado – Ordenado alfabéticamente
Todas las entradas de elementos de datos – diagramas de flujo de datos
La figura E8.4 es un ejemplo de una parte del informe resumido de elementos visualizado mediante Firefox. Los analistas
deben examinar con cuidado el contenido y buscar redundancia o elementos definidos más de una vez. Por lo general estas re-
dundancias son fáciles de detectar, ya que la lista está ordenada por nombre de elemento. Los elementos NÚMERO DE IN-
VENTARIO DE HARDWARE y NÚMERO DE HARDWARE, además de los elementos NÚMERO DE INVENTARIO DE
SOFTWARE y NÚM SOFTWARE parecen ser elementos duplicados. Otros duplicados, como UBICACIÓN SALA y UBICA-
CIÓN son más difíciles de detectar.
“Ahora debemos usar la opción No Location References (Sin referencias de ubicación), que muestra todos los elementos
que no se incluyen en ningún registro”, dice Anna.
“¡Es magnífico!”, exclama Chip. “Esta opción No Location References muestra el trabajo de diseño que necesita com-
pletarse. Deberíamos producir este informe para todos los componentes de diseño”.
Los elementos se agregaron a otras estructuras o se eliminaron como duplicados. Al producir el informe No Location
References una segunda vez ya no se revelaron elementos aislados.
“Bueno, creo que con eso terminamos la porción de los datos del diseño del sistema”, dice Chip.
“No tan rápido”, responde Anna. “Sólo hemos empezado a analizar. La herramienta Report Query (Consulta de informe)
nos proveerá mucha información de diseño, tanto para análisis como para documentación”.
Los analistas seleccionan un informe llamado Def Entities without Composition (Entidades definidas sin composición)
como su primera elección. Este informe muestra las entradas que son un almacén de datos o una estructura de datos y tienen
una entrada de composición. La salida muestra que no hay registros con errores. La siguiente consulta es el informe Elements
without Pictures (Elementos sin imágenes), que muestra todos los elementos que no tienen imágenes definidas. Un último
informe que crean Chip y Anna se llama Undefined Elements (Elementos indefinidos), el cual indica todos los elementos que
existan en el repositorio sólo como un nombre, pero sin características físicas.
“Todavía no terminamos. Hay algunas matrices útiles que proveerán documentación para todas las modificaciones que se
puedan hacer en el futuro. Vamos a producir la matriz Data Elements versus Data Structures (Comparación entre elementos
y estructuras de datos), que muestra a los registros y sus elementos”, sugiere Anna.
La herramienta Report tiene la capacidad de producir informes y matrices en una representación de cuadrícula. Muestra
todos los elementos y las estructuras de datos en las que están contenidos. Esta matriz se utiliza para tener acceso al efecto de
modificar un elemento, para lo cual muestra las estructuras de datos correspondientes que se deben modificar.
La siguiente matriz que se crea es Diagram Location Matrix (Matriz de ubicación de diagrama), la cual muestra a todos
los almacenes de datos y los diagramas en los que se encuentran. Esta información es útil si hay que hacer un cambio en el al-
macén de datos, ya que indicará en donde debemos cambiar los programas y la documentación.
La última matriz es Composition Matrix (Matriz de composición), la cual muestra todos los elementos de datos y los al-
macenes de datos que los contienen. Esta matriz ofrece a Chip y Anna un panorama de todos los elementos que se pueden alma-
cenar con redundancia; es decir, en varios almacenes de datos en vez de uno.
“Hay muchos otros informes y matrices que serían útiles de producir para nosotros”, dice Anna. “Algunos de ellos los
deberíamos usar posteriormente para la documentación y para rastrear los cambios propuestos. En realidad estoy satisfecha con
lo que hemos logrado”.
EJERCICIOS
Nota: Si no utiliza Visible Analyst, puede realizar algunos de los siguientes ejercicios mediante una plantilla de Microsoft Word
o Microsoft Excel. La información del repositorio se incluye en una página Web repository.html que usted puede guardar.
www.xlibros.com
256 PARTE III • EL PROCESO DE ANÁLISIS
E-1. Use Visible Analyst para ver el almacén de datos ARCHIVO MAESTRO DE COMPUTADORA (COMPUTER MAS-
TER). Salte a la estructura de datos y explore los elementos y registros estructurales.
E-2. Imprima el registro del ARCHIVO MAESTRO DE SOFTWARE mediante la herramienta Report.
E-3. Use el botón Jump para avanzar a Software Record Structure. Elimine los siguientes elementos:
www.xlibros.com
CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 257
E-15. Use el flujo de datos INSTALAR ACTUALIZACIÓN (INSTALL UPDATE) para saltar al (y crear el) REGISTRO DE
ACTUALIZACIÓN DE INSTALACIÓN (INSTALL UPDATE RECORD). Provea una definición con base en la infor-
mación suministrada en el problema anterior. Escriba los siguientes elementos:
NÚMERO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY NUMBER) (clave primaria)
UBICACIÓN DE CAMPUS (CAMPUS LOCATION)
DISCO DURO (HARD DRIVE)
INTERVALO DE MANTENIMIENTO (MAINTENANCE INTERVAL)
FECHA EN QUE SE INSTALÓ (DATE INSTALLED)
E-16. Cree la descripción del flujo de datos para la LISTA DE INSTALACIÓN DE SOFTWARE (SOFTWARE INSTALLA-
TION LIST). Este flujo contiene información sobre paquetes de software específicos y las máquinas en las que se debe
instalar el software. La composición debe incluir el LISTADO DE INSTALACIÓN DE SOFTWARE (SOFTWARE
INSTALLATION LISTING), una estructura de datos.
E-17. Use la LISTA DE INSTALACIÓN DE SOFTWARE para saltar al (y por lo tanto crear el) LISTADO DE INSTALACIÓN
DE SOFTWARE. Los elementos en el listado son:
NÚMERO DE INVENTARIO DE SOFTWARE (SOFTWARE INVENTORY NUMBER)
TÍTULO (TITLE)
NÚMERO DE VERSIÓN (VERSION NUMBER)
HARDWARE INVENTORY NUMBER (NÚMERO DE INVENTARIO DE HARDWARE)
UBICACIÓN DE CAMPUS (CAMPUS LOCATION)
UBICACIÓN DE SALA (ROOM LOCATION)
E-18. Modifique e imprima el elemento SUBTOTAL DE HARDWARE (HARDWARE SUBTOTAL). Cambie el tipo a Deci-
mal, la longitud a 7.2 y la imagen a Z, ZZZ, ZZ9.99.
E-19. Modifique el elemento TIPO DE COMPUTADORA (COMPUTER TYPE). La descripción debería ser: el tipo físico de
computadora. Valores y significados (Values & Meanings) debe contener: L—Laptop, D—Desktop, N—Netbook,
P—Portátil. El tipo es Char con una Longitud (Length) de 1, y una Imagen y Visualización (Picture and Display) de X.
No debe permitir un valor nulo.
E-20. Modifique e imprima el elemento NOMBRE DEL DEPARTAMENTO (DEPARTMENT NAME). Cree un alias de
NOMBRE DEPARTAMENTO PERSONAL (STAFF DEPARTMENT NAME). En el área Notes escriba el siguiente
comentario: Tabla de códigos: Tabla Departamento. El tipo debe ser Character, la longitud 25 y la imagen X(25).
E-21. Cree las siguientes descripciones de elementos. Use los valores que se suministran en la tabla. Cree nombres y definicio-
nes alternativas con base en su comprensión del elemento.
E-22. Use la herramienta Repository Reports de Visible Analyst para producir los siguientes informes y matrices, ya sea al
imprimir los informes o ver una vista previa de los mismos mediante su navegador Web. Se listan los criterios de selección
del cuadro de diálogo Repository Reports, separados con una barra diagonal (/). Explique en un párrafo en dónde se
puede usar efectivamente la información producida.
www.xlibros.com
258 PARTE III • EL PROCESO DE ANÁLISIS
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
CAPÍTULO 9
Especificaciones
de los procesos y decisiones
estructuradas
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender el propósito de las especificaciones de los procesos.
2. Reconocer la diferencia entre las decisiones estructuradas y las semiestructuradas.
3. Usar español estructurado, tablas y árboles de decisión para analizar, describir y
documentar las decisiones estructuradas.
4. Elegir un método apropiado para analizar las decisiones estructuradas y crear
especificaciones de los procesos.
www.xlibros.com
260 PARTE III • EL PROCESO DE ANÁLISIS
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 261
FIGURA 9.1
Diagrama de flujo de datos Especificación y lógica de proceso Cómo se relacionan las
especificaciones de los procesos
con el diagrama de flujo de datos.
Español
estructurado
IF construcción
THEN deduc
ENDIF
IF reemplazo
THEN sumar 1
ENDIF
IF propietario eligió
THEN sumar 1
ENDIF
Tabla de
decisión
Formulario de Reglas
1' 2' 3' 4'
especificación
Proceso de proceso
Y N
Y Y Y N
X
X
X
Árbol de
decisión
Q
20 40
P T
10 50
X
30
ESPAÑOL ESTRUCTURADO
Cuando la lógica del proceso involucra fórmulas o iteraciones, o cuando las decisiones estructuradas no son
complejas, una técnica apropiada para analizar el proceso de decisión es el uso del español estructurado. Como
su nombre indica, el español estructurado se basa en 1) la lógica estructurada, o las instrucciones organizadas en
procedimientos anidados y agrupados, y 2) las instrucciones en español simple tales como sumar, multiplicar y
mover. Un problema escrito se puede transformar en español estructurado si ponemos las reglas de decisión en su
secuencia apropiada y usamos la convención de las instrucciones IF-THEN-ELSE a lo largo del proceso.
www.xlibros.com
262 PARTE III • EL PROCESO DE ANÁLISIS
Formulario de espe
cificación de proce
so
Número 1.3
Nombre Determinar canti
dad disponible
Descripción Determin
ar si un artículo est
crear un registro de á disponible para su
artículo pendiente. venta. Si no está dis
Determinar la canti ponible,
dad disponible.
Flujo de datos de en
trada
Artículo válido del
proceso 1.2
Cantidad disponible
del registro del art
ículo
Flujo de datos de sal
ida
Artículo disponible
(Número de artículo
Artículo pendiente + Cantidad vendida)
a control de invent para los procesos
ario 1.4 y 1.5
Tipo de proceso
En línea Por lotes Nombre de subprog
Manual rama/función
Lógica del proceso
IF la Cantidad artícu
lo pedido es mayor
THEN Mover Canti que Cantidad dispo
dad artículo pedido nible
Mover Número artícu a Cantidad disponib
lo le artículo
ELSE pedido a Número art
ículo disponible
Restar Cantidad dis
ponible de Cantida
para producir Canti d artículo pedido
dad pendiente
Mover Cantidad pen
diente a Registro art
Mover Número artícu ículos pendientes
lo a Registro artícu
DO escribir Registro los pendientes
pendiente
Mover Cantidad dis
ponible a Cantidad
Mover Número artícu disponible artículo
lo pedido to Número
ENDIF artículo disponible
Referir a: Nombre:
Español estructurad
o
Tabla de decisión
Cuestiones sin resolv Árbol de decisión
er: ¿Habrá que tom
artículo? Si combin ar en cuenta la canti
amos esto con la fec dad que está en el
¿cambiaría la forma ha esperada de la pedido para este
en que se calcula la llegada de los artícu
cantidad? los en el pedido,
FIGURA 9.2
Un ejemplo de formulario de especificación de proceso
completado para determinar si un artículo está disponible.
2. Usar y poner en mayúsculas las palabras clave aceptadas como IF, THEN, ELSE, DO, DO WHILE, DO
UNTIL y PERFORM.
3. Aplicar sangría a los bloques de instrucciones para mostrar su jerarquía (anidamiento) con claridad.
4. Cuando haya palabras o frases definidas en un diccionario de datos (como en el capítulo 8), subraye esas
palabras o frases para indicar que tienen un significado especializado y reservado.
5. Tenga cuidado al usar “y” y “o”, y evite la confusión al diferenciar entre “mayor que” y “menor o igual que”
y con las relaciones de igualdad. “A y B” significa tanto A como B; “A” o “B” significa que puede ser A o B,
pero no ambas. Aclare las instrucciones lógicas ahora, en vez de esperar hasta la etapa de codificación del
programa.
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 263
O P O R T U N I D A D D E C O N S U LT O R Í A 9 . 1
FIGURA 9.3
Tipo de español estructurado Ejemplo
Ejemplos de la lógica expresada
Estructura secuencial Acción #1 en una estructura secuencial, una
Un bloque de instrucciones en las Acción #2 estructura de decisión, una
que no ocurre bifurcación Acción #3 estructura de caso y una iteración.
www.xlibros.com
264 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U LT O R Í A 9 . 2
los totales de las reclamaciones para el año. Luego determinamos si un solicitante tiene la póliza A o B,
que difieren en los deducibles y los copagos (el porcentaje de la reclamación que tienen que pagar los
solicitantes). Para ambas pólizas revisamos si se cumple con el deducible ($100 para la póliza A y $50
para la póliza B). Si no se cumple con el deducible, aplicamos la reclamación al deducible. En otro paso
se ajusta el copago; restamos el porcentaje que paga el solicitante (40 por ciento para la póliza A y 60 por
ciento para la póliza B) de la reclamación. Después emitimos un cheque si el solicitante va a recibir
dinero, imprimimos un resumen de la transacción y actualizamos nuestras cuentas. Hacemos esto hasta
que se procesan todas las reclamaciones de ese día.
Al examinar las declaraciones anteriores podemos observar algunas estructuras de secuencia simples, en especial
al inicio y al final. Hay un par de estructuras de decisión y lo más apropiado es anidarlas, para lo cual primero
FIGURA 9.4
Español estructurado para el
DO WHILE haya reclam
sistema de procesamiento de aciones restantes
IF solicitante no ha pre
reclamaciones médicas. Los sentado una reclamaci
THEN establecer un ón
elementos subrayados indican que nuevo registro de sol
ELSE continuar icitante
se definieron los términos en el Agregar reclamación
diccionario de datos. a reclamación AAF
IF solicitante tiene pla
n de póliza A
THEN IF deducible de
$100.00 no se ha cum
THEN restar deducible plido
no cumplido a reclam
Actualizar deducible ación
ELSE continuar
ENDIF
Restar copago de 40%
de reclamación a rec
ELSE IF solicitante tien lamación
e plan de póliza B
THEN IF deducible de
$50.00 no se ha cum
THEN restar deducible plido
no cumplido a reclam
Actualizar deducible ación
ELSE continuar
ENDIF
Restar copago de 60%
de reclamación a rec
ELSE continuar lamación
ELSE escribir mensa
je de error en plan
ENDIF
IF reclamación es ma
yor que cero
THEN imprimir cheque
ENDIF
Imprimir resumen par
a solicitante
Actualizar cuentas
ENDDO
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 265
hay que determinar qué póliza (A o B) usar y después hay que restar los deducibles y copagos correctos. El
último enunciado apunta a una iteración: HACER HASTA (DO UNTIL) que todas las reclamaciones se hayan
procesado o HACER MIENTRAS (DO WHILE) haya reclamaciones pendientes.
Si consideramos que es posible anidar las estructuras de decisión de acuerdo con los planes de las pólizas,
podemos escribir el español estructurado para el ejemplo anterior (vea la figura 9.4). A medida que empiece
a trabajar en el español estructurado descubrirá que una parte de la lógica y las relaciones que parecían claras
una vez son en realidad ambiguas. Por ejemplo, ¿debemos agregar la reclamación a la reclamación del año a la fecha
(AAF) antes o después de actualizar el deducible? ¿Es posible que ocurra un error si se almacena algo que no
sea la póliza A o B en el registro del solicitante? ¿A qué restamos el 40 por ciento de la reclamación? Hay que
aclarar estas ambigüedades en este punto.
Además de la obvia ventaja de aclarar la lógica y las relaciones que se encuentran en los lenguajes humanos,
el español estructurado tiene otra ventaja importante: es una herramienta de comunicación. Podemos enseñar a
los usuarios en la organización el español estructurado para que lo comprendan, por lo que si es importante la
comunicación, el español estructurado es una alternativa viable para el análisis de decisiones.
FIGURA 9.5
Estado de cuenta Estructura de datos para un estado
de envío =
Número de pedid de cuenta de envío de World’s
o+
Fecha del pedido Trend.
+
Número de cliente
+
Nombre del clien
te +
Dirección del clien
5
te +
1 {Líneas de artículos del
pedido} +
Número de artícu
los +
Total de mercanc
ía +
(Impuestos) +
Envío y manejo +
Total del pedido
Nombre del clien
te = Primer nombre +
(Inicial segundo
nombre) +
Apellido paterno
Dirección =
Calle +
(Departamento) +
Ciudad +
Estado +
CP +
(Expansión CP) +
(País)
Líneas de artículos
del pedido =
Número de artícu
lo +
Cantidad ordenad
a+
Cantidad pendien
te +
Descripción del art
ículo +
Descripción del tam
año +
Descripción del co
lor +
Precio unitario +
Monto extendido
+
www.xlibros.com
266 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 9.6
Español estructurado para crear el Español estructurad
estado de cuenta de envío para o
World’s Trend. Aplique formato al
Estado de cuenta de
línea del estado de envío. Una vez que
cuenta, escriba la lín haya aplicado forma
ea de envío. to a cada
1. GET Registro de
pedido
2. GET Registro de
cliente
3. Mover Número
de pedido a estado de
4. Mover Fecha del cuenta de envío
pedido a Estado de
5. Mover Número cue nta de envío
de cliente a Estado de
6. DO aplicar forma cue nta de envío
to a Nombre del clie
7. DO aplicar forma nte (dejar sólo un espacio ent
to a las líneas de Dir re Primer/Segundo/A
ección del cliente pellido)
8. DO WHILE hay
a artículos para el ped
9. ido
GET Registro de art
ículo
10. DO Aplicar formato
a Línea de artículo
11. Multiplicar Precio un
itario por Cantidad ord
12. Mover Monto extend enada para obtener
ido a Líneas de artícu Monto extendido
13. Sumar Monto extend los del pedido
ido a Total de merca
14. IF Cantidad pendiente ncía
es mayor que cero
15.
Mover Cantidad pen
16. diente a Líneas de art
ENDIF ículos del pedido
17. ENDDO
18. Mover Tot
al de mercancía a Est
19. Mover 0 a ado de cuenta de env
Impuestos ío
20. IF Estado
es igual a CT
21. Multiplicar Total de
mercancía por Tasa
22. ENDIF de impuestos para ob
tener Impuesto
23. Mover Impu
esto a Estado de cue
24. DO calcular nta de envío
Envío y manejo
25. Mover Envío
y manejo a Estado de
26. Sumar Tot cuenta de envío
al de mercancía, Im
27. Mover Tot pu estos y Envío y manejo
al del pedido a Estado para obtener Total del
de cuenta de envío pedido
NÚMERO DE CLIENTE como simples campos secuenciales. La lógica correspondiente, que se muestra en las
líneas 3 a la 5 en el correspondiente español estructurado en la figura 9.6, consiste de instrucciones MOVER
simples.
Una estructura de datos con elementos opcionales contenidos entre paréntesis o elementos ya sea/o conteni-
dos entre corchetes, tendrán su correspondiente instrucción IF…THEN…ELSE en la especificación del proceso.
Además, si un monto tal como CANTIDAD PENDIENTE es mayor que cero, la lógica subyacente será IF…
THEN…ELSE. La iteración, que se indica mediante llaves en una estructura de datos, debe tener una instrucción
correspondiente DO WHILE, DO UNTIL o PERFORM UNTIL para controlar los ciclos en la especificación del
proceso. La estructura de datos para LÍNEAS DE ARTÍCULOS DEL PEDIDO permite hasta cinco artículos en
el ciclo. Las líneas 8 a la 17 muestran las instrucciones contenidas en el DO WHILE hasta el END DO necesa-
rias para producir las diversas LÍNEAS DE ARTÍCULOS DEL PEDIDO.
TABLAS DE DECISIÓN
Una tabla de decisión es una tabla de filas y columnas, separada en cuatro cuadrantes, como se muestra en la figura
9.7. El cuadrante superior izquierdo contiene la(s) condición(es); el cuadrante superior derecho contiene las alter-
nativas de condiciones. La mitad inferior de la tabla contiene las acciones a realizar a la izquierda y las reglas para
ejecutar las acciones a la derecha. Cuando se utiliza una tabla de decisión para determinar la acción a realizar, la
lógica se mueve en sentido de las manecillas del reloj, partiendo desde el cuadrante superior izquierdo.
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 267
FIGURA 9.7
Condiciones y acciones Reglas
El formato estándar utilizado para
presentar una tabla de decisión.
Suponga que una tienda desea ilustrar su política sobre compras que no son en efectivo. La empresa podría
hacerlo mediante el uso de una tabla de decisión simple, como se muestra en la figura 9.8. Cada una de las tres
condiciones (venta menor de $50, paga con cheque y usa tarjetas de crédito) sólo tiene dos alternativas. Las dos
alternativas son Y (sí, es verdadero) o N (no, no es verdadero). Es posible realizar cuatro acciones:
1. Completar la venta después de verificar la firma.
2. Completar la venta. No se necesita firma.
3. Llamar al supervisor para la aprobación.
4. Comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito.
El ingrediente final que hace que valga la pena usar la tabla de decisión es el conjunto de reglas para cada
una de las acciones. Las reglas son las combinaciones de las alternativas de condiciones que precipitan una ac-
ción. Por ejemplo, la regla 3 dice:
El ejemplo anterior presenta un problema con cuatro conjuntos de reglas y cuatro posibles acciones, pero
eso es sólo una coincidencia. El siguiente ejemplo demuestra que con frecuencia las tablas de decisión se hacen
extensas y complicadas.
FIGURA 9.8
Reglas
Condiciones y acciones 1 2 3 4 Uso de una tabla de decisión para
ilustrar la política de una tienda en
Menor de $50 Y Y N N cuanto al pago de los clientes con
Paga con cheque con dos formas de ID Y N Y N cuatro conjuntos de reglas y cuatro
Usa tarjeta de crédito N Y N Y posibles acciones.
www.xlibros.com
268 PARTE III • EL PROCESO DE ANÁLISIS
2. Determinar el número de acciones posibles que se pueden realizar. Ese número se convierte en el número de
filas en la mitad inferior de la tabla de decisión.
3. Determinar el número de alternativas de condiciones para cada condición. En la forma más simple de la
tabla de decisión, habría dos alternativas (Y o N) para cada condición. En una tabla con entradas extendidas,
podría haber muchas alternativas para cada condición. Asegúrese de incluir todos los valores posibles para la
condición. Por ejemplo, si el enunciado de un problema que calcule el descuento de un cliente menciona un
rango de valores para un total del pedido de $100 a $1,000 y otro rango de más de $1,000, el analista debe
tener en cuenta que también debe agregar el rango de 0 a $100 como una condición. Esto es cierto sobre
todo cuando hay otras condiciones que se pueden aplicar al total de pedido de 0 a $100.
4. Calcular el número máximo de columnas en la tabla de decisión, para lo cual hay que multiplicar el número
de alternativas para cada condición. Si hubiera cuatro condiciones y dos alternativas (Y o N) para cada una de
las condiciones, habría 16 posibilidades, como se muestra a continuación:
Condición 1: ⫻ 2 alternativas
Condición 2: ⫻ 2 alternativas
Condición 3: ⫻ 2 alternativas
Condición 4: ⫻ 2 alternativas
16 posibilidades
5. Llenar las alternativas de condiciones. Empezar con la primera condición y dividir el número de columnas
entre el número de alternativas para esa condición. En el ejemplo anterior hay 16 columnas y dos
alternativas (Y o N), por lo que 16 dividido entre 2 es 8. Después hay que elegir una de las alternativas, por
ejemplo Y, y escribirla en las primeras ocho columnas; para terminar hay que escribir N en las ocho
columnas restantes, como se muestra a continuación:
Condición 1: Y Y Y Y Y Y Y Y N N N N N N N N
Condición 1: Y YYYYYYYNNNNNNNN
Condición 2: Y YYYNNNN
Condición 3: Y YNN
Condición 4: Y N
Condición 1 Y Y Y Y Y Y Y Y N N N N N N N N
Condición 2: Y Y Y Y N N N N Y Y Y Y N N N N
Condición 3: Y Y N N Y Y N N Y Y N N Y Y N N
Condición 4: Y N Y N Y N Y N Y N Y N Y N Y N
6. Para completar la tabla, inserte una X donde las reglas sugieran ciertas acciones.
7. Combine las reglas en las que sea aparente que una alternativa no marca una diferencia en el resultado. Por
ejemplo,
Condición 1: YY
Condición 2: YN
Acción 1: XX
El guión [—] significa que la Condición 2 puede ser Y o N, y la acción se realizará de cualquier manera.
8. Revise cualquier situación imposible, contradicción o redundancia en la tabla. Abundaremos sobre esto
posteriormente.
9. Vuelva a ordenar las condiciones y acciones (o incluso las reglas) si esto le ayuda a comprender mejor la
tabla de decisión.
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 269
O P O R T U N I D A D D E C O N S U LT O R Í A 9 . 3
UN EJEMPLO DE TABLA DE DECISIÓN La figura 9.9 es una ilustración de una tabla de decisión desarrollada
mediante el uso de los pasos antes descritos. En este ejemplo, una empresa trata de mantener una lista de clientes
de correo representativa. El objetivo es enviar sólo los catálogos para que los clientes compren la mercancía
anunciada en ellos.
Los gerentes saben que ciertos clientes leales hacen pedidos de todos los catálogos y que algunas personas de
la lista nunca hacen pedidos. Estos patrones de pedidos son fáciles de observar, pero es más difícil decidir cuáles
catálogos enviar a los clientes que ordenan sólo de ciertos catálogos seleccionados. Una vez tomadas estas deci-
siones, se construye una tabla de decisión para tres condiciones (C1: el cliente hizo un pedido del catálogo de
otoño; C2: el cliente hizo un pedido del catálogo de Navidad y C3: el cliente hizo un pedido de un catálogo es-
pecializado), cada una de las cuales tiene dos alternativas (Y o N). Se pueden tomar tres acciones (A1: enviar el
catálogo de Navidad de este año; A2: enviar el nuevo catálogo especializado y A3: enviar ambos catálogos).
La tabla de decisión resultante tiene seis filas (tres condiciones y tres acciones) y ocho columnas (dos alternati-
vas ⫻ dos alternativas ⫻ dos alternativas).
Ahora hay que examinar la tabla de decisión para ver si se puede reducir. No hay condiciones mutuamente
excluyentes, por lo que no es posible usar menos de tres filas de condiciones. No hay reglas que permitan la
FIGURA 9.9
Reglas
Condiciones y acciones 1 2 3 4 5 6 7 8 Construcción de una tabla de
decisión para decidir qué catálogo
enviar a los clientes que piden sólo
El cliente hizo un pedido del catálogo de otoño. Y Y Y Y N N N N de catálogos seleccionados.
El cliente hizo un pedido del catálogo de Navidad. Y Y N N Y Y N N
El cliente hizo un pedido del catálogo especializado. Y N Y N Y N Y N
www.xlibros.com
270 PARTE III • EL PROCESO DE ANÁLISIS
Reglas
Condiciones y acciones 1' 2' 3'
combinación de acciones. Sin embargo, es posible combinar algunas de las reglas como se muestra en la figura
9.10. Por ejemplo, las reglas 2, 4, 6 y 8 se pueden combinar debido a que todas tienen dos cosas en común:
1. Nos sugieren enviar el catálogo de Navidad de este año.
2. La alternativa para la Condición 3 siempre es N.
No importa cuáles sean las alternativas para las primeras dos condiciones, por lo que es posible insertar guiones
[—] en vez de Y o N.
Las reglas restantes (1, 3, 5 y 7) no se pueden reducir a una sola regla debido a que restan dos acciones. En
vez de ello podemos combinar las reglas 1 y 5; de igual forma podemos combinar las reglas 3 y 7.
FIGURA 9.11
Reglas
Al agregar una regla a la tabla de Condiciones y acciones 1' 2' 3' 4'
decisión cliente-catálogo se
modifica toda la tabla. El cliente hizo un pedido del catálogo de otoño.
El cliente hizo un pedido del catálogo de Navidad. Y N
El cliente hizo un pedido del catálogo especializado. Y N Y
El cliente hizo un pedido de $50 o más. Y Y Y N
Enviar el catálogo de Navidad de este año. X
Enviar el catálogo especializado. X
Enviar ambos catálogos. X
No enviar ningún catálogo. X
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 271
Reglas
FIGURA 9.12
Condiciones y acciones Es importante verificar que la
1 2 3 4
tabla de decisión no tenga
Salario > $50,000/año Y Y N N situaciones imposibles.
Salario < $2,000/mes Y N Y N
Acción 1
Acción 2
Ésta es una
situación
imposible.
Al construir tablas de decisión según lo indicado en los pasos anteriores, algunas veces podemos llegar a
establecer situaciones imposibles. En la figura 9.12 se muestra un ejemplo. La regla 1 no es factible, ya que una
persona no puede obtener más de $50,000 al año y menos de $2,000 mensuales por mes al mismo tiempo. Las
otras tres reglas son válidas. El problema pasó desapercibido debido a que la primera condición se midió en años
y la segunda en meses.
Cuando las reglas sugieren distintas acciones pero satisfacen las mismas condiciones, ocurren contradic-
ciones. La falla podría estar en la forma en que el analista construyó la tabla o en la información que recibió.
A menudo ocurren contradicciones si se insertan guiones [—] incorrectamente en la tabla. La redundancia ocu-
rre cuando conjuntos idénticos de alternativas requieren exactamente la misma acción. La figura 9.13 ilustra una
contradicción y una redundancia. El analista debe determinar qué es lo correcto y después resolver la contradic-
ción o redundancia.
Las tablas de decisión son una importante herramienta en el análisis de las decisiones estructuradas. Una
ventaja importante de usar tablas de decisión en comparación con otros métodos es que las tablas ayudan al ana-
lista a asegurar la integridad. Al usar tablas de decisión también se facilita la acción de verificar posibles errores,
como las situaciones imposibles, contradicciones y redundancia. También existen los procesadores de tablas de
decisión, que reciben la tabla como entrada y proveen código de programa de computadora como salida.
ÁRBOLES DE DECISIÓN
Los árboles de decisión se utilizan cuando ocurren ramificaciones complejas en un proceso de decisión estruc-
turado. Los árboles también son útiles cuando es imprescindible mantener una cadena de decisiones en una
secuencia específica. Aunque el nombre “árbol de decisión” se deriva de los árboles naturales, por lo general
los árboles de decisión se dibujan de lado, con la raíz en el lado izquierdo del papel; a partir de ahí el árbol
se ramifica hacia la derecha. Esta orientación permite al analista escribir en las ramas para describir las con-
diciones y acciones.
A diferencia del árbol de decisión que se utiliza en la ciencia de la administración, el árbol del analista no
contiene probabilidades y resultados. En el análisis de sistemas, los árboles se utilizan principalmente para iden-
tificar y organizar las condiciones y acciones en un proceso de decisión completamente estructurado.
Acción 1 X X X
Acción 2 X X
Acción 3 X X
Contradicción Redundancia
www.xlibros.com
272 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U LT O R Í A 9 . 4
Un árbol gratis
FIGURA 9.14 3
Completar la venta después de verificar la firma.
Cheque
Cómo dibujar un árbol de decisión
para mostrar las acciones de 2 Tarjeta de crédito
aprobación de compras que no son Menos de $50
Completar la venta. No se requiere firma.
en efectivo para una tienda 4
departamental.
1
≥ $50 Llamar al supervisor para la aprobación.
Cheque 6
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 273
El árbol de decisión tiene tres principales ventajas sobre una tabla de decisión. En primer lugar saca prove-
cho de la estructura secuencial de sus ramas, por lo que se puede observar de inmediato el orden de verificación
de las condiciones y ejecución de las acciones. En segundo lugar, podemos encontrar condiciones y acciones de
los árboles de decisión en algunas ramas pero no en otras, lo cual contrasta con las tablas de decisión, donde to-
das forman parte de la misma tabla. Esas condiciones y acciones que son críticas se conectan de manera directa
con otras condiciones y acciones, mientras que las condiciones que no importan están ausentes. En otras pala-
bras, el árbol no tiene que ser simétrico. En tercer lugar, en comparación con las tablas de decisión, otras perso-
nas en la organización pueden comprender con más facilidad los árboles de decisión. En consecuencia, son más
apropiados como herramienta de comunicación.
RESUMEN
Una vez que el analista trabaja con los usuarios para identificar superior izquierda) para: 1) describir las condiciones, 2) identificar
los flujos de datos y empieza a construir un diccionario de datos, las posibles alternativas de decisión (como Y o N), 3) indicar qué
es tiempo de pasar a la especificación de procesos y el análisis de acciones se deben realizar y 4) describir las acciones. Las tablas
decisiones. Los tres métodos para el análisis de decisiones y para de decisión son ventajosas ya que las reglas para desarrollar la
describir la lógica de procesos que vimos en este capítulo son tabla en sí, además de las reglas para eliminar redundancia, con-
español estructurado, tablas de decisión y árboles de decisión. tradicciones y situaciones imposibles, son simples y manejables.
Las especificaciones (o mini-especificaciones) de procesos Al usar tablas de decisión se fomenta la integridad y precisión en
se crean para los procesos primitivos en un diagrama de flujo el análisis de las decisiones estructuradas.
de datos, así como para algunos procesos de nivel más alto El tercer método para el análisis de decisiones es el árbol
que se expanden en un diagrama hijo. Estas especificaciones de decisión, que consiste en nodos (un cuadrado para las accio-
explican la lógica de toma de decisiones y las fórmulas que nes y un círculo para las condiciones) y ramificaciones. Los ár-
transformarán los datos de entrada de un proceso en su salida. boles de decisión son apropiados cuando las acciones se deben
Los tres objetivos de la especificación de procesos son reducir llevar a cabo en cierta secuencia. No hay ningún requerimiento
la ambigüedad del proceso, obtener una descripción precisa de de que el árbol sea simétrico, por lo que sólo las condiciones y
lo que se logra y validar el diseño del sistema. acciones que sean críticas para las decisiones en cuestión son
Una manera de describir las decisiones estructuradas es me- las que se encuentran en una rama específica.
diante el método que se conoce como español estructurado, en Cada uno de los métodos de análisis de decisiones tiene
el cual la lógica se expresa en estructuras secuenciales, estruc- sus propias ventajas y se debe utilizar de manera acorde. El es-
turas de decisión, estructuras de casos o iteraciones. El español pañol estructurado es muy útil cuando se repiten muchas accio-
estructurado utiliza palabras clave aceptadas tales como SI (IF), nes y cuando es importante comunicarse con otros. Las tablas
ENTONCES (THEN), SINO (ELSE), HACER (DO), HACER de decisión proveen un análisis completo de las situaciones
MIENTRAS (DO WHILE) y HACER HASTA (DO UNTIL) complejas, al tiempo que limitan la necesidad de cambio que
para describir la lógica utilizada; además hace uso de la sangría para se atribuye a las situaciones imposibles, redundancias o contra-
indicar la estructura jerárquica del proceso de decisión. dicciones. Los árboles de decisión son importantes cuando es
Las tablas de decisión son otra forma de examinar, describir imprescindible la secuencia apropiada de las condiciones y ac-
y documentar las decisiones. Se utilizan cuatro cuadrantes (que se ciones, y cuando cada una de las condiciones no son relevantes
ven en sentido de las manecillas del reloj, a partir de la esquina para cada una de las acciones.
www.xlibros.com
274 PARTE III • EL PROCESO DE ANÁLISIS
EXPERIENCIA DE HYPERCASE® 9
Pregunta de HYPERCASE
1. Suponga que va a crear las especificaciones para un sistema
de rastreo de proyectos automatizado para los empleados de
PREGUNTAS DE REPASO
1. Elabore una lista de tres razones para producir las especificaciones de los procesos.
2. Defina lo que significa una decisión estructurada.
3. ¿Cuáles son los cuatro elementos que debe conocer el analista de sistemas para diseñar los sistemas teniendo en cuenta
las decisiones estructuradas?
4. ¿Cuáles son los dos bloques de construcción del español estructurado?
5. Mencione cinco convenciones a seguir cuando se utiliza español estructurado.
6. ¿Cuál es la ventaja de usar español estructurado para comunicarse con las personas en la organización?
7. ¿Cuál cuadrante de la tabla de decisión se utiliza para las condiciones? ¿Cuál se usa para las alternativas de condiciones?
8. ¿Cuál es el primer paso a seguir en el desarrollo de una tabla de decisión?
9. Mencione los cuatro problemas principales que pueden ocurrir al desarrollar tablas de decisión.
10. ¿Cuál es una de las principales ventajas de las tablas de decisión si se les compara con otros métodos de análisis de
decisiones?
11. ¿Cuáles son los principales usos de los árboles de decisión en el análisis de sistemas?
12. Mencione los cuatro pasos principales para construir árboles de decisión.
13. ¿Cuáles son las tres ventajas que tienen los árboles de decisión sobre las tablas de decisión?
14. ¿Cuáles son las dos situaciones en las que debemos usar español estructurado?
15. ¿Cuáles son las dos situaciones en las que funcionan mejor las tablas de decisión?
16. ¿Cuáles son las dos situaciones en las que es preferible usar árboles de decisión?
PROBLEMAS
1. Clyde Clerk está revisando las políticas de reembolso de gastos de su empresa con el nuevo vendedor, Trav Farr.
“Nuestras políticas de reembolso dependen de la situación. Verás, primero determinamos si es un viaje local. Si es así,
sólo pagamos la distancia recorrida a 18.5 centavos por milla. Si el viaje fue de un día, pagamos la distancia recorrida y
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 275
después revisamos las horas de salida y retorno. Para que puedas obtener un reembolso para el desayuno, debes salir a
las 7:00 AM, almorzar antes de las 11:00 A.M. y comer antes de las 5:00 P.M. Para recibir el reembolso para el
desayuno, debes regresar después de las 10:00 A.M., almorzar después de las 2:00 P.M. y comer antes de las 7:00 P.M.
En un viaje que dure más de un día, otorgamos viáticos para hotel, taxi y tarifas de avión, así como las comidas. Se
aplican los mismos horarios para los gastos de comida”. Escriba en español estructurado la narrativa de Clyde sobre las
políticas de reembolso.
2. Dibuje un árbol de decisión que describa la política de reembolso del problema 1.
3. Dibuje una tabla de decisión que describa la política de reembolso del problema 1.
4. Una empresa de provisiones para computadoras conocida como True Disk acaba de establecer cuentas para
innumerables negocios en Dosville. True Disk envía las facturas cada mes y ofrece descuentos si los pagos se realizan
dentro de un plazo de 10 días. La política de descuento es la siguiente: si el monto del pedido de provisiones de
computadoras es mayor de $1,000, restar un 4 por ciento al pedido; si el monto está entre $500 y $1,000, restar un 2 por
ciento de descuento; si el monto es menor de $500, no aplicar ningún descuento. Todos los pedidos realizados a través
del sitio Web reciben de manera automática un descuento adicional del 5 por ciento. Cualquier pedido especial (muebles
para computadoras, por ejemplo) está exento de los descuentos.
Desarrolle una tabla de decisiones para las decisiones sobre los descuentos de True Disk, en donde las alternativas
de las condiciones se limiten a Y y N.
5. Desarrolle una tabla de decisión con entradas extendidas para la política de descuentos de la empresa True Disk del
problema 4.
6. Desarrolle un árbol de decisión para la póliza de descuentos de la empresa True Disk del problema 4.
7. Escriba español estructurado para resolver la situación de la empresa True Disk del problema 4.
8. Premium Airlines ofreció recientemente llegar a un acuerdo sobre una demanda colectiva que se originó debido a un
supuesto acuerdo de precios de los boletos. El acuerdo propuesto se establece de la siguiente manera:
Al inicio, Premium Airlines pondrá a disposición del acuerdo colectivo un fondo principal de $25 millones en cupones.
Si el número de demandas válidas interpuestas es de 1.25 millones o menos, el valor de cada demanda será el resultado
que se obtiene al dividir $25 millones entre el número total de demandas válidas que se hayan interpuesto. Por ejemplo,
si hay 500,000 demandas válidas, cada persona que haya interpuesto una demanda válida recibirá un cupón con un valor
de $50.
La denominación de cada cupón que se distribuya será en dólares sin centavos, y no deberá exceder a $50. Por
ende, si hay menos de 500,000 demandas válidas, el valor de cada demanda se dividirá entre dos o más cupones. Por
ejemplo, si hay 250,000 demandas válidas, cada persona que haya interpuesto una demanda válida recibirá dos cupones,
cada uno de los cuales tendrá un valor nominal de $50, para un valor total de cupones de $100.
Si el número de demandas válidas interpuestas está entre 1.25 millones y 1.5 millones, Premium Airlines hará
disponible un fondo complementario de cupones, con un valor potencial de $5 millones. El fondo complementario
estará disponible según sea necesario para proveer un cupón de $20 por cada demanda válida.
Si hay más de 1.5 millones de demandas válidas, el monto total del fondo principal y el fondo complementario, que
en conjunto equivalen a $30 millones, se dividirá en forma equitativa para producir un cupón para cada demanda válida.
El valor de cada uno de esos cupones será de $30 millones divididos entre el número total de demandas válidas.
Dibuje un árbol de decisión para el acuerdo de Premium Airlines.
9. Escriba español estructurado para el acuerdo de Premium Airlines del problema 8.
10. “Bueno, es algo difícil de describir”, dice Sharon, consejera del centro de nutrición Less Is More. “En realidad nunca he
tenido que decirle a nadie sobre la forma en que cobramos a los clientes, pero voy a intentarlo”.
“Cuando los clientes entran a Less Is More, verificamos si ya habían usado nuestros servicios antes. Por desgracia
para ellos, creo, tenemos muchos clientes repetidos que siguen rebotando. Los clientes repetidos obtienen una tarifa
reducida (perdón por el juego de palabras) de $100 por la primera visita, si regresan dentro de un periodo menor a 1 año
de haber finalizado su programa”.
“Todos los de nuevo ingreso pagan una cuota inicial de $200 para una evaluación física. El cliente puede traer un
cupón en ese momento y nosotros deducimos $50 de la cuota de inscripción. La mitad de nuestros clientes utilizan
nuestros cupones y se enteran sobre nosotros gracias a éstos. Pero nuestros clientes repetidos sólo obtienen el descuento
de $100; ¡No pueden usar un cupón también! Los clientes que se transfieren de uno de nuestros centros en otra ciudad
reciben $75 de descuento de su primer pago, pero el cupón no es válido. Los clientes que pagan en efectivo reciben un
10 por ciento de descuento de los $200, pero no pueden usar un cupón aparte de eso”.
Cree una tabla de decisión con condiciones Y o N para el sistema de cobro para los clientes del centro de nutrición
Less Is More.
11. Reduzca la tabla de decisión de la figura 9.EJ1 al número mínimo de reglas.
12. Azure Isle Resort tiene una estructura de precios para vacacionistas en una de sus tres categorías de habitaciones: el
hotel, las villas y los chalets de playa. El precio base es por quedarse en el hotel. Los chalets de playa tienen un recargo
del 10 por ciento y la renta de una villa tiene un recargo del 15 por ciento. El precio final incluye un descuento del 4 por
ciento para los clientes frecuentes. Las demás condiciones se aplican a qué tan cerca está el centro vacacional de llenarse
a toda su capacidad y si la fecha solicitada está dentro del periodo de un mes a partir de la fecha actual. Si el centro
vacacional está lleno al 50 por ciento y la fecha está dentro del periodo de un mes, hay un 12 por ciento de descuento. Si
www.xlibros.com
276 PARTE III • EL PROCESO DE ANÁLISIS
el centro vacacional está lleno al 70 por ciento y la fecha está dentro del periodo de un mes, hay un 6 por ciento de
descuento. Si el centro vacacional está lleno al 85 por ciento y la fecha está dentro del periodo de un mes, hay un 4 por
ciento de descuento.
Desarrolle una tabla de decisión optimizada para la estructura de precios de Azure Isle Resort.
13. Cree un árbol de decisión para el problema 12.
14. El precio base del boleto para Cloudliner Airlines se determina en base a la distancia recorrida y el día de la semana
en que el pasajero piensa viajar. Además, la aerolínea ajusta los boletos de sus precios con base en varias categorías.
Si los asientos restantes son más del 50 por ciento de la capacidad y el número de días antes del vuelo es menor a 7,
el precio recibe un buen descuento con una oferta Web especial para el vuelo. Si los asientos restantes son mayores al
50 por ciento y la fecha del vuelo es de 7 a 21 días en el futuro, hay un descuento medio en el precio. Si los asientos
restantes son mayores al 50 por ciento y el número de días antes de viajar es mayor de 21, sólo hay un pequeño
descuento.
Si los asientos restantes representan de un 20 a un 50 por ciento de la capacidad y los días antes del vuelo son
menores de 7, el boleto tiene un descuento medio. Si los asientos restantes representan de un 20 a un 50 por ciento de la
capacidad y la fecha del vuelo es de 7 a 21 días en el futuro, hay un descuento bajo en el precio. Si los asientos restantes
representan de un 20 a un 50 por ciento de la capacidad y el número de días antes de viajar es mayor de 21, hay un
pequeño incremento en el precio.
Desarrolle una tabla de decisión optimizada para las políticas de ajuste de precios en los boletos de Cloudliner
Airlines.
15. Desarrolle un árbol de decisión para la situación del problema 14.
PROYECTOS EN GRUPO
1. Cada miembro de grupo (o cada subgrupo) debería optar por convertirse en un “experto” y prepararse para explicar
cómo y cuándo usar una de las siguientes técnicas de decisión estructuradas: español estructurado, tablas de decisión o
árboles de decisión. Después cada miembro del grupo o subgrupo deberán crear un caso en relación con la utilidad de su
técnica de análisis de decisión asignada para estudiar los tipos de decisiones estructuradas tomadas por Maverick
Transport en cuanto a despachar ciertos camiones hacia destinos específicos. Cada grupo debe hacer una presentación de
su técnica preferida.
2. Después de escuchar cada presentación, el grupo debería llegar a un consenso en cuanto a cuál técnica es la más
apropiada para analizar las decisiones de Maverick Transport al despachar los camiones y por qué es mejor esa técnica
en este caso.
BIBLIOGRAFÍA SELECCIONADA
Anderson, D. R., D. J. Sweeny, T. A. Williams y R. K. Martin. An Introduction to Management Science, 10ª. Edición. Florence,
KY: South-Western College Publishing (un sello de Cengage), 2007.
Evans, J. R. Applied Production and Operations Management, 4ª. Edición. St. Paul, MN: West, 1993.
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 277
EPISODIO 9
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
“El número total de combinaciones se obtiene al multiplicar el número de valores para cada una de las condiciones, 2 ⫻ 2
⫻ 2 ⫽ 8. El siguiente paso es decidir qué condiciones deben ser primero”. Chip continúa: “Deduzco que una licencia de sitio
no tendría un descuento por cantidad o un descuento académico adicional, ya que el costo de la licencia de sitio refleja de an-
temano este tipo de descuento. Por lo tanto, LICENCIA DE SITIO debería ser la primera condición. Cada una de las otras dos
condiciones no tendrían una ventaja específica sobre la otra, por lo que no importa su orden.
“Como el número total de condiciones es de ocho y la condición LICENCIA DE SITIO tiene dos posibles valores, el
factor de repetición sería de 8/2 o 4”. Chip continúa y deja establecido que la primera fila de la tabla de decisión sería:
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
“La siguiente condición es DESCUENTO ACADÉMICO, que también tiene dos valores. Al dividir el factor anterior de
cuatro entre estos dos valores obtenemos 4/2 = 2 para el siguiente factor de repetición”. Chip observa que la tabla de decisión
ahora se expande en lo siguiente:
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
DESCUENTO ACADÉMICO Y Y N N Y Y N N
www.xlibros.com
278 PARTE III • EL PROCESO DE ANÁLISIS
Chip continúa: “La última condición, DESCUENTO POR CANTIDAD, también tiene dos valores; al dividir el factor de
repetición anterior de dos entre estos dos valores obtenemos 2/2 ⫽ 1, que debe ser siempre el factor de repetición para la última
fila de las condiciones”. Chip deja establecido que la entrada de condiciones completa es:
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
DESCUENTO ACADÉMICO Y Y N N Y Y N N
DESCUENTO POR CANTIDAD Y N Y N Y N Y N
Chip señala que cuando se incluyen las acciones, la tabla de decisión completa es la siguiente:
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
DESCUENTO ACADÉMICO Y Y N N Y Y N N
DESCUENTO POR CANTIDAD Y N Y N Y N Y N
Acciones
COSTO ⫽ COSTO DE LICENCIA DE SITIO X X X X
COSTO ⫽ COSTO ACADÉMICO X COPIAS X
COSTO ⫽ COSTO DESCUENTO X COPIAS X
COSTO ⫽ COSTO ACTUALIZACIÓN X COPIAS X
COSTO ⫽ (COSTO EDUC – DESC) X COPIAS X
“Me puse a reducir algunas de las acciones redundantes, en especial las que ocurren al obtener una licencia de sitio”. Chip
continúa: “Como las acciones son las mismas para los valores de Licencia de sitio de Y, los descuentos académicos y por can-
tidad no significan nada para la condición y no tienen que considerarse. Las reglas 1 a 4 se pueden reducir en una regla”. Chip
concluye con la observación de que la tabla de decisión optimizada es la siguiente:
Condición 1 2 3 4 5
LICENCIA DE SITIO Y N N N N
DESCUENTO ACADÉMICO — Y Y N N
DESCUENTO POR CANTIDAD — Y N Y N
Acciones
COSTO ⫽ COSTO DE LICENCIA DE SITIO X
COSTO ⫽ COSTO ACADÉMICO X COPIAS X
COSTO ⫽ COSTO DESCUENTO X COPIAS X
COSTO ⫽ COSTO ACTUALIZACIÓN X COPIAS X
COSTO ⫽ (COSTO EDUC – DESC) X COPIAS X
La tabla de decisión final, que se muestra en la figura 9.1, contiene la tabla de decisión optimizada. Hay tres condiciones:
que haya una licencia de sitio, un descuento académico o un descuento por cantidad. El cuadrante superior izquierdo contiene
las condiciones. Directamente debajo de ellas están las acciones. Las alternativas de condición están en el cuadrante superior
FIGURA E9.1
Tabla de decisión, COSTO DE Condiciones y acciones
ACTUALIZACIÓN. Licencia de sitio 1 2 3 4 5
Descuento académico Y N N N N
Descuento por cantidad Y Y N N
Y N Y N
Costo de actualización = Cos
to de licencia de sitio
Costo de actualización = Cos X
to académico * Número de
Costo de actualización = Cos copias
to de descuento * Número X
Costo de actualización = Cos de copias
to por copia * Número de cop X
Costo de actualización = (Co ias
sto académico – Descuento) X
* Número de copias
X
www.xlibros.com
CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 279
derecho y las entradas de acción están en el cuadrante inferior derecho. Las acciones muestran cómo se determina el costo de
actualización para cada condición, lo cual se indica mediante una X en las columnas de las reglas.
EJERCICIOS
Nota: si no utiliza Visible Analyst, puede realizar algunos de los siguientes ejercicios mediante una plantilla de Microsoft Word o Microsoft
Excel para tablas de decisión. El repositorio también está disponible como página Web.
E-1. Use Visible Analyst para ver la entrada en el repositorio del Proceso (Process) para ACTUALIZAR PEDIDO DE COMPU-
TADORAS PENDIENTES (UPDATE PENDING COMPUTER ORDER).
E-2. Use Visible Analyst para modificar e imprimir la entrada del Proceso (Process) SUBTOTALES DE HARDWARE ACUMU-
LATIVOS (ACCUMULATIVE HARDWARE SUBTOTALS). Agregue la Descripción del proceso (Process Descrip-
tion): “Acumular los subtotales de hardware. Estos incluyen el número de máquinas para cada marca de hardware”.
E-3. Use Visible Analyst para modificar e imprimir la entrada del Proceso (Process) CONFIRMAR ELIMINACIÓN DE
COMPUTADORA (CONFIRM COMPUTER DELETION). Agregue la siguiente Descripción del proceso (Process
description):
Usa el REGISTRO DE COMPUTADORA (COMPUTER RECORD) para aplicar formato a la pantalla Confirmación
de eliminación (Deletion Confirmation) (consultar la pantalla Eliminar prototipo de computadora [Delete
Computer Prototype]).
Pedir al usuario que haga clic en el botón OK para confirmar la eliminación; en caso contrario, hacer clic en el botón
Cancelar (Cancel) para cancelar la eliminación.
Si el operador hace clic en OK para eliminar el registro, eliminar el registro y mostrar un mensaje “Se eliminó el
registro”; en caso contrario mostrar un mensaje “Se canceló la eliminación”.
E-4. Crear especificaciones de Proceso (Process) para el proceso 6.6, VALIDAR MODIFICACIONES DE COMPUTA-
DORA (VALIDATE COMPUTER CHANGES). La Descripción del proceso (Process Description) para el proceso es
la siguiente:
Validar las modificaciones en el ARCHIVO MAESTRO DE COMPUTADORA (COMPUTER MASTER). Incluir una nota
para usar los criterios de edición establecidos para cada elemento. Proveer los siguientes criterios de edición adicionales:
La UBICACIÓN DE LA SALA (ROOM UBICATION) debe ser válida para un campus específico.
No debe haber un segundo disco duro sin el primero.
La FECHA DEL ÚLTIMO MANTENIMIENTO PREVENTIVO (LAST PREVENTIVE MAINTENANCE DATE) no
debe ser mayor que la fecha actual.
La FECHA DE COMPRA (DATE PURCHASED) no debe ser mayor que LA FECHA DEL ÚLTIMO
MANTENIMIENTO PREVENTIVO (LAST PREVENTIVE MAINTENANCE DATE) ni mayor que la fecha actual.
El MODELO (MODEL) se debe conformar al tipo soportado por el nombre de MARCA (BRAND).
No se pueden realizar modificaciones en un registro inactivo.
E-5. Cree especificaciones de proceso para el proceso 1.4, CREAR ARCHIVO DE REGISTRO DE SOFTWARE (CREATE
SOFTWARE LOG FILE). Use los ejemplos del diagrama de flujo de datos para determinar las entradas y salidas. Los
detalles del proceso son los siguientes:
Aplicar formato a la ENTRADA EN EL REGISTRO DE SOFTWARE (SOFTWARE LOG RECORD) a partir de la
siguiente información:
Los elementos NUEVO REGISTRO DE SOFTWARE (NEW SOFTWARE RECORD) confirmados.
Los siguientes elementos del sistema: FECHA DEL SISTEMA (SYSTEM DATE), HORA DEL SISTEMA (SYSTEM
TIME), ID DE USUARIO (USER ID).
Cuando se haya aplicado formato al registro, escribir en el ARCHIVO DE REGISTRO DE SOFTWARE (SOFTWARE
LOG FILE).
E-6. Produzca las especificaciones de proceso para el proceso 9.7.2, BUSCAR REGISTRO DE HARDWARE QUE COIN-
CIDA (FIND MATCHING HARDWARE RECORD). Este proceso forma parte de un programa que produce un informe
en el que se muestran todas las computadoras en las que se encuentra cada paquete de software. Use Visible Analyst o
Microsoft Visio para ver el diagrama de flujo de dato 9.7. Use español estructurado para describir la siguiente lógica:
Para cada REGISTRO DE SOFTWARE (SOFTWARE RECORD), realizar una iteración mientras haya un número de
inventario de hardware que coincida.
Dentro del ciclo, realizar las siguientes tareas:
Leer el ARCHIVO MAESTRO DE COMPUTADORAS (COMPUTER MASTER).
Si se encuentra un registro, aplicar formato a la información del REGISTRO DE COMPUTADORA QUE COINCIDA
(MATCHING COMPUTER RECORD).
Si no se encuentra un registro, aplicar formato a una línea de error SIN COINCIDENCIAS (NO MATCHING).
Además, si el REGISTRO DE COMPUTADORA (COMPUTER RECORD) que se encontró está inactivo, indicando
que se retiró del servicio, aplicar formato a una línea de error de COMPUTADORA QUE COINCIDE INACTIVA
(INACTIVE MATCHING COMPUTER).
www.xlibros.com
280 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA E9.2
Tabla de decisión BUSCAR
UBICACIÓN DE SOFTWARE. Condiciones y acciones
Se encontró un registro de soft 1 2 3 4
ware que coincide 5
Se encontró la versión de soft Y Y Y Y
ware N
Se encontró un registro de com Y Y Y N
putadora que coincide
Se encontró código de campus Y Y N
en la tabla
Y N
Mostrar el mensaje de error ‘No
hay registro de software que
coincida’ X
Mostrar el mensaje de error ‘Ver
sión no disponible’
Mostrar el mensaje de error ‘No X
se encontró el código de campus’
Mostrar información sobre la ubic X
ación
X
E-7. Cree la tabla de decisión BUSCAR UBICACIÓN DE SOFTWARE (FIND SOFTWARE LOCATION), la cual representa
la lógica para un programa de consulta que muestra todas las ubicaciones para un TÍTULO DE SOFTWARE (SOFT-
WARE TITLE) y VERSIÓN (VERSION) dados. Se crearon y optimizaron las condiciones para producir cinco reglas,
las cuales se ilustran en la figura E9.2. Introduzca las acciones que hay que introducir y una X en la columna relacionada
con las condiciones. Si utiliza un procesador de palabras, imprima la tabla de decisión final. Las condiciones y acciones
se representan mediante la siguiente lógica:
Se localiza el archivo MAESTRO DE SOFTWARE (SOFTWARE MASTER) para el TÍTULO (TITLE) especifi-
cado. Si no se encuentra un registro que coincida, se muestra un mensaje de error. Como puede haber varias versiones,
se revisa el NÚMERO DE VERSIÓN (VERSION NUMBER) en el registro para ver si coincide con la versión introdu-
cida. Si no se encuentra la versión solicitada, se leen más registros mediante el uso del índice alterno. SI se leen todos los
registros y no se encuentra el número de versión, se muestra el mensaje de error VERSIÓN NO DISPONIBLE (VER-
SION NOT AVAILABLE).
Una vez que se localiza el software correcto, se obtiene un registro ARCHIVO MAESTRO DE COMPUTADORAS
(COMPUTER MASTER) coincidente. Si no se encuentra el ARCHIVO MAESTRO DE COMPUTADORAS, se mues-
tra el mensaje de error NO SE ENCONTRÓ LA MÁQUINA (MACHINE NOT FOUND). Para cada máquina que coin-
cida, se busca en la TABLA DE CAMPUS (CAMPUS TABLE) el código de la UBICACIÓN DEL CAMPUS (CAMPUS
LOCATION). Si no se encuentra el código, se muestra el mensaje CAMPUS CODE NOT FOUND (NO SE ENCONTRÓ
EL CÓDIGO DE CAMPUS).
Si no hay errores, se muestra la información solicitada.
E-8. Cree una tabla de decisiones para una actualización por lotes de la tabla de base de datos ARCHIVO MAESTRO DE
COMPUTADORAS (COMPUTER MASTER). La información se envía de un campus regional en formato de XML que
contiene tres tipos de actualizaciones: Agregar (Add), Eliminar (Delete) y Modificar (Change).
Hay que leer el registro del ARCHIVO MAESTRO DE COMPUTADORAS. Si la transacción es Agregar y no se
encuentra el archivo maestro, aplicar formato y escribir el nuevo registro del ARCHIVO MAESTRO DE COMPUTADO-
RAS. Imprimir una línea de transacción válida en un INFORME DE ACTUALIZACIÓN (UPDATE REPORT). Para una
transacción Modificar o Eliminar, imprimir una LÍNEA DE ERROR DE MODIFICACIÓN (CHANGE ERROR LINE)
o una LÍNEA DE ERROR DE ELIMINACIÓN (DELETE ERROR LINE) si no se encuentra el registro en el ARCHIVO
MAESTRO DE COMPUTADORAS.
Si se encuentra el registro, revisar el código activo. Si el registro está inactivo y la transacción es Agregar, aplicar
formato y volver a escribir el nuevo registro del ARCHIVO MAESTRO DE COMPUTADORA. Imprimir una línea de
transacción válida en un INFORME DE ACTUALIZACIÓN. Para una transacción Modificar o Eliminar, imprimir una
LÍNEA DE ERROR DE MODIFICACIÓN o una LÍNEA DE ERROR DE ELIMINACIÓN.
Si el registro del ARCHIVO MAESTRO DE COMPUTADORA está activo y la transacción es Agregar, imprimir
una LÍNEA DE ERROR DE AGREGAR. Para una transacción Modificar, aplicar formato a los cambios y volver a es-
cribir el registro del ARCHIVO MAESTRO DE COMPUTADORA. Imprimir la LÍNEA DE TRANSACCIÓN VÁLIDA
(VALID TRANSACTION LINE). Para una transacción Eliminar, cambiar el CÓDIGO ACTIVO (ACTIVE CODE) a
inactivo y volver a escribir el registro del ARCHIVO MAESTRO DE COMPUTADORAS. Imprimir la LÍNEA DE
TRANSACCIÓN VÁLIDA (VALID TRANSACTION LINE).
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
CAPÍTULO 10
Análisis y diseño de sistemas
orientados a objetos
mediante el uso de UML1
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender qué es el análisis y diseño de sistemas orientados a objetos, y apreciar su utilidad.
2. Comprender los conceptos del lenguaje unificado de modelado (UML), la metodología
estándar para modelar un sistema en el mundo orientado a objetos.
3. Aplicar los pasos utilizados en el UML para descomponer el sistema en un modelo de
casos de uso y después en un modelo de clases.
4. Hacer diagramas de los sistemas con el conjunto de herramientas de UML, para poder
describirlos y diseñarlos en forma apropiada.
5. Documentar y comunicar el sistema orientado a objetos recién modelado para los
usuarios y demás analistas.
1
Por Julie E. Kendall, Kenneth E. Kendall y Allen Schmidt.
281
www.xlibros.com
282 PARTE III • EL PROCESO DE ANÁLISIS
Objetos
Los objetos son personas, lugares o cosas relevantes para el sistema a analizar. Los sistemas orientados a objetos
describen las entidades como objetos. Algunos objetos comunes son clientes, artículos, pedidos, etcétera. Los
objetos también pueden ser pantallas de GUI o áreas de texto en la pantalla.
Clases
Por lo general, los objetos forman parte de un grupo de elementos similares, conocidos como clases. La intención
de colocar elementos en clases no es nuevo. Describir el mundo como algo compuesto de animales, vegetales y
minerales es un ejemplo de clasificación. La metodología científica incluye clases de animales (como mamífe-
ros) y después divide esas clases en subclases (como animales que ponen huevos, y mamíferos marsupiales).
La idea subyacente es tener un punto de referencia y describir un objeto específico en términos de sus simi-
litudes o diferencias en relación con los miembros de su propia clase. Al hacer esto es más eficiente para alguien
decir: “El oso koala es un marsupial (o animal con bolsa) con una cabeza grande y redonda, y con oídos pelu-
dos” que tratar de describir un oso koala a través de todas sus características como mamífero. Es más eficiente
describir las características, apariencia e incluso el comportamiento de esta manera. La palabra reutilizable, en el
mundo orientado a objetos, significa que se puede ser más eficiente gracias a que no hay necesidad de comenzar
desde el principio para describir cada objeto cada vez que se requiera en el desarrollo de software.
Los objetos se representan y agrupan mediante clases, las cuales son óptimas para la reutilización y la facili-
dad de mantenimiento. Una clase define el conjunto de atributos compartidos y comportamientos que se encuen-
tran en cada objeto de la clase. Por ejemplo, los registros para los estudiantes en la sección de un curso tienen
información similar almacenada para cada estudiante. Se dice que los estudiantes conforman una clase. Los valo-
res pueden ser distintos para cada estudiante, pero el tipo de información es el mismo. Los programadores deben
definir las diversas clases en el programa que escriben. Al ejecutarse el programa se pueden crear objetos a partir de
la clase establecida. El término instanciar se utiliza cuando se crea un objeto a partir de una clase. Por ejemplo,
un programa podría instanciar un estudiante llamado Peter Wellington como un objeto de la clase etiquetada
como estudiante.
Lo que distingue a la programación orientada a objetos (y por ende al análisis y diseño orientado a ob-
jetos) de la programación clásica es la técnica de colocar todos los atributos y métodos de un objeto dentro
de una estructura autocontenida, la clase en sí. Éste es un acontecimiento familiar en el mundo físico. Por
ejemplo, la mezcla de un pastel en caja es análoga a una clase, ya que tiene los ingredientes así como las
instrucciones sobre cómo mezclar y hornear el pastel. Un suéter de lana es similar a una clase, ya que tiene
una etiqueta cosida con instrucciones sobre su cuidado, que le advierten lavarlo a mano y dejarlo secar ex-
tendido.
Cada clase debe tener un nombre que la distinga de las demás. Por lo general, los nombres de las clases son
sustantivos o frases cortas y empiezan con mayúscula. En la figura 10.1 la clase se llama AutoRenta. En UML,
una clase se dibuja como un rectángulo. Este rectángulo contiene otras dos características importantes: una lista
de atributos y una serie de métodos. Estos elementos describen una clase, la unidad de análisis que forma una
gran parte de lo que llamamos análisis y diseño orientado a objetos.
Un atributo describe cierta propiedad que poseen todos los objetos de la clase. Cabe mencionar que la clase
AutoRenta posee los atributos de tamanio, color, marca y modelo. Todos los automóviles poseen estos atributos,
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 283
pero cada automóvil tendrá distintos valores para sus atributos. Por ejemplo, un automóvil puede ser azul, blanco
o de algún otro color. Más adelante demostraremos que puede ser más específico sobre el rango de valores para
estas propiedades. Al especificar atributos, por lo general la primera letra va en minúscula.
Un método es una acción que se puede solicitar de cualquier objeto de la clase. Los métodos son los procesos
que una clase sabe cómo llevar a cabo. También se les conoce como operaciones. Para la clase AutoRenta, ren-
tar(), devolver() y reparar() son ejemplos de métodos. Al especificar métodos, por lo general la primera letra está
en minúscula.
Herencia
Otro concepto clave de los sistemas orientados a objetos es la herencia. Las clases pueden tener hijos; es decir, se
puede crear una clase a partir de otra. En UML, la clase original (o padre) se conoce como clase base; a la clase
hija se le denomina clase derivada. Podemos crear una clase derivada de tal forma que herede todos los atributos
y comportamientos de la clase base. Sin embargo, una clase derivada puede tener atributos y comportamientos
adicionales. Por ejemplo, podría haber una clase Vehículo para una empresa de renta de automóviles que con-
tenga atributos tales como tamaño, color y marca.
La herencia reduce la labor de programación al permitir que se utilicen los objetos comunes con facilidad. El
programador sólo necesita declarar que la clase Auto hereda de la clase Vehículo y después proporcionar todos
los detalles adicionales sobre los nuevos atributos o comportamientos que sean únicos para un automóvil.
Todos los atributos y comportamientos de la clase Vehículo pasan de manera automática e implícita a formar
parte de la clase Auto y no requieren de programación adicional. Esto permite al analista definir una vez pero
usar muchas veces; algo similar a los datos que están en la tercera forma normal, que se definen sólo una vez en
una tabla de la base de datos (como veremos en el capítulo 13).
Las clases derivadas que se muestran en la figura 10.2 son Auto o Camión. Aquí se antepone un signo ne-
gativo a los atributos y un signo positivo a los métodos. Más adelante en el capítulo hablaremos sobre esto con
más detalle; por ahora tenga en cuenta que los signos negativos significan que estos atributos son privados (no
se comparten con otras clases) y que los signos positivos significan que estos métodos son públicos (otras clases
pueden invocarlos).
es un es un
Auto Camion
–tamanio –tamanio
–color –color
–marca –marca
–modelo –modelo
–disponible –disponible
–tarifaPorDia –tarifaPorDia
–tarifaPorSemana –tarifaPorSemana
–tarifaPorMilla –tarifaPorMilla
–estilo –longitud
+rentar() –traccion4Ruedas
+devolver() –cambioManual
+reparar() +rentar()
+agregarNuevo() +devolver()
+reparar()
+agregarNuevo()
www.xlibros.com
284 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U LT O R Í A 1 0 . 1
La reutilización de código de programa ha formado parte del desarrollo de sistemas estructurados y los len-
guajes de programación (como COBOL) durante muchos años; además han existido subprogramas que encapsu-
lan datos. Sin embargo, la herencia es una herramienta que se encuentra sólo en los sistemas orientados a objetos.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 285
alguien sostiene una tarjeta en el aire, se considera un objeto y puede hacer cosas. Después el grupo procede a re-
finar la responsabilidad en tareas cada vez más pequeñas, de ser posible. Si es apropiado, el objeto pude cumplir
con estas tareas o el grupo puede decidir que se cumplan mediante la interacción con otras cosas. Si no existen
otras clases apropiadas, tal vez el grupo tenga que crear una.
Las cuatro tarjetas CRC descritas en la figura 10.3 muestran cuatro clases de ofrecimientos de cursos. Ob-
serve que en una clase llamada Curso, el analista de sistemas es referido a cuatro colaboradores: el departa-
www.xlibros.com
286 PARTE III • EL PROCESO DE ANÁLISIS
mento, el libro de texto, la asignación del curso y el examen del curso. Después, estos colaboradores se describen
como clases por sí solas en las otras tarjetas CRC.
Las responsabilidades que se enlistan evolucionarán en un momento dado en lo que se conoce como méto-
dos en UML. Los enunciados de Pensamiento en objetos parecen rudimentarios, pero son conversacionales, de
tal forma que alientan a los analistas durante una sesión CRC a describir tantos de estos enunciados como pue-
dan. Como vimos en el ejemplo, todo el diálogo durante una sesión CRC se lleva a cabo en primera persona, de
manera que hasta el libro de texto habla: “Conozco mi ISBN”, “Conozco mi autor”. Después, estos enunciados
se pueden utilizar para describir atributos en UML. Podemos llamar a estos atributos según los nombres de sus
variables, como edicion y editorial.
FIGURA 10.4
Categoría de UML Elementos de UML Detalles específicos de UML
Una vista general de UML y sus
componentes: cosas, relaciones y Cosas Cosas estructurales Clases
diagramas. Interfaces
Colaboraciones
Casos de uso
Clases activas
Componentes
Nodos
Cosas de Interacciones
comportamiento Máquinas de estado
Relaciones de Comunica
comportamiento Incluye
Extiende
Generaliza
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 287
objeto, pero en UML se les llama cosas. Las cosas estructurales son las más comunes. Las cosas estructurales
son clases, interfaces, casos de uso y muchos otros elementos que proveen la forma de crear modelos. Las cosas
estructurales permiten al usuario describir las relaciones. Las cosas de comportamiento describen la forma en
que funcionan las cosas. Algunos ejemplos de cosas de comportamiento son las interacciones y las máquinas
de estado. Las cosas de grupo se utilizan para definir límites. El paquete es un ejemplo de cosa de grupo. Por
último tenemos las cosas de anotaciones, para poder agregar notas en los diagramas.
Las relaciones son el pegamento que mantiene las cosas unidas entre sí. Es conveniente pensar en la relaciones
de dos formas. Las relaciones estructurales se utilizan para unir las cosas en los diagramas estructurales. Las relacio-
nes estructurales incluyen dependencias, agregaciones, asociaciones y generalizaciones. Por ejemplo, las relaciones
estructurales muestran herencia. Las relaciones de comportamiento se utilizan en los diagramas de comportamiento.
Los cuatro tipos básicos de relaciones de comportamiento son comunica, incluye, extiende y generaliza.
Hay dos tipos principales de diagramas en UML: diagramas estructurales y diagramas de comportamiento.
Los diagramas estructurales se utilizan, por ejemplo, para describir las relaciones entre las clases. Éstos se divi-
den en diagramas de clases, diagramas de objetos, diagramas de componentes y diagramas de despliegue. Por
otro lado, los diagramas de comportamiento se pueden utilizar para describir la interacción entre las personas
(actores en UML) y lo que denominamos caso de uso, o la forma en que los actores utilizan el sistema. Los
diagramas de comportamiento se dividen en diagramas de casos de uso, diagramas de secuencia, diagramas de
comunicación, diagramas de estados y diagramas de actividad.
En el resto del capítulo nos enfocaremos primero en el modelado de casos de uso, la base de todas las
técnicas de UML. Después analizaremos la forma en que se utiliza un caso de uso para derivar las actividades,
secuencias y clases: los diagramas de UML que se utilizan con más frecuencia. Como hay libros completos
dedicados a la sintaxis y el uso del UML (el documento oficial de especificaciones de UML tiene más de 800
páginas), proveeremos sólo un breve resumen de los aspectos más valiosos y más utilizados del UML.
Los seis diagramas de UML que se utilizan con más frecuencia son:
1. Un diagrama de casos de uso, que describe la forma en que se utiliza el sistema.
2. Un escenario de caso de uso (aunque técnicamente no es un diagrama). Este escenario es una articulación
verbal de excepciones para el comportamiento principal descrito por el caso de uso principal.
3. Un diagrama de actividad, que ilustra el flujo de actividades en general. Cada caso de uso puede crear un
diagrama de actividad.
4. Los diagramas de secuencia, que muestran la secuencia de las actividades y las relaciones entre las clases.
Cada caso de uso puede crear uno o más diagramas de secuencia. El diagrama de comunicación es la
alternativa a un diagrama de secuencia, el cual contiene la misma información pero enfatiza la comunicación
en vez de la sincronización.
5. Los diagramas de clases, que muestran las clases y sus relaciones. Los diagramas de secuencia se utilizan
(junto con las tarjetas CRC) para determinar las clases. El diagrama de generalización/especialización (gen/
spec) es un derivado del diagrama de clases.
6. Los diagramas de estados, que muestran las transiciones de estado. Cada clase puede crear un diagrama de
estados, el cual es útil para determinar los métodos de la clase.
En la figura 10.5 se ilustra la forma en que se relacionan estos diagramas entre sí. En las siguientes seccio-
nes hablaremos sobre cada uno de estos diagramas.
www.xlibros.com
288 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 10.5
Una vista general de los diagramas de UML que muestra cómo cada
diagrama conduce al desarrollo de otros diagramas de UML.
Diagrama de actividad
Los e
sc
caso enarios de
de l
puede uso se
n
partir generar a
d
de ca el diagram
so de a
uso.
Identificadores
Los c Cada
a
y los sos de u Pasos caso escenario
diagr s
secu amas o d
crea e uso pu de
en r
a det cia ayud de e
de se un diagra de
e an
las c rminar Condiciones cuen
cia.
ma
lases
.
1 1..
1 1
Diagrama de estados
Los d
ia
secu gramas
e de
comu ncia y
nicac
inter
camb ión son
Cada iable
s.
c
tener lase pue
d
de es un diagra e
tado ma
ayud s par
a a
las o r a deter
perac m
iones inar
.
La figura 10.6 es el ejemplo de un caso de uso de la inscripción de estudiantes en una universidad. Cabe
mencionar que se representan sólo las funciones más importantes. El caso de uso Agregar estudiante no indica
cómo agregar estudiantes, el método de implementación. Los estudiantes se pueden agregar en persona, a través
de Web, mediante el uso de un teléfono de tonos o a través de una combinación de todos estos métodos. El caso de
uso Agregar estudiante incluye el caso de uso Verificar identidad para verificar la identidad del estudiante. El
caso de uso Comprar libro de texto extiende el caso de uso Inscribirse en clase y puede formar parte de un
sistema para inscribir a los estudiantes en un curso en línea.
Tal vez parezca que el caso de uso Cambiar información de estudiante fuera una característica menor del sis-
tema y no debiera incluirse en el diagrama de casos de uso, pero como esta información cambia con frecuencia, la ad-
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 289
Agregar
estudiante
Estudiante
e >> Registro
luy
inc
<<
Oficina financiera
<< incluye >>
<<
<<
inc
ext
luy
ien
e>
de
>
>>
Cambiar
información Ver información Comprar libro
de estudiante de estudiante de texto
Tienda de libros
Transferir
créditos
FIGURA 10.6
Estudiante Departamento Ejemplo de casos de uso sobre la
inscripción de estudiantes.
ministración tiene mucho interés en permitir a los estudiantes cambiar su propia información personal. El hecho de que
los administradores consideren esto importante no sólo justifica, sino también exige, que se elabore el caso de uso.
No se debe permitir a los estudiantes cambiar el promedio de su calificación, las cuotas pendientes u otra
información relacionada. Este caso de uso también incluye el caso de uso Verificar identidad, que en esta situa-
ción significa que el estudiante tiene que introducir un ID de usuario y una contraseña para poder acceder al sis-
tema. Ver información de estudiante permite a los estudiantes ver su información personal, así como los cursos
y las calificaciones.
En la figura 10.7 se muestra el ejemplo de un escenario de caso de uso. Algunas de las áreas incluidas son
opcionales ya que tal vez no todas las organizaciones las utilicen. Las tres áreas principales son:
1. Un área de encabezado que contiene los identificadores e iniciadores de casos.
2. Los pasos realizados.
3. Un área al pie que contiene las precondiciones, suposiciones, preguntas y demás información.
En la primera área el caso de uso se identifica por su nombre, Cambiar información de estudiante; el actor
se identifica como Estudiante y se describen el Caso de uso y Evento desencadenador. La segunda área contiene
una serie de pasos que se realizan siempre y cuando no haya errores. Por último, en la tercera área se identifican
todas las pre- y post-condiciones, además de las suposiciones. Algunas de éstas son obvias, como la pre-condi-
ción de que el estudiante esté en la página Web correcta y la suposición de que el estudiante tenga un ID y con-
traseña válidos. Otras no son tan obvias, como la cuestión pendiente relacionada con las veces que se permite a
un estudiante iniciar sesión en el sistema.
www.xlibros.com
290 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 10.7
Un escenario de caso de uso se divide en tres secciones:
identificación e iniciación, pasos realizados y las condiciones,
suposiciones y preguntas.
Los diagramas de casos de uso proveen la base para crear otros tipos de diagramas, como los diagramas de
clases y los diagramas de actividad. Los escenarios de casos de uso son útiles para dibujar diagramas de secuen-
cia. Tanto los diagramas de casos de uso como los escenarios de casos de uso son potentes herramientas para
ayudarnos a comprender la forma en que un sistema funciona en general.
DIAGRAMAS DE ACTIVIDAD
Los diagramas de actividad muestran la secuencia de actividades en un proceso, incluyendo las actividades se-
cuenciales y paralelas, además de las decisiones que se toman. Por lo general se crea un diagrama de actividad
para un caso de uso y puede mostrar los distintos escenarios posibles.
En la figura 10.8 se muestran los símbolos en los diagramas de actividad. Un rectángulo con esquinas redon-
das representa una actividad, ya sea manual —como firmar un documento— o automatizada —como un método
o programa—.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 291
iones Inicio
Las bifurcac
iten real izar
perm
ades en
activid
paralelo.
Actividad
Bifurcación
regar
Podemos ag
s a es te
carrile
[condición] [sino] ra
ciones diagrama pa
Las ramifica r
iten ac tividades as ig na
perm ades.
ivas se gún Ramificación responsabilid
alternat
las distintas
condiciones. Actividad Actividad Actividad
Fusión
Unión
FIGURA 10.8
Se utilizan símbolos
Fin especializados para dibujar un
diagrama de actividad.
Una flecha representa a un evento. Los eventos representan cosas que ocurren en cierto momento y lugar.
Un diamante representa una decisión (también conocida como ramificación) o una fusión. En las decisiones
hay una flecha que entra al diamante y varias que salen de él. Se puede incluir una condición de guardia, que mues-
tra los valores de la condición. Las fusiones muestran varios eventos que se combinan para formar un evento.
Un rectángulo largo y plano representa una barra de sincronización. Estas barras se utilizan para mostrar las
actividades paralelas, donde puede haber un evento que entre a la barra de sincronización y varios eventos que
salgan de ella, a lo cual se le denomina bifurcación. Una sincronización en la que varios eventos se fusionan en
uno solo se denomina unión.
Hay dos símbolos que muestran el inicio y fin del diagrama. El estado inicial se muestra como un círculo
relleno. El estado final se muestra como un círculo negro rodeado por un círculo blanco.
Los rectángulos que rodean otros círculos se denominan carriles (swimlanes). Estos carriles indican particio-
namiento y se utilizan para mostrar qué actividades se realizan en cada plataforma, como un navegador, servidor
o computadora mainframe; también muestran las actividades que realizan distintos grupos de usuarios. Los carri-
les son zonas que pueden describir tanto la lógica como la responsabilidad de una clase.
En la figura 10.9 podemos ver un ejemplo de carriles. En esta figura se ilustra un diagrama de actividad
para el caso de uso Cambiar información de estudiante. Empieza con el estudiante al iniciar sesión en el sis-
tema mediante el proceso de llenar un formulario Web y hacer clic en el botón Enviar. El formulario se trans-
mite al servidor Web, el cual pasa a su vez los datos a la computadora mainframe. La mainframe accede a la
base de datos de ESTUDIANTES y pasa el mensaje “No se encontró” o los datos del estudiante seleccionado
al servidor Web.
El diamante debajo del estado Obtener registro de estudiante indica esta decisión. Si no se encontró el
registro del estudiante, el servidor Web muestra un mensaje de error en la página Web. Si se encontró el registro
del estudiante, el servidor Web da formato a una nueva página Web que contiene los datos del estudiante en un
formulario Web. El estudiante puede cancelar el cambio a través de los estados Iniciar sesión en sistema o In-
troducir cambios, y la actividad se detiene.
Si el estudiante introduce los cambios en el formulario y hace clic en el botón Enviar, los datos del cambio
se transmiten al servidor y se empieza a ejecutar un programa que valida los cambios. Si hay errores se envía un
mensaje de error a la página Web; si los datos son válidos se actualiza el registro de estudiantes y se escribe un Re-
gistro en el Diario de cambios de estudiantes. Después de una actualización válida, se envía una página Web de
confirmación al navegador y termina la actividad.
www.xlibros.com
292 PARTE III • EL PROCESO DE ANÁLISIS
Se transmitió
Iniciar sesión formulario Recibir formulario ID de usuario y contraseña Obtener registro
en sistema Web de estudiante
Estado del
registro
Se recibió
formulario Web
Introducir cambios Validar cambios
Estado de validación
Se recibieron
datos inválidos Datos Datos
válidos válidos
Enviar mensajes de error Crear registro en
Mostrar mensaje Actualizar registro
Diario de cambios
de error de estudiante
de estudiantes
Se actualizó Se escribió
Cancelar
FIGURA 10.9 registro registro
Este diagrama de
actividad muestra tres Cancelar Se envió confirmación Actualización válida
Mostrar
carriles: Página Web confirmación
cliente, Servidor
Web y Mainframe.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 293
O P O R T U N I D A D D E C O N S U LT O R Í A 1 0 . 2
Los carriles son útiles para mostrar cómo se debe transmitir o convertir datos, tales como los que van del
sitio Web al servidor, o del servidor a la mainframe. Por ejemplo, el diagrama de actividad de Cambiar registro
de estudiante tiene tres carriles.
El carril de la izquierda muestra las actividades que ocurren en el navegador cliente. Hay que crear páginas
Web para estas actividades. El carril de en medio muestra las actividades que ocurren en el servidor. Los eventos
como Se transmitió formulario representan los datos que se transmiten del navegador al servidor; debe haber
programas en el servidor para recibir y procesar los datos cliente.
El carril de la derecha representa la computadora mainframe. En empresas grandes es común para muchas
aplicaciones Web trabajar con una computadora mainframe. Gran parte de los datos en las grandes organizacio-
nes residen en bases de datos de equipos mainframe y hay una gran cantidad de programas para mainframe en
existencia.
Cuando un evento cruza el carril del servidor a la computadora mainframe, debe haber un mecanismo para
transmitir los datos del evento entre las dos plataformas. Los servidores usan un formato distinto para represen-
tar datos (ASCII) al que usan las computadoras mainframe (uno llamado EBCDIC). Debe haber middleware
presente para hacerse cargo de la conversión. A menudo, las computadoras IBM utilizan una cola de mensajes
(mqueue). La cola de mensajes recibe datos de los programas del servidor, los coloca en un área de retención y
llama a un programa de la mainframe, que por lo general está escrito en un lenguaje conocido como CICS. Este
programa recupera o actualiza los datos y envía los resultados de vuelta a la cola de mensajes.
En el diagrama de actividad de ejemplo antes mostrado, la decisión debajo del estado Obtener registro de
estudiante se toma en la computadora mainframe. Esto significa que la cola de mensajes recibe un mensaje “No
se encontró” o recibe el registro de la base de datos para el estudiante. Si la mainframe simplemente colocara Se
recibió estado de registro en la cola de mensajes y la decisión se evaluara en el servidor, éste tendría que llamar
a la mainframe de nuevo para obtener los datos válidos. Esto provocaría que la respuesta llegara más tarde a la
persona que espera en el navegador.
www.xlibros.com
294 PARTE III • EL PROCESO DE ANÁLISIS
Los carriles también ayudan a dividir las tareas en un equipo. Se requieren diseñadores Web para las páginas
Web que se muestran en el navegador cliente. Otros miembros tendrían que trabajar con lenguajes de programa-
ción tales como Java, PHP, Ruby on Rails, PERL o .NET en el servidor. Los programadores de CICS de la main-
frame escribirían programas que funcionaran con la cola de mensajes. El analista debe asegurar que los datos que
necesitan los diversos miembros del equipo estén disponibles y definidos en forma correcta. Algunas veces los
datos en la cola de mensajes están en forma de un documento de XML. Si hay una organización externa involu-
crada, los datos también podrían ser un documento de XML.
El diagrama de actividad provee un mapa de un caso de uso; además permite al analista experimentar al
mover partes del diseño a distintas plataformas y preguntar: “¿Qué pasaría si?” para una variedad de decisiones.
El uso de símbolos únicos y carriles hace de este diagrama algo que las personas desean usar para comunicarse
con los demás.
Se pueden usar diagramas de actividad para construir planes de prueba. Hay que evaluar cada evento para
ver si el diagrama de actividad pasa al siguiente estado. Hay que evaluar cada decisión para ver si se toma la ruta
correcta cuando ocurren las condiciones de decisión.
Los diagramas de actividad no se utilizan para todos los casos. Debe usar diagramas de actividad cuando:
1. Le ayude a comprender las actividades de un caso de uso.
2. El flujo de control sea complejo.
3. Exista la necesidad de modelar el flujo de trabajo.
4. Haya que mostrar todos los escenarios.
El analista no necesita un diagrama de actividad cuando el caso de uso es simple, o cuando hay que modelar el
cambio de estado.
También se pueden usar los diagramas de actividad para modelar un método de nivel más bajo, en el que se
muestre la lógica detallada.
Diagramas de secuencia
Los diagramas de secuencia pueden ilustrar una sucesión de interacciones entre clases o instancias de objetos a
través del tiempo. A menudo, los diagramas de secuencia se utilizan para ilustrar el procesamiento descrito en los
escenarios de casos de uso. En la práctica, los diagramas de secuencia se derivan del análisis de casos de uso y se
utilizan en el diseño de sistemas para derivar las interacciones, las relaciones y los métodos de los objetos en el
sistema. Los diagramas de secuencia se utilizan para mostrar el patrón general de las actividades o interacciones
en un caso de uso. Cada escenario de caso de uso puede crear un diagrama de secuencia, aunque éstos no siem-
pre se crean para escenarios de menor importancia.
En la figura 10.10 se muestran los símbolos utilizados en los diagramas de secuencia. Los actores y las cla-
ses o instancias de objetos se muestran en cuadros en la parte superior del diagrama. El objeto de más a la iz-
quierda es el objeto inicial y puede ser una persona (para la cual se utiliza un símbolo de actor de caso de uso),
ventana, cuadro de diálogo u otra interfaz de usuario. Algunas de las interacciones son sólo físicas, como la firma
de un contrato. Los rectángulos de la parte superior utilizan indicadores en el nombre para indicar si el rectán-
gulo representa un objeto, una clase, o una clase y un objeto.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 295
FIGURA 10.10
::Clase Objecto::Clase Símbolos especializados que se
utilizan para dibujar un diagrama
de secuencia.
método(Parámetro)
retorno
señalAsíncrona()
Una línea vertical representa la línea de vida de la clase u objeto, que corresponde al tiempo a partir del que se creó
hasta el momento en que se destruye. Una X en la parte inferior de la línea de vida representa el momento en que
se destruye el objeto. Una barra lateral o un rectángulo vertical en la línea de vida muestran el foco de control
cuando el objeto está ocupado haciendo cosas.
Las flechas horizontales muestran mensajes o señales que se envían entre las clases. Los mensajes perte-
necen a la clase receptora. Hay algunas variaciones en las flechas de los mensajes. Las puntas de flecha sólidas
representan llamadas sincrónicas, que son las más comunes. Éstas se utilizan cuando la clase emisora espera una
respuesta de la clase receptora y el control se devuelve a la clase emisora cuando la clase receptora que recibe el
mensaje termina de ejecutarse. Las medias puntas de flecha (o abiertas) representan llamadas asíncronas: aque-
llas que se envían sin esperar que la clase emisora las devuelva. Un ejemplo sería el uso de un menú para ejecutar
un programa. El retorno se muestra como una flecha, algunas veces con una línea punteada. Los mensajes se eti-
quetan mediante el uso de uno de los siguientes formatos:
El nombre del mensaje seguido de paréntesis vacíos: nombreMensaje().
El nombre del mensaje seguido de parámetros entre los paréntesis: nombreMensaje(parámetro1,
parámetro2 …).
El nombre del mensaje seguido del tipo de parámetro, nombre del parámetro y cualquier valor
predeterminado para el parámetro entre paréntesis: nombreMensaje(tipoParámetro:nombreParámetro-
(valorPredeterminado). Los tipos de los parámetros indican el tipo de datos, como cadena, número o fecha.
El mensaje puede ser un estereotipo tal como <<Crear>> para indicar que se va a crear un nuevo objeto
como resultado del mensaje.
La sincronización en el diagrama de secuencia se muestra de arriba hacia abajo; la primera interacción se
dibuja en la parte superior del diagrama y la interacción que ocurre al último se dibuja en la parte inferior del
diagrama. Las flechas de interacción empiezan en la barra del actor u objeto que inicia la interacción y termi-
nan apuntando a la barra del actor u objeto que recibe la solicitud de interacción. El actor inicial u objeto se
muestra a la izquierda. Éste puede ser el actor que inicia la actividad o una clase que represente la interfaz de
usuario.
La figura 10.11 es un ejemplo simplificado de un diagrama de secuencia para un caso de uso que admite
a un estudiante en una universidad. A la izquierda está la clase interfazUsuarioNuevoEstudiante que se
utiliza para obtener la información del estudiante. El mensaje inicializar() se envía a la clase Estudiante, la
cual crea un nuevo registro de estudiante y devuelve el número de estudiante. Para simplificar el diagrama
omitimos los parámetros que se envían a la clase Estudiante, pero éstos deben incluir el nombre del estu-
diante, su dirección y otros. La siguiente actividad es enviar un mensaje seleccionarDormitorio a la clase
www.xlibros.com
296 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 10.11
::interfazUsuario
Un diagrama de secuencia para ::Estudiante ::dormitorio ::programa
NuevoEstudiante
admitir a un estudiante. Los
diagramas de secuencia hacen inicializar( )
énfasis en el orden de los mensajes
en el tiempo.
regresar numeroEstudiante
seleccionarDormitorio( )
regresar cuartoDormitorio
seleccionarPrograma( )
regresar consejeroPrograma
estudianteCompleto( )
Dormitorio. Este mensaje debe incluir la información de selección del dormitorio, como un dormitorio para
el cuidado de la salud u otros requerimientos del estudiante. La clase Dormitorio devuelve el nombre del
dormitorio y el número de habitación. La tercera actividad es enviar un mensaje seleccionarPrograma a
la clase Programa, incluyendo el nombre del programa y demás información sobre el curso de estudio. Se
devuelve el nombre del consejero del programa a la clase interfazUsuarioNuevoEstudiante. Se envía un
mensaje estudianteCompleto a la clase Estudiante con el nombre del dormitorio, del consejero y demás
información pertinente.
Los diagramas de secuencia se pueden utilizar para traducir el escenario de caso de uso en una herramienta
visual para el análisis de sistemas. El diagrama de secuencia inicial utilizado en el análisis de sistemas muestra
los actores y las clases en el sistema, así como las interacciones entre ellos para un proceso específico. Usted
puede utilizar esta versión del diagrama de secuencia para verificar los procesos con los expertos del área de ne-
gocios que le hayan ayudado a desarrollar los requerimientos del sistema. Un diagrama de secuencia hace énfasis
en el orden de los mensajes (secuencia) en el tiempo.
Durante la fase de diseño de sistemas, los diagramas de secuencia se refinan para derivar los métodos y las
interacciones entre las clases. Los mensajes de una clase se utilizan para identificar las relaciones de las clases.
Los actores en los primeros diagramas de secuencia se traducen en interfaces y las interacciones de las clases
se traducen en métodos de clase. Los métodos de clase que se utilizan para crear instancias de otras clases y
realizar otras funciones internas del sistema se revelan en el diseño del sistema mediante el uso de diagramas
de secuencia.
Diagramas de comunicación
Los diagramas de comunicación se introdujeron en el UML 2.0. Su nombre original en el UML 1.x era diagra-
mas de colaboración. Los diagramas de comunicación describen las interacciones entre dos o más cosas en el
sistema que desempeñan un comportamiento mayor a lo que cualquiera de las dos cosas pueden hacer por su
cuenta. Por ejemplo, un automóvil se puede descomponer en varios miles de piezas individuales. Las piezas se
conectan para formar los subsistemas principales del vehículo: el motor, la transmisión, el sistema de frenos,
etcétera. Las piezas individuales del automóvil se pueden considerar como clases, ya que tienen distintos atri-
butos y funciones. Las piezas individuales del motor forman una colaboración, ya que se “comunican” entre sí
para hacer que el motor funcione cuando el conductor pisa el acelerador.
Un diagrama de comunicación consta de tres partes: los objetos (también llamados participantes), los enla-
ces de comunicación y los mensajes que se pueden pasar a través de esos enlaces. Los diagramas de comunica-
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 297
1:inicializar( )
3:seleccionarPrograma( )
::ninterfazUsuario
::estudiante ::programa
NuevoEstudiante
4:estudianteCompleto( )
ción muestran la misma información que un diagrama de secuencia, pero pueden ser más difíciles de leer. Para
poder mostrar el orden en el tiempo, debemos indicar un número de secuencia y describir el mensaje.
Un diagrama de comunicación hace énfasis en la organización de los objetos, mientras que un diagrama de
secuencia hace énfasis en el orden de los mensajes en el tiempo. Un diagrama de comunicación mostrará una
ruta para indicar cómo está un objeto enlazado con otro.
Cierto software de modelado de UML, como Rational Rose de IBM, convierte con el clic de un botón un
diagrama de secuencia en un diagrama de comunicación, o un diagrama de comunicación en un diagrama de
secuencia. En la figura 10.12 se muestra el diagrama de comunicación para admitir a un estudiante. Cada rectán-
gulo representa a un objeto o una clase. Las líneas conectoras muestran las clases que necesitan colaborar o tra-
bajar entre sí. Los mensajes que se envían de una clase a otra se muestran a lo largo de las líneas conectoras. Los
mensajes están numerados para mostrar la secuencia en el tiempo. También se pueden incluir valores de retorno
y se pueden enumerar para indicar cuándo se devuelven dentro de la secuencia de tiempo.
DIAGRAMAS DE CLASES
Las metodologías orientadas a objetos trabajan para descubrir las clases, atributos, métodos y relaciones entre
las clases. Como la programación ocurre a nivel de clase, definir clases es una de las tareas más importantes del
análisis orientado a objetos. Los diagramas de clases muestran las características estáticas del sistema y no repre-
sentan ningún procesamiento en especial. Un diagrama de clases también muestra la naturaleza de las relaciones
entre las clases.
En un diagrama de clases, las clases se representan mediante un rectángulo. En el formato más simple, el
rectángulo puede incluir sólo el nombre de la clase, pero también puede incluir atributos y métodos. Los atribu-
tos son lo que la clase conoce sobre las características de los objetos, y los métodos (también llamados operacio-
nes) son lo que la clase sabe acerca de cómo hacer las cosas. Los métodos son pequeñas secciones de código que
trabajan con los atributos.
La figura 10.13 muestra un diagrama de clases para los ofrecimientos de cursos. Cabe mencionar que el
nombre está centrado en la parte superior de la clase, por lo general en negrita. El área justo debajo del nombre
muestra los atributos y la porción inferior lista los métodos. El diagrama de clases muestra los requerimientos de
almacenamiento de datos, así como los requerimientos de procesamiento. Más adelante en el capítulo hablare-
mos sobre el significado de los símbolos de diamante que se muestran en esta figura.
Por lo general los atributos (o propiedades) se designan como privados, o que sólo están disponibles en el
objeto. En un diagrama de clases esto se representa con un signo negativo al inicio del nombre del atributo. Los
atributos también pueden ser protegidos, lo cual se indica con un símbolo (#). Estos atributos están ocultos para
todas las clases, excepto las subclases inmediatas. Bajo raras circunstancias un atributo se hace público, lo cual
significa que otros objetos fuera de su clase pueden verlo. Hacer los atributos privados implica que serán visibles
sólo para los objetos externos a través de los métodos de la clase, una técnica que se conoce como encapsula-
miento u ocultamiento de la información.
Un diagrama de clase puede mostrar sólo el nombre de la clase, el nombre de la clase y los atributos o el
nombre de la clase, los atributos y los métodos. Es útil mostrar sólo el nombre de la clase cuando el diagrama es
muy complejo e incluye muchas clases. Si el diagrama es más simple, se pueden incluir los atributos y los méto-
dos. Cuando se incluyen los atributos hay tres formas de mostrar la información de cada uno. La más simple es
incluir sólo el nombre del atributo, lo cual ocupa la menor cantidad de espacio.
www.xlibros.com
298 PARTE III • EL PROCESO DE ANÁLISIS
Asignacion Examen
FIGURA 10.13 –numeroAsignacion –numeroExamen
Un diagrama de clases para los –descripcionAsignacion –nombreExamen
–puntosAsignacion –puntosExamen
ofrecimientos de cursos. Los
–fechaEntregaAsignacion –versionExamen
diamantes rellenos muestran
+agregarAsignacion() +agregarExamen()
agregación y los diamantes
+cambiarAsignacion() +cambiarExamen()
vacíos muestran una relación
+verAsignacion() +buscarExamen()
entre un todo y sus partes.
Se puede incluir el tipo de datos (como cadena, doble, entero o fecha) en el diagrama de clases. Las des-
cripciones más completas incluyen un signo de igual (=) después del tipo de datos, seguido del valor inicial del
atributo. La figura 10.14 ilustra los atributos de las clases.
Si el atributo debe tomar un valor de un número finito de ellos, como un tipo de estudiante con valores de C
para tiempo completo, P para tiempo parcial y N para no matriculado, éstos se pueden incluir entre llaves separa-
dos por comas: tipoEstudiante: char{F,P,N}.
El ocultamiento de información significa que los métodos de los objetos deben estar disponibles para otras
clases, por lo que comúnmente los métodos son públicos, lo cual significa que se pueden invocar desde otras
clases. En un diagrama de clases, los mensajes públicos (al igual que los atributos públicos) se muestran con un
signo positivo (+) al inicio del nombre correspondiente. Los métodos también tienen paréntesis después de su
nombre, lo cual indica que se pueden pasar datos como parámetros junto con el mensaje. En el diagrama de cla-
ses se pueden incluir los parámetros del mensaje, así como el tipo de datos.
Hay dos tipos de métodos: estándar y personalizados. Los métodos estándar son las cosas básicas que todas
las clases de objetos saben cómo hacer, como crear una nueva instancia de un objeto. Los métodos personaliza-
dos están diseñados para una clase específica.
Sobrecarga de métodos
La sobrecarga de métodos se refiere a incluir el mismo método (u operación) varias veces en una clase. La firma
del método incluye su nombre y los parámetros que incluye. El mismo método se puede definir más de una vez
en una clase dada, siempre y cuando los parámetros que se envían como parte del mensaje sean distintos; es de-
cir, debe haber una firma de mensaje distinta. Puede haber un número distintos de parámetros, o éstos pueden ser
de un tipo distinto, como un número en un método y una cadena de texto en otro método. Podemos encontrar un
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 299
ejemplo de sobrecarga de métodos en el uso de un signo de suma en muchos lenguajes de programación. Si los
atributos en ambos lados del signo de suma son números, se suman los dos números. Si los atributos son cadenas
de caracteres, las cadenas se concatenan para formar una sola cadena extensa.
En un ejemplo de un depósito bancario, un recibo de depósito podría contener sólo el monto a depositar, en
cuyo caso el banco depositaría el monto completo, o podría contener el monto a depositar y la cantidad de efec-
tivo a devolver. Ambas situaciones utilizarían un método de verificación de depósito, pero los parámetros (una de
las situaciones también requeriría devolver el monto de efectivo) serían distintos.
Tipos de clases
Las clases se dividen en cuatro categorías: de entidad, de interfaz, abstracta y de control. A continuación expli-
caremos estas categorías.
CLASES DE ENTIDAD Las clases de entidad representan elementos del mundo real como personas o cosas,
por ejemplo. Las clases de entidad son las entidades representadas en un diagrama de entidad-relación. Las
herramientas CASE como Visible Analyst le permiten crear una clase de entidad de UML a partir de una entidad
en un diagrama E-R.
El analista necesita determinar qué atributos debe incluir en las clases. Cada objeto tiene muchos atributos,
pero la clase debe incluir sólo aquellos que la organización utilice. Por ejemplo, al crear una clase de entidad
para un estudiante en una universidad necesitamos conocer los atributos que identifican al estudiante, como la
dirección de su hogar y del campus al que pertenece, así como el promedio de sus calificaciones, los créditos
totales, etcétera. Si tuviera que llevar el registro del mismo estudiante para una tienda de ropa en línea, tendría
que conocer la información básica de identificación además de otros atributos descriptivos como las medidas o
preferencias de color.
CLASES DE LÍMITE O DE INTERFAZ Las clases de límite o de interfaz proveen los medios para que los usuarios
trabajen con el sistema. Hay dos amplias categorías de clases de interfaz: humana y de sistema.
Una interfaz humana puede ser una pantalla, una ventana, un formulario Web, un cuadro de diálogo, un
menú, un cuadro de lista u otro control de visualización. También puede ser un teléfono de tonos, código de ba-
rras o cualquier otra forma en que los usuarios puedan interactuar con el sistema. Hay que crear prototipos de las
interfaces humanas (como vimos en el capítulo 6) y a menudo se utiliza un guión gráfico para modelar la secuen-
cia de interacciones.
Las interfaces del sistema necesitan enviar o recibir datos de otros sistemas. Esto puede incluir a las bases
de datos en la organización. Si se envían datos a una organización externa, por lo general se hace en la forma de
archivos de XML u otras interfaces reconocidas con mensajes y protocolos claramente definidos. Las interfaces
externas son las menos estables, ya que a menudo hay muy poco o nada de control sobre un socio externo capaz
de alterar el formato del mensaje o de los datos.
El XML ayuda a proveer estandarización, ya que un socio externo puede agregar nuevos elementos al docu-
mento de XML, aunque una corporación que transforme los datos en un formato que se pueda utilizar para agre-
gar información a una base de datos interna puede ignorar los elementos adicionales sin ningún problema.
Los atributos de estas clases son los que se encuentran en la pantalla o informe. Los métodos son los que se
requieren para trabajar con la pantalla o para producir el informe.
CLASES ABSTRACTAS Las clases abstractas son clases que no se pueden instanciar en forma directa. Las clases
abstractas están enlazadas a clases concretas en una relación de generalización/especialización (gen/spec). Por lo
general el nombre de una clase abstracta se escribe en cursiva.
CLASES DE CONTROL Las clases de control o activas se utilizan para controlar el flujo de actividades; actúan
como un coordinador a la hora de implementar las clases. Para obtener clases que se puedan reutilizar, un
diagrama de clases puede incluir muchas clases de control pequeñas. A menudo las clases de control se derivan
durante el diseño del sistema.
Es común crear una clase de control sólo para poder reutilizar otra clase. Un ejemplo de ello sería el proceso
de inicio de sesión. Podría haber una clase de control que se encargue de la interfaz de usuario de inicio de sesión,
que contiene la lógica para verificar el ID y la contraseña del usuario. El problema que surge es que la clase de
control del inicio de sesión está diseñada para una pantalla de inicio de sesión específica. Al crear una clase
de control de inicio de sesión que maneje sólo la pantalla de inicio de sesión única, los datos se pueden pasar a
una clase de control de validación más general, la cual verifica los ID y contraseñas de usuario que recibe de mu-
chas otras clases de control que reciben mensajes de interfaces de usuario específicas. Esto incrementa la reutiliza-
ción y aísla los métodos de verificación de inicio de sesión de los métodos para manejar la interfaz de usuario.
Las reglas para crear diagramas de secuencia son que todas las clases de interfaz deben estar conectadas a una
clase de control. De manera similar, todas las clases de entidad deben estar conectadas a una clase de control. Las cla-
ses de interfaz, a diferencia de las otras dos, nunca se conectan de manera directa a las clases de entidad.
www.xlibros.com
300 PARTE III • EL PROCESO DE ANÁLISIS
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 301
de
Clase Clase
de de
m it e o
ad Clase
lí entid rol
in t erfaz co n t
de
Estudiante
proveer
inicioSesionUsuario iniciarSesion() obtenerEstudiante()
regresar creditos
regresar datosCurso
mostrar regresar
paginaWebCurso paginaWebCurso regresar GPA
FIGURA 10.15
Un diagrama de secuencia para usar dos páginas Web: una para la
información del estudiante y la otra para la información del curso.
diante() de nuevo, lo cual implicaría un insatisfactorio tecleo redundante. Cabe mencionar que la clase :Estu-
diante no está involucrada y que el foco de control (la barra vertical conectada a la clase :Estudiante) termina
antes de que empiece el segundo conjunto de actividades (las flechas horizontales que apuntan a la derecha).
La clase :Controlador interfaz ver estudiante envía un mensaje obtenerSeccion() a la clase :Seccion, la
cual devuelve una calificacionSeccion. La clase :Seccion también envía un mensaje calcularGPA() a la clase
:Calcular promedio calificacion, la cual envía un mensaje de vuelta a la clase :Curso. La clase :Curso de-
vuelve los creditos que permiten a la clase :Calcular promedio calificacion determinar el GPA y devolverlo al
:Controlador interfaz ver estudiante.
www.xlibros.com
302 PARTE III • EL PROCESO DE ANÁLISIS
El :Controlador interfaz ver estudiante repite el envío de mensajes a la clase :Seccion hasta que se ha-
yan incluido todas las secciones para el estudiante. En este momento, :Controlador interfaz ver estudiante
envía la paginaWebCurso a la clase :Interfaz usuario ver estudiante, que muestra la información en el
navegador.
Al utilizar las clases de interfaz de usuario, de control y de entidad, el analista puede explorar el diseño y
experimentar con él. El diseño antes mencionado mostraría toda la información personal del estudiante en una
página y la información del curso en una segunda página. El analista puede modificar el diseño de manera que la
información personal del estudiante y la información del curso aparezcan en una página Web. Estos dos posibles
escenarios se revisarían con los usuarios para determinar la mejor opción.
Una de las dificultades para el analista es determinar cómo incluir el numeroEstudiante después de hacer
clic en el botón Siguiente, ya que la clase :Estudiante no está disponible en ese momento. Hay tres formas de
almacenar y retransmitir los datos desde una página Web:
1. Incluir la información en el URL que se muestra en el área de dirección o ubicación del navegador. En este
caso, la línea de la ubicación podría mostrar algo así: http://www.cpu.edu/estudiante/consultestud.
html?numeroEstudiante=12345
Todo lo que va después del signo de interrogación son datos que los métodos de clase pueden utilizar.
Este medio de almacenar los datos es fácil de implementar y se utiliza con frecuencia en los motores de
búsqueda.
Hay varias desventajas en cuanto a usar este método, por lo que el analista debe tener cuidado. La
primera preocupación es la privacidad; cualquiera puede leer la dirección Web. Si la aplicación involucra
información médica, números de tarjeta de crédito, etcétera, ésta no es una buena opción. La mayoría de los
navegadores también muestran los datos de direcciones Web anteriores en sesiones posteriores si el usuario
introduce los primeros caracteres, por lo que la información se puede ver comprometida, dando pie al robo
de identidad. Una segunda desventaja es que por lo general los datos se pierden una vez que el usuario cierra
el navegador.
2. Almacenar la información en una cookie: un pequeño archivo almacenado en la computadora cliente
(navegador). Las cookies constituyen la única forma de almacenar datos para que persistan más allá de
la sesión actual del navegador. Esto permite a la página Web mostrar un mensaje tal como “Bienvenido
de vuelta, Robin. Si no es usted Robin, haga clic aquí”. Por lo general las cookies almacenan números de
cuenta de claves primarias pero no números de tarjetas de crédito u otro tipo de información privada. Las
cookies están limitadas a 20 por dominio (como www.cpu.edu) y cada cookie debe ser de 4,000 caracteres
o menor.
El analista debe trabajar con otras unidades de negocios para determinar quién necesita usar cookies y
debe haber cierto control central sobre los nombres utilizados en las cookies. Si la organización necesita
tener más de 20 cookies, una solución común es crear distintos nombres de dominio utilizados por la
organización, como soporte.cpu.edu o capacitacion.cpu.edu.
3. Use campos ocultos en los formularios Web. Por lo general estos campos contienen datos que envía el
servidor, son invisibles y no ocupan espacio en la página Web. En el ejemplo sobre ver información
del estudiante, la clase :Controlador interfaz ver estudiante agregó un campo oculto que contiene
el numeroEstudiante al formulario paginaWebEstudiante junto con el botonSiguiente. Cuando el
estudiante hace clic en el botonSiguiente, se envía el numeroEstudiante al servidor y el :Controlador
interfaz ver estudiante sabe para cuál estudiante debe obtener la información sobre el curso y la
calificación. Los datos en formularios ocultos no se guardan de una sesión a otra del navegador, por lo que
se mantiene la privacidad.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 303
sin alterar la visualización de la página actual. Esto resulta ser una ventaja debido a que no hay que volver a car-
gar toda la página Web si recibimos datos adicionales del servidor.
Antes de la creación de Ajax, el usuario que visitaba una página Web respondía algunas preguntas mediante
la introducción de datos en un formulario basado en Web y después tenía que esperar hasta que se cargara una
nueva página. Esto era necesario debido a que el código para validar, obtener los datos y después responder al
usuario residía en el servidor. Con la llegada de Ajax, la página Web se actualiza con rapidez debido a que gran
parte del proceso de validación y demás lógica de control se incluye ahora en el código de JavaScript del nave-
gador o del lado del cliente. Esto significa que las reglas de negocios se incluyen tanto en la clase de límite como
en la clase de control, por lo que no es posible tener tres capas.
FIGURA 10.16
:Interfaz de :Controlador Un diagrama de clases para la
usuario ver interfaz ver paginaWebEstudiante que utiliza
estudiante estudiante símbolos de clase especiales.
Estudiante
:Calcular
promedio
calificacion
www.xlibros.com
304 PARTE III • EL PROCESO DE ANÁLISIS
Relaciones
Otra manera de mejorar los diagramas de clases es mostrar las relaciones. Éstas son conexiones entre las clases,
de manera similar a las que se encuentran en un diagrama de entidad-relación. Las relaciones se muestran como
líneas que conectan a las clases en un diagrama de clases. Hay dos categorías de relaciones: asociaciones y rela-
ciones entre un todo y sus partes.
ASOCIACIONES El tipo más simple de relación es una asociación, o conexión estructural entre clases u objetos.
Las asociaciones se muestran como una simple línea en un diagrama de clases. Los puntos finales de la línea se
etiquetan con un símbolo que indica la multiplicidad, que es lo mismo que la cardinalidad en un diagrama de
entidad-relación. Un cero representa ninguno, un uno representa uno y sólo uno; un asterisco representa muchos.
La notación 0..1 representa de cero a uno y la notación 1..* representa de uno a muchos. En la figura 10.17 se
muestran las asociaciones.
Estudiante Curso
–numeroEstudiante –numeroCurso
–creditosCompletados 1 1.. –descripcionCurso
–calificacionPromedio –numeroDeCreditos
–departamento se inscribe en –numeroDepartamento
–especialidad +agregarCurso()
+inicializar() +cambiarCurso()
+verEstudiante() +buscarCurso()
+cambiarEstudiante()
+graduarEstudiante()
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 305
Los diagramas de clases no restringen el límite inferior para una asociación. Por ejemplo, una asocia-
ción podría ser 5..*, lo cual indica que debe haber un mínimo de 5 presentes. Lo mismo se aplica para los
límites superiores. Por ejemplo, el número de cursos en los que está inscrito actualmente un estudiante po-
dría ser 1..10, lo cual representa de 1 a 10 cursos. También se puede incluir un rango de valores separados
por comas, como 2, 3, 4. En el modelo de UML, las asociaciones por lo general se etiquetan con un nombre
descriptivo.
Las clases de asociaciones son aquellas que se utilizan para descomponer una asociación de muchos a mu-
chos entre las clases. Son similares a las entidades asociativas en un diagrama de entidad-relación. Estudiante y
Curso tienen una relación de muchos a muchos; para resolver esta relación se agrega una clase de asociación lla-
mada Seccion entre las clases de Estudiante y Curso. La figura 10.18 muestra una clase de asociación llamada
Seccion con una línea punteada conectada a la línea de la relación de muchos a muchos.
Un objeto en una clase puede tener una relación con otros objetos en la misma clase; a esto se le denomina
asociación reflexiva. Un ejemplo sería una tarea que tenga una tarea precedente, o un empleado que supervisa a
otro empleado. Esto se muestra como una línea de asociación que conecta a la clase consigo misma, con etique-
tas que indican los nombres de los roles, como tarea y tarea precedente.
RELACIONES ENTRE UN TODO Y SUS PARTES Estas relaciones se dan cuando una clase representa al objeto como
un todo y otras clases representan partes de ese objeto. El todo actúa como un contenedor para las partes. Para
mostrar estas relaciones en un diagrama de clases se utiliza una línea con un diamante en un extremo. El diamante
está conectado al objeto que es el todo. Las relaciones entre un todo y sus partes (así como la agregación, que
veremos más adelante) se muestran en la figura 10.19.
Una relación entre un todo y sus partes puede ser un objeto entidad que tenga partes distintas, como un sis-
tema computarizado que incluye computadora, impresora, pantalla, etc., o un automóvil que tiene un motor, sistema
de frenos, transmisión, etc. También es posible usar relaciones entre un todo y sus partes para describir una in-
terfaz de usuario en la que una pantalla de GUI contiene una serie de objetos como listas, cuadros o botones de
opción, o tal vez un encabezado, cuerpo y área del pie. Las relaciones entre un todo y sus partes tienen tres cate-
gorías: agregación, colección y composición.
Agregación Una agregación se describe comúnmente como una relación “tiene un”. La agregación provee el
medio para mostrar que todo el objeto está compuesto de la suma de sus partes (otros objetos). En el ejemplo
de inscripción de estudiantes, el departamento tiene un curso y el curso es para un departamento. Ésta es una
relación más débil, ya que tal vez el departamento cambie o se elimine y el curso puede seguir existiendo. Un
paquete de computadora tal vez ya no esté disponible, pero las impresoras y los demás componentes siguen
existiendo. El diamante al final de la línea de la relación no está relleno.
Colección Una colección consiste de un todo y sus miembros. Éste puede ser un distrito de votación con votantes
o una biblioteca con libros. Los votantes o libros pueden cambiar, pero el todo retiene su identidad. Ésta es una
asociación débil.
www.xlibros.com
306 PARTE III • EL PROCESO DE ANÁLISIS
Actividad de recaudación
de fondos
–numeroActividad
–descripcionActividad
–tipoActividad
–montoGastado
–montoRecibido
–fechaCompletada
+cambiar()
+nuevo()
+registrarMonto()
Composición La composición es una relación entre un todo y sus partes, donde el todo tiene una responsabilidad
por cada parte. Es una relación más fuerte y por lo general se muestra con un diamante relleno. Las palabras
clave para la composición son una clase “siempre contiene” a otra clase. Si el todo se elimina, todas las partes se
eliminan. Un ejemplo sería una política de seguros con cláusulas adicionales. Si se cancela la póliza también
se cancelan las cláusulas adicionales del seguro. En una base de datos se establecería la integridad referencial
para eliminar los registros hijos en cascada. En una universidad hay una relación de composición entre un
curso y una asignación, así como entre un curso y un examen. Si se elimina el curso se eliminan también las
asignaciones y los exámenes.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 307
puedeserun puedeserun
esun esun
Estudiante Empleado
–numeroEstudiante –numeroEmpleado
–creditosCompletados –salario
–calificacionPromedio –AAFBruto
–departamento –AAFRetencion
–especialidad –fechaContratacion
–esmenor –departamento
+cambiarEstudiante() +cambiarEmpleado()
+buscarEstudiante() +imprimirInformacionImpuestos()
+graduarEstudiante() +producirChequeNomina()
+inicializar()
+estudianteCompleto()
puedeserun puedeserun
+verEstudiante()
esun esuntipode
Docente Administrador
–titulo –titulo
–puesto +cambiarEmpleado()
–urlWeb
+cambiarPosicion()
+cambiarURL()
www.xlibros.com
308 PARTE III • EL PROCESO DE ANÁLISIS
unen mediante una flecha que apunta a la superclase, pero también se podrían mostrar como flechas separadas.
Observe que el nivel superior es Persona, la clase que representa a cualquier persona. Los atributos describen
cualidades que poseen todas las personas en la universidad. Los métodos permiten a la clase cambiar el nom-
bre y la dirección (incluyendo el teléfono y la dirección de correo electrónico). Ésta es una clase abstracta, sin
instancias.
Estudiante y Empleado son subclases ya que tienen distintos atributos y métodos. Un empleado no tiene una
calificación promedio y un estudiante no tiene un salario. Ésta es una versión simple y no incluye a los emplea-
dos que son estudiantes ni a los estudiantes que trabajan para la universidad. Si se agregaran, serían subclases de
las clases Empleado y Estudiante. Empleado tiene dos subclases, Docente y Administrador, ya que hay dis-
tintos atributos y métodos para cada una de estas clases especializadas.
Las subclases cuentan con verbos especiales para definirlas. A menudo son palabras seguidas, como esun
para “es un”, esuntipode para “es un tipo de” y puedeserun para “puede ser un”. No hay distinción entre “es un”
y “es una”; ambas utilizan esun.
IDENTIFICAR CLASES ABSTRACTAS Tal vez pueda identificar las clases abstractas si encuentra varias clases o
tablas de base de datos que tengan los mismos elementos, o si varias clases tienen los mismos métodos. Podemos
crear una clase general al extraer los atributos y métodos comunes, o podríamos crear una clase especializada
para los atributos y métodos únicos. Si usamos un ejemplo bancario como un retiro, un pago sobre un préstamo o
la escritura de un cheque, todos tendrán el mismo método: restar dinero del saldo del cliente.
BUSCAR CLASES Hay varias formas de determinar las clases. Se pueden descubrir durante las sesiones de
entrevista o JAD (que vimos en el capítulo 4), durante las sesiones facilitadas del equipo o a partir de las
sesiones de lluvia de ideas. Al analizar documentos y memos también se pueden revelar clases. Una de
las formas más sencillas es usar el método CRC que vimos antes en este capítulo. El analista también debe
examinar los casos de uso en busca de sustantivos. Cada sustantivo puede generar un candidato a una clase
potencial. Se les llama clases candidatas debido a que algunos de los sustantivos pueden ser atributos de una
clase.
Cada clase debe existir para un objeto distinto que tenga una definición clara. Pregúntese qué conoce la
clase, los atributos; y qué es lo que la clase sabe cómo hacer, los métodos. Identifique las relaciones entre clases
y la multiplicidad para cada extremo de la relación. Si la relación es de muchos a muchos, cree una clase de in-
tersección o asociativa, similar a la entidad asociativa en un diagrama de entidad-relación.
DETERMINAR LOS MÉTODOS DE LAS CLASES El analista debe determinar los atributos y métodos de las clases.
Los atributos son fáciles de identificar, pero los métodos que trabajan con los atributos pueden ser más difíciles
de identificar. Algunos de los métodos son estándar y siempre están asociados con una clase, como new(), o el
método <<crear>>, que es una extensión para el UML creada por una persona u organización, a lo cual se le
conoce como estereotipo. Los símbolos << y >> no son simplemente pares de símbolos mayor que y menor que,
sino que se les conoce como paréntesis angulares.
Otra manera útil de determinar los métodos es examinar una matriz CRUD (vea el capítulo 7). La figura
10.21 muestra una matriz CRUD para los ofrecimientos de cursos. Cada letra requiere un método distinto. Si
hay una C para crear, se agrega un método new(). Si hay una U para actualizar, se agrega un método actualizar()
o cambiar(). Si hay una D para eliminar, se agrega un método eliminar() o quitar(). Si hay una R para leer, se
agregan métodos para buscar, ver o imprimir. En el ejemplo mostrado, la clase librotexto necesitaría un método
crear para agregar un libro de texto y un método leer para iniciar una consulta sobre un curso, cambiar un libro
de texto o buscar un libro de texto. Si se reemplazara un libro de texto se necesitaría un método actualizar, y si se
quitara un libro de texto se requeriría un método eliminar.
MENSAJES Para poder lograr un trabajo útil, la mayoría de las clases necesitan comunicarse entre sí. La
información se puede enviar mediante un objeto en una clase a un objeto en otra clase a través de un mensaje,
en forma similar a una llamada en un lenguaje de programación tradicional. Un mensaje también actúa como
comando para indicar a la clase receptora que haga algo. Un mensaje consiste en el nombre del método en la
clase receptora, así como los atributos (parámetros o argumentos) que se pasan con el nombre del método. La clase
receptora debe tener un método que corresponda al nombre del mensaje.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 309
FIGURA 10.21
Actividad Departamento Curso Librotexto Asignacion Examen
Se puede usar una matriz CRUD
Agregar departamento C para ayudar a determinar qué
métodos se necesitan. Esta matriz
Ver departamento R CRUD se utiliza para determinar
los métodos y las operaciones
Agregar curso R C para los ofrecimientos de cursos.
Cambiar curso R U
Consulta de curso R R R R R
Agregar asignación R C
Cambiar asignación R RU
Cambiar asignación R R
Ver asignación R R
Agregar examen R RU
Cambiar examen R R
Como los mensajes se envían de una clase a otra, se pueden considerar como entrada o salida. La primera
clase debe proveer los parámetros incluidos con el mensaje y la segunda clase utiliza esos parámetros. Si existe
un diagrama de flujo de datos hijo físico para el dominio del problema, puede ser útil para descubrir métodos. El
flujo de datos de un proceso primitivo a otro representa el mensaje y hay que examinar los procesos primitivos
como candidatos a métodos.
DIAGRAMAS DE ESTADOS
El diagrama de estados, o de transiciones de estado, es otra herramienta para determinar los métodos de las cla-
ses. Se utiliza para examinar los distintos estados que puede tener un objeto.
Se crea un diagrama de estados para una sola clase. Por lo general los objetos se crean, pasan por cambios y
se eliminan o quitan.
Los objetos existen en estos diversos estados, que son las condiciones de un objeto en un momento especí-
fico. Los valores del atributo de un objeto definen el estado en que se encuentra el objeto y algunas veces hay
un atributo tal como Estado del pedido (pendiente, en recolección, empaquetado, enviado, recibido, etcétera) que
indica el estado. Un estado tiene un nombre en el que cada palabra empieza con mayúscula. El nombre debe ser
único y descriptivo. Un estado también tiene acciones de entrada y de salida: las cosas que el objeto debe hacer
cada vez que entra o sale de un estado específico.
Un evento es algo que ocurre en un tiempo y lugar específicos. Los eventos provocan un cambio del
estado del objeto y se dice que una transición se “dispara”. Los estados separan eventos, como un pedido
que espera a ser llenado, y los eventos separan estados, como un evento Pedido recibido o un evento Pedido
completo.
Un evento produce la transición y ocurre cuando se cumple una condición de guardia. Esta condición de
guardia es algo que se evalúa como verdadero o falso y puede ser tan simple como “Hacer clic para confirmar el
pedido”. También puede ser una condición que ocurra en un método, como un elemento que esté agotado. Las
condiciones de guardia se muestran entre corchetes a un lado de la etiqueta del evento.
www.xlibros.com
310 PARTE III • EL PROCESO DE ANÁLISIS
Además hay eventos diferidos, o eventos que se retienen hasta que un objeto cambia a un estado que pueda
aceptarlos. Un usuario que teclea algo cuando un procesador de palabras realiza un respaldo sincronizado es un ejem-
plo de un evento diferido. Una vez que se completa el respaldo sincronizado, el texto aparece en el documento.
Los eventos se clasifican en tres categorías distintas:
1. Señales o mensajes asíncronos, que ocurren cuando el programa que hace la llamada no espera un mensaje
de retorno, como una característica que se opera desde un menú.
2. Mensajes sincrónicos, que son llamadas a funciones o subrutinas. El objeto que hace la llamada se detiene y
espera a que se le regrese el control, junto con un mensaje opcional.
3. Eventos temporales, que ocurren en un tiempo predeterminado. Por lo general no involucran a un actor o a
un evento externo.
Los objetos materiales tienen persistencia; es decir, existen durante un extenso periodo de tiempo. Los
vuelos de aviones, conciertos y eventos deportivos tienen una persistencia más corta (pueden tener estados que
cambian en un tiempo más corto). Algunos objetos, conocidos como objetos transitorios, no sobreviven al final
de una sesión. Éstos incluyen la memoria principal, los datos de una URL (o ubicación) Web, las páginas Web,
pantallas CICS, etcétera. La única forma de guardar los objetos transitorios es almacenar la información sobre
ellos, como cuando se guardan los datos Web en una cookie.
Cada vez que un objeto cambia de estado, algunos de los atributos cambian sus valores. Además, cada vez
que cambian los atributos de un objeto, debe haber un método para cambiar esos atributos. Cada uno de los mé-
todos necesitaría una pantalla o formulario Web para agregar o modificar los atributos. Éstos se convierten en
los objetos de interfaz. Comúnmente la pantalla o formulario Web contiene más controles (o campos) que los
atributos que cambian. Por lo general tienen claves primarias, información de identificación (como un nombre o
dirección) y otros atributos necesarios para una buena interfaz de usuario. La excepción es un evento temporal,
que puede usar tablas de la base de datos o una cola para contener la información.
Los otros estados son Estudiante Programa, Estudiante Actual, Estudiante Continuo y Estudiante Gra-
duado. A cada estado hay que asociar un evento, métodos, atributos modificados y una interfaz de usuario. Po-
demos usar esta serie de estados para determinar los atributos y métodos que forman parte de la clase.
Los estados y eventos que desencadenan los cambios se pueden representar en un diagrama de estados (o en
un diagrama de transiciones de estado). En la figura 10.22 se muestra el diagrama de estados para Estudiante.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 311
Dormitorio
Asignado
Estudiante
se seleccionó
el programa
Estudiante Estudiante
Actual se inscribió el Programa
estudiante en la
clase
el estudiante se completó el
se inscribió curso con
en la clase éxito
Estudiante Estudiante
Continuo se completaron los Graduado
requerimientos de
graduación
se graduó
el estudiante
Los estados se representan mediante rectángulos y los eventos o actividades son las flechas que enlazan los es-
tados y hacen que un estado cambie a otro estado. Los eventos de transición se nombran en pasado, porque ya
ocurrieron para crear la transición.
No hay que crear diagramas de estados para todas las clases. Se crean cuando:
1. Una clase tiene un ciclo de vida complejo.
2. Una instancia de una clase puede actualizar sus atributos en varias formas durante el ciclo de vida.
3. Una clase tiene un ciclo de vida operacional.
4. Dos clases dependen una de la otra.
5. El comportamiento actual del objeto depende de lo que ocurrió antes.
Al examinar un diagrama de estados, aproveche la oportunidad para buscar errores y excepciones. Inspec-
cione el diagrama para detectar si los eventos ocurren en un tiempo inadecuado. Verifique también que se hayan
representado todos los eventos y estados. En los diagramas de estados sólo hay que evitar dos problemas: verifi-
que que no entren todas las transiciones en un estado o que salgan todas de éste.
Cada estado debe tener por lo menos una transición de entrada y de salida. Algunos diagramas de es-
tados usan los mismos símbolos de inicio y terminación que los que utiliza un diagrama de actividad: un
círculo relleno para representar el inicio y círculos concéntricos con el centro relleno para indicar el fin del
diagrama.
www.xlibros.com
312 PARTE III • EL PROCESO DE ANÁLISIS
FIGURA 10.23
Los casos de uso se pueden
agrupar en paquetes.
Estudiante
Oficina financiera
Estudiante
Agregar Inscribirse
estudiante en clase
Departamento
Docente
Estudiante
Agregar
docente
Ver información
de docente
Asignar docente
a curso
Miembro del cuerpo Administración
docente
tes físicos del sistema, o paquetes de casos de uso que contienen un grupo de casos de uso. Los paquetes usan un
símbolo de carpeta con el nombre del paquete en la ficha de la carpeta o centrado en la misma. El empaqueta-
miento puede ocurrir durante el análisis del sistema o en una etapa posterior de diseño del sistema. Los paquetes
también pueden tener relaciones de manera similar a los diagramas de clases, que pueden incluir asociaciones y
herencia.
La figura 10.23 es un ejemplo de un diagrama de paquetes de casos de uso. Muestra que cuatro casos de uso,
Agregar estudiante, Inscribirse en clase, Transferir créditos y Ver información de estudiante son parte del
paquete Estudiante. Hay tres casos de uso, Agregar docente, Ver información de docente y Asignar docente
a curso que forman parte del paquete Docente.
A medida que continúe construyendo diagramas le será conveniente utilizar los diagramas de componentes,
los diagramas de despliegue y las cosas de anotaciones. Éstos permiten distinta perspectivas sobre el trabajo a
realizar.
El diagrama de componentes es similar a un diagrama de clases, sólo que es más como una vista superficial
de la arquitectura del sistema. El diagrama de componentes muestra los componentes del sistema, como un ar-
chivo de clase, un paquete, las bibliotecas compartidas, una base de datos, etcétera, y la forma en que se relacio-
nan entre sí. Los componentes individuales en un diagrama de componentes se consideran con más detalle dentro
de otros diagramas de UML, como los diagramas de clases y los diagramas de casos de uso.
El diagrama de despliegue ilustra la implementación física del sistema, incluyendo el hardware, las relacio-
nes entre el hardware y el sistema en el que se va a desplegar. El diagrama de despliegue puede mostrar los ser-
vidores, estaciones de trabajo, impresoras, etcétera.
Las cosas de anotaciones proveen a los desarrolladores más información sobre el sistema. Estas cosas con-
sisten en notas que se pueden unir a cualquier cosa en UML: objetos, comportamientos, relaciones, diagramas
o cualquier cosa que requiera descripciones detalladas, suposiciones o cualquier información relevante para el
diseño y la funcionalidad del sistema. El éxito del UML depende de la documentación completa y precisa de
nuestro modelo del sistema para proveer toda la información que sea posible al equipo de desarrollo. Las notas
proveen una fuente de conocimiento y comprensión común sobre su sistema para ayudar a que sus desarrollado-
res estén coordinados. Las notas se muestran como un símbolo de un papel con una esquina doblada y una línea
que las conecta con el área que necesita más detalles.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 313
O P O R T U N I D A D D E C O N S U LT O R Í A 1 0 . 3
www.xlibros.com
314 PARTE III • EL PROCESO DE ANÁLISIS
casos de uso y en un modelo de objetos. El modelo de casos de uso describe los casos de uso y los actores. El
modelo de objetos describe los objetos y sus asociaciones, además de las responsabilidades, colaboradores y
atributos de los objetos.
1. Defina el modelo de casos de uso.
• Busque los actores en el dominio del problema; revise los requerimientos del sistema y entreviste algunos
expertos de negocios.
• Identifique los eventos principales iniciados por los actores y desarrolle un conjunto de casos de uso
primarios en un nivel muy alto, que describan los eventos desde la perspectiva de cada actor.
• Desarrolle los diagramas de casos de uso para comprender cómo se relacionan los actores con los casos
de uso que definirán el sistema.
• Refine los casos de uso primarios para desarrollar una descripción detallada de la funcionalidad del
sistema para cada caso de uso primario. Provea detalles adicionales al desarrollar los escenarios de casos
de uso que documenten los flujos alternos de los casos de uso primarios.
• Revise los escenarios de casos de uso con los expertos del área de negocios para verificar los procesos e
interacciones. Haga las modificaciones necesarias hasta que los expertos del área de negocios estén de
acuerdo en que los escenarios de los casos de uso son completos y precisos.
2. Continúe con la creación de diagramas de UML para modelar el sistema durante la fase de análisis de
sistemas.
• Derive los diagramas de actividad a partir de los diagramas de casos de uso.
• Desarrolle los diagramas de secuencia y de comunicación a partir de los escenarios de los casos de uso.
• Revise los diagramas de secuencia con los expertos del área de negocios para verificar los procesos y las
interacciones. Haga las modificaciones necesarias hasta que los expertos del área de negocios estén de
acuerdo en que los diagramas de secuencia son completos y precisos. Con frecuencia, la revisión
adicional de los diagramas de secuencia gráficos provee a los expertos del área de negocios la
oportunidad de reconsiderar y refinar los procesos con un detalle más atómico que la revisión de los
escenarios de los casos de uso.
3. Desarrolle los diagramas de clases.
• Busque los sustantivos en los casos de uso y haga una lista. Son objetos potenciales. Una vez que
identifique los objetos, busque similitudes y diferencias en los objetos debido a sus estados o
comportamiento y después cree las clases.
• Defina las principales relaciones entre las clases. Busque las relaciones “tiene un” y “es un” entre las
clases.
• Examine los diagramas de casos de uso y de secuencias para poder determinar las clases.
• Empezando con los casos de uso que son los más importantes para el diseño del sistema, cree los
diagramas de clases que muestren las clases y relaciones que existen en los casos de uso. Un diagrama de
clases puede representar a las clases y relaciones descritas en varios casos de uso relacionados.
4. Dibuje diagramas de estados.
• Desarrolle diagramas de estados para ciertos diagramas de clase, de manera que pueda proveer un análisis
más detallado del sistema en este punto. Use los diagramas de estados como ayuda para comprender los
procesos complejos que no se puedan derivar por completo de los diagramas de secuencia.
• Determine los métodos al examinar los diagramas de estados. Derive los atributos de las clases de los
estados (datos) a partir de los casos de uso, expertos de las áreas de negocios y métodos de las clases.
Indique si los métodos y atributos de la clase son públicos (acceso externo) o privados (acceso interno
para la clase). Los diagramas de estados son en extremo útiles para modificar los diagramas de clases.
5. Empiece el diseño de sistemas; refine los diagramas de UML y utilícelos para derivar las clases y sus
atributos y métodos.
• Revise todos los diagramas de UML existentes para el sistema. Escriba especificaciones de clases para
cada clase que incluyan los atributos, métodos y descripciones de la clase. Revise los diagramas de
secuencia para identificar otros métodos de clases.
• Desarrolle especificaciones de métodos que muestren con detalle los requerimientos de entrada y de
salida para el método, junto con una descripción detallada del procesamiento interno del método.
• Cree otro conjunto de diagramas de secuencia (si es necesario) para reflejar los métodos reales de las
clases, además las interacciones entre las clases y las interfaces del sistema.
• Cree diagramas de clases mediante los símbolos de clase especializados para la clase de límite o de
interfaz, la clase de entidad y la clase de control.
• Analice los diagramas de clases para derivar los componentes del sistema; es decir, clases relacionadas en
función y lógica que se compilarán y desplegarán en conjunto como un archivo .DLL, .COM, un objeto,
un Java Bean, un paquete, etcétera.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 315
O P O R T U N I D A D D E C O N S U LT O R Í A 1 0 . 4
C-Shore⫹⫹
• Desarrolle diagramas de despliegue para indicar cómo se desplegarán los componentes de su sistema en
el entorno de producción.
6. Documente el diseño de su sistema en forma detallada. Este paso es imprescindible. Entre más completa sea
la información que provea al equipo de desarrollo por medio de la documentación y los diagramas de UML,
más rápido será el desarrollo y más sólido será el sistema de producción final.
www.xlibros.com
316 PARTE III • EL PROCESO DE ANÁLISIS
Cuando esté completo su proceso de análisis y diseño, deberá tener un conjunto preciso y detallado de es-
pecificaciones para clases, escenarios, actividades y secuencias en el sistema. En general, podemos relacionar la
minuciosidad del análisis y diseño de un sistema con la cantidad de tiempo requerido para desarrollar el sistema
y la calidad resultante del producto entregado.
Lo que se pasa por alto con frecuencia en el desarrollo de un nuevo sistema es que entre más progrese un
proyecto, más costosas serán las modificaciones en los requerimientos de negocios de un sistema. Es mucho
más fácil, rápido y mucho menos costoso modificar el diseño de un sistema mediante el uso de una herramienta
CASE, o incluso en papel, durante las fases de análisis y diseño de un proyecto, que hacerlo durante la fase de
desarrollo.
Por desgracia algunos empleadores tienen poca visión y creen que sólo cuando un programador o analista
está codificando es cuando realmente está trabajando. Algunos empleadores asumen equivocadamente que la
productividad del programador se puede juzgar tan sólo con base en la cantidad de código producido, sin recono-
cer que la creación de diagramas ahorra en última instancia tiempo y dinero que de otra manera se desperdiciaría
si se hiciera un prototipo del proyecto sin una planificación apropiada.
En esta situación se adapta muy bien la analogía para la construcción de una casa. Aunque contratamos un
constructor para ello, no vamos a querer vivir en una estructura construida sin planeación, una en la que los cuar-
tos y características se agreguen al azar sin relación con la función o con el costo. Queremos que un constructor
construya el diseño que acordamos a partir de los planos de construcción, con las especificaciones que revisaron
con cuidado todas las partes involucradas. Como un miembro de un equipo de análisis dijo con tanta certeza:
“Poner un proyecto en papel antes de codificarlo reducirá su costo a la larga. Es mucho más económico borrar un
diagrama que modificar la codificación”.
Cuando cambian los requerimientos de negocios durante la fase de análisis, a veces es necesario volver a
dibujar algunos diagramas de UML. Pero si los requerimientos de negocios cambian durante la fase de desarro-
llo, tal vez se requiera una cantidad considerable de tiempo y dinero para rediseñar, recodificar y reevaluar el
sistema. Al confirmar su análisis y diseño en papel (en especial mediante el uso de diagramas de UML) con los
usuarios que son expertos en el área de negocios, usted ayudará a asegurar que se cumpla con los requerimientos
de negocios correctos cuando el sistema esté completo.
RESUMEN
Los sistemas orientados a objetos describen las entidades como Los principales componentes del UML son cosas, relacio-
objetos. Los objetos forman parte de un concepto general co- nes y diagramas. Los diagramas están relacionados entre sí. Las
nocido como clases, la unidad principal de análisis en el análi- cosas estructurales son más comunes; incluyen clases, interfa-
sis y diseño orientados a objetos. Cuando se introdujo por ces, casos de uso y muchos otros elementos que proveen la forma
primera vez la metodología orientada a objetos, los defensores de crear modelos. Las cosas estructurales permiten al usuario
citaron la reutilización de los objetos como el principal benefi- describir relaciones. Las cosas de comportamiento describen la
cio de su metodología. Aunque la reutilización es el principal forma en que trabajan las cosas. Las cosas de agrupamiento se
objetivo, también es muy importante el mantenimiento de los utilizan para definir límites. Las cosas de anotaciones permiten
sistemas. al analista agregar notas a los diagramas.
Los analistas pueden usar tarjetas CRC para empezar el Las relaciones son el pegamento que mantiene todo unido.
proceso de modelado de objetos de una manera informal. Se Las relaciones estructurales se utilizan para enlazar las cosas en
puede agregar el Pensamiento en objetos a las tarjetas CRC para los diagramas estructurales. Las relaciones estructurales inclu-
ayudar al analista a refinar las responsabilidades en tareas cada yen dependencias, agregaciones, asociaciones y generalizacio-
vez más pequeñas. Se pueden realizar sesiones CRC con un nes. Los diagramas de comportamiento utilizan los cuatro tipos
grupo de analistas para determinar las clases y responsabilidades básicos de relaciones de comportamiento: comunica, incluye,
en forma interactiva. extiende y generaliza.
El lenguaje unificado de modelado (UML) provee un con- El conjunto de herramientas de UML está compuesto de
junto estandarizado de herramientas para documentar el análi- diagramas de UML. Aquí se incluyen los diagramas de casos de uso,
sis y diseño de un sistema de software. El UML se basa diagramas de actividad, diagramas de secuencia, diagramas de
fundamentalmente en una técnica orientada a objetos conocida comunicación, diagramas de clases y diagramas de estados.
como modelado de casos. Un modelo de casos de uso describe Además de los diagramas, los analistas pueden describir un caso
qué hace el sistema sin describir cómo lo hace. Un modelo de de uso mediante un escenario de casos de uso.
casos de uso particiona la funcionalidad del sistema en com- Mediante el uso de UML de manera iterativa en el análisis
portamientos (llamados casos de uso) que son importantes para y el diseño podemos lograr una mejor comprensión entre el
los usuarios del sistema (llamados actores). Se crean distintos equipo de negocios y el equipo de TI en relación con los reque-
escenarios para cada conjunto diferente de condiciones de un rimientos del sistema y los procesos que necesitan ocurrir en el
caso de uso. sistema para cumplir con esos requerimientos.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 317
EXPERIENCIA DE HYPERCASE® 10
FIGURA 10.HC1
Encontrará los diagramas de
secuencia en HyperCase.
www.xlibros.com
318 PARTE III • EL PROCESO DE ANÁLISIS
PREGUNTAS DE REPASO
1. Liste dos razones de utilizar una metodología orientada a objetos para el desarrollo de sistemas.
2. Describa la diferencia entre una clase y un objeto.
3. Explique el concepto de herencia en los sistemas orientados a objetos.
4. ¿Qué significa CRC?
5. Describa lo que agrega el Pensamiento en objetos a la tarjeta CRC.
6. ¿Qué es UML?
7. ¿Cuáles son los tres elementos principales del UML?
8. Haga una lista de lo que incluye el concepto de cosas estructurales.
9. Haga una lista de lo que incluye el concepto de cosas de comportamiento.
10. ¿Cuáles son los dos tipos principales de diagramas en UML?
11. Haga una lista de los diagramas que se incluyen en los diagramas estructurales.
12. Haga una lista de los diagramas que se incluyen en los diagramas de comportamiento.
13. ¿Qué es lo que describe un modelo de casos de uso?
14. ¿Describiría un modelo de casos de uso como un modelo lógico o físico del sistema? Defienda su respuesta en un
párrafo.
15. Defina qué es un actor en un diagrama de casos de uso.
16. ¿Cuáles son las tres cosas que un caso de uso siempre debe describir?
17. ¿Qué es lo que describe un diagrama de actividad?
18. Escriba un párrafo que describa el uso de los carriles en los diagramas de actividad.
19. ¿Qué se puede describir en un diagrama de secuencia o de comunicación?
20. ¿Por qué definir clases es una tarea tan importante del análisis orientado a objetos?
21. ¿Qué se puede mostrar en un diagrama de clases?
22. Defina la sobrecarga de métodos.
23. Mencione las cuatro categorías en las que se clasifican las clases.
24. ¿Cuáles son los pasos para crear un diagrama de secuencia?
25. ¿Cuáles son las dos categorías de relaciones entre clases?
26. ¿Para qué se utilizan los diagramas de generalización/especialización (gen/spec)?
27. ¿Cuál es otro término para el polimorfismo?
28. ¿Qué se describe mediante un diagrama de estados?
29. ¿Qué es un paquete en la metodología del UML?
30. ¿Por qué es importante usar el UML para el modelado?
PROBLEMAS
1. Cree una serie de tarjetas CRC para la División de catálogos de World’s Trend. Una vez colocado un pedido, el equipo
de abastecimiento de pedidos se hace cargo y revisa la disponibilidad, abastece el pedido y calcula el monto total del
mismo. Use cinco tarjetas CRC, una para cada una de las siguientes clases: pedido, abastecimiento de pedido, inventario,
producto y cliente. Complete la sección sobre clases, responsabilidades y colaboradores.
2. Termine las tarjetas CRC del problema 1; cree enunciados de Pensamiento en objetos y nombres de propiedades para
cada una de las cinco clases.
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 319
BIBLIOGRAFÍA SELECCIONADA
Beck, K. y W. Cunningham. “Laboratory for Teaching Object-Oriented Thinking”, OOPSLA’89, según lo citado en D. Butler,
CRC Card Session Tutorial. www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/tutorial.html. Último acceso en 29 de
julio de 2009.
Bellin, D. y S. Suchman Simone. The CRC Card Book. Indianápolis: Addison-Wesley Professional, 1997.
Booch, G., I. Jacobson y J. Rumbaugh. The Unified Modeling Language User Guide, 2ª. Edición. Indianápolis: Addison-
Wesley Professional, 2005.
Cockburn, A. Writing Effective Use Cases. Boston: Addison-Wesley Publishing Co., 2001.
Dobing, B. y J. Parsons. “How UML Is Used”. Communications of the ACM, Vol. 49, Núm. 5, mayo de 2006, pp. 109-113.
Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3ª. Edición. Indianápolis: Addison-
Wesley Professional, 2003.
Kulak, D. y E. Guiney. Use Cases: Requirements in Context, 2ª. Edición. Indianápolis: Addison-Wesley Professional, 2004.
Miles, R. y K. Hamilton. Learning UML 2.0. Indianápolis: O’Reilly Media, Inc., 2006.
Sahraoudi, A. E. K. y T. Blum. “Using Object-Oriented Methods in a System Lifecycle Process Model”. ACM SIGSOFT Soft-
ware Engineering Notes, Vol. 28, Núm. 2 (marzo de 2003).
www.xlibros.com
320 PARTE III • EL PROCESO DE ANÁLISIS
EPISODIO 10
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 321
Se transmitió formulario
Sistema de Validar inicio
inicio de sesión de sesión
Sin cambios
Actualización exitosa
FIGURA E10.1
Diagrama de actividad ACTUALIZAR
IMAGEN DE LABORATORIO
www.xlibros.com
322 PARTE III • EL PROCESO DE ANÁLISIS
una lista de los títulos que coincidan. La página Web crearía un bloque rectangular flotante en la parte superior de la página Web
con una lista de los vínculos a los títulos de software y los campos ocultos almacenados con el vínculo. El usuario haría clic en
un título para agregarlo a la imagen. Después podría agregar otro título de software si fuera necesario. Ésta es la actividad SE-
LECCIONAR NUEVO SOFTWARE que envía las primeras tres letras al estado BUSCAR SOFTWARE QUE COINCIDA del
servidor Web. ACTUALIZAR LISTA DE SOFTWARE crea el bloque flotante de títulos”.
“¡Excelente idea!”, exclama Chip.
“Al terminar de agregar software, revisar el software que se va a quitar y cambiar los números de las versiones, hacen clic
en el botón enviar y la tabla de la base de datos de imágenes del laboratorio se actualiza con los cambios”, dice Anna. “El
estado SOLICITAR CAMBIOS EN IMAGEN envía los cambios al estado ACTUALIZAR IMAGEN SOFTWARE LABORA-
TORIO”.
“Esto es divertido”, sonríe Chip. “Voy a trabajar en un diagrama de secuencia para el prototipo ACTUALIZAR IMAGEN
LABORATORIO (que se muestra en la figura E10.2). Chip empieza por enviar la solicitud para la página Web Actualizar la-
boratorio. El servidor envía el mensaje obtenerCampus() a la clase CAMPUS, la cual devuelve la listaCampus incluyendo un
codigoCampus y una descripcionCampus. El controlador envía un mensaje a la clase SALA DE CAMPUS para obtener salas
que contengan software de laboratorio, las cuales se devuelven al CONTROLADOR ACTUALIZAR IMAGEN LABORATO-
RIO COMPUTADORAS. La clase controladora crea el documento de XML listaSalas y lo envía al navegador Web, el cual crea
la lista de selección Edificio de campus. Al cambiar la lista de Edificios del campus, el navegador Web utiliza el mismo docu-
mento de XML para cambiar la lista desplegable Número de sala, de manera que sólo incluya las salas de laboratorio en el
edificio del campus seleccionado.
Cuando se modifica la lista desplegable Número de sala, se envía una solicitud obtenerSoftwareSala() a la clase controla-
dora, que a su vez envía un mensaje obtenerSoftwareImagen() a la clase IMAGEN SOFTWARE. Mediante el uso del número
de sala se obtiene el software y se devuelve en la listaSoftware. LA clase controladora utiliza la listaSoftware para crear el XML
que se envía a la clase de interfaz ACTUALIZAR IMAGEN LABORATORIO COMPUTADORAS, que actualiza la página
Web con los títulos de software.
Cuando se introduce un título parcial de software, se envía una solicitud seleccionarSoftware() al CONTROLADOR
ACTUALIZAR IMAGEN LABORATORIO COMPUTADORAS, el cual envía un mensaje buscarSoftware() a la clase de
FIGURA E10.2
Diagrama de secuencia ACTUALIZAR
IMAGEN DE LABORATORIO.
:Actualizar :Controlador
imagen actualizar imagen :Sala de :Imagen de
laboratorio :Campus :Software
laboratorio campus software
computadoras computadoras
Introducir Título
parcial de software seleccionarSoftware()
buscarSoftware()
regresar titulos-
Coincidencias return softwareList
mostrar Nuevo software
Enviar solicitud de
imagen actualizar imagen() actualizarImagenSala()
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 323
entidad SOFTWARE. Se busca el software que coincida y se envía la listaSoftware que contiene el número de software,
descripción y versión a la clase controladora. Esto da formato al documento de XML, que se envía a la clase de interfaz
ACTUALIZAR IMAGEN LABORATORIO COMPUTADORAS. El navegador Web da formato al bloque flotante de títu-
los de software. Al seleccionar un título, el navegador lo agrega a la lista de títulos de software y se quita el bloque flo-
tante.
Al hacer clic en el botón Enviar solicitud de imagen en la página Web, se envía la solicitud actualizarImagen() al contro-
lador, el cual envía un mensaje actualizarImagenSala() a la clase de entidad IMAGEN DE SOFTWARE. La tabla de la base de
datos se actualiza y se devuelve el mensaje de éxito al controlador, que a su vez envía una página Web de confirmación.
“El software parece un poco complicado, ya que se reemplazan distintas versiones y paquetes de software por otras dife-
rentes”, comenta Anna. “Creo que es buena idea dibujar un diagrama de estados para el software. Esto nos dará una idea de los
métodos y atributos de software, además de la interfaz que necesitaremos para cambiar esos atributos”.
Anna empieza a trabajar en un diagrama de estados SOFTWARE. Al recibir por primera vez el software, se introduce en
el sistema mediante el formulario AGREGAR SOFTWARE de Microsoft Access y se cambian los valores de los atributos
iniciales. Hay que agregar todo el software antes de poder instalarlo en las máquinas, por lo que se difiere el evento SOFTWARE
INSTALADO EN LAS MÁQUINAS hasta que se haya agregado.
Una vez instalado el software en cualquier cantidad de máquinas, existe en el estado SOFTWARE INSTALADO durante
mucho tiempo. Se actualiza la tabla relacional HARDWARE-SOFTWARE para reflejar el estado actual. De vez en cuando se
reemplaza una máquina y el software se mueve a una máquina distinta. Se vuelve a actualizar la tabla HARDWARE-SOFT-
WARE para reflejar la nueva ubicación. Cuando hay una nueva versión del software disponible, se actualiza con un formulario
CAMBIAR SOFTWARE de Microsoft Access. O también se puede eliminar el software del sistema mediante el formulario ELI-
MINAR SOFTWARE de Microsoft Access. En la figura E10.3 se muestra el diagrama de estados SOFTWARE completo.
Chip y Anna trabajan en varios diagramas de actividad, secuencia y estados. Después de haber completado varios diagra-
mas, Chip comenta: “Creo que tenemos suficiente información para crear un diagrama de clases”.
Anna concuerda, “Sí, vamos a asignar las relaciones”.
En la figura 10.4 se muestra el diagrama de clases SISTEMA COMPUTARIZADO. Cada clase tiene atributos privados y
métodos públicos en Microsoft Access para actualizar los atributos. Las principales clases son Computadora y Software, con
una clase asociativa HardwareSoftware que las conecta. Esta clase se utiliza para implementar la relación de muchos a muchos
entre el hardware y el software. Cada paquete de software pertenece a una Categoría de software y también tiene un Experto de
software a quien se puede llamar para obtener soporte. Cada computadora tiene uno o más sistemas operativos y se localiza en
un edificio del campus.
FIGURA E10.3
Diagrama de estados
se recibió software
SOFTWARE.
se instaló el software
Software en las máquinas Software
Recibido Instalado
se desplazó el software
a un nuevo equipo se actualizó
el software
Software Software
Desplazado Actualizado
se actualizó el software
software
sin utilizar
Software
Eliminado
www.xlibros.com
324 PARTE III • EL PROCESO DE ANÁLISIS
Experto Software
–numeroEmpleado
–apellidoPaterno
–primerNombre
–telefonoOficina
–email
–codigoDepartamento
Edificio Campus
–enseñaCurso
–codigoCampus HardwareSoftware
+agregarExperto()
–descripcionCampus –numeroInventarioHardware +cambiarExperto()
+agregarEdificio() –numeroInventarioSoftware +eliminarExperto()
+instalarSoftware() +obtenerExperto()
+actualizarVersion()
1
+eliminarSoftware() 1
+obtenerSoftware()
+obtenerHardware()
Computadora 1
–numeroInventarioHardware
–tipoComputadora Software
–nombreMarca –numeroInventarioSoftware
–modelo –titulo
–numeroSerie –nombreSistemaOperativo
–fechaCompra –numeroVersion
–costoCompra –editor
–costoReemplazo –codigoCategoriaSoftware
–tamanioMemoria –marcaComputadora
–capacidadDiscoDuro –memoriaRequerida
–capacidadSegundoDiscoDuro –licenciaSitio
–discoOptico –numeroDeCopias
–garantia –costoSoftware
–codigoCampus –numeroEmpleado
–ubicacionSala
+agregarSoftware()
–numeroDistribuidor
+cambiarSoftware()
+agregarComputadora() +obtenerSoftware()
+cambiarComputadora() +obtenerTituloSoftware()
+eliminarComputadora() +eliminarSoftware()
+obtenerComputadora()
1 1
FIGURA E10.4
Diagrama de clases SISTEMA COMPUTARIZADO.
Ejercicios
E-1. Use Microsoft Visio o Visible Analyst para ver el diagrama de actividad ACTUALIZAR IMAGEN LABORATORIO
(UPDATE LAB IMAGE).
E-2. Use Microsoft Visio o Visible Analyst para ver el diagrama de secuencia ACTUALIZAR IMAGEN LABORATORIO
(UPDATE LAB IMAGE).
E-3. Use Microsoft Visio o Visible Analyst para ver el diagrama de estados SOFTWARE.
E-4. Use Microsoft Visio o Visible Analyst para ver el diagrama de clases SISTEMA COMPUTARIZADO (COMPUTER
SYSTEM).
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 325
Los siguientes ejercicios se pueden realizar con Microsoft Visio o con Visible Analyst. Hay que usar un rectángulo para
un símbolo de clase al dibujar diagramas de secuencia con Microsoft Visio o Visible Analyst (los símbolos de estereotipo
de clase no están disponibles). Coloque una etiqueta de texto arriba de cada rectángulo para identificar el tipo de clase:
interfaz, control o entidad.
E-5. Modifique e imprima el diagrama de actividad REGISTRAR PARA CAPACITACIÓN (REGISTER FOR TRAINING).
Consulte la figura E12.3 en el Episodio del caso de la CPU del capítulo 12 para ver el prototipo de esta página Web.
Agregue los siguientes símbolos de estado y conexiones de eventos:
a. El estado CREAR DATOS XML EMPLEADO (CREATE XML EMPLOYEE DATA) en el carril SERVIDOR WEB
(WEB SERVER) debajo del estado OBTENER INFORMACIÓN EMPLEADO (GET EMPLOYEE INFORMA-
TION). Conéctelo con una flecha de evento que venga de LEER REGISTRO EMPLEADO (READ EMPLOYEE
RECORD). Asigne al evento la etiqueta ENVIAR DATOS EMPLEADO (SEND EMPLOYEE DATA).
b. Agregue el estado PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB PAGE) en
el carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE) a la izquierda del estado CREAR DATOS XML EM-
PLEADO (CREATE XML EMPLOYEE DATA). Conecte los dos estados con una flecha de evento hacia el estado
PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB PAGE) etiquetada como
ENVIAR DOCUMENTO XML EMPLEADO (SEND EMPLOYEE XML DOCUMENT).
c. Agregue un estado debajo del estado CREAR DATOS XML EMPLEADO (CREATE XML EMPLOYEE DATA)
que se llame BUSCAR CLASE CAPACITACIÓN SOFTWARE (FIND SOFTWARE TRAINING CLASS). Conéc-
telo con una flecha de evento que provenga del estado PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE
INFORMATION WEB PAGE) y etiquétela como NIVEL DE SOFTWARE Y CAPACITACIÓN SELECCIONADO
(SELECTED SOFTWARE AND TRAINING LEVEL).
d. Incluya un símbolo de diamante de decisión debajo del estado BUSCAR CLASE CAPACITACIÓN SOFTWARE
(FIND SOFTWARE TRAINING CLASS). Conéctelo con una flecha de evento que provenga del estado BUSCAR
CLASE CAPACITACIÓN SOFTWARE (FIND SOFTWARE TRAINING CLASS). Un evento debe fluir a la iz-
quierda hacia el estado PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB
PAGE), etiquetado como NO SE ENCONTRÓ LA CLASE (CLASS NOT FOUND).
e. Agregue un estado SELECCIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS) debajo del estado
PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB PAGE), y un tanto debajo del
diamante de decisión. Conecte la parte inferior del diamante de decisión con una flecha de evento que vaya hacia el
estado SELECCIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS). Etiquétela como CLASES CAPA-
CITACIÓN SOFTWARE (SOFTWARE TRAINING CLASES).
f. Agregue un estado debajo del diamante de decisión y un tanto debajo del estado SELECCIONAR CLASE SOFT-
WARE (CHOOSE SOFTWARE CLASS). Etiquételo como ACTUALIZAR PARTICIPANTE CLASE (UPDATE
CLASS PARTICIPANT).
g. Conecte el estado SELECCIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS) con una flecha de
evento que apunte al estado ACTUALIZAR PARTICIPANTE CLASE (UPDATE CLASS PARTICIPANT). Etiqué-
tela como ENVIAR SOLICITUD INSCRIBIR CLASE (SEND ENROLL CLASS REQUEST).
h. Agregue un símbolo de círculo de salida en la parte inferior del carril Página Web cliente. Conecte el estado SELEC-
CIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS) con una flecha de evento que apunte al círculo de
salida y etiquétela como CANCELAR (CANCEL).
i. Conecte el estado ACTUALIZAR PARTICIPANTE CLASE (UPDATE CLASS PARTICIPANT) con una flecha de
evento que apunte al círculo de salida y etiquétela como ACTUALIZACIÓN EXITOSA (SUCCESSFUL UPDATE).
E-6. Cree e imprima el diagrama de actividad CALENDARIO CAPACITACIÓN (TRAINING CALENDAR). El prototipo
para esta página Web se ilustra en la figura E11.4, que encontrará en el Episodio del caso de la CPU del capítulo 11.
Agregue un círculo de inicio en la esquina superior izquierda del diagrama y agregue los siguientes carriles, símbolos de
estado y conexiones de eventos:
a. Agregue un carril a la izquierda etiquetado como PÁGINA WEB CLIENTE (CLIENT WEB PAGE) y uno a la de-
recha llamado SERVIDOR WEB (WEB SERVER).
b. Agregue un círculo de inicio en la parte superior del carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE) y de-
bajo de éste un estado etiquetado como SOLICITAR PÁGINA WEB CALENDARIO CAPACITACIÓN (REQUEST
TRAINING CALENDAR WEB PAGE). Conecte el círculo de inicio al estado con una flecha de evento.
c. Agregue un estado en el carril SERVIDOR WEB, a la derecha del estado SOLICITAR PÁGINA WEB CALENDA-
RIO CAPACITACIÓN (REQUEST TRAINING CALENDAR WEB PAGE). Etiquételo como OBTENER CLASE
CAPACITACIÓN (GET TRAINING CLASS).
d. Conecte el estado izquierdo al derecho con una flecha de evento etiquetada como SE TRANSMITIÓ FORMULA-
RIO (FORM TRANSMITTED).
e. Coloque un estado debajo del estado OBTENER CLASE CAPACITACIÓN (GET TRAINING CLASS). Etiquételo
como OBTENER CLASE CAPACITACIÓN (GET TRAINING CLASS), Conecte los dos estados con una flecha de
evento hacia abajo etiquetada como ENVIAR NÚMERO CURSO (SEND COURSE NUMBER).
f. Coloque un estado en el carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE) a la izquierda del estado OBTE-
NER CLASE CAPACITACIÓN (GET TRAINING CLASS). Etiquételo como PANTALLA CURSO CALENDA-
RIO CAPACITACIÓN (TRAINING CALENDAR COURSE DISPLAY). Conecte los dos estados con una flecha de
evento que apunte hacia la izquierda y etiquétela como ENVIAR VALORES XML CLASE CAPACITACIÓN
(SEND TRAINING CLASS XML VALUES).
www.xlibros.com
326 PARTE III • EL PROCESO DE ANÁLISIS
g. Coloque un círculo de salida en la parte inferior del carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE). Conecte
el estado PANTALLA CURSO CALENDARIO CAPACITACIÓN (TRAINING CALENDAR COURSE DISPLAY)
con una flecha de evento que apunte a la derecha y arriba por el lado derecho del carril SERVIDOR WEB (WEB SER-
VER), hacia el estado PANTALLA CURSO CALENDARIO CAPACITACIÓN (TRAINING CALENDAR COURSE
DISPLAY). Etiquétela como CAMBIAR FECHA O CAMBIAR ORDEN (DATE CHANGE OR SORT CHANGE).
E-7. Modifique e imprima el diagrama de secuencia REGISTRARSE PARA CAPACITACIÓN (REGISTER FOR TRAI-
NING). Agregue dos nuevas clases de entidad del lado derecho del diagrama y extienda la línea de vida hacia abajo, hasta
la parte inferior del diagrama. Las clases son Empleado y Clase. Agregue los siguientes mensajes del CONTROLADOR
REGISTRARSE PARA CLASE (REGISTER FOR CLASS CONTROLLER) y agregue los rectángulos de foco de con-
trol en donde los mensajes interactúan con la línea de vida de la clase:
a. obtenerEmpleado() [getEmployee()] del controlador a EMPLEADO (EMPLOYEE).
b. regresar datosEmpleado (return employeeData) de la clase EMPLEADO (EMPLOYEE) al controlador.
c. buscarClaseSoftware() [findSoftwareClass()] del controlador a la clase de entidad CLASE (CLASS).
d. regresar listaClaseSoftware (return softwareClassList) de la clase de entidad CLASE (CLASS) al controlador.
e. actualizarParticipanteClase() [updateClassParticipant()] del controlador a la clase de entidad CLASE (CLASS).
f. regresar éxito (return success) de la clase de entidad CLASS al controlador.
E-8. Cree e imprima el diagrama de secuencia CALENDARIO CAPACITACIÓN (TRAINING CALENDAR). Agregue el
actor Docente (Faculty) en la esquina superior izquierda del diagrama y después las siguientes clases, de izquierda a
derecha, a lo largo de la parte superior del diagrama:
a. La clase de interfaz Mostrar clases capacitación (Display Training Classes).
b. La clase de control Mostrar clases capacitación (Display Training Classes).
c. La clase de entidad Clase (Class).
d. La clase de entidad Curso (Course).
Agregue los siguientes mensajes entre las clases o entre el actor y la clase:
a. Cargar página Web Calendario capacitación (Load Training Calendar Web page) de Docente (Faculty) a la clase de
interfaz Mostrar clases capacitación (Display Training Classes).
b. enviarURLPaginaWeb (sendWebPageURL) de Mostrar clases capacitación (Display Training Classes) a Controlador
Mostrar clases capacitación (Display Training Classes Controller).
c. obtenerClase() [getClass()] del controlador a la clase de entidad Clase (Class).
d. regresar listaClases (return classList) de la clase de entidad Clase (Class) al controlador.
e. obtenerDescripcionCurso() [getCourseDescription()] del controlador a la clase de entidad Curso (Course).
f. regresar descripcionCurso (return courseDescription) de la clase de entidad Curso (Course) al controlador.
g. actualizar listaCursos (update courseList) de la clase controladora a la clase de interfaz Mostrar clases capacitación
(Display Training Classes).
h. Página Web Software laboratorio (Lab Software Web Page) de la clase interfaz Mostrar clases capacitación (Display
Training Classes) al actor.
i. Cambiar mes/año (Change Month/Year) del actor a la clase de interfaz Mostrar clases capacitación (Display Training
Classes).
j. Una auto-transición en la clase de interfaz Mostrar clases capacitación (Display Training Classes) (use JavaScript para
actualizar el calendario).
k. Nuevo Calendario (New Calendar) de la clase de interfaz Mostrar clases capacitación (Display Training Classes) al actor.
l. Cambiar fecha (Change Date) del actor a la clase de interfaz Mostrar clases capacitación (Display Training Classes).
m. obtenerNuevaClase() [getNewClass()] de Mostrar clases capacitación (Display Training Classes) al controlador.
n. Repita los pasos c a g.
o. Lista cursos disponible (Course List Available) de la clase de interfaz Mostrar clases capacitación (Display Training
Classes) al actor.
E-9. Modifique e imprima el diagrama de estados Capacitación (Training). Agregue dos estados después de CLASE CAPA-
CITACIÓN CANCELADA (CANCELLED TRAINING CLASS) del lado izquierdo del diagrama. Éstos son CLASE
CAPACITACIÓN ACTIVA (ACTIVE TRAINING CLASS) y, debajo de éste, CLASE CAPACITACIÓN COMPLE-
TADA (COMPLETED TRAINING CLASS). Agregue una clase debajo de CLASE CAPACITACIÓN PROGRAMADA
(SCHEDULED TRAINING CLASS) llamada INSCRITO CLASE CAPACITACIÓN (ENROLLED TRAINING
CLASS). Agregue las siguientes transiciones:
a. SE INSCRIBIERON PARTICIPANTES (PARTICIPANTS ENROLLED) del estado CLASE CAPACITACIÓN
PROGRAMADA (SCHEDULED TRAINING CLASS) al estado INSCRITO CLASE CAPACITACIÓN (ENRO-
LLED TRAINING CLASS).
b. CLASE EN SESIÓN (IN SESSION CLASS) del estado INSCRITO CLASE CAPACITACIÓN (ENROLLED TRA-
INING CLASS) al estado CLASE CAPACITACIÓN ACTIVA (ACTIVE TRAINING CLASS).
c. FINALIZÓ SESIÓN CAPACITACIÓN (TRAINING SESSION ENDED) del estado CLASE CAPACITACIÓN
ACTIVA (ACTIVE TRAINING CLASS) al estado CLASE CAPACITACIÓN COMPLETADA (COMPLETED
TRAINING CLASS).
d. Una flecha de finalización del estado CLASE CAPACITACIÓN COMPLETADA (COMPLETED TRAINING
CLASS) a un área en blanco a la derecha.
E-10. Cree e imprima el diagrama de estados COMPUTADORA. Hay dos columnas de estados. En la columna izquierda in-
cluya los siguientes estados de arriba hacia abajo: NUEVA COMPUTADORA (NEW COMPUTER), CLEANING
COMPUTER (LIMPIANDO COMPUTADORA) y RECYCLED COMPUTER (COMPUTADORA RECICLADA). En
www.xlibros.com
CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 327
la columna derecha incluya los siguientes estados de arriba hacia abajo: COMPUTADORA INSTALADA (INSTALLED
COMPUTER), COMPUTADORA FUNCIONAL (FUNCTIONAL COMPUTER) y COMPUTADORA RETENIDA
REPARACIÓN (REPAIR HELD COMPUTER). Agregue las siguientes transiciones:
a. Empiece con SE RECIBIÓ COMPUTADORA (COMPUTER RECEIVED) que pase de un punto en el espacio arriba
del rectángulo de estado hacia el estado NUEVA COMPUTADORA (NEW COMPUTER).
b. COMPUTADORA INSTALADA (INSTALLED COMPUTER) del estado NUEVA COMPUTADORA (NEW
COMPUTER) al estado COMPUTADORA INSTALADA (INSTALLED COMPUTER).
c. SE INSTALÓ SOFTWARE (SOFTWARE INSTALLED) del estado COMPUTADORA INSTALADA (INSTA-
LLED COMPUTER) al estado COMPUTADORA FUNCIONAL (FUNCTIONAL COMPUTER).
d. SE PROGRAMÓ MANTENIMIENTO (MAINTENANCE SCHEDULED) del estado COMPUTADORA FUNCIO-
NAL (FUNCTIONAL COMPUTER) al estado LIMPIANDO COMPUTADORA (CLEANING COMPUTER).
e. SE COMPLETÓ MANTENIMIENTO del estado LIMPIANDO COMPUTADORA (CLEANING COMPUTER) al
estado COMPUTADORA FUNCIONAL (FUNCTIONAL COMPUTER).
f. SE REPORTÓ PROBLEMA (PROBLEM REPORTED) del estado COMPUTADORA FUNCIONAL (FUNCTIO-
NAL COMPUTER) al estado COMPUTADORA RETENIDA EN REPARACIÓN (REPAIR HELD COMPUTER).
g. SE COMPLETÓ REPARACIÓN (REPAIR COMPLETED) del estado COMPUTADORA RETENIDA EN REPARA-
CIÓN (REPAIR HELD COMPUTER) al estado COMPUTADORA RECICLADA (RECYCLED COMPUTER).
h. ACTUALIZAR COMPUTADORA IDENTIFICADA del estado COMPUTADORA FUNCIONAL (FUNCTIO-
NAL COMPUTER) al estado COMPUTADORA RECICLADA (RECYCLED COMPUTER).
i. SE IDENTIFICÓ REPARACIÓN IRREALIZABLE del estado COMPUTADORA RETENIDA EN REPARACIÓN
(REPAIR HELD COMPUTER) al estado COMPUTADORA RECICLADA (RECYCLED COMPUTER).
j. Una flecha de finalización del estado COMPUTADORA RECICLADA (RECYCLED COMPUTER) a un área en
blanco debajo del estado.
E-11. Modifique e imprima el diagrama de clase COMPUTADORA (COMPUTER). Cada computadora puede tener uno o más
sistemas operativos instalados. Mueva la clase Sistema operativo (Operating System) a la derecha de su ubicación actual
y agregue una nueva clase llamada Sistema operativo de computadora (Computer Operating System) debajo de la clase
Computadora (Computer). Cambie la línea conectora de Computadora a Sistema operativo para conectar la clase Sistema
operativo a la clase Sistema operativo de computadora. Agregue una nueva relación entre la clase Computadora (el lado
de uno) a la clase Sistema operativo de computadora (el lado de muchos). Agregue los siguientes atributos a la clase
Sistema operativo de computadora:
NumeroInventarioHardware
codigoSistemaOperativo
Agregue los siguientes métodos a la clase Sistema operativo de computadora:
agregarSistemaOperativoComputadora()
eliminarSistemaOperativoComputadora()
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access
que pueden usar para completar los ejercicios.
www.xlibros.com
www.xlibros.com
PA RT E I V
CAPÍTULO 11 Los fundamentos
del diseño
Diseño de una salida efectiva
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender los objetivos para un diseño efectivo de la salida.
2. Relacionar el contenido de la salida con los métodos de salida, dentro y fuera de la
organización.
3. Comprender cómo afecta a los usuarios la predisposición en la salida.
4. Diseñar la salida de pantalla.
5. Diseñar tableros de control, widgets y gadgets.
6. Diseñar un sitio Web para comercio electrónico.
La salida es información que se entrega a los usuarios por medio del sis-
tema de información a través de intranets, extranets o la World Wide Web.
Algunos datos requieren de mucho procesamiento para poder convertirse
en una salida adecuada; otros se almacenan y, cuando se recuperan, se con-
sideran salida sin que necesiten mucho procesamiento (a veces no requie-
ren procesamiento en absoluto). La salida puede tomar muchas formas: la tradicional copia en
papel de los informes impresos y la copia transitoria como las pantallas, microformas y la salida
de video y audio. Los usuarios se basan en la salida para realizar sus tareas y con frecuencia
juzgan el mérito del sistema únicamente con base en ella. Para crear la salida más útil posible,
el analista de sistemas trabaja de cerca con el usuario a través de un proceso interactivo hasta
que se considere que el resultado es satisfactorio.
329
www.xlibros.com
330 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Usted tendrá numerosas oportunidades para proveer la salida simplemente porque la aplicación así se lo per-
mite. Sin embargo, recuerde la regla de propósito: si la salida no es funcional, no se debe crear ya que acarrea
costos de tiempo y materiales.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 331
Se provee un
área
para que los
1000 N St. clientes
Lincoln, NE 6850 proporcionen Número de cuenta
1 una Indique el monto
nueva direcc a pagar
Marque esta casil ión. 640-056-175
la si tiene nueva
dirección y escríba
la a continuación
. Una computa
dora
imprime la
información Monto vencido
sobre
la cuenta. $17.38
Dirección de servi
cio Número de cuenta
Eckert Caryn S Fecha de facturación Fec
640-056-175 ha en que se
123 Oak Street 7/8/2009 debe recibir el pag
Lectura anterior o
Lincoln, NE 6850 para poder acreditar
1 Lectura actual lo
en la siguiente fac
1517 tura
1547 5 de ago de 2009
La salida externa es algo con lo que estamos familiarizados: facturas, anuncios, cheques de nómina, infor-
mes anuales y una multitud de comunicaciones que tienen las organizaciones con sus clientes, distribuidores,
proveedores, industria y competidores. El analista diseña una parte de esta salida, como las facturas de los servi-
cios públicos, para que sirva una doble función como documento retornable. La figura 11.1 es un recibo de gas
que sirve como documento retornable para el procesamiento de datos de la compañía de gas. La salida de una
etapa del procesamiento se convierte en la entrada para la siguiente. Cuando el cliente devuelve la parte desig-
nada del documento, se digitaliza esta parte y se utiliza como entrada de computadora.
La salida externa difiere de la interna en cuanto a su distribución, diseño y apariencia. Muchos documentos
externos deben incluir instrucciones para que el receptor pueda utilizarlos en forma correcta. Muchas salidas ex-
ternas se colocan en formularios impresos o en sitios Web que muestran el logotipo de la empresa y los colores
corporativos.
Las salidas internas incluyen varios informes para los encargados de tomar decisiones. Varían desde infor-
mes cortos y sintetizados hasta los largos y detallados. Un ejemplo de informe sintetizado es un informe que
presenta sólo los totales de las ventas mensuales; un informe detallado podría mostrar las ventas semanales por
vendedor.
Otros tipos de informes internos incluyen los informes históricos y los informes de excepciones que se
producen como salida sólo en el momento en que ocurre una excepción. Algunos ejemplos de informes de ex-
cepciones son el listado de todos los empleados sin faltas en todo el año, un listado de todos los vendedores que
no cumplieron con su cuota de ventas mensual o un informe sobre las quejas de los consumidores durante los
últimos seis meses.
Tecnologías de salida
Para producir diferentes tipos de salida se requieren distintas tecnologías. Para la salida impresa, las opciones in-
cluyen una amplia variedad de impresoras. Para la salida en pantalla, las opciones incluyen pantallas conectadas
o independientes. La salida de audio se puede amplificar a través de un altavoz o escuchar a través de bocinas,
que pueden variar desde las más pequeñas hasta los sistemas de sonido envolvente para PC. También se puede
diseñar la salida de audio para teléfonos móviles. La salida electrónica se crea mediante herramientas de soft-
ware especiales. Como podemos ver, las opciones son numerosas. La figura 11.2 muestra una comparación de
los métodos de salida.
IMPRESORAS Como los informes impresos son un tipo muy común de salida, es lógico suponer que las impresoras
están omnipresentes en cualquier organización grande. Aunque hay otros tipos de salida que están ganando
popularidad, es probable que los negocios sigan deseando la salida impresa, o que quieran diseñar salida con una
buena apariencia si los clientes, proveedores o distribuidores la imprimen mediante su propio software y hardware.
www.xlibros.com
332 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Impresora • Asequible para la mayoría de las organizaciones • Aún se requiere de intervención por parte del operador.
• Flexible en cuanto a tipos de salida, ubicación • Problemas de compatibilidad con el software de computadora
y capacidades • Puede requerir provisiones especiales y costosas
• Maneja grandes volúmenes de salida • Puede ser lenta, dependiendo del modelo
• Altamente confiable, con poco tiempo de inactividad • Poco amigable para el ambiente
Salida de audio • Buena para usuarios individuales • Se requieren audífonos cuando la salida no debe interferir
y podcasts • Buena para mensajes transientes con otras tareas
• Buena en donde el trabajador necesita las manos libres • Tiene una aplicación limitada
• Buena si hay que distribuir la salida en áreas
muy amplias
DVC, CD-ROM • Tiene gran capacidad • Se requiere una computadora y una pantalla para leer
y CD-RW • Permite salida multimedia los datos
FIGURA 11.2
Una comparación de los métodos de salida.
Las impresoras ahora tienden a ser más flexibles, lo que se traduce en procesos de expansión de opciones
para la ubicación del sitio de impresión, alojar distintos números de caracteres por página, incluyendo diversos
estilos y fuentes, cambiar la posición de impresión en la página, incluir mayor capacidad de gráficas y color, pro-
ducir una impresión más silenciosa, proteger el ambiente, reducir el número de formularios impresos en el inven-
tario, simplificar las tareas del operador y reducir la cantidad de intervención del operador en general.
En conjunto con los usuarios, el analista de sistemas debe determinar el propósito de la impresora. Una vez
establecido esto, hay que tener en cuenta tres factores clave de las impresoras:
1. Confiabilidad.
2. Compatibilidad con software y hardware.
3. Soporte del fabricante.
PANTALLAS COMO SALIDA Las pantallas son una tecnología de salida cada vez más popular. Usadas en un
principio para la introducción de datos, las pantallas se están convirtiendo también en una tecnología viable para
muchos otros usos a medida que disminuye su tamaño y su precio, a la vez que aumenta su compatibilidad con
otros componentes del sistema.
Las pantallas tienen distintas ventajas sobre las impresoras debido a que son más silenciosas y tienen poten-
cial para la participación interactiva de los usuarios. La salida de pantalla puede ofrecer flexibilidad al permitir al
usuario cambiar la información de salida en tiempo real por medio de la eliminación, adición o modificación de
datos. Las pantallas también permiten revisar la salida almacenada por medio del acceso a (y la visualización de)
los elementos de una base de datos relevante, con lo cual cada uno de los encargados de tomar decisiones puede
dejar de almacenar impresiones redundantes.
Las pantallas como salida producen ahorros en el costo. Si los usuarios pueden realizar sus tareas al interactuar
con una pantalla tal vez no necesiten papel, con lo cual se elimina el costo de imprimir, archivar y almacenar en me-
dios físicos. Si antes se enviaba un informe por correo convencional, al convencer a los usuarios de que vean los docu-
mentos en pantalla podemos ahorrarnos los costos de correo y de impresión. Los corredores de bolsa, las compañías
telefónicas, las empresas de servicios públicos y los bancos ofrecen la entrega electrónica de la salida a sus clientes.
La visualización electrónica también puede ser conveniente desde el punto de vista del usuario. Tal vez un
usuario sólo quiera dar un vistazo a un estado de cuenta mensual para verificar que no tenga errores. Sin em-
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 333
bargo, el usuario necesita archivar ese estado de cuenta por cuestiones fiscales. Si el estado de cuenta se entrega
por correo electrónico, tal vez la copia electrónica sea todo lo que el usuario necesite. Esto ayudará a mantener
los registros y alentará en consecuencia al usuario a que prefiera el estado de cuenta electrónico en vez del im-
preso. Otra razón para preferir la salida de pantalla a la salida de papel es que es más fácil mantener actualizada
la versión electrónica.
Una desventaja potencial es la de mostrar la salida en una variedad de pantallas que utilizan distintas resolucio-
nes. Si la pantalla que se visualiza es de una página Web, el programador de la página Web necesita un plan para re-
visar las imágenes en cada resolución (por ejemplo, 800 × 600, 1600 × 1200, etcétera) y usar distintos navegado-
res para asegurarse de que las páginas tengan una apariencia similar. Si los usuarios necesitan acceso a teléfonos
inteligentes o teléfonos móviles para completar su tarea, tal vez también haya que desarrollar páginas Web especiales.
Si la salida es un informe en vez de una página Web, el analista se enfrenta al reto de resolver otros proble-
mas. Tal vez los usuarios no tengan las fuentes necesarias en sus computadoras y sus documentos de Microsoft
Word estén personalizados con márgenes inusuales. Si se envía un documento de Word por correo electrónico, el
documento con un hermoso formato en la computadora del emisor podría terminar viéndose muy mal en la pan-
talla del receptor. Una solución es la de convertir la salida a archivos PDF mediante Adobe Acrobat. Esto permite
incrustar fuentes inusuales y establecer todos los márgenes en forma apropiada sin importar qué computadora o
resolución de pantalla la despliegue.
VIDEO, AUDIO Y ANIMACIÓN Muchas de las herramientas y paquetes de aplicaciones con los que usted vaya a
trabajar le facilitarán el proceso de incluir video en las opciones de salida. El video es una forma compleja de
salida, ya que combina la solidez y el potencial impacto emocional del audio (incluyendo efectos de sonido, voz
y música) con un canal visual. Algunas aplicaciones conocidas son las que están basadas en Web. Examine la
figura 11.3: muestra una página Web que incluye seis cortos en video del Tazón del Conocimiento del Decision
Sciences Institute (DSI); en este caso es conveniente incluir salida en video del evento, pues conmemora un
aniversario importante en la historia del instituto.
Hay muchos usos para la inclusión de salida de video en las pantallas de los usuarios. Los video clips son
una salida conveniente para:
1. Complementar la salida estática.
2. Permitir una colaboración a distancia que conecte a las personas que no se pueden reunir con frecuencia, por
ejemplo, un equipo que, distribuido en puntos geográficos distantes, debe trabajar en un mismo proyecto.
3. Mostrar cómo llevar a cabo una acción, como demostrar la manera en que se debe llenar un formulario,
instalar cierto software o ensamblar un producto.
4. Proveer episodios de capacitación breves que sean específicos para un trabajo o tarea, de manera que se haga
énfasis en una nueva habilidad.
5. Desplazar el tiempo de un evento real, al grabarlo para verlo después.
6. Preservar una ocasión importante para agregarla a los archivos de una organización.
FIGURA 11.3
Se puede utilizar video de flujo
continuo en forma efectiva para
contar una historia o compartir un
evento. Esta página Web relata
un evento conocido como el Tazón
del Conocimiento de DSI.
www.xlibros.com
334 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
En cierta forma, podemos considerar la salida de audio como lo opuesto a la salida impresa. La salida de
audio es transitoria, mientras que la palabra impresa es permanente. Por lo general, la salida de audio es para
beneficio de un usuario, mientras que la salida impresa se distribuye comúnmente a muchas personas. El oído
humano interpreta la salida de audio como voz, aunque en realidad se produce a través de sonidos digitales dis-
cretos que se reúnen de tal forma que se perciban como palabras continuas. Las compañías telefónicas fueron de
las primeras empresas en producir sistemas que utilizan audio para los clientes.
El sonido también puede mejorar una presentación. Podemos conseguir fácilmente música y efectos de
sonido del dominio público. Los paquetes de presentaciones como Microsoft PowerPoint permiten a los usua-
rios insertar sonido, música e incluso videos. Los archivos de sonido existen en varios formatos, pero algu-
nos de los más comunes para las PC son los archivos MP3, WMP (Windows Media Player), .aac (iTunes e
iPhone) y .WAV.
La salida de audio se utiliza para proveer de ”personal” los números telefónicos gratuitos de venta por catálogo
activos las 24 horas del día, los siete días de la semana. Mediante un sistema telefónico digital, los consumidores
pueden llamar y, en respuesta a instrucciones en salida de audio, introducen número de artículo, cantidad, precio y
su número de tarjeta de crédito. Las tiendas capturan así ventas que perderían de otra forma, ya que podría ser de-
masiado costoso contratar a empleados que se ocupen de contestar llamadas las 24 horas.
Al usar audio y sistemas telefónicos para introducir datos, asegúrese de proveer una retroalimentación apro-
piada para el usuario, como “Ha indicado treinta y tres dólares. Presione uno si es correcto. Presione dos para
cambiar”. La entrada de audio debe contar con un guión bien diseñado y una secuencia clara. Hay que mantener
las instrucciones de audio breves, para que las personas puedan recordar los segmentos iniciales.
Podcasting es la técnica de colocar archivos de voz descargables en un sitio Web. Estos archivos de voz se
pueden utilizar para informar a los clientes sobre nuevos productos o sobre el producto de la semana, proveer un
paseo por una ciudad o destino turístico, presentar noticias y muchas otras aplicaciones. La capacidad de descar-
gar archivos de audio y video ha estado disponible por un buen tiempo ya en la Web, pero el podcasting utiliza
un pequeño archivo RSS (un archivo XML) para almacenar la versión más reciente de un podcast (si los archivos
cambian con frecuencia).
La animación es otra forma de salida que podemos utilizar para mejorar un sitio Web o una presentación. La
animación es la presentación de distintas imágenes en una serie, una a la vez. Las imágenes de animaciones están
compuestas de varios elementos básicos. Los símbolos elementales pueden ser objetos abstractos o fotografías
reales, y pueden tomar distintos colores, formas y texturas. La orientación espacial ayuda al usuario a determinar
si los símbolos están o no muy relacionados entre sí. Los efectos de transición pueden ser graduales o abruptos,
al igual que en las transiciones de las diapositivas de PowerPoint. Los efectos de alteración incluyen cambiar el
color, el tamaño o la textura; además se puede incluir la transformación de la imagen a través del “morphing”.
Si se utiliza la animación para apoyar la toma de decisiones, los experimentos han demostrado que el uso de
imágenes reales en vez de abstractas produce una mejor calidad en las decisiones. Los sujetos experimentales que
vieron transiciones animadas graduales, en vez de abruptas, pudieron tomar mejores decisiones. Al usar la anima-
ción en páginas Web, tenga cuidado en mantener las secuencias armonizadas y no las atiborre de elementos.
CD-ROM Y DVD Con la creciente demanda de salida multimedia, se ha esparcido ampliamente la visualización
de material en CD-ROM. Los CD-ROM son menos vulnerables a los daños producidos por el manejo humano,
en comparación con otros tipos de salida. Los CD-ROM pueden incluir texto y gráficos a todo color, así como
música y video de movimiento continuo, por lo que como medio de salida ofrecen al diseñador una máxima
creatividad. El DVD (disco versátil digital) también es una tecnología de salida útil. Los DVD se utilizan no sólo
para salida sino también como almacenamiento de respaldo.
SALIDA ELECTRÓNICA Muchos de los nuevos sistemas basados en Web que usted diseñará tienen la capacidad de
producir salida electrónica en forma de correo electrónico, fax y mensajes de tableros electrónicos que pueden
enviarse de una computadora a otra sin necesidad de una copia impresa.
El correo electrónico se puede establecer y operar en forma interna en la organización por medio de una
intranet, o por medio de compañías de comunicaciones o proveedores de servicio en línea. Al diseñar sistemas
de correo electrónico podemos brindar soporte a la comunicación en toda la organización. Un sistema de correo
electrónico útil y flexible puede formar la base de soporte para los grupos de trabajo.
Se están diseñando dos grupos de tecnologías recientes que permiten a los usuarios extraer información de
la Web y también permiten a las organizaciones enviar información a los usuarios en forma periódica para las
organizaciones. A estas tecnologías de salida se les conoce como tecnologías push y pull, para reflejar la forma
en que los usuarios y las organizaciones buscan información en la Web y la “jalan” para descargarla o hacen que
se les envíe, o “empuje” hacia ellos.
Las fuentes RSS (sindicación realmente simple) son documentos de XML que los usuarios pueden obtener
de vínculos en páginas Web o a los que se pueden suscribir. Contienen un título, que por lo general es el mismo
nombre que el sitio Web de la fuente RSS; un vínculo, que con frecuencia es el mismo vínculo que el de la página
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 335
O P O R T U N I D A D D E C O N S U LT O R Í A 1 1 . 1
Web; una descripción breve; la leyenda de copyright; el lenguaje en el que está escrito el texto, en donde se utiliza
un código estándar como en-us (para inglés-Estados Unidos); pubDate (la fecha de publicación); lastBuildDate
(la fecha en que se hizo la última modificación a la fuente RSS); imágenes; texto y demás información. Por lo ge-
neral, las fuentes RSS se marcan en una página Web mediante el texto XML o RSS blanco en un botón naranja.
Hace poco tiempo se introdujo un cuadrado naranja con tres líneas blancas que representan ondas de radio en Fi-
refox como un símbolo de botón secundario, y está ganando popularidad.
Se supone que RSS debe ser realmente simple. Está formado por una fuente (también conocida como
canal), la cual consta de un título, un vínculo y una descripción, seguida de varios artículos de noticias, cada
uno con su propio título, vínculo y descripción. Aunque se supone que debe ser simple, debe considerarse
que hay más de media docena de versiones de RSS, además de un formato de sindicación similar conocido
como Atom. Los desarrolladores pueden proveer fuentes RSS en el sitio Web de su empresa o desarrollarlos
para sus clientes.
Para leer la fuente RSS se utiliza software lector de RSS, que a menudo es un programa gratuito. Estos lec-
tores, conocidos también como agregadores de noticias, son programas que rastrean actualizaciones, descargan,
clasifican y muestran las fuentes RSS. RSS es una forma de recopilar y distribuir noticias y demás contenido
de varias fuentes. Los lectores de noticias RSS pueden ser independientes o estar integrados con el navegador
www.xlibros.com
336 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
en forma de complementos. Al momento de escribir este libro, los lectores de noticias populares son Bloglines,
BottomFeeder, FeedDemon, MY MSN, My Yahoo!, NewsIsFree, NEWSMONSTER, Pluck, RSSBANDIT,
SHARPREADER y Wizz RSS (para el navegador Firefox). Pronto se sacudirá el mercado para los lectores RSS
y sólo sobrevivirán unos cuantos de ellos.
RSS tiene la ventaja de organizar con eficiencia las noticias y demás información proveniente de una varie-
dad de fuentes elegidas por el usuario. Además muestra las noticias más recientes primero. RSS no se limita a las
noticias; también se puede usar para llevar el registro de la revisión más reciente de un libro o manuscrito, leer
nuevas reseñas de cine y teatro, o conocer de manera anticipada el nuevo software para nuestro teléfono móvil.
TECNOLOGÍA PULL Es una importante tecnología de salida que se hizo posible gracias a la Web. Si alguna
vez ha intentado jalar información de la Web al hacer clic en vínculos, ha utilizado el tipo más básico de
tecnología pull.
En el futuro tal vez se utilicen agentes evolucionarios (programados mediante el uso de software de agente
inteligente) para ayudar a los miembros de una organización a encontrar lo que necesitan en la Web. Estos agen-
tes aliviarán parte de la carga común de los usuarios al buscar en Web, debido a que observarán y comprenderán
el comportamiento de los usuarios a medida que éstos interactúan con una variedad de material en Web, y des-
pués se pueden programar para buscar la información que desean los usuarios. De esta forma, las búsquedas en
Web serán más eficientes y efectivas para los usuarios.
TECNOLOGÍA PUSH El contenido Web e inalámbrico que se suministra por medio de la tecnología push es
otro tipo de salida que diseñan los analistas. La tecnología push se puede utilizar en la comunicación externa
para empujar (enviar en forma electrónica) la información solicitada o no solicitada a un cliente o consumidor.
También se puede utilizar dentro de la organización para obtener la atención inmediata de un empleado o de
alguien encargado de tomar decisiones que se enfrente a un plazo crítico para entregar elementos críticos. El
término tecnología push se puede describir como cualquier tipo de contenido que se envía a los usuarios en
tiempos especificados, desde webcasting básico hasta la entrega de contenido selectivo mediante el uso de
sofisticados agentes de filtrado evolucionarios.
Muchas empresas tanto tradicionales como basadas en Internet están experimentando con la tecnología
push. Esta tecnología puede obtener la información para la persona que la necesita. Es menos costoso transmitir
información a todos los empleados que imprimir la información y después distribuirla a unos cuantos seleccio-
nados. Sin embargo, el analista necesita protegerse para evitar inundar a los empleados al publicar información
sin sentido.
Las tecnologías push son muy flexibles. Por ejemplo, cuando se transmite la salida de una intranet a una PC,
el usuario puede tomarla y personalizarla de muchas formas. Tal vez un empleado decida ver un solo producto o
desee generar una gráfica de las ventas a través del tiempo.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 337
FIGURA 11.4
Al diseñar un sitio Web, es
importante elegir una metáfora
que se pueda utilizar en todo el
sitio. Este ejemplo de Merchants
Bay (www.merchantsbay.com)
emplea un tema náutico.
a los gerentes en su región. La salida de pantalla o los documentos Web interactivos son excelentes para
personas tales como los despachadores de camiones que permanecen sentados en su escritorio por largos
periodos de tiempo.
Los recipientes externos de la salida (clientes y consumidores, distribuidores y proveedores, accionistas y
agencias regulatorias) y los usuarios dentro de las empresas requerirán de una salida distinta. Los clientes, dis-
tribuidores y proveedores pueden ser parte de varias extranets, que son redes de computadoras construidas por la
organización y proveen aplicaciones, procesamiento e información a los usuarios en la red.
Examine el sitio Web que se muestra en la figura 11.4 para una empresa de comercio electrónico llamada
Merchants Bay. El diseñador Web está compenetrado con los usuarios previstos del sitio de regalos de mayoreo.
El sitio Web de la empresa de comercio electrónico está operado por un algoritmo de negociación patentado, en
el cual los usuarios envían sus ofertas (por 1 artículo o por 400) en una matriz de mercancía. La estrategia de la
empresa se basa en la experiencia personal del presidente con los mercados callejeros y la observación de que
hay una atracción muy poderosa entre las personas y regatear por un artículo.
El sitio Web invoca de manera intencional una sensación de amontonamiento, similar a la sensación que
se obtiene al caminar por un mercado callejero. El sitio está previsto para los clientes que frecuentan mercados
callejeros en persona: se sabe que son coleccionistas, sociables y curiosos por naturaleza. El sitio Web muestra
profusión de colores, incluye una variedad de anuncios de venta en una mezcla de letras e incluso incorpora un
video que proporciona nuevas capas de color y acción. Se utiliza un lenguaje coloquial en todo el sitio.
Cabe mencionar que el eslogan de la empresa es “proveedor de buena mercancía”. El diseñador Web ha
empleado una metáfora náutica en todo el sitio. Se invita al usuario a “buscar en la bahía” para ver toda la mer-
cancía. Además, el logotipo de la empresa incluye una ola y un sol en el horizonte, y hay un icono del timón de
un barco colocado encima de una columna para invitar al usuario a “navegar” en busca de productos, servicios y
servicio al cliente.
Para completar una transacción en el sitio, el cliente tiene la oportunidad de aceptar el “precio del capitán”
publicado, o puede enviar una oferta. Si se envía una oferta demasiado baja de acuerdo con el algoritmo de ne-
gociación almacenado, se devuelve una respuesta en lenguaje natural en una ventana desplegable, la cual dice:
“Gracias por su oferta, marinero. No le gusta deshacerse de su dinero si no tiene que hacerlo, ¿verdad? Aún así
me simpatiza, marinero. Intente de nuevo y ofrezca un mejor precio, o pida una cantidad mayor”. De esta forma,
la oferta se rechaza de una manera amigable y humorística, y las personas que ofertan reciben dos sugerencias
sobre cómo mejorar la probabilidad de que sus siguientes ofertas tengan éxito. Sin duda, el diseñador Web tenía
en mente un sólido perfil del cliente previsto al diseñar el sitio.
¿CUÁNTAS PERSONAS NECESITAN LA SALIDA? La elección de la tecnología de salida también se ve influenciada por
la cantidad de usuarios que requieren la salida. Si muchas personas necesitan la salida, probablemente se justifique
el uso de documentos basados en Web con opción para imprimir o copias impresas. Tal vez algunos clientes
externos quieran una copia impresa de documentos específicos, como el informe para un accionista o un estado de
www.xlibros.com
338 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
cuenta de facturación mensual, pero otros podrían preferir documentos basados en Web con una notificación vía
correo electrónico. Si sólo un usuario necesita la salida, podría ser más adecuado usar una pantalla o audio.
Si muchos usuarios en la empresa necesitan distintas opciones de salida en distintos momentos durante pe-
riodos cortos y la necesitan con rapidez, los documentos Web o pantallas conectadas a terminales en línea que
puedan acceder al contenido de bases de datos son una opción viable.
¿DÓNDE SE NECESITA LA SALIDA (DISTRIBUCIÓN, LOGÍSTICA)? La elección de la tecnología de salida también se
ve influenciada por el destino físico de la salida. La información que permanecerá cerca de su punto de origen,
que sólo unos cuantos usuarios en la empresa utilizarán y que tal vez se almacene o use con frecuencia, se puede
imprimir o montar en una intranet sin peligro. Una cantidad abundante de información que se deba transmitir a
los usuarios a través de grandes distancias en operaciones con sucursales tal vez se distribuya mejor en forma
electrónica, a través de la Web o de extranets, y el receptor puede personalizarla.
Algunas veces, las leyes federales o estatales dictan que un formulario impreso debe permanecer en los ar-
chivos en una ubicación específica y durante un periodo especificado. En esos casos es responsabilidad del ana-
lista de sistemas asegurarse que se cumpla con las leyes para cualquier salida que se diseñe.
¿CUÁL ES EL PROPÓSITO DE LA SALIDA?. ¿Qué tareas de usuario y organizacionales se aceptan? Considere el
propósito de la salida al momento de elegir la tecnología de salida. Si está destinada a ser un informe creado para
atraer accionistas a la empresa, al permitirles examinar las finanzas corporativas a sus anchas, es conveniente una
salida impresa bien diseñada tal como un informe anual. También se puede utilizar una variedad de medios de
manera que el informe anual esté disponible en la Web, así como en forma impresa.
Si el propósito de la salida es proveer actualizaciones instantáneas sobre las cotizaciones en la bolsa, y si
el material cuenta con un alto grado de codificación y puede cambiar, es más adecuado el uso de una pantalla,
páginas Web o presentaciones de audio. La salida debe brindar soporte a las tareas de los usuarios, como la rea-
lización de análisis o la determinación de proporciones, de forma que las herramientas de software, incluyendo
calculadoras y fórmulas incrustadas, podrían ser parte de la salida. También deben brindar soporte a las tareas
organizacionales como el rastreo, la calendarización y la supervisión.
¿CUÁL ES LA VELOCIDAD CON LA QUE SE NECESITA LA SALIDA? Al avanzar por los tres niveles de administración
estratégica, media y de operaciones en la organización, descubrimos que los encargados de tomar decisiones
en el nivel más bajo de la administración de operaciones necesitan la salida con rapidez, para poder ajustarse
rápidamente a eventos como una línea de ensamblaje detenida, materia prima demorada o un trabajador ausente
en forma inesperada. Aquí podría ser útil la salida de pantalla.
Al subir por los niveles administrativos observamos que los gerentes estratégicos necesitan más la salida du-
rante un periodo específico, lo cual ayuda a pronosticar los ciclos y las tendencias de negocios.
¿CON QUÉ FRECUENCIA SE ACCEDERÁ A LA SALIDA? Entre más frecuente sea el acceso a la salida, más importante
será la capacidad de verla en una pantalla conectada a las redes de área local o la Web. La salida a la que se accede
con poca frecuencia y que sólo unos cuantos usuarios necesitan es ideal para un archivo de CD-ROM.
La salida a la que se accede con frecuencia es ideal para incorporarla en los sistemas basados en Web u otros
sistemas o redes en línea con pantallas. Al adoptar este tipo de tecnología, los usuarios obtienen un acceso oportuno y
se alivian el uso y desgaste físicos que producen deterioro en la salida impresa que se maneja con frecuencia.
¿CUÁNTO TIEMPO SE ALMACENARÁ (O SE DEBE ALMACENAR) LA SALIDA? La salida impresa en papel se deteriora
con rapidez a través del tiempo. La salida que se preserva en microformas o que se digitaliza en archivos no es
tan propensa a sucumbir a los disturbios ambientales como la iluminación, la humedad y el manejo humano.
Pero si el hardware para acceder al material archivado es difícil de adquirir o se vuelve obsoleto, este método de
salida puede volverse problemático.
Tal vez una empresa esté sujeta a las leyes gubernamentales en los niveles local, estatal o federal, que dicten
cuánto tiempo se debe mantener guardada la salida. Mientras que la corporación esté dispuesta a mantener la sa-
lida y ésta sea información de archivo no propietaria, se puede mantener en documentos Web como parte del si-
tio Web de la organización. Las organizaciones pueden establecer sus propias políticas internas acerca de cuánto
tiempo se debe retener la salida.
¿BAJO QUÉ LEYES ESPECIALES SE PRODUCE, ALMACENA Y DISTRIBUYE LA SALIDA? El gobierno se encarga de
regular el formato apropiado para ciertos tipos de salida. Por ejemplo, en los Estados Unidos la declaración
del salario y la retención de impuestos de un empleado, a lo cual se le conoce como formulario W-2, se debe
imprimir; su formato final no puede ser una salida de pantalla o microforma. Cada empresa en cada país existe
dentro de un complejo distinto de leyes bajo las cuales produce la salida. Para tal efecto, la ley puede dictar la
tecnología apropiada para ciertas funciones.
Sin embargo, gran parte de estas leyes dependen de la industria. Por ejemplo, en los Estados Unidos la ley federal
requiere que un banco de sangre regional mantenga un historial médico de un donador de sangre (así como su nombre)
en archivo. No se especifica el formato exacto de la salida, pero el contenido está descrito en forma minuciosa.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 339
O P O R T U N I D A D D E C O N S U LT O R Í A 1 1 . 2
¿CUÁLES SON LOS COSTOS INICIALES Y CONTINUOS DEL MANTENIMIENTO Y LOS SUMINISTROS? Los costos
iniciales relacionados con la compra o renta de equipo se deben considerar como otro factor más que participa en
la elección de la tecnología de salida. La mayoría de los distribuidores le ayudarán a estimar los costos iniciales
de comprar o rentar hardware de computadora, incluyendo el costo de las impresoras y pantallas, el costo del
acceso a los proveedores de servicio en línea (acceso a Internet) o los costos de construir intranets y extranets.
Sin embargo, muchos distribuidores no proveen información sobre cuánto cuesta mantener una impresora o
hacer funcionar otras tecnologías. Por lo tanto, es responsabilidad del analista investigar los costos de operación
de las distintas tecnologías de salida o de mantener un sitio Web corporativo a largo plazo.
¿CUÁLES SON LOS REQUERIMIENTOS AMBIENTALES HUMANOS PARA LAS TECNOLOGÍAS DE SALIDA? Los
analistas necesitan incluir en sus decisiones sobre la salida los factores correspondientes a accesibilidad,
absorción de ruido, temperatura controlada, espacio para el equipo, cableado y proximidad a los transmisores
Wi-Fi o puntos de acceso o “puntos calientes”. Cuando los humanos interactúan con las tecnologías, los
ambientes específicos ayudan a los sistemas a operar con mayor efectividad y eficiencia. Los usuarios necesitan
accesibilidad y soporte para acceder a las páginas Web, así como a los demás tipos de salida.
www.xlibros.com
340 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Las impresoras requieren un entorno seco y frío para operar en forma apropiada. Las pantallas requieren
espacio para instalarlas y verlas. La salida de audio y video requiere un entorno silencioso para poder escuchar;
además sólo los empleados (o clientes) que la utilizan deben ser quienes puedan escuchar. Por ende, el analista
no debe especificar una salida de audio para una situación de trabajo en la que haya muchos empleados o clientes
involucrados en una variedad de tareas no relacionadas con la salida.
Para poder establecer redes de área local inalámbricas, de manera que los usuarios puedan acceder a la Web sin
necesidad de cables, debe haber puntos de acceso Wi-Fi disponibles. Estos funcionan cuando las PC están a unos
cuantos cientos de pies de los transmisores, pero pueden estar sujetos a interferencia debido a otros dispositivos.
Algunas tecnologías de salida se valoran por ser discretas. Las bibliotecas, que hacen énfasis en mantener
silencioso el sitio de trabajo, utilizan mucho las pantallas para los documentos Web y demás información de base
de datos en red, pero usan muy pocas impresoras.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 341
400
2008 2009
el número de reservaciones de hotel no completadas en el 2008 con las reservaciones de hotel no completadas en el 2009.
Observe que el eje vertical está roto y parece ser que el número de reservaciones no completadas para el 2008 es dos ve-
ces mayor que el número de reservaciones no completadas en el 2009, aunque en realidad ha aumentado sólo un poco.
www.xlibros.com
342 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 1 . 3
2009
2008
¿Qué tiene de
2005 malo este
gráfico?
2006
2007
11,000 12,000
13,000 14,000
15,000
Promedio
Boletos de
boletos temporada
Estado Año vendidos
por juego vendidos
por temporada
Mejor año 2007 15,643 7,505
2006 14,880
2005 6,808
14,100 7,089
2008 13,254
Peor año 2009 6,735
12,690 6,351
FIGURA 11.C1
Un gráfico dibujado en forma incorrecta.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 343
FIGURA 11.6
Un informe de salida impreso para los gerentes
divisionales de un mayorista de alimentos.
Informació
n de tienda Página 2
Clasificada s de franqu
por las gan icia
Para el me ancias en d
s que term ólares
ina en MM/
D DD/AAAA
F. NÚM.
Nombres d I Ventas en
e las tiend Ganancia
as V miles de
C 5112 Dist bruta en Otros
Front Roy Rango dólares Gastos
S 4311 al, VA miles ingresos
Rockville 20 % en miles asignados Ingresos
R 3021 , MD 23 %
Middlebu 40 51 en miles en
S 5021 rg, VA 41 126 %
C u l p e p e r, 52 5 3.93 dólares
VA 20 22 144 2 %
R 2820 Waldorf, 53 6 1.8
20 95 4 . 2 7 5
C 4424 MD 26 4 0 0.3 4.0
Fairfax-L 40 54 4.29 4 2,144
C 4423 e e Hgwy 42 219 2 3.1 1.7
Baileys X 55 8 3.78 1.9 2,062
-Roads 20 22 72 3 4 4.0 1.4
S 3821 Herndon, 56 3 1 .5 2,057
20 131 4.69 10
C 7126 VA 22 5 1 1.2 4.4 2.2
Frederick 20 57 4.16 2 2,005
S 8029 , MD 23 98 2 1 3.3 0.9
Centrevil 58 5 4.70 . 3 1,903
le, VA 30 32 221 2 5 4.0 2.6
R 5029 Minnievil 59 7 1.7 1,869
20 125 3.35 5
S 7520 le, VA 27 5 4 1.7 4.6 1.4
Mount Ve 20 60 4.04 9 1,727
C 4712 rnon 34 1 7 5 2 4.2 1.8
D.C. M St 61 7 3.73 1.6 1,703
reet 20 24 34 3 5 4.3 0.8
S 4716 Annandal 62 2 1.9 1,615
e 40 90 5.28 8
S 7922 44 5 1 3 .3 4.7 1.3
Vienna, V 20 63 5 .22 1 1,593
R 4491 A 25 235 2 4.0 0.9
Great Fal 64 10 4.35 1.7 1,572
ls 20 25 126 4 5 5.2 4.7
R 3926 Harper’s 65 6 1 . 8 1,558
20 177 4.52 13
C 2422 Ferry 24 9 0 0.1 5.5 1.7
Falls Chu 30 66 4.86 4 1,489
R 3024 rch 33 86 2 1 3.5 0.6
Clifton, V 67 4 4.39 . 2 1,457
A 20 27 68 2 9 5.3 1.2
C 4511 Silver Sp 68 3 4.80 1.9 1,447
ring, MD 20 23 144 0 4 4.7 0.8
R 5120 Olney, MD 69 6 4.06 0.3 1,364
20 42 53 2 2 3.1 1.6
C 4527 D. C C o n n 70 3 5 1.4 1,325
ecticut A 30 121 . 1 7 7 4.6 1.9
C 4526 ve 31 71 5 1 1.6
Pennsylva 40 43 4.06 2 1,322
S 2923 nia Ave 45 72 2 1 1.2 4.3 .9
Manassas 40 110 4.60 5 1,273
42 5 1 .2. 4.3 2.4
20 73 4.28 2 1,237
25 134 0 4.0 1.0
74 6 4.55 0.2 1,217
198 0 4 3.4 2.8
Tiendas en 7 3.54 0 .2 1,200
la ciudad 0 5 4.0 1.1
Tiendas en 0.1 1,073
los suburb 6 3.1 0.8
Tiendas ru ios 6,025 1,057
rales 255 0.5
3,402 4.23
Total (toda 171 67 1.1
s las tiend 2,018 5.03 190
as en la re 92 54 1.6 3.2
gión) 4.56 133 69,987
27 1.3 3.9 1.2
11,445 47 35,020
518 2.3 1.0
4.52 148 43,223
1.3 2.1
370 3.2
148,230
1.3
después soltarlo en la pantalla donde deseamos colocarlo en el formulario. Es muy común utilizar WYSIWYG (lo
que se ve es lo que se obtiene), por lo que el diseño de formularios es un ejercicio muy visual.
La información constante es información que permanece igual cada vez que se imprime el informe. El título
del informe y todos los encabezados de las columnas se escriben como información constante. La información
variable es información que puede variar cada vez que se imprime el informe. En nuestro ejemplo cambian las
cifras de ventas en miles de dólares; por ende, se indican como información variable.
CALIDAD DE PAPEL, TIPO Y TAMAÑO La salida se puede imprimir en innumerables tipos de papel. Por lo general,
la restricción primordial es el costo. Un ejemplo es el uso de papel de seguridad para los cheques y los sobres de
los cheques, así como para los documentos que deben portar sellos oficiales inalterables u hologramas, como los
pasaportes.
Los formularios pre-impresos pueden transmitir con facilidad una imagen corporativa distintiva mediante el
uso de los colores, logotipos y otros elementos de diseño relacionados con la empresa. El uso de formas, colores
y distribuciones innovadoras también es una forma efectiva de llamar la atención de los usuarios para el informe
que contiene el formulario impreso.
CONSIDERACIONES DE DISEÑO Al diseñar el informe impreso, el analista de sistemas trabaja con los usuarios
para incorporar las consideraciones funcionales y estilísticas o estéticas, de manera que el informe provea al
usuario la información necesaria en un formato legible y agradable. Como la función y la forma se refuerzan una
a otra, no hay que hacer énfasis en una a expensas de la otra.
Atributos funcionales Los atributos funcionales de un informe impreso incluyen: 1) el encabezado o título del
informe, 2) el número de página, 3) la fecha de preparación, 4) los encabezados de columnas, 5) el agrupamiento
de los elementos de datos relacionados y 6) el uso de interrupciones de control. Cada uno de estos atributos sirve
un propósito distintivo para el usuario.
Hay varias consideraciones estilísticas o estéticas que el analista de sistemas debe observar al diseñar un in-
forme impreso. Si la salida impresa es poco atractiva y difícil de leer, no se utilizará en forma efectiva o tal vez
no se utilice para nada. El resultado es la desinformación de los encargados de tomar decisiones y un desperdicio
de los recursos de la organización.
www.xlibros.com
344 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Los informes impresos deben estar organizados en consideración del fluir de la vista. En esta cultura, eso
significa que el informe se debe leer de arriba hacia abajo y de izquierda a derecha. Los elementos de datos rela-
cionados se podrían agrupar entre sí. En una sección posterior de este capítulo veremos la estética sobre el diseño
de sitios y páginas Web.
FIGURA 11.7
La pantalla de salida de New Zoo
está ordenada y orienta bien a los
usuarios. Estado de pedidos de New Zoo
Vendedor Pedido # Fecha del pedido Estado del pedido
Animals Unlimited 933401 09/05/2009 Se envió el 09/29
934567 09/11/2009 Se envió el 09/21
934613 09/13/2009 Se envió el 09/21
934691 09/14/2009 Se envió el 09/21
Bear Bizarre 933603 09/02/2009 Envío parcial
933668 09/08/2009 Programado para el 10/03
934552 09/18/2009 Programado para el 10/03
934683 09/18/2009 Se envió el 09/28
Cuddles Co. 933414 09/12/2009 Se envió el 09/18
933422 09/14/2009 Se envió el 09/21
934339 09/16/2009 Se envió el 09/26
934387 09/18/2009 Se envió el 09/21
934476 09/25/2009 Pedido pendiente
Stuffed Stuff 934341 09/14/2009 Se envió el 09/26
934591 09/18/2009 Envío parcial
934633 09/26/2009 Pedido pendiente
934664 09/29/2009 Envío parcial
Oprima cualquier tecla para ver el resto de la lista; ESC para finalizar; ? para ayuda
Para obtener más detalle, coloque el cursor sobre el número de pedido y oprima Intro.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 345
ferior de la pantalla proveen a los usuarios varias opciones, incluyendo continuar con la pantalla actual, terminar
con la pantalla, obtener ayuda u presentar más detalle. Esta pantalla provee contexto para los usuarios que tratan
de completar una tarea, como verificar el estado de un pedido.
Las pantallas de salida de una aplicación deben mostrar información de manera consistente, de una página
a otra. La figura 11.8 muestra la pantalla que se produce cuando el usuario coloca el cursor sobre el número de
pedido para un vendedor específico. La nueva pantalla presenta más detalles sobre Bear Bizarre. En el cuerpo
de la pantalla, el usuario puede ver el número de pedido del vendedor, la dirección completa, la fecha del pedido
y el estado. Además se proporciona un desglose detallado del envío y un estado detallado de cada parte del envío.
Se provee un nombre y número telefónico de contacto, junto con el saldo de la cuenta, la clasificación de cré-
dito y el historial de envíos. Cabe mencionar que la parte inferior de la pantalla aconseja al usuario sobre ciertas
opciones, incluir más detalles, finalizar la pantalla u obtener ayuda. Los usuarios reciben el control sobre lo que
podrían hacer después de ver la pantalla.
En vez de amontonar toda la información de un vendedor en una sola página, el analista ha hecho posible
que el usuario pueda ver la información sobre un vendedor específico en caso de que surja un problema o una
duda. Por ejemplo, si el resumen indica que se envió sólo una parte de un pedido, el usuario puede verificar más
detalles del mismo mediante una llamada a una pantalla detallada del vendedor, para después proceder con la
acción apropiada.
FIGURA 11.8
Si los usuarios desean más detalles
relacionados con el estado de
envío, pueden pedir una pantalla
Pedido # Vendedor Fecha del pedido Estado del pedido
separada.
933603 Bear Bizarre 09/02/2008 Envío parcial
1001 Karhu Lane
Bern, Virginia 22024
Oprima cualquier tecla para ver el resto de la lista; ESC para finalizar; ? para ayuda
www.xlibros.com
346 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 11.9
Una pantalla de gráfico de barras
para inspeccionar el tiempo de
respuesta de la tropa en pantalla.
Tiempo de respuesta promedio por área de tropa
Policía Estatal de Nebraska
50
45
40
35
30
Tiempo
(en minutos) 25
20
15
10
5
0
Sede A B C D E Estado
Elementos en el área de tropa
Tableros de control
Los encargados de tomar decisiones necesitan una salida que les ayude a tomar decisiones con efectividad y rapi-
dez. Es muy conveniente para los ejecutivos y demás personas encargadas de tomar decisiones que toda la infor-
mación necesaria para tomar las decisiones aparezca en pantallas frente a ellos. Cuando recibe un informe escrito,
el encargado de tomar decisiones preferiría que toda la información estuviera contenida dentro de ese informe, en
vez de tener que buscar información en otros lugares. El mismo principio se aplica al diseño de pantallas.
Un tablero de control, similar al tablero de un automóvil, tiene muchos medidores distintos. Cada medidor
puede mostrar una gráfica (algo así como la velocidad en millas o kilómetros por hora), un indicador de falla
(como un indicador que muestra que el sistema de freno automático no funciona) o incluso texto (como un odó-
metro que simplemente cuenta los kilómetros recorridos).
A un ejecutivo le puede parecer muy útil el tablero de control al tomar decisiones, pero sólo si su diseño es
apropiado. El tablero de control de la figura 11.10 muestra que se puede incluir una cantidad considerable de in-
formación en una sola pantalla.
FIGURA 11.10
Este tablero de control presenta
varios tipos de indicadores de
desempeño para ayudar a tomar
decisiones.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 347
Los tableros de control se enfocan en comunicar las mediciones al usuario. Un ejecutivo utiliza un tablero
de control para revisar las medidas de desempeño y tomar acción si la información en la pantalla lo requiere. He
aquí algunas reglas empíricas que puede utilizar para que el tablero de control que usted diseñe sea más atractivo
y efectivo:
1. Asegúrese que los datos tengan contexto. Si diseña una pantalla que indique que las ventas del mes pasado
fueron de $851,235, ¿qué significa eso? ¿Están las ventas por encima o por debajo del promedio?
2. Presente la información en forma apropiadamente sintética y precisa. Su pantalla se verá atestada si muestra
las ventas del mes pasado como $852,235.32, en vez de indicar en el título el uso de miles de dólares y
mostrar sólo 851.
3. Seleccione las medidas de desempeño apropiadas para la pantalla. Por ejemplo, trazar la diferencia entre las
ventas actuales y las esperadas en un gráfico de desviación es mucho más significativo que usar un gráfico
de línea para trazar las ventas actuales y esperadas.
4. Presente los datos en forma justa. Si hay predisposición en el tablero de control, dificultará las buenas
decisiones, en lugar de sustentarlas.
5. Seleccione el estilo correcto de gráfica para la pantalla. Es importante usar la gráfica adecuada. Aunque una
gráfica de pastel puede ser excelente para persuadir a alguien, tal vez no sea la mejor elección para que un
ejecutivo supervise el desempeño de las oficinas regionales, por ejemplo.
6. Use medios de visualización bien diseñados. Incluso si selecciona el mejor tipo de gráfica, de todas
formas necesitará dibujar, ajustar tamaño y color, y etiquetar la gráfica de manera significativa y
agradable.
7. Limite la variedad de tipos de elementos. Mantenga el menor número de estilos posibles de gráficos,
diagramas y tablas, de manera que la información se pueda comunicar con rapidez y precisión.
8. Resalte los datos importantes. Use colores brillantes y fuentes en negrita sólo para los datos importantes.
Puede resaltar las medidas clave de desempeño o las excepciones importantes que estén ocurriendo, pero no
ambas cosas. Seleccione qué desea enfatizar.
9. Ordene los datos en grupos representativos. Las medidas de desempeño casi siempre se asocian con otras
medidas de desempeño debido a los datos mostrados o el tipo de gráfico. Aprenda cómo agrupar los
elementos asociados.
10. Mantenga la pantalla actual ordenada. Evite las fotografías, los logotipos ornamentados o los temas que
puedan distraer a los usuarios de los datos.
11. Mantenga todo el tablero de control en una sola pantalla. Todas las medidas de desempeño deben estar en
la misma pantalla. Si se ve obligado a cambiar pantallas, un usuario no podrá ver dos medidas relevantes
a la vez.
12. Permita cierta flexibilidad. Si un ejecutivo desea un gráfico o diagrama distinto, considere reemplazarlo. Es
conveniente crear un prototipo del tablero de control y refinarlo con base en la retroalimentación del usuario.
A menudo los encargados de tomar decisiones saben más al tratarse de obtener la información correcta en la
forma más apropiada para su estilo de decisión.
www.xlibros.com
348 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 1 . 4
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 349
Ajax Un método que utiliza JavaScript y XML para modificar páginas Web en forma dinámica, sin mostrar una
nueva página, mediante la obtención de pequeñas cantidades de datos del servidor.
CSS Hojas de estilo en cascada, un conjunto de estilos que controlan el formato de una página Web. Los estilos CSS se pueden
almacenar en un archivo y usar para dar formato a varias páginas Web, o se pueden definir dentro de una página Web.
DHTML HTML dinámico, una forma de combinar JavaScript y tal vez las hojas de estilo en cascada para hacer que
la página Web cambie con base en las acciones del usuario.
FAQ Preguntas frecuentes. Con frecuencia los sitios Web tienen una página dedicada a estas preguntas frecuentes, para
que la fuerza de ventas de la empresa o el equipo de soporte técnico no se vean inundados con las mismas
preguntas una y otra vez; además los usuarios pueden tener acceso a las respuestas las 24 horas del día.
FTP Protocolo de transferencia de archivos, en la actualidad es la forma más común de mover archivos entre distintos sistemas
computarizados.
GIF Formato de intercambio de gráficos, un formato popular de imágenes comprimidas que se adapta muy bien al material gráfico.
Java Un lenguaje orientado a objetos que permite ejecutar aplicaciones dinámicas en Internet. Los que no son
programadores pueden usar paquetes de software tales como Visual Café para Java de Symantec.
JPEG Grupo unido de expertos en fotografía, el acrónimo para un popular formato de imágenes comprimidas que se
adapta muy bien a las fotografías; el diseñador puede ajustar la calidad de estas fotografías.
HTML Lenguaje de marcado de hipertexto, el lenguaje detrás de la apariencia de los documentos en Web. En realidad es
un conjunto de convenciones que marcan las porciones de un documento para indicarle al navegador qué formato
distintivo debe aparecer en cada porción de una página.
http:// Protocolo de transferencia de hipertexto, se utiliza para mover páginas Web entre distintas computadoras; por
ejemplo, desde un sitio Web en una computadora que esté en otro país, hasta su computadora personal.
PHP Un lenguaje de programación de código fuente abierto, que a menudo se utiliza con MySQL, un sistema de administración
de bases de datos.
complementos Software adicional (a menudo desarrollado por un tercero) que se puede utilizar con otro programa; por ejemplo,
o plug-ins Real Player de RealNetworks o Macromedia Flash se utilizan como complementos en los navegadores Web para
reproducir audio o video de flujo continuo y ver animaciones basadas en vectores.
URL Localizador uniforme de recursos, la dirección de un documento o programa en Internet. Las extensiones conocidas
son .com para comercios, .edu para instituciones educativas, .gov o .gob para instituciones gubernamentales, .org
para organizaciones, etcétera.
WMP Windows media photo, una alternativa a JPEG desarrollada por Microsoft.
FIGURA 11.11
Términos del vocabulario Web.
ESTUDIE OTROS SITIOS WEB Analice los sitios Web que usted y otros usuarios piensen que son interesantes.
Analice los elementos de diseño que utilicen y vea cómo funcionan; después trate de emular lo que ve mediante
la creación de páginas de prototipo (no es ético ni legal cortar y pegar imágenes o código, pero de todas formas
puede aprender algo de los otros sitios).
Firefox, que forma parte del movimiento de software de código fuente abierto, es un útil navegador para es-
tudiar otros sitios Web. Tiene varias extensiones creadas por terceros desarrolladores, las cuales están disponibles
como descargas gratuitas. Ejecute Firefox, haga clic en “Herramientas/Complementos” y después en “Examinar
todos los complementos”. Hay páginas de complementos y extensiones; una, llamada Web Developer, es muy
útil para los diseñadores y webmasters, ya que permite al analista delinear tablas y estilos, además de ver Java-
Script y cookies; provee información además de muchos otros útiles elementos a escoger. Palette Grabber es otra
extensión que permite a los desarrolladores Web ver una pantalla de códigos de color con sólo elegir un color
en un sitio Web. También hay herramientas para trabajar con XML. La figura 11.12 es un ejemplo de la barra de
herramientas Web Developer que se utiliza para resaltar las celdas de las tablas. Observe el borde rojo alrededor
de cada celda individual.
www.xlibros.com
350 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 11.12
Un desarrollador Web puede
delinear las celdas de las tablas al
diseñar una página Web, como se
muestra en este ejemplo.
USE LOS RECURSOS QUE OFRECE LA WEB Analice los sitios Web que ofrecen sugerencias sobre diseño. Uno de
ellos es useit.com.
EXAMINE LOS SITIOS WEB DE DISEÑADORES PROFESIONALES Mientras analiza páginas diseñadas por
profesionales pregúntese: “¿Qué es lo que funciona? ¿Qué no funciona? ¿En qué formas pueden los usuarios
interactuar con el sitio?” Por ejemplo, ¿tiene el sitio vínculos activos a direcciones de correo electrónico,
formularios interactivos que se pueden llenar, encuestas para el consumidor, juegos, cuestionarios, salas de chat,
etcétera? ¿Qué hay sobre los esquemas de color y las metáforas omnipresentes?
USE LAS HERRAMIENTAS QUE APRENDIÓ La figura 11.13 provee un formulario que algunos diseñadores Web
han usado con éxito para evaluar las páginas Web en forma sistemática. Tal vez quiera usar este formulario para
FIGURA 11.13
Un formulario de evaluación de
sitios Web. Crítica de sitio
Web
Fecha de visita: Nombre del anali
sta
Hora de visita:
URL visitado
DISEÑO
Necesita
Apariencia en ge mejorar
neral Excelente
Uso de gráficos
Uso de color 1 2 3 4
1 2 5
Uso de sonido/v 3 4
ideo (multimedia) 1 5
Uso de nueva tec 2 3
nología y produ 1 4 5
ctos 2 3
1 4 5
CONTENIDO E IN 2 3
TERACTIVIDAD 4 5
Contenido
Capacidad de na
vegación 1 2
Administración 3 4
del sitio y comu 1 2 5
nicacion es 3 4
1 2 5
3 4 5
PUNTUACIÓN
COMENTARIOS /40
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 351
ATRACTIVO DE LA MAC
Hay muchas metodologías para crear sitios Web. Los codificadores desean el mayor grado de control posible sobre el
código HTML, pero muchos diseñadores no están tan interesados en dominarlo. Los buenos diseñadores desean poder
incluir muchos elementos distintos tanto en gráficos como en texto, girar y mejorar imágenes, darles formato en diseños
cuidadosamente elaborados y hacer que tengan la misma apariencia en cualquier navegador y en cualquier resolución.
Hay muchos paquetes WYSIWYG disponibles que permiten a los diseñadores hacer esto, tanto en una Mac como en
una PC. Algunos de estos paquetes funcionan bien; otros no.
Softpress Systems, los desarrolladores de Freeway Pro, han creado software de diseño Web con un enfoque dife-
rente. A diferencia de otros paquetes, Freeway Pro no crea código mientras el diseñador trabaja, sino hasta que el dise-
ñador está satisfecho con su diseño. De esta manera, el código es en extremo eficiente. También es una herramienta muy
útil para la creación de prototipos. Freeway Pro supone que cuando cambien los estándares, las actualizaciones para el
software permitirán a los diseñadores Web volver a publicar todo el sitio utilizando el estándar actualizado.
FIGURA 11.MAC
Freeway Pro de Softpress Systems ofrece un enfoque único para los diseñadores de sitios Web.
que le ayude a comparar y contrastar todos los sitios Web que visitará a medida que aprende sobre el diseño de
páginas Web.
CONSULTE ALGUNOS LIBROS Algo que puede aumentar su experiencia en este nuevo campo es leer sobre el
diseño Web. Algunos buenos libros sobre diseño Web son:
Eckerson, W. W. Performance Dashboards: Measuring, Monitoring, and Managing Your Business. Nueva York:
John Wiley & Sons, Inc., 2005.
Few, S. Information Dashboard Design: The Effective Visual Communication of Data. Sebastopol, CA: O’Reilly
Media, Incorporated, 2006.
Flanders, V. y D. Peters. Son of Web Pages That Suck: Learn Good Design by Looking at Bad Design. Alameda,
CA: Sybex, 2002.
McNeil, P. The Web Designer’s Idea Book: The Ultimate Guide to Themes, Trends & Styles in Website Design.
Nueva York: F+W Media, 2008.
www.xlibros.com
352 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
ANALICE TAMBIÉN MALOS EJEMPLOS DE PÁGINAS WEB Elabore críticas de páginas Web mal diseñadas y
recuerde evitar esos errores. Examine el sitio Web en www.webpagesthatsuck.com. A pesar de su nombre
“contracultural”, es un maravilloso sitio que provee vínculos a muchos sitios mal diseñados y resalta los errores
que cometieron sus diseñadores.
CREE SUS PROPIAS PLANTILLAS Si adopta una página con apariencia estándar para la mayoría de las páginas que
vaya a crear, podrá tener el sitio Web en funcionamiento rápidamente, con una apariencia buena y consistente.
Se pueden crear sitios Web mediante el uso de hojas de estilo en cascada (CSS), con lo cual el diseñador puede
especificar sólo una vez el color, tamaño y tipo de fuente, además de muchos otros atributos. Estos atributos se
almacenan en un archivo de hoja de estilo y después se aplican a muchas páginas Web. Si un diseñador cambia
una especificación en el archivo de hoja de estilo, se actualizarán todas las páginas Web que utilizan esa hoja de
estilo para reflejar el nuevo estilo.
USE COMPLEMENTOS, AUDIO Y VIDEO CON MEDIDA Es maravilloso tener las nuevas características que poseen
las páginas profesionales, pero debemos recordar que todos los que ven nuestro sitio no necesitan tener todos los
nuevos complementos. No ahuyente a los visitantes de su página.
PLANIFIQUE Los buenos sitios Web están cuidadosamente planificados. Ponga atención a lo siguiente:
1. Estructura.
2. Contenido.
3. Texto.
4. Gráficos.
5. Estilo de presentación.
6. Navegación.
7. Promoción.
Estructura Planificar la estructura de un sitio Web es uno de los pasos más importantes para desarrollar un sitio Web
profesional. Piense en sus metas y objetivos. Cada página de la estructura Web general debe tener un mensaje o
FIGURA 11.14
El sitio Web de DinoTech utiliza al máximo los vínculos, fuentes RSS,
suscripciones de video y anuncios de pancarta.
Vínculos a
sub-Webs
Fuentes RSS
Suscripción
de video
Anuncios Vínculos rápidos Artículos principales Salas de chat Vínculo de contacto por email
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 353
alguna otra información relacionada. Algunas veces es conveniente examinar sitios profesionales para analizarlos
en cuanto a su contenido y características. En la figura 11.14 se muestra una pantalla del sitio Web DinoTech. El
propósito del sitio y el medio Web funcionan bien en conjunto. Observe que hay mucho énfasis en apoyar a los
usuarios en el sitio. Hay texto, gráficos, imágenes JPEG e iconos. Además hay muchos tipos de vínculos: a fuentes
RSS, video, sub-Webs, salas de chat, un motor de búsqueda y muchas otras características.
Para ayudar a planear y mantener una estructura sólida, un webmaster puede aprovechar las diversas he-
rramientas para creación de diagramas y mapas de sitios Web disponibles. Muchos paquetes de software, inclu-
yendo Microsoft Visio, tienen opciones de diagramas Web integradas en el software. Además de ser útiles para
el desarrollo, estas herramientas se vuelven incluso más importantes al dar mantenimiento al sitio. Dada la natu-
raleza dinámica de la Web, los sitios vinculados a su sitio podrían moverse en cualquier momento y usted o su
webmaster tendrían que actualizar los vínculos.
En la figura 11.15 se muestra un mapa de una sección del sitio Web de los autores en la ventana de Micro-
soft Visio. En este ejemplo exploramos el sitio Web en todos los niveles existentes. Observe los vínculos a pági-
nas de HTML, documentos, imágenes (archivos GIF o JPEG) y elementos “mail-to” (una forma de enviar correo
electrónico a una persona designada). Los vínculos pueden ser internos o externos. Si un vínculo está roto, apa-
rece una X de color rojo y el analista puede investigar más sobre ello. Este archivo de Visio se puede imprimir en
secciones para publicarlo en la pared y obtener una imagen general del sitio Web.
Contenido Provea algo importante a los usuarios del sitio Web. Las animaciones, películas y sonidos
emocionantes y divertidos, pero debe incluir el contenido apropiado para que el usuario siga interesado. Ofrezca
algún consejo oportuno, información importante, una oferta gratuita o cualquier actividad que pueda proveer, que
sea interactiva y haga que los usuarios pasen del modo de exploración al modo interactivo.
La pegajosidad es una cualidad que debe poseer un sitio Web. Si un usuario permanece en su sitio durante
un extenso periodo de tiempo, su sitio tiene un alto grado de pegajosidad. Ésta es la razón por la que un comer-
ciante incluye muchos elementos de interés en un sitio. Por ejemplo, un comerciante de vinos puede poner lec-
ciones sobre cómo descorchar una botella, probar el vino o elegir una copa adecuada.
Use una metáfora o imágenes que provean una metáfora para su sitio. Puede usar un tema, como un esca-
parate, con páginas adicionales que tengan varias metáforas relacionadas con el escaparate, como una tienda de
productos gourmet. Evite el uso excesivo de caricaturas y no sea repetitivo.
Todo sitio Web debe incluir una página FAQ (preguntas frecuentes). A menudo estas preguntas se crean con
base en las experiencias de los usuarios y el personal de soporte técnico, quienes identifican los temas de preocu-
pación continua. El ochenta por ciento de las preguntas entra a la categoría FAQ. Al tener las respuestas disponi-
bles las 24 horas del día, ahorrará el valioso tiempo de sus empleados y los usuarios. Las páginas FAQ también
demuestran a los usuarios de su sitio que está coordinado con ellos y tiene una buena idea de lo que les gustaría
conocer.
FIGURA 11.15
Podemos evaluar los vínculos
rotos en un sitio Web mediante el
uso de un paquete como Microsoft
Visio.
www.xlibros.com
354 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
En la Web, el software COTS tiene otro significado: un sitio puede aprovechar el software previamente es-
crito. Algunos ejemplos son los motores de búsqueda (como Google), el software para mapas (como MapQuest),
la información sobre el clima y los cintillos de noticias y de la bolsa de valores. Los diseñadores de sitios Web
aprecian estos paquetes debido a que pueden incrementar la funcionalidad del sitio, y las características adiciona-
les alientan a los usuarios a marcar los sitios Web de sus clientes como sitios favoritos, ya que proveen un conte-
nido adicional valioso.
Texto Recuerde que el texto también es importante. Cada página Web debe tener un título. Coloque las palabras
significativas en el primer enunciado que aparece en su página Web. Deje que las personas sepan que están
navegando en el sitio Web correcto. La escritura clara es especialmente importante.
Gráficos La siguiente lista provee los detalles sobre la creación de gráficos efectivos para sitios Web:
1. Use uno de los formatos de imagen que se utilizan con más frecuencia, JPEG o GIF. Las imágenes JPEG
son mejores para las fotografías y las imágenes GIF son mejores para las ilustraciones. Las imágenes GIF
están limitadas a 256 colores, pero pueden incluir un fondo transparente, píxeles que permiten mostrar el
fondo a través de la imagen GIF. Las imágenes GIF también pueden ser entrelazadas, lo cual significa que
el navegador Web mostrará la imagen en etapas sucesivas, presentando una imagen más clara en cada
etapa.
2. Mantenga el fondo simple y asegúrese de que los usuarios puedan leer el texto con claridad. Al utilizar un
patrón de fondo, asegúrese de poder leer el texto encima del fondo claramente.
3. Cree unos cuantos gráficos con apariencia profesional para usarlos en sus páginas.
4. Mantenga las imágenes gráficas pequeñas y reutilice las viñetas o botones de navegación, como
RETROCEDER, ARRIBA, EMAIL y SIGUIENTE. Estas imágenes se almacenan en una caché, un área en
el disco duro de la computadora que está navegando por el sitio Web. Una vez recibida una imagen, se
tomará de la caché cada vez que se vuelva a utilizar. El uso de imágenes en caché aumenta la velocidad con
la que un navegador puede cargar una página Web.
5. Incluya texto en lo que se denomina atributo de texto para las imágenes y los puntos activos de imágenes. El
texto aparece cuando el usuario desplaza el ratón encima de la imagen. Un atributo alt provee texto para los
lectores de pantalla y es esencial para ofrecer el soporte de accesibilidad Web para los visitantes con
discapacidad visual.
6. Examine su sitio Web en varias pantallas y resoluciones de pantalla. Las escenas y el texto que se ven bien
en una pantalla de video de alta tecnología tal vez no se vean bien en otras pantallas de menor calidad.
Estilo de presentación La siguiente lista muestra detalles adicionales sobre cómo diseñar pantallas de entrada
atractivas.
1. Ofrezca una pantalla de entrada (también conocida como página de inicio) que introduzca al visitante al
sitio Web. La página se debe diseñar de manera que se cargue rápidamente. Una buena regla práctica es
diseñar una página que se cargue en 14 segundos (considere que la conexión del visitante de su sitio Web
podría ser más lenta). Esta pantalla de entrada debe ser de 100 kilobytes o menos, incluyendo todos los
gráficos.
La página de entrada debe contener varias opciones, algo similar a un menú. Una forma fácil de
lograr esto es diseñar un conjunto de vínculos o botones y colocarlos en el lado izquierdo o en la parte
superior de la pantalla. Estos vínculos se pueden enlazar a otras páginas en el mismo sitio Web o a
distintos sitios Web. Podemos incluir un menú de texto especializado con una fuente de menor tamaño en
la parte superior o inferior de la página. En la figura 11.16 se muestra un ejemplo de una página de
entrada que contiene una imagen extensa y algo de contenido, pero que permite al visitante navegar hacia
cualquier otra parte del sitio. Esta página se construyó con software que permite a los diseñadores ver el
código de HTML (en la parte inferior de la pantalla) al mismo tiempo que la apariencia que tendrá la
página en un navegador Web.
2. Mantenga el número de gráficos a un mínimo razonable. Se requiere un tiempo de descarga adicional para
transferir un sitio con muchos gráficos.
3. Use fuentes grandes y coloridas para los encabezados.
4. Use imágenes y botones interesantes para los vínculos. A un grupo de imágenes que se combinan en una
sola imagen se le denomina mapa de imágenes, el cual contiene varios puntos activos que actúan como
vínculos hacia otras páginas.
5. Use hojas de estilo en cascada (CSS) para controlar el formato y la distribución de la página Web. Las hojas
CSS separan el contenido (el texto y las imágenes) de la apariencia (la presentación). Por lo general, las
hojas de estilo en cascada se almacenan en un archivo externo a la página Web; además, una hoja de estilo
puede controlar el formato de muchas páginas. Una ventaja de usar las hojas de estilo externas es hacer una
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 355
FIGURA 11.16
Mediante el uso de un editor de
HTML (Visual Page en este
ejemplo), el diseñador de un sitio
Web puede ver la apariencia que
tendrá una página en el navegador
y el código de HTML (vea la parte
inferior de la pantalla) al mismo
tiempo.
modificación en la hoja de estilo; por ejemplo, al cambiar el color del texto en negritas cambiará el formato
de todas las páginas Web que utilizan esa hoja de estilo. También podemos usar hojas de estilo en cascada en
una sola página Web y cualquier estilo duplicado invalidará al de una hoja de estilo externa, en caso de que
se utilice alguna. Esto permite al diseñador variar la apariencia visual estándar de un sitio Web, tal vez para
una página Web de “venta especial” o alguna otra excepción. Es posible agregar estilos a elementos
individuales en una página Web para anular cualquier otra hoja de estilo.
6. Use divisiones y hojas en cascada o tablas para mejorar la distribución de una página Web. Las tablas son
fáciles de usar y proveen una distribución adecuada; sin embargo, no son muy apropiadas para los visitantes
discapacitados. El software de lectura de pantalla lee a través de la página, no necesariamente en la columna
de una tabla. Para controlar la distribución en pantalla, las divisiones proveen bloques de texto en la página
Web. Cada bloque se puede definir con una posición a partir de la esquina superior izquierda de la pantalla o
de un bloque más grande; además puede tener una anchura y una altura, así como un estilo de borde y un
color de fondo. Las divisiones eliminan la necesidad de colocar tablas dentro de otras tablas y simplifican el
diseño; el software de lectura de pantalla leerá todo el texto en la división para que los visitantes con
discapacidad visual puedan acceder al sitio.
7. Use la misma imagen gráfica en varias páginas Web. Mejorará la consistencia y las páginas cargarán con
más rapidez debido a que la computadora almacena la imagen en una caché y no tiene que volver a
cargarla.
8. Use JavaScript para mejorar la distribución de la página Web al hacer que las imágenes cambien cuando se
coloque el ratón encima de ellas o que se expandan los menús, por ejemplo. Podemos usar JavaScript para
volver a dar formato a la página Web con base en la altura y anchura de la pantalla. Si el sitio Web es
multinacional, JavaScript puede detectar el lenguaje que se esté usando (una configuración del navegador) y
redirigir al espectador a una versión de su página Web en otro idioma.
9. Evite el uso excesivo de las animaciones, sonidos y otros elementos relacionados.
Navegación ¿Es divertido para usted seguir los vínculos en la Web? La respuesta más probable es que depende
de ciertos factores. Cuando descubrimos un sitio Web que se carga fácilmente, tiene vínculos representativos
y nos permite regresar con facilidad a los lugares que queremos, entonces es probable que pensemos que es
divertido. La diversión no es sólo jugar; también puede ser una parte importante del trabajo. La investigación
reciente demuestra que la diversión puede tener un poderoso efecto en la efectividad de la capacitación por
computadora.
Por otro lado, si no puede decidir en cuál botón o punto activo de una imagen hacer clic y tiene miedo de
elegir el incorrecto porque podría terminar en la página equivocada que tarda mucho tiempo en cargar, entonces
la navegación es más desagradable que divertida. Un ejemplo es visitar la página de una compañía de software
para buscar información sobre las características de la versión más reciente de un producto. Usted tiene las op-
ciones tales como productos, descarga, FAQ y soporte técnico. ¿Qué botón lo llevará a las respuestas que busca?
www.xlibros.com
356 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 1 . 5
Un día en el campo
“tarioLdea cosa es que soy impaciente”, dice Seymour Fields, propie-
una cadena de 15 exitosas florerías/mercados florales en
general (como macetas, floreros, tarjetas y chucherías) almacenar
en cada punto de venta.
interiores de nombre Fields, que se encuentran en tres ciudades Seymour continúa: “Le puedo decir qué es lo que no nos gustó
del Medio Oeste. “¿Ve esto aquí?”, golpetea la pantalla de su PC sobre el programa con el que trabajé. Había que pasar por demasia-
con fastidio. “Llevamos la nómina y toda la contabilidad con estas das capas, demasiado follaje o como se llame. Incluso con una
cosas, pero no les doy el uso que debería darles. En realidad me pantalla frente a mí, era como cambiar páginas en un informe
siento un poco culpable sobre ello. ¿Ve?”, dice mientras hace una grueso. ¿Cómo se le dice a eso?”.
raya en la pantalla con su dedo. “Incluso tiene polvo. Pero soy “¿Menús?”, sugiere Potts para tratar de ayudar. “El punto
una persona práctica. Si está aquí ocupando espacio, quiero usarla. principal es que no le gustó tener que pasar por mucha información
U olerla, o por lo menos disfrutar al verla, como las flores, ¿no para llegar a la pantalla que necesitaba”.
cree usted? O sacarla de raíz. Es lo que digo. La única vez que Seymour Fields mira felizmente a Potts y dice: “Acertaste.
traté de hacer algo con ella fue un verdadero desastre. Bueno, Quiero ver más campos en cada pantalla”.
mire, le puedo mostrar si es que todavía recuerdo cómo hacerlo”. ¿Cómo debería diseñar Potts la salida de pantalla de manera
Seymour procede a tratar de ejecutar un programa, pero no puede que Fields y su grupo puedan obtener lo que desean en cada pan-
hacer que funcione. talla, cumpliendo a la vez con los lineamientos para el buen diseño
Clay Potts es un analista de sistemas que ha estado trabajando de pantallas? Recuerde que los miembros del grupo están ocupa-
en un proyecto de sistemas para toda la cadena Fields. Parte de la dos y utilizan la computadora con poca frecuencia. Diseñe una
propuesta original fue proveer a Seymour y sus vicepresidentes un página con hipervínculos que trabaje bien en un DSS para los vi-
sistema de soporte de decisiones en grupo que les ayudara a idear cepresidentes. ¿Qué debemos incluir en la primera pantalla y qué
una estrategia para determinar qué mercados europeos visitar para deberíamos almacenar en hipervínculos? Haga una lista de los
establecer contratos de compra de flores frescas, a qué puntos de elementos para cada opción y explique en un párrafo por qué de-
venta enviar ciertos tipos específicos de flores y cuánta mercancía cidió sobre esta estrategia.
Lo que es más importante, observe la regla de los tres clics. Los usuarios deben ser capaces de moverse
desde la página en la que se encuentran hacia la página que contiene la información que desean en tres clics del
botón del ratón.
Promoción Promueva su sitio. No suponga que los motores de búsqueda lo encontrarán de inmediato. Envíe su
sitio cada dos o tres meses a varios motores de búsqueda. Incluya palabras clave, conocidas como metaetiquetas,
que los motores de búsqueda utilizarán para vincular las peticiones de búsqueda a su sitio. En la página Web
searchenginewatch.com/showPage.html?page=2167931 encontrará información general sobre las metaetiquetas.
En www.siteup.com/meta.html podrá descargar un software generador de metaetiquetas gratuito y encontrará un
creador de metaetiquetas en vancouver-webpages.com/META/mk-metas.html. También puede comprar software
para facilitar este proceso. Si trata de usar correo electrónico para promover su sitio, otros lo considerarán correo
basura o spam.
Anime a sus lectores a marcar su sitio Web como sitio favorito. Si usted coloca vínculos y les sugiere que
vayan a sitios Web afiliados que tengan “la mejor página de reseñas de películas en el mundo” o el sitio Web
para “obtener música gratuita”, no de por sentado que regresarán a su sitio en un futuro cercano. La manera de
animar a sus visitantes a que vuelvan a visitar su sitio es que lo marquen como favorito (a los marcadores se les
llama “favoritos” en Microsoft Internet Explorer). Puede agregar el vínculo Haga clic aquí para marcar esta
página a su página Web para automatizar el proceso. Tal vez también quiera diseñar un “favicon” o icono favo-
rito, para que los usuarios puedan identificar su sitio en sus listas de favoritos.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 357
y las características interactivas. Los sistemas de administración de contenido (CMS) son potentes herramientas
de software que pueden permitir al analista desarrollar y dar mantenimiento a sitios Web y demás aplicaciones
en línea. Joomla! es un CMS cada vez más popular, que podrá bajar de www.joomla.org/about-joomla.html. Está
basado en PHP y MySQL. A diferencia de muchos CMS propietarios, que son costosos y no están disponibles
en muchas partes, Joomla! es una solución de código fuente abierto disponible en forma gratuita para cualquier
desarrollador.
www.xlibros.com
358 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 11.17
El software de transformación de
lenguaje de estilo extensible
(XSLT) se puede utilizar para
crear documentos de XML y
transformarlos en muchos Página Web
formatos distintos para una
variedad de plataformas.
<?xml version="1
.0"?>
<clientes> Salida de papel
<nombre>
<telefono>
</clientes>
Software XSLT
Documento de XML
<?xml version="1.0
"?>
<clientes>
<nombre>
<telefono>
</clientes>
mación, pero utiliza una serie de instrucciones para definir qué elementos se deben usar como salida, la secuencia
de orden, la selección de datos, etcétera. En la figura 11.18 se muestra un ejemplo de transformación de XML. El
XML se muestra a la izquierda y el resultado de la transformación se muestra a la derecha. Cabe mencionar que
sólo se incluyen en la salida los datos entre las etiquetas (los símbolos menor que [<] y mayor que [>]).
Ajax
Hay otra técnica conocida como Ajax que utiliza JavaScript y XML para obtener pequeñas cantidades de datos
(ya sea en texto simple o XML) de un servidor sin dejar la página Web. Ésta es una gran ventaja, ya que elimina
la necesidad de cargar toda la página Web completa. Funciona al permitir que la página Web se vuelva a dar for-
mato a sí misma con base en las opciones introducidas por el usuario. Como Ajax está también relacionado con
la entrada de los usuarios, en el capítulo 12 podrá consultar detalles adicionales.
En esta sección hablaremos sobre Ajax debido a que tiene implicaciones importantes también en el aspecto
de la salida. El analista y el diseñador deben determinar cuándo se deben agregar o modificar los datos en una
página Web; también deben identificar las condiciones que producen la modificación. El orden en que se hacen
las preguntas también es importante en este diseño.
En la figura 11.19 se muestra un ejemplo de una página Web que utiliza Ajax, la cual demuestra que Ajax
hace que sea posible mostrar mucho menos datos en una página, con lo cual la salida se vuelve menos desorde-
nada y confusa. En este ejemplo, el usuario introdujo una de las cuatro formas disponibles para reducir la bús-
queda y ver una lista de los clientes actuales. Las opciones que el usuario tenía disponibles eran: 1) introducir los
primeros tres dígitos de un código postal, 2) introducir un código de área telefónica, 3) seleccionar el estado o
4) seleccionar un país. Tal vez el usuario no conozca el código postal o de área y por lo tanto tenga que buscar
por estado o país, por lo que las opciones son muy útiles.
Después de introducir una de las opciones de ubicación, en este caso los primeros tres dígitos del código
postal, el usuario hizo clic en el botón Get Customers (obtener clientes). El valor del código postal se envía al
servidor junto con los datos que indican que era un código postal. Después el servidor busca todos los registros
de los clientes para la ubicación seleccionada, crea un documento de XML y lo envía a la misma página Web.
Al diseñar la salida, el analista de sistemas tiene muchas opciones relacionadas con la forma de mostrar es-
tos datos en la página Web. En este caso el analista especificó que se utilizaría el documento de XML para crear
una lista desplegable que contenga todos los clientes actuales para la ubicación deseada. Una vez que el usuario
selecciona un cliente de la lista desplegable aparece más información sobre ese cliente específico, como se mues-
tra en el ejemplo.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 359
FIGURA 11.18
<?xml version=“ Una transformación de XML, con
1.0” standalone=“
<?xml–stylesheet no”? > el XML a la izquierda y el
type=“text/xsl” hre
<clientes> f=“cust02.xsl” ?> Información d resultado de la transformación a la
<titulo>Informac
ión del cliente</tit
el cliente derecha. Sólo se incluyen en la
<cliente> ulo> Número:
09288 salida a la derecha los datos entre
<numero>09288 Primer nombr
</numero> e: George las etiquetas.
<nombre> Apellido pate
<apellidopaterno rno: Green
>Green</apellido Calle:
<primernombre>G paterno> 123 Oak Street
eorge</primernom Apartamento:
<inicial_segnom bre> Suite 16
>L</inicial_segno Ciudad:
</nombre> m>
Madison
<direccion> Estado:
WI
<calle> 123 Oak CP:
Street</calle> 53704
<apartamento>S País:
uite 16</apartame United States
<ciudad>Madiso nto>
n</ciudad> Saldo actual:
<estado>WI</es 123.45
tado>
<cp> 53704</cp> Número:
<pais>Estados Un 15008
idos</pais> Primer nombr
</direccion> e: Sally
<saldo_actual>1 Apellido pate
23.45</saldo_ac rno: Brown
</cliente> tual> Calle:
123 Elm Street
<cliente> Apartamento:
Apt. 1
<numero>15008 Ciudad:
</numero> Camden
<nombre> Estado:
<apellidopaterno NJ
>Brown</apellido CP:
<primernombre>S paterno> 08102
ally</primernom País:
<inicial_segnom bre> United States
>S</inicial_segno Saldo actual:
</nombre> m> 9,876.54
<direccion>
<calle> 123 Elm
Street</calle>
<apartamento>A
pt. 1</apartamen
<ciudad>Camde to>
n</ciudad>
<estado>NJ</es
tado>
<cp> 08102</cp>
<pais>Estados Un
idos</pais>
</direccion>
<saldo_actual>9
,876.54</saldo_a
</cliente> ctual>
</clientes>
FIGURA 11.19
Una página Web que utiliza Ajax
hace que sea posible mostrar
mucho menos datos en una página,
con lo cual se obtiene una pantalla
ordenada.
www.xlibros.com
360 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
EXPERIENCIA DE HYPERCASE® 11
“obtuvo
Yoendiríarelación
que la recepción que obtuvo, o más bien que su equipo
con la presentación de su propuesta fue bastante
2. Use un formulario en papel de diseño, Microsoft Visio o una
herramienta Case para diseñar un prototipo de una pantalla
cálida. ¿Qué le pareció conocer al Sr. Hyatt? ¿Qué? ¿No asistió? Oh de salida con base en los informes de la Unidad de
[riéndose], el es su propio jefe. De todas formas no me preocuparía capacitación que sintetizarán la siguiente información para
mucho por eso. Los informes que obtuve de Snowden fueron alen- Snowden:
tadores. De hecho, ahora él quiere ver algunos diseños preliminares Número de proyectos aceptados en la Unidad de
de todos ustedes. ¿Podrían tener algo en su escritorio o enviarlo capacitación.
como adjunto en un correo electrónico en dos semanas? Él estará en Número de proyectos que se están reevaluando.
un viaje de negocios en Singapur la próxima semana, pero cuando Áreas básicas de capacitación por las que se está solicitando
se recupere del desfase de horarios estará buscando esos diseños. un consultor.
Gracias”. 3. Diseñe una pantalla de salida adicional que usted crea que
apoyará a Snowden en el tipo de proceso de toma de
Preguntas de HYPERCASE decisiones que realiza con frecuencia.
4. Muestre sus diseños a tres de sus compañeros de clase.
1. Considere los informes de la Unidad de capacitación Obtenga retroalimentación por escrito de parte de ellos sobre
(Training Unit). ¿Cuáles son las quejas de Snowden sobre cómo mejorar las pantallas de salida que diseñó.
estos informes? Explique en un párrafo. 5. Rediseñe las pantallas para capturar las mejoras sugeridas
por sus compañeros de clase. Explique en un párrafo cómo
lidió con cada una de sus cuestiones.
FIGURA 11.HC1
Usted tiene la habilidad de ver y
criticar las pantallas de salida en
HyperCase.
La ventaja de usar Ajax para mostrar datos es que el usuario no tiene que esperar a que aparezca una nueva
página Web después de realizar una selección. La filosofía de Ajax es mostrar preguntas limitadas para que el
usuario las responda en forma incremental. Esto elimina el desorden en la pantalla. Una vez que el usuario res-
ponde a una pregunta al hacer una elección, se puede generar una nueva pregunta.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 361
rio, entregar la cantidad correcta de salida, entregarla en el sobre las posibilidades de predisposición en la salida, para
lugar correcto, proveer la salida a tiempo y elegir el método crear una salida flexible y con capacidad de modificación, y
correcto. para capacitar a los usuarios de manera que utilicen varias sa-
Es importante que el analista tenga en cuenta que el con- lidas para ayudar a verificar la precisión de cualquier informe
tenido de la salida está relacionado con el método de salida. específico.
La salida de distintas tecnologías afecta a los usuarios de di- Los informes impresos se diseñan mediante el uso de he-
ferentes formas. Las tecnologías de salida también difieren en rramientas de diseño de software asistido por computadora que
cuanto a su velocidad, costo, portabilidad, flexibilidad, accesi- cuentan con plantillas de diseño e interfaces tipo “arrastrar y
bilidad y posibilidades de almacenamiento y recuperación. Hay soltar”. El diccionario de datos sirve como la fuente de los da-
que considerar todos estos factores al decidir entre la salida tos necesarios en cada informe.
impresa, de pantalla, de audio, electrónica o basada en Web, o Es importante diseñar la salida para las pantallas de los
una combinación de éstas. usuarios, en especial para DSS y Web. La estética y la utili-
La presentación de la salida puede predisponer a los usua- dad son imprescindibles al crear una salida bien diseñada para
rios a la hora de interpretarla. Los analistas y los usuarios las pantallas. Es importante producir prototipos de pantallas
deben estar conscientes de las fuentes de predisposición. Es y documentos Web que animen a los usuarios a interactuar
conveniente que los analistas interactúen con los usuarios para con estos prototipos y realizar las modificaciones cuando se
diseñar y personalizar la salida, para informar a los usuarios desee.
PREGUNTAS DE REPASO
1. Mencione los seis objetivos que el analista persigue al diseñar la salida de un sistema.
2. Compare las salidas externas con las salidas internas producidas por el sistema. Recuerde que debe considerar las
diferencias en los usuarios externos e internos.
3. ¿Cuáles son tres situaciones que señalan a las impresoras como la mejor opción de tecnología de salida?
4. Mencione dos ejemplos en los que la salida de pantalla sea la mejor solución como opción de método de salida.
5. Mencione los métodos potenciales de salida electrónica para los usuarios.
6. ¿Cuáles son las desventajas de la salida electrónica y basada en Web?
7. Mencione diez factores a considerar al elegir la tecnología de salida.
8. ¿Qué tipo de salida es mejor si las actualizaciones frecuentes son una necesidad?
9. ¿Qué tipo de salida es deseable si muchos lectores van a leer, almacenar y revisar la salida durante cierto número de
años?
10. ¿Cuáles son las desventajas de la salida de audio?
11. Mencione tres formas en que las presentaciones de la salida se predisponen en forma no intencional.
12. ¿Cuáles son cinco formas en que el analista puede evitar la predisposición en la salida?
13. ¿Cuál es la diferencia entre la información constante y variable que se presenta en un informe?
14. ¿Por qué es importante mostrar a los usuarios un prototipo de un informe o una pantalla de salida?
15. Mencione seis elementos funcionales de los informes impresos.
16. Mencione cinco elementos estilísticos o estéticos de los informes impresos.
17. ¿En qué formas difieren las pantallas, la salida impresa y los documentos basados en Web?
18. Mencione cuatro lineamientos para facilitar el diseño de una buena salida de pantalla.
www.xlibros.com
362 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
19. ¿Qué diferencias hay entre la salida para un DSS y la salida para un MIS más tradicional?
20. ¿Cuáles son las cuatro consideraciones primarias que tiene el analista al diseñar la salida gráfica para los sistemas de
soporte de decisiones?
21. Defina el concepto de pegajosidad.
22. Mencione siete lineamientos para crear buenos sitios Web.
23. Mencione cinco lineamientos para usar gráficos al diseñar sitios Web.
24. Mencione siete ideas para mejorar la presentación de los sitios Web corporativos que diseñe.
25. ¿Cuál es la regla de los “tres clics”?
26. ¿En qué formas puede animar a las empresas a promover sus sitios Web que usted desarrolló?
27. ¿Cómo una hoja de estilo en cascada permite que el analista produzca la salida?
28. ¿Cuáles son las ventajas de usar XSLT en vez de una hoja de estilo en cascada?
29. ¿Qué son fuentes RSS?
30. ¿Cómo puede el administrador Web usar fuentes RSS?
31. ¿Cuál es el principal uso de los tableros de control?
32. ¿Qué son los widgets (o gadgets)?
33. ¿Por qué debe un diseñador de sistemas estar consciente de la popularidad de los widgets (o gadgets)?
34. ¿Cómo permite una hoja de estilo en cascada que el analista produzca la salida?
35. ¿Cuáles son las ventajas de usar una transformación de lenguaje de estilo extensible en vez de una hoja de estilo en
cascada?
36. ¿Cómo ayuda Ajax a construir páginas Web efectivas?
PROBLEMAS
1. “Estoy seguro de que no les importará si empezamos a enviar el informe en estas hojas de computadora extra grandes.
Todo este tiempo lo condensamos, reformulamos y lo enviamos a nuestras cuentas más grandes, pero ahora no podemos.
Hay tan poco personal que no tenemos el tiempo”, dice Otto Breth. “Voy a escribir un comentario aquí para decirles
cómo responder a este informe y así podremos enviarlo”.
a. ¿Qué problemas potenciales puede ver al cambiar la salida externa casualmente? Haga una lista.
b. Describa en un párrafo cómo pueden diferir las salidas externa e interna en cuanto a función y apariencia.
2. “No necesito verla muy seguido, pero cuando llega el momento tengo que poder revisarla rápidamente. Creo que
perdimos el último contrato debido a que la información que necesitaba estaba enterrada en una torre de papel en el
escritorio de alguien”, dice Luke Alover, un arquitecto que describe los problemas de la empresa a uno de los analistas
asignados al nuevo proyecto de sistemas. “Lo que necesito es información al instante sobre el costo que tenía un edificio
de esa medida en pies cuadrados la última vez que ofertamos; cuánto cuestan los materiales básicos como acero, vidrio y
concreto con nuestros tres principales proveedores; quién podría ser nuestra competencia en este tipo de construcción y
quién pertenece al comité que tomará la decisión final sobre quién ganó la subasta. Justo ahora, esta información se
encuentra en cien informes en alguna parte. Tengo que buscar en todos lados estos informes”.
a. Dados los detalles limitados que tenemos aquí, escriba un párrafo para sugerir un método de salida que Luke pueda
usar para resolver algunos de sus problemas actuales. Explique en un segundo párrafo sus razones para elegir el
método de salida que eligió (sugerencia: asegúrese de relacionar el método de salida con el contenido de la salida en
su respuesta).
b. El pensamiento actual de Luke es que no se debe mantener ningún registro en papel de la salida en cuestión.
Describa en un párrafo sobre los factores a sopesar antes de utilizar la salida de pantalla en vez de los informes
impresos.
c. Haga una lista de cinco a siete preguntas que usted haría en relación con la función de la salida en la organización a
Luke y a los demás antes de decidir deshacerse de cualquier informe impreso que se utilice en ese momento.
3. He aquí varias situaciones que requieren decisiones sobre el contenido de la salida, la metodología de salida, la
distribución, etcétera. Para cada situación observe la decisión de salida apropiada.
a. Un proveedor grande con buena reputación de materia prima clave para el proceso de producción de la empresa para
la que usted trabaja requiere un informe sintetizado de fin de año sobre los totales comprados a ese proveedor.
b. Se envían al personal memos internos sobre una lluvia de ideas en relación con los planes para un día de campo de
la empresa y la recaudación de fondos.
c. Un encargado de tomar decisiones clave necesita un informe sintetizado de la situación financiera de la empresa
para presentar una propuesta a los potenciales patrocinadores externos.
d. El personal de recepción requiere un listado de las reservaciones de cuartos de hotel de esta noche.
e. La policía local necesita un listado de las reservaciones de cuartos de hotel de esta noche.
f. Las patrullas de los estacionamientos utilizarán un conteo real de las personas que pasan por las puertas de Wallaby
World (un parque de diversiones australiano).
g. Un sistema de inventario debe registrar un artículo cada vez que se escanea mediante un lápiz óptico.
h. Veintidós supervisores utilizarán un informe sintetizado de los aumentos de salario por méritos asignados a cada uno
de los 120 empleados durante una reunión de supervisores; también utilizarán este informe para explicar los
aumentos en los sueldos por méritos a los empleados de los departamentos de cada supervisor.
i. Tres planeadores estratégicos en la organización requieren información competitiva, pero debe considerarse que
incluiría información delicada, en el caso que sea posible una divulgación más amplia.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 363
j. Se requiere un estilo casual de conversación para informar a los clientes sobre las características potentes pero raras
veces utilizadas de un producto.
k. Un distrito histórico de cierta ciudad desea informar a sus visitantes sobre los edificios y eventos históricos.
l. Hay que entregar advertencias sobre tormentas a los suscriptores en un área geográficamente extensa.
4. “Creo que ahora sé cuál era la intención de esa persona, pero me engañó por un instante”, dice la Srita. deLimit.
Ella está hablando sobre un prototipo de salida de pantalla diseñado por el analista de sistemas con el que habló
hace unos momentos. “Es decir, nunca consideré que fuera un problema el hecho de que no poder ajustar en una
clase ni el 20 por ciento del cupo total”, dice. “Sabemos que nuestras clases tienen buena demanda, pero como no
podemos contratar más maestros para cubrir las áreas que necesitamos, tuvimos que hacer ajustes en la demanda de
estudiantes. Él resaltó como problema el hecho de que sólo el 5 por ciento de los estudiantes que deseen tomar una
clase no puedan entrar, pero está bien. Ahora que sé lo que significa, sólo ignoraré a la computadora cuando emita
un sonido”.
a. Describa en uno o dos enunciados el problema al que se enfrenta la Srita. deLimit con la salida de pantalla.
b. ¿Es acaso su solución de “ignorar los sonidos” razonable, dado que la salida se encuentra en la etapa de prototipo?
c. Explique en un párrafo cómo se puede modificar la salida de pantalla para este problema específico, de manera que
refleje mejor las reglas del sistema que utiliza la Srita. deLimit.
5. La siguiente es una hoja de registro para un sistema de información de pacientes utilizado por las enfermeras de un
sanatorio para registrar los visitantes de los pacientes y las actividades durante sus turnos. Diseñe un informe impreso
mediante el uso de software de diseño de formularios que proporcione un resumen para la enfermera a cargo de cada
turno y un informe para el coordinador de actividades al final de una semana. Asegúrese de utilizar las convenciones
apropiadas para indicar los datos constantes, los datos variables y otros. Estos informes se utilizarán para determinar los
patrones de dotación de personal y los ofrecimientos de actividades a futuro.
6. Diseñe la salida de pantalla para el problema 5 mediante el uso de software de diseño de formularios. Haga todas las
suposiciones necesarias sobre la capacidad necesaria del sistema y siga las convenciones de diseño de pantallas para las
instrucciones en pantalla (Sugerencia: Puede usar más de una pantalla si lo desea.).
a. Describa en un párrafo por qué diseñó cada informe como lo hizo en los problemas 5 y 6. ¿Cuáles son las
principales diferencias en su metodología en cada problema? ¿Es posible trasplantar con éxito los informes impresos
a las pantallas sin necesidad de modificaciones? ¿Por qué sí o por qué no?
b. Algunas de las enfermeras están interesadas en un sistema basado en Web al que las familias de los pacientes puedan
acceder desde su hogar con una contraseña. Diseñe una salida de pantalla para Web. Describa en un párrafo cómo
tuvo que alterar su informe para que lo pudiera ver la familia de un paciente.
7. Clancy Corporation fabrica uniformes para los departamentos de policía a nivel mundial. Muchos grupos seleccionan
sus uniformes debido a su bajo costo y a su diseño simple pero digno. Usted va a ayudar a diseñar un DSS para Clancy
Corporation, quienes han solicitado una salida en formato tabular que les ayude a tomar varias decisiones en cuanto a los
diseñadores que deben usar, dónde comercializar sus uniformes y qué cambios hacer en los uniformes para que
conserven una apariencia actualizada. La siguiente tabla enlista algunos de los datos que la compañía desearía ver en
tablas, incluyendo los nombres de los estilos de uniformes, un ejemplo de un grupo comprador para cada estilo y los
diseñadores a cargo de los estilos de uniformes. Prepare un ejemplo de salida en formato tabular para pantalla que
incorpore estos datos sobre Clancy. Siga las convenciones apropiadas para las pantallas de salida en formato tabular. Use
códigos y una clave en donde sea apropiado.
www.xlibros.com
364 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
8. A los de Clancy les interesa una salida gráfica para su DSS. Desean ver una comparación gráfica de la cantidad de
uniformes de cada estilo que se venden al año.
a. Seleccione un estilo de gráfico apropiado y diseñe un gráfico para la pantalla de salida que incorpore los siguientes
datos:
Militar completo
(porcentaje del total) Semi militar Formal Casual
2005 50 20 20 10
2006 55 15 20 10
2007 60 15 15 10
2008 62 15 15 8
2009 65 10 15 10
Asegúrese de seguir las convenciones de diseño apropiadas para las pantallas. Use códigos y una clave si es
necesario.
b. Seleccione un segundo método para graficar que permita a los encargados de tomar decisiones de Clancy ver una
tendencia en la compra de ciertos estilos de uniformes específicos a través del tiempo. Dibuje una gráfica para
visualización como parte de la salida del DSS de Clancy. Asegúrese de seguir las convenciones de diseño apropiadas
para las pantallas. Use códigos y una clave si es necesario.
c. Describa en un párrafo las diferencias en los dos gráficos en pantalla que seleccionó. Defienda sus elecciones.
9. Michael Cerveris es propietario de varios autos de carreras. ¿Qué medidas de desempeño necesita desarrollar para llevar
registro del desempeño de su conductor, los mecánicos de pit y el personal de soporte (sin mencionar el gasto de las
llantas)?
10. Diseñe un tablero de control de DSS para Michael (problema 9). Use los tipos de diagramas y gráficos apropiados para
ilustrar el desempeño.
11. Diseñe un tablero de control para llevar el registro de las acciones y la cartera de clientes de una persona. Piense cómo
podría utilizar el tablero de control para tomar decisiones sobre comprar y vender acciones. Recuerde que un cliente
puede tener más de un corredor de bolsa.
12. Gabriel Shanks opera una compañía teatral sin fines de lucro que produce siete obras por año en tres teatros. Cada obra
dura ocho semanas, pero se puede extender cuatro semanas más si resulta un éxito. Diseñe un tablero de control para
Gabriel; tome en cuenta las distintas fases del montaje, así como la necesidad de vender todos los boletos que sea
posible. No olvide que Gabriel está involucrado en el teatro, es muy visual y no le gustan las tablas.
13. Mientras Gabriel (del problema anterior) se hace cargo de varios detalles durante un día ordinario, le gustaría estar al
tanto de las noticias de teatro en Manhattan y tener al mismo tiempo algunas herramientas simples a la mano para
ayudarle con sus actividades relacionadas con la computadora. ¿Qué tipo de widgets y gadgets necesitaría Gabriel para
hacer su trabajo y tener al mismo tiempo algunas herramientas simples basadas en computadora siempre disponibles?
14. Explore la Web para ver todos los sitios Web que estén mal y bien diseñados. Seleccione tres ejemplos de cada uno.
Comente sobre lo que hace que los sitios sean excelentes o malos; use el formulario de crítica que presentamos antes en
el capítulo para compararlos y contrastarlos.
15. Proponga un sitio Web para Clancy’s, la empresa de uniformes que describimos en los problemas 7 y 8. Haga un
bosquejo a mano o use software de diseño de formularios para crear un prototipo de la página de inicio de Clancy’s.
Indique los hipervínculos e incluya un bosquejo de un documento de hipervínculo. Recuerde incluir gráficos, iconos e
incluso sonido u otro tipo de medio apropiado. Describa en un párrafo quiénes son los usuarios previstos para el sitio
Web y por qué es conveniente que Clancy’s cuente con una presencia Web.
16. Las tiendas departamentales Elonzo’s son una cadena de aproximadamente 50 tiendas de ventas al detalle, las cuales se
especializan en artículos de cocina, baño y otros enseres domésticos, incluyendo muchos artículos decorativos y de
moda. Hace poco Elonzo’s decidió automatizar su registro de regalos para permitir que los invitados a las bodas y otros
eventos puedan ver los artículos seleccionados por los novios u otras personas.
a. Diseñe una página Web que permita a los clientes introducir un código postal y buscar la tienda más cercana.
b. Diseñe una página Web para que los clientes vean los regalos y puedan pedirlos en línea. No incluya los formularios
reales para los pedidos, sólo los productos. ¿Qué tipo de opciones estarían disponibles para los clientes? Incluya
botones o vínculos para cambiar la secuencia de orden en su diseño.
c. Diseñe una lista impresa que los clientes puedan solicitar cuando vayan a una de las tiendas. ¿Cuáles serían las
secuencias óptimas para un cliente que trata de buscar artículos? ¿Se incluirían todos los elementos solicitados por
los novios en la lista? (Sugerencia: tal vez ya se hayan comprado algunos.).
17. Diseñe el esquema de un podcast para alguien que pasea por su universidad, colegio o empresa. ¿En qué secuencia
colocaría los temas? ¿Cuánto tiempo asignaría para cada campus o ubicación? Suponga que el grupo llegará en la
mañana y tome en cuenta el almuerzo en el podcast.
18. Diseñe una pantalla de recordatorio de vuelos para un teléfono inteligente u otro dispositivo portátil.
19. Diseñe un estilo Ajax de página Web que permita al decano de un colegio comunitario seleccionar instructores
de medio tiempo. El decano debe ser capaz de seleccionar una disciplina o curso y hacer que el servidor envíe un
documento de XML que contenga todos los instructores potenciales de medio tiempo para la selección. Hay que usar
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 365
el documento de XML para llenar una lista desplegable con los nombres de los instructores. Al hacer clic en el nombre
de un instructor debe aparecer información sobre ese instructor potencial. Decida qué información debe incluir para
ayudar al decano a tomar una decisión sobre el instructor que debe contratar (Sugerencia: Tal vez los instructores de
medio tiempo puedan enseñar sólo en ciertos días o sólo en la mañana, tarde o noche.).
PROYECTOS EN GRUPO
1. Haga una sesión de lluvia de ideas con los miembros de su equipo sobre los tipos de salida más apropiados para una
variedad de ejecutivos y gerentes de alto nivel de Dizzyland, un gran parque de diversiones en Florida. Incluya una lista
de entornos o situaciones de toma de decisiones y los tipos de salida. Describa en un párrafo por qué el grupo sugirió
opciones específicas para la salida.
2. Haga que cada miembro del grupo diseñe una pantalla o formulario de salida para las situaciones de salida que enlistó en
el proyecto en grupo 1 (use Microsoft Visio, una herramienta CASE o un formulario de diseño en papel para completar
cada pantalla o formulario).
3. Cree un tablero de control para los gerentes de Dizzyland del proyecto en grupo 1.
4. Diseñe un sitio Web, ya sea en papel o mediante el uso de software con el que esté familiarizado, para Dizzyland del
proyecto en grupo 1. Aunque puede bosquejar en papel los documentos o gráficos para tres niveles de páginas y los
hipervínculos requeridos, cree el prototipo de una página de inicio para Dizzyland; indique los hipervínculos en donde
sea apropiado. Obtenga retroalimentación de otros grupos en su clase y modifique su diseño de manera acorde. Describa
en un párrafo cómo es que diseñar un sitio Web difiere del diseño de pantallas para otros sistemas en línea.
5. Explore el sitio Web de Joomla! En www.joomla.org. ¿Cómo podría esta aplicación de código fuente abierto ayudarle a
implementar sus diseños del problema 4? Sintetice sus hallazgos en un párrafo. Use la Web para buscar otro CMS y
utilice un párrafo para compararlo con Joomla! Asegúrese de incluir el costo, la facilidad de uso, el soporte y la
disponibilidad en su comparación.
6. Use la lluvia de ideas para desarrollar un nuevo conjunto de widgets (gadgets) para aumentar la productividad. Haga una
lista con las cinco mejores ideas para nuevos wigdets.
BIBLIOGRAFÍA SELECCIONADA
Davenport, T. H. “Saving IT’s Soul: Human-Centered Information Management”. Harvard Business Review, marzo-abril 1994,
pp. 119-131.
Davis, G. B. y H. M. Olson. Management Information Systems, Conceptual Foundations, Structure, and Development, 2ª. Edi-
ción. Nueva York: McGraw-Hill, 1985.
Kendall, K. E. y J. E. Kendall. “DSS Systems Analysis and Design: The Role of the Analyst as Change Agent from Early DSS
to Mashups”, en Handbook of Decision Support Systems 2, editado por F. Burstein y C. W. Holsapple, pp. 293-312. Berlin:
Springer, 2008.
Souders, S. “High Performance Web Sites”. Communications of the ACM, Vol. 51, Núm. 12, diciembre de 2008, pp. 36-41.
www.xlibros.com
366 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
EPISODIO 11
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
FIGURA E11.1
Salida de ejemplo del INFORME
DE INVERSIÓN DE
1/04/2010
HARDWARE (HARDWARE Informe de inversión de
Nombre de marca hardware
INVESTMENT REPORT). Modelo Página 1 de 1
Número
Total
Xxxxxxxxxxxx de máquinas
Xxxxxxxxxxxxxxxxxx invertido
3 $29,997.00
Subtotal de marca
3 $29,997.00
Xxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxx 4 $39,996.00
Xxxxxxxxxxxxxxxxxx
2 $19,998.00
Subtotal de marca
6 $59,994.00
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx 3 $29,997.00
Xxxxxxxxxxxxxxxxxxxx
11 $82,992.00
Subtotal de marca
14 $112,989.00
Total general
23 $202,980.00
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 367
Chip regresa a su computadora y realiza los cambios necesarios. En la figura E11.1 se muestra el ejemplo final del IN-
FORME DE INVERSIÓN DE HARDWARE (HARDWARE INVESTMENT REPORT). Paige revisa de nuevo esta versión y
firma en el diseño para indicar que está completo.
La lógica para este informe sintetizado se describe en una especificación de proceso. La tabla COMPUTER (COMPUTADORA)
se ordena por MODELO (MODEL) dentro de MARCA (BRAND). Los totales se acumulan para cada MARCA y MODELO. Cuando
cambia la MARCA o el MODELO, se imprime una línea en el informe. Cuando ocurre un cambio en la MARCA, se imprimen los
SUBTOTALES DE MARCA (BRAND SUBTOTALS). Los TOTALES DE MARCA (GRAND TOTALS) se imprimen después de
procesar todos los registros.
Anna pasa cierto tiempo hablando con Cher Ware sobre sus necesidades de informes. Se describen varios informes impresos cuando
Cher hace la pregunta: “¿Recibiré informes en línea que pueda ver rápidamente y que contengan la información más reciente?”.
La discusión que le sigue a la pregunta genera la creación de varias consultas.
¿Cómo le gustaría ver las categorías de software?” pregunta Anna. “¿Le gustaría ver todo el software en una sola pantalla
extensa desplazable?”.
“Bueno, me gustaría tener alguna manera de buscar una categoría y después mostrar todo el software disponible para esa
categoría”, responde Cher. “También sería útil poder pasar a la categoría anterior y la siguiente”.
Anna crea la pantalla SOFTWARE POR CATEGORÍA (SOFTWARE BY CATEGORY) mediante un formulario de Mi-
crosoft Access, el cual se muestra en la figura E11.2. Hay un botón para buscar registros, así como botones para pasar a las
categorías anterior y siguiente. En el área inferior de la pantalla hay un área para mostrar los diversos paquetes de software para
la categoría. El campo SISTEMA OPERATIVO (OPERATING SYSTEM) se almacena como un código en la correspondiente
tabla de la base de datos y se convierte en la descripción del código en la pantalla.
Anna muestra a Chip y a Cher la pantalla completa. “Estoy impresionada”, exclama Cher. “¡Es exactamente lo que necesito!”
En ese momento entra Hy Perteks. “¿Qué está pasando?”, pregunta. Después de ver la consulta, comenta: “Me gustaría
que desarrollaran algunas páginas Web para las clases de capacitación”.
¿Qué tiene en mente?”, pregunta Chip.
“Bueno, he estado pensándolo”, le responde Hy. “Imagino que sería útil para los maestros y el personal poder buscar la
información sobre los cursos de software que planeamos ofrecer. Después podríamos agregar un formulario Web para que se
inscribieran en los cursos”.
“Sería divertido trabajar en eso”, comenta Chip. “Podríamos crear un vínculo a la página desde nuestros menús de Soporte
de tecnología (Technology Support)”.
“Yo también quiero participar”, responde Anna. “¿Qué le gustaría en la página?”.
“Me gustaría crear una página Web que muestre una lista de lo cursos, incluyendo el nivel, como principiante o intermedio,
y las fechas de inicio de cada curso”, le responde Hy.
Chip y Anna se ponen a trabajar en la página Web. Los campos se identifican y se agrupan en el flujo de datos CLASES
DE CAPACITACIÓN QUE SE OFRECEN (TRAINING CLASSES OFFERED), el cual se muestra en la pantalla de Visible
Analyst de la figura E11.3. Observe que se incluye la dirección Web como alias. Anna crea la página Web de intranet final, que
se muestra en la figura E11.4. Chip y Hy revisan la página.
“Me gustan los menús en la parte superior de la página y el submenú que se despliega debajo de ese menú al pasarle el
ratón por encima, para desplegar más opciones del menú”, comenta Chip.
“El calendario es muy útil para que el personal vea los cursos que están programados por fecha, con botones para cambiar
el mes y el año”, comenta Hy. “Es muy conveniente que cambien los cursos en forma dinámica cuando cambia el mes, día o
año. El usuario tendrá una experiencia sin complicaciones”.
FIGURA E11.2
Pantalla SOFTWARE POR
CATEGORÍA (SOFTWARE BY
CATEGORY) de Microsoft
Access.
www.xlibros.com
368 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA E11.3
Pantalla del flujo de datos
CLASES DE CAPACITACIÓN
Clases de capacitación que se ofrecen
QUE SE OFRECEN (TRAINING
CLASSES OFFERED).
Una página de intranet que indica las próximas clases de capacitación a
ofrecer por medio del Centro de información. Mostrar todas las clases para
cada paquete de software.
Titulo +
Version +
Nombre sistema operativo +
{Nombre clase} +
{Duracion clase} +
{Fecha inicial}
“Sí, y creo que también es muy bueno permitir al personal modificar la forma en que aparecen los datos. A muchos miem-
bros del personal les gusta ver los cursos que se ofrecen en su campus”, comenta Chip.
“Agregaríamos algo de distinción si incluyéramos una imagen de la mascota”, comenta Hy, “y el lema de la universi-
dad”.
“Me pondré a trabajar en ello”, responde Anna. “Realmente son buenas sugerencias”.
Después de un tiempo, terminan la página Web final y Hy la aprueba.
“Voy a enviar un email a todos los maestros y el personal, junto con un vínculo sobre nuestra ‘Nueva y mejorada’ página
Web”, comenta Hy. “Gracias por incluir mi dirección de correo electrónico. Será de utilidad para facilitar el proceso de registro
para los cursos y contestar cualquier pregunta. ¡Creo que realmente estamos progresando!”.
Para realizar los siguientes ejercicios, puede diseñar el informe o pantalla mediante formularios de diseño, o crearlos a
través de cualquier procesador de palabras con el que esté familiarizado. Los campos y demás información relacionada con los
informes se incluyen en las entradas del repositorio de flujo de datos de Visible Analyst o en una página Web que contiene una
copia del repositorio. La página Web contiene vínculos a los demás elementos en el repositorio para facilitar el proceso de ver
una entrada del repositorio y saltar hacia otra entrada para atrás o para adelante. En cada ejercicio se enlistan los nombres para
el flujo de datos.
FIGURA E11.4
Una página Web habilitada con
Ajax para la Central Pacific
University.
www.xlibros.com
CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 369
Se crearon los informes y formularios en Microsoft Access correspondientes. Toda la información está presente en la base
de datos de Microsoft Access; usted sólo tiene que modificar los informes y pantallas existentes para producir las versiones
finales. Para hacer las modificaciones, haga clic en el informe o pantalla deseada y después haga clic en el botón Design (Di-
seño). Puede realizar las siguientes modificaciones. El Page Header (Encabezado de página) contiene los encabezados de las
columnas. El área Detail (Detalle) contiene los campos a imprimir para el informe.
Haga clic en un campo para seleccionarlo. Haga clic en varios campos mientras oprime la tecla Mayús para
seleccionarlos.
Arrastre un campo (o campos) seleccionado para moverlo.
Haga clic en una de las cajas pequeñas que rodean el campo para cambiar su tamaño.
Seleccione varios campos, haga clic en Format (Formato) y después en una de los siguientes opciones:
Align (Alinear), para alinear todos los campos con el campo superior, izquierdo, etc.
Size (Ajustar tamaño), para hacer todos los campos iguales al campo más ancho, más alto, etcétera.
Horizontal Spacing (Espacio horizontal), para hacer el espacio horizontal igual, aumentarlo o reducirlo.
Vertical Spacing (Espacio vertical), para hacer el espacio vertical igual, aumentarlo o reducirlo.
EJERCICIOS
E-1. Use Microsoft Access para ver el INFORME DE INVERSIÓN DE HARDWARE (HARDWARE INVESTMENT RE-
PORT). Si está familiarizado con Microsoft Access, utilice la opción de menú File/Export… (Archivo/Exportar…)
para guardar el informe como página Web. Cuando se abra el cuadro de diálogo Export (Exportar), haga clic en la lista
desplegable Save As Type (Guardar como) y seleccione HTML Documents (Documentos HTML).
E-2. Chip, Dot y Mike participaron en varias sesiones de lluvias de ideas que produjeron como resultado los esquemas de
varios informes. Diseñe (o modifique mediante Access) el INFORME MAESTRO DE HARDWARE (HARDWARE
MASTER REPORT). Este informe es extenso, por lo que tendrá que ser cuidadoso para incluir todos los datos en el área
del informe. Tal vez quiera tener varias líneas de detalles para cada registro. Imprima el informe completo.
E-3. Después de reunirse con Cher Ware y Hy Perteks para hablar sobre las necesidades de los informes, Anna identificó los
campos para el INFORME DE NUEVO SOFTWARE INSTALADO (NEW SOFTWARE INSTALLED REPORT) par-
cialmente completo. Diseñe (o modifique) el informe para incluir los elementos encontrados en la entrada en el reposi-
torio de flujo de datos. ¿Es el informe detallado o sintetizado? Describa en un párrafo la lógica que usted cree que debe
usar el programa para producir informes.
E-4. Tanto Dot como Mike necesitan saber cuando se reciban nuevas computadoras. Cree el INFORME DE RECEPCIÓN DE
NUEVAS COMPUTADORAS (NEW COMPUTER RECEIVED REPORT). El flujo de datos INFORME DE COMPU-
TADORAS RECIBIDAS (COMPUTER RECEIVED REPORT) contiene los elementos necesarios.
E-5. Diseñe el INFORME MAESTRO DE SOFTWARE (SOFTWARE MASTER REPORT) que contiene información perti-
nente para ayudar a Cher y a Hy a localizar las diversas copias de cualquier paquete de software con facilidad. Los ele-
mentos necesarios para producir el informe se encuentran en el flujo de datos del INFORME MAESTRO DE SOFTWARE
(SOFTWARE MASTER REPORT).
Hay que imprimir en grupo los elementos TÍTULO (TITLE), VERSIÓN (VERSION), NOMBRE DEL SISTEMA
OPERATIVO (OPERATING SYSTEM NAME), EDITOR (PUBLISHER), CATEGORÍA (CATEGORY), PRIMER
NOMBRE (FIRST NAME) y APELLIDO PATERNO (LAST NAME) del experto de software. Se deben incluir totales
para cada combinación de TÍTULO/SISTEMA OPERATIVO/VERSIÓN. Imprima el diseño del informe completo.
E-6. Diseñe el LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING) que muestre las
computadoras disponibles en cada sala de cada campus. El campo CAMPUS deberá ser la DESCRIPCIÓN DEL CAM-
PUS (CAMPUS DESCRIPTION) y no el código que representa al campus.
E-7. Diseñe el INFORME DE COMPUTADORAS INSTALADAS (COMPUTER INSTALLED REPORT) que muestre las
computadoras personales instaladas en cada sala. Use la DESCRIPCIÓN DEL CAMPUS e imprima por grupos en base
a DESCRIPCIÓN DEL CAMPUS y UBICACIÓN DE SALA (ROOM LOCATION).
E-8. Use Microsoft Access para ver el informe de pantalla SOFTWARE POR CATEGORÍA (SOFTWARE BY CATEGORY).
Haga clic en el botón Find (Buscar) y localice CASE toolset (Conjunto de herramientas CASE). Haga clic en los
botones Next (Siguiente) y Previous (Anterior) para ver los elementos siguiente y anterior de Software Categories
(Categorías de software).
E-9. Diseñe el informe de pantalla SOFTWARE POR MÁQUINA (SOFTWARE BY MACHINE). Consulte los elementos en
la entrada en el repositorio de flujo de datos.
E-10. Diseñe el INFORME DE PROBLEMAS DE COMPUTADORAS (COMPUTER PROBLEM REPORT). Este informe
muestra todas las computadoras que tienen una gran cantidad de reparaciones o un costo extenso de reparación. Consulte
los elementos en la descripción del repositorio para el flujo de datos o modifique el informe de Microsoft Access.
E-11. Diseñe o modifique el INFORME DE INSTALACIÓN (INSTALLATION REPORT). Consulte los elementos en la en-
trada del repositorio para el flujo de datos. Este informe muestra las computadoras que se recibieron hace poco y que
están disponibles para la instalación.
www.xlibros.com
370 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
E-12. Diseñe el INFORME DE NUEVAS COMPUTADORAS QUE SE RECIBIERON (NEW COMPUTER RECEIVED
REPORT). Consulte los elementos en la descripción en el repositorio para el flujo de datos o modifique el informe de
Microsoft Access. Este informe sintetizado muestra el número de computadoras de cada marca y modelo. Hay que des-
empacar estas computadoras para instalarlas en las salas.
E-13. Diseñe o modifique el INFORME DE MANTENIMIENTO PREVENTIVO (PREVENTIVE MAINTENANCE RE-
PORT). Consulte los elementos en la entrada del repositorio para el flujo de datos. Este informe muestra las computado-
ras que necesitan mantenimiento preventivo.
E-14. Diseñe el INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS REFERENCE RE-
PORT). Consulte los elementos en la descripción en el repositorio para el flujo de datos o modifique el informe de Mi-
crosoft Access. Este informe muestra la computadora en la que está instalado cada paquete de software. Se imprimen en
grupo los elementos TÍTULO (TITLE), VERSIÓN (VERSION), SIGNIFICADO DE SISTEMA OPERATIVO (OPE-
RATING SYSTEM MEANING) y EDITOR (PUBLISHER). Las líneas de detalle bajo el grupo contienen datos que
muestran la máquina, campus de instalación y sala.
E-15. Diseñe o modifique el INFORME DE PEDIDOS PENDIENTES DE COMPRAS DE COMPUTADORAS (OUTSTAN-
DING COMPUTER PURCHASE ORDERS REPORT). Consulte los elementos en la entrada del repositorio para el flujo
de datos. Este informe se debe producir para todos los registros ORDEN DE COMPRA (PURCHASE ORDER) que
tengan un código de orden de compra de M101, el cual representa a las computadoras, con la condición adicional de que
la CANTIDAD ORDENADA (QUANTITY ORDERED) en el registro debe ser mayor que la CANTIDAD RECIBIDA
(QUANTITY RECEIVED). Indique en un párrafo si este informe es sintetizado, por excepción o detallado y explique el
por qué.
E-16. Diseñe el INFORME DE INVERSIÓN DE SOFTWARE (SOFTWARE INVESTMENT REPORT). Consulte los ele-
mentos en la descripción en el repositorio para el flujo de datos o modifique el informe de Microsoft Access.
E-17. Diseñe la página Web REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS REFERENCE). Consulte
los elementos de la página Web en la descripción en el repositorio de software para el flujo de datos del INFORME DE
REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS REFERENCE REPORT). Esta página Web
muestra las computadoras en las que está instalado cada paquete de software. Incluya una lista desplegable de software
que permita al usuario seleccionar un paquete de software. El diseño usa Ajax para actualizar la lista de computadoras
en la página Web que contiene el software y sus ubicaciones.
E-18. Diseñe la página Web LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING), que
muestre las computadoras disponibles en cada sala de cada campus. El CAMPUS se selecciona de una lista desplegable
que muestra la DESCRIPCIÓN DEL CAMPUS (CAMPUS DESCRIPTION). Cuando el usuario selecciona el nombre
de un campus de la lista desplegable, la página Web usa técnicas de Ajax para llenar la lista desplegable de salas del
campus. Al seleccionar una sala, la página Web usa Ajax para mostrar las máquinas ubicadas en cada sala. Use el repo-
sitorio para el LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING) sin el número
total de máquinas en campus o el número total de máquinas.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar archivos de ejemplo de Microsoft Visio o un proyecto de Visible Analyst, además de una base de
datos de Microsoft Access que pueden usar para completar los ejercicios.
www.xlibros.com
CAPÍTULO 12
Diseño de una entrada efectiva
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Diseñar formularios de entrada funcionales para los usuarios de sistemas empresariales.
2. Diseñar pantallas de entrada atractivas para los usuarios de sistemas de información.
3. Diseñar formularios de entrada útiles para las personas que interactúan en la Web.
4. Diseñar páginas de entrada útiles para los usuarios de intranets y de Internet.
www.xlibros.com
372 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FLUJO DEL FORMULARIO Un formulario con un flujo apropiado reduce el tiempo y esfuerzo que invierten los
empleados en llenarlo. Los formularios deben fluir de izquierda a derecha y de arriba abajo. Un flujo ilógico
requiere tiempo adicional y es frustrante. Un formulario en el que las personas tienen que pasar directamente a la
parte inferior y después saltar hacia la parte superior para terminarlo exhibe un mal flujo.
SIETE SECCIONES DE UN FORMULARIO Hay un segundo método que facilita a las personas llenar los formularios
en forma correcta; éste se enfoca en agrupar la información en forma lógica. Las siete secciones principales de
un formulario son:
1. Encabezado.
2. Identificación y acceso.
3. Instrucciones.
4. Cuerpo.
5. Firma y verificación.
6. Totales.
7. Comentarios.
Lo ideal es que estas secciones aparezcan agrupadas como en el recibo de gastos de empleado de Bakerloo Bro-
thers, de la figura 12.1. Observe que las siete secciones abarcan la información básica requerida en la mayoría de
los formularios. El tercio superior del formulario se dedica a tres secciones: encabezado, sección de identificación
y acceso, y sección de instrucciones.
Por lo general, la sección del encabezado incluye el nombre y la dirección de la empresa que creó el formu-
lario. La sección de identificación y acceso incluye códigos que se pueden usar para archivar el informe y obte-
ner acceso al mismo en una fecha posterior (en el capítulo 13 veremos con detalle cómo acceder a la información
con claves especiales en una base de datos). Esta información es muy importante cuando una organización debe
archivar el documento durante varios años. La sección de instrucciones indica cómo llenar el formulario y a
dónde se debe enviar al terminar de llenarlo.
La parte media es su cuerpo, el cual representa aproximadamente la mitad del formulario. En esta parte, la
persona que lo llena debe poner más detalle y elaboración. El cuerpo es la parte del formulario que probable-
mente contendrá datos explícitos y variables.
El tercio inferior del formulario está compuesto de tres secciones: firma y verificación, totales y comenta-
rios. Requerir totales finales y un resumen de los comentarios es una forma lógica de que la persona que llena el
formulario termine de hacerlo.
Hay una característica más a resaltar sobre el formulario de Bakerloo Brothers. El diseño del formulario
provee una doble verificación interna, con totales de columnas y totales de filas que deben dar como resul-
tado el mismo número. Si los totales de fila y de columna no dan el mismo resultado, el empleado que está
llenando el formulario sabrá que hay un problema y podrá corregirlo en ese instante. Se evita un error y el
empleado puede recibir el reembolso de la cantidad pendiente; ambos resultados se atribuyen a un diseño ade-
cuado del formulario.
LEYENDAS El uso de leyendas claras es otra técnica para facilitar el trabajo de llenar un formulario. Las leyendas
indican a la persona que completa el formulario lo que debe poner en una línea, espacio o cuadro en blanco. En
la figura 12.2 se muestran varias opciones para las leyendas. Se muestran dos tipos de leyendas de línea, dos
tipos de leyendas de verificación y ejemplos de una leyenda enmarcada y una leyenda de tabla.
La ventaja de poner la leyenda debajo de la línea es que hay más espacio en la línea para los datos; la des-
ventaja es que algunas veces no está claro cuál línea está asociada con la leyenda, si la de arriba o la de abajo.
Las leyendas de línea pueden estar a la izquierda de los espacios en blanco, a la misma altura, o se pueden
imprimir debajo de la línea en la que se van a introducir los datos.
Otra forma de usar leyendas es proveer un cuadro para los datos en vez de una línea. Las leyendas se pue-
den colocar en el interior, encima o debajo del cuadro. Los cuadros en los formularios ayudan a las personas a
introducir los datos en el lugar correcto y facilitan a la persona que recibe el formulario el proceso de leerlo. La
leyenda debe usar un tamaño de letra pequeño, de manera que no domine el área de entrada. Es posible incluir
pequeñas marcas de verificación en el cuadro si los datos se van a introducir en un sistema computarizado. Si
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 373
FIGURA 12.1
En un formulario bien diseñado
hay siete secciones que ayudan a
Bakerloo Brother fomentar que se complete.
s Número de ID del
empleado
RECIBO DE GAST
OS DE EMPLEADO
Solicitante: No esc
riba en las áreas
sombreadas. Número de recibo
Nombre completo
del empleado
Departamento Se realizó una acc
Número de sala ión sobre:
Totales
Certifico que toda
la información ant
erior es correcta
no hay suficiente espacio en un registro para los datos, la persona que llena el formulario (en vez del opera-
dor que introducirá los datos) tiene la libertad de determinar cómo se deben abreviar los datos. Las leyendas
también pueden incluir pequeñas notas aclaratorias para ayudar al usuario a introducir la información correcta-
mente, como Fecha (MM/DD/AAAA) o Nombre completo (Apellido paterno, apellido materno, Nombre(s)).
No importan los estilos de leyendas de línea que se elijan, es imprescindible emplearlos de manera consis-
tente (por ejemplo, sería confuso tratar de llenar un formulario diseñado con leyendas tanto arriba como debajo
de las líneas).
Las leyendas de verificación son una mejor opción cuando es necesario restringir las opciones de respuesta.
Observe la lista de métodos de viaje que se muestran para el ejemplo de verificación vertical en la figura anterior. Si
se va a rembolsar los gastos del empleado en el viaje de negocios sólo para los métodos de viaje de la lista, un sis-
tema de verificación es más conveniente que una línea en blanco. Este método tiene la ventaja adicional de recordar
a la persona que verifica los datos que debe buscar un talón de boleto de avión o cualquier otro recibo relacionado.
Una leyenda de verificación horizontal también es mejor opción que una leyenda de línea cuando la infor-
mación requerida es rutinaria y constante. Como ejemplo podemos citar un formulario que solicita los servicios
de uno de los siguientes departamentos: Laboratorio fotográfico, Departamento de impresión, Mantenimiento o
www.xlibros.com
374 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 12.2
Alternativas principales para usar
leyendas. Leyenda de línea
Nombre
Apellido paterno
Título
Teléfono ( )
–
Nombre
Leyenda debajo Apellido paterno
de la línea
Título – –
Teléfono
Leyenda enmarcada
Nombre
Apellido paterno
Título
Teléfono
– –
Marque el métod
o de viaje:
Avión
Tren Lista de verificación Lista de verificación
vertical horizontal
Auto de la empre
sa
Auto personal
Laboratorio fotográf
ico Departamento de im
presión Mantenimiento
Provisiones
Leyenda de tabla
Subtotal
Impuesto de venta
Total
Provisiones. Estos departamentos proveen servicios de rutina a otros en la organización y no es probable que va-
yan a cambiar rápidamente.
Las leyendas de tabla funcionan bien en el cuerpo de un formulario donde se requieren detalles. Cuando
un empleado llena de manera apropiada un formulario con leyendas de tabla, está creando una tabla para la si-
guiente persona que recibirá el formulario, con lo cual ayuda a organizar los datos en forma coherente.
También se puede utilizar con efectividad una combinación de leyendas: por ejemplo, leyendas de tabla para
especificar categorías como cantidad, y leyendas de línea para indicar dónde deben estar el subtotal, los impues-
tos de venta y el total. Como las distintas leyendas sirven para propósitos diferentes, por lo general es necesario
emplear varios estilos de leyendas en cada formulario.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 375
diferentes departamentos o usuarios y compartir al mismo tiempo cierta información básica. Aquí es donde son
útiles los formularios especializados.
El término formulario especializado también se puede referir sólo a la manera en que la papelería prepara
los formularios. Algunos ejemplos de formularios especiales de papelería son los formularios de tantos múltiples
que se utilizan para crear triplicados instantáneos de los datos, los formularios de alimentación continua que pue-
den pasar por la impresora sin necesidad de intervención humana y los formularios perforados que dejan un talón
como registro cuando se separan.
FIGURA 12.3
El software permite a un usuario
tomar un formulario existente,
escanearlo en la computadora y
definir campos de manera que se
pueda llenar fácilmente en una PC.
www.xlibros.com
376 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 377
O P O R T U N I D A D D E C O N S U LT O R Í A 1 2 . 1
Formulario de his
torial médico
Nombre
Empleador
Dirección Edad
CP Teléfono
Aseguradora Oficina
Es esta [ ] su pó
liza [ ] la póliza
de su esposa
Cruz azul [ ] Se
rvicio médico est
atal [ ] Otro [
] (explique)
¿Alguna vez le ha
n realizado cirugía?
Sí ____ No____
De ser así, ¿cuánd
Describa la cirugía o?______
¿Alguna vez lo ha
n hospitalizado?
Sí ____ No____
De ser así, ¿cuánd
¿Por qué? o?______
Complete lo siguie
nte.
He tenido Historial familiar
Diabetes
Problemas cardia
cos
Cáncer
Ataques
Desmayos
¿Qué inmunizacio
nes ha recibido?
Familia:
Esposa o familiar
directo Relac
ión Dirección
Fecha del último
examen ___/___
¿Quién lo refirió?
¿Por qué está vis
itando al doctor ho
y?
¿Sufre de dolor en
este momento?__
_____ Constante
______ Esporád
¿Cuánto tiempo du ico______
ra?
Escriba su número
de seguro social:
¡IMPORTANTE! Ne
cesitamos el núme
ro correcto de su
compañía de seg
uros
FIGURA 12.C1
Se aprecia de manera considerable su ayuda para mejorar este formulario.
www.xlibros.com
378 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
La tercera sección de la pantalla es de “comentarios e instrucciones”, y puede mostrar un menú corto de co-
mandos que recuerdan al usuario aspectos básicos como cambiar de página, funciones y acciones como guardar
el archivo o terminar de introducir datos. Al incluir dichos aspectos básicos los usuarios inexpertos se sienten
mucho más seguros sobre su capacidad para completar la tarea.
Otras maneras de mantener simple la pantalla es utilizar ayuda sensible al contexto, botones desplegables
que revelen más información y otras ventanas desplegables. Los usuarios pueden minimizar o maximizar el ta-
maño de las ventanas según sea necesario. De esta manera, los usuarios empiezan con una pantalla simple y bien
diseñada que pueden personalizar y controlar por medio de varias ventanas. Los hipervínculos en un formulario
basado en Web sirven para un propósito similar.
Facilitar el movimiento
El tercer lineamiento para el buen diseño de pantallas es facilitar el proceso de pasar de una página a otra. La
regla de los “tres clics” establece que los usuarios deben ser capaces de llegar a las páginas que necesitan en tres
clics de ratón o de teclado como máximo. Los formularios basados en Web facilitan el movimiento mediante el
uso de hipervínculos a otras páginas Web relevantes. Otro método común de movimiento es hacer que los usua-
rios se sientan como si estuvieran cambiando físicamente a una nueva página. Esta ilusión de movimiento físico
entre pantallas se puede obtener al desplazarse mediante flechas, ventanas desplegables sensibles al contexto o
un cuadro de diálogo en pantalla.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 379
O P O R T U N I D A D D E C O N S U LT O R Í A 1 2 . 2
CONDUCCIÓN ÓSEA
Oído derecho Oído izquierdo
500 1000 2000 4000 6000 500 1000 2000 4000 6000
FIGURA 12.C2
Esta pantalla se puede diseñar de manera que sea más amigable para el usuario.
Un usuario puede apuntar a un archivero, “sacar” un icono de carpeta, “agarrar” una pieza de icono de papel y
“echarla” al icono de bote de basura. Al emplear iconos estándar, los diseñadores y usuarios ahorran tiempo.
Los iconos para una aplicación específica deben estar limitados a una cantidad aproximada de 20 formas
reconocibles, de manera que el vocabulario de iconos no sea tan abrumador y se pueda realizar un esquema de
codificación que valga la pena. Use iconos de manera consistente en las aplicaciones donde aparecerán juntos
para asegurar la continuidad y facilidad de comprensión. En general, los iconos valen la pena para los usuarios si
son significativos.
www.xlibros.com
380 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 12.4
El diseñador tiene muchos
componentes de GUI que permiten
flexibilidad al diseñar pantallas de
entrada para la Web u otros
paquetes de software. Este
ejemplo es de Microsoft Access.
ces gráficas de usuario aprovechan las características adicionales en el diseño de pantallas, como los cuadros de
texto, las casillas de verificación, los botones de opción, los cuadros de lista y de lista desplegable, los controles
deslizantes y botones aumentar/disminuir, los cuadros de diálogo con controles en pestañas y los mapas de ima-
gen. La figura 12.4 es una pantalla de entrada de Microsoft Access que muestra varios controles de GUI.
CUADROS DE TEXTO Un rectángulo representa un cuadro de texto, como vimos antes; se utiliza para delinear
los campos de entrada y visualización de datos. Hay que tener cuidado de asegurar que el cuadro de texto sea lo
bastante grande como para poder alojar todos los caracteres que es necesario introducir. Cada cuadro de texto
debe tener una leyenda a la izquierda para identificar lo que se va a introducir o lo que se muestra en el cuadro.
En Microsoft Access, los datos de caracteres se alinean a la izquierda y los datos numéricos a la derecha.
CASILLAS DE VERIFICACIÓN En el ejemplo de los controles de GUI se utiliza una casilla de verificación para
indicar un nuevo cliente. Las casillas de verificación pueden contener una X o estar vacías, lo que corresponde
a indicar si el usuario seleccionó o no la opción; se utilizan para marcar una o más opciones (es decir, en forma
no exclusiva). Una notación alternativa es utilizar un botón cuadrado con una marca de verificación (✓) para
indicar que se seleccionó esa opción. Cabe mencionar que por lo general el texto (o leyenda) de la casilla de
verificación se coloca a la derecha del cuadro. Si hay más de una casilla de verificación, las etiquetas deben tener
cierto orden, ya sea alfabético o que el elemento que se marque con más frecuencia aparezca primero en una
lista. Si hay más de 10 casillas de verificación, agrúpelas en un recuadro.
BOTONES DE OPCIÓN Un círculo conocido como botón de opción se utiliza para seleccionar opciones exclusivas:
se puede elegir sólo una de varias. De esta forma podemos dejar en claro a los usuarios que deben decidir entre
varias. De nuevo, las elecciones se enlistan a la derecha del botón, por lo general en cierta secuencia. Si hay una
opción que se seleccione con frecuencia, por lo general se selecciona como predeterminada la primera vez que se
muestra la página. A menudo hay un rectángulo, conocido como grupo de opciones, que rodea a los botones de
opción. Si hay más de seis botones de opción tal vez sea más conveniente usar un cuadro de lista o un cuadro
de lista desplegable.
CUADROS DE LISTA Y DE LISTA DESPLEGABLE Un cuadro de lista muestra varias opciones que se pueden
seleccionar con el ratón. Un cuadro de lista desplegable se utiliza cuando hay poco espacio disponible en la
página. Un solo rectángulo con una flecha apunta para abajo hacia una línea localizada del lado derecho del
rectángulo. Al seleccionar esta flecha se despliega un cuadro de lista. Una vez que el usuario selecciona un
elemento, se muestra en el rectángulo de selección desplegable y el cuadro de lista desaparece. Si hay una opción
que se seleccione con frecuencia, por lo general se muestra de manera predeterminada en la lista desplegable.
CUADROS DE DIÁLOGO CON CONTROLES EN PESTAÑAS Estos cuadros de diálogo son otra parte de las interfaces
gráficas de usuario y otra forma de hacer que los usuarios se organicen y comprendan el material del sistema con
eficiencia. Al diseñar los cuadros con controles en pestañas, cree una pestaña separada para cada característica
única, coloque las pestañas que se utilizan con más frecuencia al frente y muéstrelas primero; incluya también
botones para Aceptar, Cancelar y Ayuda.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 381
FIGURA 12.5
Los controles deslizantes y
botones aumentar/disminuir son
dos componentes de GUI
adicionales que el analista
puede utilizar para diseñar
pantallas de entrada.
CONTROLES DESLIZABLES Y BOTONES AUMENTAR/DISMINUIR Estos controles se utilizan para cambiar los datos
que tienen un rango continuo de valores; proporcionan mayor control a los usuarios en su tarea de seleccionar
valores. Al desplazar el control deslizable en una dirección o en otra (ya sea izquierda/derecha o arriba/abajo)
los valores aumentan o disminuyen. La figura 12.5 muestra el uso de controles deslizables para cambiar la cantidad
de rojo (Red), verde (Green) y azul (Blue) al seleccionar un nuevo color. Los botones aumentar/disminuir
también se utilizan para cambiar un valor continuo y se muestran a la derecha de los controles deslizables.
MAPAS DE IMAGEN Los campos de los mapas de imagen se utilizan para seleccionar valores dentro de una
imagen. El usuario hace clic en un punto dentro de una imagen y se envían las correspondientes coordenadas x
y y al programa. Los mapas de imagen se utilizan al crear páginas Web que contienen mapas con instrucciones
para hacer clic en cierta área y poder ver un mapa detallado de la región.
ÁREAS DE TEXTO Un área de texto se utiliza para introducir una cantidad mayor de texto. Estas áreas incluyen
varias filas, columnas y barras de desplazamiento que permiten al usuario introducir y ver texto que sea mayor
que el tamaño del área del cuadro. Hay dos formas de manejar este texto. Una es evitar el uso del ajuste de línea, que
obliga al usuario a oprimir la tecla Intro para pasar a la siguiente línea; el texto se desplazará a la derecha si
excede la anchura del área de texto. La otra opción es permitir el ajuste de línea.
CUADROS DE MENSAJE Los cuadros de mensaje se utilizan para advertir a los usuarios y proveer otros mensajes
de retroalimentación en un cuadro de diálogo, traslapando con frecuencia la pantalla. Estos cuadros de
mensaje tienen distintos formatos. Cada uno debe aparecer en una ventana rectangular y debe redactar con
claridad el mensaje, de manera que el usuario sepa precisamente lo que está ocurriendo y qué acciones se pueden
tomar.
BOTONES DE COMANDOS Un botón de comando realiza una acción cuando el usuario lo selecciona con el ratón.
Calcular el total, Agregar pedido y Aceptar son algunos ejemplos. El texto se centra en el botón, que tiene una
forma rectangular. Si hay una acción predeterminada, el texto se rodea con una línea punteada. El botón también
se puede sombrear para indicar que es el predeterminado. Los usuarios oprimen Intro para seleccionar el botón
predeterminado.
www.xlibros.com
382 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 12.6
Un formulario de entrada basado
en Web para que los usuarios se
registren en un crucero.
decidir los valores para cada una de las opciones de la lista desplegable y, al elegir una opción, el valor seleccionado
se envía con el formulario. Los valores de los formularios también se pueden usar en cálculos mediante el uso de
JavaScript en el navegador. Éstos se pueden usar para multiplicar, sumar y tomar decisiones.
La figura 12.6 es un ejemplo de un formulario utilizado para obtener precios y registrarse en un crucero. El
texto en las áreas Nombre (Name), Dirección (Address), Ciudad (City), Estado (State), Código postal (Zip), Te-
léfono (Phone) y Email se envía al servidor junto con el formulario. Se puede seleccionar sólo uno de los botones
de opción para el crucero de 4 días (4-day), 7 días (7-day) o 15 días (15-day). Los valores enviados son S de
corto (short), en caso de que se seleccione el crucero de 4 días, A para indicar una longitud promedio (average)
en caso de que se seleccione la opción de 7 días y L para un crucero largo (long) si se selecciona el de 14 días.
Además, al seleccionar uno de estos cruceros se inserta la cantidad en dólares en uno de los cuadros de texto del
lado izquierdo del formulario Web, y se borra cualquier botón de opción seleccionado antes, junto con cualquier
cantidad. Si se marca la casilla de verificación para el cuarto con vista al océano (ocean side room), se transmite
al servidor un valor de Y para indicar Sí, se inserta la cantidad en el cuadro de texto del lado izquierdo y se ac-
tualiza el total. Si el cliente trata de cambiar las cantidades en los cuadros de texto calculados, se reinician. Al
hacer clic en el botón Enviar (Submit), se envían las cantidades al servidor junto con los demás datos.
Campos ocultos
Otro de los tipos de controles que se encuentran en los formularios Web es el campo oculto. Estos controles no
son visibles para el espectador, no ocupan espacio en la página Web y pueden contener sólo un nombre y un
valor. Con frecuencia los campos ocultos se utilizan para almacenar los valores que se envían de un formulario
Web al servidor. Generalmente se requiere incluir estos valores en un segundo formulario cuando se requieren
formularios múltiples para capturar todos los datos de la transacción. Algunas veces se utilizan para retener
información sobre el tipo de navegador que se utiliza, el sistema operativo del usuario que está navegando, et-
cétera. Algunas veces un campo oculto contiene un campo clave que se utiliza para localizar un registro para el
cliente o la sesión de exploración.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 383
FIGURA 12.7
Un sitio Web que permite a los
usuarios estimar el costo de la
estancia en el Azure Islé Resort,
que cambia dependiendo del
número de huéspedes, la duración
y las actividades adicionales.
nar la página Web cuando ocurra el evento. Los eventos son para un objeto específico, como un botón, un campo
de texto, toda la página Web, etcétera.
La figura 12.7 muestra un sitio Web en el que es posible estimar el costo de la estancia en el Azure Islé
Resort. El usuario puede introducir el número de huéspedes, cambiar las fechas de inicio y final, e introducir el
número de personas para varias actividades adicionales, como buceo o golf.
En la figura 12.8 se muestra la tabla de respuesta a eventos. Observe que puede haber varios eventos para cada
control del formulario Web. Como el usuario puede realizar cualquier número de acciones y en cualquier orden, la
tabla de respuesta a eventos es útil para mostrar lo que debería ocurrir. Por ejemplo, el usuario puede hacer clic en
el botón Calcular (Calculate) primero, cambiar las fechas de inicio y final o cambiar el número de personas. La ta-
bla de respuesta a eventos también es útil para construir un formulario Web que requiera un mínimo de acción por
parte del usuario. Por ejemplo podemos considerar cuando el usuario cambia el mes o día de inicio: el mes o día
final cambia para coincidir con el mes o día inicial. El año cambia cuando el mes es anterior al mes en curso, ya que
las personas no se pueden quedar en un centro vacacional antes del día actual en el mismo año.
Algunas veces podemos usar la tabla de respuesta a eventos para explorar las mejoras en la página Web. Su-
ponga que Azure Islé Resort determinó que la mayoría de sus clientes se quedaron durante siete días. Al cambiar
el mes o día inicial, la fecha final se podría establecer de manera predeterminada en siete días. También podría
ser conveniente tener botones de opción que permitieran al cliente seleccionar una estadía de 4, 7 o 14 días y calcular
la fecha final. Otra mejora a una página Web podría ser detectar cuando se haya introducido cierto número de ca-
racteres, por ejemplo los tres dígitos que corresponden al código de área de un teléfono de Estados Unidos, para
después mover el cursor hacia el siguiente campo.
Los eventos no se limitan al trabajo dentro de una sola página Web; también se pueden usar para controlar
la navegación entre páginas. Esto puede ocurrir al momento de cambiar una selección en una lista desplegable o
al hacer clic en un botón de opción. Los eventos también se pueden usar para cambiar el contenido de las listas
desplegables. Por ejemplo, en una página para buscar empleo, al seleccionar una categoría de empleo pueden
aparecer las posiciones detalladas para ese empleo en una segunda lista desplegable.
www.xlibros.com
384 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 12.8
Una tabla de respuesta a eventos que muestra la lista de controles del formulario, eventos y respuestas para varios eventos que pueden ocurrir
cuando el usuario interactúa con la pantalla para estimar costos de Azure Islé Resort.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 385
campos o eliminar campos antiguos, o para cambiar los atributos de los campos, como la longitud de un campo
o convertir un botón de opción en una casilla de verificación. Esto hace que la página Web sea más sensible a las
acciones de los usuarios y a menudo elimina la necesidad de cargar nuevas páginas Web con base en las eleccio-
nes de los usuarios.
El analista debe pensar en la información que tendría sentido para el usuario del sitio Web. Por ejemplo, al
colocar la lista de selección de país en una página Web antes de otros elementos de la dirección el usuario puede
cambiar la lista de países para que cambien a su vez las leyendas y se refleje el país. Si la persona seleccionó
Estados Unidos de la lista desplegable, las leyendas dirían ‘Estado’ y ‘Zip Code’. Si el país fuera Canadá, las le-
yendas dirían ‘Provincia’ y ‘Código postal’. Si fuera Japón, sería ‘Prefectura’ y ‘Código de correo’.
www.xlibros.com
386 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
a
Si se seleccion
po ra tivo (C orporate)”,
“Cor
ca m bi a para
la página
mpo para
mostrar un ca
ompany)”.
“Compañía (C
en “Agregar
Si se hace clic
ied ad (Add New
nueva prop
ar e un
ec
Property)”, ap
cu ad ro de propiedad
nuevo
ad o.
del asegur
FIGURA 12.9
Ejemplo de una página Web
dinámica de una compañía de
seguros. Si el usuario hace clic
en “Agregar nueva propiedad
(Add New Property)”, aparece
un cuadro de nueva propiedad
para el asegurado.
para un cliente existente; o eliminar una tienda para el cliente. Si está seleccionada la casilla de verificación Cor-
porativo (Corporate), los campos Apellido paterno (Last Name), Primer nombre (First Name) y Segundo
nombre (Middle) cambian a un campo de nombre Compañía (Company), y también cambia el texto de las
leyendas. Si se hace clic en el botón Agregar nueva propiedad (Add New Property), se agrega un nuevo con-
junto de campos para la tercera propiedad. Hay que tener cuidado de generar nombres únicos que el servidor re-
conocerá para los campos adicionales. Al enviar el formulario, el servidor actualiza las tablas de la base de datos
para agregar los campos adicionales.
El analista debe decidir cuándo es apropiado el uso de páginas Web dinámicas. Si los datos cambian al cam-
biar otras partes de la página Web (como hacer clic en un botón de opción o seleccionar un elemento de una lista
desplegable), puede ser buena política diseñar las páginas Web como un formulario dinámico. Pero si algunas
partes del formulario Web no están seguras y otras partes requieren de cifrado, probablemente sea mejor no usar
formularios dinámicos.
En Expedia.com (www.expedia.com) encontrará un buen ejemplo de un formulario que se modifica a sí
mismo. Al hacer clic en los botones de opción para un vuelo, hotel, auto o crucero, el formulario cambia para
recopilar los datos apropiados para reservar un vuelo o un hotel, por ejemplo.
Las páginas Web dinámicas tienen la ventaja de que se modifican a sí mismas con rapidez, con menos in-
terrupciones para enviar y recibir datos del servidor. Sin embargo, presentan ciertas desventajas; una de ellas es
que no funcionan si se desactiva el JavaScript. El analista debe decidir qué hacer en esta situación.
Si la persona debe usar el sitio Web (como en un entorno de intranet corporativo, en un sitio utilizado para
obtener préstamos para estudiantes, o en el caso de procesar transacciones gubernamentales o de otro tipo), la pá-
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 387
gina Web puede establecer con claridad que no funcionará si se desactiva JavaScript y después indicar al usuario
cómo activarlo. La mayoría de los sitios Web comerciales no requieren que JavaScript esté activado y contarán
con un sitio Web alternativo para los clientes.
Una segunda desventaja al usar páginas Web dinámicas es que tal vez no cumplan con la Ley sobre estado-
unidenses con discapacidades (para obtener más información sobre la accesibilidad Web para todos los usuarios,
consulte el capítulo 14 sobre el diseño de la interacción humano-computadora).
www.xlibros.com
388 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
cliente
Una vez que el
a cu at ro
seleccion ra
servidor gene
pasajeros, el leg ab les.
desp
cuatro listas
entificar
Después de id
pa sajeros
a los cuatro
ec e un a pr eg unta
apar
ve hí cu lo.
sobre un
FIGURA 12.10
Cuando los analistas utilizan técnicas Ajax, una página Web dinámica responde con más rapidez a la entrada corta del usuario de la que
respondería si se requirieran varias páginas distintas.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 389
www.xlibros.com
390 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 2 . 3
Juego de máscaras
A l contemplar la actualización del diseño del sitio Web de comer-
cio electrónico para las tiendas Marathon Vitamin, su propietario
Jin muestra a Bill ejemplos de algunas máscaras en la pantalla.
En la figura 12.C3 puede ver varias para Microsoft Windows Media
Bill Berry se dio cuenta de que sus clientes eran diversos. Player.
“Hemos trabajado duro para atraer muchos tipos de clientes. En Jin continúa: “Las máscaras me permiten personalizar la
cuanto a la tienda, estamos teniendo éxito. Llegan personas con dis- apariencia de mi Media Player. Cuando escucho canciones anti-
tintos intereses. He conocido entusiastas del deporte que desean vita- guas, selecciono una rústica. Cuando voy a escuchar algo de New
minas de alta energía para aumentar su poder. Otros desean perder Age, opto por una máscara que tenga un arcoíris de colores, por
peso con la ayuda de los suplementos vitamínicos. Algunos de nues- ejemplo”.
tros clientes se preocupan por su salud y creen que tomar vitaminas Mientras mira la pantalla, Bill exclama: “Creo que estás en lo
diariamente mantiene alejado al doctor. Algunos incluso adoptan el correcto. ¿Cómo dijiste que se llamaban esas cosas?”.
estilo de vida que se cultivó por primera vez en 1970. Por la forma en Jin ríe y le explica: “Se llaman máscaras, pero sólo son reves-
que está configurada la tienda puede ver que estamos tratando de timientos divertidos que los clientes pueden agregar a lo que deseen
segmentar el espacio, de manera que los clientes de todo tipo se sien- ver. Puedo prever que en un momento dado el sitio Web podrá asu-
tan bienvenidos, aunque es difícil traducir eso a la Web”. mir una apariencia completamente nueva, dependiendo de las pre-
Bill voltea hacia una de sus empleadas, Jin Singh, y le pre- ferencias de usuario para un tipo específico de máscara”.
gunta: “¿Hay algo que podamos hacer para transformar el catálogo Con base en su evaluación de los distintos tipos de clientes que
en línea, de manera que atraiga a distintos clientes? ¿Y qué hay a Marathon le gustaría atraer a su sitio Web, diseñe, dibuje y des-
sobre ser receptivo para las distintas personas que visitan el sitio?”. criba una serie de máscaras que serían apropiadas para los propósi-
Jin, que resulta ser fanática de los webcasts en Internet, dice: tos de la compañía. Explique en dos párrafos cómo la acción de
“Tengo justo lo ideal”, mientras voltea hacia su computadora y abre su incluir máscaras controladas por los usuarios en un sitio Web puede
Windows Media Player. “Personalmente me gusta entrar en un estado ampliar los objetivos de diseño del analista en cuanto al atractivo y
mental que coincida con la música o los videos que veo en la Web”. la facilidad de uso para la entrada.
FIGURA 12.C3
Seis máscaras de Microsoft Windows Media Player permiten a los usuarios personalizar sus reproductores para adaptarse a su
humor.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 391
FIGURA 12.11
La pantalla de pedidos del sitio
Web Merchants Bay (www.
merchantsbay.com) es un buen
ejemplo de cómo diseñar un
formulario de entrada claro, fácil
de usar y funcional.
Las aplicaciones de comercio electrónico requieren algo más que sólo un buen diseño de sitios Web. Los
clientes necesitan sentirse con la confianza de que van a comprar la cantidad correcta, de que van a obtener el
precio correcto y de que el costo total de una compra por Internet, incluyendo los cargos de envío, sea lo que
esperan. La forma más común de establecer esta confianza es mediante el uso de la metáfora de un carrito o ca-
nasta de compras. La figura 12.12 muestra el contenido de un carrito de compras para un cliente que va a realizar
una compra. Una característica importante del carrito de compras es que el cliente puede editar la cantidad del
artículo que se pide, o lo puede eliminar por completo.
Las aplicaciones de comercio electrónico imponen demandas adicionales para el analista que debe diseñar
sitios Web para cumplir con varios objetivos de usuarios y de negocios, incluyendo establecer la misión y los va-
lores corporativos en relación con la confidencialidad, preservar la privacidad del usuario y obtener devoluciones
rápidas y sencillas; el procesamiento eficiente de las transacciones y la creación de buenas relaciones con los
clientes.
FIGURA 12.12
El sitio Web Merchants Bay
(www.merchantsbay.com)
proporciona un buen ejemplo de
un carrito de compras.
www.xlibros.com
392 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
ATRACTIVO DE LA MAC
El comercio electrónico cambió el mundo al pedir a los usuarios que introdujeran sus datos directamente en formularios
de Web; al hacer esto aumentó la precisión de la entrada de información. Aunque esta metodología es eficiente para las
empresas que reciben datos, la labor de teclearlos recae en el cliente. Por fortuna existe software para automatizar ese
proceso, de manera que los usuarios simplemente tienen que hacer un par de clics en vez de tener que escribir largas
cadenas de caracteres alfanuméricos que constituyen sus datos personales, contraseñas y números de tarjetas de crédito.
En una PC, RoboForm de Siber Systems es una buena alternativa. En la Mac, 1 Password por Agile Web Solutions
parece ser el líder actual.
1 Password permite a un usuario automatizar inicios de sesión, completar la información de tarjetas de crédito,
llenar una identidad completa con dirección de calle y correo electrónico, e introducir notas seguras. Al igual que todo
buen programa de contraseñas, 1 Password incluye características importantes como generadores de contraseñas fuer-
tes, tecnología Anti-Phishing y protección integrada contra keyloggers. 1 Password también es una aplicación para el
iPhone y un programa para la Palm, por lo que los usuarios pueden llevar sus contraseñas consigo.
FIGURA 12.MAC
1Password de Agile Web Solutions.
©2006–09 Agile Web Solutions, todos los derechos reservados.
RESUMEN
En este capítulo presentamos los elementos del diseño de en- El diseño de formularios impresos y el de formularios en
trada para formularios, pantallas y formularios de llenado en Web. pantalla y para llenado en Web se traslapa en muchos puntos im-
La entrada bien diseñada debe cumplir con los objetivos de portantes, pero hay algunas distinciones. Las pantallas muestran
efectividad, precisión, facilidad de uso, simpleza, consistencia un cursor que orienta en forma continua al usuario. Las pantallas
y atractivo. Al conocer los distintos elementos de diseño el ana- a menudo ofrecen asistencia para el proceso de entrada de datos,
lista podrá alcanzar estas metas. mientras que con la excepción de las instrucciones pre-impresas,
Los cuatro lineamientos de los formularios de entrada puede ser difícil obtener asistencia adicional con un formu-
bien diseñados son: 1) hacer que los formularios sean fáciles lario. Los documentos basados en Web tienen capacidades
de llenar, 2) asegurar que cumplan con el propósito para el adicionales, como hipervínculos incrustados, funciones de ayuda
que se diseñaron, 3) diseñarlos para asegurar que se llenen sensibles al contexto y formularios de retroalimentación, para
de manera satisfactoria y 4) mantener los formularios atrac- corregir la entrada antes de su envío final. Es posible agregar
tivos. máscaras como una opción para personalizar un sitio Web.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 393
EXPERIENCIA DE HYPERCASE® 12
FIGURA 12.HC1
Puede ver algunas de las pantallas de entrada en HyperCase. Tal vez quiera rediseñar
algunos de los formularios electrónicos.
Los cuatro lineamientos para las pantallas bien diseñadas Es importante que haya un flujo apropiado en los formu-
son: 1) mantener la pantalla simple, 2) mantener la presentación larios de papel, las pantallas de visualización y los formularios
de la pantalla consistente, 3) facilitar el movimiento del usua- de llenado en la Web. Los formularios deben agrupar la infor-
rio entre las pantallas y páginas de visualización y 4) crear una mación de manera lógica en siete categorías; las pantallas se
pantalla atractiva y agradable. Muchos elementos de diseño deben dividir en tres secciones principales. Es posible variar las
distintos permiten al analista de sistemas cumplir con estos li- leyendas en los formularios y las pantallas, al igual que los ti-
neamientos. pos de letras y los grosores de las líneas que dividen las subca-
www.xlibros.com
394 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
PREGUNTAS DE REPASO
1. ¿Cuáles son los objetivos de diseño para los formularios de entrada en papel, las pantallas de entrada o los formularios
para llenar en Web?
2. Mencione los cuatro lineamientos para el diseño de buenos formularios.
3. ¿Qué es el flujo apropiado de un formulario?
4. ¿Cuáles son las siete secciones de un buen formulario?
5. Mencione cuatro tipos de leyendas para usar en los formularios.
6. ¿Qué es un formulario especializado? ¿Cuáles son algunas desventajas de usar formularios especializados?
7. Mencione los cuatro lineamientos para el buen diseño de pantallas.
8. ¿Cuáles son las tres secciones útiles para simplificar una pantalla?
9. ¿Cuáles son las ventajas de usar ventanas en pantalla?
10. ¿Cuáles son las desventajas de usar ventanas en pantalla?
11. Mencione dos formas en que se puede mantener la consistencia en las pantallas.
12. Mencione tres formas para facilitar el movimiento entre las páginas de visualización.
13. Mencione cuatro elementos de diseño de interfaz gráfica. Describa a un lado de cada elemento cuándo sería apropiado
incorporarlo en un diseño de pantalla o en un formulario para llenar en Web.
14. ¿Cuándo se deben usar las casillas de verificación?
15. ¿Cuándo se deben usar los botones de opción?
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 395
16. ¿Cuáles son las dos formas distintas en que se utilizan los valores de un formulario?
17. ¿Para qué se utilizan los campos ocultos en un formulario Web?
18. Mencione cuatro tipos de eventos.
19. ¿Qué son las páginas Web dinámicas?
20. ¿Qué son las páginas Web tridimensionales?
21. ¿Cómo mejora Ajax una página Web que cambia en base a las acciones de los usuarios?
22. Mencione las cinco combinaciones más legibles de colores de primer plano y de fondo para usarlas en las pantallas.
23. Defina lo que significa el término máscaras cuando se utilizan en el diseño Web.
24. ¿Cuáles son las cuatro situaciones en las que el color puede ser útil para el diseño de pantallas y de formularios para
llenar en Web?
25. Mencione los siete lineamientos de diseño para un formulario de llenado basado en Web.
PROBLEMAS
1. He aquí las leyendas que se utilizan para un formulario de censo estatal en los EE.UU.:
Nombre
_____________________________________
Ocupación
_____________________________________
Dirección
_____________________________________
Código postal
_____________________________________
Número de personas que viven en el hogar
_____________________________________
Edad del jefe de familia
_____________________________________
a. Rediseñe las leyendas de manera que el buró de censo estatal pueda capturar la misma información que se solicita en
el formulario anterior sin confundir a quienes lo van a llenar.
b. Rediseñe el formulario de manera que exhiba un flujo apropiado. (Sugerencia: Cerciórese de proveer una sección de
acceso e identificación, de manera que la información se pueda almacenar en el sistema computarizado estatal.).
c. Rediseñe el formulario de manera que lo puedan llenar los ciudadanos que visitan el sitio Web del estado. ¿Qué
cambios fueron necesarios para cambiar de un formulario en papel a uno que se enviará en forma electrónica?
2. El Elkhorn College necesita llevar un mejor registro de los estudiantes y todos los que utilizan las computadoras
disponibles en la biblioteca Buck Memorial Library.
a. Diseñe y dibuje una representación de una pantalla de visualización que los estudiantes puedan usar para iniciar
sesión en las computadoras de la biblioteca. Etiquete las tres secciones de una pantalla que incluyó.
b. Diseñe un formulario en papel para dejarlo a un lado de cada computadora diariamente, con el fin de que los
usuarios de la comunidad (pero que no sean estudiantes) lo llenen de manera obligatoria. El formulario debe pedir el
nombre, la fecha y hora de la visita, el propósito general de uso de la computadora (por ejemplo, procesamiento de
palabras, navegar en la Web, examinar los documentos de bienes raíces en línea) y la hora en que cerraron sesión.
Etiquete las siete secciones de un formulario que incluyó.
3. Speedy Spuds es un restaurante de comida rápida que ofrece todo tipo de papas. El gerente tiene una regla de 30
segundos para atender a los clientes: los dependientes del mostrador dicen que podrían alcanzar esa regla si se
simplificara el formulario que deben llenar y entregar al personal de la cocina. La información del formulario lleno
se introduce en el sistema computarizado al final del día, cuando el capturista necesita introducir el tipo de papas que se
compró, los aderezos adicionales que se pidieron, la cantidad y el precio cobrado. Es difícil que los dependientes puedan
escanear y llenar con rapidez el formulario actual.
a. Diseñe y dibuje un formulario (usted elige el tamaño, pero sea considerado) que enliste las posibles variedades de
papas y aderezos de una manera que facilite a los dependientes del mostrador y al personal de cocina el proceso
de digitalizar, y que también se pueda utilizar como entrada para el sistema de inventario/reordenamiento en la
extranet que conecta a Speedy Spuds con los cultivadores de papas de Idaho. (Sugerencia: Recuerde observar todos
los lineamientos para el buen diseño de formularios.).
b. Diseñe y dibuje una representación de una pantalla de visualización que puedan usar los dependientes y oficinistas
para llenar la información capturada en el formulario.
c. Diseñe una pantalla de visualización basada en la pantalla que diseñó en el problema 3b. Esta vez debe funcionar
como una pantalla que muestre a un miembro del equipo de cocina qué debe preparar para cada pedido de Spuds.
Mencione tres cambios que haya hecho a la pantalla existente para adaptarla de manera que funcione como pantalla
de salida.
www.xlibros.com
396 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
4. Sherry’s Meats, una empresa mayorista y minorista de carne regional, necesita recopilar información actualizada sobre
la cantidad de cada producto de carne que tiene en cada tienda. Después usará esa información para calendarizar las
entregas desde su almacén central. En la actualidad, los clientes que entran a la tienda llenan un formulario detallado en
el que especifican sus pedidos individuales. El formulario muestra más de 150 artículos; incluye carne y productos
derivados disponibles en distintas cantidades. Al final del día se tabulan entre 250 y 400 pedidos de los clientes y se
deducen del inventario de la tienda. Después, el trabajador de la oficina en cada tienda llama por teléfono para meter un
pedido para el siguiente día. Los empleados de las tiendas tienen problemas para tabular las ventas debido a los errores
que cometen los clientes al llenar sus formularios.
a. No es posible hacer que el trabajador de oficina solitario en cada tienda llene los numerosos formularios de
pedido de los clientes. Cambie el formulario (de 312 6, ya sea horizontal o vertical) y dibújelo de manera que
sea más fácil para los clientes llenarlo en forma correcta y que los trabajadores puedan tabularlo con mayor
facilidad.
b. Diseñe y dibuje un formulario especializado del mismo tamaño que cumpla con las necesidades de los clientes de
Sherry’s, los trabajadores de oficina y los trabajadores del almacén.
c. Diseñe y dibuje dos formularios distintos del mismo tamaño para cumplir con los propósitos del problema 4b, ya
que Sherry´s vende productos avícolas y de res. (Sugerencia: Piense en las formas para hacer que sea fácil distinguir
los formularios visualmente.).
d. Diseñe un formulario para llenar en una pantalla. Cuando un cliente envía un pedido, cualquier persona que atienda
a los clientes en el mostrador lo introduce en el sistema de inventario de Sherry’s. Esta información se capturará y
enviará a la computadora del almacén central para ayudar a controlar el inventario.
e. Describa en un párrafo las desventajas de que muchas personas distintas introduzcan datos desde diferentes
ubicaciones. Mencione en un párrafo los pasos que puede llevar a cabo como diseñador para diseñar el formulario a
llenar de manera que se asegure la precisión en la entrada de datos.
f. Diseñe una página Web utilizada por un cliente para introducir un pedido directamente a Sherry´s.
g. Diseñe una página Web para obtener la información de la tarjeta de crédito para un pedido en Web. Particione los
datos en dos páginas Web para obtener seguridad adicional.
h. Diseñe una página Web dinámica tridimensional que permita a Sherry’s personalizar ciertos productos, como el
solicitar ingredientes específicos en un pastel de carne o en una ensalada. Cuando el cliente seleccione un producto
de una lista desplegable deberán aparecer los ingredientes y debe haber una forma de poder seleccionar los que el
cliente desee incluir en el producto.
5. La tienda de ropa de moda R. George’s, que también cuenta con un negocio de catálogo, desea llevar el registro de los
clientes que entran en la tienda para poder expandir su lista de correo.
a. Diseñe y dibuje un formulario simple que se pueda imprimir en tarjetas de 3 5 para repartirlo a los clientes y
que lo llenen. (Sugerencia: El formulario debe tener una estética atractiva para animar a que la clientela exclusiva de
R. George’s lo llene.).
b. Diseñe y dibuje una representación de una pantalla de visualización que capture la información de los clientes en la
tienda a través de las tarjetas del problema 5a.
c. Diseñe y dibuje un segundo cuadro de diálogo de controles con pestañas en la pantalla que compare a los clientes en
la tienda con los clientes de catálogo.
d. El propietario desea que usted le ayude a mejorar su negocio de ventas por catálogo mediante el establecimiento
de un sitio de comercio electrónico. Diseñe un formulario basado en Web para capturar la información de todos
los que visitan el sitio Web. Explique en un párrafo las diferencias que tendrá en comparación con el formulario
impreso.
6. Hace poco, una prometedora agencia de corredores de bolsa con descuento expresó su interés en desarrollar su
propio software de administración de carteras basado en Web, que los clientes puedan usar desde su hogar en sus
PC para realizar transacciones comerciales, obtener cotizaciones de acciones en tiempo real y llevar a cabo otras
acciones.
a. Diseñe dos pantallas de entrada que faciliten al cliente la introducción de datos. La primera pantalla debe permitir a
los usuarios introducir los símbolos para las acciones que desean rastrear a diario. La segunda pantalla debe permitir
al cliente usar un sistema basado en iconos para diseñar un informe personalizado que muestre las tendencias en los
precios de las acciones en una variedad de gráficos o de texto.
b. Sugiera otras dos pantallas de entrada que se deban incluir en este nuevo software de administración de carteras.
7. My Belle Cosmetics es una gran empresa que tiene ventas mucho mayores a las de cualquier otra empresa regional
de cosméticos. Como organización es muy sensible al color, ya que introduce nuevas líneas de colores en sus
productos cada otoño y primavera. Hace poco, la empresa empezó a utilizar la tecnología para mostrar en forma
electrónica a los clientes en las tiendas cuál sería su apariencia con distintas sombras de cosméticos sin tener que
aplicárselos.
a. Diseñe y dibuje una representación de una pantalla que puedan usar las vendedoras en el mostrador para probar
varias sombras de lápiz labial y maquillaje en un cliente individual con mucha rapidez y alto grado de precisión. La
entrada de los clientes debe ser el color de su cabello, el color de su ropa favorita y la iluminación común en su
entorno (fluorescente, incandescente, exteriores, etcétera).
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 397
b. Diseñe y dibuje una representación de una pantalla que sea equivalente a la del problema 7a pero que demuestre
vívidamente a los encargados de tomar decisiones en My Belle cómo es que el color mejora la capacidad de
comprender la pantalla.
c. Uno de los afiliados que tiene My Belle en la Web cuenta con una extensa cadena de tiendas departamentales.
Describa en un párrafo cómo se podría alterar la pantalla del problema 7a de manera que un individuo pueda usarla
y My Belle pueda colocarla en el sitio de comercio electrónico de la tienda departamental para atraer clientes.
8. La empresa Home Finders Realty Corporation se especializa en localizar casas para compradores potenciales. La
información sobre las casas se almacena en una base de datos y se muestra en una pantalla de consulta. Diseñe una
pantalla basada en Web con GUI y campos para introducir los siguientes datos, empleados para seleccionar y mostrar las
casas que coincidan con los criterios. Tenga en cuenta las características disponibles para una pantalla de GUI. Los
elementos de diseño (que no se encuentran en ninguna secuencia específica) son:
a. Tamaño mínimo (en pies cuadrados).
b. Tamaño máximo (en pies cuadrados, opcional).
c. Número mínimo de recámaras.
d. Número mínimo de baños.
e. Tamaño de la cochera (número de autos, opcional).
f. Distrito escolar (hay un número limitado de distritos escolares disponibles en cada área).
g. Alberca (sí/no, opcional).
h. Ambiente (ciudad, suburbios o rural).
i. Chimenea (sí/no, opcional).
j. Uso eficiente de energía (sí/no).
Describa además los hipervínculos necesarios para lograr este tipo de interacción.
9. Diseñe una página de entrada Web para la pantalla de visualización de Home Finders Realty Corporation que creó en el
problema 8.
10. La cadena hotelera TowerWood de cinco años de antigüedad necesita ayuda para diseñar su sitio Web. La empresa
mantiene propiedades en todas las grandes comunidades turísticas de los EE.UU. como Orlando, Florida (cerca de
Disney World); Maui, Hawaii; Anaheim, California (cerca de Disneyland); Las Vegas, Nevada; y Nueva Orleans,
Luisiana. Sus propiedades incluyen una variedad de habitaciones en todas estas ubicaciones.
a. Describa en un párrafo cómo puede la empresa usar máscaras en su sitio Web para atraer distintos tipos de clientela,
incluyendo familias con niños pequeños, parejas jóvenes en su luna de miel, parejas retiradas que desean viajar con
un presupuesto establecido y los viajeros de empresas que necesitan servicios de negocios.
b. Diseñe y dibuje una serie de máscaras que atraigan a los distintos tipos de clientela para el hotel que se enlistan en el
problema 10a. (Sugerencia: Use un paquete de gráficos o un programa de dibujo para ayudar a diseñar las
máscaras.).
c. Agregue un grupo de usuarios potenciales del sitio Web para la cadena hotelera TowerWood que no fueron
mencionados en el problema 10a; diseñe y dibuje máscaras adicionales para ellos. Después cree una tabla que
relacione cada grupo de clientes con una máscara específica que haya diseñado.
11. Sludge’s Auto es un centro de reciclaje de auto partes, incluyendo autos clásicos y antiguos. Rhode Wheeler, el
propietario, desea elaborar un sitio Web para que los clientes exploren el catálogo de piezas. Diseñe una página Web con
Ajax que se utilice para buscar las piezas. El cliente necesita conocer la marca, modelo y año de un auto, así como la
pieza. Si la pieza está en existencia deberán aparecer la descripción, condición de la pieza, precio y costo de envío, con
la cantidad disponible para cada pieza, junto con una imagen de la misma. Provea un botón para cada pieza en el que se
pueda hacer clic para comprarla.
12. Diseñe la página Web Agregar cliente para Sludge’s Auto. Incluya un perfil que permita a Sludge’s enviar al cliente un
correo electrónico si cierta pieza está disponible.
13. Diseñe la página Comprar en Web para Sludge’s Auto. Suponga que el cliente ya se agregó y que ha iniciado sesión.
Muestre cierta información sobre el cliente. Divida la información de la tarjeta de crédito (tipo de tarjeta de crédito,
número de tarjeta de crédito, fecha de expiración y el código de seguridad en la parte trasera de la tarjeta) entre dos
páginas Web.
14. Diseñe una página Web que utilice Ajax para registrar un producto electrónico, ya sea de hardware o de software. El
formulario deberá tener el nombre y la dirección del comprador, el número telefónico, la dirección de correo electrónico
y una lista desplegable de categorías de productos. Al modificar la categoría, hay que enviar el valor de ésta al servidor,
el cual devolverá un documento de XML que contiene los productos para la categoría, que se utilizarán para crear una
lista desplegable de productos. Cuando el cliente seleccione un producto, se enviará el valor del producto al servidor, el
cual devolverá un documento XML que se utilizará para crear un modelo o versión del producto.
PROYECTOS EN GRUPO
1. Maverick Transport está considerando actualizar sus pantallas de visualización de la entrada. Realice una sesión de
lluvia de ideas con su equipo en relación con lo que debe aparecer en las pantallas de entrada de los operadores
de computadora que introducen los datos de las cargas de las entregas a medida que se aprueban las cargas. Los campos
incluirán la fecha de entrega, el contenido, el peso, los requerimientos especiales (por ejemplo, si el contenido es
perecedero), y así en lo sucesivo.
www.xlibros.com
398 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
2. Cada miembro del equipo debe diseñar una pantalla de entrada apropiada mediante una herramienta CASE, una
herramienta de dibujo como Microsoft Visio o lápiz y papel. Comparta sus resultados con los miembros de su equipo.
3. Haga una lista de otras pantallas de entrada que debería desarrollar Maverick Transport. Recuerde incluir pantallas para
el despachador así como las pantallas a las que accederán los clientes y conductores. Indique cuáles deberían ser
pantallas de PC o pantallas en dispositivos portátiles inalámbricos.
4. Diseñe una pantalla basada en Web que permita a los clientes de Maverick Transport rastrear el progreso de un envío.
Realice una sesión de lluvia de ideas con los miembros del equipo para obtener una lista de elementos, o haga una
entrevista en una empresa de transporte local para averiguar sus requerimientos. Haga una lista de los hipervínculos que
serán esenciales. ¿Cómo controlaría el acceso de manera que los clientes sólo puedan rastrear sus propios envíos?
BIBLIOGRAFÍA SELECCIONADA
Direct Ferries. “Web Site Uses Ajax in Their Application”. www.directferries.co.uk/poirishsea.htm. Último acceso en julio 31,
2009.
Garrett, J. J. “Ajax: A New Approach to Web Applications”. Febrero 18, 2005, www.adaptivepath.com. Último acceso: 31 de
julio de 2009.
Google Suggest. “Web Site That Uses Ajax”. www.google.com/webhp?complete=1&hl=en. Último acceso: 31 de julio de
2009.
Ives, B. “Graphical User Interfaces for Business Information Systems”. MIS Quarterly (edición especial), diciembre 1982, pp.
15-48.
Kyng, M. y L. Mathiassen. Computers and Design in Context. Cambridge, MA: MIT Press, 1997.
Nielsen, J., R, Molich, C. Snyder y S. Farrell. E-Commerce User Experience. Fremont, CA; Nielsen Norman Group, 2001.
Reisner, P. “Human Factors Studies of Data Base Query Languages: A Survey and Assessment”. Computing Surveys, Vol. 4,
Núm. 1, 1981.
Schmidt, A. y K. E. Kendall. “Using Ajax to Clean Up a Web Site: A New Programming Technique for Web Site Development”.
Decision Line, octubre de 2006, pp. 11-13.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 399
EPISODIO 12
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
FIGURA E12.1
Listas desplegables en la pantalla
AGREGAR NUEVA
COMPUTADORA
(ADD NEW COMPUTER)
en Microsoft Access.
www.xlibros.com
400 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
sobre los expertos de software disponibles?”, pregunta Hy. “Tengo los nombres escritos en pedazos de papel y vivo perdiéndo-
los. A menudo averiguo quiénes son estos expertos sólo después de que alguien los encuentra primero”.
Anna le hace algunas preguntas sobre la información requerida y cómo le gustaría a Hy mantener y mostrar los registros.
Hy responde: “Hay tantos expertos disponibles, pero la única forma que tengo de localizar la información de la persona es si
utilizo su nombre como índice. Y debo confesar que soy pésimo al recordar la escritura correcta del primer nombre, mucho
menos el apellido”. Anna le asegura que pronto habrá un sistema fácil de usar.
De regreso en su escritorio, Anna piensa en el problema. “La pantalla AGREGAR (ADD) sería muy fácil de crear, pero
¿qué hay de la pantalla CAMBIAR (CHANGE)?”. Se pregunta “¿Cómo puedo?”, y después piensa, “¡Muy bien!” mientras
chasquea sus dedos. El diseño se vuelve más claro. Debe haber una pantalla con dos regiones distintas en ella. La primera debe
contener el primer nombre y el apellido del experto de software. En la pantalla se incluye un botón Buscar (Find) así como
botones para desplazarse hacia delante y hacia atrás por los registros. Si los usuarios cometen un error al introducir los datos,
hay un botón Deshacer (Undo) y también hay un botón para guardar los cambios. La pantalla completa se muestra en la figura
E12.2.
“Excelente pantalla”, sonríe Chip. “Quiero estar aquí cuando se la enseñes a Hy”.
El problema de eliminar los registros de los cursos de software que ya no se utiliza requiere un enfoque distinto. Anna
razona que sería sencillo si utilizara la característica Buscar (Find) para localizar un registro y después utilizara un botón Find
Next (Encontrar siguiente) para localizar el siguiente registro que coincida con los criterios. También debe haber botones que
le permitan avanzar al siguiente registro o al anterior (vea ELIMINAR CURSO DE SOFTWARE [DELETE SOFTWARE
COURSE]).
Una vez localizado el registro, el programa ELIMINAR CURSO DE SOFTWARE debe mostrar la información pertinente.
Todos los códigos en el archivo, como NIVEL DE CURSO (COURSE LEVEL) y SISTEMA OPERATIVO (OPERATING
SYSTEM) se deben sustituir con el significado completo del código. Los datos no se podrán modificar en este momento. El
operador tendrá la oportunidad de revisar el registro y después elegir si lo desea o no eliminar. Al hacer clic en el botón para
eliminar, aparecerá un cuadro de diálogo preguntando a los usuarios si realmente desean eliminar el registro. Pueden optar por
cancelar la eliminación en ese momento.
Hy está encantado con los prototipos de las pantallas de visualización. Mientras prueba cada una de ellas, comenta: “No
saben lo fácil que será para mí responder a las solicitudes de ayuda. ¡Son fabulosas!”. Se detiene por un buen rato y después
pregunta: “Recibo muchas solicitudes sobre ofrecer cursos de capacitación programados en forma periódica. ¿Creen que po-
dríamos trabajar en un sistema para registrarse en los cursos?
Anna busca sus labios por un momento y comenta: “¿Alguna vez escuchó de un proyecto en el que siempre se agregan
pequeñas cosas y nunca termina? Sin embargo, la universidad tiene una iniciativa Web. Podemos diseñar una página Web inte-
ractiva para registrar los cursos”.
“¡Magnífico!”, responde Hy. “Es más de lo que jamás hubiera esperado”.
Anna empieza a diseñar la página Web, incluyendo nombre y apellido de los usuarios junto con sus direcciones de correo
electrónico y teléfonos de oficina. Se utilizan áreas adicionales para introducir el campus en donde se encuentran, el software
que utilizan y su nivel de clase. Chip revisa el formulario y comenta: “¿Qué tal si usamos Ajax para que introduzcan su dirección
de correo electrónico del campus y hagan clic en un botón Buscar empleado? El servidor buscaría los empleados y después
llenaría la página Web con el primer nombre y el apellido de cada empleado, junto con su teléfono de oficina. Podrían sobres-
cribir el teléfono de oficina con un celular si salieran de viaje. En vez de que tengan que introducir la información del campus
y del software, ¿por qué no hacemos que seleccionen opciones de una lista desplegable? ¿Y qué tal si les permitimos seleccio-
nar los horarios convenientes para la capacitación?”.
FIGURA E12.2
La pantalla CAMBIAR
EXPERTO DE SOFTWARE
(CHANGE SOFTWARE
EXPERT) de Microsoft Access.
www.xlibros.com
CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 401
FIGURA E12.3
Un formulario Web de intranet
para el Registro de capacitación
(Training Registration) en el sitio
Web de la CPU.
“Buena idea”, responde Anna. “Y creo que los niveles de capacitación deben estar también en una lista desplegable”. La
página Web de intranet completa se muestra en la figura E12.3. Observe que hay botones para enviar la consulta o restablecerla
y una lista desplegable que contiene el campus como valor predeterminado. Otras listas desplegables contienen instrucciones
sobre lo que se debe seleccionar. Hay casillas de verificación a la izquierda para seleccionar los cursos en los que se van a re-
gistrar. En la parte inferior se incluye un vínculo para enviar las preguntas por correo electrónico al instructor de capacitación.
Hy está encantado. “Este formulario es mejor de lo que jamás imaginé. Creo que realmente estamos proporcionando un
registro de capacitación efectivo, y sé que mi teléfono ya no sonará tanto. ¡Tengo otra gran idea!”.
Para realizar los siguientes ejercicios, puede diseñar el informe o pantalla mediante formularios de diseño, o crearlos a
través de cualquier procesador de palabras con el que esté familiarizado. Los campos y demás información relacionada con los
informes se incluyen en una página Web del repositorio o en las entradas del repositorio de flujo de datos de Visible Analyst.
En cada ejercicio se enlistan los nombres para el flujo de datos.
Se crearon los informes y pantallas correspondientes (conocidos como formularios en Microsoft Access). Toda la informa-
ción está presente en la base de datos de Microsoft Access; usted sólo tiene que modificar los informes y pantallas existentes
para producir las versiones finales. Para hacer las modificaciones, haga clic en el informe o pantalla deseada y después haga clic
en el botón Design (Diseño). Puede realizar las siguientes modificaciones. El Page Header (Encabezado de página) contiene
los encabezados de las columnas. El área Detail (Detalle) contiene los campos a imprimir para el informe.
Haga clic en un campo para seleccionarlo. Haga clic en varios campos mientras oprime la tecla Mayús para seleccionarlos.
Arrastre un campo (o campos) seleccionado para moverlo.
Haga clic en una de las cajas pequeñas que rodean el campo para cambiar su tamaño.
Seleccione varios campos, haga clic en Format (Formato) y después en una de las siguientes opciones:
Align (Alinear), para alinear todos los campos con el campo superior o el izquierdo, por ejemplo.
Size (Ajustar tamaño), para hacer todos los campos iguales al campo más ancho o el más alto, por ejemplo.
Horizontal Spacing (Espacio horizontal), para hacer el espacio horizontal igual, aumentarlo o reducirlo.
Vertical Spacing (Espacio vertical), para hacer el espacio vertical igual, aumentarlo o reducirlo.
EJERCICIOS
E-1. Cher Ware ha comentado varias veces que un buen formulario facilitaría de manera considerable la tarea de agregar nuevo
software. También ofrecería documentación permanente en papel para las adiciones de software.
Diseñe un formulario para agregar software al ARCHIVO MAESTRO DE SOFTWARE (SOFTWARE MASTER).
Abra el Diagrama de flujo de datos 0 en Visio o Visible Analyst. Vea la entrada del repositorio FORMULARIO DE
SOFTWARE RECIBIDO (SOFTWARE RECEIVED FORM) para el flujo de datos. Haga clic en el vínculo para el
NUEVO REGISTRO DE SOFTWARE (NEW SOFTWARE RECORD) en la Composición (Composition) para ver la
estructura de datos que contiene los elementos requeridos en el formulario. Haga clic en el vínculo (o en Saltar [Jump]
en Visible Analyst) a cada elemento para determinar la longitud del campo en pantalla.
E-2. Diseñe la pantalla AGREGAR REGISTRO DE SOFTWARE (ADD SOFTWARE RECORD), ya sea en papel o modificando
la pantalla de Microsoft Access. Use los campos que creó en el ejercicio E-1. El nombre de la estructura de datos de la página
Web del repositorio o de Visible Analyst es NUEVO REGISTRO DE SOFTWARE (NEW SOFTWARE RECORD).
www.xlibros.com
402 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
E-3. Hy Perteks desea un formulario para llenarlo a medida que aprende sobre los nuevos expertos de software. Use la estruc-
tura de datos del repositorio llamada AGREGAR EXPERTO DE SOFTWARE (ADD SOFTWARE EXPERT) para de-
terminar los campos requeridos para el formulario.
E-4. Cree la pantalla AGREGAR EXPERTO DE SOFTWARE en papel, mediante el uso de un procesador de palabras o
modifique el formulario de Microsoft Access. Pruebe la pantalla AGREGAR EXPERTO DE SOFTWARE; use la lista
desplegable y observe la barra de estado en la parte inferior de la pantalla.
E-5. Diseñe o modifique el formulario de Microsoft Access para la pantalla ELIMINAR EXPERTO DE SOFTWARE
(DELETE SOFTWARE EXPERT). ¿Qué campos son listas desplegables? Use la estructura de datos del reposito-
rio llamada ELIMINAR EXPERTO DE SOFTWARE.
E-6. Diseñe o modifique el formulario de Microsoft Access para la pantalla ELIMINAR REGISTRO DE COMPUTA-
DORA (DELETE COMPUTER RECORD). La estructura de datos del repositorio se llama ELIMINAR REGIS-
TRO DE COMPUTADORA.
E-7. Cher Ware y Anna pasaron una buena parte de una mañana trabajando en los detalles sobre la porción de software del
sistema. Invadida por el problema de proveer actualizaciones de software consistentes para todas las máquinas, a Cher le
gustaría un método fácil para la actualización. Tal vez se retengan unas cuantas versiones antiguas de software para ne-
cesidades especiales.
Parte de la solución es producir un informe, ordenado por ubicación, de todas las máquinas que contengan el software que
se va a actualizar. A medida que se instala el nuevo software se coloca una marca en el informe después de cada máquina.
Diseñe la pantalla ACTUALIZAR SOFTWARE (UPGRADE SOFTWARE). Agregue un botón Buscar (Find) para
localizar el título y proveer un campo que se pueda utilizar para introducir el nuevo NÚMERO DE VERSIÓN (VERSION
NUMBER). El programa de actualización mostrará una línea para cada máquina que contenga la versión anterior del
software instalado. Estas líneas se ordenan por UBICACIÓN DE CAMPUS (CAMPUS LOCATION) y UBICACIÓN
DE SALA (ROOM LOCATION).
Las columnas son UBICACIÓN DE CAMPUS (CAMPUS LOCATION). UBICACIÓN DE SALA (ROOM LOCA-
TION), NÚMERO DE INVENTARIO (INVENTORY NUMBER), NOMBRE DE MARCA (BRAND NAME), MODELO
(MODEL), ACTUALIZACIÓN (UPGRADE) y RETENER VERSIÓN ANTERIOR (RETAIN OLD VERSION). La co-
lumna ACTUALIZACIÓN contiene una casilla de verificación que se debe marcar si el software se va a actualizar. RE-
TENER VERSIÓN ANTERIOR también es una casilla de verificación, la cual está desmarcada de manera predeterminada.
Los usuarios marcan esa casilla para una máquina específica que deba retener las versiones anterior y nueva del software.
Busque en la estructura de datos del repositorio llamada ACTUALIZAR SOFTWARE (SOFTWARE UPGRADE)
los elementos contenidos en la pantalla.
E-8. Explique por qué la pantalla ACTUALIZAR SOFTWARE (SOFTWARE UPGRADE) debe mostrar las máquinas en vez
de hacer que Cher introduzca los ID de las máquinas. Describa en un párrafo por qué la pantalla muestra los registros en
una secuencia CAMPUS/SALA.
E-9. Diseñe la pantalla CAMBIAR SOFTWARE (CHANGE SOFTWARE). Esta pantalla permite a Cher Ware modificar
datos que se hayan introducido en forma incorrecta, además de información que cambia en forma rutinaria, como EX-
PERTO DE SOFTWARE (SOFTWARE EXPERT) y NÚMERO DE COPIAS (NUMBER OF COPIES). El NÚMERO
DE INVENTARIO DE SOFTWARE (SOFTWARE INVENTORY NUMBER) es la clave primaria y no se debe cambiar.
Los demás campos del ARCHIVO MAESTRO DE SOFTWARE (SOFTWARE MASTER) que se deben incluir en la
pantalla se encuentran en la estructura de datos del repositorio llamada SOFTWARE CHANGES (CAMBIOS DE SOFT-
WARE). Use estos campos para diseñar la pantalla. Se creó en Microsoft Access una pantalla limitada llamada CAM-
BIAR REGISTRO DE SOFTWARE (CHANGE SOFTWARE RECORD); use la Lista de campos (Field List) de
Microsoft Access para agregarle campos. Incluya los siguientes botones: Buscar (Find), Buscar siguiente (Find Next),
Registro anterior (Previous Record), Siguiente registro (Next Record), Guardar registro (Save Record) y Cancelar
cambios (Cancel changes).
E-10. Hy Pertks está preocupado de que los cursos anteriores para las versiones obsoletas de software estén atiborrando los
discos. Cree e imprima la pantalla ELIMINAR CURSO DE SOFTWARE (DELETE SOFTWARE COURSE).
Los campos de entrada son TÍTULO DE SOFTWARE (SOFTWARE TITLE), SISTEMA OPERATIVO (OPERA-
TING SYSTEM) y NÚMERO DE VERSIÓN (VERSION NUMBER). El programa muestra una lista para cada curso
que se enseña para la versión de software especificada. La primera columna contiene un campo de entrada con una D (de
eliminar, delete) que se presenta como valor predeterminado. Al colocar un espacio en el campo el registro no se elimi-
nará. Las demás columnas para cada línea son TÍTULO DEL CURSO (COURSE TITLE), NIVEL (LEVEL) y DU-
RACIÓN DE LA CLASE (CLASS LENGTH). Agregue un mensaje significativo para el operador.
E-11. Diseñe la pantalla ACTUALIZAR INFORMACIÓN DE MANTENIMIENTO (UPDATE MAINTENANCE INFORMA-
TION). Esta pantalla contiene los campos de entrada que permiten a Mike Crowe cambiar la información de mantenimiento
a medida que se reparan computadoras o al realizar el mantenimiento de rutina en ellas. La estructura de datos del reposi-
torio es ACTUALIZAR INFORMACIÓN DE MANTENIMIENTO (UPDATE MAINTENANCE INFORMATION).
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar archivos de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
C A P Í T U L O 13
Diseño de bases de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender los conceptos de bases de datos.
2. Usar la normalización para almacenar los datos con eficiencia en una base de datos.
3. Usar bases de datos para presentar la información.
4. Comprender el concepto de los almacenes de datos corporativos.
5. Comprender la utilidad de publicar las bases de datos en la Web.
BASES DE DATOS
Las bases de datos no son sólo una colección de archivos. Una base de datos es una fuente cen-
tral de datos con el fin de que varios usuarios la compartan para su uso en varias aplicaciones. El
corazón de una base de datos es el sistema de administración de bases de datos (DBMS), el cual
permite crear, modificar y actualizar la base de datos, la recuperación de los datos y la generación
de informes y pantallas. A la persona que asegura que la base de datos cumpla con sus objetivos se
le conoce como administrador de bases de datos.
Los objetivos de efectividad de la base de datos incluyen lo siguiente:
1. Asegurar que los datos se puedan compartir entre los usuarios y en varias aplicaciones.
2. Mantener datos precisos y consistentes.
3. Asegurar que todos los datos requeridos para las aplicaciones actuales y futuras estén siempre
disponibles.
403
www.xlibros.com
404 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 3 . 1
4. Permitir que la base de datos evolucione a medida que aumenten las necesidades de los usuarios.
5. Permitir que los usuarios construyan su propia vista personal de los datos sin preocuparse por la forma en
que éstos se almacenan físicamente.
La anterior lista de objetivos constituye un recordatorio de las ventajas y desventajas de la metodología de las
bases de datos. En primer lugar, compartir los datos significa que éstos se deben guardar sólo una vez, lo que a
su vez ayuda a asegurar su integridad, ya que las modificaciones a éstos se realizan con más facilidad y confiabi-
lidad si los datos aparecen sólo una vez y no en muchos archivos distintos.
Cuando un usuario necesita ciertos datos específicos, una base de datos bien diseñada se anticipa a la
necesidad de dichos datos (o tal vez ya se hayan utilizado en otra aplicación). En consecuencia, los datos
tienen una mayor probabilidad de estar disponibles en una base de datos que en un sistema de archivos con-
vencional. Una base de datos bien diseñada también puede ser más flexible que varios archivos separados;
es decir, una base de datos puede evolucionar a medida que cambian las necesidades de los usuarios y las
aplicaciones.
Por último, la metodología de las bases de datos tiene la ventaja de permitir que los usuarios tengan su pro-
pia vista de los datos. Los usuarios no necesitan preocuparse de la estructura de la base de datos ni con su alma-
cenamiento físico.
Muchos usuarios extraen partes de la base de datos central de las mainframes y las descargan en PC o dis-
positivos portátiles. Después, estas bases de datos reducidas se utilizan para generar informes o responder a las
consultas específicas para el usuario final.
Las bases de datos relacionales para las PC han mejorado considerablemente durante los últimos años.
Uno de los principales cambios tecnológicos ha sido el diseño de software de base de datos que aprovecha
la GUI. Con la llegada de programas como Microsoft Access, los usuarios pueden arrastrar y soltar campos
entre dos o más tablas. El desarrollo de bases de datos relacionales con estas herramientas se ha facilitado
mucho.
CONCEPTOS DE DATOS
Es importante comprender cómo se representan los datos antes de considerar el uso de archivos o de la metodo-
logía de las bases de datos. En esta sección veremos algunas definiciones críticas, incluyendo la abstracción de
los datos del mundo real hasta el almacenamiento de los datos en tablas, y las relaciones de bases de datos.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 405
FIGURA 13.1
Realidad Entidades Atributos Realidad, datos y metadatos.
Ocurrencias Ocurrencias de
Datos
de registros elementos de datos
Definiciones Definiciones de
Metadatos
de registros elementos de datos
www.xlibros.com
406 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 13.2
Ejemplos de diagramas E-R Relaciones
Los diagramas de entidad-relación
(E-R) pueden mostrar asociaciones
de uno a uno, de uno a muchos, de
muchos a uno o de muchos a Producto Empleado
muchos.
está
tiene asignado Uno a uno
a (1:1)
Médico Empleado
Uno a muchos
pertenece (1:M)
atiende o
a
Muchos a uno
(M:1)
Paciente Departamento
Estudiante Vendedor
da
toma servicio Muchos a muchos
a (M:N)
Cursos Ciudad
conecta dos entidades simples y los extremos de la línea están marcados con dos rayas pequeñas (||), existe una
relación de uno a uno. Después observará una pata de cuervo con una raya pequeña (|); cuando esta notación vincula a
las entidades, indica una relación de uno a uno o de uno a muchos (a uno o más).
Las entidades vinculadas con una línea recta más una raya corta (|) y un cero (que parece más un círculo,
O) describen una relación de uno a cero o de uno a uno (sólo cero o uno). Un cuarto tipo de vínculo para rela-
cionar entidades se dibuja con una línea recta marcada en un extremo con un cero (O) seguido de una pata de
cuervo. Este tipo muestra una relación de cero a cero, de cero a uno o de cero a muchos. Por último, una línea
recta que vincula entidades con una pata de cuervo en un extremo describe una relación a más de uno.
Una entidad puede tener una relación que se conecta a sí misma. Este tipo de relación se denomina relación
de autounión; la implicación es que debe haber una forma de vincular un registro de un archivo a otro registro
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 407
FIGURA 13.3
Símbolo Explicación oficial Lo que realmente significa
Los símbolos del diagrama
entidad-relación y sus
significados.
del mismo archivo. Podemos encontrar un ejemplo de relación de autounión en las simulaciones de HyperCase
que se incluyen en estos capítulos. Una tarea puede tener una tarea anterior (es decir, una que se deba completar
antes de poder empezar la tarea actual). En esta situación, un registro (la tarea actual) apunta a otro registro (la
tarea anterior) en el mismo archivo.
Las relaciones en palabras se pueden escribir a lo largo de la parte superior o lateral de cada línea conectora.
En la práctica se ve la relación en una dirección, aunque podemos escribir relaciones en ambos lados de la línea,
cada una de las cuales representa el punto de vista de una de las dos entidades (vea el capítulo 2 para obtener
más detalles sobre cómo dibujar diagramas E-R).
UN EJEMPLO DE ENTIDAD-RELACIÓN En la figura 13.4 podemos ver un ejemplo de un diagrama entidad-relación
que contiene muchas entidades, muchos tipos distintos de relaciones y numerosos atributos. El diagrama E-R
tiene que ver con un sistema de facturación, en especial con la parte del sistema relacionada con la prescripción
(por cuestión de simpleza vamos a suponer que las visitas al consultorio se manejan de una manera distinta y
están fuera del alcance de este sistema).
Las entidades son PRESCRIPCIÓN, MÉDICO, PACIENTE y COMPAÑÍA DE SEGUROS. La entidad
TRATAMIENTO no es importante para el sistema de facturación, pero forma parte del diagrama E-R debido a
que se utiliza como puente para PRESCRIPCIÓN y PACIENTE. Por lo tanto la dibujamos como entidad asocia-
tiva en la figura.
Aquí, un MÉDICO atiende a muchos PACIENTE(s) (1:M), cada uno de los cuales está suscrito a una COM-
PAÑÍA DE SEGUROS individual. Desde luego que el PACIENTE es sólo uno de los muchos pacientes que se
suscriben a esa COMPAÑÍA DE SEGUROS (M:1) específica.
Para completar los registros del MÉDICO, éste necesita mantener información sobre los tratamientos que
ha llevado un PACIENTE. Muchos PACIENTE(s) experimentan muchos TRATAMIENTO(s), lo cual la con-
www.xlibros.com
408 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
(Nombre-producto,
(Nombre-paciente,
experimenta Nombre-paciente,
Dirección-paciente,
Paciente Tratamiento Descripción,
Teléfono-paciente,
se aplica a Fecha,
Fecha-primera-visita)
Síntoma)
se
pertenece
asegura suscribe incluye
a
a
(Nombre-producto,
(Nombre-aseguradora,
Dosis,
Dirección-aseguradora, Aseguradora Prescripción
Fabricante,
Descripción-plan)
Cantidad)
vierte en una relación de muchos a muchos (M:N). El TRATAMIENTO se representa como una entidad aso-
ciativa debido a que no es importante en nuestro sistema de facturación por sí solo. Los TRATAMIENTO(s)
pueden incluir tomar PRESCRIPCIÓN(es), por lo cual también es una relación M:N debido a que muchos tra-
tamientos pueden requerir combinaciones de farmacéuticos y muchos fármacos pueden funcionar para muchos
tratamientos.
Después se llenan ciertos detalles para los atributos. Éstos se enlistan a un lado de cada una de las entidades
y se subraya la clave. Por ejemplo, la entidad PRESCRIPCIÓN tiene NOMBRE PRODUCTO, DOSIS, FABRI-
CANTE y CANTIDAD. En teoría sería benéfico diseñar una base de datos de esta forma, utilizando diagramas
entidad-relación y después completando los detalles concernientes a los atributos. Esta metodología arriba-abajo
es conveniente, pero algunas veces es difícil de lograr.
ATRIBUTOS Un atributo es cierta característica de una entidad. Puede haber muchos atributos para cada
entidad. Por ejemplo, un paciente (entidad) puede tener muchos atributos tales como apellido paterno, primer
nombre, dirección, ciudad, estado, etcétera; la fecha de la última visita del paciente, así como los detalles de las
prescripciones también son atributos. Cuando construimos el diccionario de datos en el capítulo 8, el elemento
más pequeño que describimos se denominó elemento de información. Al hablar sobre archivos y bases de datos,
estos elementos de datos se denominan comúnmente elementos de datos. De hecho, los elementos de datos son
las unidades más pequeñas en un archivo o base de datos. El término elemento de datos se puede intercambiar
con la palabra atributo.
Los elementos de datos pueden tener valores. Estos valores pueden ser de longitud fija o variable; pueden
ser caracteres alfabéticos, numéricos, especiales o alfanuméricos. En la figura 13.5 encontrará ejemplos de ele-
mentos de datos y sus valores.
Algunas veces a un elemento de datos también se le conoce como campo. Sin embargo, un campo representa
algo físico, no lógico. Por lo tanto, muchos elementos de datos se pueden empaquetar en un campo; el campo se
puede leer y convertir en varios elementos de datos. Un ejemplo común de esto es guardar la fecha en un solo
campo como MM/DD/AAAA. Para ordenar el archivo por fecha, se extraen tres elementos de datos separados
del campo y se ordenan primero por AAAA, después por MM y finalmente por DD.
REGISTROS Un registro es una colección de elementos de datos que tienen algo en común con la entidad descrita.
La figura 13.6 es una ilustración de un registro con muchos elementos de datos relacionados. El registro que se
muestra es para un pedido realizado con una empresa de pedidos por correo. PEDIDO-#, APELLIDO PATERNO,
INICIAL, DIRECCIÓN CALLE, CIUDAD, ESTADO y TARJETA CRÉDITO son todos atributos. La mayoría
de los registros son de longitud fija, por lo que no hay necesidad de determinar la longitud del registro cada vez
que se utiliza.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 409
FIGURA 13.5
Entidad Elemento de datos Valor
Los valores típicos asignados a los
Vendedor Número vendedor 87254 elementos de datos pueden ser
Nombre vendedor Kaytell números, caracteres alfabéticos,
Nombre empresa Music Unlimited caracteres especiales y
Dirección 45 Arpeum Circle combinaciones de los tres.
Ventas $20,765
Paquete Anchura 2
Altura 16
Longitud 16
Peso 3
Dirección postal 765 Dulcinea Drive
Dirección retorno P.O. Box 341, Spring Valley, MN
Bajo ciertas circunstancias (por ejemplo, cuando el espacio es una prioridad) se utilizan registros de longi-
tud variable. Este tipo de registro se utiliza como alternativa para reservar una gran cantidad de espacio para el
registro más largo posible, como el número máximo de veces que haya visitado un paciente a un médico. Cada
visita contendría muchos elementos de datos que formarían parte del registro completo del paciente (o carpeta de
archivo en un sistema manual). Más adelante en el capítulo hablaremos sobre la normalización de una relación.
La normalización es un proceso que elimina a los grupos repetitivos que se encuentran en los registros de longi-
tud variable.
CLAVES Una clave es uno de los elementos de datos en un registro que se utiliza para identificarlo. Cuando una
clave identifica a un registro en forma única, se le llama clave primaria. Por ejemplo, PEDIDO-# puede ser
una clave primaria, ya que sólo se asigna un número a cada pedido del cliente. De esta forma, la clave primaria
identifica a la entidad del mundo real (pedido del cliente).
Hay que tener cuidado especial a la hora de diseñar la clave primaria. A menudo es un número secuencial o
un número secuencial con un número autoverificable (llamado dígito de verificación) al final. A veces hay cierto
significado integrado en la clave primaria, pero definir una clave primaria con base en un atributo se considera
un riesgo: si cambia el atributo, la clave primaria también cambiará y se creará una dependencia entre la clave
primaria y los datos.
FIGURA 13.6
Registro Un registro tiene una clave
primaria y puede tener muchos
atributos.
APELLIDO
PEDIDO-# INICIAL DIRECCIÓN CALLE CIUDAD ESTADO TARJETA CRÉDITO
PATERNO
Clave Atributos
www.xlibros.com
410 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Un ejemplo de clave primaria basada en datos es el uso de una abreviatura de estado para el nombre de un
estado o el código de equipaje de una aerolínea para el nombre de un aeropuerto. A un atributo o colección de
atributos que pueden servir como clave primaria se le denomina clave candidata. Una clave primaria también
debe ser mínima y no debe contener atributos adicionales que sean necesarios para identificar a un registro.
A una clave se le denomina clave secundaria si no puede identificar a un registro en forma única. Las claves
secundarias pueden ser únicas o pueden identificar a varios registros en una base de datos. Las claves secundarias
se pueden utilizar para seleccionar un grupo de registros que pertenezcan a un conjunto (por ejemplo, pedidos
del estado de Virginia).
Cuando no es posible identificar a un registro en forma única mediante el uso de los elementos de datos en-
contrados en un registro, podemos construir una clave al elegir dos o más elementos de datos y combinarlos.
A esta clave se le denomina clave concatenada o compuesta. Cuando se utiliza un elemento de datos como clave
en un registro, la descripción se subraya. Por lo tanto, en el registro de PEDIDO (PEDIDO-# APELLIDO PA-
TERNO, INICIAL, DIRECCIÓN CALLE, CIUDAD, ESTADO, TARJETA CRÉDITO) la clave es PEDIDO-#.
Si un atributo es una clave en otro archivo, se debe subrayar con una línea punteada.
Algunas bases de datos permiten al desarrollador usar un identificador de objetos (OID), una clave única
para cada registro en la base de datos, no sólo en una tabla. Dado un identificador de objetos, se obtendrá un
registro sin importar la tabla en la que exista. Éste se puede incluir con un pedido o una confirmación de pago,
junto con un mensaje como: “Éste es su número de confirmación”.
METADATOS Los metadatos son datos sobre los datos del archivo o base de datos. Los metadatos describen el
nombre proporcionado y la longitud asignada a cada elemento de datos. Los metadatos también describen la
longitud y la composición de cada uno de los registros.
La figura 13.7 es un ejemplo de metadatos para una base de datos para cierto software genérico. La longitud
de cada elemento de datos se indica de acuerdo con una convención, donde 7.2 significa que se reservan siete
espacios para el número, dos de los cuales están a la derecha del punto decimal. La letra N significa “numérico”
y la A significa “alfanumérico”. La D representa a la “fecha” y se establece de manera automática en la forma
MM/DD/AAAA. Algunos programas como Microsoft Access usan inglés o español simple para los metadatos,
por lo que se utilizan palabras como text (texto), currency (moneda) y number (número). Microsoft Access pro-
vee un valor predeterminado de 50 caracteres como longitud de campo para los nombres, lo cual está bien si tra-
bajamos con sistemas pequeños, sin embargo, si va a trabajar con una base de datos extensa para un banco o una
compañía de servicios púbicos, por ejemplo, no es conveniente que dedique todo ese espacio a ese campo, pues
de lo contrario la base de datos crecería mucho y se llenaría de espacio desperdiciado. Aquí es cuando podemos
usar metadatos para planear con anticipación y diseñar una base de datos más eficiente.
Archivos
Un archivo contiene grupos de registros que se utilizan para proveer información para operaciones, planeación,
administración y toma de decisiones. Primero hablaremos sobre los tipos de archivos utilizados y después descri-
biremos las diversas formas en que se pueden organizar los archivos convencionales.
TIPOS DE ARCHIVOS Podemos usar los archivos para guardar datos durante un periodo indefinido o almacenarlos
provisionalmente con un propósito específico. Los archivos maestros y los archivos de tablas se utilizan para
almacenar datos por un periodo prolongado. Los archivos temporales por lo general se denominan archivos de
transacciones, archivos de trabajo o archivos de informes.
Archivos maestros Los archivos maestros contienen registros para un grupo de entidades. Estos atributos se
pueden actualizar con frecuencia, pero los registros en sí son relativamente permanentes. Estos archivos tienden
a tener registros extensos que contienen toda la información sobre una entidad de datos. Por lo general cada
registro contiene una clave primaria y varias claves secundarias.
Aunque el analista tiene la libertad de ordenar los elementos de datos en un archivo maestro en cualquier
orden, una disposición habitual es colocar el campo de la clave primaria primero, seguido de los elementos des-
criptivos y al último los elementos que cambian con frecuencia con base en las actividades de negocios. Ejem-
plos de un archivo maestro son los registros de pacientes, los registros de clientes, un archivo de personal y un
archivo de inventario de piezas.
Archivos de tablas Un archivo de tablas contiene los datos que se utilizan para calcular más datos o medidas de
desempeño. Un ejemplo es una tabla de las tarifas postales empleada para determinar los costos de envío de un
paquete; otro ejemplo es una tabla de impuestos. Por lo general sólo un programa lee los archivos de tablas.
Archivos de transacciones Un archivo de transacciones se utiliza para introducir las modificaciones que
actualizan el archivo maestro y producen informes. Suponga que el archivo maestro de suscriptores de un
periódico necesita actualizarse; el archivo de transacciones contendría el número de suscriptor y un código de
transacción, como E para extender la suscripción, C para cancelarla o D para cambiar la dirección. Así sólo hay
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 411
Producto(s) A 4
Descripción(es) A 30
Cantidad solicitada N 2
Apellido del cliente A 24
Primera inicial A 1
Dirección (calle) A 28
Ciudad A 12
Estado A 2
Código postal N 9
Número de tarjeta de crédito N 10
Fecha en que se hizo el pedido D 8 MM/DD/AAAA
Cantidad $ 7.2
Estado A 22
que el
7.2 significa
po co nt ie ne 7 Se pueden
cam
do s de los especificar
dígitos,
n a la
cuales está nto formatos
para
derecha de
l pu especiales
decimal. los campos.
que introducir la información relevante a las necesidades de actualización; es decir, la longitud de la renovación
si es E y la dirección si es D. No se requeriría información adicional si se cancelara la suscripción. El resto de la
información ya existe en el archivo maestro. Los archivos de transacciones pueden contener varios tipos de
registros, como los tres que se utilizan para actualizar el archivo maestro de suscripciones al periódico, con un
código en el archivo de transacciones para indicar el tipo de transacción.
Archivos de informes Cuando es necesario imprimir un informe y no hay una impresora disponible (por ejemplo,
cuando está ocupada imprimiendo otros trabajos), se utiliza un archivo de informes. Al proceso de enviar la
salida a un archivo en vez de enviarla a una impresora se le conoce como puesta en cola, o “spooling”. Después,
cuando el dispositivo está listo se puede imprimir el documento. Los archivos de informes son muy útiles, ya que
los usuarios pueden llevar los archivos a otros sistemas computarizados y enviarlos como salida a dispositivos
especializados.
www.xlibros.com
412 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 13.8
El diseño de bases de datos
incluye sintetizar los informes de
los usuarios, las vistas de usuario
y los diseños lógicos y físicos.
Informes de usuario
(Salidas en formato tabular, gráficas, etc.)
Esquema conceptual
(Modelo de diseño lógico de la base de datos)
Esquema interno
(Modelo de diseño físico de la base de datos)
En la literatura de bases de datos, las vistas se conocen como esquema. La figura 13.8 muestra cómo están
relacionados los informes y las vistas de usuario (esquema de usuario) con el modelo lógico (esquema concep-
tual) y el diseño físico (esquema interno).
Hay tres tipos principales de bases de datos estructuradas en forma lógica: jerárquicas, de redes y relacio-
nales. Podemos encontrar los primeros dos tipos en sistemas heredados (antiguos). En la actualidad, el analista
comúnmente diseña una base de datos relacional.
ESTRUCTURAS DE DATOS RELACIONALES Una estructura de datos relacional consiste en uno o más tablas
bidimensionales, las cuales se conocen como relaciones. Las filas de la tabla representan los registros y las
columnas contienen atributos.
La figura 13.9 muestra la estructura relacional para una base de datos de pedidos de CD musicales. Aquí se
necesitan tres tablas para: 1) describir los artículos y llevar el registro del precio actual de CD (PRECIO
ARTICULO), 2) describir los detalles del pedido (PEDIDO) y 3) identificar el estado del pedido (ESTADO AR-
TICULO).
Para determinar el precio de un artículo necesitamos conocer el número de artículo para encontrarlo en la
relación PRECIO ARTICULO. Para actualizar el número de tarjeta de crédito de G. MacRae, podemos buscar
la relación PEDIDO para MacRae y corregirla sólo una vez, incluso cuando él pidió muchos CD. Sin embargo,
para averiguar el estado de parte de un pedido debemos conocer ARTICULO-# y PEDIDO-#; después debemos
localizar esa información en la relación ESTADO PEDIDO.
La labor de mantenimiento de las tablas en una estructura relacional es bastante simple, si se le compara con
la labor de mantenimiento de una estructura jerárquica o de red. Una de las principales ventajas de las estructuras
relacionales es que las consultas ad hoc se manejan con eficiencia.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 413
FIGURA 13.9
PRECIO ARTICULO En una estructura de datos
ARTICULO-# TITULO PRECIO relacional, los datos se almacenan
en muchas tablas.
B235 Guys and Dolls 8.99
B521 My Fair Lady 6.99
B894 42nd Street 10.99
B992 A Chorus Line 10.99
PEDIDO
APELLIDO
PEDIDO-# PATERNO I DIRECCIÓN CALLE CIUDAD EDO CTA COBRO
ESTADO ARTICULO
Cuando se analizan estructuras relacionales en la literatura sobre bases de datos, se utiliza con frecuencia
distinta terminología. A un archivo se le llama tabla o relación, a un registro por lo general se le denomina tupla
y al conjunto de valores de atributos se le conoce como dominio.
Para que las estructuras relacionales sean útiles y manejables, primero hay que normalizar las tablas relacio-
nales. En la siguiente sección veremos la normalización con detalles.
NORMALIZACIÓN
La normalización es la transformación de las vistas de usuario y almacenes de datos complejos en un conjunto
de estructuras de datos estables y más pequeñas. Además de ser más simples y estables, las estructuras de datos
normalizadas se pueden mantener con más facilidad que las demás estructuras.
www.xlibros.com
414 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Relación sin
normalizar
Relaciones
normalizadas
(1NF)
Relaciones en
segunda forma
normal (2NF)
Relaciones en
tercera forma
normal (3NF)
Un ejemplo de normalización
La figura 13.11 es una vista de usuario para la empresa Al S. Well Hydraulic Equipment Company. El informe
muestra los siguientes elementos: 1) NUMERO-VENDEDOR, 2) NOMBRE-VENDEDOR y 3) AREA-VEN-
TAS. El cuerpo del informe muestra el 4) NUMERO-CLIENTE y el 5) NOMBRE-CLIENTE. A continuación
está el 6) NUMERO-ALMACEN que dará servicio al cliente, seguido de la 7) UBICACION-ALMACEN, que es
la ciudad en la que se encuentra la empresa. La información final contenida en la vista de usuario es 8) MONTO-
VENTAS. Las filas (una para cada cliente) en la vista de usuario muestran que los elementos 4 a 8 forman un
grupo repetido.
Si el analista estuviera usando una metodología de flujo de datos/diccionario de datos, la misma información
en la vista de usuario aparecería en una estructura de datos. La figura 13.12 muestra cómo aparecería la estruc-
tura de datos en la etapa del análisis correspondiente al diccionario de datos. El grupo repetitivo también se in-
dica en la estructura de datos mediante un asterisco (*) y el uso de sangría.
Antes de continuar, observe las asociaciones de datos de los elementos de datos de la figura 13.13. A este
tipo de ilustración se le denomina diagrama de burbuja o diagrama de modelo de datos. Cada entidad está
encerrada en una elipse; se utilizan flechas para mostrar las relaciones. Aunque es posible dibujar estas rela-
ciones con un diagrama E-R, algunas veces es más fácil usar el diagrama de burbuja más simple para modelar
los datos.
En este ejemplo hay sólo un NUMERO-VENDEDOR asignado a cada NOMBRE-VENDEDOR y esa per-
sona sólo cubrirá un AREA-VENTAS, pero cada AREA-VENTAS se puede asignar a muchos vendedores: de
aquí que se utilice la notación de doble flecha de AREA-VENTAS a NUMERO-VENDEDOR. Para cada NU-
MERO-VENDEDOR puede haber muchos NUMERO(s)-VENDEDOR(es).
También habría una correspondencia de uno a uno entre NUMERO-CLIENTE y NOMBRE-CLIENTE;
lo mismo se aplica para NUMERO-ALMACEN y UBICACION-ALMACEN. NUMERO-CLIENTE(s) sólo
tendrá un NUMERO-ALMACEN y una UBICACION-ALMACEN, pero cada NUMERO-ALMACEN o
UBICACION-ALMACEN puede atender a muchos NUMERO(s)-CLIENTE(s). Por último, para determinar
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 415
FIGURA 13.11
Un reporte de usuario para la
empresa Al S. Well Hydraulic
Equipment Company.
Al S.
Hydraulic Equi Well
pmen
Spring Valley, t Company
Minnesota
Vendedor #:
3462
Nombre: Wat
ers
Área de ventas
: West
NÚMERO
NOMBRE
CLIENTE NÚMERO
CLIENTE UBICACIÓN
ALMACÉN
18765 ALMACÉN VENTAS
Delta Services
18830 M. Levy and So 4
ns Fargo
3 13,540
Bismarck
10,600
el MONTO-VENTAS de las llamadas de un vendedor a una empresa específica, es necesario conocer tanto el
NUMERO-VENDEDOR como el NUMERO-CLIENTE.
El principal objetivo del proceso de normalización es simplificar todos los elementos de datos complejos
que se encuentran con frecuencia en las vistas de usuario. Por ejemplo, si el analista tomara la vista de usua-
rio antes descrita y tratara de crear una tabla relacional con base en ella, su apariencia sería como en la figura
13.14. Como esta relación se basa en nuestra vista de usuario inicial, nos referimos a ella como INFORME-
VENTAS.
INFORME-VENTAS es una relación sin normalizar, ya que tiene grupos repetidos. También es importante
observar que un solo atributo tal como NUMERO-VENDEDOR no puede servir como la clave. La razón es clara
si examinamos las relaciones entre NUMERO-VENDEDOR y los otros atributos en la figura 13.15. Aunque hay
una correspondencia de uno a uno entre NUMERO-VENDEDOR y dos atributos (NOMBRE-VENDEDOR y
AREA-VENTAS), existe una relación de uno a muchos entre NUMERO-VENDEDOR y los otros cinco atribu-
FIGURA 13.12
Para el analista sería útil una
estructura de datos (de un
diccionario de datos) al desarrollar
NUMERO-VEND
EDOR una base de datos.
NOMBRE-VEND
EDOR
AREA-VENTAS
NUMERO-CLIENT
E* (1- )
NOMBRE-CLIENT
E
NUMERO-ALMAC
EN
UBICACION-ALM
ACEN
MONTO-VENTA
S
www.xlibros.com
416 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 13.13
Algunas veces dibujar diagramas NOMBRE-
de modelos de datos para las VENDEDOR
asociaciones de datos ayudan a los NUMERO-
analistas a apreciar la complejidad VENDEDOR
del almacenamiento de datos.
AREA-VENTAS
NUMERO- NOMBRE-
CLIENTE CLIENTE
NUMERO- UBICACION-
ALMACEN ALMACEN
NUMERO-
ALMACEN
NUMERO-
CLIENTE
UBICACION-
ALMACEN
NUMERO-
VENDEDOR
+ MONTO-VENTAS
NUMERO-
CLIENTE
VENDEDOR-CLIENTE (NUMERO-VENDEDOR,
NOMBRE-VENDEDOR, AREA
DE VENTAS
NUMERO-CLIENTE,
NOMBRE-CLIENTE,
NUMERO-ALMACEN,
UBICACION-ALMACEN,
MONTO-VENTAS)
donde el conjunto interno de paréntesis representa el grupo repetido.
FIGURA 13.14 NUMERO NOMBRE AREA NUMERO NOMBRE NUMERO UBICACION MONTO
Si los datos se listaran en una tabla VENDEDOR VENDEDOR VENTAS CLIENTE CLIENTE ALMACEN ALMACEN VENTAS
sin normalizar, podría haber
3462 Waters West 18765 Delta Systems 4 Fargo 13540
grupos repetitivos.
18830 A. Levy and Sons 3 Bismarck 10600
19242 Ranier Company 3 Bismarck 9700
3593 Dryne East 18841 R. W. Flood Inc. 2 Superior 11560
18899 Seward Systems 2 Superior 2590
19565 Stodola’s Inc. 1 Plymouth 8800
etc.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 417
FIGURA 13.15
NUMERO- Un diagrama de modelo de datos
VENDEDOR muestra que en la relación sin
normalizar, NUMERO-
VENDEDOR tiene una asociación
de uno a muchos con algunos
atributos.
NOMBRE- NUMERO-
VENDEDOR CLIENTE
NOMBRE-
AREA-VENTAS
CLIENTE
NUMERO-
ALMACEN
UBICACION-
ALMACEN
MONTO-VENTAS
PRIMERA FORMA NORMAL (1NF) El primer paso para normalizar una relación es eliminar los grupos repetidos.
En nuestro ejemplo, la relación sin normalizar INFORME-VENTAS se descompondrá en dos relaciones
separadas. Estas nuevas relaciones se llamarán VENDEDOR y VENDEDOR-CLIENTE.
La figura 13.16 muestra cómo se normaliza la relación INFORME-VENTAS al separar la relación en dos
nuevas relaciones. Cabe mencionar que la relación VENDEDOR contiene la clave primaria NUMERO-VENDE-
DOR y todos los atributos que no se repetían (NOMBRE-VENDEDOR y AREA-VENTAS).
La segunda relación, VENDEDOR-CLIENTE, contiene la clave primaria de la relación VENDEDOR (la
clave primaria de VENDEDOR es NUMERO-VENDEDOR) así como los atributos que formaban parte del
grupo repetido (NUMERO-CLIENTE, NOMBRE-CLIENTE, NUMERO-ALMACEN, UBICACION-ALMA-
CEN y MONTO-VENTAS). Sin embargo, conocer el NUMERO-VENDEDOR no implica que conoceremos
automáticamente el NOMBRE-CLIENTE, MONTO-VENTAS, UBICACION-ALMACEN, etcétera. En esta
relación debemos usar una clave concatenada (tanto NUMERO-VENDEDOR como NUMERO-CLIENTE) para
acceder al resto de la información. Es posible escribir las relaciones en notación abreviada, como se muestra a
continuación:
VENDEDOR-CLIENTE (NUMERO-VENDEDOR,
NUMERO-CLIENTE,
NOMBRE-CLIENTE,
NUMERO-ALMACEN,
UBICACION-ALMACEN,
MONTO-VENTAS)
La relación VENDEDOR-CLIENTE es una relación en primera forma normal, pero no está en su forma ideal.
Surgen problemas debido a que algunos de los atributos no son funcionalmente dependientes de la clave prima-
www.xlibros.com
418 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
etc.
VENDEDOR-CLIENTE
NUMERO NUMERO NOMBRE NUMERO UBICACION MONTO
VENDEDOR CLIENTE CLIENTE ALMACEN ALMACEN VENTAS
3462 18765 Delta Systems 4 Fargo 13540
ria (es decir, NUMERO-VENDEDOR, NUMERO-CLIENTE). En otras palabras, algunos de los atributos que
no son claves dependen sólo de NUMERO CLIENTE y no de la clave concatenada. El diagrama de modelo de
datos en la figura 13.17 muestra que MONTO-VENTAS depende de NUMERO-VENDEDOR y de NUMERO-
CLIENTE, pero los otros tres atributos dependen sólo de NUMERO-CLIENTE.
MONTO-
FIGURA 13.17 VENTAS
Un diagrama de modelo de datos
muestra que tres atributos son
dependientes de NOMBRE-
CLIENTE, por lo que la relación
aún no está normalizada. Tanto
NUMERO-VENDEDOR como NUMERO- NUMERO-
VENDEDOR CLIENTE
NUMERO-CLIENTE
tienen que buscar el MONTO-
VENTAS.
NOMBRE-
CLIENTE
NUMERO-
ALMACEN
UBICACION-
ALMACEN
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 419
SEGUNDA FORMA NORMAL (2NF) En la segunda forma normal, todos los atributos serán funcionalmente
dependientes de la clave primaria. Por lo tanto, el siguiente paso es eliminar todos los atributos parcialmente depen-
dientes y colocarlos en otra relación. La figura 13.18 muestra cómo se divide la relación VENDEDOR-CLIENTE
en dos nuevas relaciones: VENTAS y CLIENTE-ALMACEN. Estas relaciones también se pueden expresar de la
siguiente manera:
La relación CLIENTE-ALMACEN está en la segunda forma normal. Todavía se puede simplificar más debido
a que hay dependencias adicionales en la relación. Algunos de los atributos que no son claves dependen no sólo
de la clave primaria, sino también de un atributo que no es clave. Esta dependencia se denomina dependencia
transitiva.
La figura 13.19 muestra las dependencias en la relación CLIENTE-ALMACEN. Para que la relación asuma
la segunda forma normal, todos los atributos deben ser dependientes de la clave primaria NUMERO-CLIENTE,
como se muestra en el diagrama. Sin embargo, UBICACION-ALMACEN también depende obviamente de NU-
MERO-ALMACEN. Para simplificar esta relación se requiere otro paso.
VENDEDOR-CLIENTE
VENTAS
NUMERO NUMERO MONTO
VENDEDOR CLIENTE VENTAS
3462 18765 13540
www.xlibros.com
420 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 13.19
Un diagrama de modelo de datos NUMERO-
CLIENTE
muestra que existe una
dependencia transitiva entre
NUMERO-ALMACEN y
UBICACION-ALMACEN.
NOMBRE-
CLIENTE
NUMERO-
ALMACEN
UBICACION-
ALMACEN
TERCERA FORMA NORMAL (3NF) Una relación normalizada está en la tercera forma normal si todos los atributos
que no son claves son completa y funcionalmente dependientes de la clave primaria y no hay dependencias
transitivas (no claves). Al igual que en los pasos anteriores, es posible descomponer la relación CLIENTE-
ALMACEN en dos, como se muestra en la figura 13.20.
Las dos nuevas relaciones se llaman CLIENTE y ALMACEN, y se pueden escribir de la siguiente manera:
ALMACEN (NUMERO-ALMACEN,
UBICACION-ALMACEN)
La clave primaria para la relación CLIENTE es NUMERO-CLIENTE y la clave primaria para la relación AL-
MACEN es NUMERO-ALMACEN.
Además de estas claves primarias, podemos identificar a NUMERO-ALMACEN como una clave externa
en la relación CLIENTE. Una clave externa es cualquier atributo que no sea clave en una relación, pero que sea
CLIENTE ALMACEN
NUMERO NOMBRE NUMERO NUMERO UBICACION
CLIENTE CLIENTE ALMACEN ALMACEN ALMACEN
18765 Delta Systems 4 4 Fargo
18830 A. Levy and Sons 3 3 Bismarck
19242 Ranier Company 3 2 Superior
18841 R. W. Flood Inc. 2 1 Plymouth
18899 Seward Systems 2 etc.
etc.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 421
clave primaria en otra. Para designar a NUMERO-ALMACEN como clave externa en la notación anterior y en
las figuras, la pondremos subrayada: _____________.
Finalmente, la relación original sin normalizar INFORME-VENTAS se ha transformado en cuatro relacio-
nes 3NF. Al revisar las relaciones que se muestran en la figura 13.21, podemos ver que la relación individual
INFORME-VENTAS se transformó en las siguientes cuatro relaciones:
ALMACEN (NUMERO-ALMACEN,
UBICACION-ALMACEN)
La tercera forma normal es adecuada para la mayoría de los problemas de diseño de bases de datos. La simplifi-
cación que se obtiene al transformar una relación sin normalizar en un conjunto de relaciones en 3NF constituye
un enorme beneficio en cuanto al tiempo que se requiere para insertar, eliminar y actualizar información en la
base de datos.
En la figura 13.22 se muestra un diagrama E-R para la base de datos. Un VENDEDOR atiende a muchos
CLIENTE(s), quienes generan VENTAS y reciben sus artículos de un ALMACEN (el ALMACEN más cercano a
su ubicación). Tome su tiempo para observar cómo se relacionan las entidades y atributos con la base de datos.
Uso del diagrama entidad-relación para determinar las claves de los registros
Podemos usar el diagrama E-R para determinar las claves requeridas para un registro o una relación de la base
de datos. El primer paso es construir el diagrama E-R e identificar una clave única (primaria) para cada entidad
etc.
CLIENTE ALMACEN
NUMERO NOMBRE NOMBRE NOMBRE UBICACION
CLIENTE CLIENTE ALMACEN ALMACEN ALMACEN
18765 Delta Systems 4 4 Fargo
etc.
www.xlibros.com
422 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
se
llevan a genera
cabo por
(Numero-vendedor,
Numero-cliente, Ventas
Monto ventas)
son
accede
compradas
a
por
(Numero-cliente, recibe de
Nombre-cliente, (Numero-almacen,
Cliente Almacén
Numero-almacen) envía a Ubicacion-almacen)
de datos. La figura 13.23 muestra un diagrama E-R para un sistema de pedidos de clientes. Hay tres entidades de
datos: CLIENTE, con la clave primaria NUMERO-CLIENTE; PEDIDO, con la clave primaria NUMERO-
PEDIDO, y ARTICULO, con NUMERO-ARTICULO como clave primaria. Un CLIENTE puede colocar muchos
pedidos, pero cada PEDIDO puede ser colocado sólo por un CLIENTE, por lo que la relación es de uno a mu-
chos. Cada PEDIDO puede contener muchos ARTICULO(s), y cada ARTICULO puede estar contenido en muchos
PEDIDO(s), por lo que la relación PEDIDO-ARTICULO es de muchos a muchos.
Sin embargo, una clave externa es un campo de datos de cierto archivo que es la clave primaria de otro ar-
chivo maestro. Por ejemplo, un NUMERO-DEPARTAMENTO que indica que la especialidad de un estudiante
puede existir en la tabla MAESTRA DE ESTUDIANTES. NUMERO-DEPARTAMENTO también podría ser la
clave única para la tabla MAESTRA DE DEPARTAMENTOS.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 423
como un cliente con un subformulario de todos los pedidos del cliente. Si hubiera un extenso número de registros
del extremo de muchos, aparecerían barras de desplazamiento.
En situaciones simples, la relación también se podría implementar mediante el uso de una lista desple-
gable, donde cada registro del extremo de muchos se convertiría en una entrada en el extremo de uno; un
ejemplo es la pantalla de un automóvil junto con una lista desplegable que contenga todos los modelos de ese
automóvil. Al diseñar sitios Web, la información del extremo de uno podría estar en la parte superior de la
página, con varios grupos de datos debajo de ésta o varios vínculos a los datos. Un ejemplo es un tema en un
motor de búsqueda que produce como resultado muchos vínculos coincidentes, o un género de música y mu-
chos artistas que coinciden con ese género.
PEDIDO-
PEDIDO-ARTICULO ARTICULO sirve
como vínculo.
NUMERO NUMERO CANTIDAD
PEDIDO ARTICULO ORDENADA
MAESTRA DE ARTICULOS
www.xlibros.com
424 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Restricciones de integridad
Las restricciones de integridad son reglas que gobiernan las acciones de modificar y eliminar registros, y que
ayudan a mantener la precisión de los datos en la base de datos. Podemos aplicar tres tipos de restricciones de
integridad a una base de datos:
1. Integridad de entidad.
2. Integridad referencial.
3. Integridad de dominio.
Las restricciones de integridad de entidad son reglas que gobiernan la composición de claves primarias. La clave
primaria no puede tener un valor nulo; si la clave primaria es una clave compuesta, ninguno de los campos que
componen la clave puede contener un valor nulo. Algunas bases de datos nos permiten definir una restricción
única o una clave única. Esta clave única sólo identifica un registro que no es una clave primaria. La diferencia
ente una clave única y una clave primaria es que una clave única puede contener un valor nulo.
La integridad referencial gobierna la naturaleza de los registros en una relación de uno a muchos. La tabla
que está conectada en el extremo de uno de la relación se llama padre. La tabla conectada al extremo de muchos
de la relación se llama tabla hija. Integridad referencial significa que todas las claves externas en la tabla de mu-
chos (la tabla hija) deben tener un registro que coincida en la tabla padre. Por ende, no podemos agregar un re-
gistro en la tabla hija (muchos) sin un registro que coincida en la tabla padre.
Una segunda implicación es que no podemos cambiar una clave primaria que tenga registros que coincidan
en la tabla hija. Si pudiéramos cambiar el registro padre, el resultado sería un registro hijo que tendría un distinto
registro padre o un registro huérfano, o un registro hijo sin un registro padre. Algunos ejemplos son un registro
CALIFICACION para un estudiante que no estuviera en la tabla MAESTRA DE ESTUDIANTES y un registro PE-
DIDO para un NUMERO CLIENTE inexistente. La última implicación de la integridad referencial es que no
podemos eliminar un registro padre que tenga registros hijos. Eso también produciría los registros huérfanos que
mencionamos antes.
La integridad referencial se implementa de dos formas. La primera es tener una base de datos restringida, en
la cual el sistema pueda actualizar o eliminar un registro padre sólo si no hay registros hijos que coincidan. Una
base de datos en cascada eliminará o actualizará todos los registros hijos cuando se elimine o modifique un regis-
tro padre (el padre desencadena los cambios).
Es mejor una relación restringida al eliminar registros. ¡No sería conveniente eliminar un registro de un
cliente y eliminar también todas las facturas pendientes! La metodología en cascada es mejor a la hora de modi-
ficar registros. Si se modifica la clave primaria del registro de un estudiante, se modificarían también las claves
externas (el NUMERO ESTUDIANTE en la tabla MAESTRA DE CURSOS) en todos los registros de cursos
para ese estudiante.
Las reglas de integridad de dominio se utilizan para validar los datos, como las comprobaciones de valida-
ción de tabla, límite, rango, etcétera. En el capítulo 15 explicaremos estas reglas con más detalle. Por lo gene-
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 425
ATRACTIVO DE LA MAC
Aunque Microsoft Word, Excel y PowerPoint están disponibles para el sistema operativo de la Mac, la única forma de
ejecutar Microsoft Access es ejecutar Windows en modo de virtualización o iniciar directamente en Windows. Existen
otras dos opciones para la Mac: Bento y FileMaker Pro. Bento es una base de datos personal que permite a los usuarios
recopilar información en forma eficiente de la libreta de direcciones, la aplicación de calendario, Apple Mail y Micro-
soft Excel; después podemos agregar campos al instante para crear una base de datos personalizable.
Tal vez algunos usuarios encuentren a Bento algo limitante; para estos casos está el hermano mayor de Bento,
FileMaker Pro. Éste es un programa completo de bases de datos relacionales que proporciona acceso directo a bases de
datos de SQL. Su característica distintiva es que las pantallas, los formularios y los informes para acceder a la base de datos
están completamente integrados con el motor de bases de datos.
FIGURA 13.MAC
Ejemplo de pantalla de Bento, una base de datos personal. Esta pantalla se utilizó con
permiso de FileMaker, Inc.
ral, las reglas de dominio de integridad se almacenan en la estructura de la base de datos en una de dos formas.
Las restricciones de verificación se definen a nivel de tabla y pueden hacer referencia a uno o más campos en
la tabla. Un ejemplo es que la FECHA DE COMPRA siempre es menor o igual a la fecha actual. Las reglas se
definen a nivel de base de datos con objetos separados y se pueden utilizar con varios campos. Un ejemplo es un
valor mayor a cero que se utilice para validar varios elementos.
Anomalías
Pueden ocurrir cuatro anomalías al crear tablas de bases de datos:
1. Redundancia de datos.
2. Anomalía de inserción.
3. Anomalía de eliminación.
4. Anomalía de actualización.
La redundancia de los datos ocurre cuando se almacenan los mismos datos en más de un lugar en la base
de datos (exceptuando las claves primarias que se almacenan como claves externas). Para resolver este problema
hay que crear tablas que estén en 3NF.
www.xlibros.com
426 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Una anomalía de inserción ocurre cuando no se conoce toda la clave primaria y la base de datos no puede
insertar un nuevo registro, el cual violaría la integridad de entidad. Este problema ocurre por lo general cuando la
clave primaria es una clave compuesta que contiene varios atributos más pequeños. Para evitar una anomalía de
inserción hay que utilizar un número de secuencia para la clave primaria.
Una anomalía de eliminación ocurre cuando se elimina un registro y como resultado se pierden otros da-
tos relacionados. Un ejemplo es cuando un artículo tiene un número de distribuidor y ese artículo específico
es la única referencia a cierto distribuidor. Si se elimina ese artículo, no habría referencia al registro del dis-
tribuidor.
Una anomalía de actualización se produce cuando un cambio en el valor de un atributo ocasiona que la base
de datos contenga datos inconsistentes o haya que modificar varios registros. Un ejemplo es cuando cambia el
nombre de una calle en una ciudad. Podríamos cambiar algunos de los nombres de las calles y otros no, o ten-
dríamos que asegurarnos que se hayan cambiado los nombres de todas las calles. Esto puede ocurrir cuando hay
dependencias transitivas y podemos prevenirlo mediante la creación de tablas que estén en 3NF (aunque en el
ejemplo de la calle, tal vez los datos estén en 3NF).
DESNORMALIZACIÓN
Una de las principales razones de la normalización es organizar los datos de manera que se reduzcan los datos
redundantes. Si no tenemos que almacenar los mismos datos una y otra vez, podemos ahorrar mucho espacio.
Dicha organización permite al analista reducir la cantidad de almacenamiento necesario, algo que era muy im-
portante cuando el almacenamiento era costoso.
En la última sección aprendimos que para usar datos normalizados tuvimos que progresar por una serie de
pasos que involucran la unión, el ordenamiento y la síntesis. Cuando la velocidad de consultar la base de datos
(es decir, hacer una pregunta y requerir una respuesta rápida) es crítica, tal vez sea importante almacenar los da-
tos de otras formas.
La desnormalización es el proceso de tomar el modelo de datos lógico y transformarlo en un modelo físico
que sea eficiente para las tareas requeridas con más frecuencia. Estas tareas pueden incluir la generación de in-
formes, pero también pueden implicar consultas más eficientes. Las consultas complejas como el procesamiento
analítico en línea (OLAP), así como los procesos de minería de datos y descubrimiento de conocimiento en bases
de datos (KDD), también pueden usar bases de datos que estén desnormalizadas.
Podemos llevar a cabo la desnormalización de varias formas. La figura 13.26 muestra uno de los métodos.
Primero podemos tomar una relación de muchos a muchos, como la de VENDEDOR y CLIENTE, que compar-
ten la entidad asociativa VENTAS. Al combinar los atributos de VENDEDOR y VENTAS podemos evitar uno
de los procesos de unión. Esto puede producir una cantidad considerable de duplicación de datos, pero mejora la
eficiencia de las consultas sobre los patrones de ventas.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 427
FIGURA 13.25
Los datos se obtienen y presentan
en ocho pasos.
Seleccionar una(s)
relación(es) de la base
de datos.
Seleccionar filas de
la relación.
Otra de las razones de desnormalizar es evitar la referencia repetida a una tabla de búsqueda. Tal vez sea
más eficiente repetir la misma información (por ejemplo: ciudad, estado y código postal) incluso si por lo gene-
ral esta información se puede almacenar sólo como un código postal. Por ende, en el ejemplo de ventas podría-
mos combinar CLIENTE y ALMACEN.
Finalmente veremos las relaciones de uno a uno, ya que es muy probable que se combinen por razones prác-
ticas. Si descubrimos que muchas de las consultas relacionadas con los pedidos también se interesan en saber
cómo se envió el pedido, sería conveniente combinar, o desnormalizar. Así, en el ejemplo algunos de los detalles
pueden aparecer tanto en DETALLES-PEDIDO como en DETALLES-ENVIO al llevar a cabo la desnormaliza-
ción.
www.xlibros.com
428 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
VENDEDOR VENTAS
CLIENTE ALMACEN
DETALLES-PEDIDO
DETALLES-ENVIO
VENTAS-VENDEDOR-DESNORMALIZADA
de
Combinación
con
una entidad
una entidad
asociativa
CLIENTE-DESNORMALIZADA
de
Combinación
relaciones 1:1
de
Combinación
tablas de
búsqueda
DETALLES-PEDIDOS-DESNORMALIZADA
NUMERO NOMBRE NUMERO FECHA MONTO NUMERO NOMBRE DIRECCION FECHA ENVIO
CLIENTE CLIENTE PEDIDO PEDIDO PEDIDO ENVIO ENVIO ENVIO
DETALLES-ENVIO-DESNORMALIZADA
FIGURA 13.26
Tres ejemplos de
desnormalización para hacer el
acceso más eficiente.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 429
Minería de datos
La minería de datos puede identificar patrones que un humano no puede. O el encargado de tomar decisiones
no puede ver un patrón, o tal vez no puede pensar en preguntar si existe ese patrón. Los algoritmos de minería
de datos buscan patrones en los almacenes corporativos de datos mediante el uso de algoritmos. La figura 13.27
ilustra el concepto de minería de datos.
www.xlibros.com
430 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 3 . 2
La minería de datos se conoce también por otro nombre: descubrimiento de conocimiento en bases de da-
tos (KDD). Algunos piensan que KDD es distinto a la minería de datos, debido a que su objetivo es ayudar a
los encargados de tomar decisiones a encontrar patrones, en vez de ceder el control a un algoritmo para que los
encuentre. Las ayudas disponibles para las decisiones se conocen como siftware; incluyen el análisis estadístico,
los árboles de decisión, las redes neurales, los agentes inteligentes, la lógica difusa y la visualización de datos.
FIGURA 13.27 ID
Name Customer Order
Description Contains customer
customer master and order information and
is used to update the
Customer Destination
Form
Data Structure Traveling Internal
Tarjeta de
anticiparse a sus preferencias. garantía que envió
Prospectos/listas Información de
el cliente
de correo de otras la encuesta que
empresas llenó el cliente
Datos que se
Datos mantienen en
externos forma interna
Datos
externos
Datos demográficos
del cliente procedentes
de la municipalidad
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 431
O P O R T U N I D A D D E C O N S U LT O R Í A 1 3 . 3
Pérdida de prospectos
“L a participación en el mercado puede ser un verdadero pro-
blema”, dice Ryan Taylor, director de sistemas de marketing para
equivocada de un prospecto, podría retirarme y mudarme a Flo-
rida”, bromea Ryan. “Mi trabajo es identificar cuáles prospectos
una aseguradora médica de la Costa Este de Estados Unidos. “Uno son malos. No es muy difícil si sólo hay unos cuantos miles, pero
de los mayores retos al que hacemos frente es cómo identificar ¿qué hace uno cuando hay más de un cuarto de millón?”.
buenos prospectos para nuestros vendedores. Con más del 50 por Ryan continúa, “Como usamos estos datos con frecuencia para
ciento de participación en el mercado, debemos eliminar los nom- enviar muchos correos, es muy importante para nosotros asegurar
bres de la mayoría de los prospectos que compramos antes de llenar que los nombres y direcciones en ese archivo tengan la mayor exac-
nuestra base de datos de marketing; es imprescindible que lo haga- titud posible. Por ejemplo, deben conformarse a los estándares
mos bien, ya que ésta es parte crucial de nuestro arsenal de herra- postales y no debe haber duplicados.”
mientas de información estratégica de la empresa”. “Para lograr esto utilizamos una técnica llamada higiene de
Ryan explica a Chandler, uno de los miembros del equipo de datos. ¿Qué tal suena ese término especializado? Por lo general
analistas de sistemas que usted dirige: “Una base de datos de mar- logramos la higiene de los datos mediante software especializado,
keting, o MDB para abreviar, es una poderosa base de datos relacio- el cual se utiliza para determinar la validez de una dirección. Este
nal que representa el corazón de los sistemas de marketing. Nuestra software relaciona la dirección de la base de datos con su propia
base de datos de marketing se utiliza para proveer información para base de datos interna de calles y rangos de números válidos en una
todos los sistemas de marketing. En estos sistemas se incluyen las ciudad o código postal específico”.
herramientas de productividad, como nuestra Automatización de Ryan prosigue: “Uno de los otros retos de datos a los que se
las fuerzas de ventas y nuestros Sistemas de correo masivo, diseña- enfrentan los que trabajan en marketing es la eliminación de regis-
dos para ayudar a los vendedores a administrar el ciclo de ventas. tros duplicados en la base de datos de marketing. Hay dos tipos de
También se incluyen las herramientas analíticas, como nuestros duplicados a buscar: duplicados internos, que consisten en la exis-
sistemas de información geográfica (GIS) o las herramientas del tencia de varios registros del mismo cliente o prospecto, y los du-
lenguaje gráfico de consulta (CQL), que están diseñadas para pro- plicados externos, que representan nuestra incapacidad de eliminar
veer soporte para las decisiones. clientes de nuestros datos de prospectos”.
“Pero la principal función de una base de datos de marketing es “Los duplicados internos crean problemas en los informes e
rastrear la información sobre nuestros clientes y prospectos. En la incrementan los costos del servicio de correo. Los duplicados exter-
actualidad rastreamos la información geográfica, demográfica y psi- nos son incluso peores: son tanto costosos como vergonzosos”.
cográfica o, como me gusta decirlo, dónde viven, quiénes son y cómo Ryan explica: “Una de las cosas más vergonzosas para un represen-
piensan”. tante de ventas es realizar una llamada a un prospecto sólo para
“Las bases de datos de marketing más simples se pueden crear descubrir que ya es nuestro cliente. Por lo general, el cliente se
a partir de sólo tres archivos: Perfil de prospectos, Perfil de clientes queda con la sensación de que es sólo un número en una de nuestras
e Historial de compras y pagos”. computadoras. Además de la mala impresión, desperdicia el valioso
“Una vez diseñada la base de datos de marketing, el siguiente tiempo y los recursos”.
reto es decidir cómo llenarla. En la actualidad compramos nuestra Describa en dos párrafos algunas técnicas que podría usar
información de prospectos a un distribuidor de listas. Como la es- Ryan para ayudar a identificar los duplicados internos y externos en
trategia de marketing de nuestra empresa se basa en el marketing en la base de datos de marketing de su empresa. Describa cómo crearía
masa, compramos todos los negocios en nuestra área. Debido a este una base de datos de marketing para minimizar los duplicados (use
volumen, pagamos menos de diez centavos de dólar por cada pros- un párrafo). ¿Hay métodos operacionales que podrían reducir este
pecto. No obstante, si una empresa practica la diferenciación de problema? Haga una lista de ellos. ¿Quién más en la organización
productos, es probable que su base de prospectos sea más definida. podría ayudar con este proceso? Proporcione una lista breve. Reco-
Esta empresa probablemente pagaría una prima por datos más deta- miende en un párrafo los métodos para Chandler y los demás miem-
llados que se validaron con cuidado”, explica Ryan. bros de su equipo de análisis de sistemas que se puedan usar para
“Nos enfrentamos a un verdadero reto. Si tuviera un dólar por ayudar a reclutar y asegurar la asistencia de otros miembros rele-
cada vez que un representante se queja conmigo sobre la dirección vantes de la organización.
Los tipos de patrones que los encargados de tomar decisiones tratan de identificar incluyen las asociacio-
nes, las secuencias, el agrupamiento y las tendencias. Las asociaciones son patrones que ocurren en conjunto al
mismo tiempo. Por ejemplo, una persona que compra cereal por lo general compra leche para acompañarlo. Por
otro lado, las secuencias son patrones de acciones que se llevan a cabo durante un periodo de tiempo. Por ejem-
plo, si una familia compra una casa este año, es muy probable que vayan a comprar bienes de consumo durade-
ros (un refrigerador, o lavadora y secadora) el próximo. El agrupamiento es el patrón que se desarrolla entre un
grupo de personas. Por ejemplo, los clientes que viven en un código postal específico tal vez tiendan a comprar
un automóvil específico. Por último, las tendencias son patrones que se observan durante un periodo de tiempo.
Por ejemplo, tal vez los consumidores pasen de comprar artículos genéricos a productos premium.
El concepto de minería de datos surgió del deseo de usar una base de datos para una focalización más selec-
tiva de los clientes. Las primeras metodologías para el correo directo incluían el uso de la información del código
www.xlibros.com
432 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
postal como una forma de determinar cuál podría ser el ingreso de una familia (suponiendo que ésta debe generar
suficiente ingreso como para poder vivir en el prestigioso código postal 90210 de Beverly Hills o en algún otro
vecindario acomodado). Era una manera (imperfecta, desde luego) para limitar el número de catálogos enviados.
La minería de datos lleva este concepto un paso más allá. Si suponemos que el comportamiento anterior es
un buen vaticinador de las compras futuras, se recopila una gran cantidad de datos sobre una persona específica
a partir de las compras con su tarjeta de crédito. La empresa puede identificar en qué tiendas compramos, qué
hemos comprado y cuánto pagamos por un artículo, además de saber cuándo y con qué frecuencia viajamos. Los
datos también se introducen, almacenan y utilizan para una variedad de propósitos cuando llenamos las garan-
tías, solicitamos una licencia de conductor, respondemos a una oferta gratuita o solicitamos una tarjeta de mem-
bresía en una tienda de renta de videos. Lo que es más: las empresas comparten estos datos y a menudo hacen
dinero al venderlos a terceros.
American Express ha sido líder en minería de datos para fines de marketing. American Express le envía
cupones de descuento para nuevas tiendas o entretenimiento cuando le envía la factura de su tarjeta de crédito,
habiendo determinado que usted compró en tiendas similares o asistió a eventos similares. General Motors ofrece
una tarjeta MasterCard que permite a los clientes acumular puntos de bonificación para la compra de un nuevo
automóvil, y después envía información sobre los nuevos vehículos en el momento en que sería más probable
que el consumidor esté interesado en comprar un auto nuevo.
Sin embargo, la metodología de minería de datos también presenta sus problemas. En primer lugar, los
costos pueden ser demasiado altos como para poder justificar la minería de datos, algo que tal vez se descubra
sólo hasta después de haber acumulado enormes costos de preparación. En segundo lugar, la minería de datos
tiene que estar coordinada de manera que varios departamentos o subsidiarias no traten de contactar al cliente al
mismo tiempo. Además, los clientes tal vez piensen que se ha invadido su privacidad y resientan las ofertas que
reciben. Por último, los clientes podrían pensar que los perfiles creados únicamente con base en sus compras con
tarjeta de crédito presentan una imagen bastante distorsionada de quiénes son en realidad.
Los analistas deben asumir responsabilidad en cuanto a los aspectos éticos de cualquier proyecto de minería
de datos propuesto. Hay que considerar y averiguar, junto con el cliente, todos los detalles sobre el periodo que
se mantendrá el material de los perfiles, la confidencialidad del mismo, las medidas de protección de la priva-
cidad incluidas y los usos que se le darán. Las oportunidades de abuso son evidentes, por lo que debemos estar
protegidos. Para los consumidores, la minería de datos es sólo otra tecnología más que se les impone, y si ellos
no desean que pase esto, los esfuerzos de minería de datos fracasarán.
RESUMEN
Una decisión importante en el diseño de un sistema de infor- los grupos repetitivos. En segundo lugar se eliminan todas las
mación es la forma en que se almacenan los datos. Hay dos dependencias parciales. Por último se quitan las dependencias
metodologías para ello: la primera consiste en almacenarlos en transitivas. Una vez que se completan estos tres pasos, el re-
archivos individuales, usando un archivo para cada aplicación; sultado es la creación de numerosas relaciones que están en la
la segunda, en desarrollar una base de datos que puedan com- tercera forma normal (3NF).
partir muchos usuarios para varias aplicaciones, a medida que Podemos usar el diagrama de entidad-relación para de-
surja la necesidad. terminar las claves requeridas para un registro o una relación
Para comprender el almacenamiento de los datos hay que de una base de datos. Los tres lineamientos a seguir al diseñar
captar tres ámbitos: realidad, datos y metadatos. Una entidad es tablas maestras o relaciones de bases de datos son: 1) cada en-
un objeto o evento por el que estamos dispuestos a recolectar y tidad de datos separada debe crear una tabla maestra (no com-
almacenar datos. Los atributos son las características reales de binar dos entidades distintas dentro de una tabla); 2) un campo
estas entidades. Los elementos de datos pueden tener valores y de datos específico debe existir en sólo una tabla maestra; y 3) cada
se pueden organizar en registros a los que se puede acceder me- tabla maestra o relación de base de datos debe tener programas
diante una clave. Los metadatos describen a los datos y pueden para crear (C), leer (R), actualizar (U) y eliminar (E).
contener restricciones sobre el valor de un elemento de datos El proceso de recuperar datos puede involucrar hasta
(por ejemplo, que sea sólo numérico). ocho pasos: 1) seleccionar una relación, 2) unir dos relaciones,
Algunos ejemplos de archivos convencionales son los ar- 3) proyectar (seleccionar) las columnas, 4) seleccionar las filas
chivos maestros, los archivos de tablas, los archivos de transac- relevantes, 5) derivar nuevos atributos, 6) ordenar o indexar fi-
ciones, los archivos de trabajo y los archivos de informes. Por las, 7) calcular totales y medidas de desempeño, y finalmente
lo general, las bases de datos se construyen con una estructura 8) presentar los resultados al usuario.
relacional. Sin embargo, los sistemas heredados pueden tener La desnormalización es un proceso que toma el modelo de
estructuras jerárquicas o de redes. datos lógico y lo transforma en un modelo físico que sea efi-
La normalización es el proceso que toma las vistas de ciente para las tareas más necesarias. Los almacenes corporativos
usuario y las transforma en estructuras menos complejas co- de datos difieren de las bases de datos tradicionales en muchos
nocidas como relaciones normalizadas. Hay tres pasos en el aspectos; uno de ellos es que almacenan datos desnormalizados,
proceso de normalización. En primer lugar se eliminan todos los cuales están organizados en base a temas. Los almacenes cor-
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 433
EXPERIENCIA DE HYPERCASE® 13
porativos de datos permiten un fácil acceso mediante el software de las compras futuras, las empresas recopilan datos sobre una
de minería de datos también conocido como software, el cual persona a partir de las compras con su tarjeta de crédito, las
busca patrones e identifica las relaciones que no pueden imagi- solicitudes de licencia de conductor, las tarjetas de garantías,
nar los humanos encargados de tomar decisiones. etcétera. La minería de datos puede ser poderosa, pero también
La minería de datos involucra el uso de una base de da- puede ser costosa y debe estar coordinada. Además, puede in-
tos para una focalización más selectiva de los clientes. Supo- fringir la privacidad del consumidor o incluso los derechos ci-
niendo que el comportamiento anterior es un buen vaticinador viles de una persona.
www.xlibros.com
434 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
PREGUNTAS DE REPASO
1. ¿Cuáles son las ventajas de organizar el almacenamiento de datos como archivos separados?
2. ¿Cuáles son las ventajas de organizar el almacenamiento de datos mediante una metodología de base de datos?
3. ¿Cuáles son las medidas de efectividad del diseño de bases de datos?
4. Mencione algunos ejemplos de entidades y sus atributos.
5. ¿Cuál es la diferencia entre una clave primaria y un identificador de objetos?
6. Defina el término metadatos. ¿Cuál es el propósito de los metadatos?
7. Mencione los tipos de archivos convencionales de uso común. ¿Cuáles de éstos son archivos temporales?
8. Mencione los tres tipos principales de organización de bases de datos.
9. Defina el término normalización.
10. ¿Qué se elimina cuando una relación se convierte a la primera forma normal?
11. ¿Qué se elimina cuando una relación se convierte de 1NF a 2NF?
12. ¿Qué se elimina cuando una relación se convierte de 2NF a 3NF?
13. Mencione las tres restricciones de entidad. Describa en un enunciado el significado de cada restricción de entidad.
14. Describa las cuatro anomalías que pueden ocurrir al crear tablas de bases de datos.
15. Mencione los ocho pasos para recuperar, preordenar y presentar los datos.
16. ¿Qué hace la unión? ¿Qué es la proyección? ¿Qué es la selección?
17. Defina desnormalización.
18. Explique las diferencias entre bases de datos tradicionales y almacenes corporativos de datos.
19. Defina qué hace el software cuando se utiliza en minería de datos.
PROBLEMAS
1. Dado el siguiente archivo de arrendatarios:
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 435
2. El siguiente es un ejemplo de una boleta de calificaciones para dos estudiantes en la University of Southern New Jersey:
www.xlibros.com
436 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
13. GaiaOrganix es una cooperativa de mayoreo de comida orgánica que vincula a productores y consumidores.
GaiaOrganix negocia las compras que las tiendas de abarrotes y demás tiendas relacionadas hacen a los granjeros que
cultivan una variedad de cosechas, como frutas, vegetales y granos. Cada granjero puede producir varias cosechas y
varios granjeros pueden producir una cosecha. Para proveer el nivel más alto de productos frescos, éstos se envían
directamente de la granja a la tienda. Cada tienda puede comprar de muchas granjas y cada granja puede vender a
muchas tiendas. Dibuje un diagrama de entidad-relación en la tercera forma normal que muestre la relación entre el
productor (granjas) y el vendedor (tiendas).
14. ArticleIndex.com es una empresa que produce índices de artículos de revistas y periódicos para una disciplina específica.
Un usuario Web debe tener la capacidad de introducir el tema o los autores de un artículo para recibir una lista detallada
de todos los artículos y periódicos en los que se encontró el tema. Cada artículo puede tener muchos autores y cada autor
puede escribir muchos artículos. Un artículo puede existir sólo en un periódico, pero cada periódico por lo general
contiene muchos artículos. Cada artículo puede tener muchos temas y cada tema puede estar en muchos artículos. Dibuje
un diagrama de entidad-relación en la tercera forma normal para los artículos, autores, periódicos y temas.
15. Identifique las claves primarias y externas para el diagrama de entidad-relación creado en el problema 14.
PROYECTO EN GRUPO
1. Gregg Baker compró boletos para dos conciertos a través de la Web. Sus pedidos se procesaron, las ubicaciones exactas
se asignaron y los boletos se enviaron por separado. Uno de los conjuntos de boletos se perdió en el correo. Cuando
llamó al número de servicio no recordó la fecha ni los números de los asientos, pero la agencia pudo localizar sus
boletos con rapidez debido a que desnormalizó la relación. Describa el sistema de pedidos de boletos mediante un
listado de los elementos de datos que se mantienen en el formulario de pedido y el formulario de envío. ¿Qué
información proporcionó Gregg a la agencia de boletos para recuperar la información?
BIBLIOGRAFÍA SELECCIONADA
Agrawal, R., A. Ailamaki, P. A. Bernstein, E. A. Brewer, M. J. Carey, S. Chaudhuri, et al. “The Claremont Report on Database
Research”. Communications of the ACM, Vol. 52, Núm. 6, 2009, pp. 56-65.
Avison, D. E. Information Systems Development: A Database Approach, 2ª. Edición. Londres: Blackwell Scientific, 1992.
Codd, E. F. “A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM, Vol. 13, Núm. 6, 1970,
pp. 377-387.
Deitel, H. M., P. J. Deitel y T. R. Nieto. E-Business and E-Commerce: How to Program. Upper Saddle River, NJ: Prentice Hall,
2001.
Gane, C. y T. Sarson. Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, NJ: Prentice Hall, 1979.
Gray, P. “Data Warehousing: Three Major Applications and Their Significance”. En Emerging Information Technologies, Im-
proving Decision, Cooperation, and Infrastructure. Editado por K. E. Kendall, Thousand Oaks, CA: Sage Publications,
1999.
Hoffer, J., A. Prescott y H. Topi. Modern Database Management, 9ª. Edición. Upper Saddle River, NJ: Prentice Hall, 2009.
Sanders, G. L. Data Modeling. Nueva York: International Thomson Publishing, 1995.
Shin, S. K. y G. L. Sanders. “Denormalization Strategies for Data Retrieval from Data Warehouses”. Decision Support Systems,
Vol. 42, Núm, 1, 2006, pp. 267-282.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 437
EPISODIO 13
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
FIGURA E13.1
Contiene
Computadora Software Diagrama de entidad-relación sin
Instalada en normalizar para el sistema
computarizado. La relación de
Numero inventario hardware + Numero inventario software + muchos a muchos se tendrá que
Nombre marca + Titulo + definir como una entidad
Modelo + Nombre sistema operativo + asociativa.
Numero serie + Numero version +
Fecha compra + Editorial +
Costo compra + Descripcion categoria software +
Costo reemplazo + Marca computadora +
Tamanio memoria + Modelo computadora +
Capacidad disco duro + Memoria requerida +
Capacidad segundo disco duro + Licencia sitio +
Unidad optica + Numero de copias +
Sistema operativo + Apellido paterno experto +
Intervalo actualizacion + Primer nombre experto +
Duracion garantia + Telefono oficina
Descripcion campus +
Ubicacion sala +
{Numero inventario software}
www.xlibros.com
438 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Chip continúa trabajando en el diagrama de entidad-relación. Después de unas cuantas horas exclama: “Creo que está listo.
¿Podrías dar un vistazo a la versión final?”. En la figura 13.3 se muestra la versión final. Se describieron todas las entidades y
relaciones en el repositorio.
Anna revisa la versión final y exclama, “¡Se ve excelente! Tuviste razón en mover SISTEMA OPERATIVO y EDIFICIO
CAMPUS a sus propias entidades. Buena idea, ya que el edificio no es parte de la computadora. Además, en definitiva el EX-
PERTO DE SOFTWARE no es parte de la entidad SOFTWARE. ¿Qué hay sobre CATEGORIA SOFTWARE?”.
“Moví la CATEGORIA SOFTWARE a su propia entidad para ahorrar espacio en los archivos maestros cuando se constru-
yan”, responde Chip. “En realidad es una tabla de códigos y facilita el proceso de cambiar la categoría sin tener que cambiar
todos los registros de software. Además vamos a almacenar un pequeño código en vez de una descripción extensa en cada re-
gistro de software. ¿Por qué no revisas dos veces las diversas claves en el diagrama? Cada entidad relacionada en el extremo de
muchos debería tener una clave externa que coincida con la clave primaria de la entidad en el extremo de uno”.
Anna examina el diagrama por un instante y comenta, “Se ve bien, en mi opinión. Tal vez debamos definir las entradas en
el repositorio”.
“Mira esta entrada en el repositorio”. Chip abre el diagrama de entidad-relación (figura E13.4) y hace doble clic en la
entidad COMPUTERS (COMPUTADORAS) para mostrar su entrada en el repositorio. Se definieron la clave primaria (la no-
tación [pk] de Microsoft Visio y Visible Analyst frente al elemento NUMERO INVENTARIO HARDWARE [HARDWARE
FIGURA E13.3
Diagrama de entidad-relación final para el sistema computarizado.
www.xlibros.com
CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 439
FIGURA E13.4
El diagrama de entidad-relación
normalizado de la CPU se muestra
en Microsoft Visio con la
definición del repositorio para
Software.
INVENTORY NUMBER] en el área de composición), las claves externas (FK1, FK2 y así en lo sucesivo) y varias claves alter-
nas ([Ak1],[Ak2] y [Ak3]). Después de invertir tiempo en examinar el diagrama, así como las entradas en el repositorio y los
informes de análisis, tanto Anna como Chip quedan satisfechos de que las relaciones entre los datos estén representadas en
forma precisa. A continuación deciden cómo diseñar la base de datos a partir de los diagramas.
Primero analizan la relación HARDWARE/SOFTWARE. Como hay una relación de muchos a muchos entre estas dos
entidades de datos, se puede implementar mediante el uso de tres tablas de base de datos:
1. Una tabla MAESTRA DE HARDWARE (HARDWARE MASTER).
2. Una tabla MAESTRA DE SOFTWARE (SOFTWARE MASTER).
3. Una tabla RELACION HARDWARE/SOFTWARE (HARDWARE/SOFTWARE RELATIONSHIP), que debe contener los
campos clave de las tablas maestras HARDWARE y SOFTWARE para todo el software instalado en todas las máquinas. También
podría funcionar una clave de primaria de autosecuencia, siempre y cuando se incluyan las claves externas en la tabla.
“Creo que es mi turno de trabajar en las relaciones”, dice Anna mientras saca una copia del diagrama de entidad-relación. Voy
a modificar las tablas de Microsoft Access de las sesiones de los prototipos”.
Para empezar, Anna establece las claves primarias para cada una de las tablas. Cuando éstas se encuentran en su forma
final, crea las relaciones entre ellas. En la figura E13.5 se muestra el diagrama de relaciones de Microsoft Access. Los rectán-
FIGURA E13.5
Un diagrama de RELACIONES
de Microsoft Access. Observe los
símbolos de infinito que
representan el extremo de muchos
de una relación.
www.xlibros.com
440 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
gulos en el diagrama representan las tablas de la base de datos y corresponden a los diversos tipos de entidades que se encuen-
tran en el diagrama de entidad-relación. Tenga en cuenta que la cardinalidad se representa mediante “1” y el símbolo de infinito.
Los campos que son claves primarias se listan como el primer campo de cada rectángulo; también se muestran en negrita. Las
claves externas se muestran unidas al otro extremo de la línea de la relación, si la clave externa es visible en el rectángulo de la
tabla. Las claves se arrastran de una tabla a otra para establecer una relación; aparece un cuadro de diálogo para determinar las
propiedades de la relación.
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver los diagramas de entidad-relación sin normalizar y en primera forma
normal para el sistema computarizado. Haga doble clic en las entidades para ver la información del repositorio. (En
Microsoft Visio y en Visible Analyst; en Microsoft Visio la entrada del repositorio está en un área en la parte inferior de
la pantalla. Tal vez tenga que arrastrar el borde que separa el diagrama del repositorio hacia arriba. Haga clic en la entrada
Columnas (Columns) que está en el área Categorias (Categories) del lado izquierdo del repositorio para ver los atributos
de entidad). El nombre del diagrama es SISTEMA COMPUTARIZADO – SIN NORMALIZAR (COMPUTER SYS-
TEM – UNNORMALIZED).
E-2. Use Microsoft Visio o Visible Analyst para ver el diagrama de entidad-relación del sistema computarizado. Haga doble
clic en las entidades para ver la información del repositorio (en Microsoft Visio y en Visible Analyst). El nombre del
diagrama es COMPUTADORA (COMPUTER).
E-3. Agregue la entidad DISTRIBUIDOR (VENDOR) al diagrama. El distribuidor garantiza las computadoras; la relación
entre DISTRIBUIDOR y COMPUTADORA es que un VENDEDOR puede garantizar muchas COMPUTADORA(s).
Agregue las claves primarias. Microsoft Visio creará de manera automática las claves externas. En Visible Analyst, se-
leccione Sincronización de claves (Key Synchronization) del menú Repositorio (Repository).
E-4 Agregue la entidad MANTENIMIENTO (MAINTENANCE) al diagrama. Las reparaciones de mantenimiento se reali-
zan en las computadoras; la relación entre MANTENIMIENTO y COMPUTADORA(s) es tal que una COMPUTA-
DORA puede tener muchos registros de MANTENIMIENTO. Use el repositorio para definir NUMERO PEDIDO
MANTENIMIENTO (MAINTENANCE ORDER NUMBER). Establezca este atributo como clave primaria para la en-
tidad MANTENIMIENTO y genere la clave externa.
E-5. Describa la entidad CATEGORIA SOFTWARE (SOFTWARE CATEGORY) en el repositorio. Incluya los elementos que
se encuentran en el diagrama de entidad-relación debajo de CATEGORIA SOFTWARE en el área Composición (Com-
position).
E-6. Describa la entidad MANTENIMIENTO (MAINTENANCE) en el repositorio. Los elementos son los siguientes:
a. NUMERO ORDEN MANTENIMIENTO (MAINTENANCE ORDER NUMBER)
b. NUMERO INVENTARIO HARDWARE (HARDWARE INVENTORY NUMBER)
c. FECHA MANTENIMIENTO (MAINTENANCE DATE).
d. TIPO DE MANTENIMIENTO (TYPE OF MAINTENANCE).
e. COSTO DE MANTENIMIENTO (COST OF MAINTENANCE).
f. MANTENIMIENTO CUBIERTO POR GARANTIA (MAINTENANCE COVERED BY WARRANTY).
E-7. Describa la entidad DISTRIBUIDOR (VENDOR). Los elementos son los siguientes:
a. NUMERO DISTRIBUIDOR (VENDOR NUMBER).
b. NOMBRE DISTRIBUIDOR (VENDOR NAME).
c. CALLE (STREET).
d. CIUDAD (CITY).
e. ESTADO (STATE).
f. CODIGO POSTAL (ZIP CODE).
g. NUMERO TELEFONICO (TELEPHONE NUMBER).
h. FECHA ENVIO ULTIMO PEDIDO (DATE LAST ORDER SENT).
i. MONTO TOTAL COMPRA DISTRIBUIDOR (TOTAL AMOUNT PURCHASED FROM VENDOR).
j. NUMERO TOTAL DE PEDIDOS ENVIADOS AL DISTRIBUIDOR (TOTAL NUMBER OF ORDERS SENT TO
VENDOR).
E-8. Cada computadora puede tener más de un sistema operativo y cada sistema operativo puede estar instalado en más de
una computadora. Agregue una entidad asociativa llamada SISTEMA OPERATIVO COMPUTADORA (COMPUTER
OPERATING SYSTEM) entre COMPUTADORA (COMPUTER) y SISTEMA OPERATIVO (OPERATING SYS-
TEM). Incluya las claves primarias y externas en el repositorio, ya sea en Microsoft Visio o en Visible Analyst.
E-9. Explique en un párrafo la relación entre una clave externa y una clave primaria, y por qué es necesario tenerlas en enti-
dades separadas cuando hay una relación entre las entidades.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
C A P Í T U L O 14
Interacción
humano-computadora
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender la interacción humano-computadora (HCI).
2. Diseñar gran variedad de interfaces de usuario.
3. Diseñar un diálogo efectivo para la HCI.
4. Comprender la importancia de la retroalimentación del usuario.
5. Asumir las implicaciones de la HCI para diseñar sitios Web de comercio electrónico.
6. Formular consultas que permitan a los usuarios buscar en la Web.
www.xlibros.com
442 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.1
El “ajuste” entre humano,
Entorno
computadora y tarea afecta al
desempeño y al bienestar.
Humano
Ajuste
Computadora
bajo
Espa
Desempeño y
bienestar
ra
c
t
io
del
de
Tarea
a
lez
trab
ra
jo
a
tu
Na
etcétera), para después refinar el diseño con base en los cambios sugeridos y probarlos de nuevo con los usua-
rios, hasta que el diseño sea aceptable y el analista lo considere “congele”.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 443
entre humano, sistema y tarea se respaldan mediante sistemas Web y de comercio electrónico, sistemas ERP y
sistemas inalámbricos dentro y fuera de la organización.
DESEMPEÑO La definición de desempeño en el contexto de la HCI también es clave: se refiere a una combinación
de la eficiencia involucrada al desempeñar una tarea y la calidad del trabajo que ésta produce. Por ejemplo, si
los analistas utilizan software de alto nivel o una herramienta CASE para crear diagramas de flujo de datos en los
que son muy competentes, podríamos predecir que la calidad de los diagramas de flujo de datos producidos será
alta. El desempeño también es eficiente, ya que los analistas utilizan una herramienta automatizada con la que
están familiarizados: pueden trabajar con rapidez y obtener buenos resultados. La tarea se ajusta al objetivo,
que es crear diagramas de flujo de datos de alta calidad para documentar un sistema. La eficiencia de producir
dichos diagramas con una herramienta CASE —que se puede usar después para almacenar, recuperar, comunicar
y modificar los diagramas de UML—, es excelente si se le compara con alternativas como usar una herramienta
de dibujo no relacionada con un diccionario, o con la opción de dibujar los diagramas a mano, dado que ninguna de
ellas ofrece las ventajas mencionadas.
BIENESTAR En este punto podemos presentar el concepto de bienestar: la preocupación por la comodidad,
seguridad y salud de un humano en general; por su buen estado físico y psicológico. ¿Acaso usar una herramienta
CASE para producir diagramas de UML o DFD en una computadora sirve para el bienestar del analista? Sí, ya
que la tarea se ajusta bien al analista, al software, al objetivo y a la computadora, y se parte de que los analistas
trabajan en un entorno en el que están físicamente cómodos, reciben estímulo psicológico para ser creativos y
pueden ser productivos, además de que los colegas y clientes valoran su trabajo, y la organización que los emplea
les paga correctamente.
También importan las actitudes psicológicas (el componente afectivo). Es posible medir cómo se sienten los
usuarios con respecto a sí mismos, sus identidades, su vida laboral y desempeño mediante una evaluación de ac-
titudes. Como analista que asume una perspectiva de HCI, usted se debe concentrar en averiguar cómo influyen
las actitudes de los humanos en lo que sienten sobre la tecnología y sus tareas, además de descubrir si sus actitu-
des dificultan o mejoran su experiencia.
www.xlibros.com
444 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
todo y conversiones de moneda). Parte del criterio de utilidad en la HCI se puede medir también al establecer
si los usuarios encuentran gratificante usar el sistema, para lo cual podemos realizar entrevistas y observaciones
después de la implementación.
USABILIDAD
La usabilidad es un término que se define de manera distinta dependiendo de la rama de la ciencia que es-
temos investigando. En el caso que nos ocupa, consideraremos a la usabilidad como un medio con que los
diseñadores cuentan para evaluar, tan minuciosamente como sea posible, sus sistemas e interfaces en términos
de las preocupaciones de la HCI. Los estudios sobre la usabilidad (de acuerdo con www.useit.com) se enfocan
en averiguar lo que funciona y lo que no funciona en el mundo. La ISO ha creado estándares de usabilidad
que podemos explorar en www.usabilitynet.org/tools/r_international.htm. Estos estándares abarcan el uso del
producto (efectividad, eficiencia y satisfacción en un contexto de uso específico), la interfaz e interacción
del usuario, el proceso utilizado para desarrollar el producto y la capacidad de una organización de aplicar un
diseño centrado en el usuario.
Nielsen y Mack (1994) y Nielsen, Molich, Snyder y Farrell (2001) publicaron heurísticas de uso (o reglas
prácticas) con base en los miles de pruebas de usabilidad de las interfaces y, más tarde, en las pruebas de los
sitios Web de comercio electrónico. Aquí se incluye la visibilidad del estado del sistema, la coincidencia entre
el sistema y el mundo real, el control y la libertad del usuario, la consistencia y los estándares, la prevención de
errores, la posibilidad de reconectar en vez de recordar, la flexibilidad y la eficiencia de uso, el diseño estético y
minimalista, la ayuda que reconocen los usuarios, el diagnóstico y la recuperación de los errores, además de la
ayuda y la documentación. Probablemente reconozca algunas de ellas, que vimos en los capítulos sobre el diseño
de la entrada y la salida.
La figura 14.2 muestra una encuesta de usabilidad que se administra directamente a los usuarios que han
interactuado personalmente con un prototipo. Pregunta abiertamente sobre ciertas dimensiones ergonómicas y
de usabilidad que son importantes. Otra metodología es la de escribir escenarios de casos de uso para el sistema,
que son útiles para examinar las cuestiones sobre la usabilidad.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 445
FIGURA 14.2
Podemos usar un formulario para encuestar a los usuarios de prototipos sobre
los factores clave ergonómicos y de usabilidad (categorías basadas en Zhang,
Carey, Te’eni y Tremaine, 2005, tabla de cuestiones de la HCI, p. 522).
Es posible obtener muchas tablas con sólo reordenar estas cuatro variables. Si el usuario arrastrara la va-
riable Categoría (Category) al área que dice “Coloque campos de fila aquí (Drop Column Fields Here)”, las
columnas habrían sido categorías de productos en vez de los trimestres, y la tabla resultante hubiera mostrado
con claridad cuáles elementos pertenecen a cada categoría, además de producir los subtotales de cada una. Si se
arrastrara Categoría al área de la parte superior de la plantilla que dice “Coloque campos de página aquí (Drop
Page Fields Here)”, entonces cada categoría tendría su propia tabla en una página separada.
Las tablas dinámicas son útiles debido a que conceden a los usuarios un mayor control sobre las distintas
formas en que pueden ver los datos dentro de una tabla. En la siguiente sección examinaremos este mismo con-
cepto para las gráficas.
www.xlibros.com
446 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.3
Una plantilla de tabla dinámica
puede facilitar a los usuarios la
tarea de ver la información en
distintas formas.
ANÁLISIS VISUAL DE BASES DE DATOS Se ha innovado en el despliegue visual de datos durante mucho
tiempo, incluso desde el siglo dieciocho. Las barreras contra el uso extendido de pantallas incluían la falta de
imaginación, la incapacidad de dibujar gráficas y diagramas de manera efectiva en costo y la falta de apreciación
de tales pantallas. El consumidor de información debe ser capaz de interpretar la información en el diagrama o, de
lo contrario, éste aportará muy poco valor.
Hay software disponible para permitir al usuario examinar en forma visual una base de datos u hoja de
cálculo. El producto de Tableau Software es un ejemplo (www.tableausoftware.com). Mediante el uso de una
metodología similar a las tablas dinámicas que vimos en Microsoft Excel, Tableau permite al usuario arrastrar y
soltar variables en una fila o columna para que aparezcan en una gráfica. En la figura 14.5, los elementos Región
(Region) y Dia (Weekday) se designaron como columnas y SUMA (Total de ventas) [SALES(Sales Total)] se
FIGURA 14.4
Después de que el usuario arrastra
los elementos Producto (Product),
Trimestre (Quarter) y Ventas
(Sales) a la plantilla, la tabla tiene
esta apariencia.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 447
FIGURA 14.5
Esta tabla, que muestra las ventas
diarias por categoría y por región,
se produjo mediante el uso de
Tableau.
Fuente: Cortesía de
www.tableausoftware.com.
designó como fila. Después se graficó cada Categoría de producto (Product Category) [con “muebles (furni-
ture)” en azul, “artículos de oficina (office supplies)” en naranja y “tecnología (technology)” en verde].
La gráfica demuestra que las ventas de tecnología fueron mayores que en las demás categorías, pero en espe-
cial, las ventas de tecnología fueron mucho mayores que las ventas de muebles o artículos de oficina en la región
Este (East). El usuario pudo ver esto con facilidad debido a que la Región (Region) se destacó como uno de los
separadores al arrastrar este elemento al área como una columna.
Tableau es un paquete de software bien diseñado, ya que va mucho más allá que otras aplicaciones en cuanto
a extender las capacidades del usuario para que realice sus tareas por medio de las técnicas de tablas dinámicas.
Los desarrolladores también descubrieron que los usuarios podrían querer agrupar los datos en lo que conside-
ren un grupo significativo. Así los usuarios pueden continuar el análisis al examinar uno de los grupos con más
detalle.
La figura 14.6 examina la SUMA (Ganancia bruta) [SUM(Gross Profit)] de cada Categoría de producto
de nuestro ejemplo. Esta gráfica usa colores para indicar una ganancia (verde) o una pérdida (rojo). De hecho, la
intensidad del color indica la cantidad de ganancia o pérdida.
FIGURA 14.6
Los productos que generan
pérdidas se resaltan en color rojo
brillante en este diagrama de
dispersión, creado mediante el uso
de Tableau.
Fuente: Cortesía de
www.tableausoftware.com.
www.xlibros.com
448 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.7
Cuando se pueden mostrar
distintos gráficas o tablas en la
misma página, ésta se asemeja a
un tablero de control.
Fuente: Cortesía de
www.tableausoftware.com.
Podemos usar esta gráfica para explorar la situación con más detalle si seleccionamos los tres grupos de círcu-
los de color rojo brillante, los aislamos y después vemos los datos para esas observaciones. Los usuarios pueden
examinar gráficas o simplemente ver las observaciones en una tabla. Una vez más, tienen el control sobre la
forma en que se presenta la información y por ende controlan su tarea para el mejor ajuste cognoscitivo.
En la figura 14.7 se presenta otro ejemplo de Tableau, donde se muestra que este software también puede
crear un tablero de control (vimos el concepto en el capítulo 11). Aquí se muestran una tabla, un diagrama de
dispersión y una gráfica de columnas en la misma página. Las herramientas de análisis visual de este tipo brin-
dan apoyo al pensamiento visual y extienden las capacidades cognoscitivas del usuario para ello. Una pantalla
visual apropiada incrementará la probabilidad de tomar una decisión apropiada.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 449
computadora-tarea. Los teclados se diseñaron en forma ergonómica para proveer la retroalimentación correcta
para la persona que introduce datos. Con base en la firmeza de la tecla bajo su dedo, los usuarios saben que
se efectuó la pulsación de la misma. Aunque los teclados se pueden silenciar, a menudo se diseñan con un
clic de retroalimentación. Los teclados también incluyen marcas en relieve en lo que se denomina teclas base,
comúnmente la f y la j, las cuales orientan a los usuarios para que sepan la posición de sus dedos en el teclado de
manera que puedan ver a la pantalla o escribir información de una página impresa en su escritorio sin tener que
mirar continuamente el teclado.
Aunque el teclado QWERTY que utilizamos comúnmente con las computadoras en la actualidad se
diseñó para reducir la velocidad de los mecanógrafos, de manera que no se atoraran las teclas de las pri-
meras máquinas de escribir mecánicas, esta distribución del teclado ha demostrado ser una forma bastante
efectiva de introducir datos. De hecho, como los usuarios se desempeñan tan bien con esta familiar interfaz,
es difícil conducir experimentos para comparar la eficiencia de los teclados QWERTY con otros teclados
innovadores.
Diseñar para la introducción de datos mediante teclados numéricos también constituye una oportunidad de
decisión para los diseñadores. Observe los números en su teléfono celular, que están ordenados en forma distinta
a los números en un teclado numérico o calculadora. Es probable que su teléfono tenga los números 1, 2 y 3 en la
fila superior. Si da un vistazo a la distribución de una calculadora o un teclado numérico verá los números 7, 8 y 9
en la fila superior. La investigación ahora señala la superioridad de la distribución de la calculadora cuando el
usuario introduce muchos datos. Sin embargo, se supone que la distribución de los dígitos del teléfono es mejor
para localizar un número. Como diseñador, usted tiene que examinar de manera constante el ajuste entre el hu-
mano, la computadora y las tareas establecidas por la organización.
www.xlibros.com
450 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 1
Para el caso de las personas que carecen de cierta sensibilidad al color (a lo que se le conoce erróneamente
como daltonismo), puede probar los colores que selecciona para las pantallas o formularios y asegurarse de que
se puedan diferenciar con facilidad unos de otros. Por ejemplo, hay problemas específicos que ocurren al tratar
de diferenciar el rojo y el verde. Diseñe siempre la pantalla o formulario con pistas alternativas, como iconos,
texto escrito o pistas de audio que refuercen el contenido. Por ejemplo, si al hacer clic en un hipervínculo éste
cambia a color azul para indicar que lo siguieron, también puede agregar otro icono a la pantalla para indicar que
lo siguieron o crear una lista en una barra lateral separada que muestre los sitios Web que se han visitado. Estas
son mejores alternativas que depender únicamente del color para transmitir el mensaje.
Para los usuarios que experimentan discapacidad auditiva, puede asegurarse de que los documentos y panta-
llas que diseñe incluyan el acceso a las versiones escritas del material de audio. La alternativa sería diseñar tareas
donde sea posible usar audífonos satisfactoriamente.
Si va a diseñar tareas de cómputo para los que tienen una movilidad limitada, puede pensar en usar la en-
trada de voz en vez del teclado. Además, los nuevos avances en la ingeniería biomédica permiten a los usuarios
con discapacidad móvil desplazar el cursor en la pantalla respirando a través de un tubo; también pueden dirigir
el cursor al punto deseado en la pantalla, para lo cual ven hacia ese punto o incluso, en ciertas interfaces muy
especializadas, sólo tienen que pensar hacia dónde se debería desplazar el cursor.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 451
FIGURA 14.8
Lineamientos de la metodología de la HCI para el diseño de sistemas
La metodología de la HCI para el
diseño de sistemas hace énfasis en
• Examine la tarea a realizar y considere el ajuste entre humano, computadora y tarea.
el ajuste entre humano,
• Identifique los obstáculos que existen para los usuarios al tratar de cumplir con sus tareas asignadas.
computadora y tarea.
• Tenga en cuenta la utilidad y la facilidad de uso percibidas del TAM.
• Considere la usabilidad. Examine el entorno de uso mediante la creación de escenarios de casos de
uso que describan lo que ocurre entre los usuarios y la tecnología.
• Use la información que haya obtenido de antemano para definir las características
ambientales físicas y organizacionales. Diseñe y use prototipos para adaptarse a los diversos usuarios
y a los usuarios con discapacidades.
la práctica de la usabilidad como tal; así, aunque intente introducir este cambio en su proyecto, es muy pro-
bable que el puesto quede vacante o que batalle mucho con el personal. Pero no deje que esto lo desanime.
Puede llevar a cabo algunos pasos simples que influirán en forma positiva en el resultado de su proyecto de
sistemas. La figura 14.8 muestra una lista de los lineamientos para aplicar una metodología de HCI en el
diseño de sistemas.
Aunque hemos estado describiendo el sistema en abstracto, es importante reconocer que la interfaz es el
sistema para la mayoría de los usuarios. Sin importar qué tan bien o mal diseñada esté, representa al sistema y
refleja su competencia como analista de sistemas. Una interfaz bien diseñada mejora el ajuste entre la tarea, la
tecnología y el usuario.
Su objetivo debe ser diseñar interfaces que ayuden a los usuarios y las empresas a introducir la informa-
ción al sistema y obtener de éste la información que necesitan, para lo cual hay que considerar los siguientes
objetivos:
1. Hacer que la interfaz de usuario corresponda con la tarea.
2. Hacer la interfaz de usuario eficiente.
3. Proveer una retroalimentación apropiada a los usuarios.
4. Generar consultas que se puedan utilizar.
5. Mejorar la productividad de los usuarios de computadora.
www.xlibros.com
452 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.9
Interfaces de lenguaje natural.
> Mencione los vendedores que cumplieron con sus metas este mes.
Tom Otto
Roz Berry
Spin Etch
> Grafique la venta de unidades de DVD por mes durante los últimos tres años.
Oprima cualquier tecla para continuar.
FIGURA 14.10
Un cuadro de diálogo: un tipo de
interfaz de preguntas y respuestas.
Archivo Edición Gráfica Tarea Distribución Fechas Fuentes Estilo
Proyecto Bakerloo Bros.
10/22
10/22
Resolver
9/24 información en Crear prototipo
conflicto de entrada
Administrar
cuestionario
10/22
Crear prototipo
de salida
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 453
caso una gráfica de PERT para un proyecto de análisis de sistemas para Bakerloo Brothers. Observe que el rec-
tángulo redondeado para la opción “Sí” está resaltado para indicar que es la respuesta más probable en esa situa-
ción. La interfaz principal para esta aplicación no necesita ser de preguntas y respuestas. Más bien, mediante la
incorporación de un cuadro de diálogo el programador ha incluido una interfaz fácil de usar dentro de una más
complicada.
Los asistentes que se utilizan para instalar software son un ejemplo común de una interfaz de preguntas y
respuestas. El usuario responde a las preguntas sobre el proceso de instalación, como dónde instalar el software
o las herramientas. El asistente también puede hacer preguntas y responder a las preguntas del usuario con más
preguntas diseñadas para reducir el alcance del problema. Ésta es una manera típica de establecer una interfaz de
soporte técnico para reducir los problemas y diagnosticarlos con más precisión.
Menús
Una interfaz de menú toma debidamente prestado el nombre de la lista de platillos que se pueden selec-
cionar en un restaurante, pues de manera similar, provee al usuario una lista en pantalla de las selecciones
disponibles.
Para responder al menú, el usuario está limitado a las opciones que se muestran en la pantalla. El usuario no
tiene que conocer el sistema, pero sí necesita saber qué tarea debe realizar. Por ejemplo, en un menú típico de
un procesador de palabras, los usuarios pueden elegir las opciones Edición, Copiar o Imprimir, pero para usar el
menú con eficiencia, los usuarios deben saber qué tarea desean realizar.
Los menús no dependen del hardware. Las variedades abundan. Se pueden configurar para usar la entrada
desde el teclado, un lápiz óptico, pantalla táctil o ratón. Las selecciones se pueden identificar mediante un nú-
mero, una letra o una palabra clave, o los usuarios pueden hacer clic en una selección con un ratón. La consisten-
cia es importante al diseñar una interfaz de menú.
Los menús también se pueden hacer a un lado hasta que el usuario los necesite. La figura 14.11 muestra
cómo el usuario utiliza un menú desplegable mientras construye un diagrama PERT para un proyecto de análisis
de sistemas que está terminando para Bakerloo Brothers. El usuario coloca el puntero en Fechas y despliega el
menú hacia abajo. Después coloca el puntero en Calendario y selecciona la opción para mostrar el proyecto en
un calendario mensual convencional.
Los menús se pueden anidar unos dentro de otros para conducir a un usuario por las opciones en un pro-
grama. Los menús anidados permiten que la pantalla aparezca menos desordenada, la cual es consistente con el
buen diseño. También permiten a los usuarios evitar ver las opciones de menú que no les interesan. Los menús
anidados también pueden desplazar a los usuarios rápidamente por el programa.
FIGURA 14.11
Un menú desplegable está ahí
cuando el usuario lo necesita.
Archivo Edición Gráfica Tarea Distribución Fechas Fuentes Estilo
Mostrar Fechas M
Establecer Primer Inicio P
Establecer Final Más Reciente M
Escala de Duración D
Escala de Línea del Tiempo T 10/22
Entrevistar a
Calendar C Desarrollar
B. Crieghton
base de datos
10/22
10/22
Resolver
9/24 información Crear prototipo
en conflicto de entrada
Administrar
cuestionario
10/22
Crear prototipo
de salida
www.xlibros.com
454 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 2
Los menús de GUI se utilizan para controlar el software de PC y tienen los siguientes lineamientos:
1. La barra de menús principal siempre se muestra.
2. El menú principal usa una sola palabra para los elementos de menú. Las opciones del menú principal
siempre muestran menús desplegables secundarios.
3. El menú principal debe tener opciones secundarias agrupadas en conjuntos similares de características.
4. Los menús desplegables que aparecen al hacer clic en un elemento del menú principal consisten a menudo
de más de una palabra.
5. Las opciones secundarias desempeñan acciones o muestran elementos de menú adicionales en pantalla.
6. Los elementos de menú en gris no están disponibles para la actividad actual.
Un menú de objeto, también conocido como menú contextual, aparece cuando el usuario hace clic en un ob-
jeto de la GUI con el botón derecho del ratón. Estos menús contienen elementos específicos para la actividad en
curso y la mayoría son funciones duplicadas de los elementos del menú principal.
Los usuarios experimentados podrían molestarse con los menús anidados. Tal vez prefieran usar una entrada
de comando de una sola línea para agilizar las cosas. Otros usuarios podrían usar las teclas de método abreviado
o combinaciones de teclas tales como Alt .I .P C, que inserta una imagen prediseñada en un documento de
Microsoft Office.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 455
FIGURA 14.12
Orden de compra Un ejemplo de la interfaz de
llenado de formularios.
Fecha del pedido Requerido por Núm. de requisa
(MM/DD/AAAA) (MM/DD/AAAA)
Precio Precio
Núm. Pieza Descripción Cantidad
unitario extendido
Blocs de notas, 4 pulg. X 5 pulg., caja de 25
Cinta transparente, 12mm x 33mm, caja de 12
Hi-Liter, colores surtidos, caja de 12
para introducir cheques puede proveer el siguiente número de cheque secuencial como valor predeterminado al
momento de exhibir el formulario del cheque nuevo. Si faltan cheques, el usuario modifica el número de cheque
para reflejar el cheque actual que se está introduciendo.
La entrada para los campos de las pantallas de visualización se puede restringir al formato alfanumérico para que,
por ejemplo, los usuarios puedan introducir sólo números en un campo que solicite un número de Seguro social, o que
puedan introducir sólo letras donde se requiera el nombre de una persona. Si se introducen números donde sólo se per-
miten letras, la computadora puede alertar al usuario mediante un sonido que el campo se llenó en forma incorrecta.
La principal ventaja de la interfaz del formulario de entrada/salida es que la versión impresa del formula-
rio de llenado provee una excelente documentación. Muestra las etiquetas de los campos, así como el contexto
para las entradas. Además, los formularios Web pueden devolver formularios incompletos al usuario con una
explicación de los datos que se deben introducir para completar la transacción. A menudo, los campos con datos
faltantes se marcan con un asterisco de color rojo. Los documentos basados en Web se pueden enviar de manera
directa a facturación si hay una transacción involucrada, o pueden ir directamente a una base de datos en tiempo
real si se va a enviar una encuesta. Los formularios basados en Web pasan la responsabilidad de la precisión al
usuario y ponen el formulario a su disposición para que lo completen y envíen las 24 horas del día, los 7 días de
la semana en cualquier parte del mundo.
Hay unas cuantas desventajas en los formularios de entrada/salida. La principal desventaja es que los usua-
rios experimentados en el sistema o una aplicación podrían impacientarse con los formularios de entrada/salida y
podrían garantizar maneras más eficientes de introducir datos.
www.xlibros.com
456 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 3
No me desaceleren
“L as he visto todas”, le comenta Carrie Moore. “Estuve aquí
cuando obtuvieron su primer sistema de cómputo. Creo que hasta
continúa con la entrevista. “Pero cualquier cosa que vaya a hacer,
no me desacelere. Una de las cosas que más me enorgullecen es que
he hecho una carrera de esto”, dice alegremente mientras apunta a todavía puedo vencer a los otros capturistas, que también son bue-
la gran pila de formularios de reclamaciones de seguros médicos nos”, agrega Carrie.
que ha estado introduciendo en el sistema de cómputo. Como ana- Con base en esta entrevista parcial con Carrie Moore, ¿qué tipo
lista de sistemas usted está entrevistando a Carrie, una capturista de de interfaz de usuario diseñará para ella y los otros operadores?
datos para AbundaCare (una empresa grande de seguros médicos), Suponga que incluso cuando el nuevo sistema está mejorado, de to-
sobre los cambios que se contemplan en el sistema de cómputo. das formas requerirá la introducción de cantidades masivas de datos
“Soy realmente rápida en comparación con los demás”, dice provenientes de variedad de formularios de seguros médicos envia-
mientras señala con la cabeza hacia los otros seis capturistas de la dos por los solicitantes.
sala. “Lo sé porque tenemos pequeños concursos todo el tiempo Compare y contraste en dos párrafos las interfaces como la de len-
para ver quién es el más rápido, con la menor cantidad de errores. guaje natural, de preguntas y respuestas, menús, formularios de entrada/
¿Ve esa tabla en la pared? Muestra cuántos datos hemos introducido salida, y documentos de llenado basados en Web. Después seleccione
y con qué rapidez. Las estrellas doradas muestran quién es el mejor y defienda una alternativa. ¿Qué cualidades de las que poseen Carrie y
cada semana. Las medidas de desempeño son mis amigas”. los otros capturistas (además de los datos que van a introducir) deter-
“En realidad no me importa si cambia las computadoras. Como minaron su elección? Haga una lista. ¿Hay más de una opción viable?
dije, ‘las he visto todas’”. Vuelve a teclear en su equipo mientras ¿Por qué sí o por qué no? Responda en un párrafo.
FIGURA 14.13
Interfaces de lenguaje de
comandos.
USAR VENDEDOR
USAR ABARR
IRA SUPERIOR
LISTA
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 457
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 4
los se convierte en todo un conjunto completo de decisiones y suposiciones sobre los tipos de usuarios que es-
pera atraer el sitio Web. El diseñador también debe adherirse a las convenciones que los usuarios esperan ahora
encontrar en los sitios Web.
www.xlibros.com
458 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.14
Mediante el uso de software como
Dragon NaturallySpeaking de
Nuance, un usuario puede decir
los comandos en su computadora.
En este ejemplo, para corregir una Sugerencias prácticas para
palabra el usuario despliega un
menú de palabras alternativas que
desarrollar un sitio Web
suenan igual. Use herramientas profesi
Estudie otros sitios Web Acostúmbrese
sibles al tacto (también conocidas simplemente como pantallas táctiles o tabletas táctiles) para los teléfonos mó-
viles como el iPhone y la BlackBerry están convirtiendo esta interfaz de usuario alternativa en algo familiar y de
uso extendido. Las investigaciones recientes examinan la forma de poder comercializar las tabletas táctiles sensi-
bles a presión. Estas interfaces se pueden usar con pantallas táctiles tanto grandes como pequeñas y son prácticas
para las aplicaciones como la pintura o escultura virtual, un ratón simulado y para instrumentos musicales como
un teclado de piano, donde la intensidad de la presión aplicada es crucial para la salida.
Con el reconocimiento de voz, el usuario habla a la computadora y el sistema es capaz de reconocer las
señales de voz de un individuo, convertirlas y almacenar la entrada. El reconocimiento de voz en los sistemas
de inventario ya se encuentra en operación; los automóviles ahora incluyen sistemas de entrada de voz que res-
ponden a los comandos de voz del conductor para navegar, cambiar la estación de radio o usar un teléfono con
Bluetooth conectado al vehículo.
Una ventaja de los sistemas de reconocimiento de voz es que pueden agilizar la entrada de datos en forma
considerable, además de que liberan las manos del usuario para otras tareas (como conducir, por ejemplo). La
entrada de voz agrega otra dimensión a la PC: ahora es posible agregar equipo y software que permita al usuario
de una PC hablar los comandos como “abrir archivo” o “guardar archivo” para no tener que usar el teclado o el
ratón. Los usuarios con movilidad limitada o discapacidad visual se pueden beneficiar de los sistemas de recono-
cimiento de voz. En el ejemplo que se muestra en la figura 14.14, para corregir una palabra el usuario despliega
un menú de palabras alternativas parecidas.
Al evaluar las interfaces hay que tener en cuenta ciertos estándares:
1. El periodo de capacitación necesario para los usuarios debe ser razonablemente corto.
2. En las primeras etapas de su capacitación, los usuarios deben ser capaces de introducir los comandos sin
pensar en ellos o tener que consultar un menú o manual de ayuda. Mantener las interfaces consistentes en
todas las aplicaciones es conveniente en este caso.
3. La interfaz debe ser transparente, de manera que haya pocos errores y los que ocurran no se deban a un mal diseño.
4. El tiempo que los usuarios y el sistema necesitan para recuperarse de los errores debe ser corto.
5. Los usuarios infrecuentes deben ser capaces de volver a aprender a usar el sistema rápidamente.
Hay muchas interfaces distintas disponibles, por lo que es importante tener en cuenta que una interfaz efec-
tiva requiere de mucho esfuerzo para poder lidiar con las cuestiones clave de la HCI. Tal vez los usuarios quieran
usar el sistema, por lo que debe parecerles atractivo, eficiente y divertido de usar.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 459
Como recordará, los elementos del TAM (modelo de aceptación de tecnología) indican que la utilidad y la
facilidad de uso percibidas tempranamente provocarán en el usuario la intención de usar el sistema y, en un mo-
mento dado, empezará a utilizarlo. Hay varios puntos clave para diseñar un buen diálogo:
1. Una comunicación significativa, de manera que la computadora comprenda lo que las personas introducen y
las personas comprendan lo que la computadora presenta o solicita.
2. Una mínima acción por parte del usuario.
3. Operación y consistencia estándar.
Comunicación significativa
El sistema debe presentar con claridad la información al usuario. Esto significa tener un título apropiado para
cada pantalla, minimizar el uso de las abreviaturas y proveer una retroalimentación clara al usuario. Los pro-
gramas de investigación deben mostrar los significados del código así como los datos en un formato editado;
por ejemplo, mostrar barras diagonales entre el mes, día y año en un campo de fecha o las comas y los puntos
decimales en un campo de cantidad monetaria. Hay que proveer instrucciones para el usuario en relación con
los detalles, como las asignaciones disponibles para las teclas de función. En una interfaz gráfica de usuario, el
cursor puede cambiar de forma dependiendo del trabajo que se esté realizando.
Los usuarios con menos habilidad para usar la computadora o los que realizan sus tareas con una compu-
tadora requieren de mayor comunicación. Los sitios Web deben mostrar más texto e instrucciones para guiar al
usuario por todo el sitio. Los sitios de intranets pueden tener menos diálogo, ya que hay requerimientos mínimos
en cuanto al grado de capacitación de los usuarios. Las imágenes de Internet deben tener descripciones de texto
desplegables o de sustitución cuando se utilicen imágenes como hipervínculos, ya que puede haber incertidum-
bre al interpretar su significado, en especial si el sitio se utiliza a nivel internacional. Cabe mencionar que los
lineamientos de la UE para la visualización de imágenes Web requieren que todas ellas estén etiquetadas, para
que los usuarios con discapacidad visual puedan escuchar cuando se anuncien descripciones escritas por medio
de software especial. La información de la línea de estado para las pantallas de GUI es otra forma de proveer
instrucciones para los usuarios.
Además hay que proporcionar pantallas de ayuda fáciles de usar. Muchas pantallas de ayuda de PC tienen
temas adicionales que se pueden seleccionar de manera directa mediante el uso de texto resaltado en la primera
pantalla de ayuda. Por lo general, estos hipervínculos están en un color distinto, lo cual los hace resaltar en
contraste con el resto del texto de ayuda. Recuerde usar iconos o texto además de la codificación de color para
poder hacer contacto con la mayor cantidad de usuarios que sea posible. Muchas GUI incorporan la ayuda me-
diante cuadros de información sobre las herramientas, donde se muestra un pequeño mensaje de ayuda para
identificar la función de un botón de comando cuando se coloca el cursor encima de éste. El otro lado de la co-
municación es que la computadora debe comprender lo que introdujo el usuario. Por ende, hay que editar todos
los datos que se introduzcan en la pantalla para que sean válidos.
www.xlibros.com
460 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Web no incluyen barras diagonales ni puntos decimales. Algunos formularios Web utilizan una serie de
campos de entrada con caracteres de edición entre ellos, como los paréntesis alrededor de un código
de área.
4. Usar valores predeterminados para los campos en las pantallas de entrada. Los valores predeterminados
se utilizan cuando el usuario introduce el mismo valor en un campo de pantalla para la mayoría de los
registros que se están procesando. El valor se muestra y el usuario puede oprimir Intro para aceptar el valor
predeterminado, o sobrescribirlo con uno nuevo. Las GUI pueden contener casillas de verificación y botones
de opción que se seleccionen al abrir un formulario Web o cuadro de diálogo. Los menús sensibles al
contexto aparecen cuando se hace clic en un objeto con el botón derecho del ratón. Estos menús contienen
opciones específicas para el objeto que está debajo del ratón.
5. Diseñar un programa de consulta (o de modificación, o eliminación) de manera que el usuario necesite
introducir sólo los primeros caracteres de un nombre o la descripción de un artículo. El programa muestra
una lista de todos los nombres que coincidan y, cuando el usuario selecciona uno, se muestra el registro
correspondiente.
6. Proveer pulsaciones de tecla para seleccionar las opciones de los menús desplegables. A menudo estas
opciones se seleccionan mediante un ratón y después se pulsa una tecla. A medida que los usuarios se van
familiarizando con el sistema, las teclas de método abreviado ofrecen un método más rápido para manipular
los menús desplegables, ya que ambas manos permanecen en el teclado. Esto ayuda a los usuarios a volverse
eficientes en sus tareas. En una PC o Mac, las pulsaciones de tecla por lo general requieren que se oprima
una tecla de función o la tecla Alt seguida de una letra. La figura 14.15 es un ejemplo de menús desplegables
anidados.
7. Usar botones de opción y listas desplegables para controlar las pantallas de nuevas páginas Web o
modificar formularios Web. Por ejemplo, hacer clic en un botón de opción puede cambiar una lista
desplegable para reflejar el botón de opción que se seleccionó. Se puede hacer clic en un botón de opción y
un formulario puede cambiar de acuerdo con la selección. Una lista desplegable puede cambiar o se puede
hacer clic en un botón de opción para ir a una nueva página Web. A menudo las listas desplegables se
proveen en una página Web para navegar con rapidez; al seleccionar una nueva página Web de la lista
desplegable el usuario es transportado a esa página.
8. Proveer control del cursor para los formularios Web y otras pantallas, de manera que el cursor se
desplace al siguiente campo cuando se haya introducido el número correcto de caracteres. Un ejemplo
sería cuando un usuario introduce un código de área para un teléfono de EE.UU. y, después de introducir los
tres caracteres, el cursor cambia al campo del número telefónico local. Otro ejemplo es cuando se introducen
códigos de claves de registro. A menudo los códigos están en grupos de cuatro o cinco letras y, cuando se
llena el primer campo, el cursor avanza al siguiente campo, y así en lo sucesivo. El analista debe examinar
cada campo para ver si es conveniente usar el control del cursor automático.
Cualquier combinación de estas ocho metodologías puede ayudar al analista a reducir el número de pulsa-
ciones de tecla requeridas por el usuario, con lo cual se agiliza la entrada de datos y se minimizan los errores.
FIGURA 14.15
Ejemplo de menús desplegables
anidados con teclas de método
abreviado de Microsoft Visio
Professional.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 461
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 5
www.xlibros.com
462 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Tipos de retroalimentación
ACUSAR LA ACEPTACIÓN DE LA ENTRADA La primera situación en la que los usuarios necesitan
retroalimentación es para saber si la computadora aceptó la entrada. Por ejemplo, cuando un usuario
introduce un nombre en una línea, la computadora provee retroalimentación al usuario al desplazar el cursor
un carácter a la vez cuando se introducen las letras correctamente. Un ejemplo Web sería una página Web
que muestra el mensaje “Se procesó su pago, Su número de confirmación es 1234567. Gracias por usar
nuestros servicios”.
RECONOCER QUE LA ENTRADA ESTÁ EN EL FORMATO CORRECTO Los usuarios necesitan retroalimentación
para saber que la entrada está en el formato correcto. Por ejemplo, un usuario introduce un comando y la
retroalimentación indica el mensaje “LISTO” mientras el programa progresa a un nuevo punto. Un mal ejemplo
de retroalimentación que indica al usuario que la entrada está en el formato correcto es el mensaje “ENTRADA
BIEN”, debido a que el mensaje ocupa espacio adicional, es ambiguo y no hace nada por animar al usuario a
que introduzca más datos. Al colocar un pedido en Web o realizar un pago, por lo general aparece una página de
confirmación para solicitar al usuario que revise la información y haga clic en un botón o imagen para confirmar
el pedido o pago.
NOTIFICAR QUE LA ENTRADA NO ESTÁ EN EL FORMATO CORRECTO La retroalimentación es necesaria para
advertir a los usuarios de que la entrada no está en el formato correcto. Cuando los datos son incorrectos, una
manera de informar al usuario es generar una ventana que describa brevemente el problema con la entrada y
explique cómo puede el usuario corregirlo, como se muestra en la figura 14.16.
Cabe mencionar que el mensaje correspondiente a un error al introducir la duración de la suscripción es
amable y conciso pero no enigmático, por lo que incluso hasta los usuarios inexpertos podrán entenderlo. La
duración de la suscripción para el boletín informativo en línea se introduce en forma incorrecta, pero la retroa-
limentación no hace mucho hincapié en el error del usuario, sino que le ofrece opciones (13, 26 o 52 semanas)
para que pueda corregirlo fácilmente. En una pantalla de GUI es común que la retroalimentación esté en forma
de un cuadro de mensaje con un botón Aceptar.
Los mensajes Web tienen varios formatos. Uno de los métodos es devolver una nueva página con el mensaje
a un lado del campo que contiene el error. La nueva página Web puede tener un vínculo para obtener ayuda adi-
cional. Este método funciona para todos los sitios Web; el servidor controla el proceso de detectar y dar formato
a la nueva página. Otro método utiliza JavaScript para detectar el error y mostrar un cuadro de mensaje en la
pantalla actual con detalles sobre el error específico. Una ventaja de este método es que no se tiene que enviar
la página Web al servidor, además de que es más sensible. Las desventajas son que, si se desactiva JavaScript,
no se detectará el error y sólo se mostrará un error a la vez. También debe haber una forma de detectar el error
FIGURA 14.16
La retroalimentación informa al
usuario que la entrada no estaba en
el formato correcto y muestra una
Lista de suscripciones al boletín informativo en línea de SOA
lista de opciones.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 463
en el servidor. Una segunda desventaja es que tal vez JavaScript no detecte los errores en los que hay que leer
tablas de la base de datos, como verificar un número de tarjeta de crédito. Esto se puede compensar mediante el
uso de Ajax para poder enviar el número al servidor y devolver un error a la página Web. Sin embargo, debemos
recordar que algunos usuarios desactivan de manera intencional el uso de JavaScript; por lo tanto, los analistas
necesitan seguir una variedad de tácticas al comunicar los errores.
Las páginas Web también pueden usar JavaScript para detectar varios errores y mostrar mensajes de texto en
la página. Hay que cuidar que los mensajes de error estén lo bastante remarcados como para que el usuario los
vea. Una línea de texto pequeña de color rojo podría pasar desapercibida. Se puede usar un cuadro de mensaje o
sonidos para alertar a los usuarios al ocurrir uno o más errores.
El analista debe decidir si se van a detectar e informar los errores cuando el usuario haga clic en el botón
Enviar o en un hipervínculo (a esto se le conoce como validación por lotes), o si se van a detectar los errores
uno a la vez, como cuando un usuario introduce un mes como 14 y desplaza el cursor a otro campo. El segundo
método es más riesgoso, ya que una mala codificación podría hacer que el navegador entre en un ciclo infinito y
el usuario tendrá que cerrarlo.
Hasta ahora hemos visto la retroalimentación visual en forma de texto o iconos, pero muchos sistemas
también cuentan con herramientas de retroalimentación de audio. Cuando un usuario introduce datos en
forma incorrecta, el sistema podría emitir un sonido en vez de proveer una ventana. Pero la retroalimentación
de audio por sí sola no es descriptiva, por lo que no es tan útil para los usuarios como las instrucciones en
pantalla. Use la retroalimentación de audio con moderación, tal vez para avisar de situaciones urgentes. El
mismo consejo se aplica también al diseño de sitios Web que se pueden ver en una oficina abierta, en donde
los sonidos se esparcen y las bocinas de escritorio de un compañero de trabajo están al alcance de los oídos
de otras personas.
EXPLICAR UN RETRASO EN EL PROCESAMIENTO Uno de los tipos más importantes de retroalimentación informa
al usuario que habrá un retraso en el procesamiento de su solicitud. Los retrasos mayores de 10 segundos
requieren retroalimentación, para que el usuario sepa que el sistema sigue funcionando.
La figura 14.17 muestra una pantalla que provee retroalimentación en una ventana para un usuario que acaba
de solicitar la impresión de la lista de suscripciones del boletín informativo electrónico. La pantalla muestra un
enunciado que asegura al usuario que la solicitud se está procesando, así como un anuncio en la esquina superior
derecha que instruye al usuario que “ESPERE” hasta que se haya ejecutado el comando actual. La pantalla tam-
bién provee la forma de detener la operación si es necesario.
Algunas veces durante los retrasos, mientras se instala nuevo software se ejecuta un pequeño tutorial sobre
la nueva aplicación, cuyo propósito es servir como distracción en vez de retroalimentación sobre la instalación.
A menudo se utiliza una lista de los archivos que se van a copiar y una barra de estado para tranquilizar al usuario
FIGURA 14.17
La retroalimentación indica al
usuario que habrá un retraso
durante la impresión.
Para
Todetener
Duración de la suscripción en semanas la impresión,
halt printing oprima P.P.
just typeM odo de pago
www.xlibros.com
464 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
y asegurarle que el sistema está funcionando en forma apropiada. Por lo general los navegadores Web muestran
las páginas Web que se están cargando y el tiempo restante.
Es imprescindible incluir retroalimentación al usar Ajax para actualizar los formularios Web. Como no se
carga una nueva página Web, el usuario tal vez no esté consciente de que se están recuperando datos del servidor
para modificar la página Web actual. Cuando cambia una lista desplegable, un mensaje tal como “Por favor es-
pere mientras se llena la lista.” informa al usuario sobre el cambio.
Es muy importante sincronizar la retroalimentación de este tipo. Una respuesta demasiado lenta del sistema
provocaría que el usuario introdujera comandos que impidan o interrumpan el procesamiento.
ACUSAR EL LLENADO DE UNA SOLICITUD Los usuarios necesitan saber cuándo se completa su solicitud para
poder introducir nuevas solicitudes. A menudo aparece un mensaje de retroalimentación específico cuando el
usuario completa una acción, como “Se agregó el registro del empleado”, “Se modificó el registro del cliente” o
“Se eliminó el artículo número 12345”.
NOTIFICAR QUE NO SE COMPLETÓ UNA SOLICITUD También se necesita la retroalimentación para hacer saber
al usuario que la computadora no puede completar una solicitud. Si la pantalla indica “No se pudo procesar
la solicitud. Revise la solicitud de nuevo”, el usuario puede entonces regresar para verificar si se introdujo la
solicitud en forma incorrecta, en vez de que siga introduciendo comandos que no se pueden ejecutar.
OFRECER AL USUARIO UNA RETROALIMENTACIÓN MÁS DETALLADA Los usuarios necesitan tener la seguridad
de que haya una retroalimentación más detallada disponible, y se les debe mostrar cómo pueden obtenerla. Se
pueden emplear comandos como Asistir, Instruir, Explicar y Más. El usuario también puede escribir un signo
de interrogación o hacer clic en un icono apropiado para obtener más retroalimentación. Se ha cuestionado el
uso del comando Ayuda como forma de obtener más información, ya que los usuarios se pueden sentir indefensos
o atrapados en una trampa de la que deben escapar. Pero como esta convención es la que está en uso y gracias a
que los usuarios están familiarizados con ella, el problema no es grave.
Al diseñar interfaces Web es posible incrustar hipervínculos para permitir al usuario saltar a las pantallas de
ayuda relevantes o ver más información. Por lo general, los hipervínculos se resaltan con subrayado, cursiva o un
color distinto. Pueden ser imágenes, texto o iconos.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 465
Además de la ayuda informal en el software, los sitios Web de los distribuidores son en extremo útiles para
actualizar controladores, visores y el software en sí. La mayoría de las publicaciones de cómputo en línea tienen
cierto tipo de “vigilancia de controladores” o “informe de errores” que vigila los tableros de anuncios y los sitios
Web en busca de programas útiles que se puedan descargar. Los programas buscarán en los sitios Web de los dis-
tribuidores las actualizaciones más recientes, informarán a los usuarios sobre éstas, ayudarán con las descargas y
en efecto actualizarán las aplicaciones del usuario.
www.xlibros.com
466 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 6
MENÚS CON ROLLOVER Es posible crear un menú (o botón) con rollover mediante hojas de estilo en cascada con
JavaScript y divisiones de HTML. El menú con rollover aparece cuando el cliente que usa el sitio Web desplaza
el cursor sobre un vínculo.
VÍNCULOS JERÁRQUICOS Crear una descripción del contenido del sitio por medio de la presentación de una
tabla de contenido en la página de inicio es otra manera de agilizar la navegación del sitio. Sin embargo,
este diseño impone varias restricciones sobre la creatividad del diseñador, y algunas veces el solo hecho
de presentar una lista de temas no transmite al usuario de manera adecuada la misión estratégica de la
organización.
MAPA DEL SITIO Diseñar y después mostrar de manera prominente el vínculo a un mapa del sitio es una tercera
forma de mejorar la eficiencia en la navegación. Recuerde incluir el vínculo al mapa del sitio en la página de
inicio y en todas las demás páginas también.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 467
ATRACTIVO DE LA MAC
Los megamotores de búsqueda —que obtienen resultados de varios motores de búsqueda, agrupan los resultados y
los muestran de una manera más útil que cualquier motor de búsqueda individual— han existido desde hace buen
tiempo. Hay una aplicación única en la plataforma Mac que va un paso más allá.
Esa aplicación es DEVONagent, un paquete de software que utiliza motores de búsqueda generales y especiali-
zados para obtener resultados, y después ofrece al usuario la opción de ver esos resultados en un mapa de temas
gráfico. Otra opción es ver los resultados en una lista clasificada por relevancia.
Los analistas encontrarán que DEVONagent es útil si comprenden y hacen uso del mapa de temas gráfico. También
es útil si se requieren búsquedas complejas (es decir, si las búsquedas estándar no profundizan lo suficiente para encon-
trar la información exacta que se necesita). Y también se puede usar en las búsquedas que se necesitan repetir con fre-
cuencia.
FIGURA 14.MAC
DEVONagent de DEVONtechnologies.
BARRA DE NAVEGACIÓN Por último, puede diseñar barras de navegación que se muestren de manera consistente
en la página de inicio, así como en la parte superior y en la parte izquierda de todas las demás páginas que
conforman el sitio. Una vez establecidas (durante la fase de requerimientos de información) las categorías más
útiles y más usadas (por lo general categorías como “Nuestra empresa”, “Nuestros productos”, “Compre ahora”,
“Contacto”, “Mapa del sitio” y “Buscar”), recuerde incluirlas en todas las páginas.
OTRAS OPCIONES DE NAVEGACIÓN Incluir una función de búsqueda es otra opción. Incluya el agregar un motor
de búsqueda tal como Google a su sitio. Las funciones simples de búsqueda funcionan bien para sitios pequeños
y manejables, pero a medida que éstos crecen, se requieren funciones de búsqueda avanzadas que incluyen lógica
booleana (que veremos más adelante en este capítulo).
También es importante crear flexibilidad en la forma en que los usuarios navegan por la Web. Un diseña-
dor experto de sitios Web trataría de incorporar muchas formas de buscar información sobre un tema especí-
fico. En la figura 14.18 se muestra una página Web de DinoTech. Por ejemplo, un usuario interesado en una
carrera profesional internacional de TI puede buscar información del sitio Web de DinoTech de tres maneras
www.xlibros.com
468 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.18
Un ejemplo de una página Web
que permite a los usuarios navegar
a la página deseada en tres
formas.
distintas. Si les interesa trabajar en Argentina, pueden trabajar en la bandera de Argentina, hacer clic en el
nombre del país o en el mapa que representa a Argentina.
Es conveniente diseñar un sitio Web con navegación para los usuarios con distinto procesamiento cognosci-
tivo o con distintos intereses. Es incluso posible que el mismo usuario pueda usar los tres métodos antes mencio-
nados en distintos momentos. Todo ello aumenta la usabilidad de un sitio Web.
Sin embargo, la principal prioridad en la navegación es que, sin importar lo que haga, debe facilitar lo más
que pueda a los usuarios el proceso de regresar a una página anterior y que también puedan regresar con relativa
facilidad al lugar en donde entraron al sitio de su cliente. Su principal preocupación es mantener a los consumi-
dores en el sitio Web. Entre más tiempo estén en el sitio, mayor será la probabilidad de que compren algo. Por
lo tanto se debe asegurar que, si los usuarios navegan a un vínculo en el sitio Web de su cliente, puedan hallar su
camino de vuelta. Al hacer estas cosas asegurará la pegajosidad del sitio Web. No es conveniente crear barreras
para el consumidor que desea regresar al sitio Web de su cliente.
DISEÑO DE CONSULTAS
Cuando los usuarios hacen preguntas o se comunican con la base de datos, se dice que la consultan. Hay seis
tipos distintos de consultas que son las más comunes. Si usted pone mucha atención al diseño de las consultas,
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 469
FIGURA 14.19
Los años Es posible realizar seis tipos
son los básicos de consultas en una tabla
atributos. que contiene entidades, atributos
y valores.
HISTORIAL-INGRESOS
NUMERO NOMBRE
DEPARTAMENTO E/R ANIO-2006 ANIO-2007 ANIO-2008 ANIO-2009
EMPLEADO EMPLEADO
Los números de
empleados son
las entidades. n
Los salarios so
los valores.
podrá ayudar a reducir el tiempo que invierten los usuarios en consultar la base de datos, los ayudará a encontrar
los datos que desean y obtendrán una experiencia más cómoda en general.
Tipos de consultas
Las preguntas que planteamos con respecto a los datos de nuestra base de datos se conocen como consultas. Hay
seis tipos básicos de consultas. Cada consulta involucra a tres elementos: una entidad, un atributo y un valor. En
cada caso se proporcionan dos de estos elementos y la intención de la consulta es encontrar el elemento restante.
Usaremos la figura 14.19 para ilustrar todos los ejemplos de las consultas.
TIPO DE CONSULTA 1 Se proporciona la entidad y uno de los atributos de ésta. El propósito de la consulta es
encontrar el valor. La consulta se puede expresar de la siguiente manera:
¿Cuál es el valor de un atributo especificado para una entidad específica?
Algunas veces es más conveniente usar la notación para formular la consulta. Esta consulta se puede escribir así:
V d (E, A)
donde V representa el valor, E la entidad y A el atributo; se proporcionan las variables entre paréntesis.
La pregunta
¿Cuánto ganó el empleado número 73712 en el año 2009?
se puede declarar de manera más específica como
¿Cuál es el valor del atributo ANIO-2009 para la entidad NUMERO EMPLEADO 73712?
Se encontrará el registro que contiene al empleado número 73712 y la respuesta a la consulta será $47,100.
TIPO DE CONSULTA 2 La intención del segundo tipo de consulta es encontrar una entidad o unas entidades cuando
se proporciona un atributo y un valor. El tipo de consulta 2 se puede establecer de la siguiente manera:
¿Qué entidad tiene un valor específico para un atributo en particular?
Como los valores también pueden ser numéricos, es posible buscar un valor igual a, mayor que, menor que, no
igual a, mayor o igual a, y así en lo sucesivo. El siguiente es un ejemplo de este tipo de consulta:
¿Qué empleado(s) obtuvo más de $50,000 en 2009?
E d (V, A)
www.xlibros.com
470 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
En este caso tres empleados ganaron más de $50,000, por lo que la respuesta será un listado de estos tres números
de empleado: 72845, 72888 y 80345.
TIPO DE CONSULTA 3 El propósito de este tipo de consulta es determinar qué atributos se ajustan a la descripción
provista cuando se proporcionan la entidad y el valor. El tipo de consulta 3 se puede establecer de la siguiente
manera:
¿Qué atributo(s) tiene un valor especificado para una entidad en particular?
Esta consulta es útil cuando muchos atributos similares tienen la misma propiedad. El siguiente ejemplo tiene
atributos similares (años específicos) que contienen los salarios anuales para los empleados de la empresa:
¿En qué años ganó el empleado número 72845 más de $50,000?
o, dicho en forma más precisa,
¿Qué atributos {ANIO-2006, ANIO-2007, ANIO-2008, ANIO-2009} tienen un valor [gt] 50,000 para la
entidad NUMERO-EMPLEADO = 72485?
en donde la lista opcional entre llaves ({ }) es el conjunto de atributos elegibles.
La notación para el tipo de consulta 3 es
A d (V, E)
En este ejemplo, Waters (número de empleado 72845) hizo más de $50,000 durante dos años. Por lo tanto, la res-
puesta será el año 2007 y el año 2009. El tipo de consulta 3 es más raro que los dos tipos anteriores debido a que
requiere tener atributos similares que exhiban las mismas propiedades.
TIPO DE CONSULTA 4 El tipo de consulta 4 es similar al tipo de consulta 1. La diferencia es que se desean los
valores de todos los atributos. La consulta 4 se puede expresar de la siguiente manera:
Liste todos los valores para todos los atributos de una entidad específica.
Un ejemplo del tipo de consulta 4 es:
Liste todos los detalles en el archivo del historial de ingresos para el empleado número 72888.
La notación para el tipo de consulta 4 es
todos los V d (E, todos los A)
La respuesta para esta consulta será todo el registro completo para el empleado llamado Dryne (número de em-
pleado 72888).
TIPO DE CONSULTA 5 El quinto tipo de consulta es otra consulta global, pero es similar en forma al tipo de
consulta 2. Podemos establecerlo de la siguiente manera:
Liste todas las entidades que tengan un valor específico para todos los atributos.
El siguiente es un ejemplo del tipo de consulta 5:
Liste a todos los empleados cuyos ingresos sean superiores a $50,000 en cualquiera de los años disponibles.
La notación para el tipo de consulta 5 es
todas los E d (V, todos los A)
La respuesta a esta consulta será 72845, 72888 y 80345.
TIPO DE CONSULTA 6 El sexto tipo de consulta es similar al tipo de consulta 3. La diferencia es que el tipo
de consulta 6 solicita un listado de los atributos para todas las entidades, en vez de hacerlo para una entidad
específica. Podemos establecer el tipo de consulta 6 de la siguiente manera:
Liste todos los atributos que tengan un valor especificado para todas las entidades.
El siguiente es un ejemplo del tipo de consulta 6:
Liste todos los años en que los ingresos hayan sido superiores a $40,000 para todos los empelados de la
empresa.
La notación para el tipo de consulta 6 es
todos los A d (V, todas las E)
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 471
La respuesta será ANIO-2007, ANIO-2008 y ANIO-2009. Al igual que con el tipo de consulta 3, el tipo de
consulta 6 no se utiliza tanto como los demás tipos.
CREACIÓN DE CONSULTAS MÁS COMPLEJAS Los seis tipos anteriores de consultas son sólo bloques de
construcción para consultas más complejas. Se pueden formar expresiones, conocidas como expresiones
booleanas, para las consultas. Un ejemplo de una expresión booleana es:
Liste todos los empleados que tengan códigos postales mayores o iguales a 60001 y menores que 70000, y
que hayan pedido más de $500 de nuestros catálogos o hayan hecho por lo menos cinco pedidos en el
último año.
Una dificultad con este enunciado es determinar qué operador (por ejemplo, AND [Y]) pertenece a cuál con-
dición; también es difícil determinar la secuencia en la que se deben llevar a cabo las partes de la expresión. Lo
siguiente puede ser de utilidad para aclarar este problema:
LISTE A TODOS LOS CLIENTES QUE TENGAN (CODIGO-POSTAL GE 60001 AND CODIGO-
POSTAL LT 70000) AND (MONTO-PEDIDO GT 500 OR NUMERO-PEDIDOS GE 5)
Ahora se elimina parte de la confusión. La primera mejora es que los operadores se expresan con más cla-
ridad como GE (mayor o igual que), GT (menor que) y LT (menor que) en vez de usar frases en español, como
“al menos”. En segundo lugar, los atributos reciben distintos nombres, como MONTO-PEDIDO y NUMERO-
PEDIDOS. En el primer enunciado se hizo referencia a estos atributos como “hayan pedido” y “hayan hecho”.
Por último, se utilizan paréntesis para indicar el orden en el que se va a realizar la lógica. Lo que esté entre pa-
réntesis se realiza primero.
Por lo general las operaciones se realizan en un orden predeterminado de precedencia. Generalmente las
operaciones aritméticas se realizan primero (exponenciación, después multiplicación o división y luego suma o
resta). A continuación se realizan las operaciones de comparación. Estas operaciones son GT (mayor que), LT
(menor que), etcétera. Por último se realizan las operaciones booleanas (primero AND [Y] y después OR [O]).
Dentro del mismo nivel el orden va generalmente de izquierda a derecha. La precedencia se sintetiza en la fi-
gura 14.20.
Métodos de consulta
Dos métodos de consulta populares son las consultas mediante ejemplos y el lenguaje de consulta estructurado.
CONSULTA MEDIANTE EJEMPLOS La consulta mediante ejemplo (QBE) es un método simple pero potente para
implementar consultas en los sistemas de bases de datos, como Microsoft Access. Los campos de la base de
datos se seleccionan y muestran en una cuadrícula, y los valores solicitados en la consulta se introducen en el
área del campo o debajo de éste. La consulta debe ser capaz de seleccionar ambas filas de la tabla que coincidan
con las condiciones, así como las columnas específicas (campos). Es posible establecer condiciones complejas
para seleccionar registros y el usuario puede especificar con facilidad las columnas que desea ordenar. La figura
14.21 es un ejemplo de una consulta mediante el uso de Microsoft Access. La pantalla de diseño de la consulta se
divide en dos porciones. La porción superior contiene las tablas seleccionadas para la consulta y sus relaciones,
y la porción inferior contiene la cuadrícula de selección de la consulta. Los campos de las tablas de la base de
datos se arrastran a la cuadrícula.
Las primeras dos filas contienen el campo y la tabla en donde se encuentra ese campo. La siguiente fila
contiene información sobre el orden. En este ejemplo los resultados se ordenarán por NOMBRE CLIENTE
(CUSTOMER NAME). Una marca de verificación en el cuadro Mostrar (Show) (cuarta fila hacia abajo) indica
que el campo se debe mostrar en los resultados. Cabe mencionar que se seleccionan los elementos NUMERO
www.xlibros.com
472 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U LT O R Í A 1 4 . 7
RENTA-DISFRACES
FECHA DIAS
NUMERO NUMERO FECHA VENCI- RENTA TIPO DE SOLICITUDES
DISFRAZ DESCRIPCION TRAJE COLOR COSTO SALIDA MIENTO AAF DISFRAZ RECHAZADAS
FIGURA 14.C1
Una porción de la base de datos de la tienda Merman’s Costume Rental.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 473
FIGURA 14.21
Consulta mediante ejemplos en
Microsoft Access.
AND, y dos condiciones en distintas filas representan una condición OR. Esta consulta especifica que el usuario
debe seleccionar un Cliente activo (Active Customer) y un Cliente general (General Client) o de descuento (Dis-
count Customer).
Los resultados de una consulta se muestran en una tabla como en la figura 14.22. Cabe mencionar que
no aparecen CODIGO ESTADO CUENTA (ACCOUNT STATUS CODE) ni CODIGO TIPO CUENTA (AC-
COUNT TYPE CODE). No están marcados y se incluyen en la consulta sólo para fines de selección. Como al-
ternativa se muestran los significados del código, que son más útiles para el usuario. Los nombres de los clientes
están en secuencia por orden alfabético.
LENGUAJE DE CONSULTA ESTRUCTURADO El lenguaje de consulta estructurado (SQL) es otra manera popular
de implementar consultas. Utiliza una serie de palabras y comandos para seleccionar las filas y columnas que
deben aparecer en la tabla resultante. La figura 14.23 contiene código de SQL. La palabra clave SELECT
DISTINCTROW determina las filas que se van a seleccionar. La palabra clave WHERE especifica la condición
que debe usar el NOMBRE CLIENTE para seleccionar los datos introducidos en el parámetro LIKE.
FIGURA 14.22
Una consulta mediante ejemplo
para ESTADO CLIENTE
(CUSTOMER STATUS) produce
estos resultados.
www.xlibros.com
474 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.23
Lenguaje de consulta estructurado
(SQL) para la consulta del SELECT DISTINCTRO
W
parámetro NOMBRE CLIENTE. Cliente.[Numero clie
nte],
Cliente.[Nombre clie
nte],
Cliente.Ciudad,
Cliente.Telefono
FROM Cliente
WHERE (((Cliente.[No
mbre cliente])
Like ([Escriba un No
mbre de cliente parcia
l] & "*")));
RESUMEN
Examinamos la interacción humano-computadora (HCI), una Combine interfaces como menús desplegables e interfaces gráficas
variedad de interfaces, el diseño de la interfaz de usuario, el diseño para aumentar la efectividad. La Web ha impuesto nuevos retos
de la retroalimentación del usuario y el diseño de la retroalimen- para los diseñadores, ya que no conocen al usuario.
tación y navegación de sitios Web de comercio electrónico. Nos La necesidad que tienen los usuarios de retroalimentación
enfocamos en comprender la HCI para asegurar la funcionalidad del sistema es también una consideración importante. La retroa-
y usabilidad de los sistemas computacionales que diseñamos. limentación es casi siempre visual, siendo el texto, los gráficos
Cuando los analistas crean un ajuste apropiado entre los elemen- y los iconos los tipos más comunes de retroalimentación visual.
tos de la HCI del humano, la computadora y la tarea, se produce La retroalimentación de audio también puede ser efectiva.
una mejora en el rendimiento y un bienestar psicológico y físico Para mejorar la funcionalidad de los sitios Web hay que
del individuo en general. obtener retroalimentación del cliente por medio de botones de
Los diseños se enfocan en desarrollar un ajuste apropiado. retroalimentación automática por correo electrónico o mediante
Los analistas pueden usar el TAM (Modelo de aceptación de la la inclusión de formularios en blanco en el sitio Web. Cuatro
tecnología) para organizar su modo de pensar acerca de si los estrategias importantes de diseño de navegación mejoran la pe-
usuarios aceptarán la tecnología y la utilizarán en un momento gajosidad de los sitios Web de comercio electrónico: 1) menús
dado, mediante un análisis de la utilidad y facilidad de uso per- con rollover, 2) visualizaciones jerárquicas de vínculos en la
cibidas desde la perspectiva del usuario. pantalla de entrada; 3) mapas del sitio y 4) barras de navegación
La usabilidad identifica lo que funciona y no funciona para los que ofrecen la navegación con un solo clic.
usuarios. Las consideraciones físicas del diseño de la HCI incluyen Las consultas están diseñadas para permitir a los usuarios
visión, oído y tacto. Hay que tener en cuenta las discapacidades y extraer datos significativos de la base de datos. Hay seis tipos
limitaciones físicas durante el diseño de tareas e interfaces. Hay básicos de consultas que se pueden combinar mediante el uso de
gran variedad de interfaces de usuario y dispositivos de salida. lógica booleana para formar consultas más complejas. La con-
Algunas interfaces se adaptan muy bien a los usuarios inexpertos, sulta mediante ejemplo y el SQL son dos formas comunes de
mientras que otras se adaptan mejor a los usuarios experimentados. consultar sistemas de bases de datos.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 475
EXPERIENCIA DE HYPERCASE® 14
FIGURA 14.HC1
En HyperCase podrá ver cómo los usuarios procesan información para poder crear una
interfaz de usuario más efectiva.
www.xlibros.com
476 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
PREGUNTAS DE REPASO
1. Defina HCI.
2. Explique cómo el ajuste entre los elementos de HCI del humano, la computadora y las tareas a
desempeñar conducen a un buen desempeño y bienestar.
3. ¿Cuáles son los componentes del término desempeño en el contexto de la HCI?
4. ¿Qué significa la palabra bienestar cuando se utiliza en una metodología de la HCI?
5. ¿Cuáles son las dos variables del Modelo de aceptación de la tecnología (TAM)?
6. Haga una lista de cinco de las once heurísticas de usabilidad para juzgar la usabilidad de los sistemas
computacionales y los sitios Web de comercio electrónico proporcionados por Nielsen y otros.
7. Describa algunas de las formas en que una tabla dinámica permite a un usuario ordenar datos.
8. Mencione tres consideraciones físicas de las que el diseño de HCI se ocupa.
9. Mencione tres formas en que los analistas pueden mejorar el diseño de tareas o de interfaces para
ayudar, en forma respectiva, a una persona con discapacidad visual, auditiva o móvil.
10. ¿Cuáles son los cinco objetivos para diseñar interfaces de usuario?
11. Defina las interfaces de lenguaje natural. ¿Cuál es su mayor desventaja?
12. Explique lo que significa interfaces de pregunta y respuesta. ¿A qué tipo de usuarios están mejor
acostumbrados?
13. Describa cómo utilizan los usuarios los menús en pantalla.
14. ¿Qué es un menú anidado? ¿Cuáles son sus ventajas?
15. Defina los formularios de entrada/salida en pantalla. ¿Cuál es su principal ventaja?
16. ¿Cuáles son las ventajas de los formularios de llenado basados en Web?
17. ¿Cuáles son las desventajas de las interfaces de formularios de llenado basados en Web?
18. Explique lo que son las interfaces de lenguaje de comandos. ¿A qué tipo de usuarios se adaptan mejor?
19. Defina las interfaces gráficas de usuario. ¿Cuál es la dificultad clave que presentan para los
programadores?
20. ¿Para qué tipo de usuario es una GUI especialmente efectiva?
21. ¿Cuáles son los tres lineamientos para diseñar un buen diálogo en pantalla?
22. ¿Cuáles son las funciones de los iconos, gráficos y color para proporcionar retroalimentación?
23. Mencione ocho formas para lograr el objetivo de la acción mínima del operador al diseñar una
interfaz de usuario.
24. Mencione cinco estándares que puedan ayudar a evaluar interfaces de usuario.
25. ¿Cuáles son las siete situaciones que requieren retroalimentación para los usuarios?
26. ¿Cuál es una manera aceptable de decir al usuario que se aceptó la entrada?
27. Cuando se informa a un usuario que su entrada no está en el formato correcto, ¿qué retroalimentación
adicional hay que proporcionar al mismo tiempo?
28. Mencione tres formas de notificar a un usuario Web que la entrada no está en el formato correcto.
29. ¿Por qué es inaceptable notificar al usuario que la entrada no es correcta sólo mediante el uso de
sonidos o zumbidos audibles?
30. Cuando no se completa una solicitud, ¿qué retroalimentación hay que proveer al usuario?
31. Describa dos tipos de diseños de sitios Web para obtener retroalimentación de los clientes.
32. Mencione cuatro formas prácticas en las que un analista puede mejorar la facilidad de navegación del
usuario y la pegajosidad de un sitio Web de comercio electrónico.
33. ¿Qué son vínculos de hipertexto? ¿Dónde se deben usar?
34. Describa qué es una aplicación web híbrida (mashup).
35. Haga una lista con notación abreviada de los seis tipos de consultas básicas.
PROBLEMAS
1. Manu Narayan es dueño de varios hoteles de primera clase en todo el mundo, incluyendo
propiedades en Manhattan, Mumbai e incluso algunos en los suburbios. Él desea asegurarse de que la
interfaz humano-computadora sea apropiada para cada cultura, pero también desea poder compartir
el software entre todos los departamentos de reservaciones de sus hoteles. Diseñe una interfaz de
menús anidados para un sistema de reservaciones de llegadas y partidas del hotel que se pueda usar a
nivel internacional. Utilice números para seleccionar cada elemento del menú. Muestre cómo luciría
cada menú en una pantalla de computadora.
2. Stefan Lano necesita pantallas para mostrar el inventario de instrumentos musicales en su cadena de
tiendas de música, que da servicio a músicos que tocan en orquestas sinfónicas de clase mundial en
Basel, Suiza; Buenos Aires, Argentina; Filadelfia y Nueva York, E.U. Diseñe una interfaz de llenado
de formularios para el control de inventario de los instrumentos musicales en las cuatro tiendas que
se pueda usar en una pantalla de PC. Suponga que el español será el lenguaje de interfaz.
3. Diseñe una interfaz de llenado de formularios basados en Web para realizar la misma tarea que en el
problema 2.
a. ¿Qué dificultades encontró? Descríbalas en un párrafo.
b. De los dos diseños que hizo, ¿cuál podría decir que se adapta mejor a la tarea del Sr. Lano? ¿Por
qué? Mencione tres razones de su elección. ¿Cómo evaluaría su usabilidad?
4. Una agencia de viajes ubicada en el Reino Unido, Euan Morton, LLC, desea que el equipo de
sistemas que usted dirige diseñe una interfaz de lenguaje de comandos que pueda usar para reservar
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 477
asientos para las aerolíneas con las que su empresa tiene sólidos lazos comerciales, como British Air, RyanAir y Virgin
Atlantic.
a. Muestre cuál sería la apariencia de la interfaz en una pantalla estándar.
b. Haga una lista de los comandos necesarios para reservar un asiento de la aerolínea y anote lo que significa cada
comando.
5. Una ejecutiva de Ti de nombre Felicia Finley que proviene de Jersey IT Innovators, Inc., le ha pedido que diseñe una
interfaz gráfica de usuario para un escritorio ejecutivo que le pueda ayudar en su trabajo. Use iconos para los archiveros,
un bote de basura, un teléfono, etcétera. Muestre cuál sería su apariencia en la pantalla de computadora.
6. Nick, famoso chef y propietario de un restaurante de Williamsburg, Nueva York, desea poder recibir una
retroalimentación clara en los sistemas que se utilizan para administrar sus diversos restaurantes de “atracción turística”.
Diseñe una pantalla que provea una retroalimentación apropiada para un usuario cuyo comando no se pueda ejecutar.
7. Diseñe una pantalla para un paquete de software de nómina que muestre información para indicar a Nick, del problema 6,
cómo puede obtener una retroalimentación más detallada.
8. Diseñe una pantalla basada en Web que muestre una manera aceptable de decir a Nick que se aceptó la entrada de su sistema.
9. Diseñe un formulario de retroalimentación para los clientes del restaurante de Nick mediante el uso de un sitio Web de
comercio electrónico.
10. Escriba seis consultas para el archivo en el problema 1 del capítulo 13.
11. Escriba seis consultas para la relación en 3NF en el problema 5 del capítulo 13.
12. Diseñe una búsqueda que encuentre los potenciales competidores de una empresa como World’s Trend en la Web.
Suponga que usted es el cliente.
13. Busque los potenciales competidores de World’s Trend en la Web (no encontrará a la empresa World’s Trend en la Web,
ya que es una compañía ficticia). Haga una lista de los que encuentre.
PROYECTOS EN GRUPO
1. Con los miembros de su grupo, cree un menú desplegable para una agencia de empleos que relacione los potenciales
candidatos con las vacantes disponibles. Incluya una lista de teclas para seleccionar directamente las opciones del menú;
utilice el formato Alt-X. El menú tiene las siguientes opciones:
www.xlibros.com
478 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
BIBLIOGRAFÍA SELECCIONADA
Adam, A. y D. Kreps. “Web Accessibility: A Digital Divide for Disabled People?” En Societal and Organi-
zational Implications for Information Systems, IFIP Federación Internacional para el Procesamiento de
la Información, Vol. 208. Editado por E. Trauth, D. Howcraft, T. Butler, B. Fitzgerald y J. DeGross, pp.
217-228. Boston: Springer, 2006.
Barki, H. y J. Hartwick. “Measuring User Participation, User Involvement, and User Attitude”. MIS Quar-
terly, Vol. 18, Núm. 1, 1994, pp. 59-82.
Berstel, J., S. C. Reghizzi, G. Roussel y P. San Pietro. “A Scalable Formal Method for Design and Automa-
tic Checking of User Interfaces”. ACM Transactions on Software Engineering and Methodology, Vol.
14, Núm. 2, abril de 2005, pp. 124-167.
Carey, J., D. Galletta, J. Kim, D. Te’eni, B. Wildemuth y P. Zhang. “The Role of Human-Computer Interac-
tion in Management Information Systems Curricula: A Call to Action”. Communications of the Asso-
ciation for Information Systems, Vol. 13, 2004, pp. 357-379.
Davis, F. “Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology”.
MIS Quarterly, Vol. 13, Núm. 3, 1989, pp. 319-340.
Davis, G. B. y M. H. Olson. Management Information Systems: Conceptual Foundations, Structure, and
Development. Nueva York: McGraw-Hill, 1985.
Galleta, D. y P. Zhang (Eds.). Human-Computer Interaction and Management Information Systems: Appli-
cations. Armonk, NY: M. E. Sharpe, 2006.
Greene, K. “A Better, Cheaper Multitouch Interface”. Technology Review, marzo 2009, www.technologyre-
view.com/computing/22358/?a=f. Último acceso el 19 de abril de 2009.
Hornbaek, K. y E. Frokjaer. “Comparing Usability Problems and Redesign Proposals as Input to Practical
Systems Development”. CHI 2005, abril 2-7, 2005, pp. 391-400.
Mantei, M. M. y T. J. Teorey. “Incorporating Behavioral Techniques in the System Development Lifecycle”.
MIS Quarterly, Vol. 13, Núm. 3, septiembre 1989, pp. 257-267.
Nielsen, J. y R. L. Mack. Usability Inspection Methods. Nueva York: John Wiley, 1994.
Nielsen, J., R. Molich, C. Snyder y S. Farrell. E-Commerce User Experience. Fremont, CA: Norman Nielsen
Group, 2001.
Rubin, J. Handbook of Usability Testing. Nueva York: John Wiley, 1994.
Schneiderman, B. y C. Plaisant. Designing the User Interface: Strategies for Effective Human-Computer
Interaction. Nueva York: Addison-Wesley, 2005.
Te’eni, D. J. Carey y P. Zhang. Human Computer Interaction: Developing Effective Organizational Systems.
Nueva York: John Wiley, 2007.
Departamento de salud y servicios humanos de los EE.UU. “Guía de usabilidad” (para desarrollar sitios
Web). Disponible en www.usability.gov. Último acceso el 19 de abril de 2009.
Comisión para la Igualdad de Oportunidades en el Empleo de los EE.UU., sitio Web que lista las obligacio-
nes del patrón bajo la Ley de estadounidenses con discapacidades. Disponible en www.eeoc.gov/types/
ada.html. Último acceso el 19 de abril de 2009.
UsabilityNet. “Overview of the User Centered Design Process”. Disponible en: www.usabilitynet.org/
management/b_overview.htm. Último acceso el 19 de abril de 2009.
Venkatesh, V., M. G. Morris, G. B. Davis y F. D. Davis. “User Acceptance of Information Technology:
Toward a Unified View”. MIS Quarterly, Vol. 27, Núm. 3, 2003, pp. 425-478.
Zhang, P., J. Carey, D. Te’eni y M. Tremaine. “Integrating Human-Computer Interaction Development into
the System Development Life Cycle: A Methodology”. Communications of the Association for Infor-
mation Systems, Vol. 15, 2005, pp. 512-543.
Zhang, P. y D. Galleta (Eds.). Human Computer Interaction and Management Information Systems: Foun-
dations. Armonk, NY: M.E. Sharpe, 2006.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 479
EPISODIO 14
Caso de la CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
www.xlibros.com
480 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Después de completar cada opción, hay que volver a mostrar la misma pantalla, con las áreas de entrada en blanco, hasta
que se haga clic en el icono Salir.
Al salir de una opción hay que mostrar el menú anterior.
Hay que utilizar listas desplegables siempre que sea posible en las pantallas Web y de GUI.
Hay que usar casillas de verificación y botones de opción para realizar selecciones siempre que sea posible.
Los botones predeterminados deben estar delineados de tal forma que el usuario pueda oprimir Intro para seleccionarlos.
5. Hay que validar los datos que entran al sistema. Los lineamientos son:
Los campos específicos se deben verificar de acuerdo a los criterios de edición.
A medida que se detecten errores, los operadores deben recibir la oportunidad de aceptar o realizar correcciones a los
datos introducidos.
Cuando no se detecten errores en una transacción, hay que presentar la entrada al operador para una confirmación visual.
El operador debe tener la oportunidad de aceptarla o de hacer las correcciones en los datos introducidos.
Al examinar las diversas pantallas e informes (aproximadamente 30 en Access, así como muchas páginas Web), Chip y
Anna deciden dividir el menú en varias funciones. “¿Cómo dividimos estas diversas funciones en un conjunto de menús?”,
preguntó Chip.
“¿Por qué no usamos un diagrama de descomposición para organizar las funciones en una jerarquía?”, respondió Anna.
Chip y Anna empiezan a trabajar en el diagrama. Las interacciones del menú se representarán en una estructura jerárquica, en
donde las opciones se mostrarán en rectángulos y el menú en general se representará mediante el rectángulo en la parte superior.
Cada menú secundario aparecerá debajo del menú principal, con los programas de pantalla en el nivel más bajo. El menú
principal tendrá seis opciones principales, como se muestra en la figura E14.1: 1) Actualizar software (Update Software),
2) Actualizar hardware (Update Hardware), 3) Consultar (Inquiry), 4) Modificar códigos (Modify Codes), 5) Capaci-
tación (Training) y 6) Informe (Report). Cada una de estas opciones se subdivide en menús más pequeños o en funciones
individuales. El Menú Consulta se subdivide en dos menús más pequeños, Opciones de software (Software Options) y
Opciones de hardware (Hardware Options), así como una opción para ejecutar la Consulta para el experto de software
(Software Expert Inquiry).
FIGURA E14.1
Jerarquía de pantallas para el
sistema de cómputo.
Menú principal
del sistema
de cómputo
Consulta de Consulta de
características detalles
de hardware de hardware
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 481
FIGURA E14.2
Menú principal para el sistema
de la computadora.
Los rectángulos en el diagrama de descomposición funcional se implementan mediante una serie de listas de menús des-
plegables, las cuales se muestran en la figura E14.2. Cabe mencionar que el menú Consulta tiene funciones que corresponden
a los rectángulos en la figura anterior. Se incluye una fila de botones para las funciones comunes debajo de los menús. Las
funciones de menú se incluyen como un conjunto de botones en el área principal de la pantalla; se puede hacer clic en estos
botones para ejecutar los programas correspondientes. Se decidió que los programas Agregar computadora (Add Computer),
Agregar paquete de software (Add Software Package) y Modificar computadora (Change Computer) se ejecutarían di-
rectamente desde el menú principal. Al hacer clic en los otros botones aparecen los cuadros de diálogo de selección, con opcio-
nes para seleccionar programas.
“También vamos a incluir menús desplegables para las páginas”, comenta Anna. “Éstos utilizan un índice z para colocarlos
enfrente de la página Web. Se despliegan cuando el usuario coloca el ratón encima de ellos y desaparecen cuando quita el ratón
de ellos.
“Algunas veces eso puede ser molesto”, recalca Chip. “La página Web destella constantemente los menús cuando se mueve
el ratón sobre la página”.
“Podemos agregar un retraso para que el despliegue ocurra cuando el ratón esté encima durante más de un breve segundo”,
dice Anna en tono pensativo.
“Estos menús deben ser consistentes para el conjunto de páginas y formularios Web”, reflexiona Chip. “Podemos usar el
mismo código y estilos en varias páginas Web”.
Después de cierta deliberación cuidadosa, el diseño de los menús Web está completo. La figura E14.3 muestra el menú
final.
FIGURA E14.3
Un menú Web de la CPU que
muestra las opciones desplegables
que aparecen frente a la página
Web principal.
www.xlibros.com
482 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
“He aquí lo que pienso que deberían ser los lineamientos para los programas de actualización”, dice Anna a Chip. “El
enfoque clave está en la precisión, con una capacidad detallada de edición para cada campo de datos. Agregar programas (Add
programs) mostrará una página de entrada y permitirá crear registros de hardware o software. Después de completar todas las
entradas, el usuario debería verificar los datos dos veces y después hacer clic en el botón Agregar registro de software (Add
Software Record). Cualquier dato que ya se encuentre en el sistema deberá implementarse mediante el uso de listas desplega-
bles. También hay botones para deshacer cambios, mover información a otros registros, imprimir un registro, guardar los cam-
bios y salir de la página. Se puede agregar un registro sólo si no existe de antemano la clave primaria para ese registro”.
“Las pantallas de eliminación deben tener una entrada simple de clave primaria, como DESCRIPCION CURSO (COURSE
DESCRIPTION) en la pantalla ELIMINAR CURSO SOFTWARE (DELETE SOFTWARE COURSE)”, continúa Anna. “La
pantalla ELIMINAR CURSO SOFTWARE usa un botón Buscar (Find) (los binoculares) para ayudar a localizar el registro
deseado. Se lee el registro correspondiente y se muestra la información en pantalla. Los usuarios hacen clic en el botón Eliminar
(Delete) y se les pide que confirmen la eliminación. Si el usuario hace clic en la tecla Esc o en Cancelar (Cancel), se cancela la
acción de eliminar. ¿Qué te parece todo esto?”, pregunta a Chip.
“Hasta ahora todo bien”, le contesta. “¿Algo sobre pantallas en las que se puedan modificar datos?”.
“Sí. Se introduce una clave primaria para el registro y se lee el registro que coincida. Aparece la información del registro
y el operador puede sobrescribir los datos con sus modificaciones. Hay que validar todas las modificaciones con capacidad de
edición completa. Cuando todos los campos que se modificaron sean válidos, el usuario debe hacer clic en un botón para guar-
darlos. ¿Está lo bastante claro para el usuario?”, pregunta Anna.
“Creo que está muy bien”, responde Chip. “Pienso que hemos tenido un buen inicio con el diseño de nuestras interfaces
de usuario”.
EJERCICIOS
E-1. Use Microsoft Access para ver las opciones del menú para el sistema computacional.
E-2. Examine la CONSULTA HARDWARE (HARDWARE INQUIRY). Explique el tipo de consulta utilizando la notación
de valor, entidad y atributo (V, E, A).
E-3. Explique en un párrafo por qué una pantalla para introducir datos debe hacer énfasis en la precisión, mientras que una
pantalla de consulta hace énfasis en la rapidez con que se pueden mostrar los datos.
E-4. Modifique e imprima el diagrama de jerarquías que representa al menú Actualizar Hardware (Update Hardware). El
nombre del archivo en Microsoft Visio es Update Hardware. Agregue rectángulos para representar las siguientes opciones
del menú:
MODIFICAR COMPUTADORA (CHANGE COMPUTER)
ELIMINAR REGISTRO COMPUTADORA (DELETE COMPUTER RECORD)
ACTUALIZAR COMPUTADORA INSTALADA (UPDATE INSTALLED COMPUTER)
E-5. Use el diagrama Estructura del programa (Program Structure) de Microsoft Visio o el diagrama Descomposición fun-
cional (Functional Decomposition) en Visible Analyst para dibujar un diagrama de jerarquías que represente las opcio-
nes que se encuentran en el menú Actualizar Software (Update Software). Empiece con el rectángulo superior que
representa al menú Actualizar Software.
AGREGAR PAQUETE SOFTWARE (ADD SOFTWARE PACKAGE)
MODIFICAR REGISTRO SOFTWARE (CHANGE SOFTWARE RECORD)
ELIMINAR REGISTRO SOFTWARE (DELETE SOFTWARE RECORD)
ACTUALIZAR PAQUETE SOFTWARE (UPGRADE SOFTWARE PACKAGE)
E-6. Chip y Anna descubren que el menú que han diseñado es para los usuarios involucrados en la instalación y mantenimiento
de hardware y software de computadora. Este menú no sería adecuado para los miembros del personal y del cuerpo do-
cente en general, ya que no tienen la habilidad de actualizar los registros. Diseñe un menú, ya sea en papel o mediante el
uso de software con el que esté familiarizado, para proveer al usuario general la habilidad de realizar consultas y ver
informes.
E-7. Describa en un párrafo por qué los usuarios tendrían que cambiar a otra página (oprimiendo el botón Siguiente registro
[Next Record]) para mostrar el registro correcto para la consulta UBICACION SOFTWARE (SOFTWARE LOCA-
TION).
E-8. Diseñe la pantalla de consulta DETALLES SOFTWARE (SOFTWARE DETAILS). El campo de entrada es NUMERO
INVENTARIO SOFTWARE (SOFTWARE INVENTORY NUMBER) y deberá aparecer toda la información de soft-
ware, con la excepción de EXPERTO (EXPERT) y MAQUINAS INSTALADAS EN (MACHINES INSTALLED ON).
Consulte la entrada en el repositorio del flujo de datos DETALLES DE SOFTWARE de Visible Analyst o la página Web
del repositorio.
www.xlibros.com
CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 483
E-9. Para programar los horarios de los salones de clase que utilizarán los estudiantes, Cher Ware necesita conocer todos los
paquetes de software disponibles en una sala específica. Lo que ella desea es introducir la UBICACION CAMPUS
(CAMPUS UBICATION) y la SALA (ROOM) en una pantalla de consulta. Los campos serían TITULO (TITLE), VER-
SION, LICENCIA SITIO (SITE LICENSE) y NUMERO DE COPIAS (NUMBER OF COPIES).
Diseñe la consulta SOFTWARE POR SALA (SOFTWARE BY ROOM), que se describe como flujo de datos en la
página Web del repositorio o en el repositorio de Visible Analyst.
E-10. De vez en cuando, Hy Perteks recibe una solicitud de ayuda relacionada con cierto paquete de software específico. Los
miembros del personal y los estudiantes necesitan realizar opciones avanzadas o transferir datos entre distintos paquetes
y tienen dificultades para hacerlo. A Hy le gustaría introducir el TITULO (TITLE) y NUMERO VERSION (VERSION
NUMBER) del software. La pantalla resultante debería mostrar el NOMBRE EXPERTO SOFTWARE (SOFTWARE
EXPERT NAME) junto con la UBICACION CAMPUS (CAMPUS LOCATION) y el NUMERO SALA (ROOM NUM-
BER). Diseñe la pantalla para la consulta LOCALIZAR EXPERTO SOFTWARE (LOCATE SOFTWARE EXPERT).
Describa la lógica y los archivos necesarios para producir la consulta. Use la notación de valor, entidad y atributo (V, E, A)
para esta consulta. Los detalles de la consulta se incluyen en la entrada en el repositorio para el flujo de datos EXPERTO
SOFTWARE (SOFTWARE EXPERT) de Visible Analyst o la página Web del repositorio.
E-11. Hy recibe varias solicitudes de clases de capacitación. A él le gustaría planear la capacitación y colocar las clases próxi-
mas a impartir en intranet, para que el cuerpo docente tenga una cantidad adecuada de tiempo anticipado para programar
una clase. Diseñe la consulta CLASES CAPACITACION SOFTWARE (SOFTWARE TRAINING CLASSES). Encon-
trará los detalles en la página Web del repositorio o en la entrada en el repositorio de flujo de datos de Visible Analyst
llamada CLASES CAPACITACION SOFTWARE (SOFTWARE TRAINING CLASSES).
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
www.xlibros.com
PA RT E V
CAPÍTULO 15 Aseguramiento e
implementación de la
Diseño de procedimientos calidad
CODIFICACIÓN EFECTIVA
Una de las formas en que se pueden introducir datos con más precisión y eficiencia es mediante el
empleo informado de varios códigos. Convertir datos ambiguos o voluminosos en dígitos cortos
que se introduzcan con facilidad se denomina codificación (no debemos confundirlo con la escri-
tura de código, o codificación, de programas).
La codificación ayuda al analista de sistemas a alcanzar el objetivo de eficiencia, pues los datos
codificados requieren menos tiempo para que las personas los introduzcan y, por ende, se reduce el nú-
mero de elementos introducidos. La codificación también puede ayudar a ordenar los datos en forma
apropiada en un punto posterior del proceso de transformación de los datos; además pueden ahorrar
valioso espacio de memoria y almacenamiento. En resumen, la codificación es una manera de ser elo-
cuente y a la vez conciso en la captura. Además de proveer precisión y eficiencia, los códigos deben
tener un propósito para apoyar a los usuarios. Los tipos específicos de códigos nos permiten tratar los
datos de una manera específica. Los propósitos humanos para la codificación incluyen lo siguiente:
1. Mantener el registro de algo.
2. Clasificar información.
3. Ocultar información.
485
www.xlibros.com
486 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 15.1
Pedido # Producto Cliente
Uso de un código de secuencia
simple para indicar la secuencia en 5676 Silla mecedora con piel Arthur Hook, Jr.
que los pedidos entran a una 5677 Silla de comedor/tapizada Millie Monice
tienda de muebles a la medida.
5678 Love Seat/tapizado J. & D. Pare
5679 Silla mecedora para niño/calcomanías Lucinda Morely
4. Revelar información.
5. Solicitar la acción apropiada.
Hablaremos sobre cada uno de estos propósitos de codificación en las siguientes secciones, junto con algunos
ejemplos de códigos.
FIGURA 15.2
Código Explicación del código
Identificación de la cuenta del
suscriptor de una revista mediante 68506KND7533TVG 99999XXX9999XXX
un código de derivación alfabética.
Abreviatura de la revista
Cuatro dígitos de la dirección
Primeras tres consonantes del apellido
Primeros cinco dígitos del código postal
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 487
Un segundo propósito es el de imprimir etiquetas de correo. Al diseñar este código, el código postal es la
primera parte del número de cuenta. Por lo general, los registros de suscriptores se actualizan sólo una vez al año,
pero el principal propósito de los registros es imprimir etiquetas de correo una vez al mes o una vez por semana. Tener
el código postal como la primera parte del campo de clave primaria significa que los registros no se tienen que
ordenar por código postal para enviarlos en masa, ya que los registros de un archivo se almacenan en secuencia
por clave primaria. Cabe mencionar que la fecha de expiración no es parte del número de cuenta, ya que ese nú-
mero puede cambiar con más frecuencia que los otros datos.
Una desventaja de un código de derivación alfabética ocurre cuando la porción alfabética es pequeña (por
ejemplo, el nombre Po) o cuando el nombre contiene menos consonantes de las que el código requiere. El nom-
bre Roe tiene sólo una consonante y se tendría que derivar como RXX, o por medio de algún otro esquema. Otra
desventaja es que algunos de los datos pueden cambiar. Al modificar la dirección o el nombre de un suscriptor
cambiaría la clave primaria para el archivo.
Clasificar la información
La clasificación ofrece la posibilidad de diferenciar entre las clases de elementos. Las clasificaciones son nece-
sarias para muchos fines, como reflejar las partes del plan de seguro médico con las que cuenta un empleado, o
mostrar cuál estudiante completó los requerimientos básicos de su programa de estudios.
Para que sean útiles, las clases deben ser mutuamente excluyentes. Por ejemplo, si un estudiante está en la
clase F (que significa estudiante de primer año) y completó de 0 a 36 horas crédito, no hay que clasificarlo tam-
bién como estudiante de segundo año (S). Las clases superpuestas serían F ⫽ 0 ⫺ 36 horas crédito, S ⫽ 32 ⫺ 64
horas crédito, etcétera. Los datos no son claros y no se pueden interpretar con tanta facilidad cuando las clases de
codificación no son mutuamente excluyentes.
CÓDIGOS DE CLASIFICACIÓN Los códigos de clasificación se utilizan para diferenciar un grupo de datos con
características especiales de otro. Los códigos de clasificación pueden consistir de una sola letra o número. Son
una manera abreviada de describir una persona, un lugar, una cosa o un evento.
Los códigos de clasificación se listan en los manuales o se publican de manera que los usuarios puedan locali-
zarlos con facilidad. Muchas veces los usuarios se familiarizan tanto con los códigos de uso frecuente que los me-
morizan. Un usuario clasifica un elemento y después introduce su código directamente en un sistema en línea.
Un ejemplo de codificación de clasificación es la forma en que sería conveniente agrupar los rubros dedu-
cibles de impuestos para poder llenar una declaración de impuestos. La figura 15.3 muestra cómo se desarrollan
códigos para elementos tales como Pagos de intereses, Gastos médicos, contribuciones, etcétera. El sistema de codi-
ficación es simple: se toma la primera letra de cada una de las categorías; las contribuciones son C, los pagos de
intereses son P y los suministros son S.
Todo marcha bien hasta que llegamos a otras categorías (como elementos de computadora, pagos de seguros
y suscripciones) que empiezan con las mismas letras utilizadas previamente. La figura 15.4 demuestra lo que
ocurre en este caso. Extendimos la codificación de manera que pudiéramos usar P para “ComPutadora”, A para
“PAgos de seguros” y B para “SuBscripciones”. Sin duda esta situación está lejos de ser perfecta. Una manera
de evitar este tipo de confusión es permitir códigos mayores de una letra, lo cual veremos más adelante en este
capítulo bajo el subtítulo de códigos mnemónicos. Los menús desplegables en un sistema de GUI utilizan con
frecuencia códigos de clasificación como método abreviado para seleccionar las características del menú, como
Alt-A para el menú Archivo.
CÓDIGOS DE SECUENCIA EN BLOQUE Anteriormente vimos los códigos de secuencia; el código de secuencia en
bloque es una extensión. La figura 15.5 muestra cómo el usuario de una empresa asigna números al software
de computadora. Las principales categorías de software son navegadores, paquetes de bases de datos y diseño
Web. A estas categorías se les asignaron números secuenciales en los siguientes “bloques” o rangos: navegador,
100-199, base de datos, 200-299, y así en lo sucesivo. La ventaja del código de secuencia en bloque es que los
datos se agrupan de acuerdo con las características comunes, al tiempo que aprovechan la simpleza de asignar el
siguiente número disponible (dentro del bloque, desde luego) al siguiente elemento que necesite identificación.
www.xlibros.com
488 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 15.4
Código Elemento deducible de impuestos
Los problemas al usar un código
de clasificación de una letra P Pagos de intereses
ocurren cuando las categorías G Gastos médicos
comparten la misma letra. I Impuestos
C Contribuciones
D Donaciones
gos
S Suministros Estos códi
pl ic ad os …
du
S Subscripciones
C Computadora
P Pagos de seguros
G Gastos varios
B SuBscripciones
igen al
P ComPutadora … se corr
“f or za r” lo s códigos
A PAgos de seguros n a usar.
que se va
Ocultar información
Podemos usar códigos para ocultar o disfrazar la información que otras personas no deban conocer. Hay muchas
razones por las que una empresa podría querer hacer esto. Por ejemplo, tal vez una corporación no desee que los
empleados capturistas de datos accedan a la información en un archivo de personal. Tal vez una tienda quiera que
sus vendedores conozcan el precio de mayoreo para mostrarles cuál es el precio más bajo que puedan negociar,
pero podría codificarlo en las etiquetas de los precios para evitar que los clientes lo descubran. Tal vez un restaurante
quiera capturar la información sobre el servicio sin dejar que el cliente sepa el nombre del mesero. El oculta-
miento de la información y la seguridad se han convertido en temas muy importantes durante los últimos años.
Las corporaciones han empezado a permitir a los distribuidores y consumidores el acceso directo a sus bases de
datos, y el hecho de manejar las transacciones comerciales a través de Internet ha provocado que sea necesario
desarrollar estrictos esquemas de cifrado. En la siguiente subsección veremos un ejemplo de cómo ocultar infor-
mación por medio de códigos.
CÓDIGOS DE CIFRADO Tal vez el método de codificación más simple sea la sustitución directa de una letra por
otra, un número por otro o una letra por un número. Como ejemplo de sustitución de letras podríamos mencionar
un tipo popular de acertijo conocido como criptograma. La figura 15.6 muestra un ejemplo de un código de
cifrado tomado de una tienda de departamentos de Buffalo, Nueva York, la cual codificó todos los precios
rebajados con las palabras BLEACH MIND. Nadie recordó realmente por qué se eligieron estas palabras, pero
todos los empleados las conocían de corazón y eso contribuyó al éxito del código de cifrado. Podemos observar
en esa figura que un artículo con un precio de venta de $25.00 podría tener un precio rebajado de BIMC, o de
$18.75 cuando se decodifica letra por letra.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 489
FIGURA 15.6
Código Significado Ejemplo de la etiqueta de precio Explicación
Codificar los precios rebajados
B 1 GOLDEN’S Nombre de la tienda mediante un código de cifrado es
L 2 202-395-40 Código de estilo una forma de ocultar la
E 3 BIMC Precio rebajado codificado información de los precios a los
A 4 clientes.
C 5
H 6 Talla 12 Tamaño de la ropa
M 7
I 8 $25.00 Precio del cliente
N 9
D 0
Precio regular del vestido = $25.00
BIMC codificado de la etiqueta de rebaja = $18.75
Revelar información
Algunas veces es conveniente revelar información a usuarios específicos por medio de un código. En una tienda
de ropa, la información sobre el departamento, producto, color y tamaño se imprime junto con el precio en el re-
cibo para cada artículo. Esta información ayuda a los vendedores y al personal de existencias a localizar el lugar
para la mercancía.
Otra razón de revelar información por medio de códigos es para que la entrada de datos sea más significativa
para los humanos. Un número de pieza, nombre o descripción familiares producen una mayor entrada de datos.
Los ejemplos de los códigos en la siguiente subsección explican cómo se pueden llevar a cabo estos conceptos.
Producto
(Vestido estilo 395)
Color
(Rojo)
Talla
(Talla 10)
Departamento
(Abrigos de invierno)
Producto
(Abrigo estilo 219)
Color
(Beige)
Talla
(Talla 12)
www.xlibros.com
490 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Unicode
Los códigos nos permiten revelar caracteres que por lo general no podemos introducir o ver. Los teclados tradi-
cionales proporcionan conjuntos de caracteres conocidos para las personas que utilizan caracteres alfabéticos oc-
cidentales (conocidos como caracteres del latín), pero muchos lenguajes como el griego, japonés, chino o hebreo
no utilizan el alfabeto occidental. Estos lenguajes pueden usar letras griegas, glifos o símbolos que representan
sílabas o palabras completas. La Organización Internacional para la Estandarización (ISO) definió el conjunto de
caracteres Unicode, el cual incluye todos los símbolos de lenguajes estándar y tiene espacio para 65,535 carac-
teres. Podemos mostrar páginas Web escritas en otros alfabetos si descargamos un editor de métodos de entrada
de Microsoft.
Los símbolos de glifos se representan mediante una notación “&#xnnnn;”, en la que nnnn representa a una
letra o símbolo específico y x significa que se utiliza la notación hexadecimal, o numeración base 16, para re-
presentar los caracteres Unicode. Por ejemplo, B3 representa el símbolo ko en japonés katakana. El código
que se utiliza para la palabra japonesa hola, konichiwa, es こにちわ. En japonés,
la palabra se ve así:
El conjunto completo de caracteres Unicode se agrupa por lenguaje; puede encontrarlo en www.unicode.org.
FIGURA 15.8
Código Hospitales de la ciudad
Los códigos mnemónicos
funcionan como ayudas de BGH Buffalo General Hospital
memoria mediante el uso de una ROS Roswell Park Memorial Institute
combinación significativa de letras KEN Kenmore Mercy
y números. DEA Deaconess Hospital
SIS Sisters of Charity
STF Saint Francis Hospital
STJ Saint Joseph’s Hospital
OLV Our Lady of Victory Hospital
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 491
FIGURA 15.9
Código Función
Los códigos de función capturan
1 Entregado en forma compacta las funciones
2 Vendido que debe realizar la computadora.
3 Echado a perder
4 Perdido o robado
5 Devuelto
6 Enviado por transferencia
7 Recibido por transferencia
8 Entrada en el diario (Sumar)
9 Entrada en el diario (Restar)
www.xlibros.com
492 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 1 5 . 1
MANTENER LOS CÓDIGOS ESTABLES Estabilidad significa que el código de identificación para un cliente no debe
cambiar cada vez que se reciban nuevos datos. Anteriormente presentamos un código de derivación alfabética
para la lista de suscriptores de una revista. La fecha de expiración no formaba parte del código de identificación
del suscriptor debido a que es probable que vaya a cambiar.
No cambie las abreviaturas de código en un sistema mnemónico. Una vez que haya elegido las abreviaturas
del código, no trate de modificarlas ya que será muy difícil que el personal de captura de datos se adapte.
ASEGURAR QUE LOS CÓDIGOS SEAN ÚNICOS Para que los códigos funcionen, deben ser únicos. Tome nota de
todos los códigos utilizados en el sistema para asegurar que no vaya a asignar el mismo número de código o
nombre a los mismos artículos. Los números de código y los nombres son una parte esencial de las entradas en
los diccionarios de datos, como vimos en el capítulo 8.
PERMITIR ORDENAR LOS CÓDIGOS Si va a manipular los datos en forma útil, los códigos deben poder ordenarse.
Por ejemplo, si desea realizar una búsqueda de texto en los meses del año en orden ascendente, los meses que
empiezan con “J” estarían fuera de orden (Julio y después Junio). Los diccionarios se ordenan de esta manera,
una letra a la vez y de izquierda a derecha. Por lo tanto, si ordenara en base a MMMDDAAAA, en donde MMM
representa el mes, DD el día y AAAA el año, el resultado sería incorrecto.
La figura 15.11 muestra lo que ocurriría si se realizara una búsqueda de texto en distintos formatos de fecha.
La tercera columna muestra un problema que formaba parte de la crisis del año 2000 (Y2K) que provocó cierto
grado de alarma e incluso apareció en la portada de la revista Time.
Una de las lecciones aprendidas es que debemos asegurarnos de que los usuarios puedan hacer lo que que-
ríamos que hicieran con los códigos que creamos. Es mucho más fácil ordenar códigos numéricos que los alfanu-
méricos; por lo tanto, considere la opción de convertir los códigos a numéricos siempre que sea práctico.
EVITAR CÓDIGOS CONFUSOS Trate de evitar el uso de caracteres de codificación que se vean o suenen igual.
Los caracteres O (la letra o) y 0 (el número cero) se confunden con facilidad, al igual que la letra I y el número
1, y también la letra Z y el número 2. Por ello, los códigos tales como B1C y 280Z no son satisfactorios.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 493
FIGURA 15.11
Orden incorrecto Orden incorrecto Orden incorrecto Orden correcto
Planifique para poder hacer algo
al usar al usar (problema del año al usar
útil con los datos que se hayan
MMM-DD-AAAA MM-DD-AAAA 2000) AA-MM-DD AAAA-MM-DD introducido. En este ejemplo, la
persona que creó los códigos no
Dic-25-1998 06-04-1998 00-06-11 1997-06-12 tomó en cuenta que se tendrían
Dic-31-1997 06-11-2000 97-06-12 1997-12-31 que ordenar.
Jul-04-1999 06-12-1997 97-12-31 1998-06-04
Jun-04-1998 07-04-1999 98-06-04 1998-10-24
Jun-11-2000 10-24-1998 98-10-24 1998-12-25
Jun-12-1997 12-25-1998 98-12-25 1999-07-04
Oct-24-1998 12-31-1997 99-07-04 2000-06-11
FIGURA 15.12
Formato de código para el Código Postal Canadiense
X9X 9X9 Combinar caracteres similares en
los códigos puede provocar
Código manuscrito Código real Ciudad, Provincia Problema errores.
www.xlibros.com
494 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 1 5 . 2
Qué capturar
La decisión sobre lo que se debe capturar es más importante que la interacción del usuario con el sistema. En
definitiva es imprescindible para hacer que la interfaz final valga la pena, dado que aún es válido el adagio
“entra basura, sale basura”.
Los analistas de sistemas y los usuarios son los que se encargan de las decisiones sobre los datos que se
deben capturar para introducirlos al sistema. Gran parte de lo que se captura es específico para la empresa en
particular. Capturar datos, introducirlos, almacenarlos y recuperarlos son todos procesos costosos. Con todos es-
tos factores en mente, determinar qué es lo que se debe capturar se convierte en una decisión importante.
Hay dos tipos de datos a introducir: los datos que cambian o varían con cada transacción y los datos que
diferencian en forma concisa el elemento específico que se está procesando de los demás elementos.
Un ejemplo de datos que se pueden modificar es la cantidad de provisiones que se compran cada vez que
una empresa de publicidad coloca un pedido con el mayorista de artículos de oficina. Como las cantidades
cambian dependiendo del número de empleados en la empresa de publicidad y de cuántas cuentas estén mane-
jando, hay que introducir datos sobre la cantidad cada vez que se coloca un pedido.
Un ejemplo de datos de diferenciación es incluir el número de Seguro Social y las primeras tres letras del
nombre de un/una paciente en su registro. De esta manera, el/la paciente se diferencia en forma única de los
demás pacientes en el mismo sistema.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 495
FIGURA 15.13
Uso de una tabla de códigos en
una lista desplegable. Esta lista se
utiliza para seleccionar un código
para agregar o modificar un
elemento en un registro.
www.xlibros.com
496 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
la lista desplegable muestra tanto el código como su significado. Este método ayuda a asegurar la precisión, ya
que el usuario no tiene que adivinar el significado del código y no hay probabilidad de que escriba uno inválido.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 497
Reconocimiento de caracteres de tinta magnética Los caracteres de tinta magnética se encuentran en la parte
inferior de los cheques bancarios y algunas facturas de tarjetas de crédito. Este método es similar al OCR
en cuanto a que se leen caracteres especiales, pero su uso es limitado. La entrada de datos por medio del
reconocimiento de caracteres de tinta magnética (MICR) se realiza a través de una máquina que lee e interpreta
una sola línea de material codificado con tinta formada de partículas magnéticas.
Algunas ventajas del uso de MICR son: 1) es un método confiable y de alta velocidad que no es susceptible
a confundir las marcas fuera de lugar, ya que no están codificadas en forma magnética; 2) si se requiere en todos
los cheques para retirar fondos, sirve como una medida de seguridad contra los cheques falsos, y 3) el personal
de entrada de datos puede ver los números que componen el código, si es necesario verificarlo.
Formularios de detección de marcas Estos formularios permiten introducir datos por medio de un escáner que
detecta en dónde se hicieron las marcas en formularios especiales. Un uso común es para calificar las hojas de
respuestas de los cuestionarios a las encuestas, como se muestra en la figura 15.14. El personal requiere de una
capacitación muy básica; además se puede procesar un alto volumen de formularios con rapidez.
FIGURA 15.14
Un formulario de detección de
INDICACIONES PA marcas que se puede leer mediante
RA MARCAR un escáner agiliza el proceso de
Haga marcas gru
esas de color negro entrada de datos.
Borre limpiamente que llenen el círcu
cualquier respues lo por completo.
Ejemplos de marca ta que desee camb
s CORRECTAS iar —no raye en nin
gún otro lado.
Ejemplos de marca
s INCORRECTAS
1. ¿Qué niveles de
personas atiende
gerentes usted principalmen
te en su trabajo?
supervisores; capa
taces
otros empleados
asalariados
por horas
voluntarios
2. Tamaño total de
la organización qu
menos de 1,000 e usted atiende
1,000–5,000 15 ,00 0–25,000
5,000–15,000 más de 25,000
5. La parte más co
nsiderable
4. Una parte impo
rtante
3. Una parte subs
tancial
2. Una parte más
pequeña
1. Una parte meno
r
0. No aplica
3. ¿Qué capacitac
ión y técnicas de
utiliza? (Por favor desarrollo
marque cada técnic
conferencia con o a)
sin medios
películas 0 1 2 3 4 5
TV de circuito cerra 0 1
do con videocinta 2 3 4 5
discusiones (caso 0 1
s, cuestiones, etc 2 3 4
desempeñar roles .) 0
5
1 2 3 4 5
modelado del comp 0 1 2
ortamiento 3 4 5
simulación; juego 0 1
s avanzados 2 3 4 5
capacitación en el 0 1
trabajo 2 3 4 5
rotación de emple 0 1
os 2 3 4 5
prácticas profesion 0 1
ales; ayudantías 2 3 4 5
técnicas de desarro 0 1
llo organizacional 2 3 4 5
otras 0 1 2 3 4 5
0 1 2 3 4 5
www.xlibros.com
498 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Una desventaja de los formularios de detección de marcas es que, aunque los lectores pueden determinar si
se hizo una marca, no pueden interpretarla de la manera en que lo hacen los lectores ópticos de caracteres. Esto
implica que se pueden introducir marcas fuera de lugar en los formularios como datos incorrectos. Además, las
opciones se limitan a las respuestas proporcionadas en el formulario de detección de marcas, los formularios pre-
sentan dificultades al capturar datos alfanuméricos debido al espacio requerido para un conjunto completo de le-
tras y números, y es fácil que los usuarios que llenan formularios de detección de marcas se confundan y pongan
una marca en una posición incorrecta.
Códigos de barras Por lo general, los códigos de barras aparecen en las etiquetas de productos, pero también
aparecen en brazaletes de identificación de pacientes en los hospitales y casi en cualquier contexto en el que una
persona u objeto necesite reportarse como entrada o salida en cualquier tipo de sistema de inventario. Podemos
considerar a los códigos de barras como metacódigos, o códigos que codifican otros códigos, debido a que
aparecen como una serie de bandas estrechas y anchas en una etiqueta, las cuales codifican números o letras. A su
vez, estos símbolos tienen acceso a los datos de los productos almacenados en la memoria de la computadora.
Se proyecta un rayo de luz de un escáner o lápiz óptico a través de las bandas en la etiqueta para confirmar o
registrar datos sobre el producto que se está escaneando.
Una etiqueta de código de barras como la que se muestra en la figura 15.15 incluye los siguientes elementos
de codificación para un producto específico de abarrotes: el número de identificación del fabricante, el número de
identificación del producto, un código para verificar la precisión del escaneo y códigos para marcar el principio
y fin del escaneo.
Los códigos de barras ofrecen un grado de precisión extraordinariamente elevado para la entrada de datos.
Ahorra costos de mano de obra a los vendedores, ya que no hay que marcar el precio de cada artículo por sepa-
rado. Además, la codificación de barras permite capturar de manera automática datos que se pueden utilizar para
reordenar, rastrear el inventario con mayor precisión y pronosticar las necesidades a futuro. Los precios de venta
u otros cambios en el significado de los códigos de barras se introducen en el procesador central, con lo cual nos
ahorramos el problema de rebajar muchos artículos.
Un nuevo uso de los códigos de barras es el de rastrear las compras de un individuo con su tarjeta de crédito,
con el fin de crear un perfil de cliente que pueda a su vez utilizarse para refinar las estrategias de marketing para
ese individuo o tipo de consumidor. Se desarrollan nuevos dispositivos de entrada en forma constante.
RFID La identificación por radiofrecuencia, conocida comúnmente como RFID, permite recolectar datos en
forma automática mediante etiquetas RFID o transpondedores que contienen un chip y una antena. Una etiqueta
RFID puede o no tener su propia fuente de energía. Si no cuenta con su propia fuente, la antena provee suficiente
potencia de una señal entrante para energizar el chip y transmitir una respuesta. Las etiquetas RFID se pueden
adjuntar a productos, paquetes, animales o incluso humanos, de manera que se pueda identificar el elemento o
persona mediante una frecuencia de radio.
A las etiquetas RFID también se les conoce como tarjetas de proximidad debido a su rango limitado; pue-
den ser pasivas o activas. Las etiquetas RFID pasivas no tienen fuente de energía interna; las activas sí. Las eti-
quetas pasivas son económicas (menos de 5 centavos de dólar por etiqueta) y por lo general tienen el tamaño de
una estampilla postal. Se utilizan en las grandes tiendas de menudeo, incluyendo Wal-Mart y Target. Wal-Mart
ha estado trabajando mucho con la tecnología RFID para mejorar sus procesos de administración de inventario y
cadena de suministro.
Las etiquetas activas son mucho más confiables, ya que tienen su propia fuente de energía. El Departamento
de Defensa de los EE.UU. ha utilizado estas etiquetas para minimizar los costos relacionados con la logística e
incrementar la visibilidad de la cadena de suministro. Las etiquetas activas cuestan sólo unos cuantos dólares
cada una.
FIGURA 15.15
El código de barras, como se Principio (101)
muestra en esta etiqueta para un Código que significa “producto de abarrotes”
producto de abarrotes, ofrece
mucha precisión en la entrada de Número de identificación del fabricante
(primeros cinco dígitos)
datos.
Barras de separación centrales (01010)
Utilizada con el permiso de Uniform
Code Council, Dayton, Ohio.
Número de identificación del producto
(últimos cinco dígitos)
Código para verificar la precisión del escaneo
(dígito de verificación)
Fin (101)
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 499
O P O R T U N I D A D D E C O N S U LT O R Í A 1 5 . 3
Para capturar los datos en una etiqueta RFID se requiere un lector. Este lector activa la etiqueta para que se
pueda leer. El lector decodifica los datos y el código único de producto en el chip dentro de la etiqueta; después
lo pasa a una computadora anfitriona que procesa los datos.
Un ejemplo es el paso de peaje electrónico que se utiliza en los vehículos que viajan por las carreteras de
cuota. Se puede colocar un transpondedor RFID en el parabrisas para leerlo cada vez que el vehículo pasa por
una caseta de cuota. El lector RFID de la caseta de cuota también puede actuar como escritor, por lo que se
puede almacenar un saldo en el chip RFID.
El Metro de Moscú fue el primer sistema de transporte en usar tarjetas inteligentes RFID en 1998. Otras
aplicaciones incluyen el rastreo de ganado para identificar la manada de origen, lo cual permite rastrear mejor la
enfermedad de las vacas locas, así como el rastreo RFID en librerías, servicios de equipaje de aerolíneas, farma-
cias e incluso pacientes o internos.
Las etiquetas RFID son de uso común en la mayoría de las aplicaciones relacionadas con envíos. La tecnolo-
gía pronto se utilizará en las transacciones de efectivo electrónico en general. Incluso pueden llegar a reemplazar
los códigos RPC, ya que sus ventajas incluyen la seguridad (al reducir el número de artículos robados) y no re-
querir escaneo (simplemente se pasan por la zona del lector).
Pero la tecnología RFID no escapa de la controversia. La privacidad es una cuestión importante. Un indivi-
duo que paga un artículo etiquetado con tarjeta de crédito o con una tarjeta de comprador corre el riesgo de ser
identificado.
El analista de sistemas necesita pensar en los clientes involucrados y sus derechos al considerar si esta tec-
nología se adapta a la aplicación que está diseñando.
www.xlibros.com
500 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 15.16
Este tipo de
Es importante validar la entrada validación Puede evitar estos problemas
para asegurar que se eliminen lo
más pronto posible la mayoría de Validar transacciones Enviar los datos incorrectos
los problemas potenciales con los de entrada Datos enviados por una persona no autorizada
datos. Pedir al sistema que realice una función
inaceptable
mucho tiempo en hacerse ver. El analista de sistemas debe suponer que ocurrirán errores en los datos y debe
trabajar con los usuarios para diseñar pruebas de validación de la entrada, de manera que pueda evitar que se
procesen y almacenen datos erróneos, ya que los errores iniciales que no se descubren durante largos periodos
de tiempo son costosos y se requiere mucho tiempo para corregirlos.
No es posible imaginar todo lo que puede salir mal con la entrada, pero debemos cubrir los tipos de errores
que provocan el mayor porcentaje de los problemas. En la figura 15.16 se proporciona un resumen de los proble-
mas potenciales que debemos considerar al validar la entrada.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 501
Además, el registro debe incluir los datos clave que distinguen a un registro de todos los demás, junto con
el código de función que indica a la computadora lo que debe hacer con los datos. El analista de sistemas ne-
cesita interactuar con los usuarios para determinar qué elementos de datos son esenciales y averiguar si alguna
vez ocurrieron casos excepcionales que permitieran considerar los datos válidos, incluso cuando faltaran algunos
elementos de datos. Por ejemplo, una segunda línea de dirección que contenga un número de apartamento o la
inicial del segundo nombre de una persona tal vez no sea una entrada requerida.
PRUEBA DE LONGITUD DE CAMPO CORRECTA En el segundo tipo de prueba de validez se comprueba la entrada
para ver si tiene la longitud correcta para el campo. Por ejemplo, si la estación climatológica de Omaha,
Nebraska se reporta con la computadora del servicio climatológico nacional y por error provee un código de
ciudad de dos letras (OM) en vez del código nacional de ciudad de tres letras (OMA), los datos de entrada se
podrían considerar inválidos y por ende no se procesarían.
PRUEBA DE CLASE O COMPOSICIÓN La prueba de la validez de la clase o composición verifica que todos los
campos de datos que deben estar compuestos exclusivamente de números no contengan letras y viceversa. Al
usar una prueba de composición, el programa no debe aceptar un número de cuenta de American Express que
incluya tanto letras como números.
PRUEBA DE RANGO O SENSATEZ Las pruebas de validez de rango o sensatez son en realidad medidas de entrada
de sentido común, las cuales responden a la pregunta de si los datos se encuentran dentro de un rango aceptable
o si son razonables dentro de ciertos parámetros predeterminados. Por ejemplo, si un usuario estaba tratando
de verificar una fecha de envío propuesta, la prueba de rango no permitiría una fecha de envío en el día 32 de
octubre, ni aceptaría un envío en el mes 13, siendo los rangos respectivos de 1 a 31 días y de 1 a 12 meses.
Una prueba de sensatez averigua si el elemento tiene sentido para la transacción. Por ejemplo, al agregar
un nuevo empleado a la nómina, no sería razonable introducir una edad de 120 años. Las pruebas de sensatez se
utilizan para los datos que son continuos; es decir, datos que tienen un rango uniforme de valores. Estas pruebas
pueden incluir un límite inferior, un límite superior o ambos.
PRUEBA DE VALORES INVÁLIDOS El proceso de comprobar que la entrada no tenga valores inválidos funciona
si sólo hay unos cuantos valores válidos. Esta prueba no es viable para las situaciones en las que los valores
no son restringidos ni predecibles. Este tipo de prueba es útil para verificar las respuestas donde los datos se
dividen en un número limitado de clases. Por ejemplo, una empresa de correduría divide las cuentas en tres
clases solamente: clase 1 ⫽ cuenta activa, clase 2 ⫽ cuenta inactiva y clase 3 ⫽ cuenta cerrada. Si los datos se
asignan a cualquier otra clase por medio de un error, los valores son inválidos. Por lo general las verificaciones
de valores se realizan para los datos discretos, que sólo tienen ciertos valores. Si hay muchos valores, por lo
general se almacenan en un archivo de tabla de códigos. Al tener los valores en un archivo es más fácil agregar
o modificar valores.
VERIFICACIONES DE REFERENCIAS CRUZADAS Estas verificaciones se utilizan cuando un elemento tiene una
relación con otro. Para realizar una verificación de referencia cruzada, cada campo debe estar correcto por sí
solo. Por ejemplo, el precio al que se vende un artículo debe ser mayor que el costo que se paga por él. Hay que
introducir el precio, el cual debe ser numérico y mayor de cero. Se utiliza el mismo criterio para validar el costo.
Cuando tanto el precio como el costo son válidos, se pueden comparar.
Una verificación geográfica es otro tipo de verificación de referencia cruzada. En los Estados Unidos se
puede utilizar la abreviatura de estado para asegurar que un código de área telefónica sea válido para cierto es-
tado y que los primeros dos dígitos del código postal sean válidos para el estado.
PRUEBA PARA COMPARAR CON DATOS ALMACENADOS La siguiente prueba de validez de los datos de entrada
que veremos es en la que éstos se comparan con los datos que ya están almacenados en la computadora. Por
ejemplo, un número de pieza recién introducido se puede comparar con el inventario de piezas completo para
asegurar que el número exista y se esté introduciendo en forma correcta.
CONFIGURAR CÓDIGOS DE AUTOVALIDACIÓN (DÍGITOS DE VERIFICACIÓN) Otro método para asegurar la
precisión de los datos, en especial los números de identificación, es utilizar un dígito de verificación en el mismo
código. Este procedimiento implica empezar con un código numérico original, realizar algunas operaciones
matemáticas para llegar a un dígito de verificación derivado y después agregar ese dígito de verificación al
código original. El proceso matemático implica multiplicar cada uno de los dígitos del código original por
ciertos pesos predeterminados, sumar estos resultados y después dividir esta suma por un número módulo. El
número módulo es necesario debido a que la suma por lo general es un número grande y necesitamos reducir
el resultado a un solo dígito. Por último, el residuo se resta del número módulo para obtener el dígito de
verificación.
www.xlibros.com
502 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
La figura 15.17 muestra cómo se convierte el número de pieza de cinco dígitos de una manguera para radia-
dor (54823) en un número de seis dígitos que contiene un dígito de verificación. En este ejemplo, los pesos elegidos
fueron el sistema “1-3-1”; en otras palabras, los pesos alternan entre 1 y 3. Después de multiplicar los dígitos 5,
4, 8, 2 y 3 por 1, 3, 1, 3 y 1, se convirtieron en 5, 12, 8, 6 y 3. La suma de estos nuevos dígitos es 34. Después el
34 se divide entre el número módulo elegido, 10, para obtener el resultado de 3 y un residuo de 4. El residuo (4)
se resta del número módulo (10) para obtener un dígito de verificación de 6. Ahora el dígito 6 se coloca al final
del número original para producir el código del producto oficial para la manguera de radiador (548236).
Uso de los dígitos de verificación El sistema de dígitos de verificación funciona de la siguiente manera. Suponga
que tenemos el número de pieza 53411. Hay que teclear este número en el sistema, y mientras hacemos eso
pueden ocurrir distintos tipos de errores. Uno de los posibles errores es teclear mal un dígito; por ejemplo, el
empleado teclea 54411 en vez de 53411. Sólo el dígito en la posición de los miles es incorrecto, pero este error
puede provocar que se envíe la pieza incorrecta.
Un segundo tipo de error es el de los dígitos transpuestos. Es común que el número deseado 53411se teclee
como el número 54311, sólo debido a que dos teclas se oprimieron en orden inverso. Los errores de transposi-
ción también son difíciles de detectar para los humanos.
Podemos evitar estos errores mediante el uso de un dígito de verificación, ya que cada uno de estos nú-
meros (el correcto y el erróneo) tendrían un número de dígito de verificación distinto, como se muestra en la
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 503
Transposición 5 4 3 1 1 6 543116
figura 15.18. Si el número de pieza 53411 se modificara a 534118 (incluyendo el dígito de verificación 8) y
ocurriera cualquiera de los dos errores antes descritos, se atraparía el error. Si el segundo dígito se tecleara
en forma equivocada como 4, la computadora no aceptaría 544118 como un número válido, ya que el dígito
de verificación para 54411 sería 5 y no 8. De manera similar, si se transpusieran el segundo y tercer dígitos,
como en 543118, la computadora también rechazaría el número debido a que el dígito de verificación para
54311 sería 6 y no 8.
El analista de sistemas selecciona los pesos y el número módulo, pero una vez elegidos no deben cambiar.
En la figura 15.19 encontrará algunos ejemplos de métodos de ponderación y números módulo.
VERIFICACIÓN DE TARJETAS DE CRÉDITO Al introducir tarjetas de crédito en un sitio Web o programa de
computadora, la primera verificación es la longitud del número. Las compañías de tarjetas de crédito diseñaron
sus tarjetas para incluir un número distinto de dígitos. Por ejemplo, las tarjetas Visa son de 16 dígitos mientras
que los de las tarjetas American Express están compuestas por 15 dígitos.
Otra prueba es relacionar la compañía de la tarjeta de crédito y el banco para verificar que sea realmente una
tarjeta emitida por esa compañía. Por lo general los primeros cuatro dígitos indican el tipo de tarjeta. Los dígitos
de en medio comúnmente representan al banco y al cliente. El último dígito es de verificación.
Además de estos métodos de verificación, en el procesamiento de tarjetas de crédito se utiliza una fórmula
de dígitos de verificación conocida como fórmula Luhn, la cual se creó en la década de 1960. Suponga que tene-
FIGURA 15.19
Método de dígito
de verificación Cálculos para agregar el dígito de verificación al número original 29645 Ejemplos de métodos de
ponderación y números módulo.
Módulo 10 2 9 6 4 5
“2-1-2” ×2 ×1 ×2 ×1 ×2 10
4 + 9 + 12 + 4 + 10 = 39/10 = 3 residuo (9)
Dígito de verificación igual a 1
El código con dígito de
verificación es 296451.
Módulo 10 2 9 6 4 5
“3-1-3” ×3 ×1 ×3 ×1 ×3 10
6 + 9 + 18 + 4 + 15 = 52/10 = 5 residuo (2)
Dígito de verificación igual a 8
El código con dígito de
verificación es 296458.
Módulo 11 2 9 6 4 5
“Aritmético” ×6 ×5 ×4 ×3 ×2 11
12 + 45 + 24 + 12 + 10 = 103/11 = 9 residuo (4)
Dígito de verificación igual a 7
El código con dígito de
verificación es 296457.
Módulo 10 2 9 6 4 5
“Geométrico” × 32 × 16 ×8 ×4 ×2 11
64 + 144 + 48 + 16 + 10 = 282/11 = 25 residuo (7)
Dígito de verificación igual a 4
El código con dígito de
verificación es 296454.
www.xlibros.com
504 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 1 5 . 4
¿Validan el estacionamiento?
“cio.Q ué vamos a hacer, Mercedes?”, pregunta Edsel con cansan-
Mercedes y Edsel están revisando la impresión de facturación
un número y después una letra, ¿verdad? Bueno, este de Nueva York
empieza con tres letras. La computadora no puede manejarlo”, dice.
más reciente para su empresa, Denton and Denton Parking Garages. Edsel se integra a la conversación y empieza a pensar sobre la
Han estado comprando servicios de facturación por lotes de una empresa mientras analiza el documento impreso. “Sí, y mira aquí.
empresa local pequeña de servicios de computadora desde que ad- Esta persona no tiene un número de cuenta anual, sólo mensual, por
quirieron tres estacionamientos cerrados en un área metropolitana lo que no salió ninguna factura”, dice. “Tenemos clientes mensuales
de tamaño medio. La empresa Denton and Denton Parking Garages también, y la computadora no lo sabe”.
renta lugares de estacionamiento por día, mes y año a las empresas “Y mira esto. Todavía hace cobros diarios por los tres días de
e individuos. noviembre que les dijimos que no había vacantes para los clientes
Mercedes responde: “No estoy segura de cuál será nuestro si- diarios. No es razonable”, afirma Mercedes.
guiente movimiento, pero la facturación está toda mal. Tal vez de- Edsel continúa avanzando página por página en el documento
beríamos tratar de hablar con el personal de TI”. impreso, pero Mercedes lo detiene y dice: “Ya no sigas viendo. Voy
“Dijeron que podrían averiguar cómo calcular estos costos a llamar al personal de TI para poder arreglar este desorden”.
viendo lo que habían hecho a mano los dueños anteriores, y dijeron ¿Cómo caracterizaría los problemas que se encontraron en el
que no querían ejecutar el sistema antiguo y el nuevo en paralelo”, sistema de facturación actual del estacionamiento? Use un párrafo
comenta Edsel al tiempo que sacude la cabeza. “Pero eso no está para formular una respuesta. ¿Cuáles son algunas de las pruebas de
bien. Por lo menos yo no puedo resolverlo. Tal vez usted pueda”. validez de datos que se podrían incluir en el software para producir
Mercedes acepta la noción de buscar la salida sospechosa y un sistema de facturación revisado para los estacionamientos? Haga
empieza a analizar el informe con detalle. “Bueno, al fin y al cabo no una lista. ¿Qué podrían haber hecho distinto el programador y los
saben que recibimos automóviles de todas partes. Cada vez que reci- analistas de la empresa de servicios de cómputo para que el cliente no
bimos un automóvil con placas que no son del estado, parece como si tuviera qué corregir la salida de mala calidad? Use tres párrafos para
la computadora dejara de imaginar. Mira, nuestras placas empiezan con realizar un análisis crítico de lo que se hizo y lo que se debió hacer.
mos un número 7-7-7-8-8-8, donde los primeros cinco números representan un número de cuenta bancaria y el
último dígito es de verificación. Vamos a aplicar la fórmula de Luhn para ver si es un número válido.
1. Duplique el penúltimo dígito y después los demás dígitos (es decir, omita un dígito, duplique el siguiente,
omita un dígito, duplique el siguiente, etc.). Por ejemplo, el número 7-7-7-8-8-8 se convierte en 14-7-14-8-
16-8.
2. Si al duplicar un dígito se produce un número mayor de 10, hay que reducir este número de dos dígitos a un
solo dígito, para lo cual se suman los dos números. En nuestro ejemplo, el 14 se convierte en 1 ⫹ 4 ⫽ 5 y el
16 se convierte en 1 ⫹ 6 ⫽ 7. Después de esto, nuestro número original 7-7-7-8-8-8 se ha transformado en
un nuevo número, 5-7-5-8-7-8.
3. Ahora sume todos los dígitos en el nuevo número. Así, 5 ⫹ 7 ⫹ 5 ⫹ 8 ⫹ 7 ⫹ 8 ⫽ 40.
4. Vea el total. Si termina en cero, el número es válido de acuerdo con la fórmula de Luhn. Como 40 termina
en cero, podemos decir que pasa la prueba de la fórmula de Luhn.
Podemos usar la fórmula de Luhn para identificar los errores al introducir una tarjeta de crédito incorrecta. Por
ejemplo, el número de tarjeta de crédito 1334-1334-1334-1334 es válido, debido a que los dígitos del número
transformado 2364-2364-2364-2364 se suman para un total de 60, un número que termina en cero. Si un usuario
introduce un dígito incorrecto, el total no será un múltiplo de cero.
Sin embargo, la fórmula de Luhn no atrapa todos los errores. Si un usuario comete errores al introducir más
de un dígito —por ejemplo, si introduce 1334-1334-1334-331— el total del número transformado (2364-2364-
2364-6324) sigue siendo 60. Este error de transposición (invertir el tercer y cuarto dígitos de derecha a izquierda)
no se atrapará.
Las compañías de tarjetas de crédito también usan la fecha de expiración y un código de verificación de tres
o cuatro dígitos, a menudo escrito en el lado posterior de la tarjeta para una mayor seguridad.
Las siete pruebas para verificar la validez de la entrada pueden ayudar de manera considerable a proteger
el sistema contra la entrada y el almacenamiento de datos erróneos. Siempre debemos suponer que es mucho
más probable que ocurran errores humanos en la entrada a que no ocurran. Es su responsabilidad como analista
comprender cuáles errores invalidarán los datos y cómo usar la computadora para protegerse contra esos errores
humanos, para así limitar su intrusión en los datos del sistema.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 505
El proceso de validación
Es importante validar cada campo hasta que sea válido o se detecte un error. El orden de prueba de los datos es
primero verificar si hay datos faltantes. Después, una prueba de sintaxis puede verificar la longitud de los datos
introducidos y que éstos tengan una clase y composición apropiadas. Sólo después de que la sintaxis sea correcta
se validará la semántica o significado de los datos. Esto incluye una prueba de rango, razonable o de valor, se-
guida de una prueba de dígito de verificación.
Las pantallas de GUI ayudan a reducir el número de errores de entrada humanos cuando incorporan boto-
nes de opción, casillas de verificación y listas desplegables. Cuando se utilizan botones de opción, uno se debe
establecer como el predeterminado y la única forma de deseleccionarlo es si el usuario hace clic en un botón de
opción distinto. En caso de las listas desplegables, la primera elección siempre debe contener un mensaje para
informar al usuario que debe cambiar la lista. Si la primera opción sigue aún seleccionada al momento de enviar
el formulario, un mensaje debería informarle que debe seleccionar una opción distinta.
Por lo general, la validación de un solo campo se realiza mediante una serie de instrucciones IF…ELSE,
pero también hay métodos de validación de patrones. Por lo general estos patrones se encuentran en el diseño
de la base de datos (como en Microsoft Access), pero también se pueden incluir en lenguajes de programación
como Perl, JavaScript y esquemas de XML. A los patrones se les conoce como expresiones regulares y contienen
símbolos que representan el tipo de datos que deben estar presentes en un campo. La figura 15.20 muestra los
caracteres que se utilizan en las expresiones regulares de JavaScript.
A continuación le mostramos un ejemplo de validación de patrón utilizado para evaluar una dirección de
correo electrónico:
[A-Za-z0-9]\w{2,}@[A-Za-z0-9]{3,}\.[A-Za-z]{3}/
El significado de este patrón es el siguiente: la primera letra debe ser cualquier letra mayúscula, minúscula o
número ([A-Za-z0-9]). Esto va seguido de dos o más caracteres que son cualquier letra, número o un guión bajo
(\w{2,}). Después debe haber un símbolo @, seguido de por lo menos tres letras o números, un punto y exacta-
mente tres caracteres después del punto.
Una verificación de referencias cruzadas supone que la validez de un campo puede depender del valor de
otro campo. Un ejemplo de una verificación de referencia cruzada es verificar una fecha válida. En un caso muy
especial, la validez del día del mes depende del año. Es decir, febrero 29 es sólo válido durante los años bisies-
tos. Una vez que se han verificado los campos individuales, podemos realizar verificaciones de referencias cruza-
das. Obviamente, si uno de los campos es incorrecto, la verificación de referencia cruzada no tiene sentido y no
se debe llevar a cabo.
FIGURA 15.20
Código de Significado utilizado en la validación
carácter con expresiones regulares Estos caracteres se utilizan en la
validación con expresiones
\d Cualquier dígito del 0-9 regulares (patrones).
\D Cualquier carácter que no sea dígito
\w Cualquier letra, número o guión bajo
\W Cualquier carácter distinto de una letra, número o guión
bajo
. Coincide con cualquier carácter
[caracteres] Coincide con los caracteres dentro de los corchetes
[car-car] Coincide con el rango de caracteres
[a–z][A–Z][0–9] Acepta cualquier letra o dígito
[^caracteres] Coincide con cualquier cosa que no sean los caracteres
[^car-car] Coincide con cualquier cosa fuera del rango de caracteres
[^a–z] Aceptará todo excepto letras minúsculas
{n} Coincide con exactamente n ocurrencias del carácter
anterior
{n,} Coincide con al menos n ocurrencias del carácter
\s Cualquier carácter de formato de espacio en blanco
(tabulador, nueva línea, retorno, etc.)
\S
Cualquier carácter que no sea de espacio en blanco
www.xlibros.com
506 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Para validar documentos XML debemos compararlos con una definición de tipo de documento (DTD) o
con un esquema (consulte el capítulo 8). La DTD verificará si el formato del documento es válido, pero un es-
quema es mucho más potente y verificará el tipo de datos (por ejemplo, entero corto o largo, número decimal o
fecha). Un esquema también verificará un rango de valores, el número de dígitos a la izquierda y a la derecha de
un punto decimal, y los valores de los códigos. Hay herramientas gratuitas para validar una DTD o un esquema.
IEXMLTLS es una extensión de Microsoft para Internet Explorer, la cual agrega nuevas opciones de menú
cuando el usuario hace clic con el botón derecho en un documento de XML.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 507
EXPERIENCIA DE HYPERCASE® 15
inmediato. Por ejemplo, suponga que un cliente envía sin querer un pedido de dos ejemplares de un DVD en vez
de una. Después de enviar el pedido, el cliente recibe un correo electrónico en el que se confirma el pedido. El
cliente detecta el error, se pone en contacto de inmediato con la empresa y corrige el pedido, con lo cual se evita
el tener que devolver la copia adicional del DVD. La precisión se mejora gracias a una mejor retroalimentación.
RESUMEN
Es imprescindible asegurar la calidad de la entrada de datos en un editor de método de entrada de Microsoft. Los códigos de
el sistema de información para poder asegurar una salida de función son abreviaturas útiles para informar a las computado-
calidad. Podemos mejorar la calidad de los datos introducidos ras o las personas sobre las funciones a realizar o las acciones
a través de una codificación efectiva, un proceso efectivo y efi- a tomar.
ciente de captura de datos y la validación de los datos. Para la entrada de datos efectiva también debemos consi-
Podemos agilizar la manera en que los humanos introdu- derar los dispositivos de entrada. Un formulario efectivo y bien
cen los datos mediante el uso efectivo de la codificación, que se diseñado que sirva como documento de origen es el primer
encarga de colocar los datos en secuencias cortas de dígitos y/o paso. Los datos se pueden introducir mediante muchos méto-
letras. Es posible usar códigos de secuencia simple y códigos dos, cada uno de los cuales tiene distintas velocidades y grados
de derivación alfabética para seguir el progreso de un elemento de confiabilidad. Los teclados se rediseñaron para mejorar la
dado. Los códigos de clasificación y los códigos de secuencia eficiencia y la ergonomía. El reconocimiento óptico de caracte-
en bloque son útiles para diferenciar unas clases de elemen- res (OCR), el reconocimiento de caracteres de tinta magnética
tos de otras. Los códigos de cifrado también son útiles debido (MICR) y los formularios de detección de marcas tienen cada
a que ocultan información sensible o restringida para los em- uno capacidades especiales para mejorar la eficiencia. Los có-
pleados. digos de barras también agilizan la entrada de datos, mejoran
Los códigos también son convenientes para revelar infor- la precisión de los datos y aumentan la confiabilidad. RFID
mación a los usuarios, ya que pueden permitir a los empleados permite la recolección automática de datos mediante el uso de
localizar artículos en existencia y hacer la entrada de datos más etiquetas RFID en productos, personas o animales. Pueden me-
significativa. Los códigos de subconjuntos de dígitos signifi- jorar los procesos de administración de inventario y la cadena
cativos usan subgrupos de dígitos para describir un producto. de suministro.
Los códigos mnemónicos también revelan información al ser- La precisión en la entrada de datos también se puede mejo-
vir como ayudas para la memoria humana, de manera que un rar mediante el uso de la validación de la entrada. Los analistas
operador pueda introducir los datos correctamente, o también deben trabajar con los usuarios para diseñar pruebas de valida-
pueden ayudar al usuario. El conjunto de caracteres Unicode ción de la entrada, de manera que se evite el procesamiento y
incluye todos los símbolos de los lenguajes estándar. Podemos almacenamiento de datos erróneos, lo cual es costoso y poten-
mostrar páginas Web escritas en otros alfabetos si descargamos cialmente perjudicial.
www.xlibros.com
508 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Hay que verificar las transacciones de entrada para ase- diante patrones que se encuentran en el diseño de la base de
gurar que la petición sea aceptable, esté autorizada y sea datos o se incluyen en los lenguajes de programación. A los
correcta. Los datos de entrada se pueden validar mediante patrones se les conoce como expresiones regulares y contienen
software que utilice varios tipos de pruebas que verifiquen si símbolos que representan el tipo de datos que debe haber en un
hay datos faltantes, la longitud de los elementos de datos, el campo.
rango y la sensatez de los datos, y que no haya valores inváli- Los entornos de comercio electrónico nos ofrecen la opor-
dos. Los datos de entrada también se pueden comparar con los tunidad de mejorar la precisión de los datos. Con un énfasis
datos almacenados para fines de validación. Una vez que se apropiado en los elementos de diseño centrados en el usuario, los
introducen datos numéricos, se pueden verificar y corregir en clientes pueden introducir sus propios datos, almacenarlos para
forma automática por medio de los dígitos de verificación y la su uso posterior, usar los mismos datos almacenados en todo el
fórmula de Luhn. proceso de cumplimiento del pedido y recibir retroalimentación
Hay un orden establecido en la prueba de los datos para en relación con las confirmaciones y actualizaciones de los pe-
validar cada campo. También hay métodos de validación me- didos.
PREGUNTAS DE REPASO
1. ¿Cuáles son los cuatro principales objetivos de la entrada de datos?
2. Mencione los cinco propósitos generales de codificar los datos.
3. Defina el término código de secuencia simple.
4. ¿Cuándo puede ser útil un código de derivación alfabética?
5. Explique lo que se logra con un código de clasificación.
6. Defina el término código de secuencia en bloque.
7. ¿Cuál es el tipo más simple de código para ocultar información?
8. ¿Cuáles son los beneficios de usar un código de subconjunto de dígitos significativos?
9. ¿Cuál es el propósito de usar un código mnemónico para los datos?
10. Defina el término código de función.
11. Mencione los ocho lineamientos generales para una codificación apropiada.
12. ¿Qué son los datos modificables?
13. ¿Qué son los datos de diferenciación?
14. ¿Cuál es una manera específica de reducir la redundancia de los datos que se van a introducir?
15. Defina el término cuello de botella según su aplicación en la entrada de datos.
16. ¿Cuáles son las tres funciones repetitivas de la entrada de datos que una computadora puede realizar con más eficiencia
que un operador de entrada de datos?
17. Mencione seis métodos de entrada de datos.
18. Mencione los tres principales problemas que pueden ocurrir con las transacciones de entrada.
19. Defina RFID. ¿Cuáles son las diferencias entre las etiquetas RFID activas y pasivas?
20. Mencione dos ejemplos del uso de etiquetas RFID en la administración de procesos o de inventario en entornos de
ventas al menudeo o centros al cuidado de la salud.
21. ¿Cuáles son las ocho pruebas para validar los datos de entrada?
22. ¿Qué prueba verifica si los campos de datos se llenaron correctamente con números o letras?
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 509
PROBLEMAS
1. Una pequeña universidad privada especializada en programas de graduados necesita llevar el registro de la lista de
estudiantes que a) hacen solicitud, b) son aceptados y c) se inscriben en la universidad. Por cuestiones de seguridad, la
universidad también debe enviar un informe al gobierno con una lista de los estudiantes extranjeros que se inscriben pero
no se registran. Sugiera un tipo de código para este fin y proporcione un ejemplo de su uso en la universidad, en donde
se demuestre si es apropiado o no. ¿Cuáles son sus ventajas?
2. Las Ardillas de la Universidad Central Pacific han estado usando un código de secuencia simple para llevar el registro de
los que poseen abonos de temporada y los fanáticos que no poseen abonos de temporada de todos sus programas
deportivos. Se han producido varias confusiones desagradables.
Sugiera en un párrafo un esquema de codificación distinto que ayude a identificar en forma única a cada abonado y
explique cómo podrá este esquema evitar las confusiones.
3. El código utilizado por una tienda de helados para ordenar sus productos es 12DRM215-220. Este código se descifra de
la siguiente manera: 12 representa la cuenta de artículos en la caja, DRM representa a unas paletas de hielo llamadas
“Dreamcicles” (un tipo específico de novedad en el ámbito de los helados) y 215-220 indica toda la clase completa de
productos bajos en grasa con los que cuenta el distribuidor.
a. ¿Qué tipo de código se utiliza? Describa el propósito detrás de cada parte (12, DRM, 215-220) del código.
b. Construya una entrada codificada usando el mismo formato y la misma lógica para una novedad en los helados
conocida como Pigeon Bars, que vienen en un paquete de seis y no son bajos en grasa.
c. Construya una entrada codificada usando el mismo formato y la misma lógica para una novedad en los helados
conocida como Airwhips, que viene en un paquete de 24 y es un producto bajo en grasa.
4. Los operadores de entrada de datos en la empresa Michael Mulheren Construction han estado cometiendo errores al
introducir los códigos para los productos de recubrimientos residenciales, que son los siguientes: U ⫽ estUco, A ⫽
Aluminio, R ⫽ ladRillo, M ⫽ Masonite, EZ ⫽ masonite esmaltado tipo EZ color-lok, N ⫽ recubrimiento de madera
Natural, PI ⫽ acabado con PIntura, SH ⫽ SHake SHingles. Sólo se permite un código por dirección.
a. Haga una lista de los posibles problemas con el sistema de codificación que podrían estar provocando entradas con
error. (Sugerencia: ¿Son las clases mutuamente excluyentes?).
b. Desarrolle un código mnemónico que ayude a los operadores a comprender lo que están introduciendo para mejorar
su precisión.
c. ¿Cómo rediseñaría las clases para los materiales de recubrimiento? Responda en un párrafo.
5. A continuación le mostramos un código para un producto en una extensa línea de cosméticos: L02002Z621289. La L
significa que es un lápiz labial, 0 significa que se introdujo sin barniz de uñas complementario, 2002 es un código de
secuencia que indica el orden en el que se produjo, Z es un código de clasificación que indica que el producto es
hipoalergénico y 621289 es el número de la planta (hay 15 plantas) donde se produce el producto.
a. Critique el código mediante una lista de las características que podrían provocar una entrada de datos imprecisa.
b. El diseñador Brian d’Arcy James es propietario de la empresa de cosméticos que utiliza este esquema de
codificación. Con un interés continuo en el nuevo diseño, Brian está dispuesto a considerar un código más elegante
que codifique la misma información de una mejor manera. Rediseñe el esquema de codificación y proporcione una
clave para su trabajo.
c. Escriba un enunciado para cada cambio que haya sugerido, indicando cuál problema de entrada de datos (del
problema 5a) eliminará ese cambio.
d. El Sr. d’Arcy James está encantado con su trabajo. Dice que a la empresa le gustaría contratarlo para que les ayudara
a expandir su actividad comercial para vender maquillaje para teatro (las obras como Wicked y Shrek con ocho
funciones por semana usan mucho maquillaje color verde). Agregue los nuevos códigos que sean necesarios para el
esquema de codificación que sugirió en el inciso b y proporcione una clave para su trabajo.
6. La empresa de cosméticos de d’Arcy James requiere que sus vendedores usen computadoras notebook para introducir
los pedidos de las tiendas departamentales (sus mayores clientes). Después esta información se transmite a los
almacenes y los pedidos se envían según el orden en el que hayan llegado. Por desgracia las tiendas están conscientes de
esta política y son muy competitivas en cuanto a cuál de ellas ofrecerá primero un nuevo producto de d’Arcy James.
Muchos vendedores han tomado el camino oscuro y han persuadido a los vendedores para que falsifiquen las fechas de
sus pedidos en los formularios de ventas, de manera que parezcan haberse hecho antes.
a. Este problema está creando una gran confusión en el almacén. No es viable disciplinar al personal involucrado.
¿Cómo se puede usar la computadora del almacén para certificar la fecha en que se realizan los pedidos? Explique
en un párrafo.
www.xlibros.com
510 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
b. Los vendedores se quejan de que tienen que ignorar su verdadero trabajo de vender para poder teclear los datos.
Mencione los elementos de datos relacionados con las ventas de cosméticos a las tiendas que se deban almacenar y
recuperar de la computadora central, en vez de tener que teclearlos en cada pedido.
c. Describa en uno o dos párrafos cómo los códigos de barras podrían ayudar a resolver el problema del inciso 6b.
7. Mencione el mejor método de entrada de datos y la razón por la que lo eligió para cada una de las siguientes seis
situaciones:
a. El documento de respuesta para una empresa de servicios públicos que desea la notificación de un cambio en la
dirección del cliente.
b. Sólo se pueden recuperar datos si hay una identificación de máquina positiva de la parte que solicita los datos.
c. No hay suficiente personal capacitado disponible para interpretar respuestas largas por escrito; se enviaron muchos
formularios que capturan respuestas a exámenes de opción múltiple; es necesario un alto nivel de confiabilidad; no
se requiere un tiempo de respuesta rápido.
d. Se estableció un almacén para una operación de venta de discos compactos con descuento; los botes están
identificados con la información sobre el precio, pero los discos individuales no; hay pocos operadores
experimentados disponibles para introducir los datos de los precios.
e. Centro de control de venenos que mantiene una base de datos extensa de venenos y antídotos; necesita una manera
de introducir datos sobre el veneno ingerido; también hay que introducir el peso, edad y condición física general de
la víctima cuando una persona llama al número de atención gratuito del centro para obtener consejos de emergencia.
f. Un consumidor compró en línea un DVD con su tarjeta de crédito.
8. Ben Coleman, uno de los miembros de su equipo de análisis de sistemas, lo sorprende al afirmar que cuando un sistema
utiliza una prueba para la longitud de campo correcta, es redundante incluir también una prueba de rango o sensatez.
Describa en un párrafo un ejemplo que demuestre que Ben está equivocado en este caso.
9. Varios vendedores se reunieron y empezaron a emitir una tarjeta de crédito “estatal” que sólo es válida en las tiendas en
su estado. Como cortesía, se permite a los vendedores transcribir el número de cuenta de 15 dígitos a mano (después de
obtenerlo de la oficina de contabilidad) si el cliente no lleva consigo la tarjeta. El único problema con las cuentas que los
vendedores han detectado hasta ahora es que algunas veces se aceptan números de cuenta erróneos en el sistema de
cómputo, lo cual provoca que se envíe una factura a una cuenta inexistente.
a. ¿Qué tipo de prueba de validez resolvería el problema? ¿Cómo? Responda en un párrafo.
b. Sugiera un método de entrada de datos alternativo que podría solucionar este problema por completo.
10. Los siguientes son números de piezas: 238902, 238933, 239402, 235693, 235405, 239204, 240965. Desarrolle un dígito
de verificación para estos números mediante el uso de multiplicadores 1-3-1-3-1 y módulo 11. Use el método que
presentamos en este capítulo. ¿Por qué algunos números tienen el mismo dígito de verificación?
11. Desarrolle un sistema de dígitos de verificación para los números de piezas del problema 10; use multiplicadores 5-4-3-
2-1 y módulo 11.
12. Desarrolle un sistema de dígitos de verificación para los números de piezas del problema 10; use la fórmula de Luhn.
13. ¿Por qué un sistema de dígitos de verificación tal como 1-1-1-1-1 no funciona tan bien como otros métodos? ¿Qué
errores no detectaría?
14. Defina una expresión regular para validar cada uno de los siguientes casos:
a. Un código postal de los EE.UU., que debe tener cinco dígitos seguidos de un guión corto opcional y de otros cuatro
dígitos.
b. Un número telefónico en el formato (aaa) nnn-nnnn, en donde aaa representa el código de área y las n representan
dígitos.
c. Una fecha en la forma de día-mes-año, en donde el mes es un código de tres letras y el año es de cuatro dígitos.
Debe haber un guión corto para separar el día del mes y otro para separar el mes del año.
d. El código de derivación alfabética que se muestra en este capítulo para el suscriptor de una revista. El formato es
99999XXX9999XXX, en donde X representa a una letra y 9 representa a un número.
15. Para los siguientes códigos, defina los criterios de validación (puede haber varias verificaciones para cada campo) y el
orden en el que evaluaría cada una de las condiciones.
a. Un número de tarjeta de crédito introducido en un formulario Web: El cliente seleccionó el tipo de tarjeta de
crédito de una lista desplegable.
b. Un número de pieza en una tienda de ferretería: El número de pieza es un código complejo, en donde el primer
dígito representa el departamento (como artículos del hogar, automotriz, etcétera) y el número debería ser de
autoverificación. Hay siete departamentos distintos.
c. La fecha en que se colocó el matasellos en un libro al momento de devolverlo a una biblioteca en línea: Se
debe incluir una copia del recibo del cliente con el libro. Los libros devueltos se deben sellar en un plazo no mayor a
30 días después de la fecha de compra.
d. El código hablado de un lenguaje utilizado en un sitio Web: (Sugerencia: Busque en la Web los códigos de
lenguajes estándar.).
e. El número de licencia de un conductor, compuesto de varias partes: El mes de nacimiento de la persona, el
cumpleaños y el año de nacimiento, no necesariamente juntos; un código que representa el color de ojos y un
número de secuencia. La licencia de conductor contiene la fecha de nacimiento, el color de ojos y de pelo, así como
el nombre y dirección de la persona.
f. El código postal canadiense: El formato es X9X 9X9 (X es cualquier letra, 9 es cualquier número).
g. Códigos de equipaje de aerolíneas: Como LAX para Los Ángeles o DUB para Dublín.
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 511
h. Una clave de producto utilizada para desbloquear el software comprado: La clave consiste en cuatro grupos de
cinco caracteres cada uno. El primer grupo debe tener dos letras seguidas de tres números; el segundo grupo debe
contener dos números seguidos de tres letras; el tercer grupo debe contener dos letras, cada una de la A a la G,
seguidas de tres números del uno al cuatro; y el último grupo debe contener una letra, E, G o C, dos dígitos con
valores de cuatro a siete y dos letras, ya sean A, B o C. (Sugerencia: Un patrón puede ser la mejor forma de validar
la clave del producto.).
PROYECTOS EN GRUPO
1. Lea junto con los miembros de su grupo la Oportunidad de consultoría 15.3, “Entrar o no entrar: esa es la cuestión” que
presentamos anteriormente en este capítulo. Diseñe un sistema de entrada de datos apropiado para Elsinore Industries. El
diseño de su grupo debe hacer énfasis en la eficiencia y precisión. Además, debe haber distinción entre los datos
modificables y los datos que indican la diferencia entre un elemento introducido y todos los demás. Dibuje los prototipos
de las pantallas necesarias para explicar lo que recomienda.
2. Divida su grupo en analistas y empleados de Elsinore Industries para un juego de roles. Los analistas deben presentar el
nuevo sistema de entrada de datos, completo con pantallas de prototipos. Pida a los empleados de Elsinore una
retroalimentación sobre el diseño.
3. Escriba un breve párrafo para describir cómo mejorar el diseño original de entrada de datos con base en los comentarios
recibidos.
BIBLIOGRAFÍA SELECCIONADA
Davis, G. B. y M. H. Olson, Management Information Systems, Conceptual Foundations, Structure, and Development, 2ª. Edi-
ción. Nueva York: McGraw-Hill, 1985.
Lamming, M. G., P. Brown, K. Carter, M. Eldridge, M. Flynn, G. Louie, P. Robinson y A. Sellan. “The Design of a Human
Memory Prosthesis”. Computer Journal, Vol. 37, 1994, pp. 153-163.
Lee, Y. M., F. Cheng y Y. T. Leung. “Exploring the Impact of RFID on Supply Chain Dynamics”. En Proceedings of the 2004
Winter Simulation Conference, pp. 1145-1152. Editado por R. G. Ingalls, M. D. Rossetti, J. S. Smith y B. A. Peters.
MacKay, D. J. Information Theory, Inference and Learning Algorithms. Cambridge, Reino Unido: Cambridge University Press,
2004.
Miller, G. A. “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capability for Processing Information”.
Psychological Review, Vol. 63, Núm. 2, marzo de 1956, pp. 81-97.
Newman, W. N., M. G. Lamming y M. Lamming. Interactive System Design. Reading, MA: Addison-Wesley Longman Publis-
hing Co., 1995.
Niederman, F., R. G. Mathieu, R. Morley e I. Kwon. “Examining RFID Applications in Supply Chain Management”, Commu-
nications of the ACM, Vol. 50, Núm. 7, julio de 2007, pp. 92-101.
Owsowitz, S. y A. Sweetland. “Factors Affecting Coding Errors”, Rand Memorandum RM-4346-PR. Santa Monica, CA: Rand
Corporatioin, 1965.
Robey, D. y W. Taggart. “Human Processing in Information and Decision Support Systems”. MIS Quarterly, Vol. 6, Núm. 2,
junio 1982, pp. 61-73.
Ryder, J. “Credit Card Validation Using LUHN Formula”. www.freevbcode.com. Último acceso en 26 de agosto de 2009.
www.xlibros.com
512 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
EPISODIO 15
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
www.xlibros.com
CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 513
FIGURA E15.1
TABLA DE CODIGOS
SISTEMA OPERATIVO
(OPERATING SYSTEM TABLE
OF CODES) definida mediante
Microsoft Access.
EJERCICIOS
E-1. Modifique e imprima los siguientes elementos con criterios de edición en el área Notas (o Valores y significados para
códigos específicos). Puede encontrarlos en la página Web Repositorio o en el repositorio de Visible Analyst.
E-2. Modifique e imprima los siguientes elementos con los criterios de edición colocados en el área Notas:
www.xlibros.com
514 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
E-3. Después de hablar con Dot Matricks y Mike Crowe, es aparente que los códigos del campus deben tener capacidad de
ordenamiento para instalar hardware y software, así como para crear hojas de inventario. Use Microsoft Access para
modificar e imprimir la tabla CODIGOS UBICACION CAMPUS (CAMPUS LOCATION CODES). El primer dígito
representa la ubicación del campus. Los valores son los siguientes:
1 Campus Central
2 Campus Waterford
3 Campus Hillside
Los siguientes tres dígitos representan los edificios en el campus, con los siguientes códigos de edificios:
Use una combinación (de su elección) de códigos y edificios del campus para construir la tabla final de códigos. Incluya
el significado del código.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
www.xlibros.com
C A P Í T U L O 16
Aseguramiento e
implementación de la calidad
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Reconocer la importancia de los usuarios y analistas que asumen el enfoque de calidad
total para mejorar la calidad del diseño y mantenimiento del software.
2. Comprender la importancia de los procesos de documentación, prueba, mantenimiento y
auditoría.
3. Entender cómo la arquitectura orientada a los servicios y la computación en nube están
cambiando la naturaleza del diseño de sistemas de información.
4. Diseñar programas de capacitación apropiados para usuarios del nuevo sistema.
5. Reconocer las diferencias entre las estrategias de conversión físicas; recomendar una
apropiada para un cliente.
6. Abordar cuestiones de seguridad, preparación para desastres y recuperación de desastres
para los sistemas tradicionales y basados en Web.
7. Comprender la importancia de evaluar el nuevo sistema y recomendar una técnica de
evaluación adecuada a un cliente.
515
www.xlibros.com
516 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Seis Sigma
La llegada de Seis Signa modificó el enfoque hacia la administración de la calidad. Los analistas de sistemas y
los usuarios de los sistemas necesitan estar conscientes de la existencia de Seis Sigma y aplicar algunos de los
principios a sus proyectos de análisis de sistemas. La metodología Seis Sigma, desarrollada originalmente por
Motorola en la década de 1980, es algo más que una metodología; es una cultura que se basa en la calidad. El
objetivo de Seis Sigma es eliminar todos los defectos y se aplica a cualquier producto, servicio o proceso. En los
libros de texto de administración de operaciones, desde la década de 1970 hasta finales de siglo, el control de
calidad se expresaba en términos de tres derivaciones estándar de la media, o tres sigma, lo cual equivale a cerca
de 67,000 defectos por millón de oportunidades. Seis Sigma implica un objetivo de no más de 3.4 defectos por
millón de oportunidades.
Seis Sigma es una metodología descendente. Es necesario que un CEO adopte la filosofía y que un ejecutivo
sirva como campeón del proyecto. Al líder de un proyecto Seis Sigma se le denomina Cinta Negra (la metáfora
de Cinta Negra proviene del sistema de clasificación de capacidades en las artes marciales). Los Cintas Negras
se certifican después de haber dirigido proyectos con éxito. A los demás miembros del equipo se les denomina
Cintas Verdes. Las Cintas Negras son Cintas Verdes que han trabajado en muchos proyectos y están disponibles
como recurso para los equipos de los proyectos.
Podemos sintetizar a Seis Sigma como una metodología (la figura 16.1 muestra los pasos de Seis Sigma);
sin embargo, es mucho más que sólo eso: es una filosofía y una cultura. Para obtener más información sobre Seis
Sigma y la administración de la calidad, visite el sitio Web del Juran Center en la Carlson School of Management,
University of Minnesota, Twin Cities (ww.csom.umn.edu). En 2002 el Juran Center emitió una declaración de
apoyo y fomento de la calidad. Los autores de este libro firmamos el estatuto en ese entonces y estamos comple-
tamente de acuerdo en sus principios.
El desaparecido Joseph M. Juran dijo: “Toda mejora de la calidad ocurre proyecto tras proyecto y de nin-
guna otra manera” (Juran, 1964). Los analistas de sistemas, los gerentes de proyectos y los usuarios deberían
tomar esto muy en serio.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 517
FIGURA 16.1
1
Todo analista de sistemas debe
Definir el comprender la metodología y
problema filosofía de Seis Sigma.
7 2
Sacar Observar el
conclusiones problema
6
Seis Sigma 3
5 4
ción. Es preferible que se reestructuren los estándares cada vez que el equipo de análisis de sistemas proponga
formalmente un nuevo sistema o una modificación importante al sistema actual.
No es fácil elaborar estándares, pero es posible y ya se ha hecho antes. Parte del trabajo del analista de siste-
mas es alentar a los usuarios a cristalizar sus expectativas sobre los sistemas de información y sus interacciones
con éstos.
Después es necesario comunicar los estándares de calidad departamentales por medio de la retroalimenta-
ción para el equipo de análisis de sistemas. A menudo, el equipo se sorprende de lo que se ha desarrollado. Por lo
general las expectativas son menos complejas de lo que los analistas experimentados saben que se podría hacer
con un sistema. Además, cabe la posibilidad de que las cuestiones humanas que el equipo de analistas pasó por
alto o subestimó se consideren mucho muy urgentes en los estándares de calidad de los usuarios. Al hacer que
los usuarios se involucren en delinear los estándares de calidad para los sistemas de información, el analista po-
drá evitar costosos errores en el desarrollo de sistemas no deseados o innecesarios.
Recorrido estructurado
Una de las acciones administrativas de calidad más robusta que el equipo de análisis de sistemas puede llevar
a cabo es realizar recorridos estructurados de manera rutinaria. Los recorridos estructurados son una manera de
usar colegas revisores para que supervisen la programación del sistema y su desarrollo en general, señalen los
problemas y permitan que el programador o analista responsable de esa parte del sistema realicen las modifica-
ciones apropiadas.
Los recorridos estructurados involucran por lo menos a cuatro personas: la persona responsable de la parte
del sistema o subsistema que se va a revisar (un programador o analista), un coordinador del recorrido, un colega
programador o analista y un colega que haga las anotaciones sobre sugerencias.
Cada persona que asiste a un recorrido tiene que desempeñar un papel especial. El coordinador está ahí
para asegurar que los otros se adhieran a los roles que tienen asignados y para asegurar que se realicen todas las
actividades programadas. El programador o analista está ahí para escuchar y no para defender su opinión, racio-
nalizar un problema o argumentar. El colega programador o analista está presente para señalar los errores o pro-
blemas potenciales, no para especificar cómo se deberían corregir. El que toma notas registra lo que se dice, de
manera que los otros presentes puedan interactuar sin ningún impedimento.
Los recorridos estructurados se adaptan bien en una metodología de administración de la calidad total cuando
se realizan en todo el ciclo de vida del desarrollo de sistemas. El tiempo que requieren debe ser poco (entre me-
www.xlibros.com
518 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 1 6 . 1
dia y una hora a lo más), lo cual significa que deben estar bien coordinados. La figura 16.2 muestra un formula-
rio útil para organizar el recorrido estructurado e informar sus resultados. Como los recorridos toman tiempo, no
es conveniente abusar de ellos.
Usar recorridos estructurados es una forma de obtener (y después actuar con base en) una valiosa retroali-
mentación desde una perspectiva que no tenemos nosotros. Al igual que con todas las medidas de aseguramiento
de calidad, el objetivo de los recorridos es evaluar el producto de manera sistemática en forma continua, en vez de
esperar a que se complete el sistema.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 519
FIGURA 16.2
Un formulario para documentar
recorridos estructurados; es
posible realizar recorridos cada
vez que se completa una porción
Informe para la
gerencia sobre de código, un sistema o un
el recorrido estru Fecha del recorrid
cturado o: / / subsistema.
Hora:
Porción (descripc
ión) del trabajo qu
e se examinó:
Coordinador del
recorrido:
Lista de participan
tes:
Comentarios:
Acción recomenda
da (marque una):
( ) ACEPTAR TR
Firma del coordina ABAJO COMO ES
dor: ( ) REVISAR TR TÁ
ABAJO
Fecha en que se pre ( ) REVISAR TR
ABAJO Y REALIZA
sentó R
el informe: / RECORRIDO DE SE
/ GUIMIENTO
( ) RECHAZAR TR
ABAJO
El diseño descendente es compatible con el pensamiento sobre sistemas generales que vimos en el capítulo 2.
Cuando los analistas de sistemas emplean una metodología descendente, están pensando en las interrelaciones e
interdependencias de los subsistemas y la manera en que se adaptan a la organización existente. La metodología
descendente también provee un conveniente énfasis en la sinergia o las interfaces que requieren los sistemas y
sus subsistemas, lo cual no es posible en la metodología ascendente. Esto ayuda a responder la pregunta sobre
cuántos equipos deben trabajar juntos para lograr sus metas.
Una de las ventajas de utilizar una metodología descendente para el diseño de sistemas es evitar el caos de
tratar de diseñar un sistema todo a la vez. Como hemos visto, el proceso de planeación e implementación de sis-
temas de información administrativa es increíblemente complejo. Tratar de implantar todos los subsistemas y
ejecutarlos al mismo tiempo es la vía más directa al fracaso.
Una segunda ventaja de la metodología descendente en el diseño es que permite a los equipos separados de
análisis de sistemas trabajar en paralelo en subsistemas distintos pero necesarios, lo cual puede ahorrar mucho
tiempo. El uso de equipos para el diseño de subsistemas se adapta muy bien de manera específica a una metodo-
logía de aseguramiento de calidad total.
www.xlibros.com
520 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
ATRACTIVO DE LA MAC
A un analista que necesite completar un recorrido estructurado le podría convenir utilizar Things, una aplicación para
el iPhone de Apple. Cuando los analistas regresan a su oficina, pueden descargar la información en su versión de escri-
torio. Things es simplemente otra forma de organizarse, pero es mucho más simple que OMNI-focus (que vimos en otra
sección del libro).
FIGURA 16.MAC
Things de Cultured Code.
Una tercera ventaja es que la metodología descendente evita un problema importante asociado con la meto-
dología ascendente: evita que los analistas de sistemas se enreden tanto en los detalles que pierdan la visión de lo
que se supone debe hacer el sistema.
La administración de calidad total y la metodología descendente para el diseño pueden ir de la mano. La
metodología descendente provee al grupo de sistemas una división preparada de usuarios en fuerzas de trabajo
(equipos especializados de usuarios) para los subsistemas. Las fuerzas de trabajo que se establecen de esta forma
pueden cumplir entonces una doble función como círculos de calidad para el sistema de información adminis-
trativa. De esta manera se establece la estructura necesaria para el aseguramiento de la calidad, al igual que la
motivación apropiada para hacer que el subsistema logre las metas departamentales que son importantes para los
usuarios involucrados.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 521
Una segunda ventaja del diseño modular es que los módulos son más fáciles de mantener. Por lo general, las
modificaciones se limitan a unos cuantos módulos y no se diseminan en todo un programa.
Una tercera ventaja del diseño modular es que los módulos son más fáciles de comprender, ya que son sub-
sistemas independientes. Por ende, un lector puede elegir un listado de código de un módulo y comprender su
función.
A continuación le mostramos algunos lineamientos para la programación modular:
1. Mantener cada módulo en un tamaño manejable (lo ideal es que sólo incluya una función).
2. Poner atención especial en las interfaces críticas (los datos y las variables de control que se pasan a otros
módulos).
3. Minimizar el número de módulos que debe modificar el usuario al realizar cambios.
4. Mantener las relaciones jerárquicas establecidas en las fases de la metodología descendente.
La herramienta recomendada para diseñar un sistema modular descendente se denomina diagrama de estructura;
consiste en cuadros rectangulares que representan a los módulos, junto con flechas para conectarlos.
La figura 16.3, un conjunto de módulos que se utilizan para modificar el registro de un cliente, muestra siete
módulos identificados como 000, 100, 110, 120, etcétera. Los módulos de nivel más alto se identifican con los
números de 100 en adelante y los de nivel más bajo, con números de 10 hasta antes del 100. Esta numeración
permite a los programadores insertar módulos utilizando un número entre los números de módulos adyacentes.
Por ejemplo, si insertamos un módulo entre los módulos 110 y 120 le asignaríamos el número 115.
En los extremos de las líneas conectoras se dibujan dos tipos de flechas. Las flechas con los círculos sin
relleno se denominan acoplamientos de datos y las flechas con los círculos rellenos se denominan banderas de
control o interruptores. Un interruptor es lo mismo que una bandera de control, excepto porque se limita a dos
valores: sí o no. Estas flechas indican que se transmite algo, ya sea hacia el módulo inferior o hacia el superior.
En teoría, el analista debería mantener este acoplamiento de datos en el mínimo posible. Entre menos puntos
de acoplamiento de datos y banderas de control tenga uno en el sistema, más fácil será modificarlo. Al momento de
empezar a programar estos módulos es importante pasar el menor número de puntos de acoplamiento de datos
entre los módulos.
Lo que es incluso más importante es evitar usar demasiadas banderas de control. El control está diseñado
para transmitirse de los módulos de nivel más bajo a los de nivel más alto en la estructura; en raras ocasiones
será necesario transmitir el control hacia abajo en la estructura. Cuando se pasa el control hacia abajo, se permite
a un módulo de nivel bajo tomar una decisión y el resultado es un módulo que realiza dos tareas distintas, lo que
viola el ideal de un módulo funcional: sólo debe realizar una tarea.
100
Modificar
registro de
cliente
www.xlibros.com
522 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Incluso cuando un diagrama de estructura logra todos los fines para los cuales se dibujó, no puede permane-
cer como la única técnica de diseño y documentación. En primer lugar, no muestra el orden en el que se deben
ejecutar los módulos (un diagrama de flujo de datos se encarga de eso); en segundo, no muestra el suficiente de-
talle (el español estructurado se encarga de eso).
FIGURA 16.4
Los módulos en las arquitecturas Servicios basados en Web
orientadas al servicio son
independientes y pueden ser
omnipresentes.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 523
lladores puedan buscar los servicios que necesitan. Por último, la seguridad y la privacidad pueden presentar pro-
blemas al utilizar software desarrollado por alguien más. Los defensores de la SOA afirman que la arquitectura
orientada a servicios ha hecho posibles muchas de las características que se encuentran en la Web 2.0.
METODOLOGÍAS DE DOCUMENTACIÓN
El esfuerzo de aseguramiento de calidad total requiere que los programas tengan una documentación apropiada.
Hay que documentar el software, los sistemas y los procedimientos tanto formales como informales, de manera
que se pueda dar mantenimiento a los sistemas y mejorarlos. La documentación permite a los usuarios, progra-
madores y analistas “ver” el sistema, su software y procedimientos sin tener que interactuar con él.
La rotación del personal de servicios de información ha sido tradicionalmente alta en comparación con otros
departamentos, por lo que es probable que las personas que idearon e instalaron el sistema original no sean las
mismas que le den mantenimiento. Una documentación consistente y bien actualizada reduce el número de horas
requeridas para que el nuevo personal aprenda a usar el sistema antes de realizar un mantenimiento.
Hay muchas razones por las que los sistemas y programas no se documentan o cuentan con muy poca docu-
mentación. Algunos de los problemas residen en los sistemas y programas en sí; otros, en los analistas y progra-
madores.
Los analistas de sistemas tal vez no documenten los sistemas de manera apropiada por falta de tiempo o
de una compensación suficiente por el tiempo invertido en esta tarea; algunos no lo hacen por aversión y otros
piensan que no es su verdadero trabajo. Además, muchos analistas se muestran reticentes a documentar siste-
mas que no sean de ellos, tal vez por temor a las represalias si incluyen material incorrecto sobre el sistema
de alguien más. Los defensores de la metodología SDLC nos recuerdan que la documentación que se lleva a
cabo mediante una herramienta CASE durante las fases de análisis puede hacer frente a muchos de estos pro-
blemas.
Manuales de procedimientos
Los manuales de procedimientos son documentos comunes en las organizaciones; la mayoría de las personas los
han visto. Son el componente en español de la documentación, aunque también pueden contener, por ejemplo,
códigos de programas y diagramas de flujo. Los manuales tienen el objetivo de comunicarse con quienes los
utilizan y contienen comentarios sobre antecedentes, los pasos requeridos para realizar distintas transacciones,
instrucciones sobre cómo recuperarse de los problemas y qué se puede hacer si algo no funciona (diagnóstico de
fallas). Muchos manuales están disponibles en línea, y en hipertexto para facilitar su uso.
También es conveniente tener una metodología sencilla y estandarizada para crear documentación de soporte
para los usuarios. Para ser útil, la documentación del usuario se debe mantener actualizada. El uso de la Web ha
revolucionado la velocidad con la que los usuarios pueden obtener ayuda. Muchos desarrolladores de software
han desplazado el soporte para los usuarios (junto con los manuales, páginas FAQ, chat en línea y comunidades
de usuarios) a la Web.
Las secciones clave de un manual son una introducción, cómo usar el software, qué hacer si las cosas salen
mal, una sección de consulta técnica, un índice e información sobre cómo ponerse en contacto con el fabricante.
Las mayores quejas con los manuales de procedimientos son que: 1) están mal organizados, 2) es difícil encontrar
información en ellos, 3) el caso específico en cuestión no aparece en el manual y 4) el manual no está escrito en
español común.
El método FOLKLORE
FOLKLORE es una técnica de documentación de sistemas que se creó para complementar algunas de las técni-
cas que hemos visto. Incluso con la plétora de técnicas disponibles, muchos sistemas están mal documentados o
no cuentan con ningún tipo de documentación. FOLKLORE recopila la información que comparten comúnmente
los usuarios pero que raras veces escriben.
FOLKLORE se desarrolló por primera vez en la década de 1980 por Kendall y Losee, mucho antes de la
creación de blogs y comunidades de usuarios. FOLKLORE tiene dos ventajas principales en comparación con
las comunidades de usuarios que se encuentran comúnmente: 1) es estructurado, lo cual produce una documenta-
ción más completa y organizada, y 2) anima a que alguien familiarizado con el software busque información en
vez de dejar que los usuarios avancen por su cuenta.
FOLKLORE es una técnica sistemática basada en los métodos tradicionales utilizados para recopilar el fol-
klore sobre las personas y leyendas. En esta metodología para la documentación de sistemas, el analista tiene
que entrevistar a los usuarios, investigar la documentación existente en los archivos y observar el procesamiento
de información. El objetivo es recopilar la información correspondiente a una de cuatro categorías: costumbres,
relatos, dichos y formas artísticas. La figura 16.5 sugiere cómo se relaciona cada categoría con la documentación
de sistemas de información.
www.xlibros.com
524 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 16.2
Al documentar las costumbres, el analista (u otro folklorista) trata de capturar por escrito lo que están ha-
ciendo los usuarios para ejecutar todos los programas sin problemas. Un ejemplo de una costumbre sería: “Por lo
general nos tardamos dos días en actualizar los registros mensuales debido a que la tarea es bastante extensa. Nos
encargamos de las cuentas comerciales el primer día y guardamos las demás para el siguiente”.
Los relatos son historias que cuentan los usuarios en relación con la forma en que trabajó el sistema. Desde
luego que la precisión del relato depende de la memoria del usuario y es a lo más una opinión sobre la manera en
que operó el programa. Por lo general los relatos tienen un principio, una parte media y un final. Así, tendríamos
una historia sobre un problema (el principio), una descripción de los efectos (la parte media) y la solución (el final).
Los dichos son declaraciones breves que representan generalizaciones o consejo. Tenemos muchos dichos en
la vida diaria, como “Más vale malo por conocido que bueno por conocer” o “Todo cabe en un jarrito sabiéndolo
acomodar”. En la documentación de sistemas tenemos también muchos dichos, como “Omita esta sección de có-
digo y el programa explotará” o “Siempre hay que respaldar datos con frecuencia”. A los usuarios les gusta dar
consejos, por lo que el analista debe tratar de capturarlos e incluirlos en la documentación de FOLKLORE.
La recopilación de formas artísticas es otra importante actividad de los folkloristas tradicionales, por lo que
el analista de sistemas también debe comprender su importancia. Los diagramas de flujo, los diagramas y las ta-
FIGURA 16.5
COSTUMBRES
Las costumbres, los relatos, los
Descripciones de la forma
dichos y las formas artísticas en que los usuarios hacen
utilizadas en el método de FORMAS ARTÍSTICAS
que funcione el sistema en
documentación FOLKLORE se ese momento. Diagramas, tablas y
aplican a los sistemas de diagramas de flujo.
información.
DICHOS
CUENTOS
“Haga esto y dará
resultado”. Historias sobre la forma
en que los usuarios
pudieron hacer que
funcionara el sistema.
FOLKLORE
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 525
FIGURA 16.HC1
En HyperCase puede usar FOLKLORE para documentar formas artísticas creadas o
recolectadas por los usuarios para hacer uso de sus sistemas.
blas que los usuarios dibujan algunas veces pueden ser mejores o más útiles que los diagramas de flujo dibujados
por el autor original del sistema. A menudo los analistas encontrarán dicho arte publicado en tableros de anun-
cios, o pueden pedir a los usuarios que limpien sus archivos y recuperen los diagramas que sean útiles.
Los colaboradores en el documento de FOLKLORE no tienen que documentar todo el sistema, sólo las par-
tes que conozcan. Al igual que con las comunidades de usuarios basadas en Web, el peligro de depender de FOL-
KLORE es que la información recopilada de los usuarios puede ser correcta, parcialmente correcta o incorrecta.
www.xlibros.com
526 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
El proceso de prueba
Todos los programas de aplicaciones recién escritos o modificados del sistema (así como los nuevos manuales de
procedimientos, el nuevo hardware y todas las interfaces del sistema) se deben probar de manera exhaustiva. No
basta con el método de prueba y error al azar. La prueba se realiza durante el desarrollo de sistemas y no sólo al
final. Su propósito es sacar a la luz los problemas desconocidos hasta ese momento, no demostrar la perfección
de los programas, manuales o equipo.
Aunque el proceso de prueba es tedioso, es una serie esencial de pasos que ayudan a asegurar la calidad del
sistema eventual. Es mucho menos perjudicial evaluar con anticipación a tener un sistema probado en forma in-
correcta que falle después de su instalación. Las pruebas se realizan en los subsistemas o módulos del programa
a medida que avanza su desarrollo. El proceso de prueba se lleva a cabo en muchos niveles, a diversos intervalos.
Antes de poner el sistema en producción hay que realizar una verificación de escritorio de todos los programas,
comprobarlos con datos de prueba y comprobar que los módulos funcionen en conjunto como se había pla-
neado.
También hay que probar el sistema como un todo funcional. Aquí se incluye la prueba de las interfaces entre
los subsistemas, la exactitud de la salida, además de la utilidad y comprensibilidad de la documentación y salida
del sistema. Los programadores, analistas, operadores y usuarios desempeñan distintos roles en los diversos as-
pectos del proceso de prueba, como se muestra en la figura 16.6. Por lo general la prueba del hardware se pro-
porciona como un servicio por parte de los distribuidores de equipo, quienes realizan sus propias pruebas en el
equipo cuando se entrega en el sitio.
FIGURA 16.6
Los programadores, analistas,
operadores y usuarios desempeñan
Prueba de los programas con Prueba de vínculos
distintos roles en el proceso de datos de prueba
prueba del software y los sistemas. con datos de prueba
PROGRAMADORES ANALISTAS
PRUEBA
OPERADORES USUARIOS
Prueba completa
de sistemas con Prueba completa de
datos de prueba sistemas con
datos reales
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 527
PRUEBA DE PROGRAMAS CON DATOS DE PRUEBA Gran parte de la responsabilidad de la prueba de los
programas recae en el (los) autor(es) original(es) de cada programa. El analista de sistemas actúa como
consejero y coordinador para la prueba de los programas; su objetivo es asegurar que los programadores
implementen las técnicas de prueba correctas, pero es probable que no lleve a cabo personalmente este nivel de
comprobación.
En esta etapa los programadores primero deben realizar una verificación de escritorio de sus programas para
comprobar la forma en que funcionará el sistema. En este tipo de comprobación el programador sigue cada paso
del programa en papel para verificar que la rutina funcione según lo escrito.
A continuación, los programadores deben crear datos de prueba tanto válidos como inválidos. Luego se eje-
cutan los programas con estos datos para ver si las rutinas básicas funcionan y detectar errores. Si la salida de los
módulos principales es satisfactoria, puede agregar más datos de prueba para verificar otros módulos. Los datos
de prueba creados deben probar los valores mínimos y máximos posibles, así como todas las posibles variacio-
nes en formato y códigos. La salida de archivos de los datos de prueba se debe verificar con cuidado. Nunca
debemos asumir que los datos que contiene un archivo son correctos sólo porque se creó y se pudo acceder a su
contenido.
Durante este proceso el analista de sistemas verifica la salida en busca de errores y aconseja al programador
en caso de requerir alguna corrección. Por lo general el analista no recomienda ni crea datos de prueba para pro-
bar los programas, pero podría señalar al programador las omisiones de los tipos de datos que se deban agregar
en pruebas posteriores.
PRUEBA DE VÍNCULOS CON DATOS DE PRUEBA Cuando los programas pasan la verificación de escritorio y la
comprobación con datos de prueba, deben pasar por la prueba de vínculos, a la cual también se le conoce como
prueba de cadena. La prueba de vínculos verifica que los programas interdependientes trabajen juntos realmente
como se planeó.
El analista crea datos especiales de prueba que abarcan varias situaciones de procesamiento para la prueba
de vínculos. Primero se procesan los datos de prueba comunes para ver si el sistema puede manejar las transac-
ciones normales, las que representan la mayor parte de su carga. Si el sistema funciona con las transacciones
normales se agregan variaciones, incluyendo los datos inválidos utilizados para asegurar que el sistema pueda
detectar errores en forma apropiada.
PRUEBA DE SISTEMAS COMPLETOS CON DATOS DE PRUEBA Al concluir de manera satisfactoria las pruebas de
vínculos, se debe probar el sistema como una entidad completa. En esta etapa, los operadores y usuarios finales
se involucran de manera activa en la prueba. Aquí se utilizan los datos de prueba creados por el equipo de análisis
de sistemas con el propósito específico de probar los objetivos del sistema.
Como es de esperarse, hay varios factores a considerar a la hora de probar sistemas con datos de prueba:
1. Examinar si los operadores tienen la documentación adecuada en los manuales de procedimiento (impresos
o en línea) para lograr una operación correcta y eficiente.
2. Verificar si los manuales de procedimientos son lo bastante claros para comunicar la forma en que se deben
preparar los datos para la entrada.
3. Averiguar si los flujos de trabajo requeridos por el sistema nuevo o modificado realmente “fluyen”.
4. Determinar si la salida es correcta y si los usuarios comprenden que esta salida es casi idéntica a la
apariencia que tendrá en su forma final.
Recuerde programar el tiempo adecuado para la prueba del sistema. Por desgracia este paso se pasa por alto con
frecuencia si la instalación del sistema está requiriendo más tiempo del planeado.
La prueba de sistemas incluye la reafirmación de los estándares de calidad establecidos para el desempeño
del sistema al crear sus especificaciones iniciales. Todos los involucrados deben estar una vez más de acuerdo
en cómo determinar si el sistema hace lo que se supone que debe hacer. Este paso debe incluir medidas de error,
conveniencia, facilidad de uso, orden apropiado de las transacciones, tiempo inactivo aceptable y manuales de
procedimientos comprensibles.
PRUEBA DE SISTEMAS COMPLETA CON DATOS REALES Cuando las pruebas de sistemas con datos de prueba
resulten satisfactorias, es conveniente probar el nuevo sistema con varias corridas de datos reales, es decir,
usando datos satisfactoriamente procesados por el sistema anterior. Este paso permite una comparación precisa
de la salida del nuevo sistema con lo que sabemos que es una salida procesada en forma correcta, además de
que es una buena idea para probar cómo se manejarán los datos reales. Sin duda, este paso no es posible al crear
salidas completamente nuevas (por ejemplo, la salida de una transacción de comercio electrónico de un nuevo
sitio Web corporativo). Al igual que con los datos de prueba, se utilizan sólo pequeñas cantidades de datos reales
en este tipo de prueba del sistema.
www.xlibros.com
528 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 1 6 . 3
Aunque hemos considerado con mucho detenimiento la interacción entre usuario y sistema (vea el capítulo
14), nunca podremos predecir por completo todo el rango de diferencias que ésta asume. No es suficiente en-
trevistar a los usuarios sobre la forma en que están interactuando con el sistema; debemos observarlos personal-
mente.
Los elementos a observar son la facilidad de aprender a usar el sistema y la reacción de los usuarios a la
retroalimentación del sistema, incluyendo lo que ocurre al recibir un mensaje de error y lo que ocurre cuando se
informa al usuario que el sistema está ejecutando sus comandos. Hay que estar especialmente atentos a la forma
en que los usuarios reaccionan al tiempo de respuesta del sistema y al lenguaje de las respuestas. También hay
que escuchar lo que dicen los usuarios sobre el sistema a medida que lo van descubriendo. Hay que resolver
cualquier problema real antes de poner el sistema en producción, no sólo encubrirlos como ajustes al sistema que
los usuarios y operadores deberían realizar por su cuenta.
Al igual que el software de computadora, también hay que probar los manuales de procedimientos. Aunque
el personal de soporte puede revisar los manuales, y el equipo de análisis de sistemas puede verificar su precisión
técnica, la única forma real de probarlos es a través de los usuarios y operadores, de preferencia cuando se reali-
zan pruebas completas en el sistema con datos reales. Considere las sugerencias de los usuarios e incorpórelas en
las versiones finales de las páginas Web, los manuales impresos y el resto de la documentación.
Prácticas de mantenimiento
Su objetivo como analista de sistemas debe ser instalar o modificar sistemas que tengan una vida útil razona-
ble. Lo ideal es crear un sistema cuyo diseño sea integral y con una suficiente visión a futuro suficiente para
atender las necesidades actuales y proyectadas de los usuarios durante los años por venir. Recurra a su expe-
riencia para anticipar esas necesidades y después agregar tanto flexibilidad como capacidad de adaptación al
sistema. Entre mejor sea el diseño del sistema, más fácil será mantenerlo y menos dinero tendrá que invertir la
empresa en ello.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 529
Reducir los costos de mantenimiento es primordial, ya que el mero mantenimiento del software puede devo-
rar hasta el 50 por ciento del presupuesto total de procesamiento de datos de una empresa. Los costos excesivos
de mantenimiento son responsabilidad del diseñador del sistema, ya que cerca del 70 por ciento de los errores de
software se atribuyen a un diseño de software inapropiado. Desde la perspectiva de sistemas, tiene sentido el he-
cho de que detectar y corregir los errores de diseño de software lo antes posible sea menos costoso que dejar que
pasen desapercibidos hasta que sea necesario el mantenimiento.
La mayor parte de las veces el mantenimiento se realiza para mejorar el software existente y no para respon-
der a una crisis o falla del sistema. El mantenimiento también se realiza para actualizar software en respuesta a
los cambios en la organización. Este trabajo no es tan sustancial como mejorar el software, pero hay que hacerlo.
El mantenimiento de emergencia y adaptativo representa menos de la mitad de todo el mantenimiento del sis-
tema.
Parte del trabajo del analista de sistemas es asegurar que se implementen los canales y procedimientos
adecuados para permitir la retroalimentación sobre las necesidades de mantenimiento y las acciones para sa-
tisfacerlas. Para los usuarios debe ser fácil comunicar los problemas y las sugerencias a los encargados de dar
mantenimiento al sistema. Las soluciones son proveer a los usuarios el acceso vía correo electrónico al soporte
técnico, así como permitirles descargar actualizaciones de productos o parches a través de la Web.
Auditoría
La auditoría es otra forma de asegurar la calidad de la información que contiene el sistema. En términos genera-
les, la auditoría se refiere al proceso de hacer que un experto que no esté involucrado en el proceso de establecer
o usar un sistema examine la información para evaluar su confiabilidad. Sin importar que la información resulte
confiable o no, el hallazgo sobre su confiabilidad se comunica a los demás con el fin de que actúen en conse-
cuencia.
Para los sistemas de información, en general hay dos tipos de auditores: internos y externos. El hecho de
determinar si ambos son necesarios para el sistema que usted diseñe dependerá del tipo de sistema. Los auditores
internos trabajan para la misma organización que posee el sistema de información, mientras que los auditores ex-
ternos (también llamados independientes) se contratan del exterior.
Los auditores externos se utilizan cuando el sistema de información procesa datos que influyen en los esta-
dos financieros de la empresa; los externos realizan una auditoría sobre el sistema para asegurar la imparcia-
lidad de los estados financieros que se producen. También se pueden usar cuando ocurre algo fuera de lo normal
en el que hay empleados de la empresa involucrados, como una sospecha de fraude por computadora o malver-
sación de fondos.
Los auditores internos estudian los controles que se utilizan en el sistema de información para asegurarse de
que sean adecuados y que estén realizando la función esperada. También evalúan la conveniencia de los controles
de seguridad. Aunque trabajan para la misma organización, los auditores internos no se reportan con la persona
responsable del sistema al que están auditando. Con frecuencia, el trabajo de los auditores internos es más pro-
fundo que el de los auditores externos.
Tecnología cliente-servidor
El modelo cliente-servidor, la computación cliente-servidor, la tecnología cliente-servidor y la arquitectura clien-
te-servidor se refieren a un modelo de diseño que podemos considerar como aplicaciones que se ejecutan en una
www.xlibros.com
530 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
red. En términos muy básicos, podemos imaginar que el cliente hace (y el servidor ejecuta, o cumple de cierta
forma con) la solicitud. Eso se consideraría una arquitectura cliente-servidor de dos niveles.
Hay una configuración más compleja en la que se involucran tres conjuntos de computadoras para realizar
los procesos de recuperación, procesamiento, almacenamiento y recepción de los datos. La figura 16.7 muestra
un modelo cliente-servidor de tres niveles. En esta figura, las computadoras cliente acceden a tres niveles de ser-
vidores: los servidores Web, que manejan el intercambio de información basado en Web; los servidores de apli-
caciones, que procesan datos que entran y salen de las computadoras cliente y el servidor de bases de datos; y el
servidor de bases de datos, que almacena y recibe los datos. Las computadoras en la red están programadas para
realizar su trabajo con eficiencia al dividir las tareas de procesamiento entre los clientes y servidores.
Piense en el modelo cliente/servidor como en un sistema que coloca a los usuarios como el centro del tra-
bajo, con su interacción con datos como concepto clave. Aunque hay dos elementos funcionando —el cliente y el
servidor— el objetivo del modelo cliente-servidor es que los usuarios lo vean como un sistema. De hecho, se es-
pera que los usuarios no adviertan cómo desempeña la red cliente-servidor su procesamiento distribuido, debido
a que debe tener la apariencia de un sistema unificado. En una red de igual a igual, las PC pueden actuar como el
servidor o el cliente, dependiendo de los requerimientos de la aplicación.
CLIENTES COMO PARTE DEL MODELO CLIENTE-SERVIDOR Al ver el término cliente, podría verse tentado a pensar
en personas o usuarios; por ejemplo, hablamos de “clientes de nuestra práctica de consultoría”. Sin embargo, en
el modelo cliente-servidor el término cliente no se refiere a las personas, sino a máquinas conectadas en red que
son los puntos típicos de entrada al sistema cliente-servidor que utilizan los humanos. Por lo tanto, los clientes
podrían ser computadoras de escritorio conectadas en red, una estación de trabajo, computadoras portátiles o
cualquier otra forma en que el usuario pueda entrar al sistema.
FIGURA 16.7
Una configuración cliente-servidor
de tres niveles.
Servidor de aplicaciones
(procesa datos que entran y
salen de las computadoras
cliente y del servidor de
bases de datos)
Servidor Web
(maneja el intercambio de
información basada en Web)
Computadoras cliente
(el medio de entrada y
visualización de información)
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 531
Al usar una interfaz gráfica de usuario (GUI), los individuos por lo general interactúan en forma directa
sólo con la parte del cliente. Las estaciones de trabajo del cliente usan programas más pequeños que residen en
el cliente para hacer el procesamiento en primer plano (contrario al procesamiento en segundo plano, que men-
cionaremos más adelante), incluyendo la comunicación con el usuario. Si una aplicación se denomina aplicación
basada en el cliente, la aplicación reside en una computadora cliente y otros usuarios en la red no pueden acceder
a ella.
ANÁLISIS DE LAS VENTAJAS Y DESVENTAJAS DEL MODELO CLIENTE-SERVIDOR Las primeras empresas en adoptar
el modelo cliente-servidor descubrieron que no siempre es la mejor solución a los problemas informáticos de
la organización. Con frecuencia, se pide al diseñador de sistemas que avale un modelo cliente-servidor que ya
está en funcionamiento. Así como con cualquier otra propuesta de cómputo corporativa en cuya creación usted
no haya tenido una parte activa, debe revisar el plan cuidadosamente. ¿Apoyará la cultura de la organización un
modelo cliente-servidor? ¿Qué cambios es necesario hacer en la cultura informal y en los procedimientos de
trabajo formales para que un modelo cliente-servidor se pueda usar con todo su potencial? ¿Cuál debe ser su rol
como analista de sistemas en esta situación?
Aunque uno de los beneficios mencionados del modelo cliente-servidor son costos más bajos de procesa-
miento, hay muy pocos datos reales disponibles para demostrarlo (incluso cuando hay alguna evidencia anecdó-
tica para apoyar esta aseveración). Hay costos de cambio y costos iniciales muy bien documentados asociados
con una migración hacia una arquitectura cliente-servidor. Las aplicaciones para el modelo cliente-servidor se
deben escribir como dos componentes de software, cada uno de los cuales se ejecuta en una máquina separada,
pero que deben aparecer como si operaran como una sola aplicación. Sin embargo, usar el modelo cliente-servi-
dor permite usar mayor poder de cómputo y brinda una mejor oportunidad de personalizar las aplicaciones, en
comparación con las otras opciones.
Aunque las redes se pueden caracterizar por su forma o topología, también se clasifican por su alcance
geográfico y los tipos de servicios que ofrecen. Los tipos estándares de redes incluyen una red de área amplia
(WAN) y una red de área local (LAN). Las LAN son estándares para vincular computadoras locales o terminales
en un departamento, edificio o varios edificios de una organización. Las WAN pueden servir a los usuarios a tra-
vés de varios kilómetros o de continentes enteros.
Ahora, conectar una red también es técnica, económica y operacionalmente factible para las oficinas pe-
queñas y proporciona una solución que los analistas deben considerar para los negocios pequeños. Uno de los
aspectos costosos a la hora de implementar una LAN es que cada vez que se mueve hay que volver a tender el
cableado. Algunas organizaciones están haciendo frente a este problema mediante la aplicación de una red de
área local inalámbrica de alta velocidad (WLAN). Dicho en forma más específica, a estas redes inalámbricas se
les conoce como Wi-Fi.
Computación en nube
En la actualidad, el tipo de computación con un crecimiento más rápido es la computación en nube. Este tipo de
computación se describe como una metáfora para Internet, ya que a menudo Internet se dibuja como una nube en
los diagramas de red. Al utilizar la computación en nube, las organizaciones y los usuarios individuales pueden
usar servicios Web, servicios de bases de datos y servicios de aplicaciones a través de Internet, sin tener que
invertir en hardware corporativo o personal, software o herramientas de software. La figura 16.8 describe los in-
tercambios entre computadoras cliente y los servicios en la nube. Las empresas utilizan navegadores Web como
Microsoft Internet Explorer o Mozilla Firefox para acceder a estas aplicaciones. Como puede ver, los servidores
almacenan software y datos para las empresas.
Muchas empresas de hardware, software y consultoría grandes y bien establecidas como Cisco, Dell, IBM,
HP, Microsoft, SAP y otras están llevando a cabo esfuerzos masivos de computación en nube, a menudo con lo
que se denomina “recursos virtualizados”. Lo distinto de estas metodologías es su habilidad de crecer y adaptarse
a las necesidades cambiantes de las empresas. Es decir, son escalables para adaptarse a la demanda creciente
(o cambiante) por parte de los usuarios. El modelo de “software como un servicio”, también conocido como
SaaS, se incluye en el concepto de la computación en nube.
Por su parte, los usuarios no necesitan comprender, controlar o ser expertos en la infraestructura de tecno-
logía que constituye la compleja infraestructura de nube que les permite realizar su trabajo. Con frecuencia las
organizaciones no necesitan mantener personal de TI para dimensionar hacia arriba o hacia abajo, incluso cuando
el contrato o presupuesto de una compañía cambie en forma ascendente o descendente debido al impacto redu-
cido de estos cambios.
Es común que las organizaciones que utilizan la computación en nube no encuentren necesario realizar gas-
tos iniciales de capital en infraestructura de TI, por lo que las empresas más pequeñas con presupuestos menores
y menos predecibles pueden avanzar en el procesamiento con más rapidez. Esto también permite a las grandes
corporaciones invertir en proyectos estratégicos en vez de hacerlo en infraestructura de TI.
www.xlibros.com
532 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 16.8
La computación en nube ofrece
muchos servicios.
Computadoras cliente
Compartir recursos de TI por medio de la computación en nube significa que una gran colección de usuarios
corporativos comparten servicios Web, pero también tienen que compartir el costo de éstos; además descubren
que aumenta la capacidad de carga máxima y que se puede maximizar la eficiencia y el uso de los sistemas.
Las empresas también esperan mejorar su habilidad de desempeñar el proceso de recuperación de desastres
mediante el uso de la computación en nube, ya que provee muchos sitios redundantes. Aunque la computación en
nube no es inmune a los cortes de energía, puede dividir el riesgo entre varios servidores.
Las organizaciones tratan de mejorar la seguridad a través de la computación en nube y mediante el uso de
servicios que se venden con un énfasis especial en la seguridad. Sin embargo, existe la preocupación de que la
centralización de este tipo pueda también significar una pérdida del control sobre los datos de misión crítica. Los
usuarios se podrían beneficiar de la movilidad al no estar supeditados a una sola instalación de computadora o
una sola interfaz. Los navegadores Web y los servicios basados en Web disponibles a través de la computación en
nube liberan a los usuarios para acceder a las aplicaciones en cualquier parte y a cualquier hora, sin preocuparse
por la ubicación o el dispositivo que vayan a utilizar.
Muchas empresas grandes de software (algunas de las cuales se denominan “jugadores puros” o “pure
players”, ya que nunca han existido como empresas con presencia física) ofrecen aplicaciones que utilizan la
computación en nube, en donde los usuarios pueden utilizar su navegador Web para acceder a las aplicaciones.
Algunos ejemplos son Google Apps (para hojas de cálculo y calendarios), Amazon Web Services, Akami y el
software CRM de Salesforce.com que ahora también está disponible en el iPhone. Estos proveedores de software
afirman que están tratando de reducir el costo para el usuario, así como de proporcionar mayor flexibilidad.
Algunos observadores tienen la creencia de que migrar a la computación en nube es una forma de que las
empresas más grandes y antiguas se solidifiquen y retengan sus negocios esenciales al incorporar SaaS (software
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 533
como un servicio), SOA (Arquitectura orientada a servicios), virtualización, código fuente abierto y muchas otras
tendencias de la última década en sus ofrecimientos de software, herramientas de software, servicios y poder de
cómputo vía Internet. Pero si el costo de la infraestructura cayera drásticamente (como lo ha hecho según la his-
toria), el impulso hacia la computación en nube se podría invertir. Si eso ocurriera, las organizaciones podrían to-
mar decisiones distintas e invertir una vez más en su propia infraestructura. Además, muchos de los servicios en
línea que conforman la computación en nube se pagan por medio de los ingresos provenientes de la publicidad.
En una economía vacilante se reducirían los ingresos por publicidad y los patrocinios de la computación en nube
podrían disminuir también.
Modelado de red
Debido a que la conexión a una red se ha vuelto muy importante, el diseñador de sistemas necesita tomar en
cuenta al diseño de la red. Ya sea que un diseñador de sistemas tenga que decidir sobre las configuraciones de las
redes —o si se preocupa por el hardware tal como enrutadores y puentes que deben estar en el lugar cuando se
conocen las redes—, siempre debe tomar en cuenta el diseño lógico de las redes.
Un analista debe adoptar un conjunto de símbolos tal como los de la figura 16.9 para modelar la red. Es útil
tener diferentes símbolos para distinguir entre concentradores, redes externas y estaciones de trabajo. También
es útil adoptar una convención para ilustrar múltiples redes y estaciones de trabajo. El primer paso es dibujar un
diagrama de descomposición de red que proporcione una apreciación global del sistema. Después, dibujar
un diagrama de conectividad de concentrador. Finalmente, dividir el diagrama de conectividad de concentrador
para mostrar las diversas estaciones de trabajo y cómo se conectan.
CÓMO DIBUJAR UN DIAGRAMA DE DESCOMPOSICIÓN DE RED Podemos ilustrar el dibujo de un modelo de
descomposición de red al referirnos una vez más al ejemplo de World’s Trend Catalog Division de los capítulos
anteriores. Empiece dibujando un círculo en la parte superior y denominándolo “Red de World’s Trend”.
Ahora dibuje varios círculos en el nivel inferior, como se muestra en la figura 16.10. Estos círculos representan
los concentradores para la división de marketing y para cada uno de los tres centros de toma de pedidos y
distribución (división estadounidense, división canadiense y división mexicana).
Podemos extender este dibujo al dibujar otro nivel. Esta vez, podemos agregar las estaciones de trabajo.
Por ejemplo, la división de marketing tiene dos estaciones de trabajo conectadas, mientras que la división esta-
dounidense tiene 33 estaciones de trabajo en su LAN (administración, almacén, gerente de entrada de pedido y
30 empleados de entrada de pedido). Esta red se simplifica con el propósito de proporcionar un ejemplo fácil de
entender.
FIGURA 16.9
Use símbolos especiales al dibujar
Concentrador o red de área local diagramas de descomposición
de red y de conectividad de
concentrador.
Red externa
Estación de trabajo
www.xlibros.com
534 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 16.10
Red de
Un diagrama de descomposición World’s
de red para World’s Trend. Trend
División
División de División División Proveedores
estado-
marketing canadiense mexicana (21)
unidense
Empleados de
Gerente de Publicaciones Gerente de entrada de
Almacén
publicidad de catálogos entrada de pedido
mexicano
pedido (4)
Empleados de
Almacén Gerente de entrada de
canadiense entrada de pedido
pedido (8)
Empleados de
Almacén Gerente de
Adminis- entrada de
estado- entrada de
tración pedido
unidense pedido (30)
FIGURA 16.11
Un diagrama de conectividad de División
concentrador para World’s Trend. canadiense
10
s –3
i lla ,50
5m 0m
62 illa
s
División
División de 50 millas 50–3,500 millas Proveedores
estado-
marketing unidense (21)
s
2,7
50 m illa
m 00
illa
s –3,5
1
División
mexicana
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 535
Para producir un diagrama de conectividad de concentradores eficaz, empiece por dibujar todos los concen-
tradores. Después experimente (quizás haciendo primero un bosquejo en una hoja de papel) para ver qué víncu-
los son necesarios. Una vez hecho esto, puede volver a dibujar el diagrama para que sea atractivo e informe bien
a los usuarios.
EXPANSIÓN DEL DIAGRAMA DE CONECTIVIDAD DE CONCENTRADORES EN UN DIAGRAMA DE CONECTIVIDAD DE
ESTACIONES DE TRABAJO El propósito del modelado de redes es mostrar la conectividad de las estaciones de
trabajo con un cierto nivel de detalle. Para ello hay que expandir el diagrama de conectividad de concentradores.
La figura 16.12 muestra cada una de las 33 estaciones de trabajo para la división estadounidense y cómo se
deben conectar.
Dibuje los diagramas para este nivel examinando el tercer nivel del diagrama de descomposición de red.
Agrupe artículos tales como Gerente de entrada de pedido y Empleados de entrada de pedido, debido a que ya
reconoce que se deben conectar. Use un símbolo especial para mostrar múltiples estaciones de trabajo e indique
en paréntesis el número de estaciones de trabajo similares. En nuestro ejemplo, hay 30 empleados de entrada de
pedido.
En el perímetro del diagrama, coloque estaciones de trabajo que se deben conectar a otros concentrado-
res. De esta forma, será más fácil representar estas conexiones usando flechas. Dibuje las conexiones exter-
nas en un color diferente o use flechas más gruesas. Por lo general, las conexiones externas están a grandes
distancias. Por ejemplo, la administración se conecta a la división de marketing, la cual está a 50 millas,
y también a las divisiones canadiense y mexicana. El almacén necesita comunicarse directamente con los
almacenes canadiense y mexicano en caso de que sea posible obtener la mercancía de otro almacén. El ge-
rente de entrada de pedido y los empleados de entrada de pedido no tienen que estar conectados con nadie
fuera de su LAN.
VENTAJAS DE LOS SISTEMAS DISTRIBUIDOS Los sistemas distribuidos permiten el almacenamiento de datos en
lugares donde no estorben a las transacciones de tiempo real en línea. Por ejemplo, el tiempo de respuesta en las
consultas se podría mejorar si no todos los registros necesitan ser investigados antes de que se dé una respuesta.
Además, los usuarios no necesitan los datos todo el tiempo, de modo que se pueden almacenar en medios menos
caros en un sitio diferente y se pueden acceder sólo cuando sea necesario.
El uso de sistemas distribuidos también puede bajar los costos de equipo, debido a que no todas las partes
del sistema necesitan desempeñar todas las funciones. Se hace posible compartir algunas habilidades tales como
procesamiento y almacenamiento.
50 millas
ies
500 pies 0p 50–100 pies
25
A la división canadiense
575 millas Empleados
Almacén 200–250 pies de entrada
A la división mexicana
2,800 millas de pedido
(30)
A los proveedores
50–3,500 millas
www.xlibros.com
536 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 16.13
Ventajas de los sistemas distribuidos
Hay cinco ventajas principales en
cuanto a crear sistemas • Permiten el almacenamiento remoto de datos en línea y
distribuidos. transacciones en tiempo real
• Permiten un medio menos caro de almacenamiento de
datos cuando los usuarios no los necesitan continuamente
• Reducen el costo de equipo debido a que no todas las partes
del sistema necesitan desempeñar todas las funciones
• Reducen el costo de equipo al permitir la flexibilidad en la
elección de un fabricante
• Al principio son menos costosos que los sistemas grandes
debido a que la expansión se puede planear sin tener que
comprar hardware
Los sistemas distribuidos también pueden ayudar a bajar los costos al permitir la flexibilidad en la elección
del fabricante, debido a que el enfoque total de redes se centra en la comunicación entre nodos y los fabricantes
hacen componentes compatibles. Esta compatibilidad permite al usuario tomar decisiones de compra con base
en el precio así como en la funcionalidad. Además, al principio, los sistemas distribuidos pueden ser menos
costosos que los sistemas grandes porque es posible diseñar para la expansión sin realmente tener que comprar
el hardware en el momento que el sistema se implementa. El desarrollo de intranets corporativas es una forma
anticipada de conectar a una red a los miembros de la organización, una forma que también puede servir como
medio para reducir los aspectos problemáticos de Internet (tal como navegar sin objeto por Internet en horas de
oficina o posibles fallas de seguridad causadas por la falta de firewall) y al mismo tiempo como apoyo al trabajo
de grupo con aplicaciones útiles. Las extranets formadas con proveedores y otros socios importantes también son
excelentes formas de demostrar que un negocio está orientado hacia el exterior y es accesible. En la figura 16.13
se mencionan ventajas de los sistemas distribuidos.
DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS Los sistemas distribuidos presentan algunos problemas únicos
que los sistemas de cómputo centralizados no poseen. El analista necesita pesar estos problemas contra las
ventajas presentadas y plantearlos también con la empresa interesada.
El primer problema es la confiabilidad de la red. Para hacer de una red un recurso en lugar de una carga,
debe ser posible transmitir, recibir, procesar y almacenar datos de forma confiable. Si hay demasiados problemas
con la confiabilidad del sistema, éste se abandonará.
La distribución de gran potencia de cómputo a individuos incrementa la amenaza a la seguridad debido al
acceso extendido. La necesidad de contraseñas confidenciales, salas de cómputo seguras y capacitación de segu-
ridad adecuada al personal son cuestiones que se multiplican cuando se implementan sistemas distribuidos.
Los analistas de sistemas que crean sistemas distribuidos necesitan enfocarse en la red o en el aspecto coor-
dinado de los sistemas distribuidos. Su poder reside en la capacidad de interactuar como grupos de trabajo de
usuarios que comparten datos. Si el analista de sistemas ignora o resta importancia a la relación entre los subsis-
temas, está creando más problemas de los que está resolviendo. En la figura 16.14 se mencionan las desventajas
de los sistemas distribuidos.
CAPACITACIÓN DE USUARIOS
La capacitación es un proceso educativo en el que participan los analistas de sistemas con los usuarios. El usua-
rio se ha involucrado en todo el ciclo de vida de desarrollo de sistemas, por lo que ahora el analista debe tener
una valoración exacta de los usuarios que se deben capacitar.
FIGURA 16.14
Desventajas de los sistemas distribuidos
Las cuatro desventajas de los
sistemas distribuidos. • Dificultad para lograr un sistema confiable
• Las preocupaciones de seguridad se incrementan proporcionalmente cuando
más personas tienen acceso al sistema
• Los analistas deben hacer énfasis en la red y las interacciones que ésta
proporciona; además deben restar importancia al poder de los subsistemas
• Escoger el nivel erróneo de cómputo para el soporte (por ejemplo,
personas en lugar de departamentos, departamentos en lugar de
sucursales)
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 537
Estrategias de capacitación
Los factores que determinan las estrategias de capacitación son las personas que serán capacitadas y quiénes las
capacitarán. El analista tendrá que garantizar que cualquiera cuyo trabajo sea afectado por el nuevo sistema de
información sea propiamente capacitado por el instructor correcto.
A QUIÉN CAPACITAR Todas las personas que tendrán uso principal o secundario del sistema deben recibir
capacitación: desde los capturistas hasta aquellos que usarán la salida para tomar decisiones sin usar
personalmente una computadora. La cantidad de capacitación que requiere un sistema depende de cuánto
cambiará el trabajo de alguien debido a las nuevas interacciones requeridas por el nuevo sistema.
Debe asegurarse de que los usuarios con diferentes niveles de habilidad e intereses de trabajo estén separa-
dos. Habrá problemas si incluye a principiantes en las mismas sesiones de capacitación que los expertos, debido
a que los principiantes se pierden con rapidez y los expertos se aburren con los elementos básicos. En consecuen-
cia, ambos grupos se pierden.
PERSONAS QUE CAPACITAN A LOS USUARIOS Para un proyecto grande, se podrían usar muchos instructores
dependiendo de cuántos usuarios se deben capacitar y quiénes son. Las posibles fuentes de capacitación incluyen
lo siguiente:
1. Vendedores.
2. Analistas de sistemas.
3. Instructores externos.
4. Instructores internos.
5. Otros usuarios del sistema.
Esta lista proporciona sólo algunas de las opciones que el analista tiene para diseñar y proporcionar la capacita-
ción.
Con frecuencia, los vendedores grandes proporcionan uno o dos días de sesiones de capacitación sobre su
equipo como parte de los beneficios de servicio ofrecidos cuando las corporaciones compran software COTS
caro. Estas sesiones incluyen conferencias y capacitación práctica en un entorno específico. También pueden ex-
tender la experiencia con grupos de usuarios en línea, blogs dedicados o conferencias anuales de usuarios.
Debido a que los analistas de sistemas conocen a las personas y al sistema de la organización, con frecuencia
pueden proporcionar buena capacitación. El uso de analistas para los propósitos de capacitación depende de su
disponibilidad, debido a que también se espera que vigilen el proceso de implementación completo.
En ocasiones, la organización contrata instructores externos para colaborar en la capacitación. Éstos podrían
tener gran experiencia en capacitar a las personas en cómo usar una variedad de computadoras, pero podrían no
dar la capacitación práctica que algunos usuarios necesitan. Además, tal vez no tengan la capacidad de personali-
zar suficientemente sus presentaciones para hacerlas significativas para los usuarios.
Los instructores internos de tiempo completo con frecuencia están familiarizados con el personal y pueden
adaptar los materiales a sus necesidades. Una de las desventajas de los instructores internos es que podrían tener
experiencia en áreas aparte de los sistemas de información y por consiguiente podrían carecer del alto grado de ex-
periencia técnica que los usuarios requieren.
También es posible asignar a cualquiera de estos instructores para que capacite a un grupo pequeño de per-
sonas de cada área funcional que estará usando el nuevo sistema de información. A su vez, estas personas se pue-
den usar para capacitar al resto de los usuarios. Este enfoque puede funcionar bien si los aprendices originales
todavía tienen acceso a los materiales e instructores como recursos cuando ellos mismos proporcionen la capaci-
tación. De lo contrario, esto podría acabar como una situación de prueba y error en lugar de una estructurada.
www.xlibros.com
538 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 16.4
objetivos permiten evaluación de capacitación cuando están completos. Por ejemplo, los operadores deben saber
dichos elementos esenciales como encender la máquina, qué hacer cuando ocurren errores comunes, solucionar
problemas básicos y cómo acabar un proceso de entrada.
MÉTODOS DE CAPACITACIÓN Cada usuario y operador necesitará capacitación ligeramente diferente. Hasta cierto
punto, sus trabajos determinan lo que necesitan saber, y sus personalidades, experiencia y antecedentes determinan
cómo aprenden mejor. Algunos usuarios aprenden mejor viendo, otros oyendo y otros haciendo. Debido a que
normalmente no es posible personalizar totalmente la capacitación, una combinación de métodos es a menudo la
mejor forma de proceder. Así, se satisface a la mayoría de los usuarios mediante un método u otro.
Los métodos para aquellos que aprenden mejor viendo incluyen demostraciones de equipo y exposición para
manuales de capacitación. Aquellos que aprenden mejor oyendo se beneficiarán de las conferencias sobre los
procedimientos, discusiones y sesiones de preguntas y respuestas entre instructores y aprendices. Aquellos que
aprenden mejor haciendo necesitan experiencia práctica con el nuevo equipo. Para los operadores de computa-
dora, la experiencia práctica es esencial, mientras que un gerente de control de calidad para una línea de produc-
ción sólo podría necesitar ver la salida, aprender a interpretarla y saber cuándo se espera que llegue.
SITIOS DE CAPACITACIÓN La capacitación se lleva a cabo en muchas ubicaciones, algunas de las cuales son más
favorables para aprender que otras. Los grandes vendedores de computadoras proporcionan ubicaciones remotas
especiales donde se mantiene equipo operable en forma gratuita. Sus instructores ofrecen experiencia práctica así
como seminarios en situaciones que permiten a los usuarios concentrarse en aprender el nuevo sistema. Una de
las desventajas de la capacitación remota es que los usuarios están fuera del contexto organizacional en el cual
finalmente deberán operar.
La capacitación en las instalaciones de la organización a la cual pertenecen los usuarios también es posible
con varios tipos diferentes de instructores. La ventaja es que los usuarios ven el equipo tal como estará cuando
sea totalmente operacional dentro del contexto organizacional. Una desventaja seria es que los aprendices con
frecuencia se sienten culpables de no cumplir sus tareas rutinarias de trabajo si permanecen en el lugar de la ca-
pacitación. En estos casos, no se puede lograr una total concentración en la capacitación.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 539
FIGURA 16.15
Elementos Factores relevantes
Los objetivos de capacitación,
Objetivos de capacitación Dependen de los requerimientos del trabajo del usuario métodos, sitios y materiales están
sujetos a muchos factores.
Métodos de capacitación Dependen del trabajo del usuario, personalidad, antecedentes y
experiencia; usa una combinación de conferencia, demostración,
práctica y estudio
Materiales de capacitación Dependen de las necesidades del usuario; manuales operativos, casos,
prototipos de equipos y salida; tutoriales en línea
Los sitios de capacitación remota también están disponibles mediante un pago a través de consultores y ven-
dedores. Los sitios de capacitación se pueden establecer en lugares de alquiler tales como un salón de hotel o
instalaciones permanentes mantenidas por los instructores. Estos arreglos permiten a los trabajadores liberarse de
las demandas regulares del trabajo, pero no podrían proporcionar equipo para la capacitación práctica.
MATERIALES DE CAPACITACIÓN En la planeación de capacitación de usuarios, los analistas de sistemas deben
comprender la importancia de los materiales de capacitación bien preparados. Estos materiales incluyen manuales
de capacitación; casos de capacitación, en los cuales los usuarios se asignan para trabajar a través de un caso que
incluye la mayoría de las interacciones normalmente encontradas con el sistema, y prototipos y muestras de
salidas. Los usuarios de sistemas grandes a veces se podrán capacitar en simulaciones detalladas basadas en Web
o software que es idéntico a lo que se escribe o se compra. La mayoría de los vendedores de software COTS
proporciona tutoriales en línea que ilustran las funciones básicas, y los distribuidores podrían mantener sitios
Web que ofrecen páginas dedicadas a responder preguntas frecuentes (FAQ), las cuales se pueden descargar e
imprimir. Los cambios a los manuales también se pueden recabar de los sitios Web de muchos vendedores.
Debido a que el entendimiento del sistema por parte de los usuarios depende de ellos, los materiales de ca-
pacitación se deben escribir claramente para el público correcto con un mínimo de jerga. Los materiales de capa-
citación también deben estar bien indexados y disponibles para cualquiera que los necesite. En la figura 16.15 se
proporciona un resumen de consideraciones para objetivos de capacitación, métodos, sitios y materiales.
Estrategias de conversión
En la figura 16.16 se presentan las cinco estrategias para convertir del sistema viejo al nuevo:
1. Conversión directa.
2. Conversión paralela.
3. Conversión gradual o por fases.
4. Conversión modular.
5. Conversión distribuida.
Cada enfoque de conversión se describe en las siguientes subsecciones.
CONVERSIÓN DIRECTA La conversión directa significa que en una fecha especificada, el sistema viejo se
abandona y el nuevo sistema se pone en uso. La conversión directa puede tener éxito sólo si antes se lleva a cabo
una comprobación extensa, y funciona mejor cuando se pueden tolerar algunos retrasos en el procesamiento. La
conversión directa se considera un enfoque arriesgado para la conversión. Podrían ocurrir trastornos en el entorno
laboral si los usuarios se ofenden porque se les obliga a usar un sistema desconocido sin recursos. Por último, no
hay ninguna forma adecuada para comparar los nuevos resultados con los viejos.
www.xlibros.com
540 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
FIGURA 16.16
Método de conversión Cambios a través del tiempo
Cinco estrategias de conversión
para los sistemas de información. Conversión directa
Conversión paralela
Conversión gradual
Conversión modular
Conversión distribuida
CONVERSIÓN PARALELA La conversión paralela se refiere a ejecutar al mismo tiempo el sistema viejo y el nuevo,
en paralelo. Cuando se obtienen los mismos resultados todo el tiempo, el nuevo sistema se pone en uso y el
viejo se detiene. Una ventaja de ejecutar ambos sistemas en paralelo es la posibilidad de verificar los nuevos
datos contra los viejos para percibir cualesquier errores en el procesamiento del nuevo sistema. Las principales
desventajas incluyen el costo de ejecutar dos sistemas al mismo tiempo y el agobio en los empleados de
virtualmente doblar su carga de trabajo durante la conversión.
CONVERSIÓN GRADUAL La conversión gradual, o por fases, intenta combinar las mejores características de los dos
planes previamente mencionados, sin incurrir en todos los riesgos. En este plan, el volumen de las transacciones
manejado por el nuevo sistema aumenta gradualmente conforme el sistema se introduce por fases. Las ventajas
de este método incluyen permitir a usuarios que se involucren gradualmente con el sistema, la posibilidad de des-
cubrir y recuperar errores sin desperdiciar mucho tiempo y la capacidad de agregar características una por una.
Las metodologías ágiles tienden a usar esta metodología de conversión.
CONVERSIÓN MODULAR La conversión modular usa la construcción de subsistemas independientes y ope-
racionales para cambiar de los sistemas viejos a los nuevos de forma gradual. Conforme se modifica y acepta
cada módulo, se pone en uso. Una ventaja es que cada módulo se prueba completamente antes de ser usado.
Otra ventaja es que los usuarios se familiarizan con cada módulo conforme se vuelve operacional. Esta retro-
alimentación ha ayudado a determinar los atributos finales del sistema. Las metodologías orientadas a objetos
utilizan con frecuencia esta metodología.
CONVERSIÓN DISTRIBUIDA La conversión distribuida se refiere a una situación en que se contemplan muchas
instalaciones del mismo sistema, como es el caso en actividades bancarias o franquicias tal como restaurantes
o tiendas de ropa. Una conversión completa se hace (con cualquiera de los cuatro enfoques considerado
previamente) en un sitio. Cuando esta conversión se completa exitosamente, se prosigue con las demás. Una
ventaja de la conversión distribuida es que se pueden detectar y contener un problema antes de que repercuta
simultáneamente en todos los sitios. Una desventaja es que incluso cuando una conversión es exitosa, cada sitio
tendrá su propia gente y cultura, además de sus propias peculiaridades regionales y locales para trabajar, y se
deben manejar en consecuencia.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 541
4. Planear, fijar y supervisar a programadores y personal de captura de datos que deben convertir todos los
archivos y bases de datos relevantes.
Para muchas implementaciones, su papel principal será estimar con precisión el tiempo necesario para cada
actividad, nombrar a las personas para manejar cada subproyecto y coordinar su trabajo. Para proyectos más
pequeños, hará mucho del trabajo de conversión por usted mismo. Muchas de las técnicas de administración de
proyecto que vimos en el capítulo 3, tal como las gráficas de Gantt, PERT, análisis de puntos de función y la co-
municación exitosa con los miembros del equipo, son útiles para planear y controlar la implementación.
Familia
Guerra Sistema de soporte de decisiones Sociedad
Expedición Organismo
Juego
Jungla Sistemas expertos/AI Organismo
Zoológico Máquina
Expedición
Sociedad Sistemas cooperativos Juego
Zoológico Organismo
Zoológico Guerra
Familia Sistemas competitivos Juego
Sociedad Organismo
www.xlibros.com
542 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Seguridad física
La seguridad física se refiere a proteger el sitio donde se encuentra la computadora, su equipo y software a través
de medios físicos. Puede incluir acceso controlado a las salas de cómputo por medio de signos legibles por la
máquina, sistemas biométricos o un registro de entrada y salida del sistema por un humano, así como el uso de
cámaras de televisión de circuito cerrado para supervisar las áreas de cómputo, respaldando con frecuencia los
datos y almacenando los respaldos en un área a prueba de fuego o de agua, a menudo en una ubicación remota
segura.
Además, el equipo de cómputo pequeño se debe asegurar para que un usuario típico no pueda moverlo y se
debe garantizar el suministro ininterrumpido de energía eléctrica. Las alarmas que notifican a las personas apro-
piadas en caso de fuego, inundación o intrusión no autorizada de una persona deben estar en todo momento en
funcionamiento activo.
El analista debe tomar las decisiones acerca de la seguridad física junto con los usuarios cuando esté pla-
neando las instalaciones de cómputo y la compra de equipo. Sin duda la seguridad física puede ser mucho mejor
si se planea con antelación a la instalación real y si las salas de cómputo se dotan de equipo de seguridad especial
al momento de construirlas, en lugar de equiparse después de que se hayan construido.
Seguridad lógica
La seguridad lógica se refiere a los controles lógicos en el software. Los controles lógicos son conocidos por
la mayoría de los usuarios como contraseñas o códigos de autorización de alguna clase. Cuando se usan, per-
miten al usuario entrar al sistema o a una parte específica de una base de datos con una contraseña correcta.
Sin embargo, las contraseñas se manejan de manera descuidada en muchas organizaciones. Los emplea-
dos han escuchado por casualidad gritar una contraseña en las oficinas atestadas, grabar las contraseñas para
sus pantallas y compartir las contraseñas personales con empleados autorizados que han olvidado las suyas.
Se ha desarrollado software de cifrado especial para proteger las transacciones comerciales en Web y las
transacciones comerciales están proliferando. Sin embargo, el fraude de Internet también ha aumentado brusca-
mente, y hay pocas autoridades capacitadas en identificar a los delincuentes y se evidencia una mentalidad de
“salvaje oeste” o “última frontera” en esos casos cuando las autoridades han podido aprehender a los delincuen-
tes de Web.
Una forma para que las redes reduzcan el riesgo de exposición al desafío de la seguridad del mundo ex-
terior es construir un firewall o un sistema similar. Un firewall construye una muralla entre la red interna y la
externa de una organización (tal como Internet). Se asume que la red interna es confiable y segura, mientras
que Internet no lo es. Se pretende que los firewalls impidan la comunicación entrante o saliente de la red que
no haya sido autorizada y que no se requiera. Un sistema firewall no es un remedio perfecto para la seguridad
organizacional y de Internet; sin embargo, es una capa adicional de seguridad que ahora se acepta amplia-
mente. Todavía no hay ninguna forma totalmente integrada de solucionar los problemas de seguridad con las
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 543
redes internas y externas, pero merecen la atención de los analistas al diseñar cualquier sistema nuevo o me-
jorado.
Los controles lógicos y físicos son importantes, pero no son suficientemente claros para proporcionar la se-
guridad adecuada. Los cambios conductuales también son necesarios.
Seguridad conductual
Las expectativas conductuales de una organización están implícitas en sus manuales de políticas e incluso en le-
treros anunciados en las salas de trabajo y los comedores, como vimos en el capítulo 5. Sin embargo, la conducta
que los miembros de la organización interiorizan también es crítica para el éxito de los esfuerzos de seguridad
(una razón por la que los firewalls no son totalmente a prueba de ataques es que muchos ataques a los sistemas
de información provienen del interior de la organización).
La seguridad puede empezar con la identificación de empleados que en algún momento tendrán acceso a
las computadoras, datos e información, para asegurar que sus intereses son consistentes con los intereses de la
organización y que entienden por completo la importancia de llevar a cabo los procedimientos de seguridad. Es
necesario escribir, distribuir y actualizar las políticas con respecto a la seguridad para que los empleados estén
totalmente conscientes de las expectativas y responsabilidades. Es típico que el analista de sistemas primero ten-
drá contacto con los aspectos conductuales de la seguridad. Algunas organizaciones han escrito reglas o políticas
que prohíben a los empleados navegar en Web durante horas de trabajo o incluso prohíben totalmente la navega-
ción de Web, si el equipo de la compañía está involucrado. Otras corporaciones usan software de bloqueo para
limitar el acceso a los sitios Web que se consideran inaceptables en el lugar de trabajo, tal como sitios de juegos,
apuestas o pornográficos.
Parte del aspecto conductual de la seguridad es supervisar la conducta a intervalos irregulares para cercio-
rarse de que se están siguiendo los procedimientos apropiados y corregir cualesquier conductas que se podrían
deteriorar con el tiempo. Hacer que el sistema registre el número de inicios de sesión fallidos de los usuarios es
una forma de supervisar si usuarios no autorizados están intentando iniciar sesión en el sistema. Es conveniente
inventariar periódica y frecuentemente el equipo y software. Además, es necesario examinar las sesiones largas
inusuales o el acceso al sistema atípico después de las horas de oficina.
Los empleados deben entender claramente lo que se espera de ellos, lo que se prohíbe y la magnitud de sus
derechos y responsabilidades. Debe comunicar al personal acerca de toda la supervisión que se está haciendo o
que se está contemplando y debe proporcionar la razón para esto. Dicha comunicación debe incluir el uso de cá-
maras de vídeo, monitoreo de software y telefónico.
La salida generada por el sistema se debe reconocer por su potencial de poner a la organización en riesgo en
algunas circunstancias. Los controles para la salida incluyen pantallas que sólo se pueden acceder mediante la
contraseña, la clasificación de información (es decir, a quién se puede distribuir y cuándo) y el almacenamiento
seguro de documentos impresos y almacenados, sin importar el formato.
En algunos casos, es necesario tomar medidas para destruir documentos clasificados o confidenciales. Los
servicios de destrucción o pulverización se pueden contratar con una empresa externa que, por una cuota, des-
truirá medios magnéticos, cartuchos de impresora y papel. Una corporación grande puede destruir anualmente
más de 34,000 kilos de material de salida en una variedad de medios.
www.xlibros.com
544 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 545
Al sufrir un desastre, la empresa se arriesga a perder personas, dinero, reputación y sus propios bienes, así
como los de sus clientes. Es importante hacer lo correcto para minimizar las pérdidas potenciales. Los analistas
deben determinar cuál es el nivel de planeación contra desastres de la organización y qué tan bien articulado está
el rol de sistemas de información en sus planes de respuesta y recuperación en caso de desastres. Las preguntas
clave que se deben hacer los analistas lo antes posible son: 1) si los empleados saben a dónde ir y 2) qué hacer
en caso de un desastre. La respuesta a estas preguntas lo guiará a través del proceso de planeación. La sabiduría
convencional provee siete elementos a considerar durante y después de un desastre. Como veremos, muchos de
estos elementos involucran a los sistemas de información y se relacionan de manera específica con la planeación
que usted debe proveer como analista de sistemas.
1. Identificar los equipos responsables para administrar una crisis.
2. Eliminar puntos individuales de fallas.
3. Determinar las tecnologías de duplicación de datos que coincidan con la agenda de la organización para
poner los sistemas en funcionamiento.
4. Crear planes de reubicación y transportación detallados.
5. Establecer varios canales de comunicación entre los empleados y consultores que están en el sitio, como los
equipos de analistas.
6. Proveer soluciones de recuperación que incluyan una ubicación remota.
7. Asegurar el bienestar físico y psicológico de los empleados y otros que puedan estar físicamente presentes
en el sitio de trabajo cuando ocurra un desastre.
El plan de preparación para desastres debe identificar a los responsables de realizar varias decisiones fun-
damentales en caso de un desastre. Hay que decidir si van a continuar o no las operaciones comerciales; cómo
brindar soporte para las comunicaciones (tanto de computadora como de voz); a dónde se enviarán las personas
si las instalaciones de la empresa son inhabitables; a dónde irá el personal en caso de una emergencia; ocuparse
de las necesidades personales y psicológicas de las personas presentes en la empresa y los que podrían trabajar
en forma virtual; y restaurar los entornos principales de cómputo y laborales.
La redundancia de los datos provee la clave para eliminar puntos individuales de fallas para los servidores
que ejecutan aplicaciones Web. Como analista, usted puede ser especialmente útil para establecer este tipo de
respaldo y redundancia.
Algunas empresas están migrando a las redes de área de almacenamiento (SAN) para evitar parte de la ines-
tabilidad asociada con los respaldos físicos en cintas magnéticas y su almacenamiento. La duplicación remota
sincrónica (también conocida como discos en espejo, o data mirroring) también está ganando popularidad. Pero
si las empresas están a más de 100 millas de distancia del sitio, el proceso de discos en espejo se puede ver afec-
tado. La duplicación remota asíncrona envía datos a la ubicación de almacenamiento secundaria en intervalos de
tiempo designados. Hay opciones en línea para pequeñas empresas también.
La organización debe desarrollar y distribuir a todos un memorándum de una página que contenga las rutas
de evacuación y los puntos de reunión de los empleados. Las tres opciones comunes son enviar a los empleados
a sus casas, hacer que permanezcan dentro de las instalaciones o reubicarlos a una instalación de recuperación
preparada para continuar operando. Hay que tener en cuenta toda la gama de opciones de transportación a la hora
de desarrollar este memo.
Los miembros de la organización y del equipo de análisis de sistemas deben ser capaces de comunicarse en
caso de que se interrumpa el sistema ordinario de correo electrónico. Si no hay correo electrónico disponible para
transmitir un mensaje de emergencia, una página Web con información de emergencia o una línea telefónica
pueden servir para tal fin como alternativas viables. Hace poco, varias empresas de software empezaron a ofre-
cer una suite de herramientas de software que permiten la comunicación ad hoc mediante agencias de respuesta
de emergencia que les permiten establecer con rapidez herramientas de VoIP, conectividad Web y Wi-Fi. La dis-
ponibilidad cada vez más amplia y los precios más bajos sin duda llevarán en el futuro estas importantes herra-
mientas de comunicación a otros tipos de organizaciones.
Para proteger mejor los sistemas de respaldo de la organización y asegurar el flujo continuo de las tran-
sacciones bancarias en caso de un desastre, las nuevas regulaciones en los Estados Unidos estipulan que las
ubicaciones remotas de los bancos deben estar por lo menos a 100 millas de distancia del sitio original. Como
los archivos y respaldos en papel también representan un gran problema y son muy vulnerables a los desastres
naturales y humanos, es imprescindible que las organizaciones creen un plan que les ayude a migrar hacia un
proyecto de documentación digital con el fin de convertir todos sus documentos en papel a formatos electrónicos,
dentro de un plazo de entre tres y cinco años después de su creación (Stephens, 2003).
El soporte para los humanos que trabajan en una organización que experimenta un desastre es algo primor-
dial. Debe haber suficiente agua potable a la que se tenga un fácil acceso, en especial si los empleados no pue-
den salir del sitio durante varios días debido a las condiciones del clima exterior o derrumbamientos parciales de
edificios. Aunque la comida es importante, el agua lo es más. También se debe proporcionar a los empleados un
www.xlibros.com
546 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 16.5
kit de seguridad que contenga agua, una mascarilla antipolvo, una linterna, barras luminosas y un silbato. Una
forma de averiguar qué debe contener un kit de provisiones contra desastres para el espacio de trabajo individual
es ir al sitio Web de la Cruz Roja Americana (www.redcross.org), donde se proveen los detalles para apoyar a las
personas en caso de desastres y hacerse cargo de ellas después de los mismos.
EVALUACIÓN
A lo largo del ciclo de vida del desarrollo de sistemas, el analista, los directivos y los usuarios han estado eva-
luando la evolución de los sistemas de información y las redes para proporcionar retroalimentación para su me-
jora eventual. La evaluación también se necesita para dar seguimiento a la implementación del sistema.
Técnicas de evaluación
En reconocimiento de que la evaluación continua de sistemas de información y redes es importante, se han in-
ventado muchas técnicas de evaluación. Estas técnicas incluyen el análisis costo-beneficio (como vimos en el
capítulo 3); los modelos que intentan estimar el valor de una decisión con base en los efectos de la información y
que usan teoría de información, simulación o estadísticas bayesianas; las evaluaciones del usuario que enfatizan
los problemas de implementación y participación del usuario, y los enfoques de utilidad de sistemas de informa-
ción que examinan las propiedades de la información.
Cada tipo de evaluación sirve para un propósito diferente y tiene desventajas inherentes. El análisis costo-
beneficio podría ser difícil de aplicar, debido a que los sistemas de información proporcionan información acerca
de los objetivos para la primera vez, haciendo imposible comparar el desempeño antes y después de la implemen-
tación del sistema o red distribuida. El enfoque de evaluación de decisión revisada presenta dificultad, debido a
que todas las variables involucradas con el diseño, el desarrollo y la implementación del sistema de información
no se pueden calcular o cuantificar. El enfoque de participación del usuario produce algún entendimiento para
los nuevos proyectos al proporcionar una lista de control de la conducta potencialmente disfuncional por varios
miembros organizacionales, pero enfatiza la implementación sobre otros aspectos del diseño del SI. El enfoque
de utilidad del sistema de información para la evaluación puede ser más completo que otros si se extiende y se
aplica de manera sistemática.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 547
Módulos de
sistemas de Utilidad de Utilidad de Utilidad de Utilidad de Utilidad de Utilidad de
información forma tiempo lugar posesión actualización objetivo
Listas de Bueno. Acrónimos Bueno. Los Bueno. Las listas de Bueno. Los informes Bueno. La Bueno. La
inventario usados donde son informes se inventario se los recibieron las implementación fue información acerca
Éxito iguales que los códigos recibieron por lo imprimieron en el mismas personas fácil debido a que los de la ubicación de
de envío. Conforme menos una hora centro regional de que originalmente hospitales encontraron una unidad
crece un sistema, se antes de que se sangre. Las listas se mantuvieron los las listas de inventarios particular estuvo
presenta demasiada programaran los entregaron a los registros manuales. extremadamente útiles. disponible.
información; esta envíos en una hospitales con los
sobrecarga se hizo para base diaria. envíos actuales.
resumir la información.
Informes de Bueno. El informe de Bueno. Igual que Bueno. Los informes Bueno. Los Bueno. Los Bueno. Los informes
resumen de resumen se diseñó para los listados. de resumen se administradores de administradores de de resumen
la gerencia las especificaciones de imprimieron en sangre que sangre participaron en ayudaron a reducir
Éxito formato exactas de los el centro donde originalmente el diseño de los obsolescencias y
informes de resumen se necesitaban. mantienen los informes. evitar escasez.
manuales desarrollados informes manuales
por el administrador de recibieron estos
sangre de los hospitales reportes.
de la ciudad.
Pronóstico a Bueno. Se emitió un Bueno. Los Bueno. Se imprimieron Bueno. Los Bueno. El diseño de Bueno. Se
corto plazo pronóstico para cada pronósticos se en el banco de sangre. administradores la salida pudo haber previnieron
Éxito tipo de sangre. actualizaron a involucrados con la sido más participativo. ausencias al llamar
diario. distribución y a más donadores.
recolección reciben
el informe.
Asignación Pobre. Las personas Bueno. Los Bueno. Se imprimieron Regular. Los Pobre. Hubo Pobre. Ésta no fue
heurística que asignan la sangre informes se en el banco de sangre. administradores demasiadas personas una meta inmediata
Falla desconfían de los proporcionaron responsables de involucradas con los de la región del
misteriosos números una hora antes de asignar a diario la inventarios de sangre banco de sangre.
producidos por la que se tomaran sangre recibieron el para participar en el Los costos de envío
computadora. las decisiones. original. diseño del sistema. se pasaron a los
pacientes.
FIGURA 16.18
Evaluación de información de inventario de sangre y de un sistema de soporte de
decisiones mediante el enfoque de utilidad de un sistema de información.
UTILIDAD DE POSESIÓN La utilidad de posesión responde la pregunta de quién debe recibir la salida o, dicho de otro
modo, quién debe ser responsable de tomar las decisiones. La información no tiene valor en posesión de alguien
que carece de poder para hacer mejoras en el sistema o carece de habilidad de usar la información en forma
productiva.
UTILIDAD DE FORMA La utilidad de forma responde la pregunta de qué tipo de salida se distribuye al encargado
de tomar decisiones. Los documentos deben ser útiles para una persona específica encargada de tomar decisiones
en lo que se refiere al formato y a la jerga del documento usados. Los acrónimos y títulos de columna deben
ser significativos para el usuario. Además, la información debe estar en un formato apropiado. Por ejemplo, el
usuario no debe tener que dividir un número entre otro para obtener un porcentaje. En cambio, un porcentaje
se debe calcular y desplegar claramente. Al otro extremo está la presentación de muchos datos irrelevantes. La
sobrecarga de información ciertamente disminuye el valor de un sistema de información.
UTILIDAD DE LUGAR La utilidad de lugar responde la pregunta de dónde se distribuye la información. La
información se debe entregar en el lugar donde se tomó la decisión. Se deben archivar o almacenar informes más
detallados o informes de administración anteriores para facilitar el acceso futuro.
UTILIDAD DE TIEMPO La utilidad de tiempo responde la pregunta de cuándo se distribuye la información. La
información debe llegar antes de que se tome una decisión. La información retrasada no tiene utilidad. Al otro
extremo está la entrega de información mucho tiempo antes de la decisión. Los informes se podrían volver
inexactos o podrían olvidarse si se entregaron prematuramente.
UTILIDAD DE ACTUALIZACIÓN La utilidad de actualización está relacionada con cómo el encargado de tomar
decisiones introduce la información y la utiliza. Primero, el sistema de información tiene valor si posee la
www.xlibros.com
548 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U LT O R Í A 16.6
habilidad de ser implementado. Segundo, la utilidad de actualización implica que un sistema de información
tiene valor si se mantiene después de que sus diseñadores se van, o si un usuario que utilice por una sola vez el
sistema de información obtiene resultados satisfactorios y duraderos.
UTILIDAD DE OBJETIVO La utilidad de objetivo responde el “porqué” de los sistemas de información al preguntar
si la salida tiene el valor de ayudar a la organización a cumplir sus metas. El objetivo del sistema de información
no sólo debe estar en línea con los objetivos de los encargados de tomar decisiones, sino que también debe
reflejar sus prioridades.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 549
FIGURA 16.19
Ejemplo de un informe de
Webtrends Corporation que
muestra los archivos que más se
descargaron en el sitio Web
corporativo.
3. Averigüe más sobre los visitantes del sitio Web La demografía e información del visitante —tal como el
número de visitas por un visitante particular en un periodo, si el visitante es nuevo o es uno que está
regresando, y quiénes son los visitantes más frecuentes— es información valiosa al evaluar un sitio Web. La
pantalla en la figura 16.20 muestra el número de los visitantes únicos (gráfico superior), el número de
visitantes que realizan su primera visita (gráfico medio) y la duración media de las visitas (gráfico inferior).
4. Descubra si los visitantes pueden completar adecuadamente los formularios que diseñó Si el porcentaje de
error es alto, rediseñe el formulario y vea lo que sucede. El análisis de las estadísticas revelará si un mal
diseño de formulario puede ser culpable por los errores en las respuestas.
5. Averigüe quién envía a los visitantes del sitio Web al sitio del cliente Averigüe cuáles sitios son
responsables de enviar a los visitantes al sitio Web del cliente. Consiga estadísticas de los sitios que le han
enviado más tráfico, los motores de búsqueda más efectivos e incluso las palabras clave que los visitantes
usaron para localizar el sitio Web de su cliente. Después de promover un sitio, puede usar el análisis de
tráfico Web para rastrear si la promoción del sitio realmente representó una diferencia.
FIGURA 16.20
Informe que compara las
estadísticas de los visitantes
generadas por Commerce Trends
(de Webtrends Corporation).
www.xlibros.com
550 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
6. Determine qué navegadores están usando los visitantes Sabiendo qué navegadores se están usando, puede
agregar características de un navegador específico que mejoren la apariencia y el funcionamiento del sitio, y
animen a los visitantes a quedarse más tiempo, con lo cual mejora la lealtad del sitio. Esto ayuda a saber si
los visitantes están usando navegadores actuales o anticuados.
7. Averigüe si los visitantes del sitio Web del cliente están interesados en la publicidad Por último, averigüe si
los visitantes del sitio están interesados en las campañas publicitarias que tiene en su sitio, tal como ofrecer
un descuento especial a productos por un periodo específico.
Los servicios de monitoreo de actividad Web pueden ser útiles al evaluar si el sitio está cumpliendo con
sus objetivos en lo que se refiere al tráfico, a la efectividad de la publicidad, la productividad del empleado y el
retorno sobre la inversión. Ésta es una de las maneras en que un analista puede evaluar si la presencia Web cor-
porativa está cumpliendo con las metas fijadas por la gerencia y si se cumple con precisión con la visión de la
organización.
RESUMEN
El analista de sistemas puede asegurar la administración de la cinco símbolos para ayudar a dibujar diagramas de descompo-
calidad total (TQM) para analizar y diseñar sistemas de infor- sición de red y de conectividad de concentradores.
mación de muchas formas. Seis Sigma es una cultura, filosofía, La capacitación de usuarios y personal para interactuar con
metodología y un enfoque para la calidad que tiene como meta el sistema de información es parte importante de la implemen-
la eliminación de todos los defectos. Una herramienta para tación, debido a que los usuarios generalmente deben poder
diseñar un sistema con un enfoque descendente y modular se ejecutar el sistema sin la intervención del analista. La conver-
denomina diagrama de estructura. La arquitectura orientada sión es el proceso de cambiar del sistema de información viejo
a servicios es una metodología que utiliza servicios indepen- al nuevo. Las cinco estrategias de conversión son conversión
dientes para realizar varias funciones. Dos de las técnicas es- directa, conversión paralela, conversión por fases o gradual,
tructuradas que pueden ayudar al analista de sistemas son los conversión modular y conversión distribuida. La investigación
manuales de procedimientos y FOLKLORE. Los analistas de sugiere que los analistas pueden mejorar la probabilidad de que
sistemas deben elegir una técnica que se adapte bien a lo que se se acepten los sistemas recién implementados si desarrollan
utilizaba anteriormente en la organización; además debe permi- sistemas teniendo en cuenta metáforas organizacionales predo-
tir flexibilidad y una fácil modificación. minantes.
La prueba de programas específicos, subsistemas y siste- La seguridad de datos y sistemas ha cobrado mayor im-
mas totales es esencial para la calidad. El mantenimiento del portancia para los analistas que diseñan más aplicaciones de
sistema es una consideración importante. Los auditores inter- comercio electrónico. La seguridad tiene varias facetas —fí-
nos y externos se usan para determinar la fiabilidad de la in- sica, lógica y conductual— que deben trabajar en conjunto. Los
formación del sistema. Ellos comunican sus resultados de la analistas pueden tomar varias precauciones, tal como software
auditoría a otros para mejorar la utilidad de la información del antivirus, filtrado de correo electrónico, filtros URL, firewalls,
sistema. gateways, redes privadas virtuales, productos de detección de
La implementación es el proceso de asegurar que los siste- intrusión, nivel de sockets seguros, transacción electrónica
mas de información y las redes sean funcionales y después in- segura y el uso de una infraestructura de clave pública para
volucrar a los usuarios bien capacitados en su operación. En los mejorar la privacidad, confidencialidad y seguridad de siste-
proyectos grandes de sistemas, el papel principal del analista es mas, redes, datos, individuos y organizaciones. Además, toda
vigilar la implementación, estimando correctamente el tiempo empresa para la cual usted diseñe una aplicación de comercio
necesario, y después supervisar la instalación del equipo para electrónico debe adoptar una política de privacidad con base en
los sistemas de información. cinco lineamientos.
Los sistemas distribuidos aprovechan la tecnología de las Incluso cuando se tomen todas las medidas posibles para
telecomunicaciones y de administración de bases de datos para asegurar la seguridad, privacidad y estabilidad del sistema,
interconectar a las personas que manipulan algunos de los mis- todos los empleados y sistemas son vulnerables a los desas-
mos datos de formas significativas pero diferentes. Conforme se tres naturales o provocados por los humanos. La recuperación
evalúan el hardware y software, el analista de sistemas también de los desastres se concentra en la forma en que una empresa
necesita considerar los costos y beneficios de emplear un sis- puede continuar después de sufrir un desastre y cómo puede
tema distribuido para satisfacer los requerimientos del usuario. restaurar la infraestructura esencial de TI.
Una de las formas más populares de acercarse a los sistemas Hay muchos enfoques de evaluación disponibles, inclu-
distribuidos es mediante el uso de un modelo cliente-servidor. yendo el análisis costo-beneficio, el enfoque de evaluación de
La computación en nube permite dar servicio al comercio, las decisión revisada y las evaluaciones de la participación del usua-
aplicaciones y el almacenamiento de datos mediante Internet. rio. El marco de referencia de la utilidad del sistema de infor-
Los tipos estándar de redes organizacionales incluyen la red de mación es una forma directa de evaluar un nuevo sistema con
área local (LAN) y la red de área amplia (WAN). Mediante la base en las seis utilidades de posesión, forma, lugar, tiempo,
metodología descendente (top-down) los analistas pueden usar actualización y objetivo.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 551
PREGUNTAS DE REPASO
1. ¿Cuáles son las tres metodologías amplias disponibles para que el analista de sistemas obtenga calidad en los sistemas
recién desarrollados?
2. ¿Qué o quién es el factor más importante para establecer y evaluar la calidad de los sistemas de información o sistemas
de soporte de decisiones? ¿Por qué?
3. Defina la metodología de administración de la calidad total (TQM) según su aplicación al análisis y diseño de sistemas
de información.
www.xlibros.com
552 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
PROBLEMAS
1. Uno de los miembros de su equipo de análisis de sistemas ha estado desalentando los comentarios de los usuarios
sobre los estándares de calidad, argumentando que debido a que ustedes son los expertos, realmente son los únicos
que saben lo que constituye un sistema de calidad. En un párrafo, explique al miembro de su equipo por qué es
importante obtener las opiniones de los usuarios para la calidad del sistema. Use un ejemplo.
2. Escriba una tabla de contenido detallada para un manual de procedimientos que explique a los usuarios cómo conectarse
a la red de cómputo de su escuela, así como también las políticas de la red (quién es un usuario autorizado, etc.).
Asegúrese de que el manual se escriba pensando en el usuario.
3. Su equipo de análisis de sistemas está cerca de completar un sistema para Meecham Feeds. Roger está bastante seguro
de que los programas que ha escrito para el sistema de inventario de Meecham funcionarán como se requiere, debido a
que son similares a los programas que ha hecho antes. Su equipo ha estado muy ocupado y le gustaría empezar a realizar
la prueba completa de sistemas tan pronto como sea posible. Dos miembros jóvenes de su equipo han propuesto lo
siguiente:
a. Omitir la verificación de escritorio de los programas (debido a que programas similares se verificaron en otras
instalaciones; Roger está de acuerdo).
b. Hacer la prueba de vínculos con grandes cantidades de datos para comprobar que el sistema funcionará.
c. Hacer la prueba completa de sistemas con grandes cantidades de datos reales para demostrar que el sistema está
funcionando.
Responda a cada uno de los tres pasos del programa de prueba propuesto. Explique su respuesta en un párrafo.
4. Proponga un plan de pruebas modificado para Meecham Feeds (problema 3). Divida su plan en una secuencia de pasos
detallados.
5. Dibuje una red de área local, o alguna otra configuración de procesamiento distribuido que use el enfoque cliente/
servidor, para resolver algunos de los problemas con la compartición de datos que está teniendo la compañía de
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 553
construcción Bakerloo Brothers. La empresa quiere que equipos de arquitectos trabajen en diseños en la oficina
principal, permitir al supervisor de la construcción introducir los cambios de último momento a los planos de obras en
proceso y permitir a clientes ver los diseños casi en cualquier parte. Actualmente, la compañía tiene una LAN para los
arquitectos que están en una ciudad (Filadelfia) que les permite compartir algunas herramientas de dibujo y cualquier
actualización que los miembros del equipo hacen con los arquitectos en otras ciudades (Nueva York, Terre Haute,
Milwaukee, Lincoln y Vancouver). El supervisor usa una computadora portátil, no puede hacer ningún cambio y no se
conecta a una base de datos. Los clientes ven los diseños en las pantallas, pero los representantes de ventas no pueden
introducir las modificaciones para mostrarles lo que pasaría si una pared se moviera o si se alterara una línea del tejado
(Sugerencia: Mencione los problemas que la compañía está encontrando, analice los síntomas, piense en una solución y
después empiece a dibujar.). Se podría necesitar más de una red y no todos los problemas se prestan a una solución de
sistemas.
6. Cree un plan de recuperación de desastres para una de las redes que recomendó a Bakerloo Brothers en el problema 5.
7. Cramtrack, el sistema de tren regional, está intentando capacitar a los usuarios de su sistema de cómputo recién
instalado. Para que los usuarios obtengan la capacitación adecuada, los analistas de sistemas involucrados con el
proyecto enviaron un memorándum a los jefes de los cuatro departamentos que incluye a usuarios principales y
secundarios. El memorándum decía en parte, “Sólo las personas que sienten que requieren capacitación necesitan hacer
las reservaciones para la capacitación externa; todos los demás deben aprender el sistema conforme trabajen con él”.
Sólo se inscribieron 3 usuarios de 42 posibles. Los analistas están satisfechos de que el memorándum separó
eficazmente a las personas que necesitan la capacitación de aquellos que no la necesitan.
a. En un párrafo, explique qué puede estar mal en el enfoque que los analistas siguieron para capacitar.
b. Delinee los pasos que seguiría para asegurar que las personas correctas de Cramtrack están capacitadas.
c. En un párrafo sugiera cómo se debería usar la Web para ayudar en la capacitación para Cramtrack.
8. Al escritorio de Bill Cornwell llegó un atractivo y colorido folleto donde se describe el programa de capacitación externa
y las instalaciones de la Benny Company en términos muy favorables, mostrando usuarios felices frente a sus PC e
instructores profesionales atendiéndoles con aspecto interesado. Bill se dirigió agitadamente hacia la oficina de Roseann
y le dijo: “Tenemos que contratarlos. ¡Este lugar se ve excelente!”. Roseann no se convenció por el folleto, pero no supo
qué decir en defensa de la capacitación interna para usuarios que ella ya había autorizado.
a. En unas frases, ayude a Roseann a argumentar la utilidad de la capacitación interna con instructores internos en
comparación con la capacitación externa con instructores contratados externamente.
b. Si Bill se decide por la capacitación de la Benny Company, ¿qué debe hacer para verificar que esta compañía sea de
hecho el lugar correcto para capacitar a los usuarios del sistema de información de la compañía? Haga una lista de
acciones que deba seguir.
9. “Sólo un poco más... Quiero estar seguro que está trabajando correctamente antes de que cambie de opinión”, dice
Buffy, la dueña de tres boutiques de accesorios de baño de nombre Tub’n Stuff. Su contador, quien le ayudó a establecer
un nuevo sistema de información de contabilidad, está intentando desesperadamente persuadir a Buffy de migrar
completamente hacia el nuevo sistema. Buffy ha insistido en ejecutar los sistemas antiguo y nuevo en paralelo durante
un año entero.
a. Describa brevemente los problemas generales involucrados al usar una estrategia de conversión paralela para
implementar un nuevo sistema de información.
b. En un párrafo, intente convencer al dueño de Tub’n Stuff de que un año para ejecutar un sistema en paralelo es
mucho tiempo. Sugiera una forma de acabar los sistemas duales de Tub’n Stuff que proporcione bastante certeza a
Buffy (asuma que el nuevo sistema es confiable).
10. Delinee un plan para realizar el análisis de tráfico Web para la aplicación de comercio electrónico desarrollada para
Marathon Vitamin Shops (consulte las Oportunidades de consultoría 1.1, 13.2 y 14.6 para conocer más sobre la
organización, sus productos y sus objetivos). Su diseño debe tomar la forma de un informe escrito para el dueño de la
cadena, Bill Berry. Asegúrese de indicar qué estadísticas supervisará y por qué es importante que Marathon Vitamin
Shops las conozca.
11. FilmMagic, una cadena de tiendas de renta de video, está experimentando con agregar un nuevo servicio basado en Web
a su tienda (similar a www.netflix.com) que podría, por una cuota mensual, permitir a clientes escoger una lista de
DVD, prepararlos para enviarlos a su casa y regresarlos en un sobre prepagado cuando los hayan visto. Con base en lo
que sabe de FilmMagic, escriba una política de privacidad corporativa que funcionaría bien en su sitio Web
recientemente propuesto. Cree una pantalla de prototipo (con un paquete de gráficos o un procesador de texto) que
incluya lenguaje apropiado, fuentes e iconos para mostrar cómo aparecerá su política como una página en el sitio Web
de FilmMagic.
12. Ayman’s Office Supplies Company mandó instalar hace poco un nuevo sistema de información para ayudar a sus
gerentes con el inventario. Al con ellos, usted observa que parecían enfadados con la salida del sistema, una serie de
pantallas que muestran el inventario actual, direcciones del cliente y proveedor, y otros datos. Se necesita acceder a todas
las pantallas a través de varios comandos especiales y el uso de una contraseña. Los gerentes tuvieron varias opiniones
sobre el sistema pero no tuvieron ninguna forma sistemática de evaluarlo.
a. Invente una lista de control o formulario que ayude a los gerentes de Ayman a evaluar las utilidades de un sistema de
información.
b. Sugiera una segunda forma de evaluar el sistema de información. Compárela con lo que hizo en el problema 12a.
www.xlibros.com
554 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
PROYECTOS EN GRUPO
1. Nicholas Ventola es director general del mundialmente famoso restaurante Le Corked. Su sistema de información se
desarrolló con el tiempo y, en la actualidad, consta de dos sistemas de cómputo que no se comunican entre sí. Un
sistema se encarga de las reservaciones y mantiene una base de datos de las preferencias de los clientes (gustos y
aversiones), fechas y aniversarios, y demás información. El otro sistema asigna cada grupo de comensales a una mesa en
una noche dada. En su grupo utilice una metodología descendente para identificar los módulos necesarios para realizar
todo lo que Nicholas quiere hacer con sólo un sistema de cómputo, desde hacer reservaciones hasta ordenar comida. Con
base en su propia experiencia, determine qué sistemas son necesarios para operar un establecimiento de cenas de lujo y
después describa los módulos, además de cómo y cuándo los utilizaría.
2. Divida su grupo en dos subgrupos; uno debe entrevistar a los miembros del otro sobre sus experiencias al registrarse en
una clase. Se debe diseñar preguntas para obtener información sobre costumbres, relatos, proverbios y formas artísticas
que ayudarán a documentar el proceso de registro de su escuela.
3. Reúna a su grupo para desarrollar una página Web para un extracto de un manual de FOLKLORE que documente el
proceso de registro para una clase, basado en el FOLKLORE que se utilizó en las entrevistas del proyecto en grupo 2
antes mencionado. Recuerde incluir ejemplos de costumbres, relatos, proverbios y formas artísticas.
BIBLIOGRAFÍA SELECCIONADA
Evans, J. R. y W. M. Lindsay. An Introduction to Six Sigma and Process Improvement. Florence, KY: Cengage Learning,
2004.
Hecht, J. A. “Business Continuity Management”. Communications of the AIS, Vol. 8, artículo 30, 2002.
Juran, J. M. Managerial Breakthrough. Nueva York: McGraw-Hill, 1964.
Kendall, J. E. y K. E. Kendall, “Metaphors and Methodologies: Living Beyond the Systems Machine”, MIS Quarterly, Vol. 17,
Núm. 2, junio de 1993, pp. 149-171.
Kendall, K. E. “Evaluation of a Regional Blood Distribution Information System”. International Journal of Physical Distribu-
tion and Materials Management, Vol. 10, Núm. 7, 1980.
Kendall, K. E., J. E. Kendall y K. C. Lee. “Understanding Disaster Recovery Planning through a Theatre Metaphor: Rehearsing
for a Show That Might Never Open”. Communications of AIS, Vol. 16, 2005, pp. 1001-1012.
Kendall, K. E. y R. Losee, “Information System FOLKLORE: A New Technique for System Documentation”, Information and
Management, Vol. 10, Núm. 2, 1986, pp. 103-111.
Kobieulus, J. “Above the Cloud”, Network World, diciembre 15 de 2008, p. 22. www.networkworld.com. Último acceso en 26
de agosto de 2009.
Stephens, D. O. “Protecting Records in the Face of Chaos, Calamity and Cataclysm”, The Information Management Journal,
enero/febrero de 2003, pp. 33-40.
Warkentin, W., R. S. Morse, E. Bekkering y A. C. Johnston. “Analysis of Systems Development Project Risks: An Integrative
Framework. The DATA BASE for Advances in Information Systems, Volumen 40, Número 2, mayo de 2009, pp. 8-21.
Wikipedia, the free encyclopedia, “Cloud Computing”. Último acceso en 26 de agosto de 2009.
Zmud, R. W. y J. F. Cox, “The Implementation Process: A Change Approach”, MIS Quarterly, Vol. 3, Núm. 2, 1979, pp.
35-44.
www.xlibros.com
CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 555
EPISODIO 16
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Semper Redundate
Mack Roe se dirige hacia el escritorio de Anna, donde también se encuentra Chip, y dice: “Se ha probado el último programa
e incorporado a la prueba del sistema. Los resultados indican que el sistema está terminado. Todos los programas y subsistemas
funcionan de la manera como se planeó. Todo el sistema se revisó en detalle. Las pruebas han sido extensas y precisas, y todos
los problemas y errores se han resuelto de manera satisfactoria. He revisado todo lo que se debía entregar, y todo se desarrolló
en los programas. Los dejo que lo instalen y que después celebren”.
“¡Esto es grandioso!”, exclama Anna cuando Mack se aleja. “Hemos estado esperando mucho este momento. Ahora tene-
mos la tarea de instalar el sistema. Ya revisé con Mike Crowe: ya llegó todo el hardware y está instalado. Las computadoras se
conectaron en una configuración de estrella, y ya se instaló el software de red. ¿Por qué no hacemos una lista de las tareas que
debemos realizar?”.
“De acuerdo”, responde Chip. “Tenemos que capacitar a los usuarios en el manejo del sistema. Sería bueno ofrecer primero
una capacitación general, y luego la capacitación específica para cada usuario. Tal vez sea necesario que capacitemos a varias
personas —al usuario y a alguien que lo sustituya— para cada operación específica.”
“Me parece bien”, contesta Anna, “pero no creo que sea conveniente un sustituto para Paige Prynter. No creo que a ella le
agrade la idea”.
“Hablando de sustitución”, agrega Chip, “¿qué hay de la creación de respaldos de las tablas maestras de la base de datos
y otras tablas? Deberíamos diseñar algún procedimiento automatizado para crear estas copias”.
“Sí”, responde Anna. “Excelente idea. También debemos ocuparnos de la seguridad del sistema: quién puede acceder a los
datos, y quién puede actualizar los diversos elementos de la base de datos. También deberíamos crear un plan de recuperación de
desastres, sólo en caso de que ocurran cosas como cortes de energía u otros desastres naturales o provocados por los humanos”.
“De acuerdo”, subraya Chip. “Uno nunca sabe cuando las cosas pueden salir mal. Otro pendiente es convertir al nuevo
formato los archivos de producción del sistema anterior. No necesitamos volver a teclear todos los registros de los archivos
maestros de hardware y software.”
“¿Por qué no encargamos a uno de los programadores que escriba un programa único que convierta al nuevo formato cada
uno de los archivos del formato viejo?”, sugiere Anna. “Los índices se podrían actualizar automáticamente, y los campos adi-
cionales se podrían inicializar con espacios o ceros”.
Los programadores terminan en poco tiempo los programas de conversión de archivos. Las nuevas tablas de la base de
datos se crean y su exactitud se verifica con gran detalle. Este esfuerzo se ve recompensado con nuevas tablas que contienen
todas las filas necesarias con información correcta.
La capacitación se programa para comenzar en el Centro de Información. Hy Perteks tiene mucha disposición para dedicar
tiempo a la instalación del software y a impartir las sesiones de capacitación. Chip y Anna se alternan para dar capacitación en
las respectivas áreas del sistema que crearon.
Al finalizar las sesiones de capacitación, la última tarea consiste en la conversión del sistema viejo al nuevo. Se elige el
método de fases como el mejor enfoque. Primero se instalan los programas en el hardware. Los registros se actualizan con in-
formación para los elementos adicionales que se incluyeron en el diseño del sistema.
A continuación, se instalan los programas de actualización del software. Una vez más, se introducen actualizaciones a las
tablas de las bases de datos. Cuando los registros contienen toda la información necesaria, se instalan las pantallas de consulta.
Por último, se agregan al sistema los programas de informes y menús.
“La instalación es un éxito redondo”, se regocija Chip. “Todo funciona correctamente, sin un error en el sistema. Creo que
deberíamos tocar madera. ¿Te han comentado algo los usuarios?”.
“Sí”, responde Anna. “Están felices y aliviados por contar con su nuevo sistema. Mike Crowe ya empezó a utilizar la ca-
racterística de mantenimiento preventivo, y puso a sus estudiantes a que le ayudaran a realizarlo en un salón de laboratorio a la
vez. Cher y Dot han ejecutado las diversas pantallas y varias veces han elogiado lo fácil que es realizar sus tareas. Visité a Paige
Prynter, y me pidió que le sugiriera qué hacer con todo el tiempo libre que le queda.”
“Entiendo que el sistema Web está disponible a través del portal de maestros. Se enviaron avisos por correo electrónico
sobre la disponibilidad del sistema Web y las sesiones de capacitación”.
Los analistas sonríen. Chip dice: “En realidad ha sido bueno trabajar en este proyecto”.
“Así es”, responde Anna. “El mejor sistema que hemos creado aquí en la CPU.”
“También he aprendido mucho de la universidad en mi breve estancia aquí. Es un buen lugar para trabajar”, dice Chip con
filosofía.
“Y si recuerdas nuestro lema, debes hacerlo bien”, responde Anna. “Semper redundate”, le dice a Chip.
“Sí, lo veo en todos los membretes. Sin embargo, admito que nunca tomé latín en la escuela. ¿Qué significa este lema?”,
pregunta Chip.
“¡Respalda siempre!”, dice Anna con seguridad.
www.xlibros.com
556 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
EJERCICIOS
E-1. Describa los procedimientos que deben diseñarse para crear archivos de respaldo de manera automática. Explique en un
párrafo los pros y contras de estos procedimientos.
E-2. Mencione las medidas de seguridad que deben tomarse para impedir que personas no autorizadas utilicen el sistema de
cómputo.
E-3. Describa un plan de recuperación de desastres para el nuevo sistema de cómputo que acaba de crear para la CPU. Haga
un énfasis especial en los equipos que serán responsables de manejar una crisis.
E-4. Explique en un párrafo por qué se utilizaría una conversión en fases para instalar el sistema de cómputo.
www.xlibros.com
GLOSARIO
Los números entre paréntesis hacen referencia al capítulo en ALMACÉN DE DATOS Datos que se almacenan en el
el que se define el término. sistema; se representa mediante un rectángulo con un
ACOPLAMIENTO DE DATOS Representación de la extremo abierto en los diagramas de flujo de datos. (7).
forma de pasar los datos entre dos módulos en un diagrama ALMACÉN DE DATOS CORPORATIVO Una colección
(o gráfico) de estructura. (16) de datos de apoyo de los procesos de decisión administrativos
ACTOR En UML, el rol específico de un usuario del que está orientada al tema, integrada, varía con el tiempo y es
sistema. El actor existe fuera del sistema e interactúa con el no volátil. (14) Vea también minería de datos.
mismo de una manera específica. Un actor puede ser un ANÁLISIS DE PUNTOS DE FUNCIÓN Una manera de
humano, otro sistema o un dispositivo tal como un teclado. estimar el tamaño de un proyecto, tomando en cuenta los
(10) Vea también caso de uso. cinco componentes principales de los sistemas
ADMINISTRACIÓN DE LA CADENA DE computacionales: entradas externas, salidas externas,
SUMINISTRO El esfuerzo de una organización por integrar consultas de registros externas, archivos lógicos internos y
a sus proveedores, distribuidores y los requerimientos archivos de interfaz externa. (3)
administrativos de los clientes en un solo proceso unificado. ANALISTA DE SISTEMAS La persona que evalúa de
Las aplicaciones de comercio electrónico pueden mejorar la manera sistemática la forma en que funcionan los negocios,
administración de la cadena de suministro. (16) mediante un examen de la introducción y el procesamiento
ADMINISTRACIÓN DE PROYECTOS El arte y la de los datos y la información de salida con la intención de
ciencia de planificar un proyecto, estimar costos y mejorar los procesos organizacionales y la calidad de la vida
calendarios, administrar el riesgo, organizar y supervisar un útil para los usuarios. (1)
equipo. Existen muchos paquetes de software para apoyar las ÁRBOL DE DECISIONES Un método de análisis para las
tareas de administración de proyectos. (3) decisiones estructuradas; es una metodología apropiada cuando
ADMINISTRADOR DE PROYECTOS La persona es necesario realizar las acciones en cierta secuencia. (9)
responsable de supervisar la planificación, costos, ARQUITECTURA CLIENTE/SERVIDOR Un modelo
calendarios y organización del equipo de un proyecto de diseño en el que las aplicaciones se ejecutan en una red de
(a menudo de sistemas). Con frecuencia este papel lo área local (LAN). Las computadoras en la red dividen las
desempeña un analista de sistemas. (3) tareas de procesamiento entre servidores y clientes. Los
AGREGACIÓN A menudo se describe como relación clientes son máquinas en red que actúan como puntos de
“tiene un” al usar UML para una metodología orientada a entrada en el sistema cliente/servidor. (16)
objetos. Las agregaciones proveen la manera de mostrar que ARQUITECTURA ORIENTADA A SERVICIOS
un objeto está compuesto en su totalidad por la suma de sus (SOA) Crear servicios de software individuales que no estén
partes (otros objetos). (10) asociados o que tengan un acoplamiento débil con algún otro
AJAX Un método que utiliza JavaScript y XML para elemento como aplicaciones o partes de aplicaciones para los
modificar páginas Web en forma dinámica sin tener que usuarios, usando a menudo la Web como plataforma. (16)
mostrar una nueva página, para lo cual obtiene pequeñas ATRIBUTO Cierta característica de una entidad. Puede
cantidades de datos del servidor. (12) haber muchos atributos para cada entidad. (13) Vea también
AJUSTE Describe la forma en que trabajan en conjunto elemento de datos.
los elementos HCI del humano, la computadora y la tarea a BANDERA DE CONTROL Se utiliza en los diagramas
realizar para mejorar el rendimiento y bienestar. (14) (o gráficos) de estructura para gobernar la porción a ejecutar
ALIAS Nombre alternativo para un elemento de datos usado de un módulo; se asocia con instrucciones IF, THEN, ELSE
por distintos usuarios. Se registra en un diccionario de datos. (8) y demás tipos similares de instrucciones. (16)
557
www.xlibros.com
558 GLOSARIO
BASE DE DATOS Un almacén de datos electrónico CLAVE (O LLAVE) CONCATENADA Una clave
definido de manera formal y controlado en forma central, compuesta que se crea cuando no es posible identificar un
para usarse en muchas aplicaciones. (13) registro con sólo utilizar uno de los elementos de datos que
BENEFICIOS INTANGIBLES Beneficios que se se encuentran en él; para elegir una clave se elijen dos o
acumulan en la organización como resultado de un nuevo más elementos de datos y se combinan entre sí. (13)
sistema de información y que son difíciles de medir, como CLAVE (O LLAVE) PRIMARIA Una clave que
mejorar la toma de decisiones, mejorar la precisión y identifica a un registro en forma única. (13) Vea también
volverse más competitivo. (3) Vea también costos clave, clave secundaria.
intangibles, beneficios tangibles, costos tangibles. CLAVE (O LLAVE) SECUNDARIA Una clave que no
BENEFICIOS TANGIBLES Ventajas que se pueden puede identificar a un registro en forma única; se puede
medir en dinero y se acumulan en la organización a través utilizar para seleccionar un grupo de registros que
del uso de los sistemas de información. (3) Vea también pertenezcan a un conjunto. (13)
beneficios intangibles, costos intangibles, costos tangibles. CÓDIGO NEMÓNICO Cualquier código (a menudo
BOTÓN DE OPCIÓN Uno de varios elementos de utilizando una combinación de letras y símbolos) que ayuda
diseño de GUI que provee un botón de opción redondo en al capturista de datos a recordar cómo introducirlos
un cuadro de diálogo. Los botones son mutuamente correctamente, o que ayuda al usuario a recordar cómo usar
excluyentes, debido a que un usuario puede escoger sólo un la información. (15)
botón de opción dentro del grupo de opciones que se COMERCIO ELECTRÓNICO Hacer negocios por vía
visualicen. (11) electrónica, incluyendo el correo electrónico, las tecnologías
CAMPO Una parte física de una base de datos que se Web, BBS, tarjetas inteligentes, EFT y EDI, entre
puede empaquetar con varios elementos de datos; la unidad proveedores, clientes, agencias gubernamentales y otras
más pequeña identificable de datos de la aplicación, empresas para realizar y ejecutar transacciones en
reconocida por el software del sistema. (13) actividades comerciales, administrativas y de los
CARRILES (SWIMLANES) Zonas que se utilizan en los consumidores. (1)
diagramas de actividad para indicar el particionamiento; COMPLEMENTO (PLUG-IN) Software adicional
pueden mostrar qué actividades se realizan en cada (a menudo desarrollado por un tercero) que se puede utilizar
plataforma y qué grupo de usuarios las realiza; también con otro programa; por ejemplo, los complementos Real
pueden representar la lógica del sistema. (10) Player de RealNetworks o Flash de Macromedia se utilizan
CASO DE USO En UML, una secuencia de transacciones en los navegadores Web para reproducir audio o video de
en un sistema; el propósito es producir algo de valor para un flujo continuo y ver animaciones basadas en vectores. (11)
actor en el sistema; se concentra en lo que hace el sistema, COMPORTAMIENTO La forma en que un objeto actúa
en vez de en cómo lo hace. El modelo de caso de uso se basa en y reacciona. (10)
las interacciones y relaciones de casos de uso individuales. CÓMPUTO EN LA NUBE Esquema dentro del cual las
En un caso de uso, un actor que utiliza el sistema inicia un organizaciones y los usuarios individuales utilizan servicios
evento que a su vez empieza una serie relacionada de Web, de bases de datos y de aplicaciones a través de
interacciones en el sistema. (10) Internet (la nube), sin tener que invertir en hardware
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS o software corporativo o personal, o en herramientas de
(SDLC) Una metodología de siete fases para el análisis y software adicionales a las que la Web proporciona. Las
diseño de sistemas, la cual sostiene que los sistemas se empresas utilizan navegadores Web para acceder a las
desarrollan mejor mediante el uso de un ciclo específico de aplicaciones y los servidores almacenan software y datos
actividades de analistas y usuarios. (1) para las empresas. (16)
CIFRADO El proceso de hacer ilegible un mensaje CONSULTAS Preguntas que los usuarios hacen a la base
mediante el uso de una clave, de manera que pueda leerlo de datos en relación con la información que contiene. Cada
sólo el destinatario designado. De esta forma, la persona consulta involucra a una entidad, un atributo y un valor. (14)
designada como receptor del mensaje puede utilizar la clave CONVERSIÓN Convertir físicamente la información del
para descifrarlo y leerlo. (13) sistema antiguo al nuevo sistema. Hay cinco estrategias de
CLASE Una plantilla común para un grupo de objetos conversión: cambio directo, conversión en paralelo, conversión
individuales con atributos y comportamientos comunes en el en fases o gradual, conversión de prototipo modular y
análisis y diseño orientados a objetos, y en el UML. (10) conversión distribuida.
CLASE DE OBJETO Una categoría de objetos similares. COSAS En UML, las cosas describen a los objetos del
Los objetos se agrupan en clases. Una clase define el análisis y diseño orientados a objetos. Los dos agrupamientos
conjunto de atributos y comportamientos compartidos que se de cosas que se utilizan con más frecuencia son las cosas
encuentran en cada objeto de la clase. (10) estructurales y las cosas de comportamiento. (10)
CLAVE (O LLAVE) Uno de los elementos de datos en un COSTOS INTANGIBLES Costos que son difíciles de
registro que se utiliza para identificar al registro. (13) Vea estimar y que tal vez se desconozcan, incluyendo el perder la
también clave primaria, clave secundaria. ventaja competitiva o la reputación de innovador, y deteriorar
www.xlibros.com
GLOSARIO 559
la imagen de la empresa debido a información inoportuna o DIAGRAMA DE FLUJO DE DATOS FÍSICO Un DFD
inaccesible. (3) Vea también beneficios intangibles, que muestra la forma en que se implementará un sistema,
beneficios tangibles, costos tangibles. incluyendo el hardware, software, las personas y los
COSTOS TANGIBLES Los costos en dinero que el analista archivos involucrados. (7) Vea también diagrama de flujo
de sistemas puede pronosticar con precisión, incluyendo el de datos lógico.
costo de las computadoras, los recursos, el tiempo de los DIAGRAMA DE FLUJO DE DATOS LÓGICO Un
analistas y programadores, y los salarios de los demás diagrama que se enfoca en el negocio y la manera en que éste
empleados, para desarrollar un nuevo sistema. (3) Vea también opera; describe los eventos de negocios que se llevan a cabo
beneficios intangibles, costos intangibles, beneficios tangibles. y los datos que cada evento requiere y produce. (7) Vea
CREACIÓN DE PROTOTIPOS Un proceso rápido e también diagrama de flujo de datos, diagrama de flujo de
interactivo entre los usuarios y analistas para crear y refinar datos físico.
porciones de un nuevo sistema; se puede utilizar como parte DIAGRAMA DE NIVEL 0 La expansión
del ciclo de vida del desarrollo de sistemas (SDLC) para (o descomposición) del diagrama de flujo de datos a nivel de
determinar los requerimientos, o como una alternativa para el contexto, que muestra de tres a nueve procesos importantes,
SDLC. (6) Vea también desarrollo rápido de aplicaciones. flujos de datos importantes y almacenes de datos del sistema
DEFINICIÓN DEL PROBLEMA Una declaración formal que se está estudiando. (7)
del problema, incluyendo: 1) aspectos de la situación actual, DIAGRAMA DE OBJETOS Un diagrama similar a los
2) los objetivos para cada cuestión, 3) los requerimientos que diagramas de clase, pero que representa el estado de las
se deben incluir en todos los sistemas propuestos y 4) las instancias de la clase y sus relaciones en un punto en el
restricciones que limitan el desarrollo del sistema. (3) tiempo; muestra los objetos y sus relaciones. También
DESARROLLO RÁPIDO DE APLICACIONES muestra la opcionalidad (el cliente puede tener cero o más
(RAD) Una metodología orientada a objetos para el contratos de renta) y la cardinalidad (el contrato de renta sólo
desarrollo de sistemas, la cual incluye un método de puede tener un cliente). (10)
desarrollo junto con herramientas de software. (6) Vea DIAGRAMA DE SECUENCIA En UML, un diagrama
también creación de prototipos. de secuencia ilustra una sucesión de interacciones entre
DESNORMALIZACIÓN instancias de objetos a través del tiempo. A menudo se utiliza
(O DENORMALIZACIÓN) Definir registros físicos que no para ilustrar el procesamiento descrito en escenarios de casos
estén en la tercera forma normal o en una superior; incluye la de uso. (10)
unión de atributos de varias relaciones entre sí para evitar el DIAGRAMA ENTIDAD-RELACIÓN (E-R) Una
costo de acceder a varios archivos. El particionamiento es representación gráfica de un modelo E-R. (8)
una forma intencional de desnormalización. (13)
DIAGRAMA HIJO El diagrama que resulta al expandir un
DIAGRAMA DE BURBUJA Un diagrama simple que proceso del Diagrama 0 (conocido como proceso padre). (7)
muestra las asociaciones de datos de los elementos de datos.
Cada entidad se encierra en una elipse y se utilizan flechas DIAGRAMA PERT Una herramienta que se utiliza para
para mostrar las relaciones. También se le conoce como determinar las actividades críticas de un proyecto. Se puede
diagrama de modelo de datos. (13) utilizar para mejorar la calendarización de un proyecto y
evaluar su progreso. Significa Técnica de Revisión y
DIAGRAMA DE CLASES Se usa para modelar en forma Evaluación de Programas. (3)
gráfica la vista de diseño estructural estática de un sistema;
ilustra los requerimientos funcionales del sistema recopilados DICCIONARIO DE DATOS Una obra de consulta con
mediante el análisis, así como el diseño físico del sistema. (10) información sobre los datos (metadatos) creados por el
analista de sistemas con base en los diagramas de flujo de
DIAGRAMA DE ESTADOS En UML, una forma de datos; recopila y coordina términos de datos específicos,
refinar aún más los requerimientos. (10) confirmando lo que cada término significa para distintas
DIAGRAMA DE ESTRUCTURA Una herramienta para personas en la organización. (8)
diseñar un sistema modular arriba-abajo, la cual consiste en DIRECCIÓN IP (PROTOCOLO DE INTERNET) El
cuadros rectangulares y flechas de conexión. (16) Vea número que se utiliza para representar una computadora
también bandera de control, acoplamiento de datos. individual en una red. El formato para una dirección IP es
DIAGRAMA DE FLUJO DE DATOS 999.999.999.999. (16)
(DFD) Representación gráfica de los procesos de datos, DISEÑO DE APLICACIÓN CONJUNTA (JAD) La
flujos de datos y almacenes de datos en un sistema metodología propietaria de IBM para las entrevistas de panel
comercial. (7) con analistas, usuarios y ejecutivos para realizar el análisis
DIAGRAMA DE FLUJO DE DATOS A NIVEL DE de requerimientos en forma conjunta. (4)
CONTEXTO El diagrama de flujo de datos más básico de DOCUMENTACIÓN Material escrito creado por el
una organización; muestra la forma en que los procesos analista que describe la forma de ejecutar el software,
transforman los datos entrantes en información saliente. muestra las generalidades del sistema o detalla el código del
También se le conoce como modelo ambiental. (2) Vea programa utilizado. Los analistas pueden utilizar una
también diagrama de flujo de datos. herramienta CASE para facilitar la documentación. (16)
www.xlibros.com
560 GLOSARIO
www.xlibros.com
GLOSARIO 561
eliminan la necesidad de programar el sistema. (1) Vea Cierta parte del mantenimiento se puede realizar de manera
también herramientas CASE. automática al conectarse al sitio Web del distribuidor. (1)
HIPERVÍNCULO Cualquier palabra resaltada en un MASHUPS Una nueva aplicación que se crea al combinar
sistema de hipertexto que muestra otro documento cuando el dos o más API (interfaces de programación de aplicaciones)
usuario hace clic en ella. (11) basadas en Web.
ICONO Pequeña imagen que representa una actividad y MENÚ DESPLEGABLE Uno de varios elementos de
función, u otro elemento de un sistema operativo como un diseño de GUI que provee un menú en pantalla de opciones
archivo o un directorio, disponible para los usuarios cuando de comandos que aparecen una vez que el usuario selecciona
la activen, a menudo mediante un clic del ratón. Se usa con el nombre del comando en una barra de menús. (14) Vea
frecuencia en el diseño de GUI. (14) también lista desplegable.
IMPLEMENTACIÓN La última fase del ciclo de vida del MÉTODO En UML, una acción que se puede solicitar de
desarrollo de sistemas, en la cual el analista asegura que el cualquier objeto de la clase; los procesos que una clase sabe
sistema está en operación y después permite a los usuarios cómo realizar. (10)
hacerse cargo de su operación y evaluación. (16)
METODOLOGÍA ÁGIL (O MODELADO ÁGIL) Una
INGENIERÍA DE SOFTWARE APOYADA POR metodología de desarrollo de sistemas que tiene valores,
COMPUTADORA (CASE) Herramientas de software principios y prácticas útiles para los analistas de sistemas que
especializadas que incluyen capacidades de diagramación, desean una metodología flexible, interactiva y participativa.
análisis y modelado automatizados basados en computadora. (1) (6) Vea también programación extrema.
INTERACCIÓN HUMANO-COMPUTADORA METODOLOGÍA DE DESARROLLO DE
(HCI) El aspecto que permite la comunicación y las SISTEMAS Cualquier metodología aceptada para analizar,
interacciones entre los humanos y la computadora; la capa de diseñar, implementar, probar, mantener y evaluar un sistema
la computadora entre los humanos y la computadora. (14) de información. Algunos ejemplos de metodologías son:
INTERFAZ DE LENGUAJE DE COMANDOS Un tipo SDLC, metodologías ágiles, y el análisis y diseño de
de interfaz que permite a los usuarios controlar la aplicación sistemas orientados a objetos. (1) Vea también ciclo de vida
con una serie de pulsaciones de teclas, comandos, frases o del desarrollo de sistemas.
alguna combinación de estos métodos. (14) MINERÍA DE DATOS Técnicas que aplican algoritmos
INTERFAZ DE LENGUAJE NATURAL Una interfaz para extraer patrones de datos guardados en almacenes de
que permite al usuario hablar o escribir en un lenguaje datos corporativos que por lo general no son aparentes para los
humano para interactuar con la computadora. (14) humanos que toman las decisiones. También se le conoce
INTERFAZ DE LLENADO DE FORMULARIOS Parte como descubrimiento de conocimiento en bases de datos
de los elementos de diseño de GUI que pide de manera (KDD). (14)
automática al usuario que llene un formulario estándar. Es MODELO DE ACEPTACIÓN DE TECNOLOGÍA
útil para las aplicaciones de comercio electrónico. (14) (TAM) Un método basado en la investigación que permite
INTERFAZ GRÁFICA DE USUARIO (GUI) Una a los analistas organizar su modo de pensar en cuanto a si los
interfaz de usuario basada en iconos, con características usuarios aceptarán y utilizarán la tecnología de información,
como menús y listas desplegables, y botones de opción. (14) incluyendo la utilidad y la facilidad de uso percibidas. (14)
JAVA Un lenguaje de programación orientado a objetos MODELO DE BASE DE DATOS
que permite ejecutar aplicaciones dinámicas en Internet. (11) RELACIONAL Representa a los datos en la base de datos
JUEGO DE PLANEACIÓN Se utiliza en el desarrollo como tablas bidimensionales llamadas relaciones. Mientras
ágil; el juego de planeación establece las reglas que pueden que ambas tablas compartan un elemento de datos común, la
ayudar a formular la relación del equipo de desarrollo ágil base de datos podrá relacionar cualquier otro archivo o tabla
con sus clientes comerciales. (1) con los datos en otro archivo o tabla. (13)
LENGUAJE UNIFICADO DE MODELADO (UML) El MUESTREO Seleccionar de manera sistemática elementos
UML provee un conjunto estandarizado de herramientas para representativos de una población. Los analistas muestrean los
documentar el análisis y diseño orientados a objetos de un datos concretos, los datos de archivo y las personas durante la
sistema de software. (10) determinación de los requerimientos de información. (5)
LÍNEA DE SUSCRIPTOR DIGITAL (DSL) Protocolos NAVEGADOR Software especial que se ejecuta en
que permiten la transmisión de datos de alta velocidad a computadoras conectadas a Internet y permite a los usuarios
través del cable telefónico común. (16) ver páginas Web de hipertexto en Internet. Microsoft Internet
LISTA DESPLEGABLE Uno de varios elementos de Explorer y Mozilla Firefox son ejemplos de navegadores
diseño de GUI que permite a los usuarios hacer clic en un gráficos. (11)
cuadro que parece desplegarse en la pantalla y muestra una NORMALIZACIÓN La transformación de los almacenes
lista de alternativas, de las cuales se puede elegir una. (11) de datos y vistas de usuario complejas en un conjunto de
MANTENIMIENTO El mantenimiento dado al sistema estructuras de datos más pequeñas y estables. Las estructuras
de información para mejorarlo o corregir problemas empieza de datos normalizadas se pueden mantener con más facilidad
en esta fase del SDLC y continúa durante la vida del sistema. que las estructuras complejas. (13)
www.xlibros.com
562 GLOSARIO
OBJETO En la metodología orientada a objetos, un objeto PRIMERA FORMA NORMAL (1NF) El primer paso
es una representación computacional de alguna cosa o evento para normalizar una relación en los datos que se utilizan en
del mundo real; puede tener tanto atributos como una base de datos, de manera que no contenga grupos
comportamientos. (10) repetitivos. (13) Vea también segunda forma normal, tercera
OBSERVACIÓN ESTRUCTURADA DEL ENTORNO forma normal.
(ESTROBO) Un método de observación sistemática para PROCESO Las actividades que transforman o modifican
clasificar e interpretar elementos organizacionales que los datos en un sistema de información. Pueden ser manuales
influyen en la toma de decisiones. Se basa en la técnica de o automatizadas. Se representan mediante un rectángulo
crítica de cine conocida como mise-en-scéne. (5) redondeado en un diagrama de flujo de datos. (2)
ORGANIZACIÓN DE ARCHIVOS INDEXADOS Un PROGRAMACIÓN EN PAREJA Una práctica básica de
tipo de organización de archivos que utiliza archivos índice la metodología ágil, en la que dos programadores eligen
separados para localizar los registros. (13) trabajar juntos en la programación, las pruebas y hablan entre
PANTALLA Cualquiera de una variedad de alternativas de sí sobre las formas de realizar el trabajo con eficiencia y
visualización que emplean los usuarios para ver el software efectividad. (6)
de computadora, incluyendo los monitores y las pantallas de PROGRAMACIÓN EXTREMA (XP) La programación
plasma o de cristal líquido. (11) extrema (XP) es una metodología de desarrollo de sistemas
PAQUETE En UML las cosas se pueden agrupar en que acepta lo que conocemos como buenas prácticas de
paquetes, a los cuales se les puede considerar como desarrollo de sistemas y las lleva a los extremos. Es el
subsistemas físicos. Los sistemas se implementan y génesis de las metodologías ágiles. (3)
despliegan en paquetes. (10) PRONÓSTICO Los analistas de sistemas tienen que
PEGAJOSIDAD Una propiedad de las páginas Web, predecir ciertas variables clave antes de enviar la propuesta
utilizada especialmente en el comercio electrónico. Las del sistema al cliente. El pronóstico es el arte y la ciencia de
herramientas que incrementan la pegajosidad de una predecir las variables clave, que a menudo se apoya en los
página Web son aquellas que alientan a los clientes a modelos matemáticos de pronóstico. (3)
permanecer más tiempo en la página, los ayudan a PROPUESTA DE SISTEMAS Una propuesta escrita que
navegar de vuelta a la página si hacen clic en un vínculo e sintetiza el trabajo del analista de sistemas en el negocio
incrementan la probabilidad de que completen una hasta ese punto, e incluye recomendaciones y alternativas
compra. (14) para resolver los problemas de sistemas identificados. (3)
PENSAMIENTO EN OBJETOS Instrucciones PROVEEDOR DE SERVICIOS DE APLICACIÓN
elementales que el analista escribe en tarjetas CRC para (ASP) Una empresa que hospeda software de aplicación y
empezar a pensar en una forma orientada a objetos. (10) lo renta a otras empresas para usarlo en la Web. Se incluyen
PLANIFICACIÓN DE RECUPERACIÓN DE las aplicaciones tradicionales así como las de colaboración y
DESASTRES Planes estratégicos y tácticos para ayudar a administración de datos. (16)
las personas y los sistemas a recuperarse en caso de desastres PROVEEDOR DE SERVICIOS DE INTERNET
naturales y provocados por los humanos. (16) (ISP) Una empresa que provee acceso a Internet y que
PODCASTING La técnica de colocar archivos de audio puede proveer otros servicios, como el hospedaje Web y el
descargables en la Web. (11) análisis del tráfico Web, por un costo. (12)
POLIMORFISMO Comportamientos alternativos entre PRUEBA DE SISTEMAS La sexta fase en el SDLC
las clases derivadas en las metodologías orientadas a objetos. (junto con el mantenimiento). Usa tanto los datos de prueba
Cuando varias clases heredan tanto atributos como como los datos en vivo en un momento dado para medir los
comportamientos, el comportamiento de una clase derivada errores, la oportunidad de la respuesta, la facilidad de uso, el
podría ser distinto al de su clase base o al de sus clases orden apropiado de las transacciones, el tiempo inactivo
derivadas hermanas. (10) aceptable, la comprensión de los manuales de procedimientos
PREGUNTA ABIERTA Un tipo de pregunta que se utiliza y demás aspectos del nuevo sistema. (16)
en entrevistas o encuestas y que abre el posible conjunto de RECORRIDO ESTRUCTURADO Una revisión
respuestas disponibles para los que responden a las sistemática realizada por expertos en relación con la
preguntas. (4) Vea también pregunta binaria, pregunta programación y el desarrollo del sistema en general, para
cerrada. resaltar los problemas y permitir que el programador o
PREGUNTA BINARIA Un subconjunto de preguntas analista realice las modificaciones apropiadas. (16)
cerradas que se pueden responder sólo de dos formas: sí o RED DE ÁREA LOCAL (LAN) El cableado, hardware y
no, verdadero o falso, y de acuerdo o en desacuerdo. (4) Vea software utilizados para conectar estaciones de trabajo,
también pregunta cerrada, pregunta abierta. computadoras y servidores ubicados en un área geográfica
PREGUNTA CERRADA Un tipo de pregunta que se confinada (por lo general dentro de un edificio o campus). (15)
utiliza en entrevistas o encuestas y que limita el conjunto de RED DIGITAL DE SERVICIOS INTEGRADOS
respuestas disponibles para quienes responden a las preguntas. (ISDN) Un servicio de red conmutada que provee
(4) Vea también pregunta binaria, pregunta abierta. conectividad digital de un extremo a otro para transmitir voz,
www.xlibros.com
GLOSARIO 563
datos y video en forma simultánea a través de una sola línea SISTEMA CERRADO Parte de la teoría general de
en vez de a través de varias. (16) sistemas; un sistema que no recibe información, energía,
REGISTRO Una colección de elementos de datos que personas o materias primas como entrada. Los sistemas
tienen algo en común con la entidad descrita. (13) nunca son totalmente cerrados o totalmente abiertos, sino
que existen en un continuo desde el más cerrado hasta el más
REGLAS DE NEGOCIO Instrucciones específicas para
abierto. (2) Vea también sistema abierto.
el funcionamiento de una organización, que proveen la
descripción lógica de las actividades de negocios. Se utilizan SISTEMA DE ADMINISTRACIÓN DE BASES DE
para ayudar a crear diagramas de flujo de datos. (7) DATOS (DBMS) Software que organiza los datos en una
base de datos; provee la capacidad de almacenamiento,
RELACIÓN Asociación entre entidades (algunas veces se
organización y recuperación de los datos. (13)
le conoce como asociación de datos); puede tomar la forma
de uno a uno, de uno a varios, de varios a uno o de varios a SISTEMA DE INFORMACIÓN GERENCIAL
varios. (13). (MIS) Un sistema de computación compuesto por
REPOSITORIO DE DATOS Una base de datos centralizada personas, software, hardware y procedimientos que
que contiene todos los diagramas, definiciones de formularios e comparten una base de datos común para ayudar a los
informes, estructuras de datos, definiciones de datos, flujos y usuarios a interpretar y aplicar los datos en el negocio. (1)
lógicas de los procesos, y definiciones de otros componentes SISTEMA DE PROCESAMIENTO DE
de la organización y del sistema; provee un conjunto de TRANSACCIONES (TPS) Un sistema de información
mecanismos y estructuras para lograr la integración uniforme computarizado desarrollado para procesar grandes cantidades
de datos con herramientas y de datos con datos. (8) de datos para transacciones de negocios rutinarias, como
RUBY ON RAILS Una combinación de lenguaje de nóminas e inventario. (1)
programación y generador de código para crear aplicaciones SISTEMA DE SOPORTE DE DECISIONES (DSS) Un
Web. (11) sistema de información interactivo que brinda soporte al
RUTA CRÍTICA La ruta más larga calculada mediante la proceso de toma de decisiones a través de la presentación de
técnica de programación PERT; la ruta que provocará el información diseñada de manera específica para la
atraso de todo el proyecto de sistemas si ocurre inclusive un metodología de solución de problemas de la persona que
solo día de retraso . (3) toma las decisiones y las necesidades de la aplicación. No
toma la decisión en lugar del usuario. (1)
SALIDA Información que se entrega a los usuarios a
través del sistema de información mediante intranets, SISTEMA DE SOPORTE PARA EJECUTIVOS
extranets o la Web, en informes impresos, en pantallas o a (ESS) Un sistema computacional que ayuda a los
través de audio. (11) ejecutivos a organizar sus interacciones con el entorno
externo al proveer soporte gráfico y de comunicaciones. (1)
SEGUNDA FORMA NORMAL (2NF) Al normalizar los
datos para una base de datos, el analista se asegura de que SISTEMA EXPERTO (ES) Un sistema de computadora
todos los atributos que no sean claves dependan por completo que captura y utiliza el conocimiento de un experto para
de la clave primaria. Se eliminan todas las dependencias resolver un problema específico. Los componentes básicos
parciales y se colocan en otra relación. (13) Vea también son la base del conocimiento, un motor de inferencia y la
primera forma normal, tercera forma normal. interfaz de usuario. (1)
SEIS SIGMA (SIX SIGMA) Una cultura basada en la SISTEMAS DISTRIBUIDOS Sistemas computacionales
calidad; el objetivo es eliminar todos los defectos. (16) que están distribuidos en forma geográfica, además de que
SEUDOCÓDIGO Una técnica para crear instrucciones de su procesamiento, datos y bases de datos están distribuidos.
computadora que representan el paso intermedio entre el Una arquitectura común para los sistemas distribuidos es el
lenguaje natural y el código del programa; se utiliza para sistema cliente/servidor basado en LAN. (16)
representar la lógica de cada módulo en un diagrama de SISTEMAS EMPRESARIALES Sistemas de
estructura. (16) Vea también diagrama de estructura. información que se integran a nivel de la organización (en
SISTEMA Una colección de subsistemas que están toda la empresa) y que ayudan a las compañías a coordinar
interrelacionados y son interdependientes; trabajan en los procesos organizacionales críticos. (1)
conjunto para lograr metas y objetivos predeterminados. SOFTWARE A LA MEDIDA Otro término para el software
Todos los sistemas tienen entrada, procesos, salida y personalizado; es lo opuesto del software comercial para venta
retroalimentación. Algunos ejemplos son un sistema de en los canales de distribución tradicionales (COTS). Es
información computarizado y una organización. (2) Vea software desarrollado para desempeñar una función específica,
también sistema cerrado, sistema abierto. o dar soporte a una característica única de la organización. (1)
SISTEMA ABIERTO Parte de la teoría general de SOFTWARE DE CÓDIGO FUENTE ABIERTO
sistemas; un sistema que recibe libremente información, (OSS) Modelo y filosofía de desarrollo en relación con la
energía, personas o material prima como entrada. Los sistemas distribución de software de una manera libre y publicando su
nunca son totalmente cerrados o totalmente abiertos, sino que código fuente, para que los usuarios y programadores puedan
existen en un continuo desde el más cerrado hasta el más estudiarlo, compartirlo y modificarlo. El sistema operativo
abierto. (2) Vea también sistema cerrado. Linux es un ejemplo. (1)
www.xlibros.com
564 GLOSARIO
SOFTWARE DE VALIDACIÓN Software que revisa si clave dependen de otros atributos que tampoco son clave.
los datos introducidos en el sistema de información son (13) Vea también primera forma normal, segunda forma
válidos. Aunque la mayor parte de la validación de las normal.
entradas que se realiza a través de software es TIPO DE ENTIDAD Una colección de entidades que
responsabilidad del programador, el analista debe saber qué comparten propiedades o características comunes. (8)
problemas comunes podrían invalidar una transacción. (15)
USUARIOS FINALES En una organización, los que no
SONDEO Preguntas de seguimiento que se utilizan son profesionales de sistemas de información, que
principalmente durante las entrevistas entre los analistas y especifican los requerimientos de negocios para las
los usuarios. (4) Vea también pregunta cerrada, pregunta aplicaciones de software y las utilizan. A menudo, los
abierta. usuarios finales solicitan aplicaciones nuevas o modificadas,
TABLA DE DECISIONES Una forma de examinar, evalúan y aprueban las aplicaciones, y pueden servir en los
describir y documentar las decisiones estructuradas. Se equipos de proyectos como expertos de negocios. (1)
dibujan cuatro cuadrantes para describir las condiciones, VALOR PREDETERMINADO Un valor que asumirá un
identificar las alternativas posibles de decisión, indicar las campo, a menos que se introduzca un valor explícito en éste.
acciones que se deben realizar y describir esas acciones. (9) (13)
TABLERO DE CONTROL Visualizador para los que VALOR PRESENTE La cantidad total que vale una serie
toman decisiones; incluye una variedad de visualizadores de de pagos a futuro en la actualidad; una forma de evaluar los
medidas de desempeño (o rendimiento) relevantes. (11) desembolsos económicos e ingresos del sistema de
TARJETAS CRC El analista crea tarjetas de Clases, información durante su vida económica, y de comparar los
Responsabilidades y Colaboradores para representar las costos hoy en día con los beneficios a futuro. (10)
responsabilidades de las clases y la interacción entre éstas
VOZ SOBRE PROTOCOLO DE INTERNET (VoIP) El
cuando se empieza a modelar el sistema desde una
enrutamiento de los datos de voz a través de Internet. (15)
perspectiva orientada a objetos. Los analistas crean las
tarjetas con base en los escenarios que resumen los WEBMASTER La persona responsable de actualizar y dar
requerimientos del sistema. (10) mantenimiento a un sitio Web; comúnmente, al principio es
el analista de sistemas durante el desarrollo de las
TERCERA FORMA NORMAL (3NF) Una forma en la
aplicaciones de comercio electrónico. (12)
que se eliminan todas las dependencias transitivas. Una
dependencia transitiva es en la que los atributos que no son XP Vea metodología ágil y programación extrema. (6)
www.xlibros.com
ACRÓNIMOS
www.xlibros.com
ÍNDICE
Nota: Los números de página de proyectos y el diseño de entradas, 387-88 Arrendamiento de hardware, 67
seguidos por una f cursiva acerca de, 56 y el particionamiento, 213 Artefactos para UML, 311-12
indican que se trata de una actividades de análisis y y la salida de páginas Web, 358-60 Aseguramiento de calidad,
figura. diseño, 83-88 y los diagramas de secuencia, implementación
análisis de costos y 302-03 acerca de, 515
SÍMBOLOS beneficios, 72-77 Ajuste para HCI, 442-43 auditoría, 529
# (libra), 297 de los proyectos de comercio Alcance, metodología ágil, 170-71 documentación, 523-26
* (asterisco), 246, 304, 414, electrónico, 86 Almacenamiento. Vea Almacenes ejercicios, 551-54
455 ejercicios, 92, 94-98 Almacenes evaluación, 546-48
[ ] (corchetes), 232 estatutos, 87 corporativos de datos, 429-32 de sitios Web corporativos,
{ } (llaves), 231 fracaso, 87-88 de datos 548-50
⫹ (signo de suma), 231, 246, 298, inicio, 56-62 contenido, 236-38 proceso de prueba, 526-28
383 lidiar con la complejidad, 82 desarrollo, 241 y administración de calidad total
« » (comillas angulares), 308 necesidades de hardware y metodologías, 403 (TQM), 516-23
⬍ (menor que), 244 software, 63-72 símbolo, 194f, 195 y capacitación de usuarios,
⫽ (signo de igual), 231, 298 planeación y control de Vea también Diseño de bases de 536-39
⬎ (mayor que), 244, 262, 266, actividades, 77-82 datos y conversión de sistemas,
276, 455, 471 programación de proyectos American Express, 432 539-41
— (guión), 297 mediante diagramas de Análisis y cuestiones de seguridad, 542-44
⫺ (signo de resta), 297 Gantt, 79-80 de costos y beneficios, 72-79, y el desarrollo ágil, 170
() (paréntesis), 232, 298 propuesta de sistemas, 88-91 546 y mantenimiento, 528-29
/ (barra diagonal), 257 selección, 61-62 de flujo de efectivo, 75 y metáforas organizacionales,
uso de diagramas PERT, de punto de equilibrio, 74-75 541-42
A 80-82 de sistemas, 6, 228-58 y planeación de recuperación de
Accesorios (props) de oficina, viabilidad, 62-63 de valor presente, 75-77 desastres, 544-46
145-46 estratégica, 45 Analista de sistemas y sistemas distribuidos, 529-36
Acción del usuario, mínima, Administración de calidad total cualidades, 6 Asignar prioridades, 59
459-60 (TQM) deberes, 1, 10 Asistentes, 464
Acciones arquitectura orientada a derechos, 181 Asociaciones
árboles de decisión, 271-73 servicios (SOA) para, 522-23 habilidades requeridas, 20 como patrones, 431
tablas de decisión, 266-71 metodología modular, 520-22 roles, 6-8 entre clases, 304-05
Actividades comerciales, listado, recorridos estructurados, Anomalía(s) Asterisco (*), 246, 304, 414, 455
207-08, 209f 517-18, 519f de actualización, 426 Atributos
Actores responsabilidad, 516-17 de eliminación, 426 de datos, 34
acerca de, 36-38, 142 y diseño de sistemas de inserción, 426 de entidades, 405-08
ejercicios, problemas, 54 descendente (top-down), en las tablas, 425-26 en clases, 282-83, 303, 306-08
en diagramas conductuales, 518-20 Anuncios, 141 en consultas, 470-471
287-88 y Seis Sigma, 516, 517f Apertura organizacional, 26 en formularios, 417-20
en diagramas de secuencia, Adobe Dreamweaver, 348 Aplicaciones web híbridas, 468 en metodologías O-O, 297-300
294-96, 300 Agente de cambio, 7-8 Árboles de decisiones, 271-73 en UML, 286-87
en el modelado de casos de uso, Agregación, 305 Archivos de transacciones, 410-11 funcionales, 343
17, 41-43, 314 Agrupamiento, como patrón, 431 Archivos maestros, 410, 424-26 modificación, 310-11
Administración Ajax (JavaScript asíncrono y XML) Áreas de texto, 381 que no son claves, 413
de equipos, 83-86 acerca de, 6 Arquitectura orientada a servicios Auditoría de sistemas, 529
de nivel medio, 44 definición, 349f (SOA), 5, 522-23, 533 Ayuda, opciones de, 464
566
www.xlibros.com
ÍNDICE 567
www.xlibros.com
568 ÍNDICE
www.xlibros.com
ÍNDICE 569
www.xlibros.com
570 ÍNDICE
Ley para estadounidenses con Mnemónicos, códigos 490 Normalización solución de sistemas, 546
discapacidades, 449 Modelado diagramas E-R, 421-22 STROBE, 145
Leyendas en un formulario, 372-74 ágil ejemplos, 414-17 tabla de decisiones, 269
Libra (#), símbolo de, 297 acerca de, 155 formularios, 417-21 validación de la entrada, 500
Limitaciones y HCI, 449-50 actividades, 168-69 pasos, 413-14 Orientado a objetos (OO), análisis
Llaves ({ }), 231 ejercicios, problemas, 183-85 y desnormalización, 426-28 y diseño
Llenado de formularios, 371, 389 en comparación con SDLC, Notación algebraica, 231-32 acerca de, 17-19, 281
Luhn, fórmula de, 503-04 14, 19f, 177-79 Número de identificación (ID), clases, 282-83
lecciones de, 175-76 230, 234, 237, 299 diagramas de clases, 297-300
M medir el impacto, 181 diagramas de secuencia, 287,
MAC, atractivo de prácticas básicas, 171, 172f O 288f, 294-96, 300-09
1Password, 392 principios, 168 Objetivos/metas, 85-86, 104 ejercicios y problemas, 318-19,
acerca de, 12 proceso de desarrollo, 15-17, Objetos, 309-10 320-27
Bento, 425 171-75 Observación, 142-48 herencia, 283-84
DEVONagent, 467 riesgos inherentes, 179-81 estructurada del entorno modelado de casos de uso, 287-90
FileMaker Pro, 425 valores, principios, 166-68 (STROBE), 142-49, 152, 154 objeto, definición, 282
Freeway Pro, 351 variables de control de OCLC (centro de bibliotecas de RAD como, 163-66
OmniFocus, 173 recursos, 169-71 cómputo en línea), 495 y tarjetas CRC, 284-86
OmniGraffle, 35 Vea también Prototipos OCR (reconocimiento óptico de
OmniPlan, 83 de aceptación de tecnología caracteres), 496 P
Things, 520 (TAM), 443-44 OLAP (procesamiento analítico en Páginas Web
Yojimbo, 147 de casos de uso línea), 429 dinámicas, 383, 386, 395
Mantenimiento de sistemas, 12-13, alcance del sistema, 38 OmniGraffle, 35 tridimensionales, 385-87
17, 528-29 caso de la CPU sobre, 51-55 Omniplan, 83 Pancartas, 141
Manuales como técnica OO, 287-90 Oportunidades de consultoría Pantalla
de políticas, 141 creación de descripciones administración de equipos, 85 sensible al tacto, 457-58
de procedimientos, 523 para, 43 almacén corporativo de datos, 430 para la salida, 332-33
Mapa definición, 35-36 análisis de costos y beneficios, 78 Papel para la salida, 343
de imágenes, 381 definir, 314 análisis OO, 284, 313, 315 Paquetes, 311-12
del sitio, 466 diagramas, 38, 43 árbol de decisiones, 272 Paréntesis (()), 232, 298
Máscaras (skins) en sitios Web, 390 durante la resolución de aseguramiento de calidad, Particionamiento, 206-07, 213-17
Mayor que (>), símbolo, 244, 262, problemas, 61 implementación, 518 Pata de cuervo, símbolo, 30-31,
266, 276, 455, 471 escenarios, 38-39, 49 capacitación, 538 405-06
Memos, 140-41 formulario, 205f, codificación, 492, 494 Patrones, identificar, 431
Menor que (<), símbolo, 244 niveles, 39-43 consultas de bases de datos, 472 Pegajosidad de los sitios Web, 353
Mensaje, definir, 300 paquetes y artefactos, 311-12 contratar ayuda de comercio Pensamiento en objetos,
Menús, 453-54 relaciones, 36-38 electrónico, 7 instrucciones, 284-86
con rollover, 466 símbolos, 36 copias de archivos, 44 PeopleSoft, 162
Metadatos, 404-10, 411f y DFD, 205-06 cuestionarios, 120, 121 Periodo de retribución, 75, 77
Metáforas, 140-41, 337, 541-42 de espiral, 18-19 decisión estructurada, 263 Persistencia, capa de, 302
Método de eventos, 205, 206f desarrollo de un sitio de PERT, diagramas, 80-82, 97, 101
definir, 300 de redes, 533-35 comercio electrónico, 26 PKI (infraestructura de claves
determinar, 308-11, 314 Módulo administrable, 159 DFD, 216-17 públicas), 544
en clase de UML, 283 Motivación, 86 diccionario de datos, 240 Planeación
estándar y personalizado, 298 Muchos a muchos (M:N), diseño de bases de datos, 404 de recuperación de desastres,
sobrecarga, 298-99 relaciones, 405-06, 423, diseño de formularios, 377, 379 544-46
y salida, 330-40 426-27 documentación, 524 de recursos empresariales
Metodología orientada a objetos Muestra elegir software, 70, 73 (ERP), sistemas de, 5, 28-29
(OOA), 10 compleja, 133 entrada, 390 de requerimientos de materiales
MICR (reconocimiento de estratificada, 133 entrevistas, 108, 110, 113 (MRP), 28
caracteres de tinta intencionada, 133 especificaciones de procesos, y control administrativo, 43-44
magnética), 497 simple, 133 264 Plantillas, 352
Microsoft sistemática, 133 evaluación, 548 Plumilla, 457
Excel, 444-46 Muestreo(s), 132-36 HCI, 466 Polimorfismo, 307
Expression Web, 348 de conglomerados, 133 interfaces, 454, 456, 457 Precisión, 270, 506-08
Visio de conveniencia, 132-33 investigación, 137 Predisposición en la salida, 340-44
caso de la CPU, 51-55, muestreo, 135 Preguntas abiertas
100-01 N problemas de comunicación, 46 acerca de, 105-06
comparación con Navegación prototipos, 159, 160, 161, 162 anticiparse a la respuesta, 115
OmniGraffle, 35 intuitiva, 465 prueba, 528 ejercicios, 125
ilustración, 353f Web, 355-56, 465-68 prueba de validez, 504 ilustración, 116f, 117f
usos, 14 Nivel retroalimentación, 461 Preguntas
Minería de datos, 429-32 de confianza en el muestreo, salida, 335 bipolares, 106-07
Mini especificaciones. Vea 134-35 salida para, 339, 342, 348, 356 cerradas, 106-07, 115, 117f, 125
Especificaciones de procesos de sockets seguros (SSL), 544 solución de problemas, 58 frecuentes (FAQ), 353
www.xlibros.com
ÍNDICE 571
Presentación, capa de, 302 investigación, 136-41 aseguramiento de calidad, de información administrativa
Primera forma normal (1NF), muestreo, 131-36 implementación, 526 (MIS), 3
417-18 observación, 141-48 como audio, 333-34 de procesamiento de
Privacidad y comercio electrónico, Vea también Entrevistas; como CD-ROM, DVD, 334 transacciones (TPS), 2
544 Cuestionarios como tecnología push/pull, de soporte
Procesamiento analítico en línea Recorridos estructurados, 517-18, 336 de decisiones (DSS), 3
(OLAP), 429 519f como video, 333-34 de decisiones en grupo
Proceso Rectángulo, símbolo comparación entre interna y (GDSS), 3-4
padre, 198, 199f con extremo abierto, 194f, 195 externa, 331 para ejecutivos (ESS), 4
primitivo, 198 en diagramas de clases, 297 contenido y método, 330-40 de trabajo de conocimiento, 3
Programación en pareja, 171, 175-76 en diagramas E-R, 407f definición, 329 distribuidos
Programadores, programación preguntas abiertas, 194f, 195 ejercicios y problemas, 361-65 computación en nube, 531-33
derechos, 181 usos, 194-95 electrónica, 334-36 modelado de redes, 533-35
lenguaje, 6 Recursos elegir tecnología, 336-40 tecnología cliente-servidor,
productividad, 316 en la metodología ágil, 176 flujos de datos, 260 529-31
Vea también Orientado a objetos virtualizados, 531 impresa, diseño, 341, 343 ventajas y desventajas,
(OO), análisis y diseño Red, redes impresoras, 331-32 535-36
y retroalimentación, 167 de área amplia (WAN), 531 mensajes, 309 expertos, 3
Pronóstico, 72 de área de almacenamiento objetivos de diseño, 329-30 organizacionales
Propuesta de sistemas, 10-11, (SAN), 545 pantallas, 332-33, 344-47 comprensión, 24
88-91 de área local (LAN), 531 predisposición, 340-44 cultura, 45-46
Protección antivirus, 543 de área local inalámbricas producción y XML, 357-60 diagramas de estado, 309-11
Prototipos (WLAN), 5 Vea también Entrada flujo de datos a nivel de
acerca de, 155-56 de fidelidad inalámbrica y las fuentes RSS, 335 contexto, 29-30
caso de la CPU, 186-91 (Wi-Fi), 5, 339-40, 531 SAN (red de área de interrelación,
como alternativa al SDLC, 157-58 Redundancia de datos, 425 almacenamiento), 545 interdependencia, 25-26
de características seleccionadas, Registro Scrum (melé), 174-75 modelado de casos, 35-43
156f, 157 de longitud variable, 409 Secuencias como patrones, 431 perspectiva, 27-28
de parches, 156 para investigación, 136, 138f Segunda forma normal (2NF), 419 virtuales, 26-27
desarrollo, 158-60 Registros Web, 357 Seguridad y el modelo de entidad-
ejercicios y problemas, 183-85 Regla de los tres clic, 356, 378 acerca de, 542 relación, 30-35
no operacional, 156f, 157 Relaciones conductual, 543 y ERP, 28-29
primero de una serie, 156f, 157 de auto unión, 407 física, 542 y los niveles administrativos,
rol de los usuarios, 159-63 en entidades, 405-08 lógica, 542-43 43-45
tipos, 156-57 Renta de hardware, 67 y comercio electrónico, 543-44 Web, 4-5
Vea también Modelado ágil Replicación remota asíncrona, 545 y partición DFD, 207, 215 Sitios Web
ventajas y desventajas, 160-61 Repositorio, 294 Seis Sigma, 516, 517f corporativos, 141
y software COTS, 161-62 de datos, 229-38 Semana de trabajo de 40 horas, diseñar, 348-56
Proveedor de servicios de Respuesta, 205 171, 176, 179 mantener, 356-57
aplicación (ASP), 68 Resta, signo de (–), 297 Sensibilidad perceptual, 450 máscaras (skins), 390
Prueba, 169, 526-28 Restricciones de integridad, 424-25 SET (transacción electrónica particionar, 213-17
de cadena, 527 Resumen ejecutivo, 89 segura), 544 promoción, 356
de sistemas completa, 527-28 Retraso, procesamiento, 463-64 Símbolo vocabulario para, 349f
de vínculos, 527 Retroalimentación de flecha, 194, 295-96 SOA. Vea Arquitectura orientada a
Puedeserun, 307f, 308 acerca de, 461 utilizados en STROBE, 147-48 servicios (SOA)
Puesta en producción, 17 como control del sistema, 25 Simpleza en el modelado ágil, 167 Sobrecarga de información
como valor de metodología ágil, Sin normalizar, 413-23 humana, 179
Q 167 Sistemas Software
QBE (consulta mediante ejemplo), después de los prototipos, 158 de administración de contenido como un servicio (SaaS), 531-33
471-73 diseñar, 464-65 (CMS), 356-357 ejercicios y problemas, 256-57
QuickBooks Pro, 73 tipos, 462-64 de automatización de oficinas elegir, 68-72
QWERTY, teclados, 449 y precisión, 506-07 (OAS), 2-3 externalizar, 71
RFID (identificación por radio de información foros, 464-65
R frecuencia), 498-99 análisis y diseño orientado a para el diseño de formularios, 375
Rango, prueba, 501 Riesgos de la innovación, 179-81 objetos (OO), 17-19 personalizado, 68-69
Reconocimiento Rollover, menús, 466 ciclo de vida del desarrollo registros y elementos, 252-53
de caracteres de tinta magnética Ropa, 146 de sistemas, 8-13 Vea también Software,
(MICR), 497 RSS, fuentes, 335 elegir, 19 comercial de venta en canales
óptico de caracteres (OCR), 496 Ruby on Rails, lenguaje, 6 enfoque de utilidad para la convencionales (COTS);
Recopilación de información evaluación, 546-48 Entrada, MAC, atractivo de;
caso de la CPU, 154 S integrar tecnologías para, 4-5 Salida
diseño de aplicación conjunta SaaS (software como un servicio), necesidades de análisis y Software
(JAD), 111-14 531-33 diseño, 6 comercial de venta en canales
ejercicios, problemas, 124-30, Salida rol de los analistas, 6-8 convencionales (COTS)
150-52 animada, 333-34 tipos, 2-4 crear prototipos, 161-62
www.xlibros.com
572 ÍNDICE
www.xlibros.com
OPORTUNIDADES DE CONSULTORÍA
1 SISTEMAS
SISTEMAS, ROLES Y METODOLOGÍAS
Í DE DESARROLLO
1.1 Contratación saludable: se busca ayuda para el comercio
electrónico 7
3 ADMINISTRACIÓN DE PROYECTOS
3.1 El sonido más dulce que haya sorbido 58
3.2 Veni, Vidi, Vendi o Vine, vi y vendí 70
3.3 Vamos a ver a los magos 73
3.4 Comida para pensar 78
3.5 Cuidar los objetivos 85
4 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS
4.1 Fortalezca sus tipos de preguntas 108
4.2 Un vistazo a la superficie 110
4.3 Analista de sistemas, supongo 113
4.4 El cuestionario insoportable 120
4.5 Orden en las cortes 121
www.xlibros.com
10.2 Reciclando el entorno de programación 284
10.3 Desarrollo de un sistema fino cuyo plazo de entrega se venció hace
mucho: uso del análisis orientado a objetos para el Sistema de la
biblioteca pública Ruminski 313
10.4 C-Shore++ 315
14 INTERACCIÓN HUMANO-COMPUTADORA
14.1 El espíritu escolar viene en varias tallas 450
14.2 Preferiría hacerlo yo mismo 454
14.3 No me desaceleren 456
14.4 Ésa no es una bombilla 457
14.5 En espera de ser alimentado 461
14.6 Al correr en un maratón, es conveniente saber hacia dónde
se dirige 466
14.7 ¡Eh, mírame! (Repetición) 472
www.xlibros.com