Modelo de Procesos de Datos y Orientación a Objetos - Lectura M1.pdf

Módulo I
Planificación de proyecto de
software basado en el
enfoque del análisis
estructurado moderno

Modelo de Procesos de Datos y Orientación a Objetos
2
Contenido
Planificación de proyecto de software basado en el enfoque del análisis
estructurado moderno ........................................................................................ 5
Tipos de Sistemas.............................................................................................. 5
Sistemas de Procesamiento de transacciones. .............................................. 6
Sistemas de automatización de oficinas y sistemas de trabajo de conocimiento.
........................................................................................................................ 7
Sistema de información administrativa. .......................................................... 7
Sistema de soporte de decisiones.................................................................. 8
Inteligencia artificial y sistemas expertos........................................................ 8
Sistemas de soporte de decisiones en grupo y sistemas de trabajo colaborativo
asistido por computadora................................................................................ 8
Sistemas de soporte para ejecutivos .............................................................. 9
Los participantes en el juego de los sistemas. ................................................... 9
Usuarios........................................................................................................ 10
Clasificación de los usuarios por categoría de trabajo: ............................. 10
El Ciclo de Vida del Desarrollo de Sistemas. ................................................... 15
El ciclo de vida de un proyecto tiene por objetivo cuanto sigue:................... 15
El Ciclo de Vida del Proyecto Clásico........................................................... 16
Implantación ascendente. ......................................................................... 18
Progresión secuencial............................................................................... 18
El Ciclo de Vida Semiestructurado ............................................................... 19
Ciclo de vida estructurado del proyecto........................................................ 21
La encuesta............................................................................................... 22
El análisis de sistemas.............................................................................. 23

3
Diseño....................................................................................................... 23
Implantación.............................................................................................. 23
Generación de pruebas de aceptación ..................................................... 24
Garantía de calidad................................................................................... 24
Descripción del procedimiento .................................................................. 24
Conversión de Base de Datos................................................................... 24
Instalación................................................................................................. 25
El Ciclo de vida de Prototipos....................................................................... 25
Análisis y Diseño de Sistemas de computadora basado en el Enfoque del Análisis
Estructurado Moderno – Parte 1 ...................................................................... 27
Administración de Proyecto.............................................................................. 27
Problemas en la organización....................................................................... 27
Identificación de las necesidades. ................................................................ 27
Estudio de Viabilidad .................................................................................... 28
Viabilidad técnica ...................................................................................... 29
Viabilidad económica ................................................................................ 29
Viabilidad operacional ............................................................................... 30
Diagrama de Flujo de Datos............................................................................. 30
Componentes del DFD ................................................................................. 32
El flujo ....................................................................................................... 33
El almacén ................................................................................................ 35
El Terminador............................................................................................ 37
DFD por niveles............................................................................................ 39
Diagrama de Contexto .............................................................................. 39
Diagrama Cero.......................................................................................... 40

4
Diagrama por Niveles................................................................................ 40
Bibliografía.................................................................................................... 42

5
Planificación de proyecto de software
basado en el enfoque del análisis
estructurado moderno
Figura 1. Chiste Informático. Fuente: http://www.eoi.es/blogs/embaen/2014/04/29/cursos-de-gestion-de-proyectos-para-
todos/
Esta unidad trata de todo lo referente a la planificación de proyectos de software,
las consideraciones a tener en cuenta desde el momento en que se debe realizar
un relevamiento de datos y los recursos que deben ser empleados.
Tipos de Sistemas
 En la siguiente figura se ilustra la variedad de sistemas de información
que pueden desarrollar los analistas.

6
Figura 2. El profesional informático con conocimientos de análisis de sistemas podría involucrarse con éstos sistemas.
Los tipos de sistemas se estructuran de arriba hacia abajo, indicando el nivel
operacional de la organización, según la jerarquía de mandos. (Kendall &
Kendall, 2011).
Sistemas de Procesamiento de transacciones.
Conocido por su sigla en inglés (TPS), son sistemas que se desarrollaron para
manejar grandes cantidades de información para las transacciones de negocios
rutinarias, como nóminas de empleado e inventario de un comercio. Este tipo de
sistema reduce el tiempo que se requiere para realizar las mismas operaciones
ESS
GDSS
CSCWS
Sistemas expertos
Sistemas de soporte de
decisiones
Sistemas de información
administrativa
Sistemas de trabajo de conocimiento
Sistemas de automatización de oficinas
Sistemas de procesamiento de transacciones

7
de forma manual. Estos sistemas no sólo pueden funcionar de manera interna
en la organización sino también con su entorno exterior. (Kendall & Kendall,
2011).
Sistemas de automatización de oficinas y sistemas
de trabajo de conocimiento.
Los sistemas automatizados de oficina facilitan la labor de las personas que
trabajan con datos, no para generar conocimiento sino para analizar la
información y transformar los datos de cierta forma, antes de compartirlos o
distribuirlo de manera formal a través de la organización. Entre las tareas que
realizan éstos sistemas, son el de procesamiento de palabras, planillas
electrónicas, el de diseño gráfico realizado a través de la computadora, correo
electrónico, entre otros. (Kendall & Kendall, 2011).
Sistema de información administrativa.
Los sistemas de información administrativas, no reemplazan a los sistemas
transaccionales, sino que lo integran. Este tipo de sistema brinda ayuda a los
usuarios. Los sistemas de información administrativas proporcionan soporte a
los usuarios para realizar un espectro más amplio de tareas organizacionales en
comparación a los sistemas de procesamiento de transacciones e incluso a
procesos de análisis y toma de decisiones. Para tener acceso a la información,
los usuarios del sistema de información administrativa, comparten un repositorio
de datos común, donde se tienen los datos de modelos que permiten al usuario
interactuar con ellos, interpretarlos y aplicarlos. Este tipo de sistema produce
información que se utiliza en el proceso de toma de decisiones. (Kendall &
Kendall, 2011).

8
Sistema de soporte de decisiones.
Los sistemas de soporte de decisiones, más conocidos por su sigla DSS, forman
parte de una clase superior de sistemas de información automatizado. Estos
sistemas son similares a los sistemas de información administrativa, en vista a
que ambos dependen de un repositorio de datos como fuente de datos. La
diferencia radica en que el sistema de soporte de decisiones está más
relacionado a proporcionar ayuda a la toma de decisiones en todas sus fases.
(Kendall & Kendall, 2011).
Inteligencia artificial y sistemas expertos.
La Inteligencia Artificial, más conocida por la sigla AI, ha sido creada por equipos
que se comparten de manera inteligente. La misma se compone de:
Comprensión del lenguaje natural y del análisis de la habilidad para razonar un
determinado problema. Los sistemas expertos utilizan metodologías de
razonamiento para resolver problemas que los usuarios proponen. (Kendall &
Kendall, 2011)
Sistemas de soporte de decisiones en grupo y
sistemas de trabajo colaborativo asistido por
computadora.
El sistema de soporte de decisiones es conocido por su sigla GDSS. Estos
sistemas se utilizan en salas especiales equipadas con varias configuraciones,
los cuales permiten a los miembros de los grupos inteligentes, interactuar con un
soporte electrónico. Su propósito es lograr que un grupo resuelva un problema
con la ayuda de varios elementos de recolección de datos como los son: las
encuestas, cuestionarios, lluvia de ideas por mencionar algunos de ellos.
(Kendall & Kendall, 2011)

9
Sistemas de soporte para ejecutivos
Este sistema es conocido por su sigla ESS, los cuales están dirigidos para uso
de los ejecutivos a los efectos de que le ayude a organizar sus actividades
haciendo uso de gráficos y comunicaciones en sitios accesibles como lo son las
juntas de sesiones corporativas. (Kendall & Kendall, 2011).
Los participantes en el juego de los
sistemas.
Edward en su capítulo 3 nos habla acerca de los “Participantes en el desarrollo
de Sistemas”. Entre las categorías de los participantes en el desarrollo de un
proyecto de sistemas, podemos encontrar:
 Usuarios.
 Administradores.
 Auditores, personal de control de calidad y verificadores de normas.
 Analistas de Sistemas.
 Diseñadores de Sistemas.
 Programadores.
 Personal de operaciones. (Yourdon, 1989)

10
Usuarios
Es el participante más importante, es a quién a menudo se le entrevista con gran
detalle a fin de conocer las características que deberá de tener el nuevo sistema
para poder tener éxito. El usuario viene a ser el dueño del proyecto de sistema,
por el hecho que es quién solicita y recibe el proyecto software como un producto
a ser utilizado. Al ser dueño, pasa a ser cliente, y al igual que en otras
profesiones, se debe aceptar que “el cliente siempre tiene la razón”, sin importar
lo exigente o desagradable que pudiera ser, además el cliente es el que a fin de
cuentas paga el sistema, y también tiene el derecho a rechazar el proyecto en
caso de que el resultado no refleje lo pactado. (Yourdon, 1989).
Clasificación de los usuarios por categoría de trabajo:
Usuarios operacionales: son oficinistas, administradores y operadores que son
lo que probablemente tendrán un contacto directo con el nuevo sistema. Dado
éste contexto es que en grandes organizaciones, se tendría que entrevistar a
secretarias, agentes de seguro, bibliotecarios, oficinistas por mencionar a
algunos de ellos. Se preocupan mucho por las funciones que tendrá el sistema,
así como de los detalles que tendrá la interfaz. (Yourdon, 1989)
Los usuarios supervisores: usualmente administran a un grupo de usuarios
operaciones y son responsables de calificar sus logros, a éste grupo de usuarios,
corresponden: los jefes de turno, gerentes, ejecutivos, jefes de ingeniería, estos
están familiarizados con el trabajo de sus respectivos subordinados. (Yourdon,
1989)
Los usuarios de nivel ejecutivo: son los que no se involucran directamente con
el proyecto, a no ser de que el proyecto sea lo suficientemente grande y tan
importante que tenga un involucramiento directo para la toma de decisiones. Son

11
los que proporcionan la iniciativa para el proyecto y que probablemente
intervenga como autoridad para financiar las solicitudes que se presentan en los
niveles de menor jerarquía dentro de la organización. Los usuarios ejecutivos se
preocupan por los detalles estratégicos y la rentabilidad a ser obtenida a
corto/largo plazo. (Yourdon, 1989)
Estos tres tipos de usuarios tienen distintas perspectivas, intereses y prioridades.
Hay usuarios que se rehúsan a tener un nuevo sistema por temor a que una o
más de sus necesidades no sean satisfechas. (Yourdon, 1989)
Administradores. Éstos a su vez se clasifican en:
(a) Administradores usuarios: Son los administradores que
están a cargo de varias personas en el área operacional en
donde va a ser instalado el nuevo sistema. Por lo general
son administradores de nivel medio que desean que de que
el sistema arroje por resultado una variedad de informes
internos y de análisis a corto plazo. (Yourdon, 1989)
(b) Administradores de informática: Son las personas
encargadas del proyecto de desarrollo de sistema,
conocedor de los insumos que serán necesarios para llevar
a cabo el proyecto de sistema, estos insumos abarcan:
herramienta de desarrollo del software, servidores,
computadores, equipos de redes de comunicación para la
conexión remota del sistema. (Yourdon, 1989)
(c) Administrador general: Son los administradores del nivel
superior que no están directamente involucrados con la
organización informática ni con los usuarios. Esta categoría
de administradores pudieran ser: el presidente de la

12
organización o el jefe de la administración financiera.
Generalmente se interesan en los sistemas que sean de
planificación estratégica y de apoyo a decisiones. (Yourdon,
1989)
Auditores, control de calidad y departamento de nomas o estándares.
Dependiendo del tamaño y de la naturaleza del proyecto, puede que existan
auditores, personal de control de calidad o un departamento encargado de las
normas o estándares a ser aplicados en los proyectos de sistemas. El objetivo
general de los auditores es que el sistema se desarrolle conforme a los
estándares o normas de calidad, como por ejemplo los estándares de
contabilidad o estándares impuestos por diversas dependencias
gubernamentales. A menudo no se involucran al inicio de un proyecto, sino que
al finalizar el mismo, después de que se haya terminado con el trabajo del
análisis de sistemas, el diseño y la programación o cuando se ha comenzado
con las pruebas. Se interesan más por la forma que por el contenido, es por ello
que si los documentos no tienen la presentación exacta que ellos exigen, puede
que el proyecto sea rechazado. (Yourdon, 1989).
El Analista de Sistemas
Es el personaje clave en cualquier proyecto de desarrollo de sistemas,
desempeña varios papeles tales como:
(a) Arqueólogo y escribano: Como analista, una de sus
principales labores es la de describir a detalle la política del

13
negocio que será transmitida de generación a generación
entre los usuarios. (Yourdon, 1989)
(b) Innovador: El analista junto con sus conocimientos de
tecnología debe ayudar al usuario a mejorar las
funcionalidades que serían implementadas en el nuevo
sistema, y a explorar aplicaciones novedosas y más útiles
que les permita formas nuevas de hacer negocio. (Yourdon,
1989)
(c) Mediador: El analista suele encontrarse en medio entre el
usuario, administradores, programadores, auditores y otros
diversos participantes. El analista no debería de imponer su
propia opinión respecto a cómo debe ser el sistema o cuáles
serían las funciones a cumplir. (Yourdon, 1989)
(d) Jefe de Proyecto: Por su experiencia en análisis, gestión y
desarrollo de aplicaciones, hay una tendencia habitual de
asignarle al analista las responsabilidades de la
administración total del proyecto. (Yourdon, 1989)
Diseñadores de sistemas
Este recibe el resultado del trabajo del analista, su rol consiste en transformar
los requerimientos del usuario con respecto a los recursos tecnológicos a ser
utilizados. En ocasiones ocurre a que el analista y el diseñador son la misma
persona o el mismo grupo de personas. Por más que el analista y diseñador
resultaren ser personas distintas, los mismos deberían de estar en contacto
permanente pues se necesita de una retroalimentación continua a los efectos de
intercambiar información. (Yourdon, 1989)

14
Los Programadores.
En proyectos grandes puede que no exista un contacto directo del cliente con el
programador, por lo que el analista sería el intermediario, es por ello que la
persona que entra en contacto directo con el programador de manera rutinaria
es el analista de sistemas. Es así que los analistas entregan los resultados de la
recolección de los datos del usuario al programador, así como lo hace con el
diseñador. En los proyectos pequeños, los papeles del analista, diseñador y
programador se combinan, de tal manera que una sola persona hace tanto el
papel del analista como el de diseñador, o también podría ocurrir que una sola
persona realice la labor de diseñador y programador. (Yourdon, 1989)
El Personal de Operaciones
Es el encargado de las operaciones del centro de cómputo, la red de
telecomunicaciones, la seguridad del hardware y del software, además de la
ejecución de los programas, el montaje de los discos, como así también de la
instalación y configuración de la impresora. La labor del personal de operaciones
se realiza después de haber terminado, probado e instalado el sistema.
(Yourdon, 1989)

15
El Ciclo de Vida del Desarrollo de
Sistemas.
El autor Edward Yourdon en su capítulo 5 nos describe acerca de un proyecto
de sistema o software. En las pequeñas y medianas empresas el procesamiento
de datos suele llevarse a cabo de manera informal, donde los proyectos de
desarrollo de sistemas se originan en reuniones casuales entre el usuario y el
administrador del proyecto (un analista, programador, e incluso, el mismo
operario podrían cumplir con ese rol), y el proyecto va desde el análisis hasta el
diseño e implantación sin mayores protocolos. En cambio, en las grandes
empresas, las actividades se llevan a cabo de manera mucho más formal. La
interacción entre los usuarios, la administración y el equipo del proyecto se
realiza de modo escrito, y todos entienden que el proyecto pasará por diversas
etapas antes que culmine. Hoy en día la tendencia tanto en pequeños como en
grandes proyectos es que los mismos adopten un ciclo de vida uniforme y única,
a esto se lo suele conocer como: plan de proyecto, metodología de desarrollo de
sistema. (Yourdon, 1989)
El ciclo de vida de un proyecto tiene por objetivo
cuanto sigue:
a) Definir las actividades que serán desarrolladas dentro del proyecto de
sistemas.
b) Conseguir correspondencia entre la multitud de proyectos de desarrollo
de sistemas en una misma organización.
c) Consensuar entre las partes involucradas en el proyecto, si el mismo no
es factible, a los efectos de tomar la decisión de continuar o no, con un
determinado proyecto. (Yourdon, 1989)

16
El primer objetivo es importante principalmente cuando se presenta rotación de
personal. Un nuevo administrador de proyecto puede que no tome en cuenta las
fases claves de proyecto, sino que sólo se guíe por su criterio personal.
Con respecto al segundo objetivo, se pretende lograr la uniformidad de
proyectos, pues para los niveles más alto de la administración, puede que resulte
complicado hacer seguimiento de cada uno de los diferentes proyectos con que
se cuenta en la empresa.
El tercer objetivo se refiere a la necesidad de ir controlando el proyecto a medida
que se avanza por etapas, en pequeños proyectos, quizás el único punto de
revisión sea la que se realiza cuando le proyecto ya culminó. En caso de trabajar
con un gran proyecto, se debería de implementar varios puntos de control, que
permitan identificar si el proyecto está avanzando o retrasándose, o fuera
necesario reforzar los recursos.
Con todo lo enunciado podríamos por tanto afirmar que el ciclo de vida del
proyecto ayuda a organizar las actividades del administrador de proyecto, dando
la posibilidad de que los problemas puedan identificar y resolverse a tiempo.
(Yourdon, 1989)
El Ciclo de Vida del Proyecto Clásico
Es el que se utiliza actualmente en la mayoría de las organizaciones, donde el
proyecto, atraviesa por algún tipo de análisis, diseño e implantación.

17
Figura 3. Fases del Ciclo de Vida del Proyecto Clásico
 Las fases de exploración y análisis podrían juntarse en una sola etapa.
 El estudio de hardware podría ser opcional, más aún si se considera
de que se podrían reutilizar las computadoras existentes.
 Las fases de diseño preliminar y de diseño detallado pueden definirse
en una sola etapa llamada diseño.

18
 Las fases de prueba podrían agruparse en una sola, incluso incluirse
con la etapa de programación. Sea cual fuere la forma de agrupar las
etapas, en cinco, siete o doce, lo mismo el ciclo de vida, tiende a ser
el clásico.
Lo que caracteriza a un proyecto como clásico es que el mismo tiene una fuerte
tendencia a la implantación ascendente, programación lineal y secuencial de una
fase a la siguiente. (Yourdon, 1989)
Implantación ascendente.
Esto representa una de las grandes debilidades del ciclo de vida de los proyectos
clásicos, pues se espera a que los programadores realicen primero las pruebas
por módulo, luego las de subsistema, para finalmente realizar la pruebas del
sistema integrado como tal, a este enfoque se lo conoce también como ciclo de
vida en cascada. (Yourdon, 1989)
Progresión secuencial.
La segunda debilidad que registra el ciclo de vida secuencial es que las fases se
realizan en forma secuencial, por lo que se asume que ya se culminó al 100% la
fase de análisis y de que ya no tendríamos necesidad de volver a revisar ésta
fase. Esto trae como consecuencia problemas, pues no se ajusta a la realidad,
bien sabemos que no hay nada perfecto, se vive en un mundo en que las
circunstancias se presentan de manera cambiante como lo son: la rotación del
personal, la política de la empresa e incluso la economía. Como humanos, raras
veces podríamos hacer un trabajo de manera perfecta, e incluso el analista o el
diseñador pudieron haber cometido errores y haber elaborado un producto con
fallas. Por parte del usuario, podría ocurrir a que cambien de parecer respecto a

19
cómo debiera de funcionar el sistema o el usuario se va afectado por factores
externos tales como: la economía, la competencia, los reglamentos
gubernamentales que interfieren en las actividades del usuario. (Yourdon, 1989)
El Ciclo de Vida Semiestructurado
Desde finales de los años 70 e inicios de los 80, se ha visto acrecentar la
tendencia a reconocer al diseño y a la programación estructurada.
Figura 4. Ciclo de vida Semiestructurado

20
La secuencia ascendente de codificación, la prueba que se realiza en cada
módulo y las pruebas integradas, son reemplazadas por una implantación de
arriba hacia abajo. Los módulos de alto nivel se codifican y prueban primero,
seguido por los de bajo nivel, pero de forma más detallada. Se utiliza por ende
ya en el semiestructurado la codificación estructurada aunque no es una
obligación. (Yourdon, 1989)
 El diseño clásico se reemplaza por el diseño estructurado.
Este tipo de ciclo de vida, permite una implantación descendente donde podría
dar una retroalimentación entre el proceso de implantación y el de análisis.
(Yourdon, 1989)

21
Ciclo de vida estructurado del proyecto
Figura 5. El ciclo de vida estructurado del proyecto.
En el estructurado se le involucra a los terminadores. Estos representan
personas, grupos de personas o dependencias de la empresa que proporcionan
las entradas al equipo del proyecto, como así también son los beneficiados del
sistema. (Yourdon, 1989)
Con respecto a las actividades que se tienen en el ciclo de vida estructurado
tenemos:

22
La encuesta
Es un instrumento de recolección de datos que se utiliza para dar inicio a las
actividades del proyecto. Se lo utiliza cuando el usuario solicita que una o más
partes del sistema se automaticen, sus principales objetivos son:
 Identificar a los usuarios responsables y definir las actividades a llevarse
a cabo. Esto puede abarcar la conducción de una serie de entrevistas para
determinar que usuarios formarían parte del proyecto. Es probable que
durante la entrevista se realice un bosquejo en forma de diagramas, lo
que representaría el futuro sistema a ser desarrollado.
 Detectar las deficiencias actuales con respecto al entorno del usuario,
esto comprendería una lista de funciones a ser incorporadas, como así
también nuevos criterios de funcionamiento que el usuario ha decidido
implementar, éstos requerimientos podrían ser: El hardware del sistema
no es confiable, el software actual no puede ser mantenido, el tiempo de
respuesta del sistema telefónico es bastante lento, la falta de informes que
el sistema no es capaz de generar, etc.
 Definir los objetivos para el nuevo sistema.
 Analizar si es factible o no automatizar el nuevo sistema, y de ser así,
proponer nuevas funcionalidades. Estas estimaciones requerirá definir
costo y tiempo que requerirá para construir el nuevo sistema, como así
también los beneficios a ser obtenidos.
 Elaborar el esquema de actividades que se seguirá a los efectos de guiar
el desarrollo del proyecto.
Por lo general la encuesta ocupa sólo del 5 al 10 por ciento de todo el tiempo y
los recursos de todo el proyecto. (Yourdon, 1989)

23
El análisis de sistemas
Su propósito es convertir los datos ingresados, según la política del usuario y del
plan de actividades que se quiere seguir. Esto se logra mediante la
representación de los datos en el diagrama de flujo de datos, diagrama entidad-
relación, diagramas de transición de estados.
Además del modelado del sistema, se describen los requerimientos del usuario,
que abarca la elaboración del presupuesto, cálculos de costos y otros beneficios
más precisos y detallados que forman parte de la actividad del análisis. (Yourdon,
1989)
Diseño
Dentro del diseño se realiza la especificación de los procesadores (equipos
computacionales) a ser utilizados, incluyendo a los recursos humanos que serían
necesarios como parte del equipo de recurso, como así también la definición de
las labores a ser desarrolladas. Entre otras de las actividades de diseño se
encuentran la definición de los módulos del programa y las interfaces que cubran
las necesidades de los usuarios, así también la transformación de los modelos
de datos en un modelo lógico de diagrama entidad relación que posteriormente
será el diseño físico del sistema. (Yourdon, 1989)
Implantación
Abarca la programación y la integración de cada uno de los módulos. Por lo
general el analista de sistemas no se ve involucrado en ésta parte del ciclo de
vida del sistema, aunque en proyectos pequeños una sola persona que suele ser
el analista de sistema es el que efectúa todas las actividades. (Yourdon, 1989)

24
Generación de pruebas de aceptación
La especificación estructurada debe contener toda la información que se requiere
para definir un sistema que sea aceptable por el usuario. Una vez generada la
especificación, se podría definir una serie de casos de prueba. El desarrollo de
las pruebas podría llevarse a cabo al mismo tiempo que la de diseño e
implantación. (Yourdon, 1989)
Garantía de calidad
Se lo conoce como prueba final o prueba de aceptación. Esta etapa requiere de
la entrada de datos para la prueba de aceptación. Para realizar las pruebas, se
podría tener en cuenta a uno o más usuarios, un grupo de usuarios o la
dependencia de control de calidad en caso que existiere. En ocasiones a ésta
etapa se lo podría llamar como control de calidad en lugar de garantía de calidad.
(Yourdon, 1989)
Descripción del procedimiento
Consiste en la descripción formal de la partes del sistema, transcriptos en un
forma de un manual de usuario, lo cual indica paso a paso, la forma en que los
usuarios interactuarán con el sistema. (Yourdon, 1989)
Conversión de Base de Datos
En algunos proyectos, pudiera ocurrir que la conversión de la Base de Datos
lleve más trabajo que el desarrollo mismo del proyecto. En otras circunstancias,

25
pudiera no haber existido una Base de Datos como para convertir. En caso que
existiese, se toma como datos de entrada a los datos actuales que se encuentran
en la Base de Datos del usuario y luego se procede a la conversión de una nueva
Base de Datos. (Yourdon, 1989)
Instalación
Para comenzar la instalación del nuevo sistema es necesario contar con el
manual del usuario, la base de datos convertida y el sistema previamente
aceptado. En algunos casos puede ocurrir que la instalación se realice de
manera rápida pero en otros casos, dependiendo del tamaño y la complejidad
del proyecto software, el mismo podría ser llevado a cabo de manera gradual,
los usuarios por grupo van recibiendo los manuales, el adecuado entrenamiento,
como así también comiencen a usar el nuevo sistema. (Yourdon, 1989)
El Ciclo de vida de Prototipos
Supone a una colección de programas de computadora que simulará a las
funciones que el usuario desea. Como parte del prototipo se realizan lo siguiente:
 Un Diccionario de Datos integrado.
 Un generador de pantallas.
 Un generador de reportes.
 Un lenguaje de programación de cuarta generación.
 Un lenguaje de consulta. (Yourdon, 1989)

26
Para llevar a cabo el ciclo de vida por prototipos, primeramente se realiza un
sondeo para poder determinar si el proyecto es o no buen candidato para un
enfoque de prototipos, para poder evaluar si lo es, se deben tener en cuenta las
siguientes características:
a. El usuario no desea o no puede examinar el modelado del sistema
por medio de los diagramas de proceso.
b. El usuario no puede o no es capaz de definir su requerimientos de
ninguna forma, sino que el mismo manifiesta que va a definir sus
específicamente de lo que desea al ver. (Yourdon, 1989)
Figura 6. Ciclo de vida de prototipos

27
Análisis y Diseño de Sistemas de
computadora basado en el Enfoque del
Análisis Estructurado Moderno – Parte 1
Administración de Proyecto
Los clientes proponen proyectos de sistemas por dos amplios tipos de razones:
1) porque experimentan problemas que se ajusta a una posible solución por
medio de software y 2) porque reconocen oportunidades para mejorar mediante
la actualización o modificación de los sistemas existentes, o la instalación de
sistemas nuevos. Ambas situaciones pueden surgir a medida que la organización
se adapta y hace frente a los cambios culturales y organizacionales. (Kendall &
Kendall, 2011)
Problemas en la organización.
Investigar el comportamiento de los empleados y escuchar opiniones de fuentes
externas son valiosas herramientas para detectar problemas. Al reaccionar a los
problemas en la organización, el analista de sistemas desempeña los roles de
consultor, experto de soporte y agente de cambio. (Kendall & Kendall, 2011)
Identificación de las necesidades.
El analista primero define los problemas y objetivos en el sistema. Éstos forman
la base para determinar qué debe lograr el sistema. Las cuestiones referentes a
los posibles problemas que se podrían presentar son la situación actual y los

28
objetivos planteados son la situación deseada. Los objetivos pueden ser muy
específicos o se pueden redactar de forma genérica. (Kendall & Kendall, 2011)
 Preguntas que podría aplicarse para poder identificar los objetivos
de la empresa:
a) ¿Cuáles son los propósitos de la empresa?
b) ¿Es una empresa con o sin fines de lucro?
c) ¿Planea la compañía crecer o expandirse?
d) ¿Cuál es la postura de la empresa (cultura) en cuanto a la
tecnología?
e) ¿Cuál es el presupuesto que la empresa tiene asignado para la
TI?
f) ¿El personal de la empresa tiene la experiencia requerida?
El Planteamiento del problema contiene los requerimientos, lo que se debe
lograr, junto con las posibles soluciones y las restricciones que limitan el
desarrollo del sistema. Los requerimientos pueden incluir seguridad, capacidad
de uso, requerimientos gubernamentales, etcétera. (Kendall & Kendall, 2011)
Estudio de Viabilidad
La evaluación de la viabilidad es efectiva para descartar proyectos inconsistentes
con los objetivos de la empresa, que requieran una capacidad técnica imposible
o que no tengan ninguna recompensa económica. (Kendall & Kendall, 2011)
Aunque es minucioso, el estudio de la viabilidad es algo que vale la pena ya que
ahorra tiempo y dinero a las empresas y a los analistas de sistemas. Para que el

29
analista pueda recomendar que se continúe con el desarrollo de un proyecto,
éste debe mostrar que es viable en las tres siguientes formas: técnica,
económica y operacional. (Kendall & Kendall, 2011)
Viabilidad técnica
El analista debe averiguar si es posible desarrollar el nuevo sistema teniendo en
cuenta los recursos técnicos actuales. Si esto no pudiera ser así, ¿se puede
actualizar o complementar el sistema de tal forma que pueda cumplir con lo que
se requiere? Si no es posible actualizar los sistemas existentes, la siguiente
pregunta sería si existe o no la tecnología que cumpla con las especificaciones
técnicas. Al mismo tiempo, el analista puede preguntar si la organización cuenta
con el personal informático calificado para lograr los objetivos. De no ser así, la
pregunta es si pueden o no contratar programadores, expertos o demás personal
adicional que pueda tener habilidades de programación distintas a las del
personal existente, o si tal vez puedan contratar personal tercerizado que se
haga cargo del proyecto. En todo caso, se podría investigar si hay o no paquetes
de software disponibles que puedan lograr sus objetivos. (Kendall & Kendall,
2011)
Viabilidad económica
La viabilidad económica es el análisis posterior a la viabilidad técnica que se
debe realizar. Los recursos básicos que se deben considerar son el tiempo del
analista y el tiempo de su equipo de análisis de sistema, el costo de realizar un
estudio de sistemas completo, el costo del tiempo del empleado de la empresa,
el costo estimado del hardware y el costo estimado del software o del desarrollo
de software que se pretende llevar a cabo. (Kendall & Kendall, 2011)

30
Viabilidad operacional
Una vez evaluados la factibilidad técnica y económica, se debe evaluar la
viabilidad operacional que implica a los recursos humanos disponibles para el
proyecto como así también a la actividad de pronosticar si el sistema funcionará
y será utilizado. Se debe tener en cuenta que si los usuarios están muy
acostumbrados con el sistema actual, no identifican problema, puede ocurrir que
no quieran involucrase en el proceso de solicitar un nuevo sistema, y habrá
mucha resistencia a la implementación del nuevo sistema, pero en cambio sí son
los mismos usuarios quienes han expresado la necesidad de un nuevo sistema
que sustituya al vigente, a los efectos de que le sea más eficiente y accesible,
hay más probabilidades de que el sistema solicitado se llegue a utilizarse.
Diagrama de Flujo de Datos
Esta es una herramienta que proporciona un panorama como una red de
procesos funcionales, lo cual genera una conexión como una red de datos. El
diagrama de flujo de datos tiene los siguientes sinónimos:
 Carta de burbujas.
 DFD
 Diagrama de burbujas.
 Modelo de Procesos.
 Diagrama de flujo de trabajo.
 Modelo de función. (Yourdon, 1989)

31
Se utilizaron por primera vez en la ingeniería de software para el estudio del
diseño de sistemas. Hasta hoy día los DFD continúa siendo utilizada por los
ingenieros de software que trabajan en la implantación de modelos de los
requerimientos del usuario para un futuro desarrollo de software, los DFD no sólo
se pueden utilizar para modelar sistemas de proceso de información, sino
también como manera de modelar organizaciones enteras, es decir, se lo puede
utilizar también como herramienta para la planeación estratégica y de negocios.
Los DFD representan a su vez una notación, para modelar sistemas de tiempo
real (es decir, flujos de control y procesos de control). Generalmente no se ocupa
sólo de los sistemas dirigidos a los negocios, sino que también a una variedad
de sistemas científicos y de ingeniería. (Yourdon, 1989)
Figura 7. Estructura de un DFD

32
Componentes del DFD
El primer componente del DFD se conoce como proceso. Los sinónimos
comunes son burbuja, función o transformación. El proceso muestra una parte
del sistema que transforma los datos de entradas en salidas. Según el gráfico
descrito, algunos analistas prefieren usar óvalo o un rectángulo con esquinas
redondeadas, y otros prefieren usar un rectángulo. Las diferencias entre estas
tres formas son básicamente estéticas, aunque es importante usar la misma
forma de manera consistente para representar todos los procesos del sistema.
(Yourdon, 1989)
Figura 8. Ejemplos de formas que se podrían utilizar en el DFD
El proceso se nombra o describe con una sola palabra, frase u oración sencilla.
Por medio del nombre se describe lo que hace. Es importante recalcar que un
buen nombre de proceso, generalmente consiste en una frase verbo-objeto tal
como GENERAR ENTRADA u OBTENER IMPUESTO. En algunas ocasiones
describe quién o qué está efectuando. (Yourdon, 1989)
CALCULAR
IMPUESTOS
DE VENTAS
CALCULAR
IMPUESTOS DE
VENTAS
CALCULAR
IMPUESTOS DE
VENTAS

33
El flujo
El flujo que está representado por una flecha, se usa para describir el movimiento
o paquete de información desde una parte del sistema a otra, los mismos
representan datos en movimiento.
Figura 9. Representación de un flujo de datos
Estos datos pueden consistir en: bits, caracteres, mensajes y los diversos otros
tipos de información como lo que la computadora puede operar. Los flujos por lo
general se nombran, y el nombre representa el paquete de datos que se mueve
a lo largo del flujo. Los datos del flujo podrían dirigirse hacia otros componentes,
como lo son: a un almacén o a un terminador y en caso de que el diagrama
tratase de un modelado de Sistema en Tiempo real, entonces el flujo podría estar
dirigiéndose hacia otro proceso. (Yourdon, 1989)
Tipos de Flujos
a) Flujo de diálogo o doble cabeza: indica empaquetado de
datos de dos extremos (pregunta y respuesta), haciendo uso
de un solo flujo. En el caso de flujo de diálogo, ambos
extremos del flujo deben nombrarse. (Yourdon, 1989)
b) Flujo Divergente: es cuando un solo flujo, puede dividirse
en otros varios flujos. El flujo divergente, significa que se

34
están mandando duplicados de paquetes de datos a
diferentes partes del sistema, o se lo puede utilizar también
para representar la división de un conjunto de datos
individuales, donde cada uno de los éstos paquetes se está
enviando a diferentes partes del sistema. (Yourdon, 1989)
c) Flujo convergente: varios paquetes de datos, se unen para
formar un solo agregado de datos. Provienen los paquetes
de datos de diversos orígenes y se agrupan para ir a un solo
destino. (Yourdon, 1989)
Figura 9. Ejemplo de flujo de diálogo
Figura 10. Ejemplo de flujo de divergente
Determinar
estado de
un pedido
Solicitud sobre estado del pedido
respuesta sobre el estado del
pedido
Validar
código
postal
Validar
número
telefónico
Validar
calle
dirección del cliente
Código postal
Nro. Telefónico
datos de la calle

35
Figura 11. Ejemplo de flujo de convergente
El almacén
Se utiliza para representar una colección de datos en reposo, gráficamente se
tiene como dos líneas paralelas. La formar de escribir el nombre de los
almacenes, es el plural del nombre de los flujos que se utilizan para presentar a
los datos que entran y salen de él, y por lo general se escribe todo en mayúscula.
Figura 12. Representación habitual del almacén
Figura 13. Representación alternativa del almacén
PEDIDO
PEDIDO PEDIDO
S
Realizar
cobranza
datos de la factura a crédito
datos del cobrador
datos del cliente
datos de cobranza

36
Las datos que registra un almacén, representan los datos de todo lo que
queremos registrar, como ser datos personales, datos de artículos, pedidos de
un cliente, por mencionar alguno de los ejemplos. Los almacenes se conectan
por flujos a los procesos, donde se puede tener un flujo desde un almacén, y otro
flujo en dirección al almacén que salen de algún proceso. (Yourdon, 1989)
Figura 14. Representación de un almacén enlazado a dos procesos por medio del flujo.
En ocasiones se podría utilizar flujos sin etiquetarse, principalmente cuando los
datos que salen o entran, contienen todos los valores que el almacén debe
registrar como datos. Un flujo sin etiqueta, se representa como una lectura o un
acceso a la información del almacén, por lo tanto se podría afirmar que se
recupera del almacén un solo paquete de datos. Por ejemplo de un almacén
llamado CLIENTES, donde el paquete de datos contiene a todos los campos
que el almacén clientes debería de registrar, tales como: nombre, apellido,
dirección, número de teléfono. Cuando no se va a recuperar todos los valores
que tiene registrado el almacén, entonces, el flujo, debería de tener nombre.
(Yourdon, 1989)
Según sea el sentido que tenga el flujo hacia o desde el almacén, el mismo
podría tener los siguientes significados:
 Se están guardando uno o más datos en el almacén.
Ingresar
pedido
detalle de pedido
Pedido invalido
PEDIDO
Procesar
pedido
pedido
pedido
respuesta pedido

37
 Uno o más datos del almacén requieren ser borrados.
 Uno o más datos del almacén se están extrayendo.
 Uno o más datos del almacén se están modificando o cambiando.
(Yourdon, 1989)
Un aspecto que se debiera de tener en cuenta es que, los flujos transportan
datos, que sólo el almacén es capaz de guardar, es por esto que un flujo
conectado a un almacén CLIENTES, sólo puede transportar información
relacionada a los clientes, y cuyos campos de valores se van a tener en cuenta
en una posible tabla de la base de datos, pues cada almacén representa a una
tabla en la Base de Datos. (Yourdon, 1989)
El Terminador
Se lo representa como un rectángulo, son entidades externas, con las cuales el
sistema se comunica. Este podría consistir en una persona, grupo de personas,
una organización externa, un determinado departamento de la empresa, también
podría ser la representación de un sistema externo al que se está modelando, y
desde donde se querría capturar datos. (Yourdon, 1989)
Figura 15. Representación gráfica de un terminador.
En ocasiones, el propio usuario, es quién representaría a un terminador, pues
tendría la necesidad de suministrar al sistema determinados datos, de tal modo
a que sean transformados en información, esa información representa un
conjunto de datos asociados visibles en el monitor del computador, o de modo
Departamento de
Contabilidad

38
impreso, en papel que se obtiene de la impresora. Cuando el usuario se
considera parte del sistema, ayuda a identificar los terminadores relevantes, es
por ello, que el departamento de contabilidad y el departamento de finanzas son
terminadores con los cuales se comunica el sistema. (Yourdon, 1989)
Existen determinadas reglas para graficar un adecuado diagrama de flujo de
datos, los cuales son:
a) Se debe escoger nombres fáciles de recordar y que vayan en relación
directa con el sistema, tanto para los procesos, flujos, almacenes y
terminadores.
b) Se debe enumerar los procesos.
c) El DFD se debe rehacer las veces que sea conveniente de tal modo a que
refleje exactamente el funcionamiento del sistema que será plasmado en
un proyecto software.
d) Se debe evitar DFD muy complejos.
e) La representación de los datos que se transportan de un lugar a otro por
medio de los flujos, deberían de ser consistentes, es por ello que se
debería de evitar:
 Sumideros infinitos: los cuales son burbujas que tienen entradas
de datos, pero no salidas de datos, es decir un determinado
proceso, no sólo debería de tener sólo entradas, sino que también
debería tener al menos un flujo de salida de datos. (Yourdon, 1989)
 Burbujas de generación espontánea: Son las que tienen salidas,
sin tener flujos de entrada. Al igual que el punto a., un proceso no
debería de tener sólo salidas, sino que al menos debería de tener
una entrada de datos. (Yourdon, 1989)
 Flujos y procesos no etiquetados: a no ser que el flujo envié un
conjunto de datos que representa a un paquete de todos los datos

39
que un almacén es capaz de registrar, así como se escribió al
momento de mencionar al flujo de diálogo. Si, el proceso, no está
etiquetado significa que no tiene nombre y por ende, no se podrá
saber qué actividad realiza. (Yourdon, 1989)
Figura 16. Representación de proceso de sumidero infinito y de generación espontánea.
DFD por niveles
Si el sistema es complejo y tiene docenas o cientos de funciones que se precisan
sean representados por medio del diagrama, para éste propósito se debería de
desglosar el DFD en niveles, de modo a que cada nivel proporcione el detalle de
las funciones del nivel anterior. (Yourdon, 1989)
Diagrama de Contexto
El DFD de primer nivel consta sólo de una burbuja, el cual representa al sistema
como un todo; los flujos de datos representan a la interfaz entre el sistema y los
Generar
informe
de venta
datos
datos
datos
datos
datos
Generar
informe
de venta
datos
datos
datos

40
terminadores externos. Al DFD de primer nivel se lo conoce como diagrama de
contexto. (Yourdon, 1989)
Diagrama Cero.
Representa a las funciones de más alto nivel, cada proceso a partir de éste
primer nivel deben estar enumerados para que puedan ser referenciados en la
subdivisión de niveles. (Yourdon, 1989)
Diagrama por Niveles
Representan a la subdivisión de los procesos del diagrama cero, es así que la
burbuja 2 del diagrama 0, se lo podría dividir dependiendo de su complejidad, en
2.1, 2.2, 2.3, y así sucesivamente. La burbuja 3 del diagrama 0, se asocia con el
DFD de nivel inferior en 3.1, 3.2, 3.3. A ésta primera subdivisión se lo llama nivel
dos. (Yourdon, 1989)
Cuando surja la necesidad de volver a subdividir el nivel 2, debido a que el
sistema es muy complejo, entonces podríamos tener un tercer nivel: 2.2.1,
2.2.2…3.2.1, 3.2.2
Si un proceso 2.2 tiene un nombre de “CALCULAR IMPUESTO DE VENTA”,
entonces al diagrama que surge de la división del éste proceso, se lo debe llamar
como: “Proceso o Figura 2.2: CALCULAR IMPUESTO DE VENTA”. (Yourdon,
1989)
Lo más probable es que al momento de analizar un sistema y de determinar si,
el mismo debería de estar organizado en uno o más niveles, surjan las siguientes
interrogantes:

41
a. ¿Cuántos niveles debería de tener el DFD? La recomendación dada por
el autor Edward Yourdon en su libro Análisis Estructurado Moderno, es
que el mismo no debería de tener más de media docena de procesos y
almacenes relacionados que puedan ser graficados en una hoja normal
que se utiliza habitualmente para las impresiones.
b. ¿Se tiene alguna regla definida seguir? No existe regla, más bien, la
división de los DFD por niveles viene asociado directamente por la
complejidad del sistema que se pretende modelar, es así que un sistema
simple, probablemente sólo tendrá dos o tres niveles, uno mediano, podría
tener de tres a seis niveles, uno grande de cinco a ocho niveles.
c. ¿Todos los procesos del primer nivel deben ser divididos? No, porque no
necesariamente todos los procesos podría resultar complejos, es por ello
que si tenemos a los procesos del 1 al 6, en el primer nivel, puede que
sólo el proceso 2 y el proceso 4, resultare conveniente dividirlos en:
2.1,2.2,2.3,2.4 y 4.1, 4.2 de ésta división de procesos, también se debe
considerar que no todos los procesos del nivel dos, requieran una nueva
subdivisión, es por ello que se podría tener la subdivisión a un nivel 3, del
siguiente modo: 2.2.1, 2.2.2 … 2.4.1,2.4.2, 2.4.3, como se observa, sólo
los procesos 2.2 y 2.4 han requerido una nueva subdivisión.
d. ¿Cómo lograr que todos los niveles del DFD sean consistentes? Para esto
se debe considerar de que los flujos que salen y entran de una burbuja a
otra, en un determinado nivel, deben corresponderse con los que entran
y salen en las burbuja del nivel inmediato inferior que se haya obtenido.
Cabe destacar que a los procesos que correspondan a la última
subdivisión, se los conoce como primitiva funcional. (Yourdon, 1989)

42
Bibliografía
Kendall, K. & Kendall, J.: “Análisis y Diseño de Sistemas”. Prentice Hall.
México, 2011.
Yourdon, Edward: “Análisis Estructurado Moderno”. Prentice Hall. México, 1989.

Modelo de Procesos de Datos y Orientación a Objetos - Lectura M1.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a Modelo de Procesos de Datos y Orientación a Objetos - Lectura M1.pdf

Similar a Modelo de Procesos de Datos y Orientación a Objetos - Lectura M1.pdf (20)

Último

Último (20)

Modelo de Procesos de Datos y Orientación a Objetos - Lectura M1.pdf