Análisis y diseño de sistemas estructurado

Análisis y diseño de sistemas
estructurado

José Reynaldo
Palacios Gómez

23/03/2012 1

Temas

• Fundamentos del
Análisis de Sistemas
• Análisis de los
requerimientos de
información
• Proceso de Análisis
• Aspectos esenciales del
diseño
• Ingenieria e
implementación de
software

Fundamentos del Análisis de
Sistemas
• Rol del analista de
sistemas
• Estilo organizacional e
impacto en los
sistemas de
información
• Determinación de la
viabilidad y
administración de las
actividades de análisis
y diseño

Regresar

Rol del analista de sistemas
Determinar el papel del analista de sistemas, para el desarrollo de sistemas, es un poco
complicado, la idea que presenta Kendall, es que se pretende que sea una persona que
realice principalmente tres funciones dentro de la empresa:

•Consultor: La contribución que se espera es que canalice ciertos tópicos de informática,
deberá implantar metodologías, para analizar y diseñar sistemas de información,

•Especialista de apoyo: A fin de que de manera regular trabaje dentro del departamento
de sistemas, siendo un recurso humano de apoyo para quienes lo dirigen, quienes
aprovecharan su experiencia profesional respecto al hardware y al software y a sus
aplicaciones en la empresa.

•Gente de cambio: Ser un catalizador para el cambio, al realizar alguna de las
actividades del ciclo del desarrollo del sistema que son las siguientes:
i. Identificación de oportunidades y objetivos
ii. Determinación de los requerimientos de información

iii. Análisis de las necesidades del sistema
iv. Diseño del sistema recomendado
v. Desarrollo y documentación del software
vi. Prueba y mantenimiento del sistema
vii. Implantación y evaluación del sistema

para lo cual debe tener ciertas cualidades como ser un solucionador de problemas, que le
gusten los retos, que disfrute encontrando soluciones, debe ser un buen interlocutor,
debe ser un experto en computación para programar, entender las capacidades y
limitaciones de la computadora, y reconocer las necesidades de los usuarios.

Sin embargo considero que el analista de sistemas, debe trabajar conjuntamente con los
Administradores, ya que por lo regular son los Administradores los que establecen el
sistema de información en las empresas, dado que un sistema es una serie de elementos
que forman una actividad, un procedimiento o un plan de procedimientos que buscan una
meta o metas comunes mediante la manipulación de datos o energía o materia.

Dado que de manera similar tienen diversas metodologías para el estudio de desarrollos
organizacionales, a manera de ejemplo, se presentan las siguientes etapas que realizan
para definir su desarrollo de sistema de información:

1. Visión del estudio: Nace de la percepción, depuración y consolidación de una idea, que
reditúa en la evolución de la misma y en aproximación de conceptos.

2. Planeación del estudio: Con base en la identificación de elementos o variables
estudiados para que la organización cumpla su cometido, tomadas de fuentes de estudio
internas y externas, se define el objetivo de estudio y considerando una investigación
preliminar, se prepara el proyecto de estudio, que incluye la propuesta técnica y el
programa de trabajo, para su autorización se integra al grupo y se da capacitación al
mismo.

3. Recopilación de datos: Es la captación de datos específicos, completos, congruentes,
susceptibles de validarse a través de la investigación documental, consulta a sistemas
de información, entrevista cuestionario y observación directa, resguardándola en
medios electrónicos en una forma ordenada, considerando su historia para comprender
la situación actual.

4. Análisis de los datos: Examen critico que permite precisar las causas que originaron el
estudio y ponderar las posibles alternativas de acción para su efectiva atención.

5. Formulación de recomendaciones: Propuestas concretas de acción y actuación,
evaluando sus ventajas y desventajas, presentándolas a manera de propuestas o
recomendaciones.

6. Implantación: Puesta en marcha del proceso determinado, considerando la
preparación del programa, integración de recursos y la ejecución del programa.

7. Evaluación: Identificación, calificación y cuantificación de las realizaciones, y cambios
operativos que de estas se desprendan, análisis cuantitativo y cualitativo del estudio que
permite establecer un marco comparativo entre lo planeado y lo realizado.

De echo, existen diferentes metodologías para el desarrollo de sistemas en informática,
como la que a continuación se presenta:

1.- Investigación preliminar.
Se realiza una investigación preliminar para valorar si entendemos claramente la
solicitud del usuario y determinar si es factible o no llevar a cabo el proyecto, y
asegurar con la aprobación de la solicitud que se desarrollara una aplicación correcta a
los deseos del usuario.

2.- Determinación de los requerimientos del sistema.
Se lleva a cabo un estudio del proceso administrativo, para comprenderlo y estar en
posibilidades de plantear alternativas de depuración o corrección del proceso, e
identificar problemas y las causas que los producen, a fin de plantear y delimitar una
solución factible y conveniente en términos de costo-beneficio.

3.- Diseño del sistema.
Se elabora el diseño del sistema considerando que exista un orden lógico y coherente de
los componentes que formaran el sistema, para que al momento de programarlo no exista
dudas de la mecánica, estructura y datos que compondrán las entradas y salidas del
sistema.

4.- Desarrollo del software.
Se puede determinar el utilizar software empaquetado que se apegue a los
requerimientos del usuario o en su caso elaborar un sistema a la medida de los
requerimientos del usuario.

5.- Prueba de los sistemas.
Se realizan pruebas para tener la certeza y confianza de que el sistema opera
adecuadamente y que los datos que proporcione sean confiables.

6.- Implantación.
Se entrena al personal que operará el sistema en forma directa para que no exista
margen de error en la captación de los datos por desconocimiento en la operatividad de
los programas y se opere correctamente.

7.- Evaluación.
Se identifican los puntos débiles y fuertes del sistema y se valora la operación del
mismo, para conocer los beneficios del sistema.

Existen diferentes metodologías, por que cada autor de acuerdo a su experiencia, nos
transmite la manera de desarrollar sistemas de información, ya que como es un proceso
administrativo, no existe un procedimiento a manera de receta para solucionar los
problemas que el usuario (de cualquier nivel) le puedan surgir administrativamente.

Derivado de lo anterior, el analista de sistemas debe ser una persona critica, con la
capacidad de entender lo que la organización requiere, con un espíritu servicial, y que le
gusten los retos, y con base en esto aportar sus conocimientos, en materia de
informática y computación, para elaborar un sistema de información, basado en
herramientas de computo y software, para que a través de estos medios se faciliten las
actividades que conllevan la operación, además de la obtención de datos, que se
convertirán en información para la toma de decisiones administrativas, por lo cual debe
trabajar en conjunto con los diferentes profesionistas, peritos en su materia.

Regresar

Estilo organizacional e impacto
en los sistemas de información
El desarrollo planteado por los profesores Jeffrey Whitten, Lonnie Bentley y Victor
Barlow acerca del “ciclo de vida del desarrollo de sistemas”, se me hizo muy completo,
primeramente encierran en 5 aspectos dicho desarrollo:

• Principios esenciales: Los principios que como desarrolladores de sistemas
debemos tener en cuenta al llevar a cabo el desarrollo

• Clasificación de oportunidades y normas: Identificación de las necesidades
abarcando una amplia gama de conceptos

• Funciones de alto nivel: En si esta es la parte que corresponde al ciclo de
desarrollo del sistemas y abarca las etapas de:

o Planificación de sistemas
o Análisis de sistemas
o Diseño de sistemas

o Implantación de sistemas
o Soporte de sistemas

• Actividades cruzadas del ciclo de vida: Se nos presentan las actividades que
se tienen que realizar a la par de las etapas del ciclo del desarrollo del
sistemas,
• Desarrollo de sistemas de usuario final: Se toma un aspecto importante,
cuando el usuario final es la misma persona que desarrolla el sistema,
puntualizándose en los aspectos relevantes a considerar del ciclo del
desarrollo del sistema.
Este capitulo del libro es muy enriquecedor para las personas que tienen que
enfrentarse en una institución o empresa, para el desarrollo de sistemas, me parece que
están muy bien llevados los conceptos, y me llamaron la atención ciertos puntos en
particular como son:
• Implicar al usuario: Este apartado se me hace muy importante, ya que el
usuario, por lo regular se opone al cambio, y en cierta manera hasta trata de
boicotear el proyecto, pensando que el sistemas le va a restar oportunidades
laborales.

• Los conceptos que abarcan la “Aplicación metódica en la resolución de
problemas”, como son: “Comprender el contexto del problema” y “Hallar
soluciones alternativas”: Existen muchas empresas que brindan el servio
outsourcing, mismas que no les importa de entrada dichos conceptos, a lo que
van es a identificarlos como focos de oportunidad, actividades o procesos
que no están contemplados dentro del contrato establecido para el
desarrollo del sistema para el que fueron contratados, y por lo tanto intentan
enganchar a la empresa con otros requerimientos que supuestamente no
estuvieron contemplados.
• Clasificación de oportunidades y normas: Este apartado es interesante por
que nos da el apoyo justificable de las actividades que requieren
automatizarse, al indicarnos todas las necesidades que se pueden ofrecer,
para implementar un sistema de información.
• Funciones de alto nivel: Esta parte me parece la tradicional metodología de
desarrollo de sistemas en informática:
o Planificación de sistemas
o Análisis de sistemas
o Diseño de sistemas
o Implantación de sistemas

o Soporte de sistemas

• Actividades cruzadas del ciclo de vida: Me parece muy adecuado identificar
que actividades se deben alternar al mismo tiempo con las de la metodología
del desarrollo de sistemas, las cuales la profesionalizan y le otorgan calidad.
• Desarrollo de sistemas de usuario final: Es muy apropiado dedicarle un
espacio al desarrollo de sistemas, cuando el usuario final es el que desarrolla
el sistema.

En general, los temas abordados están muy bien tratados, pero tengo mis dudas de su
total aplicación, ya que me ha tocado en mi vida laboral, que el desarrollo del sistema
tenga un plazo de tiempo para llevarse a cabo, y ese tiempo, por lo regular o casi
siempre es muy reducido, lo que impide que se lleven a buen termino todas las
actividades antes presentadas, lo que nos lleva a que no se consideran algunas
actividades, que en esencia serian de gran apoyo, además como en el capitulo se
menciona, es mejor identificar a tiempo ya en el desarrollo del sistema, si vale la pena
seguir con el proyecto, o cancelarlo para no tirar mas dinero innecesariamente.

Regresar

Determinación de la viabilidad y administración de las
actividades de análisis y diseño

Kendall, nos habla de lo que un analista de sistemas debe considerar cuando se inicia con
la ardua tarea de desarrollar un sistema de información, para lo cual primeramente se
toma en cuenta que problemas existen en la organización, que oportunidades de mejora
pueden ofrecerse a la empresa como son:

• Reducción de errores de captura
• Eliminación de salidas redundantes
• Combinación de procesos
• Mejoría en la integración de los sistemas y los subsistemas
• Aceleración del proceso
• Entre otros

Y después de esto, seleccionar los proyectos a desarrollar.

Inmediatamente debemos valorar nuestro proyecto a través de la factibilidad del
mismo, para lo cual definimos nuestros objetivos enfocados a:


• Automatización de procedimientos
• Reducción de errores
• Aceleración de la captura de datos
• Reducción del tiempo de procesamiento de datos
• Actualización del servicio al cliente
• Integración de los subsistemas del negocio
• Reducción de las salidas del sistema

Una vez, que contamos con nuestros objetivos, evaluamos si es factible nuestra
organización operativa, si económicamente es viable, y si técnicamente es posible
llevarlo a cabo. Para pasar a la determinación de los recursos.

El analista debe ser una persona ordenada, para lo cual tiene que administrar los
tiempos del desarrollo del proyecto, tanto en el análisis, diseño e implantación,
apoyándose de herramientas como son el uso de diagramas de Gannt y el uso de graficas
de PERT.


El analista debe tener la capacidad de administrar los recursos humanos que participan
en el proyecto, para lo cual lleva a cabo estrategias de comunicación para el manejo de
los grupos como son:

• Identificación con lo que el grupo produce
• Responsabilización del desempeño del grupo
• Integración del grupo en la organización
• Motivar la protagonización de múltiples papeles
• Establecimiento de metas de productividad del proyecto
• La motivación de los integrantes de grupos de proyectos
• Evitar el fracaso del proyecto

Regresar

Análisis de los requerimientos
de información
• Recopilación de
información: Métodos
interactivos
a. entrevistas,
b. cuestionarios
• Recopilación de
información: Métodos
no intrusitos
(muestreo,
investigación,
observación)
• Elaboración de
prototipos
Regresar

Recopilación de Información:
Métodos interactivos (entrevistas)
Antes de realizar la entrevista, necesita pensar en ella. Analizar el motivo de la
misma, cuáles serán las preguntas que hará, y desde su punto de vista, qué es lo
que brindará el éxito a la entrevista.
I. Tipos de información buscada: Una entrevista para la recopilación de
información es una conversación dirigida con un propósito específico, que se basa
en un formato de preguntas y respuestas. Sobre todo esto, busque la opinión de la
persona entrevistada. Las metas son una fuente importante de información, y
pueden identificarse a partir de una entrevista.
II. Planeación de la Entrevista
A. Preparación de la Entrevista
1. Lectura de antecedentes: Consulte y comprenda el mayor número posible de
antecedentes de los entrevistados y de su organización. Otro de los
beneficios de explorar de antemano la organización es aprovechar al máximo
el tiempo de la entrevista, más que desperdiciarlos al hacer preguntas
generales sobre los antecedentes.
2. Establecimiento de objetivos de la entrevista: Establezca los objetivos de
la entrevista con base en los antecedentes que consulte y en su experiencia
particular.

3. Selección de los entrevistados: Incluya a gente clave de todos los niveles
del sistema
4. Preparación del entrevistado: Las entrevistas deben fluctuar entre 45
minutos y una hora
5. Selección del tipo y estructura de las preguntas: Redacte preguntas que
cubran los aspectos fundamentales de la toma de decisiones, detectados al
plantear los objetivos de la entrevista.
a. Tipos de preguntas
(1) Abiertas
(2) Cerradas
(3) Sondeos
b. Errores en las preguntas
(1) Tendenciosas: Las preguntas tendenciosas tienden a dirigir al
entrevistado hacía la respuesta que usted quisiera escuchar
(2) Dobles: Las preguntas dobles son aquellas que en una sola contienen,
de hecho, dos preguntas diferentes.

(3) Orden de preguntas
a) Piramidal: La organización inductiva de la entrevista puede
concebirse como una pirámide ( de lo particular a lo general.
b) Embudo: En el segundo tipo de estructuras, el entrevistador
toma el enfoque deductivo, comenzando con preguntas abiertas
de carácter general; y más adelante, va reduciendo las posibles
respuestas mediante el uso de preguntas cerradas.
c) Diamante: Es mejor una combinación de las dos estructuras, lo
que da por resultado una entrevista con estructura en forma
de diamante. Esto permite comenzar de una manera muy
específica, luego examinar aspectos generales y finalmente
llegar a una conclusión muy específica.
B. Estructuradas vs No estructuradas: Estar consciente de las diferencias entre
las entrevistas estructuradas y las no estructuradas le permitirán tomar la
mejor decisión sobre el tipo más adecuado para una situación particular.
C. Registro de la entrevista: Registre los aspectos más importantes de su
entrevista.

1. Uso de grabadora: La decisión de grabar las entrevistas es de tipo
profesional y usted tendrá que hacerla con base en su conocimientos sobre las
entrevistas, la posición del entrevistador al respecto, y el proyecto en
particular.
2. Toma de notas: Tomar notas puede ser la única alternativa para documentar
la entrevista
3. Antes de la entrevista: Confirmar el lugar y la hora de la entrevista, vístase
de manera adecuada.
III. Realización de la entrevista
A. Comienzo de la entrevista: Conforme transcurra el programa de la entrevista,
mencione a su interlocutor el grado de detalle que desearía tener en las
respuestas.
B. Solución de problemas durante la entrevista
a) Percepción de que la autoestima del entrevistado se encuentre
amenazada: En ocasiones, se dará cuenta de que amenaza (sin
intención) la autoestima de la persona que entrevista.
b) Reacciones emotivas a temas conflictivos: La reacción emocional
ante un tema conflictivo.

c) Malentendidos respecto a la sucesión de los acontecimientos: Los
errores en la apreciación cronológica de los acontecimientos también
implican problemas potenciales.
d) Apego a formas sociales tradicionales: Apegarse a las formas
sociales tradicionales puede llegar a crear obstáculos en la respuesta
de entrevistado.
e) Equívocos al inferir sobre lo observado: Este error ocurre cuando su
entrevistado observa algo pero infiere otra cosa.
f) Competencia por el tiempo: Hay competencia por el tiempo de la
entrevista, pregunte al entrevistado si tiene asuntos que atender que
no lleven demasiado tiempo; y si así fuera, ofrézcale esperar a su
conclusión. Si la competencia del tiempo está fuera de control, la
mejor táctica será hacerle saber a su interlocutor que: “Me doy
cuenta que es un día extremadamente ocupado para usted y preferiría
reprogramar nuestra cita para otra ocasión con menos interrupciones”.
g) Olvido de hechos importantes: Puede decirse que sus entrevistados
han caído en el olvido, cuando vacilan continuamente o se contradicen a
lo largo de la entrevista.

h) Mentir para ocultar hechos importantes La garantía de una
información de alta calidad debe ser siempre una alta prioridad para
los analistas de sistemas, ya que la información recopilada es la base
de las demás decisiones que se van a tomar a lo largo del proyecto.
i) Conclusión de la entrevista: Todo material de la entrevista debe
cubrirse en un periodo de 45 minutos a una hora y a esta altura, ya
estará consiente de la planeación y del manejo requerido para lograrlo.
IV. Reacción del informe de la entrevista
Captar la esencia de la entrevista en un informe escrito

Solucuón de
Persepción de que la Comienzo de la
Malentendidos probemas durante la
autoestima del entrevista
respecto a la sucesión entrevista Dobles
entrevistado se encuentre
de los acontecimientos
amenazada

Selección de los
Establecimiento Errores en
Preparación del entrevistados
de objetivos de la las
entrevistado Tendenciosas
entrevista preguntas

Apego a formas Piramidal
sociales
tradicionales Tipos de
información
Estructuradas
buscada Selecció del tipo
vs No y estructura de Orden de Embudo
estructuradas Preparacion de las preguntas preguntas
la Entrevista

Diamante

Olvido de hechos Realizacion de
importantes Entrevista Tipos de Abiertas
la entrevista Lectura de
preguntas
Planeación de Antes de la antecedentes
la Entrevista entrevista

Cerradas
Sondeos
Toma de
Competencia Reacción del Registro de la
informe de la notas
por el tiempo entrevista
entrevista

Uso de
grabadora
Mentir para Equivocos al Reacciones
ocultar hechos Conclusión de emotivas a temas
inferir sobre lo
importantes la entrevista conflictivos
observado

Regresar

Recopilación de Información: Métodos
interactivos (Cuestionario)
Los cuestionarios recogen opiniones, posturas, conductas y características de las
diversas personas claves de una organización; la opinión es lo que se piensa de la
realidad; la conducta es lo que hacen los miembros de una organización, y las
características son los atributos de las personas o de los objetos.
I. Diseño de cuestionarios: Un cuestionario bien diseñado y de relevancia elimina
cierta resistencia para responder.
II. El formato de cuestionario
A. Suficiente espacio en blanco
B. Especio adecuado para las respuestas
C. Círculos para respuestas
D. Establecer el formato conforme a objetivos: Necesita definir sus objetivos
E. Estilo consistente: Organice de manera consistente el cuestionario, utilice
letras mayúsculas y minúsculas para las preguntas y sólo mayúsculas al referirse
a las respuestas.
III. Orden de preguntas: Al ordenar las preguntas debe considerar sus objetivos y
determinar la función que tiene cada una de las preguntas para lograr tales
objetivos.

A. Las preguntas de importancia para quien contesta el cuestionario van
primero: Deben sentir que al contestar el cuestionario, motivarán un cambio, o
que llegarán a tener cierto impacto.
B. Agrupar preguntas del mismo tema: Colocar preguntas relacionadas con un
tema común.
C. Uso de tendencias asociativas: Asociaciones que realice quien responde.
D. Plantear primero los temas de menor controversia: Plantear al inicio del
cuestionario, los temas de menor controversia, ydeje para más adelante, otros
temas polémicos o explosivos.
IV. Aplicación del cuestionario
A. Personas que responden el cuestionario: El muestreo ayuda para determinar el
tipo de representación que le conviene, y asimismo, qué personas deben recibir
el cuestionario.
B Métodos para la aplicación del cuestionario: El analista de sistemas, cuenta
con varias alternativas para aplicación de cuestionario. Dentro de las opciones
que se tienen para aplicar un cuestionario están:
a Reunir a todas las personas en un solo sitio.

b Entregar personalmente los cuestionarios en blanco y recogerlos una ves que
encuentren completos.
c Permitir a quienes contestan el cuestionario que durante las horas de trabajo
lo respondan por su cuenta y posteriormente lo depositen en un buzón central.
d Enviar por correo el cuestionario a aquellos empleados de sucursales remotas,
estableciendo una fecha límite, proporcionando instrucciones y el reembolso
postal.
V. Uso de cuestionarios
A. Tipos de información buscada
B. Plantación para el uso de cuestionarios: La planeación de un cuestionario útil
requiere bastante tiempo, lo primero que debe definir es qué busca un
cuestionario.
1. Redacción de preguntas: Durante la entrevista se mantiene la relación entre
la pregunta y su significado, en los cuestionarios las preguntas deben ser
completamente transparentes.

2. Preguntas abiertas: Cuando redacta preguntas abiertas para un cuestionario,
se anticipa al tipo de respuesta que piensa obtener. Las preguntas abiertas
son adecuadas, en especial, en aquellas circunstancias en que desea conocer la
opinión de los miembros de una organización sobre algunos aspectos del
sistema,
3. Preguntas cerradas: Las preguntas cerradas deben utilizarse cuando el
analista de sistemas sea capaz de enumerar de antemano todas las respuestas
posibles.
4. La elección del vocabulario: La selección de las palabras también es de gran
relevancia para lograr que los cuestionarios sean efectivos.
C. Uso de escalas en cuestionarios: Escalar es el proceso de asignar números u
otros símbolos a un atríbuto o característica con el fin de poder medirlo.
1. Fundamentos de las escalas
a. Razones para escalas: Si el analista desea medir actitudes o
características de los que responden un cuestionario, las respuestas
pueden combinarse o agruparse para que nos informen de tales
actitudes de las personas.
b. Mediciones:
• Las escalas nominales se utilizan para clasificar objetos.

• Las escalas ordinales permiten la clasificación, la escala ordinal
implica además un arreglo por categorías.
• Las escalas de intervalo tienen como característica que la
diferencia que existe es la misma entre los intervalos de cada
uno de los números, las operaciones matemáticas pueden
realizarse sobre datos del cuestionario.
• Las escalas proporcionales son similares a las de intervalo sin
embargo cuentan con un cero absoluto.
c. Valides y confiabilidad: Existen dos parámetros de desempeño; la
validez y la confiabilidad., la validez es el grado con el que la pregunta
determina lo que el analista intenta medir, la confiabilidad es un
parámetro de consistencia.
2. Elaboración de escalas
a. Opciones para la elaboración de las escalas
• La escala arbitraria supone que la escala mide lo que él intenta
medir.
• La escala por consenso involucra a un grupo de jueces.

• La factorización es el procedimiento estadístico por medio del
cual se agrupan objetos similares.
b. Como evitar problemas durante el uso de escalas
• La indulgencia se presenta cuando los que responden los
cuestionarios son poco evaluadores.
• La tendencia central es un problema que se presenta cuando el
que responde califica todo como un promedio.
• El efecto de halo es un problema que surge cuando la impresión
que deja una pregunta se acarrea a la siguiente.
D. Uso de Arreglos-Q: La estructuración de un arreglo-Q, en el cual fuerza a que
las respuestas se apeguen a una distribución normal, que es adecuada para agrupar
a los que responden, con base en sus opiniones sobre el tópico particular.
1. Técnica de arreglos-Q: El arreglo.Q se utiliza para identificar subgrupos
dentro de una población.
2. Ventajas de la técnica de arreglos-Q
3. Lineamientos para el uso de la técnica de arreglos-Q

Las p reguntas Pregunt as
Agrup ar
de imp o rtancia La elección d el
p regunt as del Ventajas de la cer radas
p ar a quien Técnica de vocabulario
mis mo t ema arr eglos -Q técnica d e
con testa el
arr eglos -Q
cuestinario v an
p rimero

Us o de
ten dencias
Lin eamientos Pregunt as
aso ciativ as
p ar a el u so d e abiertas
Us o de Planeacion
la t écnica de
Ar reglos -Q p ar a el u so d e
arr eglos -Q
cuestion arios
Or den d e
Plantear p regunt as
p rimero los
temas d e
menor
con trov ersia Us o de
cuestion arios
Dis eño de Tip os d e
cuestion arios Dis eño y
inf ormacion
ap licació n de Redacción de
Suf icien te bus cada
cuestion arios p regunt as
esp acio en
blanco
Us o de escalas
en
El formato de cuestion arios
Esp ecio
adecuad o cuestion ario Fu ndamentos
p ar a las de las es calas
Ap licacion d el
res p ues tas cuestion ario Valides y
con fiabilidad

Elaboración d e
Cir culos p ara escalas
res p ues tas

Est ablecer el M etodo s p ar a
Per sonas que Op ciones p ara Co mo evitar
for mato la ap licación Razones p ara M edicio nes
Est ilo res p ond en el la elabor acion p ro blemas
con forme a del escalas
cuestion ario de las es calas dur ante el us o
objetivo s con sistente cuestion ario
de escalas

Regresar

Recopilación de Información: Métodos no
intrusitos (muestreo, investigación, observación)

Muestreo y la investigación de datos
I Necesidad del muestreo: El muestro es el proceso por el cual se seleccionan de
manera sistemática elementos representativos de una población. Para el analista
de sistemas sería demasiado costoso examinar cada nota escrita o entrevistarse
con cada uno de los integrantes de una organización. El muestro agiliza el proceso,
por medio de la recopilación de datos seleccionados, y no de todos los datos de la
población. Lo anterior se logra al entrevistar a sólo unos cuantos empleados, pero
haciéndose preguntas precisas.
II. Diseño del muestreo
A. Determinación de los datos a recopilar: El analista de sistemas debe
contar con un plan realista sobre lo que hará con los datos, aun antes de
llevar a cabo la recopilación
B. Delimitar la población a estudiar: El analista de sistemas deberá
establecer cuál en la población enfocada. El analista de sistemas tiene que
definir si la población incluye un solo nivel de la organización, o si considera
todos los niveles.
C. Elección de tipo de muestra
1. Oportunidad: Las muestras de oportunidad son deterministas y no
tienen restricciones ni soporte probalístico


2. Dirigidas: Un analista de sistemas puede elegir a un grupo de
individuos que conozcan y estén interesados en el nuevo sistema de
información.
3. Aleatorias simples: Obtener una lista numerada de la población
para asegurar que cada uno de los documentos o integrantes de la
población tiene la misma probabilidad de ser elegido.
4. Aleatorias complejas: Para el analista de sistemas, los enfoques
más adecuados son:
1) muestro sistemático,
2) muestreo estratificado,
3) muestreo por grupos
D Decisión del tamaño de la muestra: El analista de sistemas puede elegir
un intervalo estimado aceptable (esto es, el grado de precisión deseado) y
el error estándar (al elegir el nivel de confianza).
1. Tamaño para datos de atributos: El analista de sistemas querrá
saber qué proporción de la organización piensa de cierta manera o
cuenta con características particulares. El analista deseará saber
qué porcentaje de las formas de entrada presentan errores. Estos
datos se denominan atributos.


2. Tamaño para datos de variables: El analista de sistemas puede
necesitar la recopilación de información de carácter cuantitativo,
como el número de errores procesado. A este tipo de datos se les
denomina variables.
3. Tamaño para datos cualitativos: Una buena parte de la
información no puede obtenerse mediante la consulta de archivos.
Esta información mejor se obtiene entrevistando a gente de la
organización.


Tipos de Información Obtenidos
III. Tipos de datos concretos: Los datos concretos revelan la trayectoria de la
organización y hacia dónde se dirige según sus miembros
A. Análisis de documentos cuantitativos: Son todos los documentos que
tienen un propósito y una audiencia especifica hacia la cual se dirigen, como
son:
1. Informes corporativos: Hay varios tópicos clave, si la compañía es
solvente, si obtiene utilidades, si le confiere una distinción a la
investigación y al desarrollo; y si existe un equilibrio entre pasivos y
capital.
2. Informes que soportan la toma de decisiones: Un analista de
sistemas debe consultar algunos de los documentos que se utilizan
en la operación de la empresa. Estos documentos comúnmente son
informes del status de los inventarios, de las ventas o de la
producción.
3. Informes de desempeño: Los informes de desempeño comparan los
resultados reales con los planeados, el desempeño actual y el
desempeño esperado. El analista querrá saber si existe un
parámetro del desempeño y si éste es el más conveniente para las
áreas básicas de la organización.


4. Registros: Los registros contienen actualizaciones periódicas de lo
que ocurre en la empresa.
5. Formas para captura de datos: El analista debe comprender la
operación vigente, para lo cual se recopilan y catalogan copias en
blanco de cada una de las formas (oficiales o extraoficiales) que se
utilizan, otro enfoque sería tomar muestras de las formas llenadas
para la captura de datos.
Mediante el estudio de las formas se averigua entre otros: si la
información no fluye, cuellos de botella, duplicidad innecesaria en el
trabajo o falta de comprensión del trabajo.
B. Análisis de documentos cualitativos: Su análisis se vuelve fundamental
para comprender cómo los integrantes de la organización están involucrados
en el proceso de la organización y estos son:
1. Memorándums: Los memorándums revelan el diálogo vivo de la
organización, su análisis proporciona una idea clara de los valores,
las actitudes y creencias de los miembros de la organización.
2. Avisos en tableros y áreas de trabajo: Dan al analista una idea de
la cultura oficial de la organización.


3. Manuales: Dan la pauta de cómo deberían ocurrir las cosas:
Verificar que estén actualizados y si han tenido seguimiento o si se
tienen en el olvido.
4. Manuales de políticas: Son los lineamientos generales que plantean,
de manera ideal, la conducta a seguir de los miembros de la
organización, con el fin de alcanzar las metas estratégicas.
C. Obtención de datos a partir de documentos de archivo: Gran parte de la
información, tanto cuantitativa como cualitativa, que necesitará, no es de
uso corriente; más bien, se encontrará almacenada en archiveros. Ejemplos
de información de archivo que puede ser de interés para el analista de
sistemas son los registros actuariales, los presupuestos y los informes de
ventas.


Formas
Registros
para
Necesidad del captura de
muestreo datos
Tamaño para Delimitar la
Determinacion
datos de población a
de los datos a
atributos
recopilar estudiar
Informes de
Analisis de desempeño
Obtención de
datos a partir documentos
cuantitativos
de documentos
de archivo
Informes
que
Decisión del Muestreo y la soportan la
Diseño del Tipos de
tamaño de la investigación de datos Informes toma de
muestreo
muestra datos corporativos decisiones
Tamaño para concretos
datos de
variables

Oportunidad Elección de tipo Manuales de
de muestra políticas

Tipos de Analisis de
Información documentos
Obtenidos cualitativos

Manuales
Tamaño para
datos Aleatorias Aleatorias
Dirigidas
cualitativos complejas simples

Avisos en
tableros y
Memorándums áreas de
trabajo

Regresar

Elaboración de prototipos
El desarrollo de prototipos es una técnica de recopilación de información útil para
complementar al ciclo de vida del desarrollo de sistemas (Systems Development Life
Cycle, SDLC) tradicional. Los prototipos son una visión preliminar del sistema futuro que
se implantara.
La elaboración de prototipos de un sistema de información es una técnica valiosa para la
recopilación rápida de información especifica a cerca de los requerimientos de
información de los usuarios.
Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del
desarrollo de sistemas, durante la fase de determinación de requerimientos.
En esta forma el analista esta buscando las reacciones iniciales de los usuarios y de la
administración hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza
del sistema para el que construye un prototipo, posibles innovaciones y planes de
revisión que detallan que parte del sistema necesita realizarse primero.
Tipos de Información que busca el Analista durante la Elaboración de Prototipos.
 Reacciones del usuario.
 Innovaciones.
 Sugerencias del usuario.
 Plan de revisión.

Reacciones: Son recopiladas por medio de observaciones, entrevista y formas de
retroalimentación, diseñadas para recoger la opinión de cada persona acerca del
prototipo cuando interactuá con él.
Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo
incluyendo el agrado que tenga el usuario al sistema.
Sugerencias: El analista también esta interesado en las sugerencia de los usuarios y la
administración acerca como refinar o cambiar el prototipo presentado. Las sugerencias
son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de
tiempo especifico.
El tiempo que pasan los usuarios con el prototipo depende por lo general de su
dedicación e interés en el proyecto de sistemas. Las sugerencias son el producto de la
interacción de los usuarios con el prototipo. Estas sugerencias deben apuntar al analista
hacia formas de refinación, cambio o limpieza del prototipo para que se ajuste mejor a
las necesidades de los usuarios.
Innovaciones: Son parte de las informaciones buscada por el equipo de análisis de
sistema. Son capacidades nuevas del sistema que no habían sido pensadas antes de la
interacción con el prototipo.
Van más allá de las características prototípicas actuales añadiendo algo nuevo e
innovador.

Plan de Revisión: Ayuda a identificar prioridades para lo que se debe construir un
prototipo a continuación. En situaciones donde están involucradas muchas ramas de la
organización, los planes de revisión ayuda a determinar para cuáles hay que construir un
prototipo a continuación.
La información recolectada en la fase de hechura del prototipo permite al analista
asignar prioridades y redirigir los planes sin realizar gastos con un mínimo de ruptura.
La elaboración de prototipo y la planeación van mano a mano.

TIPOS DE PROTOTIPO
Prototipo de Remiendo o Parchado: Es un sistema que tiene todas las características
propuesta pero es realmente un modelo básico que eventualmente será mejorado. Este
tipo de prototipo trabaja pero no es eficiente ni elegante.
Prototipo a escala no Operacional o no funcional: La segunda concepción de un
prototipo es la de un modelo o escala no funcional para objeto de probar determinados
aspectos del diseño. Este puede ser hecha cuando la codificación requeridas por las
aplicaciones es muy amplia para hacerse el prototipo y, sin embargo se puede obtener
una idea útil del sistema por medio de la elaboración de prototipos de la entrada y
salida solamente.
Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido
al costo y tiempo excesivo podría no ser realizado, sin embargo se puede tomar algunas
de las utilidades del sistema con base en la entrada y salida ya en el prototipo.
Prototipo Primer modelo a escala completa: Una tercera concepción de la elaboración
de prototipos involucrados la creación de un primer modelo o escala completa de un
sistema, llamado también piloto.
Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo
sistema. El modelo funcional o escala completa permite la interacción realista con el
nuevo sistema, pero minimiza el costo de superar cualquier problema que presente.

Prototipo de Características Seleccionadas, modelo que cuenta con ciertas
características esenciales: Un prototipo de características seleccionada permite que
el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en
fecha posterior.
Se refiere a la construcción de un modelo operacional que incluye algunas, pero no
todas, de las características que tendrá el sistema final.
Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos,
de modo que si las características reciben una evaluación satisfactoria, éstas puedan
incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo
inmenso en interfaces. Los prototipos hechos en esta forma son parte del sistema
actual, no son simplemente una maqueta.

DESARROLLO DE UN PROTOTIPO
Cuando haya que decidir si hay que incluir la elaboración de prototipos como parte del
ciclo de vida de desarrollo de sistemas, el analista necesita considerar cuál tipo de
problema esta siendo resuelto y en qué forma el sistema presenta la solución.
Lineamientos para el Desarrollo de un Prototipo:
 Trabajar en módulos manejables.
 Construir el prototipo rápidamente.
 Modificar el prototipo en interacción sucesiva.
 Enfatizar la interfaz del usuario.
Trabajar en Módulos Manejables: Es bueno que el analista en modelos manejables
cuando se realiza el prototipo de algunas de las características de un sistema para
obtener un modelo funcional.
Un modelo manejable es aquel que permite la interacción con sus características
principales, pero todavía puede ser construido por separado de otros módulos del
sistema. Las características del módulo que se consideran menos importantes son
intencionalmente dejadas fuera del prototipo inicial.

Construcción Rápido del Prototipo: La velocidad es esencial para la elaboración
satisfactoria de un prototipo en un sistema. El prototipo ayuda a acortar el tiempo de
la interacción del sistema con el usuario para que pueda empezar a experimentar con él.
Se usan técnicas de recolección de información tradicional tales como: entrevistas, las
observaciones e investigaciones de datos de archivo.
La elaboración de un prototipo debe llevarse a cabo en una semana, para construir un
prototipo tan rápidamente se deben de usar herramientas especiales tales como: Los
sistemas de administración de las base de datos y software, existente que permitan la
entrada y salida generalizada.
En esta etapa del ciclo de vida el analista sigue recopilando información acerca de lo que
se necesita y quieren los usuarios del sistema.
El poner un prototipo operacional rápidamente junto a las primeras etapas del ciclo de
vida de desarrollo de sistemas, permite obtener observaciones valiosas sobre la manera
en que se debe realizar el resto del proyecto. De este modo se le va mostrando al
usuario como actúan las partes del sistema.
Modificaciones del Prototipo: Un tercer lineamiento para el desarrollo del prototipo es
que debe ser flexible para futura modificaciones. Esto significa crearlo en módulos que
no sean muy interdependientes.

Por lo general el prototipo es modificados varias veces pasando a través de varias
interacciones. Los cambios al prototipo deben mover al sistema más cerca a lo que los
usuarios dicen que es importante.
Cada modificaciones necesitan otras evaluaciones de los usuarios, estas modificaciones
se deben realizar velozmente en uno o dos días, esto depende también del usuario y que
tan rápido sea su evaluación.
Enfatizar la Interfaz de Usuarios: La interfaz del usuario con el prototipo (y
eventualmente con el sistema) es muy importante debido que lo que se esta tratando
realmente de lograr con el prototipo es hacer que los usuarios muestren cada vez más
sus requerimientos de información, debe ser capas de interactuar fácilmente con el
prototipo del sistema.
El objetivo del analista es diseñar una interfaz que permita al usuario interactuar con el
sistema con un mínimo de entrenamiento y que permita el máximo de control del usuario
sobre las funciones representadas.

DESVENTAGAS DE LOS PROTOTIPOS
Puede ser bastante difícil el manejar el prototipo como un proyecto dentro de un
esfuerzo para un sistema más grande.
Es que si un sistema es muy necesario y es bienvenido rápidamente , puede ser aceptado
el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin
los refinamientos necesarios. En este caso el prototipo no tendrá las funciones
necesarias y eventualmente cuando se de cuenta de la deficiencias se puede
desarrollar un rechazo del usuario.

VENTAJAS DE LOS PROTOTIPOS
Cambio de un Sistema en Etapas Tempranas de sus Desarrollo: La elaboración de
prototipos satisfactoria depende de la retroalimentación temprana y frecuente de los
usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta más
ágil a las necesidades actuales. Los cambios tempranos son menos caros que los
cambios hechos posteriormente en le desarrollo del proyecto.
Desechado de Sistemas Indeseables: Una segunda ventaja del uso de prototipos como
una técnica para la recopilación de información es la posibilidad de desechar un sistema
que no es lo que los usuarios y analistas esperaban.
Diseño de un Sistema para las Necesidades y Expectativas de los Usuarios: Una tercera
ventaja de la elaboración de prototipos es que el sistema que está siendo desarrollado
debe ajustarse mejor a las necesidades y expectativas de los usuarios . Esto quiere
decir que se pueden atacar las necesidades de usuarios y expectativas más de cerca.

PAPEL DEL USUARIO EN LOS PROTOTIPOS
Hay tres formas principales en que un usuario puede ser de ayuda en la elaboración del
Prototipo.
 Experimentando con el Prototipo.
 Reaccionar abiertamente ante el Prototipo.
 Sugiriendo adiciones y/o eliminaciones del prototipo.
Experimentando con el Prototipo: Los usuarios deben tener libertad para
experimentar con el prototipo, y no una simple lista de características del sistema, el
prototipo permite a los usuarios la realidad de la interacción real.
Los analista deben estar presente la mayor parte del tiempo en que se este
experimentando con el prototipo.
Reaccionar Abiertamente ante el Prototipo: Si los usuarios se siente temerosos de
hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o
iguales dentro de la organización, es poco probable que se de reacciones abiertas ante
el prototipo. Una forma para aislarlos de influencias organizacionales no deseada es
proporcionar un periodo privado, para que los usuarios interactúen con y respondan al
prototipo.

El hacer que los usuarios se sienta lo suficientemente seguros para dar una reacción
abierta es parte de la realización entre los analista y usuarios que el equipo tiene que
construir.
Sugerencias de Cambios al Prototipo: Un tercer aspecto del papel de los usuarios en la
elaboración de los prototipos es sugerir adiciones y/o eliminaciones a las
características que se están probando. El papel del analista es deducir tales
sugerencias, asegurando a los usuarios que tal retroalimentación que proporciona es
tomada en serio, observando a los usuarios mientras interactúan y realizando
entrevistas cortas y específicas en relación con su experiencia con el prototipo.

Regresar

Proceso de Análisis

• Uso de diagramas de
flujo de datos
• Análisis de sistemas
mediante diccionarios
de datos
• Descripción de las
especificaciones de
procesos y decisiones
estructuradas
• Preparación de la
propuesta de sistemas

Regresar

Uso de diagramas de flujo de datos
Análisis del Flujo de Datos
Existen dos métodos principales para el análisis del flujo de datos de los sistemas
orientados a datos: los diagramas de flujo de datos y el diccionario de datos.
La estrategia del flujo de datos muestra el empleo de éstos en forma gráfica. Las
herramientas usadas para seguir esta estrategia muestran todas las características
esenciales del sistema y la forma en que se ajustan entre sí. Puede ser difícil
comprender en su totalidad un proceso de la empresa si se emplea para ello solo una
descripción verbal; las herramientas para el flujo de datos ayudan a ilustrar los
componentes esenciales de un sistema junto con sus interacciones.
El análisis de flujo de datos usa las siguientes herramientas:
Diagrama de flujo de datos (DFD)
Diccionario de datos
Una vez que se concluyen los diagramas de flujo de datos en distintos niveles sucesivos,
los analistas de sistemas los utilizan para ayudarse a catalogar los procesos, el flujo, el
almacenamiento, las estructuras y los elementos en un diccionario de datos. Los
nombres utilizados para identificar los datos son de gran importancia. Los analistas de
sistemas, al nombrar a los elementos de los sistemas orientados a datos, deben utilizar
nombres significativos que los distingan de otros nombres ya existentes en el sistema.

Diagramas de flujo de datos
Es una herramienta gráfica que se emplea para describir y analizar el movimiento de los
datos a través de un sistema, ya sea este manual o automatizado, incluyendo procesos,
lugares para almacenar datos y retrasos en el sistema. Los DFD, como se les conoce
popularmente son la herramienta más importante y la base sobre la cual se desarrollan
otros componentes. La transformación de datos de entrada en salida por medio de
procesos puede describirse en forma lógica e independiente de los componentes físicos
(computadoras, gabinetes de archivos, y procesadores de texto) asociados con el
sistema.
Notación: los DFD se pueden dibujar con solo cuatro notaciones sencillas, a saber:
Flujo de datos: movimiento de datos en determinada dirección, desde un origen hasta un
destino en forma de documentos, cartas, llamadas telefónicas o virtualmente cualquier
otro medio. El flujo de datos es un “paquete de datos”

Procesos: personas procedimientos o dispositivos que usan o producen (transforman)
datos.

Fuente o destino de datos: fuentes o destinos externos de datos, que pueden ser
personas, programas, organizaciones u otras entidades que interactúan con el sistema
pero que se encuentran fuera de sus fronteras. La diferencia fundamental con los
procesos es que las fuentes o destinos no transforman información, al menos no dentro
de las fronteras del sistema que se está modelando

Almacenamiento de datos: es el lugar donde se guardan los datos o al que referencian
los procesos en el sistema. El almacenamiento de datos puede representar dispositivos
tanto computarizados como no computarizados.

Los DFD se concentran en el movimiento de los datos a través del sistema, no en los
dispositivos o el equipo. Los analistas identifican y describen, desde el inicio hasta del
final proceso, para comprender un área de aplicación o los datos que fluyen por todo el
sistema y entonces explican por qué los datos entran o salen y cuál es el procesamiento
que se realiza con ellos. Es muy importante determinar cuándo entran los datos al área
de aplicación y cuándo salen de ésta.

A medida que los analistas reúnen hechos y detalles, comprenden mejor el proceso; esto
los conduce a formular preguntas relacionadas con aspectos específicos del mismo y los
lleva a una investigación adicional. La investigación se divide en detalles que tienen cada
vez un nivel menor hasta que se comprenden todos los componentes esenciales junto con
sus interrelaciones.
Lo que se quiere dar a entender con esto, es que una investigación de sistemas produce
muchos conjuntos de DFD, algunos (los primeros) brindan panoramas de procesos
importantes, mientras que otros (los que se obtienen de los primeros) nos muestran con
bastante detalle elementos dato, almacenes de datos y pasos de procesamiento para
componentes específicos de un sistema grande.
A los primeros diagramas obtenidos se les conoce como diagramas de alto nivel,
mientras que a los resultantes de estos se les conoce como diagramas de bajo nivel.
En este sentido el primer diagrama que se obtiene se le conoce con el nombre de
diagrama de contexto, es un diagrama de nivel muy general (alto nivel); es también
conocido como diagrama de nivel 0. Contiene un solo proceso pero juega un papel muy
importante en el estudio del sistema en uso; ya que define fronteras. Todo lo que no se
encuentre dentro de las fronteras identificadas en el diagrama no forman parte del
estudio de sistemas.
Cada flujo de datos (cada flecha) emplea una etiqueta que describe que datos emplea.
Cuando los datos se mueven de un lugar a otro el flujo de datos apunta hacia el lugar
donde se dirige el flujo.

Ejemplo:
Un sistema está formado por varias actividades o procesos, cada uno de los cuales
contiene varios sub-procesos con marcadas interrelaciones entre ellos. Por ejemplo un
proceso de cuentas por pagar puede estar integrado por tres sub-procesos que podrían
llamarse: autorización de la factura, revisión del adeudo en la cuenta y elaboración del
cheque.
A su vez cada sub-proceso se divide en sub-procesos más específicos.
Los nombres dados a los procesos especifican acciones y procedimientos de control que
realizan
Cada proceso se etiqueta además con un número que identifica de donde proviene
(excepto el diagrama de contexto que solo se identifica con un nivel 0 más el nombre
que se le proporcione)
En términos generales todo componente de los DFD se etiquetan con un nombre que
sea representativo.
Primer nivel del DFD
En el primer nivel, es muy importante identificar los principales procesos, y flujos que
dan en forma conjunta sentido operacional al sistema que se está modelando.

Algunos analistas consideran ventajoso trabajar primero con todos los flujos de datos y
asignar, como ya se dijo nombres que sean significativos y descriptivos. Se identifican
todos los procesos, como ya se mencionó pero no se les da nombre hasta que sean bien
entendidos todos los flujos de datos. Después cuando se les ha asignado nombre a los
procesos, si el analista tiene dificultas para ligar los flujos de datos con los nombres
apropiados entonces esta situación indica que es necesario dividir aun más el proceso.
Expansión de los procesos a diagramas de mayor nivel
Una vez que se ha desarrollado el sistema como está descrito en el diagrama de primer
nivel, es indudable que el analista formule preguntas en relación con la forma que se
lleven a cabo los procesos. (Ver documento de determinación de requerimientos) En
general se debe estar seguro de:
Todos los flujos de datos que explican el proceso en el diagrama previo deben incluirse
en el diagrama del siguiente nivel inferior
Los flujos y almacenes de datos nuevo se añaden si son usados internamente por el
proceso para eslabonar otros procesos introducidos por primera vez en la expansión de
este nivel. Se deben mostrar los flujos y almacenes de datos originados en el proceso
dentro en este nivel.
Ninguna entrada debe contradecir las descripciones de los DFD de niveles más altos (si
lo hacen uno o ambos son incorrectos y deben introducirse cambios)

En general la expansión de niveles depende de la naturaleza y complejidad del sistema
que se modele; no es posible especificar un número de niveles, en general se debe
continuar con el proceso de expansión todo lo que sea necesario para comprender los
detalles del sistema y la forma en que trabaja, teniendo cuidado de verificar todos los
aspectos con usuarios que conocen el sistema, en general, se debe expandir todo aquel
proceso que incluyen varias tareas para las que es necesario, el flujo de datos entre
diferentes personas o localidades. Por otra parte no requieren expansión aquellas tareas
que son realizadas por una persona o en un escritorio, donde no existe flujo de datos.
Reglas adicionales para el dibujo de DFD: ya se han identificado la mayor parte de los
lineamientos que se siguen para el dibujo de los DFD, he aquí algunas más:
Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que
entran al proceso
Todos los flujos de datos tienen un nombre que refleja los datos que fluyen entre
procesos, almacenes de datos, fuentes o destinos
Solo deben entrar al proceso, los datos necesarios para llevarlo a cabo
Un proceso no debe saber nada de ningún otro en el sistema, es decir debe ser
independiente, la única dependencia que debe existir es aquella basada en sus propios
datos de entrada y salida

Los procesos siempre están en continua ejecución, no se inician ni tampoco se detienen.
Los analistas siempre deben suponer que un proceso está listo para ejecutar su trabajo
La salida de los procesos puede tomar una de las siguientes formas
Flujo de datos con información añadida por el proceso (i.e: una anotación a una factura)
Una respuesta o cambio en la forma de los datos (i.e: un cambio en la forma de
expresar las utilidades -de ¢ a $-)
Un cambio de condición (i.e: de autorizado a no autorizado)
Cambio de contenido (i.e: integración o separación de la información contenida en uno o
más flujos entrantes de datos)
Cambios en la organización (i.e: separación física o redondeo de datos)
La norma común es definir cada nivel inferior en términos de 3 a 7 procesos para cada
proceso de nivel superior, si son necesarios más detalles se puede hacer en el siguiente
nivel.
Los almacenes y flujos de datos que son relevantes solo para el interior del proceso, son
ocultados hasta que el proceso se extiende con mayor detalle
Los datos que fluyen hacia los procesos experimentan cambios. Por consiguiente, el flujo
de datos de salida tiene un nombre diferente al de la entrada; si no se efectúa algún
cambio en el flujo de datos, entonces ¿cuál es la finalidad del proceso?

En cuanto a los nombres de los procesos lo más apropiado es escoger un verbo y un
sujeto que reciba la acción y no nombre generales que no digan nada. Si un nombre de
proceso es vago o complejo tal vez se deba subdividir el proceso aún más.
Por otra parte no se ha mencionado nada aún sobre controles en los DFD, no hemos
mencionado nada al respecto sobre como manejar errores o excepciones, por ejemplo el
procesamiento de facturas incorrectas. Aunque esta información es necesaria para el
análisis final, no es importante identificar todos los flujos de datos (los errores o
excepciones son también flujos de datos). Los diagramas secundarios (por debajo del
segundo o tercer nivel), deben mostrar el manejo de errores y excepciones del proceso.
Aun así ciertos detalles físicos como el día de la semana que se debe hacer un pago u
otros controles de este tipo son innecesarios en los DFD, puesto que no tienen nada que
ver con los aspectos lógicos y de datos de la determinación de requerimientos. Los
elementos importantes para comprender un proceso durante el análisis lógico de flujo
de datos, no son el número de copias que se requieren de un documento sino las
descripciones de los datos necesarios para llevar a cabo el proceso.

Regresar

Análisis de sistemas mediante
diccionarios de datos
DICCIONARIO DE DATOS
Un diccionario de datos es un catálogo, un depósito, de los elementos de un sistema.
Estos elementos se centran alrededor de los datos y la forma en que están
estructurados para satisfacer los requerimientos y las necesidades de la organización.
En él se encuentran la lista de todos los elementos que forman parte del flujo de datos
en todo el sistema.
Los analistas usan los diccionarios de datos por cinco razones principales:
1. Manejar los detalles en sistemas grandes
2. Comunicar un significado común para todos los elementos del sistema
3. Documentar las características del sistema
4. Facilitar el análisis de los detalles con la finalidad de evaluar las
características y determinar donde efectuar cambios en el sistema
5. Localizar errores y omisiones en el sistema
6. Contenido de un registro del diccionario:
Campos: es el nivel más importante de datos; ninguna unidad más pequeña tiene
significado para los analistas. La descripción de los datos debe ir acompañada por los
siguientes elementos:

Estructuras de datos: son un grupo de datos elementales que están relacionados con
otros y que en conjunto describen un componente del sistema. Los flujos de datos, o los
almacenes de datos son ejemplo de estructuras de datos. Dicho de otra forma si las
estructuras están en movimiento reciben el nombre de flujos y si son estéticas son
almacenes de datos. Se construyen sobre cuatro relaciones de componentes; que bien
pueden ser datos o estructuras de datos también. Se pueden usar las siguientes
combinaciones ya sea en forma individual o en conjunción con alguna otra:

• Relación secuencial
• Relación de selección
• Relación de iteración
• Relación opcional

Notación empleada en el Diccionario de datos: Se usa símbolos especiales con la
finalidad de limitar la cantidad de texto necesario empleado para describir las
relaciones entre los datos y al mismo tiempo mostrar con claridad las relaciones
estructurales.

La simbología empleada se describe a continuación:

Símbolo Significado Explicación Uso

= Es equivalente a Alias Denota sinónimos
+ Y Concatenación, componentes que Denota una relación
siempre están incluidos en una de secuencia
estructura
[] Uno u otro Define opciones entre los Denota una relación
componentes de una estructura de selección

{} Iteraciones de Define la repetición de un Denota una relación
componente de la estructura de iteración

() Opcional Define componentes de la Denota una relación
estructura que puede o no estar opcional
presente una sola vez

Los registros del diccionario de datos deben contener información referente a las
categorías siguientes:
1. El nombre y el sinónimo del dato: La manera de denominar al dato en la
mayoría de los programas, asi como el sinónimo
2. Las descripciones del dato: Descripción textual del dato elemental, que debe
ser concisa
3. Los datos elementales que se relacionan con el término
4. El rango permitido del dato: Incluir los distintos rangos y límites que se
aplican al elemento.
5. La longitud disponible en caracteres: Longitud permitida para el acceso de un
dato elemental. La longitud siempre se da en función del número de caracteres
impresos y no por la cantidad requerida de memoria
6. Una adecuada codificación: Se debe incluir su código si es que lo tiene, y el
significado de éste.
7. Cualquier otra información pertinente de edición: Es de gran utilidad el
diccionario de datos si cada entrada se registra de manera consistente, incluyendo
el nombre del dato, el sinónimo, su descripción, los elementos relacionados, el
rango, la longitud, la codificación, los elementos relacionados, el rango, la longitud,
la codificación y cualquier otra información necesaria para su edición

Se tienen cuatro pasos esenciales para integrar un diccionario de datos, los cuales son:

1. Incluir los procesos identificados en los diagramas de flujo
2. Catalogar los flujos básicos de datos y Almacenes de datos para la operación
adecuada de los procesos
3. Describa la estructura de los datos que existan dentro del sistema
4. Desglosar la estructura de los datos elementales

El diccionario de datos no será nunca un producto concluido, debe considerarse como
una actividad paralela al análisis y diseño de los sistemas.

Regresar

Descripción de las especificaciones de
procesos y decisiones estructuradas
Las especificaciones de procesos son creadas para los procesos primitivos en los
Diagramas de Flujos de Datos (DFD) así como para algunos procesos de más alto nivel
que explotan hacia un diagrama hijo.

La producción de especificaciones de procesos tiene tres objetivos fundamentales los
cuales son:
a) Minimizar la ambigüedad del proceso ya que permite al analista a aprender
la manera en que trabajan los procesos.
b) Obtener una descripción precisa de lo que se logra.
c) Validar los diseños del sistema para asegurarse que un proceso tenga todos
los flujos de datos para poder producir la salida.

Existen categorías de procesos que no necesitan especificaciones; estas categorías son
las siguientes:

a) Procesos que son de entrada o salida típica
b) Procesos que representan validación de datos simple
c) Procesos que usen códigos preescrito.

DESCRIPCIÓN DE PROCESOS:

• Se hace en base al resto de los componentes, en el momento en que se
pueden considerarse como primitivas funcionales.
• Nombre del proceso, descripción, entrada de datos, salida de datos,
resumen de la lógica.

El análisis de decisiones se enfoca a la lógica de las decisiones que se ejecutan dentro
de las organizaciones, con el fin de alcanzar sus objetivos.

En la toma de decisiones de nivel base, es donde las decisiones se encuentran
plenamente estructuradas.

Las condiciones, las alternativas de las condiciones, las acciones u reglas de acción
deben conocerse con el fin de diseñar sistemas para decisiones estructuradas. El
analista precisa primero las condiciones. Esto es, aquellos fenómenos que pueden
afectar el resultado de algo. En el siguiente paso, el analista de sistemas identifica las
opciones a las condiciones especificas por quien toma las decisiones.

Cada una de las acciones se encierra en un cuadro y las condiciones se circulan. Una vez
hecho lo anterior, se destacan los términos cuestionables, las ambigüedades, los
calificativos poco claros, ejemplo: “sin embargo”, “pero” y otros términos similares.

Con el fin de precisar los requisitos de información necesarios para el análisis de
decisiones, el analista de sistemas debe identificar los objetivos de la organización,
mediante un enfoque descendente.

Las condiciones, las alternativas de las condiciones, las acciones y reglas de acción
deben conocerse con el fin de diseñar sistemas para decisiones estructuradas. El
analista precisa primero las condiciones. Esto es, aquellos fenómenos que pueden
afectar el resultado de algo. En el siguiente paso, el analista de sistemas identifica las
opciones a las condiciones específicas por quien toma las decisiones. Estas alternativas
pueden ser tan simples como "si", "no", o pueden ser más descriptivas como "menos de
$50", "entre $50 y $100" y "mayores de $ 100".

Luego se identifican las acciones. Esto incluye cualquier instrucción que se requiera para
alcanzar el resultado de una o más de las condiciones anteriores. Todas las
instrucciones para la manipulación o el cálculo de valores, la impresión de los informes, o
aún el desglose de las transacciones en preguntas, serían acciones. Las acciones se unen
a las condiciones por medio de las reglas de acción, las cuales son los protocolos de
ejecución de las acciones requeridas.

Como ejemplo de reglas de acción tenemos en esta página un documento de primas de
seguro que se proporciona a los agentes de Compañía de Seguros Fortres:

Los seguros de los dueños de inmuebles dependen, por supuesto del tipo de política y
de la ubicación del inmueble, pero una vez que esto se determina existen otros
factores que incrementan o disminuyen la prima del seguro. Uno de los factores es la
construcción. Una casa de tabique ahorrará al dueño un 10% de la prima anual. Si se
cuenta con una alarma sonora, se reducirá un 5% de la tasa y calculada. También el
asegurado puede hacer elecciones que incrementarían la prima. Si el dueño desea
pagar por reposición, en lugar de valor depreciado, aumenta la base un 10%. El dueño
puede elegir el manejo de un deducible de $100 dólares, en lugar de un deducible de
$250 dólares; esto incrementará la prima en un 15 %.

El planteamiento anterior puede en primera instancia parase claro, pero un examen
cuidadoso revelará ambigüedades que requieren de una resolución previa a la conclusión
del análisis de la decisión.

El documento de primas se analiza para establecer las acciones y las condiciones. Una
vez hecho lo anterior, se destacan los términos cuestionables, las ambigüedades, los
calificativos poco claros, "sin embargo", "pero" y otros términos similares. Para aclarar
todo ello, debería realizarse una entrevista para organizar el proceso de la decisión.
Observe que las alternativas se encuentran más explícitas y las acciones son más
específicas, se definen la "base", se describen y se ordenan las reglas de acción.

Lenguaje Estructurado

Esta técnica se utiliza cuando las decisiones no son complejas. El lenguaje estructurado
se basa en: la lógica estructurada o en instrucciones que se organizan en procesos
agrupados cíclicos y en planteamientos sencillos del idioma español tales como sumar,
multiplicar, mover y otros similares.

Para escribir en lenguaje estructurado es recomendable usar las siguientes
convenciones:

a) Toda la lógica debe estar expresada en términos de estructuras secuenciales,
estructuras de decisión, de casos o iteraciones

b) Dejar sangría en los bloques de enunciados para así demostrar la jerarquía.

c) Cuando hayan palabras definidas en el diccionario de datos, dichas palabras
deben ser subrayadas para indicar que tienen un significado especializado.

d) Hay que tener cuidado al utilizar “y” o “o” para que no se confunda con “mayor
que” o “menor que”

El ejemplo anterior de la Compañía de Seguros Fortress hace uso del lenguaje
estructurado, esto lo podemos observar en la tabla 5.2.1. En ella se ordenan con una
secuencia las reglas de decisiones y a todo lo largo se hace uso de la cláusula (SÍ -
ENTONCES- DE LO CONTRARIO).

TABLA 5.2.1: EJEMPLO DE LA COMPAÑIA DE SEGUROS FORTRESS
Calcular la prima base

IF la construcción de tabique
THEN deducir 10 % del total
ENDIF
IF se elige la opción de reemplazo
THEN agregar 10% de la base al subtotal
ENDIF
IF el propietario elige un deducible de $100
THEN aumentar 15% del subtotal al total ENDIF
IF la casa cuenta con alarma
THEN deducir 5% del subtotal ajustado al subtotal ajustado
ENDIF

Con el fin de escribir en lenguaje estructurado, es conveniente apegarse a las siguientes
convenciones:

1. Exprese toda la lógica, en términos de estructuras secuenciales,
estructuras de decisión, estructuras case (decisión múltiple) o iteraciones
(como ejemplo, véase la figura 5.2.1).

2. Utilice y aproveche términos tales como: IF, THEN, ELSE, DO, DO
WHILE, DO UNTIL, y PERFORM (SÍ, ENTOCES, DE LO CONTRARIO,
EJECUTE, EJECUTE MIENTRAS, EJECUTE HASTA QUE y REALICE).
3. Para mostrar con claridad la jerarquía (anidando), utilice sangrías en los
bloques de proposiciones.

4. Cuando la palabra o frase utilizadas hayan sido definida en un diccionario
de datos, destaque tales palabras o frases para indicar que tienen una
connotación reservada y especializada.

5. Sea cuidadoso cuando utilice los operadores lógicos "y" (and) y "o" (or),
evitando la confusión al distinguir entre "mayor que" e "igual que" de
relaciones similares. Aclare los planteamientos lógicos en el momento y no
espere hasta la etapa de codificación del programa.

Tablas de decisión

Las tablas de decisión son renglones y columnas separadas en cuatro cuadrantes, el primer
cuadrante, es decir el cuadrante superior izquierdo, contiene la condición. El segundo
cuadrante (cuadrante superior derecho), contiene las alternativas de condición. En la
parte inferior izquierda están las acciones a ser tomadas y al lado inferior izquierdo las
reglas para ejecutar las acciones.

Las tablas de decisión al ser utilizadas para ver que acciones son las que deben ser
tomadas, la lógica se mueve en el sentido de las agujas del reloj comenzando por la esquina
superior izquierda.

Para construir una tabla de decisión el analista necesita eliminar cualquier situación
imposible, inconsistente, redundancias, y necesita simplificar la tabla lo mas que se pueda.

El analista debe determinar que condiciones pueden afectar la decisión, las acciones
posibles que pueden ser tomadas, la cantidad de alternativas de condición para cada
condición, calcular la máxima cantidad de columnas en la tabla de decisión multiplicando la
cantidad de alternativas para cada condición, llenar las alternativas de condición,
completar la tabla colocando una X donde las reglas sugieran determinadas acciones,
combinar las reglas donde sea aparente que una alternativa no produce diferencia de
salida, revisar la tabla por cualquier situación imposible y reacomodar las condiciones y las
acciones.

Las tablas de decisión pueden crecer muy rápido según vaya aumentando la cantidad de
condiciones y alternativas. Una manera de reducir la complejidad de las tablas es usando
entradas extendidas, usar la regla SINO y crear varias tablas.

Arbolés de decisiones

Los árboles de decisión se usan cuando ocurren ramificaciones complejas en un proceso
de decisión estructurado. Para dibujar un árbol de decisión se utiliza un cuadrado para
representar una acción y un círculo para representar una condición, al mismo tiempo hay
que numerar cada círculo y cada cuadrado. Los cuadrados se pudiese decir que significan
ENTONCES y los círculos SI.

Para dibujar un árbol de decisión se deben seguir los siguientes pasos:
a) Identificar las condiciones
b) Identificar las alternativas de condición
c) Identificar las acciones
d) Identificar las reglas de acción (en orden)

Cuando un proceso de decisión estructurada se integra con ramificaciones complejas,
entonces se hace uso de los árboles de decisiones. Los árboles de decisiones se dibujan
sobre un plano horizontal, con la raíz del árbol al lado izquierdo del papel y las ramas
hacia la derecha. Esto permite al analista describir las condiciones de acciones sobre las
ramas.

Cuando se dibujan los árboles de decisiones es útil distinguir entre las condiciones y las
acciones. Para este propósito, el uso de un nodo cuadrado indica una acción y un círculo
representa una condición. El uso de esta notación hace más accesible el árbol de
decisiones sí uno piensa que un círculo significa IF (SI), mientras que cuadrado significa
THEN (ENTONCES).

El árbol de decisiones tiene tres ventajas principales sobre la tabla de decisiones:

•Primera, es que toma las ventajas de la estructura consecutiva de las ramas del
árbol de decisiones, de tal forma que se identifican de manera inmediata el orden
de verificación de las condiciones y las acciones que se deben llevar a cabo.

•Segundo, las condiciones y acciones del árbol de decisiones se encuentran en
ciertas ramas pero no en otras, a diferencia de las tablas de decisiones, donde
todas forman parte de la misma tabla.

•Tercero, al compararse con las tablas los árboles de decisiones se entienden con
más facilidad en una organización y son apropiados como un método de
comunicación.

Regresar

Preparación de la propuesta de
sistemas
En la preparación de las propuestas de sistemas el analista hace una destilación de todo
lo que ha aprendido acerca del negocio y lo que necesita para mejorar su desempeño.

El analista primero que todo debe tener una idea con respecto al hardware y software
que posee la empresa para manejar adecuadamente las cargas de trabajo. El analista
hace un inventario del hardware computacional, aquí hace un lista de los productos que
posee que pueden ser expandidos o que tienen que reciclarse, tales como: Tipo de
equipo, numero de modelo, fabricante, el estado de operación del equipo, edad estimada,
vida proyectada, ubicación física, persona que va utilizar el equipo y la propiedad del
equipo (Propio, rentado, etc.), en fin tener una lista detallada de todos los accesorios
que posea la maquina

Luego de que el analista hace el estudio de todo el hardware disponible, hace un cuadro
comparativo donde mide la estimación de las cargas, es decir, en una columna muestra la
máxima operacionalidad del hardware que posee la empresa y en la otra columna muestra
lo que necesita el sistema propuesto. Si existe algún hardware que no cumpla con los
requerimientos ahí es donde decide que habrá que actualizar el hardware que posee la
empresa. De no ser así quedaría el hardware anterior a menos que la empresa decida
estar al día con la tecnología y hace un cambio.

Análisis y diseño de sistemas estructurado

Análisis y diseño de sistemas estructurado

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Análisis y diseño de sistemas estructurado

Semelhante a Análisis y diseño de sistemas estructurado (20)

Último

Último (20)

Análisis y diseño de sistemas estructurado