Tarea 1

Resumen Kendall y Kendall de análisis y diseño

de sistemas
CAPÍTULO1

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 encuentran los sistemas de
información administrativa (MIS) y los sistemas de soporte de decisiones (DSS).

Los sistemas de procesamiento de transacciones son sistemas que atraviesan

límites y permiten que la organizació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.

La información puede ser tratada como un recurso organizado como los humanos.
Por tanto, debe gestionarse con el mismo cuidado que otros recursos. La
disponibilidad de potencia informática asequible para las organizaciones ha
provocado una explosión de información, por lo que se debe prestar más atención
al procesamiento de la información generada. Los analistas de sistemas
recomiendan, diseñan y mantienen varios tipos de sistemas para los usuarios,
incluido el procesamiento de transacciones, la automatización de oficinas, el
trabajo del conocimiento y la información de gestión. También crean sistemas
orientados a la toma de decisiones para usuarios específicos. Estos sistemas
incluyen sistemas de apoyo a la toma de decisiones, sistemas expertos, sistemas
de apoyo a la toma de decisiones en grupo, sistemas de trabajo colaborativo
asistido por computadora y sistemas de apoyo al desempeño.

Un gran número de aplicaciones se están migrando o se originan en la Web para

admitir el comercio electrónico y muchas otras funciones comerciales. El análisis y
diseño de sistemas es un método sistemático para identificar problemas,
oportunidades y metas. Analizar el flujo de información generado por las personas
y las computadoras de la organización, y diseñar sistemas de información
computarizados para resolver problemas.

Los analistas de sistemas juegan muchos roles en el proceso de trabajo. Los

analistas tienen una amplia gama de habilidades. En primer lugar, el analista es un
solucionador de problemas, le gusta analizar problemas y diseñar soluciones
viables. Los analistas de sistemas necesitan habilidades de comunicación que les
permitan interactuar de manera significativa con muchos tipos de personas y
habilidades informáticas todos los días. Conocer a sus usuarios e interactuar bien
con ellos es esencial para su éxito.
El analista lo hará de forma sistemática. El marco de la metodología del sistema
se proporciona en el ciclo de vida del desarrollo del sistema. Este ciclo de vida se
puede dividir en siete fases consecutivas, aunque en realidad estas fases están
interrelacionadas y suelen ocurrir simultáneamente. Las siete etapas son:
identificar problemas, oportunidades y metas; determinar los requisitos de
información para factores humanos; analizar los requisitos del sistema; diseño del
sistema recomendado; desarrollo y documentación del software; prueba y
mantenimiento del sistema; e implementación y evaluación del sistema. La
metodología ágil es una metodología de desarrollo de software basada en valores,
principios y prácticas básicos. Los sistemas diseñados con métodos ágiles se
pueden desarrollar rápidamente. Las diversas etapas del proceso de desarrollo
ágil incluyen exploración, planificación, lanzamiento de la primera iteración,
producción y mantenimiento.

Estas tecnologías se basan en conceptos de programación orientada a objetos

codificados en UML (Standard Modeling Language), en este modelo los objetos
creados incluyen no solo códigos de datos, sino también instrucciones para las
operaciones a realizar. datos. El diagrama de claves ayuda a analizar, diseñar y
comunicar el sistema desarrollado mediante UML. Estos sistemas generalmente
se desarrollan como componentes, y el proceso de repensar estos componentes
suele ser una actividad normal en el diseño y análisis orientado a objetos.

CAPÍTULO2
Comprensión y modelado de
los sistemas organizacionales

Las organizaciones están compuestas por sistemas más pequeños e

interrelacionados (departamentos, unidades, divisiones, etc.) que brindan
funciones especializadas.
Algunas de las funciones comunes son contabilidad, marketing, producción,
procesamiento
de datos y administración. Las funciones especializadas (sistemas más pequeños)
se reintegran.
Esto se debe a que la salida de información del subsistema será la entrada
Por otro lado, creando así un sistema de trazabilidad. Por tanto, el analista debe
Encuentre una manera de clasificar estos subsistemas y sus actividades;
¿Qué diferentes métodos de análisis se utilizan, como diagramas de flujo,
Modelo de relación de entidad o caso de uso. Para poder estudiar más
profundamente
En el análisis de las organizaciones, los expertos las dividen en tres partes
diferentes.
Jerarquía para crear un modelo piramidal donde diferentes
Funciones dentro de la organización de cada subsistema.

Capacidad de interrelación e interdependencia de los sistemas

Otro aspecto de las organizaciones como sistemas es que todos los sistemas
están contenidos por límites que los separan de sus entornos. Los límites
organizacionales existen en un rango continuo, desde los extremadamente
permeables hasta los que son casi impermeables. Para poder adaptarse y
sobrevivir, las organizaciones primero deben ser capaces de importar personas,
materia prima e información a través de sus límites (entradas) y después
intercambiar sus productos terminados, servicios o información con el mundo
exterior (salidas). cosa externa a los límites de una organización se considera un
entorno. Numerosos entornos con diversos grados de estabilidad constituyen el
medio en el que existen las organizaciones.
Algunos de éstos son:
1) el entorno de la comunidad en la que se encuentra físicamente la organización,
y se determina considerando el tamaño de su población y su perfil demográfico
(nivel de educación, ingresos
promedio y otros indicadores);
2) el entorno económico, que se ve influenciado por los factores del mercado,
incluyendo la competencia;
3) el entorno político, que se controla mediante gobiernos estatales y locales,
4) el entorno legal, que establece leyes y lineamientos federales, estatales,
regionales y locales. Aunque es posible planear respuestas a los cambios del
entorno, por lo general una organización no puede controlarlos de
manera directa.

Organizaciones y equipos virtuales

Muchos analistas de sistemas y equipos de diseño ahora pueden trabajar en
forma virtual y, de hecho, muchos 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.

Puede ser frustrante implementar una solución ERP, ya que es difícil analizar un
sistema en uso y después adaptar el modelo ERP a ese sistema. Además, las
empresas tienden a diseñar sus procesos de sistemas antes de implementar el
sistema ERP. Por desgracia, es común que este proceso se realice de manera
apresurada y el modelo de negocios propuesto no siempre coincide con la
funcionalidad del sistema ERP. El resultado es que se requiere más
personalización, periodos de tiempo de implementación extendidos, costos más
altos y a menudo.

CAPÍTULO3
Administración de Proyectos

Las características más destacadas de los analistas de sistemas son la capacidad

de iniciar un proyecto, determinar su viabilidad, programar una fecha y hora para
la implementación, planificar y luego administrar las actividades y los miembros del
equipo para optimizar la productividad. Los proyectos de sistemas siempre
comienzan con problemas u oportunidades que surgen cuando la organización se
adapta a los cambios para mejorar la empresa. industrial. El analista y el usuario
crean una definición de problema para reflejar el problema y el sistema
empresarial actual. El analista debe tomar una decisión y determinar si el proyecto
adjudicado es factible.

Cuando se utilizan diagramas de Gantt y diagramas de tecnología de revisión y

evaluación de planes (PERT) y otras herramientas para planificar las actividades
del proyecto, el proyecto se puede completar a tiempo. La tarea principal del
equipo de análisis del sistema es gestionar de forma eficaz sus actividades
planificadas.
Algunos proyectos concebidos por el equipo pasarán por varias etapas, otros no
sobrevivirán.

Cabe señalar que los emprendedores quieren proyectos por dos razones: por los
problemas que han encontrado que los hacen aptos para soluciones de sistemas,
y porque se dan cuenta de que actualizando o modificando sistemas existentes o
instalando nuevos sistemas o nuevos sistemas Para realizar mejoras. A los
gerentes no les gustan los problemas con su organización, y mucho menos hablar
de ellos con personas externas. Por el contrario, los buenos gerentes se dan
cuenta de que si quieren que su negocio continúe maximizando su potencial,
deben identificar los síntomas del problema o diagnosticar el problema ellos
mismos en una etapa posterior y luego enfrentar el problema.

Una forma de conceptualizar qué son los problemas y cómo surgen es pensar en
ellos como situaciones en las que el objetivo nunca se alcanza o se detiene en
algún momento. La retroalimentación real puede proporcionar información sobre el
mal desempeño o la ineficiencia de la organización. En algunos casos, debido a la
imposibilidad de cumplir con los indicadores de desempeño, se descubrieron
problemas que requerían los servicios de un analista de sistemas. Los problemas
de proceso que no son visibles en el proceso de salida pueden requerir la ayuda
de un analista de sistemas; incluyen demasiados errores y trabajo que se realiza
con demasiada lentitud, de forma incompleta, incorrecta o no se realiza en
absoluto.

Otras formas de resolver los errores organizacionales son los cambios en el

comportamiento de los empleados, como el ausentismo alto y anormal, la
insatisfacción laboral severa o la alta rotación de empleados.
La retroalimentación sobre el desempeño organizacional puede provenir de
afuera, como quejas o sugerencias de clientes, distribuidores o proveedores, así
como ventas perdidas o inesperadas.
Al responder a historias sobre problemas en la organización, los analistas actúan
como consultores, expertos de apoyo y agentes de cambio.
El analista primero define los problemas y objetivos del sistema. Éstos forman la
base para determinar qué debe lograr el sistema. A su vez, debe poder
comprender, al menos en parte, cómo funciona la estructura de la empresa.
Ciertas decisiones que tomen los analistas estarán influenciadas por el análisis y
las observaciones realizadas a través de diversas herramientas.
La persona a cargo del análisis del sistema debe intentar hacer las preguntas
correctas, por lo que una vez que se determina el objetivo, se debe determinar el
objetivo clave.

Hay que tener en cuenta que ciertos requisitos nos plantearán más metas, a la
hora de transformar el proceso de análisis puede que tengamos o no varios casos
de uso. Es importante mantener un plan diferente y diseñar un plan para cada
requisito, ya que esto ayudará a que este proceso sea más preciso a medida que
avanza el proyecto.
En el proceso de creación de una solución, hay muchas variantes del proyecto,
pero no se deben usar todas las variantes, es importante elegir cada variante
correctamente. Algunos proyectos son interdependientes, así que no lo tome a la
ligera. Siempre se debe consultar a los consultores y la gerencia sobre las
posibilidades de cada opción.

Algunas de las contribuciones que tendrán un impacto en la empresa son dignas

de mención: 1) mejorar las ganancias de la empresa, 2) apoyar la estrategia
competitiva de la organización, 3) mejorar la cooperación con distribuidores y
socios, 4) mejorar el apoyo a las operaciones internas para que los productos y
Brindar servicios de manera eficiente y eficiente; 5) Mejorar el apoyo a la toma de
decisiones internas para hacerla más efectiva; 6) Mejorar el servicio al cliente; 7)
Mejorar la moral de los empleados

A partir de la "selección del proyecto" en la etapa anterior, debemos adoptar

criterios de factibilidad y considerar operaciones, capacidades técnicas y
económicas.

El analista debe tener un diálogo con la autoridad competente para ejecutar el

proyecto hasta que se complete el proyecto.
Una vez que se decide el proyecto, se deben determinar los requisitos de
hardware y software, y se debe inventariar el hardware y el software para
determinar los elementos que son útiles para el proyecto, lo que ayudará a reducir
los gastos. Además de la lista de verificación de ejecución, se debe estimar la
carga de trabajo, esto se refiere al hecho de que si el sistema actual es adecuado
para realizar actividades futuras del sistema, se pueden utilizar herramientas como
el benchmarking para completar este trabajo.

CAPÍTULO4

Recopilación de información: métodos interactivos

Para obtener los requerimientos humanos de información se requiere de tres
métodos clave como lo son: entrevistas, 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 interacciones con la
tecnología, a través de una serie de preguntas cuidadosamente elaboradas. En un
capítulo posterior veremos los métodos discretos 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á obtener una descripción más completa de los
requerimientos de información de la organización.

Entrevistas

Se debe pensar en el proceso completo de la entrevista antes de llevarla a cabo,

pensar en que preguntas se van a formular, y que hará que sea una entrevista
exitosa; se debe buscar la opinión del entrevistado, preguntar sus principales
preocupaciones, también se debe explorar sobre el HCI (interacción humano-
computadora) para saber que tan placentero y divertido es el sistema y que tan útil
es para las tareas individuales. Se debe generar confianza y comprensión sin que
se pierda el control de la entrevista.

Cinco pasos para la preparación de una entrevista.

1. Leer el material sobre los antecedentes.

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. (Preguntas Abiertas y
Cerradas)

El entrevistador debe empezar con preguntas muy detalladas, a menudo cerradas.

Después se expanden los temas al permitir preguntas abiertas y respuestas más
generalizadas.

Diseño de Aplicación Conjunta

El motivo principal para usar JAD es para reducir el tiempo ya que una entrevista
dura mucho y por ende el costo, mejorar la calidad de los resultados de la
evaluación de los requerimientos de información y mejorar el grado de
identificación del usuario con los nuevos sistemas de información.

Aunque JAD se puede sustituir por las entrevistas personales en cualquier

momento apropiado durante el SDLC, por lo general se emplea como técnica que
le permite a usted, como analista de sistemas, realizar el análisis de
requerimientos y diseñar la interfaz de usuario en forma conjunta con los usuarios,
en un ambiente de grupo.
Cuando usarlo:

1. Los grupos de usuarios estén inquietos y deseen algo nuevo, no una solución
estándar para un problema
común.
2. La cultura de la organización apoya los comportamientos de solución de
problemas conjuntos entre varios
niveles de empleados.
3. Los analistas pronostican que la cantidad de ideas generadas mediante las
entrevistas cara a cara no será tan
abundante como el número de ideas posibles mediante un ejercicio de grupo
extendido.
4. El flujo de trabajo permita la ausencia del personal clave durante un periodo de
dos a cuatro días.

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 organizació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 propiedades
de las personas u objetos.

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 sentimiento 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 cuestiones importantes antes de programar las entrevistas.

Lineamientos para saber si es apropiado utilizar cuestionarios.

1. Las personas a quienes necesita interrogar están esparcidas en un área amplia

(distintas sucursales de la misma corporación).
2. Hay gran cantidad de personas involucradas en el proyecto de sistemas, por lo
que es importante saber qué proporción de un grupo dado (por ejemplo, la
gerencia) aprueba o desaprueba una característica específica del sistema
propuesto.
3. Piensa realizar un estudio exploratorio y desea medir la opinión general antes
de que el proyecto de sistemas tome cualquier dirección específica.
CAPÍTULO5
Recopilación de información:
métodos discretos
La efectividad en la recopilación de los datos también es un factor importante. El
muestreo ayuda a mejorar la efectividad si se permite obtener información más
precisa. Por ejemplo, puede hablar con menos empleados, pero debe hacerles
preguntas más detalladas. Además, si se entrevista a menos personas, el analista
tendrá tiempo para dar seguimiento a la información incompleta o faltante, con lo
cual se mejorará la efectividad de la recopilación de datos.

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 intencionado
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 analista de sistemas se obtienen mediante
1) muestreo sistemático
2) muestreo estratificado
3) muestreo de
conglomerados.

Hay muchos documentos cuantitativos disponibles para su interpretación en

cualquier empresa: informes empleados
para la toma de decisiones, informes de rendimiento, registros y variados tipos de
formularios. Todos
estos documentos tienen un propósito y una audiencia específicos.

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.
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 imprimir cualquier formulario basado en Web que los
usuarios tengan que imprimir. Como alternativa puede identificar 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.

Análisis de los documentos cualitativos

Los documentos cualitativos incluyen mensajes de correo electrónico,

memorandos, anuncios en tableros y áreas de trabajo, páginas Web, manuales de
procedimientos y de políticas. Muchos de estos documentos contienen gran
cantidad de detalles que revelan las expectativas de los autores con respecto al
comportamiento de los demás, junto con las formas en que los usuarios esperan
interactuar con las tecnologías de información. Aunque muchos analistas de
sistemas son aprensivos en cuanto al análisis de documentos cualitativos, no
tienen razón para serlo. Varios lineamientos pueden ayudar a los analistas a
adoptar un enfoque sistemático para
este tipo de análisis; muchos se relacionan con los aspectos afectivos, emotivos y
motivacionales de HCI, así como las relaciones interpersonales en la organización.

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.

Aunque es posible describir y documentar cómo toman decisiones los gerentes

mediante el uso de cuadros y flechas, lo que describiremos principalmente es a los
humanos y sus actividades. Por lo tanto, sugerimos que los analistas de sistemas
utilicen una metodología más humanista para describir lo que hacen los gerentes.
A este método se le conoce como guión (playscript) del analista. Con esta técnica,
el “actor” es el encargado de tomar decisiones y a quien observamos cómo “actúa”
o toma las decisiones. Al momento de establecer un guión, el actor aparece en
una lista en la columna izquierda y todas sus acciones se listan en la columna
derecha,
como se muestra en la figura 5.7. Todas las actividades se registran con verbos;
así, el encargado de las decisiones se podría describir siempre llevando a cabo
una actividad: “habla”, “muestrea”, “corresponde” y “decide”.

CAPÍTULO6
Modelado ágil
y prototipos
Algunos analistas argumentan que es necesario considerar a los prototipos como
una alternativa al SDLC. En el capítulo 1 vimos que el SDLC es una metodología
lógica y sistemática para desarrollar sistemas de información. Las quejas sobre
tener que pasar por el proceso del SDLC se concentran en dos aspectos
interrelacionados. El primero es el largo tiempo requerido para pasar por el ciclo
de vida de desarrollo. A medida que aumenta la inversión de tiempo del analista,
el costo del sistema entregado se eleva en forma proporcional. La segunda es que
los requerimientos del usuario cambian con el tiempo. Durante el extenso intervalo
entre el momento en que se analizan los requerimientos de los usuarios y el
momento en el que se entrega el sistema terminado, los requerimientos de los
usuarios evolucionan. Así, debido al ciclo de desarrollo extendido, puede suceder
que el sistema resultante reciba críticas por abordar en forma inadecuada los
requerimientos de información actuales de los usuarios.

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.

Al crear prototipos de algunas de las características de un sistema y

convertirlos en un modelo funcional, es imperativo que el analista trabaje en
módulos administrables. Una de las ventajas únicas de los prototipos es que no es
necesario ni conveniente construir todo un sistema funcional para usarlos.
Un módulo administrable permite a los usuarios interactuar con sus características
clave y se puede construir por separado. Las características del módulo que se
consideran menos importantes se dejan intencionalmente fuera del prototipo
inicial. Como veremos más adelante en este capítulo, esto es muy similar a la
metodología
ágil que hace énfasis en liberar pequeñas versiones.
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 modificació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 requerirá
modificaciones es una postura útil que demuestra a los usuarios qué tan necesaria
es su retroalimentación para mejorar el sistema.

La utilización de prototipos no es necesaria o apropiada en todos los proyectos de

sistemas, como hemos visto. Sin embargo, las ventajas también se deben tener en
consideración al decidir si debemos o no crearlos. Las tres principales ventajas de
los prototipos son el potencial de cambiar el sistema durante las primeras etapas
de su desarrollo, la oportunidad de detener el desarrollo en un sistema que no está
funcionando y la posibilidad de desarrollar un sistema que cumpla mejor con las
necesidades y expectativas de los usuarios. La creación de prototipos exitosos
depende de la retroalimentación oportuna y frecuente de los usuarios, que los
analistas pueden usar para modificar el sistema y hacerlo más sensible a las
necesidades actuales. Al igual que con cualquier otro esfuerzo de sistemas, los
cambios en las primeras etapas son menos costosos que los cambios tardíos. En
la última parte del capítulo verá cómo la metodología ágil para el desarrollo utiliza
una forma extrema de prototipos, en la que se requiere un cliente en el sitio de
trabajo para que provea retroalimentación durante todas las iteraciones.

El papel de los usuarios en los prototipos se puede resumir en dos palabras:

participación honesta. Sin la participación de los usuarios, los prototipos no tienen
mucho sentido. Los comportamientos precisos necesarios para interactuar con un
prototipo pueden variar, pero está claro que el usuario es fundamental para el
proceso de creación de prototipos. Teniendo en cuenta la importancia del usuario
para el éxito del proceso, los miembros del equipo de análisis de sistemas deben
fomentar y agradecer la entrada y protegerse contra su propia resistencia natural a
cambiar el prototipo.

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 presentes usuarios y analistas experimentados, no hay
duda de que este esfuerzo creativo puede impulsar el desarrollo con un ritmo
acelerado.

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.

CAPÍTULO7

Uso de diagramas
de flujo de datos

Convenciones usadas en los diagramas de flujo de datos

Se utilizan cuatro símbolos básicos para graficar el movimiento de los datos en los
diagramas: un cuadrado doble, una flecha, un rectángulo con esquinas redondas y
un rectángulo con un extremo abierto (cerrado del lado izquierdo y abierto del lado
derecho), como se muestra en la figura 7.1. Podemos describir en forma gráfica
todo un sistema y numerosos subsistemas al combinar estos cuatro símbolos.
El cuadrado doble se utiliza para describir una entidad externa (otro departamento,
una empresa, una persona o una máquina) que pueda enviar/recibir datos
hacia/desde el sistema. La entidad externa, o simplemente entidad, también se
conoce como origen o destino de los datos, y se considera externa al sistema que
se está describiendo. Cada entidad se identifica con un nombre apropiado.
Aunque interactúa con el sistema, se considera fuera de los límites de éste. Se
debe denominar a las entidades con un sustantivo. Se puede utilizar la misma
entidad más de una vez en un diagrama de flujo de datos para evitar cruzar las
líneas de flujo de 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 computadora, no se incluyen en el diagrama de flujo de datos. Hay que dar a
cada almacén de datos un número de referencia único, como D1, D2, D3, por
ejemplo.

Con una metodología arriba-abajo para crear un diagrama del movimiento de los
datos, los diagramas avanzan de generales a específicos. Aunque el primer
diagrama ayuda al analista de sistemas a comprender el movimiento de datos
básico, su naturaleza general limita su utilidad. El diagrama de contexto inicial
debe ser una vista general que incluya las entradas básicas, el sistema general y
las salidas. Este diagrama será el más general, una verdadera vista panorámica
del movimiento de datos en el sistema y la conceptualización más amplia posible
del
sistema.

El Diagrama 0 es la expansión del diagrama de contexto; puede incluir hasta

nueve procesos. Si incluimos más procesos en este nivel obtendremos un
diagrama abarrotado de información que será difícil de comprender.
Cada proceso se enumera con un entero, por lo general empezando a partir de la
esquina superior izquierda del diagrama y avanzando hacia la esquina inferior
derecha. En el Diagrama 0 se incluyen los principales almacenes de datos del
sistema (que representan a los archivos maestros) y todas las entidades externas.

Por lo general, las entidades no se muestran en los diagramas hijos debajo del
Diagrama 0. El flujo de datos que concuerda con el flujo padre se denomina flujo
de datos de interfaz y se muestra como una flecha que entra o sale de un área en
blanco del diagrama hijo. Si el proceso padre tiene un flujo de datos que lo
conecta con un almacén de datos, el diagrama hijo puede incluir el almacén de
datos también. Además, este diagrama de nivel inferior puede contener almacenes
de datos que no se muestren en el proceso padre. Por ejemplo, se puede incluir
un archivo que contenga una tabla de información tal como una tabla de
impuestos, o un archivo que vincule dos procesos en el diagrama hijo. Los flujos
de datos menores, como una línea de error, se pueden incluir en un diagrama hijo
pero no en el padre.

Al desarrollar un diagrama de flujo de datos lógico para el sistema actual podemos

comprender con claridad la forma en que opera el sistema actual y, por ende,
constituye un buen punto de partida para desarrollar el modelo lógico del sistema
actual. Como este paso lleva mucho tiempo, a menudo se omite para pasar
directamente al DFD lógico propuesto.

Para desarrollar un diagrama de este tipo hay que construir primero un diagrama
de flujo de datos lógico para el
sistema actual. Hay varias ventajas en cuanto al uso de un modelo lógico:
1. Mejor comunicación con los usuarios.
2. Sistemas más estables.
3. Los analistas comprenden mejor el funcionamiento de la empresa.
4. Flexibilidad y mantenimiento.
5. Se eliminan las redundancias y se facilita la creación del modelo físico.

Los diagramas de flujo de datos físicos también tienen almacenes de datos

intermedios, a menudo compuestos 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 compras de abarrotes, la preparación de comidas y la
acción de comer.
Comentario Respecto al programa

Me parece muy completo el temario ya que abarca distintos aspectos relacionados

con la administración de proyectos y requerimientos como lo son las estimaciones,
análisis costo beneficio, las técnicas de administración de proyectos, el análisis y
toma de Decisiones, la redacción y lectura, liderazgo, comunicación y manejo de
estrés y tiempo y el retorno de la inversión entre otras más. Considero que cada
uno de estos temas me van a ayudar a poder tener un desarrollo mejor, así como
relacionarme con cada uno de los aspectos que se van a trabajar en este curso y
de esa manera ayudarme a la toma de decisiones cuando sea el caso de poner a
prueba todo lo que se llevara a cabo en este temario.