Analisis YDiseño

Instituto de Estudios Superiores Argentino (IESA)
Materia: Análisis y Diseño de Sistemas

Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala
Análisis y Diseño de Sistemas
Clase I
Concepto de Sistema:
Def. 1: Es un conjunto de partes que se relacionan entre sí (interrelacionadas) con un objetivo en

común.
Def. 2: Es un conjunto de elementos interdependientes o que actúan regularmente formando un
TODO.
Un sistema puede estar constituido por subsistemas y/o por cajas negras.
Subsistema: Sistema pequeño que forma parte de un Sistema Mayor que lo contiene, está
compuesto por varias funciones.
Caja Negra: es aquel elemento que es estudiado desde el punto de vista de las entradas que
recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno.
Clases de Sistemas:
En función con su relación con el medio:

 Sistemas cerrados: Son los sistemas que no presentan intercambio con el medio ambiente
que los rodea, pues son herméticos a cualquier influencia ambiental. Así, los sistemas
cerrados no reciben ninguna influencia del ambiente, y por otro lado tampoco influyen en
el ambiente.
 Sistemas abiertos: Son los sistemas que presentan relaciones de intercambio con el
ambiente, a través de entradas y salidas. Los sistemas abiertos intercambian materia y
energía regularmente con el medio ambiente. Son eminentemente adaptativos, esto es,
para sobrevivir deben reajustarse constantemente a las condiciones del medio.
En función a su origen:
 Sistemas Naturales: Son los sistemas que NO están hechos por el hombre, existen en la
naturaleza y sirven a sus propios fines. Pueden ser:
Sistemas Físicos:
a) Sistemas Estelares: galaxias, sistemas solares, etc.
b) Sistemas Geológicos: ríos, cordilleras, etc.
c) Sistemas Moleculares: organizaciones complejas de átomos.
Sistemas Vivientes: comprenden toda la gama de animales y plantas que nos
rodean, al igual que la raza humana.
 Sistemas Artificiales: Son sistemas creados por el hombre. Pueden ser:

a) Sistemas Manuales: realizados por el hombre en forma manual.

b) Sistemas Mecanizados: realizados por medio de una computadora. La tarea la
realiza una herramienta:
 Sistemas en Línea.
 Sistemas Batch.
 Sistemas orientados a la toma de decisiones.
 Sistemas de planeación estratégica.
 Etc.
Participantes en el Desarrollo de un Sistema de Información (Bloques Elementales)
Los Usuarios:
Es el participante más importante en el desarrollo de un Sistema. Es aquel o aquellos para quien
se construye el sistema. Es la persona a la que se tendrá que entrevistar, a menudo con gran
detalle, con fin de conocer las características que debería tener el nuevo sistema para tener éxito.
Los usuarios se clasifican:
En Función a la tarea que realizan:
Sirve para determinar la información que brindan al analista.
Sirve para determinar las características que debe tener la parte del sistema destinada a él: la
información que brinda, tipos de interfaz, clase de reportes, listados etc.
 Operacionales: Hace funcionar el sistema y tiene una visión física del sistema.
 Supervisores: generalmente está familiarizado con la operación. Rigen consideraciones
presupuestales. Actúa a menudo como intermediario entre los usuarios operacionales y
los niveles superiores de administración.
 Ejecutivos: tiene un panorama global. Provee la iniciativa para el proyecto. No tiene
experiencia operacional directa.
En Función a sus conocimientos:
Sirve para comprender con mayor o menos grado lo que se requiere del sistema.
 Novatos
 Amateurs
 Expertos
Administradores:
Existen tres tipos de administradores:
 Administradores Operativos: están a cargo de varias personas en el área operacional
donde se va a implantar el nuevo sistema.
 Administradores de Informática: son las personas encargadas del proyecto en sí de
sistemas, administradores del nivel superior y encargados de la distribución de recursos.
 Administración General: son los administrativos de nivel superior que no están

directamente involucrados con la organización informática ni con la organización usuaria.
Auditores:
Son agentes externos de control.
Analista de Sistemas:
Es el personaje clave en cualquier proyecto de desarrollo de sistemas. Desempeña varios papeles:
 Arqueólogo y Escribano: descubre detalles y documenta la política de negocios.
 Innovador: distingue entre síntomas, problemas y causas del usuario y los soluciona
aplicando tecnología.
 Mediador: intenta llegar a acuerdos entre los usuarios.
 Jefe de Proyecto: por tener el papel mas importante se le asigna una administración
integra.
Características del analista:

 Mejorar los conocimientos en tecnología y Sistemas de Información.
 Experiencia y dominio de programación informática.
 Conocimientos generales de Empresa.
 Capacidad para resolver problemas.
 Dominio de las técnicas de comunicación interpersonal.
 Capacidad de relación personal.
 Flexibilidad y capacidad de adaptación.
 Carácter y ética.
Diseñadores de Sistema:
En muchos casos el analista de sistemas y el diseñador son la misma persona. Es quien recibe los
resultados del trabajo de análisis y transforma la petición en un diseño de alto nivel que servirá a
los programadores.
Traduce los requisitos del sistema en especificaciones funcionales (de datos, de procesos).
Programadores/Desarrolladores:
Son los encargados de desarrollar una solución aplicada en software, que se utilizará para poner
en práctica el sistema.
Traducir las especificaciones funcionales a una aplicación.
Ciclo del desarrollo de un sistema / Ciclo de vida de un Sistema

Son las grandes Etapas por las que atraviesa el desarrollo de un Sistema de Información.
Fases:
 Planificación (No en todos los casos).

 Análisis.
 Diseño.
 Implementación / implantación
 Soporte.
Metodología
Permite alcanzar el desarrollo completo del Ciclo de Vida de un Sistema de Información (C.V.S.I)
detallando paso a paso las actividades que se realizan en cada fase.
Es una descripción mas detallada de las fases del C.V.S.I.
Fases para cada Fase:
 Tareas que se pueden hacer.
 Personas involucradas en cada tarea.
 Funciones de grupo o particulares.
 Técnicas que se van a utilizar.
 Especificación de estándares para la medición y control de calidad de cada tarea.
Clase II
Todo Software que desarrollamos, primero tiene que pasar por diferentes etapas:
Ciclo de Vida del Desarrollo de un Sistema/ Ciclo de vida de un Sistema de Información (C.V.S.I)
Análisis Diseño Implantación Soporte
Análisis: ¿Qué?
Ej. Qué tengo que hacer para solucionar el problema…
Diseño: ¿Cómo?
Ej. Cómo voy a implementar la solución…
Ciclos de Vida
Ciclo de Vida Clásico:
Cada proyecto atraviesa por algún tipo de análisis, diseño e implantación, aunque no se haga
exactamente como se muestra en la figura. El ciclo de vida de proyecto utilizado, pudiera diferir
del que se muestra en la figura en una o todas de las formas siguientes:
 La fase de exploración y análisis pudieran juntarse en una sola.

 Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo
pudiera instalarse con las computadoras existentes sin causar mayor problema
operacional.
 La fase de diseño preliminar y el diseño de detalles pudieran juntarse en una sola llamada
simplemente de diseño.
 Diversas fases de pruebas pueden juntarse en una sola; de hecho, podrían incluirse con la
codificación.
El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida de los
proyectos clásicos. Como se podrá ver en la figura, se espera que los programadores lleven a cabo
primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del
sistema mismo. Este enfoque también se conoce como el ciclo de vida de cascada. .
Muchas organizaciones que desarrollan sistemas únicos, el enfoque ascendente presenta un gran
número de dificultades serias:
 Nada esta hecho hasta que todo esté terminado.

 Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves al
final.
 La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba
del sistema.
 La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas
finales de prueba.
La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en
que las fases se sucedan secuencialmente. Querer esto es una tendencia natural humana:
deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que
volver a preocuparnos por ella. El único problema del progreso ordenado es que no es nada
realista. Por ejemplo, durante el período que transcurre para desarrollar el sistema pueden
cambiar ciertos aspectos del ambiente del usuario (la economía, la competencia, los reglamentos
gubernamentales que afectan a las actividades del usuario).
Ciclo de Vida Semiestructurado

En la figura se muestra el modelo semiestructurado, en donde se observa la siguiente diferencia
con respecto al modelo clásico:
"La secuencia ascendente de codificación, la prueba de módulos y prueba del sistema se
reemplaza por una implementación de arriba hacia abajo, que es un enfoque en el cual los
módulos de alto nivel se codifican y prueban primero, seguidos por los más detallados de bajo
nivel".
Dentro del modelo semiestructurado encontramos otros detalles tales como, la implementación
descendente que significa que se pondrán en ejecución paralelamente parte de la codificación y
de las pruebas. Dándose con lo anterior una retroalimentación entre la codificación, la prueba y la
eliminación de las fallas.
Como último punto acerca del modelo semiestructurado, tenemos que una gran parte del trabajo
que se realiza bajo el nombre de "diseño estructurado" es en realidad un esfuerzo manual para
enmendar especificaciones erróneas. Otra funcion de los diseñadores, es traducir un documento
narrativo, ambiguo, monolítico y redundante a un modelo útil, que sirva de base para derivar la
jerarquía de módulos que cumplan con los requisitos del usuario.
En general con este enfoque de desarrollo de sistemas los diseñadores tenían poco contacto con
el analista que escribía la especificación y definitivamente "no tenía contacto con el usuario".
Ciclo de Vida Estructurado

En el modelo estructurado se examinan brevemente las nueve actividades y los tres terminadores
que lo componen, como se muestra en la figura. Los terminadores son los usuarios, los
administradores, y el personal de operaciones. Los cuales se tratan de individuos o grupos que
proporcionan la entrada al equipo del proyecto, y son los beneficiados finales del sistema. Ellos
interactúan con las nueve actividades.
Prototipos
El diseño de prototipos es el acto de construir un modelo de trabajo representativo a escala
reducida de las necesidades de los usuarios con el fin de descubrir o comprobar dichas
necesidades.
Este método responde a la idea de que "sabrás lo que necesitas cuando lo veas". El analista pone
en práctica potentes herramientas de diseño de prototipos para construir rápidamente prototipos
de tipo informático. Los usuarios pueden reaccionar ante estos prototipos y ayudar así al analista a
afinar las necesidades o añadir nuevos requisitos. También pueden utilizarse prototipos para
desarrollar o afinar los modelos de sistemas anteriormente mencionados.
Las técnicas de prototipos pueden utilizarse en varias fases del ciclo de vida. Existen cuatro tipos.
Resumiendo:
Ciclo de vida Clásico Progresión Lineal
Implantación Ascendente Programa
Módulos
Subsistemas
Sistema
Ciclo de Vida Semiestructurado Análisis Clásico + Diseño Estructurado

Progresión Lineal
Implantación Descendente
Ciclo de Vida Estructurado Análisis y Diseño Estructurado

No hay Linealidad
Implantación Descendente
Prototipos De viabilidad
De necesidades / Descubrimiento
De Diseño / Comportamiento
De Implantación / Producción
Más información en:

http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/maf/cap3.htm
Clase III
Actividades Cruzadas del Ciclo de Vida de un Sistema
Se denominan actividades cruzadas porque van a ser utilizadas durante todo el Ciclo de Vida del
Desarrollo del Sistema.
Actividades Cruzadas:
1) Investigación de Hechos.
2) Documentaciones y presentaciones.
3) Estimaciones y Medidas.
4) Análisis de Viabilidad
5) Gestión de Proyectos y Procesos.
1) Investigación de Hechos (también llamada reunión de información o recogida de datos)

Es la que me va a permitir relevar toda la información de la Organización.
Es el proceso formal que emplea muestreos, encuestas, entrevistas, reuniones, cuestionarios y
otras técnicas para recoger información de los sistemas, las necesidades y las preferencias.
a) Muestreo: es el proceso de seleccionar sistemáticamente elementos representativos de una

población. Los elementos seleccionados y el análisis de estos elementos revelará información
útil a cerca de la población como un todo.
Razones por la que necesito hacer un muestreo:

 Costos contenidos: el muestreo reduce los costos como hablar con todas las personas de
la organización, la fotocopia de reportes, el pedir tiempo valioso de los empleados.
 Agilización en la recolección de datos: el muestreo acelera el proceso, recolectando datos
seleccionados, en vez de todos los datos de la población completa.
 Mejora en la efectividad: el muestreo obtiene información mas precisa. Esto se logra
hablando con menos empleados pero preguntándoles cuestiones mas detalladas.
Diseño de la muestra:
 Determinar los datos a ser recolectados: ¿Qué datos necesito? Si se recolectan datos
irrelevantes se desperdicia tiempo en la recolección, almacenamiento y análisis de los
datos inútiles.
Para determinar los datos a ser recolectados se deben considerar los objetivos del estudio
así como el tipo de método de recolección de datos.
 Determinar la población a ser muestreada: el analista debe determinar cual es la
población. Por ejemplo: si necesito todos los reportes del año, o me bastan solo algunos; o
si la población debe incluir todos los niveles de la organización o solamente un nivel, o tal
vez la reacción de los clientes.
Seleccionar el tipo de muestra: los tipos de muestra son:

 De conveniencia: publico y vienen los interesados, son muestras no restringidas y no
probables. Es la muestra más fácil de recolectar pero la menos confiable. (No basada en
probabilidad).
 Intencionales: el analista basa la muestra sobre un criterio, ahora la muestra es restringida

pero todavía es no probada, por lo tanto es moderadamente confiable. (No basada en
probabilidad).
 Aleatoria simple: se selecciona al azar. Se Necesita una lista ordenada. La lista ordenada
asegura la misma probabilidad a toda la población. A veces esto no es práctico,
especialmente cuando el muestreo involucra documentos y reportes. (Basada en
probabilidad).
 Aleatorias complejas: existen tres enfoques: (Basada en probabilidad)
 Muestreo sistemático: tengo una lista ordenada de la población, y por ejemplo de
cada 5 tomo uno o de cada 10 tomo 3.
 Muestreo estratificado: Divido en estratos o niveles (como por ejemplo en
operarios y gerentes), y tomo una muestra de cada área o de cada nivel.
 Muestreo aglomerado: tomo un grupo de la población y supongo que
representan a los demás.
El mejor muestreo es el estratificado porque me aseguro de entrevistar a uno de los diferentes
grupos o niveles.
Decisión del tamaño de la Muestra:

Depende frecuentemente del costo involucrado en el tiempo requerido por el analista de sistemas
o hasta del tiempo disponible de las personas de la organización.
Tipos de información a buscar:

Se buscan hechos y cifras, información financiera, contextos organizacionales, tipos de
documentos y problemas.
Recopilación de Documentos
Permite detectar:
 Si la información no fluye como debería.
 Si la recibe mucha o poca gente.
 Si existe duplicación de trabajo.
b) Cuestionarios: Son documentos específicos que permiten al analista recoger la información y

las opiniones que le manifiestan las personas encuestadas.
Tipos Básicos de preguntas usadas:

 Preguntas Abiertas: son particularmente adecuadas para situaciones en las cuales se
quiere obtener la opinión de los miembros de la organización acerca de algún aspecto del
sistema. Se utilizan cuando es imposible listar en forma efectiva todas las respuestas
posibles a la pregunta.
 Preguntas Cerradas: se utilizan cuando el analista de sistemas es capaz de listar

efectivamente todas las posibles respuestas a la pregunta y cuando todas las respuestas
listadas son mutuamente excluyentes, para que la selección de una impida la selección de
cualquiera de las demás.
El lenguaje de los cuestionarios es un aspecto extremadamente importante para su efectividad. A

continuación se presentan unos lineamientos a utilizar cuando se seleccione el lenguaje para el
cuestionario:
 Mantener simple la redacción.
 Tratar de ser específico en la redacción. Sin embargo evite también preguntas
extremadamente específicas.
 Mantener cortas las preguntas.
 Asegurarse que las preguntas sean técnicamente precisas antes de incluirlas.
Escala:
Escalar es el proceso de asimilar números u otros símbolos, atributos o características, con el
objeto de medir ese atributo o característica. El analista de sistemas querrá usar escalas, tanto
para medir las actitudes o características de los que responden, como para contar con sus juicios
sobre los tópicos del cuestionario.
Existen 4 formas diferentes para la medición escalar:
 Nominal: son utilizadas para clasificar cosas, todo lo que los analistas pueden hacer en
ellas es obtener totales de cada clasificación.
 Ordinal: de manera similar a las escalas nominales, permiten clasificación. La diferencia es
que la escala ordinal también implica ordenamiento de rango.
 Intervalo: poseen la característica de que los intervalos entre cada uno de los números
son iguales. Debido a estas características se pueden realizar operaciones matemáticas
sobre los datos del cuestionario, dando como resultado un análisis más completo.
 Relación: son similares a las escalas de intervalo. Sin embargo las escalas de relación
tienen un cero absoluto. Un ejemplo de una escala de relación es la distancia, tal como es
medida con una regla.
Formato del Cuestionario:

 Formato Libre: permiten al encuestado una gran libertad de respuesta. El encuestado
escribe la respuesta en un espacio en blanco libre reservado inmediatamente debajo de la
pregunta. Estas respuestas son difíciles de incluir en tablas o las respuestas no se
corresponden con las preguntas planteadas.
 Formato Fijo: contienen preguntas que requieren respuestas específicas por parte de las
personas encuestadas.
Existen tres tipos:
 Preguntas con elecciones múltiples.

 Preguntas con respuestas de opinión.
 Preguntas con valoraciones de importancia.
Ventajas de los Cuestionarios:

 En su mayoría los cuestionarios pueden ser contestados con rapidez.
 Ofrecen un medio relativamente económico para recoger datos de un amplio número de
personas.
 Permiten a las personas mantener el anonimato. Por consiguiente, es más probable que
estas informen los hechos más reales, en vez de decir lo que piensan que su jefe aprobaría
que digan.
 Las respuestas pueden incluirse en tablas y analizarse rápidamente.
Desventajas de los Cuestionarios:

 El número de encuestados es, a menudo insuficiente.
 No existe garantía de que los encuestados respondan o expliquen todas las preguntas.
 Suelen ser poco flexibles.
 El analista no tiene la posibilidad de observar el lenguaje corporal del encuestado.
 Los buenos cuestionarios son difíciles de preparar.
c) Entrevista: 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 que es lo que le
brindara el éxito a la entrevista. El otro elemento que debe considerar es el individuo a quien
entrevistará. Debe prever la forma de lograr que la entrevista también sea satisfactoria para
él.
La entrevista desea conocer tanto las opiniones como los sentimientos del entrevistado acerca
del estado actual de los sistemas, sus metas personales, de la organización y de los
procedimientos informales.
Planificación de la entrevista: consta de cinco pasos:

 Lectura de antecedentes: consulte y comprenda el mayor número posible de antecedentes de
los entrevistados y de su organización (llamada telefónica a su contacto, informe anual
reciente, busque cualquier información relativa a la empresa). Conforme vaya leyendo este
material, fíjese bien en el tipo de lenguaje que los miembros de la organización utilizan para
describirse y describir a la organización.
 Establecimiento de los objetivos de la entrevista: establezca los objetivos de la entrevista con
base en los antecedentes que consulte y en su experiencia particular.
 Selección de los entrevistados: cuando decida a quienes entrevistar, incluya a gente clave de
todos los niveles del sistema.
 Preparación del entrevistado: prepare a la persona que entrevistara, avisándole con tiempo
para que pueda pensar acerca de la entrevista. Las entrevistas deben durar entre 45 minutos y
una hora. Recuerde que cuando ellos disponen de tiempo para atenderlo a usted, no atienden
sus actividades.
 Selección del tipo y estructura de las preguntas: la esencia de la entrevista es el uso de
técnicas inquisitivas adecuadas.
Los dos tipos básicos de preguntas son las abiertas y las cerradas.
Es posible estructurar su entrevista bajo tres patrones diferentes: el de estructura de pirámide, de
estructura de embudo y la estructura de diamante.
Tipos de preguntas:
 Preguntas abiertas: son preguntas que permiten al entrevistado expresarse libremente sobre
un determinado tema. La respuesta puede ser, dos palabras o dos párrafos.
Ventajas:
 Simplifican las cosas para el entrevistado.
 Permite al entrevistador seleccionar el vocabulario del entrevistado.
 Proporciona una gran riqueza de detalle.
 Hacen más interesante la entrevista.
 Permiten una mayor espontaneidad.
Desventajas:
 Permiten preguntas que pueden generar demasiada información irrelevante.
 Es posible la pérdida del control de la entrevista.
 Permiten respuestas que pueden llevar demasiado tiempo para la cantidad de información
que aportan
 Pueden dar la apariencia de que el entrevistador no se preparó.
 Preguntas cerradas: son preguntas, en que el número de posibles respuestas es limitado para
el entrevistado.
Ventajas:
 Ahorran tiempo.
 Facilitan la comparación entre entrevistas.
 Llegan al punto de interés.
 Mantienen el control de la entrevista.
 Obtienen datos de relevancia.
Desventajas:
 Aburren al entrevistado.
 Pierden la riqueza del detalle.

 Se pueden perder ideas centrales por el punto anterior.
 No favorecen un clima de armonía entre el entrevistado y el entrevistador.
Errores en las preguntas:

 Evite las preguntas tendenciosas: estas tienden a dirigir al entrevistado hacia la respuesta que
usted quiera escuchar. La respuesta desde este punto de vista será parcial, ya que tiende una
trampa.
 Evite las preguntas dobles: las preguntas dobles son aquellas que en una sola contienen, de
hecho dos preguntas diferentes. Elegir una pregunta doble puede ocasionar que el
entrevistado conteste solo una de ellas (a propósito o no) o usted puede equivocarse sobre la
pregunta que conteste y llegar a una conclusión errónea.
Estructura de la entrevista:
 Uso de estructura piramidal: mediante el uso de esta estructura el entrevistador inicia la
entrevista con preguntas detalladas, con frecuencia del tipo cerradas. El entrevistador aplicará
luego los tópicos, haciendo preguntas abiertas y en consecuencia respuestas de carácter más
generalizado.
 El uso de la estructura embudo: 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.
 El uso de una estructura en forma de diamante: con frecuencia es mejor una combinación de
las dos estructuras, lo que da como resultado una entrevista con forma de diamante. Esto
permite comenzar de una manera muy específica, luego examinar aspectos generales y
finalmente llegar a una conclusión muy especifica.
Clase Nº 4
Actividades Cruzadas:
6) Investigación de Hechos.
7) Documentaciones y presentaciones.
8) Estimaciones y Medidas.
10) Gestión de Proyectos y Procesos.
2) Documentación y Presentación
 Permiten ver el Sistema sin tener que interactuar con él.
Las técnicas de comunicación son esenciales, para terminar con éxito un proyecto. Existen dos
formas habituales de comunicación, durante los proyectos de desarrollo de sistemas:
La documentación es una actividad consistente en registrar los hechos y las especificaciones de un
sistema. Ej.
 Manual de Usuario: se entrega al finalizar al proyecto. (¿Cómo tengo que hacer para
utilizar el sistema?).
 Carpeta del Sistema: Todo lo que se desarrolle para el Sistema final queda documentado.
Las presentaciones son actividades relacionadas, consisten en el envío formal de la

documentación, para su revisión por los usuarios y los directivos interesados, generalmente se
hacen al finalizar cada etapa. Las presentaciones pueden ser:
 Escritas: se recomienda que no tengan términos técnicos y que no sean muy extensas.
 Orales: una ventaja es la de interactuar con los oyentes. Una desventaja es que no queda
nada registrado.
Claramente, las oportunidades de documentación y presentaciones se extienden a lo largo de todo
el ciclo de vida y apoyan todas las fases del proyecto: planificación, análisis, diseño, implantación y
soporte.
3) Estimación y medidas
Los sistemas de información son importantes inversiones de capital. Por este motivo, se llevan a
cabo normalmente actividades de estimación y medida para estudiar la calidad y la productividad
de los sistemas.
La estimación es la actividad encargada de calcular el tiempo, el esfuerzo, los costes y las ventajas
del desarrollo de un sistema. En ausencia de datos fiables, se utiliza él termino conjeturación (es
decir, hacer conjeturas) para describir esta misma actividad.
La medida es la actividad consistente en medir y analizar la productividad y la calidad (y, a veces,
los costos) de las personas que desarrollan el sistema.
 Medida: calidad y avance del proyecto.
 Medida de la Calidad: que tanto me ajusto a esa medida ya definida.
 Medida de avance del Proyecto: compara lo que se había planificado con el desarrollo
real de la tarea.
Viabilidad: es la medida del beneficio obtenido en una Organización gracias al desarrollo de un

Sistema de Información.
En otras palabras, es la medida de las ventajas que el desarrollo de un sistema de información

podría reportar a una organización.
El análisis de viabilidad es la actividad/proceso por la cual se mide la viabilidad.
Cuatro Test de Viabilidad

 Viabilidad Operativa: es una medida del correcto funcionamiento de una posible solución
a los problemas dentro de una Organización.
Mide la Urgencia del problema. ¿Vale la pena resolver el problema? ¿Puede funcionar?
Opinión de los Usuarios finales y directivos ¿Realmente funcionará?
 Viabilidad Técnica: es una medida del éxito de la puesta en práctica de una solución
técnica específica y de la disponibilidad de los recursos y los conocimientos técnicos
necesarios.
La voy a poder evaluar cuando esté en la Etapa de Diseño.
¿Es práctica la solución propuesta?
¿Dispone la empresa o en la Actualidad de esa Tecnología?
¿Disponemos de los conocimientos técnicos necesarios y son razonables los plazos?
 Viabilidad Temporal o de Fechas: es una medida que indica si un proyecto es razonable en
el cumplimiento de su calendario.
Al finalizar cada una de las fases, desde la primera, yo puedo hacer un test de viabilidad
por fechas.
Plazos obligatorios: por cuestiones legales.
Plazos deseables: los plazos ideales a cumplir.
 Viabilidad económica: es una medida de la eficacia de los costes asociados a un proyecto
o a una solución. A menudo suele recibir el nombre de “Análisis de costos y beneficios”.
Generalmente se evalúa en la Etapa de Diseño.
Costos asociados al Desarrollo o a la Implementación.
5) Gestión de Proyecto
Los proyectos de desarrollo de sistemas pueden implicar a un equipo de analistas,
programadores, usuarios y otros profesionales de los sistemas de información que han de
trabajar conjuntamente
La Gestión de Proyecto es el proceso por el cual se planifica, dirige y controla el desarrollo de un
Sistema aceptable, con un costo mínimo y dentro de un periodo específico.
Es la actividad continuada por la cual el analista planea, delega, dirige y controla el avance de los
proyectos para desarrollar un sistema acorde con los plazos y los presupuestos asignados.
Gestión de procesos es una actividad continuada que establece normas para las actividades, los
métodos, las herramientas y los resultados del ciclo de vida. La gestión de procesos es un
concepto relativamente novedoso en el desarrollo de sistemas. Su intención es normalizar tanto el
modo de enfocar los proyectos como los resultados intermedios que se producen mediante estos
proyectos. Muchos centros de información forman equipos de garantía de calidad para evaluar los
productos obtenidos en los proyectos. Esta medida no pretende limitar la creatividad, sino más
bien asegurar que la documentación producida sea más transferible a la siguiente generación de
programadores y analistas que trabajen en un sistema dado.
Causas de Fracasos en los Proyectos / Causas de Proyectos Fallidos

 Falta de aplicación de técnicas de análisis y diseño.
 Necesidades no satisfechas o no identificadas.
 Mala gestión de Proyecto:
 Síndrome de necesidades que crecen.
 Omisión del Ciclo de Vida.
 Exceso en Costos: necesidad de estimación precisa antes de comenzar. Uso de
técnicas deficientes de estimación. Retraso de los plazos por mala estimación etc.
PLANIFICACIÓN
 Plan general del Proyecto.
 Plan particular por Etapas.
 Control de avances:
 Objetivos modificados.
 Complicaciones inesperadas.
 Desviación del calendario.
Pasos para Planificar:

1) Definir las actividades que componen el proyecto.
2) Establecer las secuencias de las actividades. Orden de precedencia.
3) Determinar tareas resúmenes (Agrupar o englobar un conjunto de subtareas).
4) Analizar y asignar tiempos de duración de cada tarea.
5) Establecer vinculación entre tareas:
 Comienzo a fin (Para que termine la tarea A tiene que haber comenzado la tarea
B).
 Fin a comienzo (Termina una tarea para que comience otra).
 Fin a fin (Las dos tareas terminan juntas).
 Comienzo a comienzo (Las dos tareas comienzan juntas).
6) Identificar Hilos del Proyecto (Puntos de control que se puedan definir en el desarrollo del
proyecto).
7) Determinar recursos a asignar a las tareas (Ej. RR.HH).
8) Asignar recursos a las tareas.
9) Resolver las sobreasignaciones de recursos.
10) Determinar Costo Total y Duración del Proyecto.

11) Determinar el Camino Crítico, Secuencia de tareas Críticas.
12) Procurar minimizar el Costo Total del Proyecto.
Clase Nº 5
HERRAMIENTAS DEL MODELADO
Modelar un Sistema: Representarlo Gráficamente.
Si el Sistema existe el modelado permite identificar problemas.
Si el Sistema en nuevo, el mismo es una representación de las Soluciones a los Problemas.
Herramientas Gráficas:
 Diagrama de Flujo de Datos (DFD).
 Diagrama Entidad-Relación (DER).
 Diagrama de Transición de Estados (DTE).*
 Diagrama de Conexión de Puestos (DCP).*
*pueden estar presentes o no, dependiendo de las características del Sistema.
Herramientas Textuales:
 Diccionario de Datos (DD).
 Especificación Lógica de Procesos (ELP).
Diagrama de flujo de datos (DFD): Esta es una herramienta que permite visualizar al sistema como
una red de procesos funcionales, conectados entre si por “conductos” y “tanques de
almacenamiento” de datos.
 Modela procesos
 Organiza y documenta los procesos de un sistema, Sus entradas, salidas y
almacenamiento.
 Red de procesos asíncronos.
Elementos de un DFD
El proceso
El primer componente de un DFD se conoce como proceso. El proceso muestra una parte del
sistema que transforma entradas en salidas; es decir muestra cómo es que una o más entradas se
transforman en salidas. El proceso se representa gráficamente como un círculo, algunos analistas
prefieren usar un óvalo o un rectángulo con esquinas redondeadas.
Un buen nombre para el proceso generalmente consiste en una frase verbo-objeto tal como
VALIDAR ENTRADA
El Flujo
El flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso. Se
utiliza para describir el movimiento de bloques o paquetes de información de una parte del
sistema a otra. Los flujos representan datos en movimiento.
Los flujos muestran la dirección. Tienen un nombre y no tiene que ser verbo el nombre del mismo.
El Almacén
El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota con
dos líneas paralelas. El nombre que se utiliza para identificar al almacén es en plural del que se
utilizan para los paquetes que entran y que salen del almacén por medio de flujos.
Los almacenes se conectan por flujos a los procesos. Así, el contexto en el que se muestra un
almacén en un DFD es uno de los siguientes o ambos:
 Un flujo desde un almacén
 Un flujo hacia un almacén
El Terminador
Gráficamente se representa como un rectángulo. Los terminadores representan entidades
externas con las cuales el sistema se comunica. Comúnmente un terminador es una persona o un
grupo de personas, o un grupo o departamento que esté dentro de la misma empresa, pero fuera
del control del sistema que se esta modelando.
 Son externos al sistema que se esta modelando
 Como consecuencia, es evidente que ni el analista ni el diseñador del sistema están en
posibilidades de cambiar los contenidos de un terminador o la manera que trabaja.
 Las relaciones que existan entre los terminadores no se muestran en el modelo de DFD.
Por definición no son parte del sistema que se esta estudiando.
Guía para la construcción de un DFD

 Escoger nombres con significado
 Numerar los procesos
 Redibujar el DFD tantas veces como sea necesario, hasta que estéticamente sea correcto
 Evitar DFD demasiado complejos
 Evitar sumideros infinitos (procesos con entradas solamente) y burbujas de generación
espontánea (procesos con salidas solamente)
 Tener cuidado con flujos y procesos no etiquetados
 Tener cuidado con almacenes de “solo lectura” y “solo escritura”.
Modelo esencial:
 Modelo ambiental
o Declaración de Propósitos: descripción breve de lo que va a hacer el sistema
o Diagrama de contexto: enfatiza varias características importantes del sistema
Las personas, organizaciones y sistemas con los que se comunica el sistema. Se conocen como
terminadores.
Los datos que el sistema recibe del mundo exterior y que deben ser procesados de alguna forma.
Los datos que el sistema produce y que se envían al mundo exterior.
Los almacenes de datos que el sistema comparte con los terminadores.
La frontera entre el sistema y el resto del mundo
o Lista de acontecimientos: es una lista narrativa de los estímulos que ocurren en el
mundo exterior a los cuales el sistema debe responder.
 Modelo de comportamiento: modela el comportamiento del Sistema. Lo que tiene que
hacer el sistema para cumplir con la declaración de los propósitos
Modelo Preliminar
Parte de la lista de acontecimientos, consiste en dibujar una burbuja por cada acontecimiento.
El nombre de la burbuja es lo que hace el sistema para responder a ese acontecimiento.
Cada una de las burbujas siempre esta relacionada a otra por medio de un almacén.
Figura Cero
 Agrupar los procesos relacionados
 Esconder almacenes
 Regla de miller 7+- 2 (que la figura cero no tenga mas de 9 burbujas)
Nivelación descendente
La figura cero es un único DFD que representa todo lo que estuve modelando.
Para la explosión de una burbuja se toma cada una de las burbujas de la figura cero y por cada una
se describe en detalle cada proceso.
Diagrama Entidad Relación (DER)

Todos los almacenes del DFD tienen que ser entidades en el DER.
Es un modelo de red que describe con un alto nivel de abstracción la distribución de datos
almacenados en un Sistema.
Los componentes de un DER:
Entidades:
 Personas
 Suceso
 Objetos
Relaciones
Tipo de relaciones:
Cardinalidad
 Uno a uno
 Uno a muchos
 Muchos a muchos
Atributos
Diagrama de transición de estados (DTE)

Enfatiza comportamientos en Sistemas de Tiempo Real
Notación
Estados
Cada rectángulo representa un estado en que se puede encontrar el sistema.
 Estado inicial: típicamente suele ser el que se dibuja en la parte superior del diagrama.
 Cambios de estado: se muestran los cambios de estado válidos en un DTE conectando
pares relevantes de estados con una flecha.
Condiciones
Las condiciones y acciones se muestran junto a la flecha que conecta dos estados. Una condición
es un acontecimiento en el ambiente externo que el sistema es capaz de detectar.
 Acontecimiento externo
 Producen cambios de estados
Acciones
Como parte del cambio de estado, normalmente el sistema hará una o mas acciones: producirá un
salida, desplegará una señal. Llevará a cabo un cálculo etc. Así las acciones realizadas en un DTE
son respuestas regresadas al ambiente externo.
 respuestas
Diccionario de datos
Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y
rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las
entradas, salidas, componentes de almacenes y cálculos intermedios.
 Describe el significado de los flujos y almacenes que se encuentran en el DFD
 Describe la composición de agregados de paquetes de datos que se mueven a lo largo de
los flujos.
 Describen la composición de los paquetes de datos en los almacenes
 Especifica los valores y unidades relevantes de piezas elementales de información en los
flujos de datos y en los almacenes de datos
 Describe los detalles de las relaciones entre almacenes que producen en un DER.
Notación del Diccionario de Datos

= está compuesto de
+y
() Optativo (puede estar presento o ausente)
{} Iteración
** Comentario
@ Identificador
/ separa opciones alternativas en la construcción
Especificación de Procesos
Es la descripción de qué es lo que sucede en cada burbuja primitiva del nivel mas bajo de un DFD,
para aquellos que no tiene nivelación descendente. Define lo que debe hacerse para transformar
entradas en salidas.
 La especificación de proceso debe expresarse de una manera que puedan verificar tanto
usuario como analista.
 El proceso debe especificarse de una forma que pueda ser comunicado efectivamente al
público amplio que este involucrado.
Existen una variedad de herramientas que podemos utilizar para producir especificación de
procesos:
 Lenguaje estructurado
 Pre/Post condiciones: especifica lo que dice el proceso pero sin dar especificaciones del
algoritmo.
 Tabla de decisiones: cuando las decisiones se basan en diversas variables distintas, y
dichas variables pueden tomar diversos valores.
 Diagrama de flujo
 Etc.
Más Información:
http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/maf/cap2.htm
Clase Nº 6
Principios esenciales:
1. Implicar al usuario: Las personas responsables del desarrollo de sistemas deben reservar
tiempo para los usuarios, insistir en la participación de estos en el proyecto y buscar un acuerdo
sobre las decisiones que puedan afectarle, porque al fin y al cabo, ellos son los reales usuarios del
sistema.
2. Aplicar un método de resolución de problemas: por ser “el ciclo de vida de desarrollo de
sistemas” un método de resolución de problemas es necesario buscar una solución eficaz para el
mismo.
a) Identificar el problema, oportunidad o norma.

b) Comprender el contexto del problema, causas y efectos del mismo.
c) Definir los requisitos para alcanzar una solución adecuada.
d) Hallar soluciones alternativas
e) Elegir la mejor solución.
f) Diseñar e implantar la solución.
g) Observar y evaluar el impacto de la solución.
3. Definir fases y actividades: consiste en dividir el CVSI en fases etapas y actividades para poder
manejarse y cumplirse con más facilidad.
4. Establecer normas para un desarrollo y una documentación consistente: sirve para poner de
acuerdo a los participantes del sistema en caso de ser ascendidos o cambiados de lugar, para que
no adopten posturas independientes. Describen actividades, responsabilidades, requisitos de
documentación, controles de calidad.
5. Justificar los sistemas como inversión de capital: Los sistemas de información son inversiones
de capital, en la mayoría de los casos los directivos no los consideran así.
Existen varias soluciones al problema que incurren diferentes costes, habría que analizarlos a
todos.
6. No tener miedo de cancelar o revisar un proyecto: una ventaja del método por fases es la
oportunidad de revaluar su viabilidad. El analista no debe tener miedo de cancelar el proyecto si
ha dejado de ser viable, revelará los costes y plazos del proyecto o el recorte de dicho proyecto si
se ha congelado el presupuesto.
7. Divide y vencerás: todos los sistemas forman parte de sistemas mayores. Dividimos el sistema
en subsistemas con el fin de controlar con más facilidad y ser capaces de construir sistemas más
grandes.
8. Diseñar sistemas que puedan crecer y cambiar: la mayoría de los analistas cometen el error de
desarrollar sistemas que satisfagan necesidades "Para hoy". Ningún sistema dura para siempre, un
sistema debería estar hecho de manera tal que pueda crecer o ser modificado en el momento
requerido.
Metodología Moderna (STRADIS):

Consta de las siguientes Etapas:
1) Planificación de sistemas
2) Análisis de sistemas
3) Diseño de sistemas
4) Implementación de sistemas
5) Soporte o mantenimiento de sistemas
1. PLANIFICACIÓN DE SISTEMAS:
La planificación estratégica de sistemas pretende identificar y establecer prioridades acerca de

aquellas tecnologías y aplicaciones que reparten un máximo beneficio para la empresa. La
planificación de sistemas se basa en las preocupaciones manifestadas por los propietarios de
sistemas y en los temas estratégicos de las empresas. Consta de tres fases distintas que estudian
los bloques elementales (personas, datos, actividades y redes). El resultado de cada fase se
almacena en un diccionario de planificación.
Las tres fases de esta Etapa son:
a) Fase de estudio: (estudiar el cometido de la empresa). El propósito de la fase de estudio es
conocer el ámbito y el cometido de la empresa. El cometido de la empresa puede analizarse en
el contexto de varias estructuras, entre las que se incluyen el análisis de factores críticos de
éxito, el análisis de la competencia y el análisis de la cadena de valores. Una fase de estudio
completa incluye estas actividades:
Actividad 1: Formar el equipo de planificación.
Actividad 2: Definir el ámbito y las expectativas de la planificación.
Actividad 3: Identificar medidas de rendimiento de la empresa.
Actividad 4: Desarrollar un plan de proyecto.
Actividad 5: Revisar las conclusiones y comunicar las aspiraciones de la empresa.
El producto resultante de la fase de estudio es un informe de planificación de proyectos que
transmite las aspiraciones de la planificación y decide la fase de definición venidera.
b) Fase de Definición: (definir una arquitectura de información). El propósito de la fase de

definición es definir una visión y un plan para el empleo de tecnología de información y el
desarrollo de los sistemas de información necesarios para apoyar una misión de empresa. Para
construir esta arquitectura de información, el equipo de planificación debe completar las
siguientes actividades:
Actividad1: Elaborar un modelo de empresa.
Actividad2: Evaluar las estrategias actuales de la empresa.
Actividad3: Evaluar los servicios y las estrategias actuales de información.
Actividad4: Identificar y fijar prioridades en torno de las áreas de empresa.
Actividad5: Completar la nueva arquitectura de información.
Actividad6: Identificar y planear proyectos posteriores.
Actividad7: Revisar las conclusiones y aprobar el plan.
Algunas de estas actividades pueden hacer uso de herramientas y técnicas especiales, como
matrices de asociaciones, análisis de afinidades y análisis de agrupaciones.
El producto final de la fase de definición recibe el nombre de plan y arquitectura de información.
En el se expone un plan estratégico de alto nivel para los sistemas de información. Esta
arquitectura expone una serie de modelos gráficos de empresa. El modelo de empresa clave se
denomina modelo sustancial de datos, en torno al cual pueden integrarse las funciones de
empresa y los procesos de empresa.
c) Fase de Análisis: (analizar las áreas de la empresa). El propósito de la fase de análisis es aplicar
el plan para una única área de empresa. Un área de la empresa es una agrupación lógica de
procesos, datos y lugares de empresa, sin considerar los límites o las estructuras organizativas.
El objetivo es elaborar un plan que obtenga aplicaciones altamente integradas para las áreas de
la empresa. Las actividades incluyen:
Actividad1: Formación del equipo de análisis.
Actividad2: Identificar medidas de rendimiento del área de empresa.
Actividad3: Elaborar un modelo del área de empresa.
Actividad4: Evaluar el rendimiento actual del área de empresa y de los sistemas de información.
Actividad5: Identificar y establecer prioridades en los proyectos de desarrollo.
Actividad6: Planear proyectos de desarrollo.
Actividad7: Revisar las conclusiones y aprobar el plan.
El producto final de esta fase es un plan de área de empresa, proyectos planificados de desarrollo
de bases de datos y redes y proyectos planificados de desarrollo de aplicaciones. Este ultimo
producto final activa la Etapa de Análisis de sistemas
Clase Nº 7
2. ANÁLISIS DE SISTEMAS
El análisis de sistemas es un método de resolución de problemas.
Más específicamente es el estudio de una aplicación de un sistema actual de empresa y de la
información y definición de las necesidades y prioridades de usuario, para posteriormente obtener
un sistema nuevo y mejorado.
El análisis de sistemas se basa en los asuntos de interés para los usuarios de los sistemas y las
cuestiones de empresa (no en temas técnicos o de implantación). Consta de tres fases distintas
referidas a los bloques elementales (personas, datos, actividades y redes), desde la perspectiva del
usuario.
BLOQUES ELEMENTALES
Son los aspectos a cubrir en el Ciclo de Vida de un Sistema de Información.
1. Bloque Elemental Personas
Es el bloque más importante. Las personas se clasifican en:

a) Propietarios de Sistemas: patrocinan y promueven los sistemas de información. Son
normalmente responsables de fijar el presupuesto y el plazo necesario para desarrollar y
mantener el sistema de información, y deciden en último término la validez del sistema de
información.
b) Usuarios de sistemas: son aquellas personas que utilizan el sistema de información (y obtienen
beneficios directos del mismo), de forma regular: capturan, validan, introducen y almacenan datos
e información.
c) Diseñadores de sistemas: traducen las necesidades y las restricciones de empresa,
manifestadas por los usuarios a soluciones técnicas. Diseñan los archivos, las bases de datos, las
entradas, las salidas, las pantallas, las redes y los programas informáticos requeridos por los
usuarios de sistemas. Además, integran las soluciones técnicas en el entorno cotidiano de trabajo
de la empresa.
d) Constructores de sistemas: fabrican sistemas de información multiusuario basados en las
especificaciones de diseño obtenidas de los diseñadores de sistemas. (Los usuarios finales, con
ayuda de los consultores del centro de información, se encargan normalmente de construir sus
propios sistemas de información personales).
2. Bloque elemental Datos: los datos pueden, y deberían, interpretarse como la materia prima
utilizada para producir información. Consideramos que los datos deben constituir uno de los
pilares fundamentales de un sistema de información.
Dato: es una colección de hechos considerado de forma aislada, describen la organización. Estos
portan un significado, pero en general no son de utilidad por sí solos.
Información: es un dato que ha sido manipulado, con lo que resulta de utilidad para alguien. Debe
tener valor sino, seria un dato. La información dice a la gente que no sabia o le confirma algo que
sospecha.
Lo que para una persona es información, para otra puede ser un simple dato. Personas diferentes
pueden tener visiones diferentes de los datos.
a) Como ven los datos los propietarios de sistemas: ven a los datos como recursos que ayudan a
gestionar mejor los otros recursos de empresa.
Recurso de la empresa: son cosas esenciales para los propósitos o los objetivos del sistema; o
cosas que han de ser gestionadas o controladas para alcanzar las metas y los objetivos de la
empresa. Los más importantes son: cosas tangibles (materiales, maquinas), funciones (clientes,
proveedores, empleados), sucesos (pedidos, solicitudes, contratos), lugares (oficinas de ventas e
instalaciones).
Cuando los analistas de sistemas traten con los propietarios de sistemas, intentaran señalar los
recursos que son importantes para el sistema. También intentaran conocer los problemas, las
oportunidades y las restricciones que se aplican a las entidades. El analista utiliza él término
entidad para describir un recurso. Para el analista cada una de las entidades puede ser descripta
con datos. El analista debe evitar hablar de herramientas y técnicas que se relacionen con
cuestiones de detalles.
b) Como ven los datos los usuarios de sistemas: son expertos en datos, como trabajadores de la
información se encargan de capturar, almacenar, procesar, editar y utilizarlos en forma cotidiana.
Para ellos, se registran en formularios, se guardan en armarios de archivos, libros y carpetas, en
hojas de cálculo y base de datos informáticas.
El analista de sistemas se enfrenta, al reto de identificar y verificar las necesidades de datos de los
usuarios solo en términos de empresa de forma que puedan plantearse formas alternativas de
implantación de los mismos.
c) Como ven los datos los diseñadores de sistemas: definen las necesidades de datos de un
sistema de información; a su vez las convierten en bases de datos y archivos informáticos que
servirán de soporte al "bloque elemental actividades" del sistema de información, su visión se
limita por tecnologías especificas.
El analista puede elegir la tecnología pero a menudo ya viene dada y este debe utilizar la que tiene
disponible.
En todos los casos los diseñadores de sistemas ven los datos en forma de disposiciones de
registros, estructuras de datos, esquemas de bases de datos, organizaciones de archivos, campos,
índices y otros ítems técnicos. Algunos pueden ser correctamente interpretados por los usuarios
del sistema pero en la mayoría de los casos esto no es así.
La intención del diseñador es representar el diseño de modo que: 1) satisfaga las necesidades de
datos de los usuarios, 2) ofrezca el nivel de detalle y la consistencia suficientes para transmitir el
diseño de datos a los constructores de sistemas.
d) Como ven los datos los constructores de sistemas: La visión final de los datos es importante
para los constructores de sistemas. En el modelo en pirámide, los constructores de sistemas son
los que están más próximos a la base tecnológica. No debe sorprender, ya que están obligados a
representar los datos en lenguajes muy precisos y estrictos. Los constructores de sistemas
escriben programas de datos para su implantación en las bases de datos y los archivos
informáticos.
3. Bloque elemental de Actividades

Los eventuales clientes definen la función deseada y el analista crea un diseño que realice dicha
función. Las ACTIVIDADES definen la función de un sistema de información.
Las actividades de una empresa son procesos cotidianos que sirven para apoyar sus cometidos,
metas y objetivos. Las actividades pueden ser por ejemplo: marketing, las ventas, las operaciones
de almacén.
Las actividades de los sistemas de información son procesos que apoyan las actividades de
empresa por medio de: 1) el suministro de datos y el proceso de información 2) la mejora y la
simplificación de las actividades de empresa.
a) Como ven las actividades los propietarios de sistemas: los propietarios de sistemas determinan
cuales son las funciones de los sistemas de información de las que se extraerán mayores ventajas y
beneficios para la empresa. Los propietarios de los sistemas ven sus funciones de empresa a través
de diversos parámetros de planificación, como son las metas y los objetivos.
Las metas son declaraciones generales de intenciones, algo que la empresa quiere conseguir.
Los objetivos son fines más específicos que ayudan a alcanzar las metas.
b) Como ven las actividades los usuarios de sistemas: Los usuarios ven las actividades en función
de los distintos procesos de empresa.
Los procesos de empresa son actividades que tienen entradas y salidas. Estos procesos se basan
con frecuencia en métodos específicos y procedimientos de aplicación pasa a paso. Los procesos
de empresa pueden ser puestos en marcha por personas, maquinas u ordenadores.
Naturalmente, los procesos de datos y la generación de información son procesos de empresa
llevados a cabo por sistemas de información. En las empresas, existe una necesidad imperiosa de
replantearse totalmente los procesos para eliminar las redundancias, aumentar la eficacia y
simplificar el funcionamiento global de la empresa. Una vez mas, los analistas de sistemas han de
afrontar el reto de detectar y expresar las necesidades de procesos que afectan a los usuarios
exclusivamente en términos de empresa (por ejemplo, que métodos y formas alternativas de
implantación deberían considerarse).
c) como ven las actividades los diseñadores de sistemas: La visión que tienen los diseñadores de
sistemas de las actividades esta condicionada por las limitaciones de la tecnología especifica. En
ocasiones el analista puede elegir esta tecnología. Pero a menudo la elección ya ha sido hecha, y el
analista debe utilizar la tecnología existente. En ambos casos la visión de las actividades es de
carácter más bien técnico.
El diseñador debe, en primer lugar, determinar que actividades deben automatizarse y como se
automatizaran. De aquí en adelante, el diseñador tiende a pensar en términos de procesos
informáticos.
Los procesos informáticos son procesos de empresa que se implantan, o implantarán en el
ordenador. Los procesos informáticos pueden automatizar procesos de empresa o simplemente
apoyar los procesos de empresa.
La visión del diseñador acerca de los procesos informáticos se describe normalmente en función
de especificaciones informáticas de programas, como esquema de estructuras, organigramas
lógicos, y diagramas de registros.
El analista de sistemas y otros especialistas de los sistemas de información estudian y documentan

estas visiones técnicas de las actividades de los sistemas.
d) como ven las actividades los constructores de sistemas: Los constructores de sistemas
representan las actividades por medio de precisos lenguajes de programación informática que
describen las entradas, las salidas y los procesos lógicos. Estos lenguajes se utilizan para escribir
programas de aplicaciones.
Los programas de aplicaciones son representaciones basadas en lenguajes y comprensibles por las
máquinas sobre lo que se supone que debe hacer un proceso informático, o las acciones que debe
desarrollar un proceso informático para cumplir una determinada tarea.
4. Bloque elemental de Redes

Las redes son:
1) Estructuras de distribución de personas, datos, actividades y tecnología (los restantes bloques
elementales) en los lugares adecuados de la empresa.
2) Movimientos de datos entre dichos lugares.
El diseño de redes pretende suministrar procesos cooperativos entre los sistemas, los ordenadores
y las personas.
Existen redes de empresa y redes de ordenadores. Los analistas de sistemas son los encargados de
comprender estas diferentes perspectivas.
a) como ven las redes los propietarios del sistema: Para el propietario de un sistema, el diseño de
redes no es un asunto técnico. En realidad es de carácter meramente geográfico.
La geografía de un sistema es el conjunto de lugares geográficos donde la empresa elige o necesita
realizar sus operaciones.
Los analistas de sistemas deben aprender que funciones de empresa se llevan a cabo en cada uno
de estos lugares.
Los propietarios de sistemas decidirán en última instancia el grado de centralización, distribución o
duplicación que caracterizara el sistema. En estas decisiones existen importantes consideraciones
de índole política o económica.
Cuando trata con propietarios de sistemas, el analista puede mostrar la distribución geográfica de
un sistema de información con simples mapas o planos de las plantas. También puede utilizar
matrices para determinar las funciones que se llevan a cabo en cada lugar.
b) como ven las redes los usuarios del sistema:

Gracias a la visión que tienen de los datos y los procesos, los usuarios de sistema son los mejores
situados para determinar las necesidades requeridas en un lugar concreto. Como los propietarios
de sistemas, los usuarios se interesan por los lugares de trabajo. Pero al estar más inmersos en la
labor cotidiana pueden señalar lugares que son desconocidos para los propietarios de sistemas, o
que estos han olvidado. Los usuarios suelen tener una visión más detallistas de los puestos.
También los usuarios pueden señalar algunas definiciones muy especiales de los lugares.
Los puestos de trabajo se pueden definir en lugar único y genérico que representa cualquier sitio
donde se encuentra el usuario en cualquier instante. Esto obligará a los usuarios, los diseñadores y
los constructores de sistemas a considerar posibilidades creativas como por ejemplo el uso de
ordenadores portátiles. Pero los mas impórtate es que los usuarios puedan pensar en términos de
redes de empresa.
Una red de empresa define los lugares detallados de trabajo, los recursos específicos disponibles
en cada lugar y las necesidades de comunicaciones de empresa entre dichos lugares. Una red de
empresa no requiere necesariamente una red informática.
A veces, las redes de empresa reciben el nombre de redes logísticas.
c) como ven las redes los diseñadores del sistema: La visión que tienen de las redes los
diseñadores de sistema esta condicionada por las limitaciones impuestas por el uso de una
tecnología especifica. Su interés se centra más bien en las redes informáticas que pueden servir de
soporte a la red de empresa.
Una red informática es una disposición técnica que interconecta ordenadores y periféricos de
manera que puedan intercambiar datos y compartir recursos técnicos.
A veces recibe el nombre de arquitectura distribuida de sistema.
Una vez más, pocas veces es capaz el analista de elegir esta tecnología. Con frecuencia, la elección
ha sido ya realizada y el analista debe hacer uso de la tecnología diseño de redes disponible. En
cualquier caso, la visión que tiene de las redes el diseñador es de carácter técnico.
Sobre la base de la visión que tienen los usuarios de sistemas de la red de empresa, el diseñador
de sistemas debe crear una nueva red informática (o usar una ya existente) con el fin de llevar a la
practica el sistema distribuido de información deseado.
Los sistemas de información distribuida son aquellos en que los datos y los procesos se han
dividido en subconjuntos que se encuentran técnicamente distribuidos, o duplicados, en múltiples
lugares. Él término opuesto, es sistemas de información centralizada.
El analista de sistema y los especialistas en telecomunicaciones estudian y documentan estas
visiones técnicas de las redes.
d) Como ven las redes los constructores de sistemas: Solo la visión final de las redes resulta
importante para los constructores de sistemas. Estos utilizan lenguajes y estándares de
telecomunicaciones para escribir los programas de redes.
Los programas de redes son especificaciones comprensibles por la maquina de parámetros de
comunicaciones informáticas tales como direcciones de nodos, protocolos, velocidades de línea,
controles de flujo y otros parámetros técnicos complejos.
5. Bloque elemental Tecnología

La tecnología es la base de la pirámide de los sistemas de información. Colectivamente estas

tecnologías reciben a menudo el nombre de tecnologías de información.
La tecnología de información designa la moderna combinación de tecnologías informáticas y de
telecomunicaciones. En la tecnología de información se incluyen los ordenadores, los periféricos,
las redes, y otros tipos de dispositivos tecnológicos que apoyan el proceso de informaciones y las
comunicaciones de la empresa.
Base de tecnología de información de los sistemas de información:
a) tecnología de datos: Los bloques elementales datos de los sistemas de información se
implantan por medio del empleo de tecnología de datos.
La tecnología de datos incluye todo el hardware y software requerido para capturar, almacenar y
gestionar los recursos de datos
b) Tecnología de procesos: Los bloques elementales actividades de los sistemas de información se

implantan por medio del empleo de tecnología de procesos.
La tecnología de procesos incluye todo el hardware y software requerido para apoyar las
actividades de los sistemas de empresa y de información.
Naturalmente, en ello se incluyen tanto los ordenadores como sus periféricos de entrada/salida
(por ejemplo, impresoras, pantallas, ratones, escáneres y lectores ópticos), así como los programas
de aplicaciones.
c) tecnología de comunicaciones: Los bloques elementales redes de los sistemas de información

se implantan por medio del uso de tecnología de comunicaciones.
La tecnología de comunicaciones, también denominada tecnología de diseño de redes o de
telecomunicaciones, incluye el hardware y software utilizado para interconectar la tecnología de
datos y de procesos en diferentes lugares.
d) Especialistas técnicos: Los propietarios, usuarios, diseñadores y constructores de sistemas

deben poder ser apoyados en su tarea por especialistas técnicos conocedores de la tecnología.
Los especialistas técnicos venden, configuran, reparan y mantienen tecnología de información de
cara a los propietarios y los usuarios de sistemas.
Personas Datos Actividades Redes
Recursos de la Funciones de la
Propietario Geográficas
Organización Empresa
Procesos de la
Usuarios Necesidades de Datos Puestos de Trabajo
Empresa
Necesidades de BD y
Diseñadores Procesos Informáticos Redes Informáticas
Archivos
Necesidades físicas de Programas de

Constructores Programas de Redes
BD y de Archivos Aplicaciones
Más cerca de la Parte funcional del Sistema

Más cerca de la Parte tecnológica del Sistema
Clase Nº 8

3. ETAPA DE ANÁLISIS (continuación Clase 7)

Las Fases que debemos cumplir en esta Etapa son las siguientes:
Nota: No olvidarse que cada Etapa del C.V.S.I consta de varias Fases, y que cada fase consta de
varias Actividades
a) Fase de inspección: Tiene por objeto contestar a la pregunta ¿Merece la pena el proyecto?
Algunos proyectos no requieren esta evaluación, porque ya han sido justificados por un equipo
de planificación o la dirección de la empresa.
Los objetivos fundamentales de la fase de inspección.
 Identificar los problemas, las oportunidades y/o las normas que dieron lugar a la solicitud del
proyecto.
 Determinar si, resolver los problemas, aprovechar las oportunidades Y/o cumplir las normas
reportarán beneficios a la empresa.
Actividades a desarrollar en esta fase:

Actividad 1: Dirigir las entrevistas iníciales: Consiste en realizar una o mas entrevistas a la/s
persona/s que solicito/solicitaron el proyecto.
Puede consistir en crear una matriz con los siguientes datos:
 Lista de personas datos, actividades, lugares y redes, a si como la tecnología existente.

 Lista de problemas y oportunidades que llevaron a la solicitud del proyecto.
 Cualquier restricción idea u opinión que considere relevante.
Actividad 2: Definir el ámbito del proyecto: Basándose en las entrevistas anteriores el analista
debería definir el ámbito inicial del proyecto. No es esencial, ni posible una precisión absoluta. Una
de las formas más sencillas de definir este ámbito es elaborar diagramas de contexto, que son
imágenes simples que reflejan entradas y salidas y relaciones con otros subsistemas de la
empresa.
Elaboramos el Diagrama de contexto de nuestro Proyecto.
Actividad 3: Clasificar problemas oportunidades y posibles soluciones: en base a los hechos

descubiertos en los puntos anteriores, el analista y el propietario / usuario del sistema, clasificarán
los problemas oportunidades y soluciones en función de:
 La urgencia: intervalo de tiempo en que debería resolverse el problema o aprovecharse la
oportunidad.
 La visibilidad: en que medidas son percibidos el problema o la oportunidad por los directivos
de la empresa.
 Los beneficios actuales: en cuanto aumentaría los beneficios o reduciría los costos la solución
al problema o la oportunidad.
 La prioridad: en base a las respuestas anteriores determinar un orden en importancia.
 La solución: se clasifican en:
a) Dejar las cosas como están (el problema no existe, el problema no es tan grave, es
demasiado costoso).
b) Corrección rápida.
c) Realizar mejoras.
d) Nuevo desarrollo.
Para ello utilizamos una Matriz de Problemas/Oportunidades:
Oportunidades/Problemas Visibilidad Urgencia Prioridad Solución
Los expedientes de
Solucionar en 6 Nuevo
proveedores y clientes ALTA
Meses Desarrollo
carecen de organización
…… ….. ….. …..
Actividad 4: Establecer un plan de proyecto propuesto: si se recomienda una mejora o un nuevo

desarrollo, el analista tendrá que desarrollar un plan de proyecto inicial. El plan de proyecto se
basa en la experiencia y en las estimaciones de tamaño y modelos de sistema propuestos y las
soluciones posibles.
Utilizamos como Herramienta cualquier software recomendado por la cátedra para la planificación
de fechas ej. Project.
Actividad 5: Presentar la conclusiones y las recomendaciones de la inspección: el analista y el

propietario o usuarios se encargan de reunir la documentación apropiada y presentar la
evaluación de viabilidad de proyecto para la toma de decisiones (aceptar recomendación,
enmendar, devolver las recomendaciones o rechazar el proyecto):
Clase Nº 9
4. ETAPA DE ANÁLISIS (continuación Clase 8)
b) Fase de estudio: Consiste en estudiar y analizar el sistema actual: dota al analista de una
comprensión mas profunda de los problemas, oportunidades y/o normas.
Los objetivos fundamentales:
 Conocer el entorno de la empresa.
 Conocer las causas y efectos de los problemas
 Conocer las ventajas de aprovechar las oportunidades.
 Conocer las consecuencias de no cumplir las normas.
PIECES: Es un método para analizar los problemas, las oportunidades y las normas.
Prestaciones: Productividad, tiempo de respuesta. Ej. Con que rapidez se efectúa el procesamiento
de información, la velocidad de respuesta esta muy relacionada con la productividad.
Información: Salidas, entradas y almacenado de datos. Información y Datos, problemas y
oportunidades. Información: datos procesados. Datos: que exactitud tienen, calidad de datos,
cuan flexible es la estructura de los mismos.
Economía: costos. Problemas y oportunidades relacionados con los costos.
Control: control demasiado bajo o exceso control. Es el grado de importancia que tiene ese dato
para el usuario. Trata los accesos a los datos e información.
Eficacia y Eficiencia: desperdicio de tiempo, materiales, esfuerzo y materiales requeridos. Eficacia:
que las cosas se hagan bien. Eficiencia: en tiempo y forma.
Servicios: el sistema es incomodo, difícil de usar, de aprender, ineficiente, inexacto. Lo que el
sistema ofrece al usuario, que mejoras puedo incorporar y que problemas tiene actualmente.
Actividades a desarrollar en esta fase:

Actividad 1: Asignar papeles en el proyecto: Una vez planificado el proyecto, el analista, el

director, el propietario y usuarios del sistema deben trabajar conjuntamente, para ello deben
asignarse sus papeles en el proyecto. De esta forma se comparte las responsabilidades en la
participación del proyecto. No se requieren técnicas ni conocimientos especiales para llevar a cabo
esta actividad.
Actividad 2: Conocer el sistema actual: Una vez establecido los participantes y sus papeles
podemos empezar a conocer mejor el sistema actual, esto requiere de la colaboración de todos
ellos. Para conseguir estos resultados el analista debe utilizar técnicas de investigación de hechos:
 Elaboración de entrevistas.
 Reuniones y discusiones en grupo.
 Investigación.
 Observación.
 Muestreo de archivos y formularios.
 Encuesta y cuestionarios.
Actividad 3: Modelar el sistema actual: Para comprender el sistema actual es necesario diseñar
modelos. El modelo es una representación gráfica de la realidad.
Los modelos de sistemas actuales adecuados pueden incluir:
 Personas: organigramas.
 Actividades: diagramas de flujos de datos.
 Datos: diagrama de modelos de datos.
 Redes: modelos de redes.
 La tecnología (Mencionar la tecnología).
LISTA DE EVENTOS / ACONTECIMIENTOS
La información sobre el funcionamiento del sistema actual se obtendrá de los responsables de las
áreas de usuario afectadas que aporten una visión global de la misma y de los propios usuarios
para obtener una visión detallada. Para facilitar esta función, se utilizará la Lista de Eventos, que es
una lista narrativa de los estímulos que ocurren en el mundo exterior a lo cuales el sistema debe
responder. Hay 3 tipos de acontecimientos o de eventos:
 Acontecimientos Orientados a Flujos: se asocia a un flujo de datos. Son aquellos en los
que el sistema se da cuenta de que ha ocurrido algo y contesta a ese evento.
 Acontecimientos Temporales: estos eventos arrancan con la llegada de un momento dado
en el tiempo. No se inician con flujos de datos de entrada; se puede imaginar que el
sistema tiene un reloj interno con el cual puede determinar el paso del tiempo.
 Acontecimientos Orientados a Flujos de Control: deben considerarse como un caso
especial de los acontecimientos temporales. A diferencia del un acontecimiento temporal
normal, no se asocia con el paso regular del tiempo, por lo que el sistema no puede
anticiparlo utilizando un reloj interno. Y, a diferencia de un acontecimiento de flujo
normal, el de control no indica su presencia con la llegada de datos. Se asocia con un flujo
de control (o flujo binario). Son bastantes comunes en sistemas de tiempo real.
Al final de este estudio y, para la posterior obtención del modelo de funciones, se debe tener una
idea clara de:
 Las principales entradas y salidas de información y su procedencia, eliminando toda
referencia al entorno físico.
 Identificación de las principales funciones ejecutadas por el sistema.
 Realizar el modelo de funciones para cada subsistema, identificando las subfunciones que
realizan.
El modelo obtenido es una descripción lógica o conceptual del sistema, sin distinguir entre
funciones que se realizarán de forma manual o automatizada.
CONSTRUCCIÓN DE LA LISTA DE ACONTECIMIENTOS

La lista de eventos es un listado textual sencillo de los acontecimientos del ambiente a los cuales
debe responder el sistema. Al crear la lista de acontecimientos, se debe asegurar de distinguir
entre un acontecimiento y de describirlos desde el punto de vista de fuera del sistema, es decir, de
fuera hacia adentro.
En la mayor parte de los casos, la mejor manera de identificar los acontecimientos para un sistema
es visualizarlo en acción: examinar cada agente externo y preguntar qué efecto pueden tener sus
acciones sobre el sistema.
EJEMPLO
EVENTO PROCESO ENTRADA T SALIDA T
El cliente cancela una Datos cuenta.
Actualizar estado de la cuenta E Datos cuenta E
cuenta Nº Cliente
El cliente realiza una Datos cuenta.
Actualizar saldo de la cuenta E Datos cuenta E
retirada de efectivo Nº Cliente
A las 9:00 de la mañana se
Generar listado de cuentas Datos cuenta. Datos cuenta.
requiere un listado de I I
canceladas Datos cliente Datos cliente
cuentas canceladas
EVENTO: Se indica el evento que se produce.
PROCESO: Se indica el proceso que se va a desencadenar en el sistema al llegar ese evento.
ENTRADA: Se indica los datos que van a llegar al proceso.
SALIDA: Se indica los datos que van a salir del proceso como contestación del sistema al evento.
TIPO: Si es de tipo Externo (E) o de tipo interno (I)
Actividad 4: Analizar los problemas y oportunidades: Los analistas deberán trabajar con los
propietarios y usuarios para analizar los hechos relevantes, los problemas y las oportunidades,
utilizando como base los modelos del sistema actual. En esta actividad se identifican realmente los
problemas, la situación que se desemboco en el problema, cuales son los efectos negativos del
problema o de no aprovechar las oportunidades.
La estructura PIECES se ha convertido en la herramienta más útil para el análisis de causas y
efectos.
Actividad 5: Establecer los objetivos del nuevo sistema: El existo de un proyecto debería medirse
en términos del cumplimiento de objetivos alcanzados por el nuevo sistema.
Los objetivos deberían ser enunciados precisos y mensurables del rendimiento de la “empresa”
para definir las expectativas depositadas en un nuevo sistema.
Los objetivos deben ser moderados por las restricciones conocidas:
 calendario.
 Coste.
 Tecnología.
 Normas.
Problemas/Oportunidades Causas/Efectos Obj. Del Nuevo Sist. Restricciones

Causa: La registración
Utilizar un nuevo
La carga de datos de los manual de los datos.
método de
Clientes y proveedores es Efecto: se requiere gran Calendario
almacenamiento de
ineficiente. cantidad de horas del
datos.
personal.
Causa: los datos están
almacenados en
diversos formularios,
El acceso de información Desarrollar una nueva
planillas y fichas.
tanto de clientes como forma de acceder a los Tecnología
Efecto: obtención de
proveedores es dificultoso datos almacenados
datos con gran lentitud,
y redundancia de los
mismos.
……………………. …………………………….. ……………………… ………………………
Actividad 6: Modificar el ámbito y el plan de proyecto: El ámbito de un proyecto es un objetivo

móvil. Una vez llegado al final de la fase de estudio deberíamos reevaluar el ámbito y revisar el
plan de proyecto de forma consecuente.
Aplicables a esta actividad son las siguientes técnicas y conocimientos:
 Gestión de expectativas crecientes del usuario.
 Gestión de proyectos.
Actividad 7: Revisar las conclusiones y las recomendaciones: consiste en revisar las conclusiones
y las recomendaciones en dos posibles niveles:
 Una revisión de calidad que asegure que la fase a sido completada en conformidad con la
metodología y que la documentación es completa, consistente y acorde a las normas.
 Una revisión de viabilidad que reevalúe la viabilidad que continúe con el proyecto.
El desarrollo conjunto de las aplicaciones es un trabajo en equipo muy estructurado que lleva a
todos los participantes a trabajar conjuntamente para analizar, diseñar y/o definir prototipos de
sistemas de información.
Guía de actividades para el TP Final:

 Entrevistas, cuestionarios, observaciones etc. Inv. de Hechos.
 Declaración de propósito.
 Diagrama de contexto redefinido.
 Lista de acontecimientos.
 Modelo preliminar.
 Figura 0.
 Nivelación descendente.
 Diccionario de Datos.
 Matriz de Problemas/Oportunidades.
 Modificación de plan de proyecto.
 Conclusiones y recomendaciones.
Ejemplo de la Declaración de propósitos:

El propósito del Sistema XXXXX (Nombre del sistema) es optimizar y administrar de manera
adecuada XXXXX,XXXXX,XXXX… (los archivos, clientes, proveedores aquí van los ítems que uds.
Desean optimizar).
Ejemplo de Conclusión y Recomendación: Esto va en todas las fases.

Conclusión de la fase de inspección
Finalizada la misma y encontrando a grandes rasgos deficiencias y oportunidades no utilizadas en
el funcionamiento del sistema actual se recomiendo continuar con la fase siguiente, Fase de
Estudio.

Clase Nº 10
Etapa de Análisis - Fase de Estudio
Metodología Moderna STRADIS
Repaso: Edward Yourdon
Modelo Esencial
1. Modelo ambiental:
 Declaración de Propósitos: (Ver ejemplo en clase IX): La declaración de Propósitos puede
constar de una, dos o varias frases. Sin embargo, jamás debe llegar a más de un párrafo,
ya que la intención no es proporcionar una descripción completa y detallada del sistema.
Tal esfuerzo iría en contra del objetivo: el propósito del Modelo ambiental y del modelo de
comportamiento es dar todos los detalles.
 Diagrama de Contexto.(Ver apuntes clase V)
 Lista de acontecimientos.(Ver apuntes clase V y IX)
2. Modelo de Comportamiento: modela el comportamiento del Sist. Lo que tiene que hacer el
sistema para cumplir con la declaración de los propósitos
 Modelo Preliminar: Parte de la lista de acontecimientos, consiste en dibujar una burbuja
por cada acontecimiento
El nombre de la burbuja es lo que hace el sistema para responder a ese acontecimiento.
Cada una de las burbujas siempre esta relacionada a otra por medio de un almacén.
 Figura Cero:
 Agrupar los procesos relacionados
 Esconder almacenes
 Regla de Miller 7+- 2 (que la figura cero no tenga mas de 9 burbujas)
 Nivelación descendente: La figura cero es un único DFD que representa todo lo que
estuve modelando.
Para la explosión de una burbuja se toma cada una de las burbujas de la figura cero y por
cada una se describe en detalle cada proceso.
 Diccionario de Datos: Es un listado organizado de todos los datos pertinentes al sistema,
con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un
entendimiento común de todas las entradas, salidas, componentes de almacenes y
cálculos intermedios. (Ver Clase V).
Clase Nº 11
Unidad VII: Etapa de Análisis: Fase de Definición:
Fase de definición: Esta fase es vital para el éxito de un nuevo sistema de información.
Objetivos:
 Definir las necesidades de la empresa referidas a los problemas identificados en el sistema
actual.
 Definir las necesidades de la empresa que aprovechan las oportunidades identificadas en el
sistema actual.
 Definir las necesidades de empresa que cumplen las normas.
 Ofrecer a los grupos de desarrollo de sistemas una flexibilidad absoluta en lo que se refiere a
las futuras elecciones de diseño.
Actividades a desarrollar:
Actividad 1: Identificar las necesidades: El propósito de esta actividad es solicitar los requisitos
para una nueva aplicación. Las necesidades deberían basarse en los objetivos del sistema que se
identificaron en la fase de estudio.
Se utilizan diversas técnicas de investigación para solicitar la definición de las necesidades:
 Elaboración de entrevistas.
 Reuniones y discusiones en grupo.
 Encuestas.
 Investigaciones.
 Brainwriting y Brainstoring.
Actividad 2: Modelar las necesidades de sistemas: Se propone expresar las necesidades en forma
de modelos de sistemas. Mediante el modelo en pirámide se puede identificar las necesidades en
cuatro modelos:
 Personas: Organigramas.
 Datos: Diagramas de modelos de datos.
 Actividades: Diagramas de flujos de datos.
 Redes: Diagramas de conectividad.
Las entradas utilizadas para desarrollar los modelos de sistemas propuestos son las necesidades
de usuarios y de la empresa identificadas en la actividad anterior junto con los detalles del sistema
actual.
Actividad 3: Elaborar prototipos de descubrimiento (si fuera necesario): Una vez determinadas
las necesidades y su validación se procede a elaborar los prototipo de descubrimiento.
Los prototipos de descubrimiento son sencillas maquetas de pantallas y de informas cuyo fin es
ayudar a los analistas a “descubrir” las necesidades.
Gracias a estos prototipo los usuarios se hacen participantes mas activos en le desarrollo del
sistema.
Actividad 4: Definir prioridades entre las necesidades de empresa: Una vez dadas las
necesidades, modelos y prototipos del sistema propuesto que fueron definidas, el propietario y el
analista deberán evaluar las necesidades de la empresa conforme a los siguiente criterios:
 Es ineludible la necesidad de la empresa. No es necesario etiquetar como obligatorios a todos
los requisitos.
 La necesidad de la empresa es deseable pero no esencial.
 La necesidad de la empresa es opcional.

Actividad 5: Modificar el ámbito y plan de proyecto: Al acercarnos al final de la etapa, es
necesario reevaluar el ámbito y plan del proyecto. El analista y el propietario usarán el plan de
proyecto y estimaciones de tamaño que se revisaron por última vez durante la fase de estudio, así
como las necesidades, prioridades y modelos de sistemas propuestos den la fase de definición. El
resultado de esta actividad es nuevo plan de proyecto y estimaciones de tamaño modificadas.
Actividad 6: Al igual que las fases anteriores es necesario revisar las especificaciones de las
necesidades:
 Una revisión de calidad que asegure que la fase ha sido completada en conformidad con la
metodología y que la documentación es completa, consistente y acorde a las normas.
 Una revisión de viabilidad que reevalúe la viabilidad que continúe con el proyecto.
Según el resultado de las anteriores revisiones, deberán tomarse una de las siguientes decisiones:
 Autorizar que el proyecto prosiga, tal como esta, con las fases de diseño del sistema.
 Ajustar el ámbito, el coste y/o calendario del proyecto y después continuar con las fases de
diseño del sistema.
 Cancelar el proyecto debido a la falta de recursos para seguir desarrollando el sistema.
Guía para el Trabajo Práctico final, Etapa de Análisis, Fase de Definición:

 Carátula de la Fase: Fase de Definición.
 Planificación de la Fase.
 Declaración de Propósitos.
 Lista de Necesidades
 Diagrama de Contexto.
 Lista de Acontecimientos.
 Modelo preliminar.
 Figura cero.
 Nivelación descendente. (Explosiones)
 Diccionario de Datos. (DD)
 Especificación Lógica de Procesos.(ELP)
 Diagrama de Conexión de Puestos.(DCP)
 Diagrama Entidad – Relación.(DER)
 Matriz de Prioridades.
 Planificación General.
 Conclusiones y Recomendaciones.
Clase XII
Unidad VII: Etapa de Análisis: Fase de Definición:
La fase de definición permite modelar el sistema nuevo. Las características del sistema nuevo,
¿qué características va a tener el sistema nuevo?
Define las necesidades del sistema nuevo.
Las necesidades se clasifican en: Obligatorias, deseables y opcionales.
Modela en sistema nuevo en función a esas características/necesidades.
Lista de Necesidades
En base a las fases anteriores se crea una lista de las necesidades, las cuales deben ser cubiertas
en el sistema actual, también dependen de su clasificación.
Ejemplo de una lista de necesidades:
 Contemplar una base de datos que permita el almacenamiento de los datos
correspondientes a :
o Clientes.
o Cuentas del cliente
o Proveedores
o Mercaderías
o Ventas
 Que contenga una aplicación que permita, tanto la carga y la actualización de la base de
datos.
 Que permita generar automáticamente documentos como por ejemplo:

o Resumen de ventas.
o Listados de Clientes morosos
o Listado de mercaderías faltantes.
 Consentir la generación automática de Resumen de ventas mensuales y anuales.
Especificación Lógica de Proceso (ELP). “Análisis estructurado Moderno” Edward Yourdon,

páginas: 77-78, 227-259.
La especificación Lógica de proceso es la descripción de qué es lo que sucede en cada burbuja
primitiva de nivel más bajo de un DFD. Define que debe hacerse para transformar entradas en
salidas. Es una descripción detallada de la política de negocios del usuario que cada burbuja lleva a
cabo.
Se puede usar cualquier método mientras satisfaga dos requerimientos cruciales.
 La ELP debe expresarse de una manera que puedan verificar tanto el usuario como el
analista.
 El proceso debe especificarse en una forma que pueda ser comunicada efectivamente al
público amplio que esté involucrado.
Existen tres Herramientas principales:

 Lenguaje estructurado (español, inglés, etc.).
 Pre/Post condiciones.
 Tablas de decisión.
Lenguaje estructurado
El lenguaje estructurado, como su nombre lo indica, es “Lenguaje español (o inglés u otro) con
estructura. Es decir, es un subconjunto de todo el idioma con importantes restricciones sobre el
tipo de frases a que pueden utilizarse y la manera en que dichas frases pueden juntarse. También
se conoce con el nombre de “pseudocódigo”.
Los verbos deben escogerse de entre un pequeño grupo de verbos orientados a la acción tales
como:
 CONSEGUIR (o ACEPTAR o LEER)
 PONER (o MOSTRAR o ESCRIBIR)
 ENCONTRAR (o BUSCAR o LOCALIZAR)
 SUMAR
 RESTAR
 MULTIPLICAR
 DIVIDIR
 CALCULAR
 BORRAR
 VALIDAR
 MOVER
 REEMPLAZAR
 FIJAR
 ORDENAR
Los objetos deben consistir sólo en datos que se han definido en el diccionario de datos o ser
términos locales (variables locales). Los términos locales se definen explícitamente en una
especificación Lógica de proceso individual; sólo son conocidos y relevantes dentro de dicha
especificación.
Ejemplo:
Total = 0;
HACER MIENTRAS haya más pedidos en PEDIDOS con fecha-pedido = fecha de hoy
LEER el siguiente PEDIDO en PEDIDOS con fecha-pedido = fecha de hoy;
MOSTRAR a contabilidad numero-pedido, nombre-cliente y cantidad-total;
Total = cantidad-total + Total;
FIN HACER
MOSTRAR a contabilidad el Total;
Finalmente el lenguaje estructurado permite que se combinen frases en unas cuantas formas
limitadas que se toman de las construcciones acostumbradas a la programación estructurada.
SI-ENTONCES-OTRO
SI condición-1
Frase-1
FIN SI
SI condición-1
Frase-1
OTRO
Frase-2
FIN SI
HACER CASO
CASO variable = valor-1
Frase-1
…
…
CASO variable = valor-n
Frase-n
OTRO CASO
Frase-n+1
FIN CASO
HACER MIENTRAS condición-1

Frase-1
FIN HACER
Pre/ Post Condiciones
Las Pre/Post condiciones son una manera conveniente de describir la función que debe realizar el
proceso, sin decir mucho acerca del algoritmo o procedimiento que se utilizará, resulta ser un
enfoque particularmente útil cuando:
 El usuario tiene tendencia a expresar la política llevada a cabo por la burbuja en términos
de un algoritmo particular que ha estado utilizando durante décadas.
 El analista está razonablemente seguro de que existen muchos algoritmos distintos que
podrían usarse.
 El analista desea que el programador explore varios de estos algoritmos pero no quiere
involucrarse personalmente en tales detalles y, sobre todo, no quiere enredarse en
discusiones con el usuario acerca del mérito relativo de cada uno.
Ejemplo:
ELP 3.1: CALCULAR EL IMPUESTO SOBRE VENTAS.
Precondición 1
Ocurre DATOS-VENTA con TIPO-ITEM que corresponde con CATEGORIA-ITEM en
CATEGORIAS-IMPUESTO
Postcondición 1
IMPUESTO-VENTA se hace igual a MONTO-VENTA * IMPUESTO
Precondición 2
Ocurre DATOS-VENTA con TIPO-ITEM que NO concuerda con CATEGORIA-ITEM en
CATEGORIAS-IMPUESTO
Postcondición 2
Se genera un mensaje de error.
Las precondiciones describen todas las cosas (si hay) que deben darse antes de que el proceso
pueda comenzar a ejecutarse.
Las postcondiciones describen lo que debe darse cuando el proceso ha concluido.
Tablas de decisión
Existen situaciones donde ni el lenguaje estructurado ni las pre/post condiciones son adecuadas
para escribir especificaciones lógicas de proceso. Esto se da sobre todo si el proceso debe
producir alguna salida o tomar alguna acción basada en decisiones complejas. Si las decisiones se
basan en diversas variables distintas (por ejemplo, datos de entrada), si dichas variables pueden
tomar diversos valores, entonces la lógica expresada por el lenguaje estructurado o por las
pre/post condiciones probablemente sean tan complejas que el usuario no la comprenderá.
Una tabla de decisiones se crea listando todas las variables relevantes (a veces conocidas como
condiciones o entradas) y todas las acciones relevantes en su lado izquierdo. En este ejemplo las
variables son lógicas, lo cual significa que pueden tomar el valor de verdadero o falso.
En muchas aplicaciones es fácil (y preferible) expresar las variables como binarias (verdadero -
falso), pero también se pueden construir las tablas de decisiones a partir de variables
multivaluadas.
A continuación se lista en columnas separadas cada combinación posible de valores de las
variables; cada columna usualmente se conoce como regla. Una regla describe una acción (o
acciones) que deben llevarse a cabo para una combinación específica de valores de las variables.
Por lo menos se debe especificar una acción para cada regla (esto es para cada columna de la
tabla), o el comportamiento del sistema para tal situación no quedará especificado.
1 2 3 4 5 6 7 8
Edad mayor a 21 años V V V V F F F F

Sexo F F M M F F M M
Peso mayor a 100Kgs Y N Y N Y N Y N
Medicamento 1 X X
Medicamento 2 X X
Medicamento 3 X X
Ningún medicamento X X
Si existen N variables con valores binarios (verdadero - falso), entonces existirán 2N reglas
distintas; así que si existen tres condiciones, habrá 8 reglas, y si hay 7 condiciones habrá 128
reglas.
Debe discutirse cada regla con el usuario para asegurarse que se ha identificado la acción o
acciones correctas para cada combinación de variables.
Matriz de Prioridades
Se deben clasificar las necesidades en base a su prioridad, es decir, debemos reunirnos con el
usuario y clasificar junto con el mismo, todas aquellas necesidades que hemos expuesto en la Lista
de necesidades.
Necesidades Prioridad
 Contemplar una base de datos que permita el
almacenamiento de los datos correspondientes a :
o Clientes.
o Cuentas del cliente OBLIGATORIA
o Proveedores
o Mercaderías
o Ventas
 Que contenga una aplicación que permita, tanto la
OBLIGATORIA
carga y la actualización de la base de datos.
 Que permita generar automáticamente documentos
como por ejemplo:
o Resumen de ventas. OBLIGATORIA
o Listados de Clientes morosos
o Listado de mercaderías faltantes.
 Consentir la generación automática de Resumen de
DESEABLE
ventas mensuales y anuales.

Clase Nº 13
Metodología Moderna/ STRADIS: ETAPA DE DISEÑO
Diseño de sistemas: se basa en los conocimientos adquiridos en las etapas de planificación y

análisis de sistemas. El diseño de sistemas es el proceso por el cual las necesidades de los usuarios
finales se transforman en un paquete de software y/o una especificación de un sistema de
información basado en ordenadores.
El diseño de sistemas consta de tres fases:
1. Fase de Selección.
2. Fase de Adquisición.
3. Fase de Diseño e Integración.
Fase de Selección:
El propósito de la fase de selección es identificar soluciones alternativas, tanto manuales, como de
tipo informático. Es durante esta fase que se toma una decisión sobre si el sistema debe hacerse o
comprarse. Se analiza la viabilidad de cada una de las soluciones alternativas. En concreto se
analiza la viabilidad operativa, técnica, económica y de calendario de cada una de las soluciones
candidatas. Normalmente se recomienda la solución que ofrezca la mejor combinación global de
estas clases de viabilidad.
Las actividades son:
Actividad 1: Especificar soluciones alternativas: Se inicia a partir de la aprobación para proseguir

con el proyecto obtenida de la fase de definición. Una vez dadas las necesidades de empresa
establecidas en la fase de definición, debemos identificar las soluciones candidatas alternativas, la
cantidad de información que describe las características de cada una de las soluciones candidatas
puede ser muy abundante. Una herramienta útil para la localización, organización y comunicación
de las características de las soluciones es una matriz que permite comparar las características de
las soluciones.
Actividad 2: Analizar la viabilidad de las soluciones alternativas: Una vez identificadas las posibles
soluciones se debe analizar la viabilidad de cada una de ellas. Este análisis se debe realizar
basándose en cuatro criterios.
1. Viabilidad técnica: se analiza si es practica la solución de desde un punto de vista técnico.
2. Viabilidad operativa: se analiza si la solución satisface las necesidades de los usuarios.
3. Viabilidad económica: se analiza si resulta eficaz la solución en términos de costos.
4. Viabilidad de calendario: se analiza si la solución puede diseñarse o implementarse en un

periodo de tiempo aceptable.
El análisis de viabilidad se lleva acabo de forma individual para cada solución candidata, sin tener
en cuenta la viabilidad de otras posibles soluciones. Esta forma de actuar pretende evitar que el
analista y los usuarios adopten decisiones prematuras sobre cual de las candidatas es la mejor
solución.
Actividad 3: Recomendar una solución para el sistema: Una vez terminado el análisis de viabilidad
para cada solución candidata, puede seleccionarse cual de estas soluciones será la recomendada.
En primer lugar se eliminan las soluciones no viables, de las restantes se busca la que tenga mejor
combinación de todos los tipos de viabilidad. Se puede utilizar una Matriz de valores de muestra.
Clase Nº 14
Fase de Selección
Herramientas para esta fase:
1. Planificación de la fase.
2. Matriz de Soluciones Alternativas
3. Análisis de Viabilidad.
4. Matriz de Análisis de Viabilidad Cualitativa
5. Matriz de Análisis de Viabilidad. (Pesos ponderados)
6. Conclusiones y Recomendaciones de la fase.
7. Planificación General.
Ejemplo de la Matriz de Soluciones Alternativas

Solución 1 Solución 2 Solución 3
 Crear una BD que  Crear una BD que

permita el permita el
 Crear una BD que almacenamiento almacenamiento
permita el de datos de datos
almacenamiento correspondientes correspondientes
de datos a: Mercadería, a: Mercadería,
correspondientes Clientes, Clientes,
a: Mercadería, Proveedores, Proveedores,
Clientes, Ventas…. Ventas….
Proveedores,  Crear una  Crear una
Ventas…. aplicación que aplicación que
 Crear una permita la carga y permita la carga y
aplicación que la actualización de la actualización de
permita la carga y la base de datos. la base de datos.
Partes del Sistema la actualización de  Generar  Generar
que contempla la base de datos. automáticamente automáticamente
 Generar documentos como documentos como
automáticamente ser: planilla de ser: planilla de
documentos como ventas, planilla de ventas, planilla de
ser: planilla de proveedores, proveedores,
ventas, planilla de clientes… clientes…
proveedores,  Acelerar el flujo de  Acelerar el flujo de
clientes… información entre información entre
 Acelerar el flujo de los puestos de los puestos de
información entre trabajo. Utilizando trabajo. Utilizando
los puestos de una red informática una red informática
trabajo. Utilizando  Automatizar la  Automatizar la
una red informática confección de confección de
Facturas de ventas. Facturas de ventas.
 Motor de Base de  Motor de Base de  Motor de Base de

Hardware y Software Datos MySql. Datos MySql. Datos SQL Server
Necesarios  Impresora chorro a  Impresora chorro a  Impresora Laser
(Tecnología) tinta. tinta. Jet.
 S.O Linux Ubuntu  S.O Win XP  S.O Win Vista HP
Tiempo de Desarrollo 4 Meses 5 Meses 6 Meses
Costo de desarrollo $ 4000 $ 5000 $ 6000
Costo de
$ 5000 $ 6500 $ 8000
Implementación
Ejemplo de Análisis de Viabilidad:

CRITERIOS DE ANALISIS
Viabilidad Técnica:
 Productividad: Se evalúa el aumento de productividad de la empresa causado por el
Sistema.
 Tiempo de respuesta: Se evalúa la rapidez del Sistema.
 Necesidad de mantenimiento: Se evalúa si el Sistema necesita mantenimiento o no.
Viabilidad Operativa
 Facilidad de adaptación del Usuario: qué tan fácil será para los usuarios adaptarse al
nuevo Sistema.
 Facilidad de uso: qué tan fácil será manejar el nuevo Sistema.
 Capacitación necesaria: Se evalúa el nivel necesario de capacitación para manejar el
Sistema.
Viabilidad Temporal
 Tiempo necesario para actualizar: el tiempo que durará el Sistema antes de necesitar una
actualización.
 Tiempo necesario para la capacitación: el tiempo necesario para capacitar a los usuarios
del Sistema.
Viabilidad Económica
 Costo de mantenimiento: Se evalúa el costo del mantenimiento necesario en el Sistema.
 Costo de capacitación: Se evalúa el costo de la capacitación necesaria para manejar el
Sistema.
Clase Nº 15
Fase de Selección
Herramientas para esta fase:
8. Planificación de la fase.
9. Matriz de Soluciones Alternativas
10. Análisis de Viabilidad.
11. Matriz de Análisis de Viabilidad Cualitativa
12. Matriz de Análisis de Viabilidad. (Pesos ponderados)
13. Conclusiones y Recomendaciones de la fase.
14. Planificación General.
Ejemplo de la Matriz de Análisis de Viabilidad Cualitativa

Criterio Solución 1 Solución 2 Solución 3

Viabilidad Técnica
Productividad X X X
Tiempo de Respuesta X X X
Necesidad de Mantenimiento X X X
Viabilidad Operativa
Facilidad de adaptación Usuario X X X
Facilidad de Uso X X X
Capacitación Necesaria X X X
Viabilidad Temporal
Tiempo Nec. Para Actualizar X X X
Tiempo Nec. Para capacitación X X X
Viabilidad Económica
Costo de Mantenimiento X X X
Costo de Capacitación X X X
Ejemplo de la Matriz de Análisis de Viabilidad Cuantitativa

Puntuaciones
1. Regular
2. Bueno
3. Muy Bueno
Criterio Solucion1 Solución 2 Solución 3
PP Puntaje Valor Puntaje Valor Puntaje Valor
Viabilidad Técnica 12 18 27
Productividad 4 1 4 2 8 3 12
Tiempo de Respuesta 3 2 6 2 6 3 9
Necesidad de Mantenimiento 2 1 2 2 4 3 6
Viabilidad Operativa 11 18 23
Facilidad de adaptación Usuario 3 1 3 2 6 3 9
Facilidad de Uso 2 2 4 2 4 3 6
Capacitación Necesaria 4 1 4 2 8 2 8
Viabilidad Temporal 14 20 24
Tiempo Nec. Para Actualizar 4 2 8 2 8 3 12
Tiempo Nec. Para capacitación 6 1 6 2 12 2 12
Viabilidad Económica 20 20 26
Costo de Mantenimiento 6 2 12 2 12 3 18
Costo de Capacitación 4 2 8 2 8 2 8
Puntaje Total 57 76 100
Clase Nº 16
Fase de adquisición
La adquisición de software y hardware (equipo informático) no es necesaria en todos los nuevos
sistemas. Por otra parte, cuando se precisa un nuevo software o hardware, la selección de los
productos apropiados entraña con frecuencia una cierta dificultad. Las decisiones se complican
por consideraciones técnicas, económicas y políticas. Una decisión deficiente puede arruinar
cualquier tarea de análisis y diseño que, en otro caso, habría logrado sus objetivos. El analista de
sistemas esta cada vez mas involucrado en la tarea de adquisición de paquetes de software,
periféricos y ordenadores sobre los que se apoyan las aplicaciones especificas que están siendo
desarrolladas por dicho analista.
Bloques elementales en la fase de adquisición:

1) Identificar e investigar los productos específicos susceptibles de servir de soporte a la

solución recomendada para el sistema de información objeto.
2) Solicitar, evaluar y clasificar las propuestas de los posibles proveedores.
3) Seleccionar y recomendar la mejor de estas propuestas.
4) Establecer los requisitos de integración de los productos de los proveedores elegidos.
La fase de adquisición es opcional, esto es, se activa a través de una aprobación de diseño que
plantea la necesidad de disponer de nuevo hardware o software.
Actividad 1: Investigar las opciones y los criterios técnicos: Esta Actividad responde a las
necesidades de hardware y/o software establecida en la fase de selección. Tales necesidades
detallan las funciones, las características y los parámetros críticos de operación.
Los analistas deben obtener datos de los productos y los vendedores de varias fuentes, no deben
obtener información de un único comercio, no porque este no vaya a ser sincero sino porque la
regla numero uno de los vendedores es insistir en las ventajas de su producto y omitir sus puntos
débiles.
Algunas fuentes de información útil son las siguientes:
* Las normas internas que pueden existir sobre la selección de hardware y software. Algunas
empresas insisten en comparar determinadas tecnologías a vendedores específicos.
* Los servicios de información cuyo objetivo primordial es inspeccionar permanentemente la
aparición en el mercado de nuevos productos y aconsejar a los posibles compradores sobre las
especificaciones que han de tener en cuenta.
* Los periódicos y publicaciones de venta al público que ofrecen artículos y relatos de experiencias
sobre los diversos tipos de hardware y software que el analista puede estar examinando.
Actividad 2: Solicitar propuestas (o presupuestos) a los vendedores: Una vez obtenidos los
vendedores potenciales, opciones y criterios técnicos la siguiente tarea es solicitar propuestas a
tales vendedores. Si la empresa adquirió el compromiso de realizar sus compras en una sola
fuente la tarea resultará bastante rutinaria. Pero la mayor parte de las decisiones se basan en
muchas alternativas posibles. En esta situación el sentido de empresa aconseja aprovechares de la
competencia del mercado para obtener las mejores condiciones. La tarea de solicitud requiere la
preparación de uno de los dos documentos siguientes:
La solicitud de presupuestos: se utiliza cuando ya se ha decidido acerca de un producto específico,
pero dicho producto puede adquirirse en varios distribuidores. Su objetivo primordial es solicitar
configuraciones específicas, precios, acuerdos de mantenimiento.
La solicitud de propuestas: se utiliza cuando existen varios vendedores y/o productos, diferentes
candidatos y se desea solicitar de ellos tanto propuestas técnicas como presupuestos. Las
solicitudes de propuestas pueden verse como superconjuntos de solicitudes de presupuestos. La
calidad de una solicitud de propuestas tiene un impacto importante sobre la calidad y la amplitud
de las propuestas resultantes.
El propósito primordial de la solicitud de propuesta es comunicar a los vendedores los requisitos y

las características buscadas. Estos se clasifican en: obligatorios (que deben ser suministrados por
el vendedor), extremadamente importantes (solicitados del vendedor, pero que pueden
obtenerse dentro de la empresa o de otros colaboradores) o deseables (sin los cuales se puede
trabajar). Los requisitos deben clasificarse también según dos criterios alternativos: los que
satisfacen las necesidades de los sistemas y los que satisfacen las necesidades de la empresa con
respecto al vendedor.
Actividad 3: Validar las declaraciones y las prestaciones manifestadas por los vendedores:
Inmediatamente después de enviar las solicitudes de propuestas y presupuestos a los posibles
vendedores, deben empezarse a recibir propuesta(s) y/o presupuesto(s). Como las propuestas no
pueden y no deben tomarse al pie de la letra, ha de hacerse una labor de validación de las
afirmaciones y las prestaciones declaradas. Esta tarea se realiza de forma independiente para cada
propuesta; no se deben comparar unas propuestas con otras.
Elimínense las propuestas que no reúnan todos los requisitos considerados obligatorios.
Si se hubieran especificado los requisitos con claridad, los vendedores no habrían remitido tales
propuestas. Para aquellas propuestas que no satisfagan uno o más de los requisitos considerados
extremadamente importantes, verifíquese que es posible cubrir dichos requisitos o características
por otros medios. Finalmente, valídense las declaraciones y las promesas declaradas por los
vendedores mediante criterios de validación.
Actividad 4: Evaluar y clasificar las propuestas de los vendedores: La tarea de evaluación y

clasificación es, en realidad un análisis de costes y beneficios realizados durante el desarrollo de
sistema. Antes que tenga la valuación real, deberían establecerse los criterios de valuación y el
sistema de baremo.
Algunos métodos proponen la atribución de un peso a cada requisito basándose en una escala de
puntos. Los mejores de estos métodos utilizan unidades monetarias. Los sistemas monetarios son
más fáciles de defender ante los directivos que los sistemas de puntos.
Actividad 5: Hacer el contrato he informar a los vendedores no seleccionados: Tras tomar la

decisión final de aprobación de hardware y software, debe negociarse un contrato con el
vendedor que resulta ganador. Es posible que haya que escribir algunas condiciones y términos
especiales en el contrato y pedido estándar. En términos ideales, no debería firmarse ningún
contrato informático sin el asesoramiento de un abogado.
Por cortesía, y para mantener las buenas relaciones, el analista debería suministrar una
información valorada de las propuestas a los vendedores que no resulten seleccionados. El
objetivo de esta reunión no es dar a los vendedores una segunda oportunidad de conseguir el
contrato; más bien está encaminada estrictamente a informar a los vendedores que resultaron
perdedores de los puntos débiles concretos que se encontraron en su propuesta y/o producto(s).
Actividad 6: Establecer los requisitos de integración: Finalmente, dadas las especificaciones de

hardware y software de los productos del vendedor seleccionado, los analistas deben determinar
el modo de integración de los mismos con otros sistemas de información existentes. No se trata
sólo de comprar o construir sistemas que reúnan los requisitos del sistema objeto. El analista debe
integrar o interconectar el nuevo sistema con la multitud de los restantes sistemas existentes que
son esenciales para la empresa. Muchos de estos sistemas pueden usar tecnologías, técnicas y
estructuras de archivos radicalmente diferentes.
El analista debe considerar en qué grado se ajusta el sistema objeto al conjunto de sistemas del
que forma parte. Las necesidades de integración que se especifican son de vital importancia para
asegurar que el sistema objeto funcione armónicamente con dichos sistemas.

Clase Nº 17
Fase de diseño e integración

Es la fase más detallada del desarrollo de sistemas. El propósito de esta fase es generar las
especificaciones detalladas para los elementos informáticos del nuevo sistema de información (o
para la modificación y mejora de un paquete de software). Estas especificaciones de diseño se
transmitirán a los programadores informáticos para su implantación. Obviamente el grado en que
los programadores informáticos sean capaces de construir el sistema sin mayor asistencia,
depende de lo claras y completas que sean las especificaciones de diseño. Aunque el objetivo
último del diseño de sistemas es comunicar las especificaciones a los programadores, para su
implantación, no debe olvidarse de la importancia de la participación de los usuarios finales.
Las actividades 1,2 y 3 forman parte del diseño general, y las actividades 4, 5, 6 y 7 forman parte
del diseño detallado.

Diseño General
Actividad 1: Analizar y distribuir los datos: Durante esta actividad, el analista trabajará en
estrecho contacto con los usuarios para desarrollar un buen modelo de datos, es decir, un modelo
de datos que permita el desarrollo de soluciones de archivos y bases de datos ideales. El análisis
de datos es la técnica utilizada para obtener un buen modelo de datos.
El análisis de datos es un procedimiento que prepara un modelo de datos para su implantación
como un archivo/base de datos flexible, adaptable y exento de redundancias.
La normalización es el procedimiento que se utiliza para simplificar las entidades, eliminar las
redundancias y dotar a los modelos de datos de flexibilidad y capacidad de adaptación.
La normalización de datos se refiere al modo de agrupación de los atributos de datos en forma de
entidades estables, flexibles y adaptables.
Una vez terminado el análisis de datos, se llevará acabo un análisis de sucesos para orientar la
acción del analista a asegurar que los datos de los usuarios finales se conserven con precisión y
bien actualizados.
El análisis de sucesos en una técnica que estudia las entidades en un modelo de datos totalmente
normalizado con el fin de identificar los sucesos y las condiciones de empresa que originan la
creación, el borrado o la modificación de los datos.
Como es probable que el análisis de datos y de sucesos tenga un impacto sobre los modelos de
procesos del sistema objeto, puede hacerse necesario revisar los diagramas de flujo de datos
(DFD) de dichos sistema objeto. Los productos finales obtenidos de esta primera actividad son los
modelos de datos distribuidos normalizados y modelos de procesos revisados.
Actividad 2: Analizar y distribuir los procesos: Podemos ahora desplazar nuestro foco de atención
desde los datos a los procesos. Los modelos revisados de datos y procesos pueden utilizarse en
este punto para abordar las cuestiones de distribución de los datos del sistema objeto.
Dado el conjunto diagrama de modelo de datos, solución objeto y modelos de procesos, el analista
pasará al desarrollo de modelos de procesos distribuidos. Para llevar a cabo esta actividad, el
analista puede requerir la participación de diversos diseñadores y usuarios de sistemas.
Actividad 3: Dividir en unidades de diseño: Consiste en dividir el sistema objeto en unidades de

diseño independientes. Mediante el uso de los modelos de datos y de procesos, el analista y los
diseñadores del sistema determinarán el mejor modo en que puede dividirse el sistema objeto en
fragmentos más pequeños a través de los cuales sea posible completar con facilidad los detalles
del diseño. Las unidades de diseño resultantes actuarán a modo de un esquema que servirá de
guía para desarrollar las actividades propias del diseño detallado.
Diseño Detallado
Actividad 4: diseñar bases de datos y/o archivos informáticos: Dadas las unidades de diseño de
archivos y bases de datos obtenidas del diseño general, los diseñadores de sistemas deben
desarrollar las correspondientes especificaciones de diseño de archivos y bases de datos. El diseño
de datos es algo mas que una simple disposición de registros. Los archivos / bases de datos son
recursos compartidos. Muchos programas harán uso de ellos. Los programas futuros pueden
utilizar los archivos y las bases de datos en formas originalmente no previstas. Por consiguiente, el
diseñador debe poner especial cuidado en diseñar archivos y bases de datos que puedan
adaptarse a futuros requisitos y posibles ampliaciones.
El diseñador también de analizar el modo en que accederán los programas a los datos, con el fin
de mejorar el rendimiento.
Finalmente como los archivos y las bases de datos son recursos compartidos, el diseñador también
debe diseñar controles internos que aseguren la disposición de técnicas de seguridad apropiadas y
recuperación ante posibles desastres que resuelvan las situaciones de perdida o la destrucción de
los datos.
Actividad 5: diseñar las entradas y salidas informáticas: Dadas las necesidades de diseño de
entradas y salidas para el sistema objeto, el diseñador de sistemas debe trabajar en estrecha
colaboración con los usuarios de sistema para desarrollar especificaciones de entrada y salida.
Como los usuarios finales y los directivos deberán trabajar con entradas y salidas, el diseñador
debe preocuparse por requerir sus ideas y sugerencias, en particular en lo que se refiere al
formato.
Por lo general las informaciones y otras salidas se imprimen directamente en papel o en las
pantallas de los terminales. En cualquier caso debe especificarse el formato preciso y la estructura
de las salidas. También es necesario que participen los directivos, dado que son ellos quienes
deben aprobar los gastos que asocian a esas salidas. Por último deben especificarse controles
internos para asegurar que las salidas no se pierdan, se traspapelen, se utilicen inadecuadamente
o resulten incompletas.
En lo que se refiere a las entradas, es de vital importancia diseñar el método de captura de datos
que se utilizará. Debe también diseñarse la estructura del registro de entrada tal como figurará en
el ordenador.
Cuando se introducen datos pueden cometerse errores. Es preciso definir controles de edición
para asegurar la precisión de los datos de entrada. Normalmente nos vemos obligados a definir
salidas adicionales para identificar los errores de entrada.
Actividad 6: diseñar interfaces interactivas de usuario: Esta actividad se omite en muchos

diseños. Sin embargo, para los sistemas on-line, el desarrollo de las especificaciones de diseño de
las interfaces (dialogo entre el usuario final y el ordenador) obtenidas de las necesidades de
diseño de interfaces puede convertirse en una de las actividades de diseño primordiales. Son
demasiados los sistemas on-line difíciles de aprender y utilizar por deficiencias en su ergonomía.
La idea que subyace en el diseño de interfaces de usuario es confeccionar interfaces fáciles de
aprender y utilizar en torno a las pantallas interactivas de entrada y salida que fueron diseñadas
en tareas anteriores. Este diálogo entre usuario y ordenador debe tener en cuenta factores como
la familiaridad con las terminales, los posibles errores y fallos de comprensión que puede padecer
el usuario, la necesidad de instrucciones adicionales o de ayuda en determinados puntos del
sistema y el contenido y la estructura de la pantallas. En esencia, se trata de intentar anticiparse a
cualquier pequeño error de concepto o de uso que pueda darse. Sin importar lo improbable que
parezca ser. Y lo que es más, se trata también de intentar hacer más fácil de comprensión por el
usuario final de lo que muestra la pantalla en un instante dado.
Actividad 7: presentar y revisar el diseño: Esta actividad final del diseño detallado contiene todas
las especificaciones obtenidas en las tareas anteriores en especificaciones de programas
informáticos que servirán de guía a las actividades de los programadores informáticos durante la
fase de construcción del ciclo de vida del desarrollo de sistemas.
Además del grupo de especificaciones, se necesita determinar la estructura global de los

programas.
Obtenidas las unidades de diseño final, es necesario preparar otros dos componentes:
1) Un plan de implantación que presente un calendario propuesto para las fases de construcción y
entrega.
2) Un análisis final de costes y beneficios que determine si el diseño sigue siendo viable.
El diseño de sistemas debería ser revisado por todos los participantes adecuados (usuarios del
sistema, propietarios del sistema, personal de soporte técnico y personal auditor).
El resultado de cualquier revisión, puede obligar a volver a algunas de las tareas previas ya
realizadas en la fase de diseño.

Clase Nº 18
Fase de diseño e integración:
Diseño General
Herramientas:
 DER (Diagrama Entidad – Relación).
 Tabla de Análisis de Sucesos.
 DFD Lógico: Unión de todas las explosiones (nivelación descendente) de las burbujas en su
nivel primitivo (último nivel de explosión).
 Definición de la Frontera de Automatización. Clasificación de Procesos BATCH y procesos
ON-LINE: Separar lo informatizado (UDI) de lo manual (UDM).
o Clasificar en las Unidades de Diseño Informatizado (UDI), los procesos ONLINE o
BATCH, el mismo está dado por el tiempo de respuesta y en las entidades externas
que utilizan el sistema.
o ONLINE: Llega la transacción, se procesa y se envía la respuesta. Dentro del
Umbral de Respuesta.
o BATCH: Llegan n transacciones, se procesan y luego se emite la respuesta. Mas allá
del Umbral de Respuesta.
o Definir el Umbral de Respuesta: Cuanto tiempo se tarda en emitir la respuesta. Por
ej. 50ms
o Identificar las salidas netas del Sistema. Flujos de datos del sistema hacia las
entidades externas.
 Salidas:
o IAP: Inmediatamente y a Petición.
o ASAP: Tan pronto como sea Posible (As soom as Posible).

o Clasificar la salida de los procesos como IAP o ASAP.
o Si el Proceso tiene salidas IAP todas las entradas tienen que ser IAP.
o Si el proceso tiene salidas ASAP todas las entradas tienen que ser ASAP.
o Si el proceso tiene salidas IAP y ASAP hay que dividir el proceso y vincularlos luego
con un almacén.
 Clasificar los Procesos:
o Procesos ONLINE – Salidas IAP.
o Procesos BATCH – Salidas ASAP.
 DFD de Implantación de Unidad de Diseño ON-LINE: En las Burbujas/Procesos se especifica
el lenguaje de programación o la herramienta en la que se van a programar dichos
procesos. Flujos Hacia almacenes: Se especifica el nombre de la consulta SQL. Almacenes:
Nombre de la tabla, Nombre del motor de BD.
 DFD de Implantación de Unidad de Diseño BATCH: Ídem Unidad de Diseño Online.
 Diagrama de Topología de Red: Diagrama de Topología de Red, especificando el tipo de
Cable (de utilizarlo), distancia del mismo, Host Conectados, tipos de máquinas, SO a
utilizar.
 Diseño de Base de Datos.
Diseño Detallado
Herramientas:
 Salidas Impresas.
 Diseño de Pantallas.
 Jerarquía de Pantallas. (Site Map)
 Especificación de Pantallas:
o Lógica de Botones.
 Consultas SQL.
Conclusión de la Fase de Diseño e Integración.
Tabla de Análisis de Sucesos (Ejemplo)
Nombre de la Descripción del Nombre del

ABML Condición
Entidad Suceso Suceso
Se quiere DNI del cliente Lectura Que se encuentre
obtener los datos cargados los
Clientes
de un Cliente datos de los
clientes
Proveedores Se Desea cargar Datos del Alta No deben estar
los datos de un proveedor cargados

proveedor previamente
Se desea Datos Modificación El proveedor
actualizar los actualizados debe estar
Proveedores
datos de un Proveedor cargado
proveedor previamente
Se desea Dato Proveedor Eliminación El proveedor
eliminar un debe estar
Proveedores
proveedor cargado
previamente.
Diseño de Base de Datos (Ejemplo)

Nombre de la Entidad Tipo Cantidad
Clientes
IDCliente Integer
DNI Carácter 15
Nombre Carácter 30
Dirección Carácter 30
Teléfono Carácter 10
Casado Boolean
Proveedores
IDProveedor Integer
CUIT - CUIL Integer
Nombre Carácter 15
Teléfono Carácter 10
Así con todas las Tablas de la Base de Datos.
Diseño Detallado
Especificación de Pantallas: Se muestra el Diseño de la misma, Botones, campos de Texto, Menús,
checkBox etc. Como así también un detalle de la misma. Ejemplo:
Nombre: Alta Cliente

Descripción: Registro de Nuevos Clientes en la Base de Datos.

Tipo: Entrada
Entorno de Datos: Clientes (Tabla de la BD).
En el caso de tener botones la Pantalla
Botón de Comando Procedimiento Asociado
Dar de Alta btnAltaCliente
Salir btnSalirAltaCliente
Lógica de Botones: (Ejemplo)

NOMBRE DE LA VENTANA: Alta Clientes
Nombre: btnAltaCliente
Descripción: Se utiliza para registrar un nuevo cliente en la Base de Datos.
Tipo: Procedimiento.
Argumentos: IDCliente –DNI – Nombre – Dirección – Teléfono – Casado
Entorno de Datos: Clientes
Lógica asociada:
Comenzar
Buscar el DNI del cliente en la tabla Clientes
Si Encontró
Mostrar mensaje de cliente existente.
Si No encontró
Crear un nuevo registro en la Base de Datos con los datos ingresados.
Fin Si
Teminar
Nombre: btnSalirAltaCliente
Descripción: Se utiliza para cancelar el proceso y cerrar la ventana.
Argumentos:
Entorno de Datos:
Lógica Asociada:
Comenzar
Cerrar ventana
Terminar
NOMBRE DE LA VENTANA: Alta Proveedores

Nombre: btnAltaProveedor
Descripción: Se utiliza para registrar un nuevo Proveedor en la Base de Datos.
Argumentos: IDProveedor – CUIT-CUIL – Nombre - Telefono
Entorno de Datos: Proveedores
Lógica asociada:
Comenzar
Buscar el CUIT-CUIL del Proveedor en la tabla Proveedores
Si Encontró
Mostrar mensaje de Proveedor existente.
Si No encontró
Crear un nuevo registro en la Base de Datos con los datos ingresados.
Fin Si
Teminar
Nombre: btnSalirAltaProveedor
Descripción: Se utiliza para cancelar el proceso y cerrar la ventana.
Argumentos:
Entorno de Datos:
Lógica Asociada:
Comenzar
Cerrar ventana
Terminar
Consultas SQL: (Ejemplos)

Nombre: Alta_Cliente (Coincide con el nombre del flujo que toca el almacén)
Tipo: Inserción
Entorno de Datos: Clientes
Condición: No deben estar cargados los datos de ese cliente previamente.
Resultado:
ATRIBUTO TIPO
IDCliente Integer
DNI Carácter
Nombre Carácter
Dirección Carácter
Teléfono Carácter
Casado Boolean
Así con todas las consultas de ABML que se realicen sobre los almacenes de la Base de Datos
Clase Nº 19
Las otras Etapas del Desarrollo

Implantación de sistemas es la construcción del nuevo sistema y la entrega de dicho sistema.
La implantación de sistemas de divide en cuatro fases, cada fase se describe en función de:
* El propósito de la fase.
* Las actividades que deberían realizarse.
* Los papeles desempeñados por las diversas personas en cada actividad.
* Las entradas y las salidas de cada actividad
* Las técnicas y los conocimientos que pueden usarse para completar cada actividad.
1) La fase de construcción y prueba de redes y bases de datos en la implantación: En muchos

casos, se construyen aplicaciones nuevas o mejoradas en torno a redes y bases de datos ya
existentes. Si fuera así, esta fase se omite. Sin embargo, si la nueva aplicación requiere redes y
bases de datos nuevas o modificadas se debe construir y probar las redes y bases de datos.
Bloques elementales para construir y probar redes y bases de datos:
* Construir (o modificar) y probar las redes.
* Construir (o modificar) y probar las bases de datos.

Actividad 1: Construir y probar redes (si es necesario): Dadas las necesidades de diseño de redes
desarrolladas durante el diseño de sistemas, el especialista de redes hará las modificaciones
apropiadas en las redes existentes susceptibles de ser usadas por el nuevo sistema.
Alternativamente, puede ser necesario desarrollar redes desde el principio. Como producto final
se obtienen redes instaladas que se pondrán en funcionamiento en la empresa.
Actividad 2: construir y probar bases de datos: Esta tarea debe preceder inmediatamente A otras
actividades de programación, ya que los archivos y las bases de datos son los recursos
compartidos por los programas informáticos que han de escribirse. Si se requieren bases de datos
nuevas o modificadas en el nuevo sistema, éste es el momento de construirlas y probarlas. Una
vez más esta actividad será realizada típicamente por el mismo de especialista de sistemas que
diseñó la base de datos. Recuerde que esta persona podría ser un especialista o una analista de
sistemas. Como requisito previo se debe instalar el hardware y software necesarios. El hardware
es normalmente instalado y probado por el vendedor, El software puede ser instalado o no por el
vendedor.
Dados los detalles de diseño de bases de datos preparados durante el diseño sistemas, el
especialista en base de datos o el analista desarrollarán nuevos archivos y base de datos que serán
utilizados por el nuevo sistema. El producto final de esta actividad es una estructura de
archivo/base de datos vacía de contenido para el nuevo archivo o base de datos. También durante
esta actividad se producen esquemas de base de datos revisado y detalles de datos de prueba.
2) La fase de construcción y prueba de programas en la implantación de sistemas: ahora

podemos dirigir nuestra atención hacia la construcción y prueba de los programas.
Bloques elementales para la fase de construcción y prueba de programas:
 desarrollar un plan detallado para guiar el desarrollo y las pruebas de programas informáticos
nuevos o revisados.
 Desarrollar programas informáticos que respondan de manera precisa a las necesidades de
proceso de la empresa.

Actividad 1: plan de programación: La primera tarea será desarrollar un plan de programación. El
plan de duración debería incluir tres etapas:
 Revisiones especificaciones de diseño: algunos expertos están en desacuerdo con la idea de

congelar las especificaciones. Los cambios críticos requieren una modificación inmediata en el
documento de especificaciones. Si el cambio no es crítico se anotará como un requisito de
mejora futura.
 Organización del equipo de programación: una extendida estrategia de programación
consiste en usar equipos con programadores jefes. El programador jefe revisa todas las
actividades de codificación y pruebas y ofrece su ayuda en los aspectos más difíciles de los
programas.
 Desarrollo de un plan de programación detallado: en la mayoría de las especificaciones de
diseño incluyen numerosos programas. Muchos sistemas se construyen por versiones. La
primera versión implanta los aspectos más críticos del sistema, de manera que la versión
pueda pasarse a explotación antes de que el sistema esté completamente construido. Otro
método apropiado consiste en construir primero programas de proceso de transacciones.
Actividad 2: escribir y probar nuevos programas: Dada la redacción del diseño técnico y el plan de
programación, el programador de aplicaciones escribirá y probará los programas. Los
programadores de aplicaciones más experimentados primero comprobarán la posible existencia
de componentes de software reutilizables disponibles en la biblioteca de software del centro de
sistemas de información.
Se propone un modo de implantación descendente, es decir, los módulo se diseñan, se codifican y
se prueban empezando por el superior.
Cada módulo atraviesa por tres etapas: diseño del algoritmo, codificación y pruebas. Una vez
completos, los módulos se integran entre sí y se prueban. Finalmente, se completará y se probará
el programa en su conjunto.
Existen tres niveles de ejecución de pruebas:
Las pruebas individuales son pruebas realizadas sobre módulos individuales, que pueden ser
programas, subrutinas, subprogramas, bloques o párrafos.
La prueba de unidades o programas en una prueba en la que se verifican todos los módulos
codificados, ya comprobados individualmente, como una sola unidad integrada.
La prueba de sistemas en una prueba que garantiza que los programas de aplicación escritos
individualmente funcionan de modo adecuado cuando se integran en el sistema global.
3) La fase de instalación y pruebas en la implantación de sistemas:

Bloques elementales para las fases de instalación y pruebas del nuevo sistema.
Los objetivos fundamentales de esta fase son:
 Instalar y probar los nuevos paquetes de software adquiridos de los vendedores.
 Realizar una prueba completa del sistema para garantizar que los paquetes de software
adaptado a las necesidades y del software adquirido funcionan juntos de un forma apropiada.
 Desarrollar un plan detallado para convertir el sistema antiguo en el nuevo sistema.
Actividades, participantes y técnicas de la instalación y las pruebas del nuevo sistema.
Actividad 1: Instalar nuevo paquete de software (sí es necesario): Algunos soluciones de los
sistemas pueden haber requerido la compra o el alquiler de paquetes de software. Si fuera así, el
programador de instalaciones deberá encargarse de la instalación de esos paquetes de software.
Una vez dados los paquetes de software y documentación, el programador de aplicaciones
instalará el paquete de software.
Actividad 2: probar el paquete (sí es necesario): Los programadores de aplicaciones deben probar
dicho paquete. Las necesidades de integración y la documentación de los programas son entradas
adicionales a la actividad de pruebas. La probar un paquete pueden ponerse de manifiesto nuevas
necesidades de integración para el nuevo sistema.
Actividad 3: Realizar una prueba del sistema (sí es necesario): Una vez que los paquetes de
software han sido instalados y probados, debemos llevar a cabo una prueba final del sistema.
Todos los paquetes de software, programas adaptados a las necesidades y programas existentes
que comprenda el nuevo sistema deben ser probados para garantizar que, en su conjunto,
funcionan adecuadamente. La prueba del sistema se realiza mediante el empleo de datos de
prueba del sistema. Si se detectan problemas se deberá retroceder a una actividad previa en la
fase de implantación.
Actividad 4: Preparar un plan de conversión: Una vez completada la prueba buena del sistema,
podemos empezar los preparativos para pasar el nuevo sistema a explotación. Mediante el
empleo de especificaciones de diseño para el nuevo sistema, el analista de sistemas desarrollará
un plan de conversión detallado.
Este plan identificará los archivos/bases de datos que han de instalarse, la formación
y la documentación necesarias para su desarrollo y una estrategia par convertir el antiguo sistema
en el sistema nuevo.
4) La fase de entrega del nuevo sistema para sus pasos a explotación de la implantación de
sistemas.
Bloques elementales en la fase de entrega del nuevo sistema para su paso a explotación.
El objetivo es convertir suavemente el sistema antiguo en el nuevo sistema.
 Instalar los archivos y/o bases de datos que utilizará el nuevo sistema.
 Ofrecer formación y documentación a las personas que utilizarán el nuevo sistema.
 Convertir el sistema antiguo en el nuevo sistema.

Actividad 1: Instalar los archivos y/o bases de datos: Para pasar el sistema a explotación, es
necesario cargar los archivos y las bases de datos. Deberán escribirse programas especiales para
cargar los nuevo archivos/bases de datos. Se usarán los datos existentes de los archivos/bases de
datos en producción, junto con los modelos de esquema de archivos y bases de datos y las
estructuras de archivos/bases de datos de los nuevos archivos /bases de datos para escribir
programas informáticos que carguen los nuevos archivos/bases de datos con datos existentes
reestructurados. Esta tarea, en si misma, es a menudo efectuada por grupos de introducción de
datos, ya que los usuarios finales no pueden dedicar tiempo suficiente para completarla.
Actividad 2: Impartir formación a los usuarios del sistema: Dada la documentación apropiada del
nuevo sistema, los analistas de sistemas suministrarán a los usuarios finales documentación de
usuario y formación de usuario final. El analista ofrecerá su ayuda a los usuarios durante el
período de aprendizaje, hasta que se sientan más cómodos y seguros con el nuevo sistema.
Se debe documentarse explícitamente todas las posibles situaciones que puedan darse y sus
procedimientos correctos de aplicación. La formación real se articula en torno a los manuales de
usuario. La formación puede impartirse a cada usuario de forma individual; sin embargo, por lo
general se prefiere impartir en grupo.
Actividad 3: Pasar al nuevo sistema: Después de la conversión, la propiedad del sistema se

transfiere oficialmente de los analistas y los programadores a los usuarios finales. El analista
completa esta actividad llevando a cabo un cuidadoso plan de conversión. El plan de conversión
incluirá estrategias detalladas de instalación que habrán de seguirse para convertir un sistema
existente en un nuevo sistema de información en producción.
Algunas estrategias son:
1) Puesta en servicio total: En una fecha especificada, se da fin al sistema antiguo y se pasa a
explotación el nuevo sistema. Este en un planteamiento de alto riesgo, ya que aún pueden
darse problemas importantes que el sistema recién puesto en explotación no pueda tratar
durante al menos un cierto período.
2) Conversión en paralelo: Con este planteamiento, se hace coexistir un sistema nuevo con el
antiguo durante un cierto periodo de tiempo para garantizar la resolución de todos los
posibles problemas que el nuevo sistema pueda acarrear antes de que el antiguo sea retirado.
Este enfoque será posible sólo si el sistema antiguo es básicamente manual.
3) Conversión por puestos: cuando un nuevo sistema se va a utiliza en numerosos puestos
geográficos en una empresa, se suele probar primero en un puesto determinado. Tan pronto
como dicho puesto haya probado el sistema, este podrá ser implantado en los restantes.
4) Conversión por etapas: una conversión por etapas se basa en el concepto de versiones
introducido anteriormente, cada versión puede experimentar una conversión total, en
paralelo o por puestos.
También en esta etapa se realizan las pruebas de aceptación del sistema:

La prueba de aceptación de sistemas es una prueba final del sistema llevada a cabo por los
usuarios finales mediante el empleo de datos reales durante un periodo amplio de tiempo. Esta
prueba aborda tres etapas:
1) Prueba de verificación, que comprueba el sistema en un entorno simulado haciendo uso de

datos simulados. El objetivo principal de la prueba de simulación es buscar posibles errores y
omisiones con respecto a las especificaciones de diseño y de los usuarios finales que se
determinaron en las fases anteriores pero no se lograron satisfacer durante la construcción.
2) Pruebas de validación, que comprueba el sistema en un entorno en vivo mediante el uso de
datos reales. Durante esta validación, se probarán diversas cuestiones.
a) Rendimiento del sistema: ¿son adecuados la productividad y el tiempo de respuesta de

los procesos para permitir una carga normal de trabajo? Si no fuera así, habría que volver
a escribir algunos programas para mejorar la eficacia o sustituir o adquirir la siguiente
versión del software para poder manejar la carga adicional de trabajo.
b) Rendimiento del proceso durante los picos de carga de trabajo: ¿Puede el sistema
manejar la carga de trabajo durante los períodos críticos de proceso? Si no fuera así, es
posible tener que mejorar el hardware y/o el software para incrementar la eficacia.
c) Prueba de ergonomía: ¿Es el sistema fácil de aprender y usar, de acuerdo con las
previsiones? Si no fuera así ¿es al menos correcto?
d) Prueba de los métodos y los procedimientos: Durante la conversión, los métodos y los
procedimientos del nuevo sistema serán probados en modo real por vez primera. Es
posible tener que modificar los métodos y los procedimientos si se demuestra que son
complejos e ineficaces desde el punto de vista del usuario.
e) Prueba de copias de seguridad y recuperaciones: Deberíamos simular que se ha
producido una perdida irremediable de datos y probar el tiempo requerido para
recuperarnos de este desastre. Además deberíamos, llevar acabo una comparación de los
datos de antes y de después del proceso para garantizar que la recuperación ha sido
correcta.
3) Prueba de auditoria: que certifica que el sistema no contiene errores y esta listo para su paso
a explotación. Existen empresas independientes que realizan la certificación de software y
sistemas por encargo de organizaciones de usuarios finales.
Actividad 4: Evaluar el proyecto y el sistema: La revisión pretende cumplir dos objetivos:
1. Evaluar el sistema de información operativo que se ha desarrollado.
2. Evaluar los procedimientos de desarrollo de sistemas para determinar en que medida podría
haberse mejorado el proyecto.
Una vez obtenidas las opiniones sobre los resultados por parte de la empresa y las opiniones sobre
los procesos dadas por los encargados del desarrollo de sistemas, es posible hacer una valoración
de nuestro rendimiento y aprender donde pueden incluirse mejoras.
Deben revisarse los siguientes elementos:
 ¿Cumple el nuevo sistema de información las metas y los objetivos identificados y
perfeccionados en las primeras fases del proyecto?.
 ¿Da el sistema un soporte adecuado al proceso de transacciones, la elaboración de informes
de gestión y las necesidades de ayuda a la decisión en la empresa?
 ¿Se han hecho realidad los beneficios previstos?
 ¿Que opinan los usuarios del nuevo sistema, como sería posible mejorar las relaciones con los
usuarios en proyectos futuros?
 ¿Debería realizarse de inmediato alguna de las mejoras propuestas al sistema?, debería
establecerse un orden de prioridades entre dichas mejoras.
 ¿Son adecuados los controles internos?
A lo largo de esta evaluación, se identificarán necesidades de mejoras/arreglos. Estas necesidades

servirán como hechos de partida para el soporte de sistemas.

Clase Nº 20
Soporte de sistemas: Es el mantenimiento permanente de un sistema después de que haya sido
puesto en explotación. Ello incluye tanto el mantenimiento estricto de los programas como las
posibles mejoras que puedan añadirse al sistema. Consta de las siguientes fases:
1) Corregir errores (también llamado mantenimiento): Con independencia de como esté
diseñado, construido y probado un sistema o aplicación, inevitablemente aparecerán errores.
Algunos de estos errores son:
* Fallos en la comunicación de las necesidades.
* Defectos de diseño.
* Situaciones no previstas, y por lo tantos no probadas.
* Mal uso no previsto de los programas.
En todas estas situaciones deben emprenderse acciones de corrección, estas acciones las
llamamos mantenimientos de sistemas o mantenimiento de programas.
Objetivos y bloques elementales del mantenimiento de sistemas:

* Hacer cambios predecibles en los programas existentes para corregir errores que se cometieron
durante el diseño y la implantación de sistemas.
* Preservar aquellos aspectos de los programas que ya fueron corregidos (Evitar la posibilidad de
que los arreglos en dichos programas originen que otros aspectos de los mismos funcionen de
modo diferente.
¿Cómo se relaciona el mantenimiento de sistemas con los bloques elementales de los sistemas de
información?
* PERSONAS: El mantenimiento de sistemas es normalmente iniciado por los usuarios del sistema.
El mantenimiento es llevado acabo por lo general por constructores de sistemas, con posible
ayuda de los diseñadores de sistemas.
* DATOS: El mantenimiento de sistemas rara vez influye sobre los datos, salvo por la posibilidad de
que se mejore la edición de dichos datos.
* ACTIVIDADES: Los procesos de los sistemas de empresa y de información se implantas
finalmente como programas de aplicaciones. El mantenimiento de sistemas consiste en arreglar
los errores cometidos durante la implantación de dichos programas.
* REDES: el mantenimiento de sistemas rara vez tiene que ver con las redes informáticas, si bien
en ocasiones son las redes informáticas las fuentes de determinados errores.
* TECNOLOGIA: El mantenimiento de sistemas, no tiene que ver con los cambios tecnológicos.
Actividad 1: definir y validar los problemas: Trabajando conjuntamente con usuario o usuarios, el
equipo deberá intentar validar el o los problemas consiguiendo reproducirlos. Si el problema no
puede reproducirse debería suspenderse el proyecto hasta que se reprodujera el problema y el
usuario pudiera explicar las circunstancias en las cuales tubo lugar. Las entradas es el conjunto de
errores encontrado al usar el sistema. Una posible salida sería las solicitudes de cambio validadas,
estas deberán definir las expectativas de solución.
Otra posible salida es problema no validado. En el caso de que volviera a producirse el error los
usuarios deberían ser aleccionados para que documentaran del mejor modo posible las
circunstancias que llevaron a la aparición del error y de los síntomas del problema.
Si el error ha sido validado, se pasarán los problemas y programas validados a la siguiente tarea.
Actividad 2: aplicar un juego de datos de prueba a los programas y la aplicación: El equipo

debería entonces aplicar un juego de datos de prueba a los programas y la aplicación. El
mantenimiento de sistemas puede descubrir efectos impredecibles y no deseables que influirán
sobre el funcionamiento y el rendimiento global de los programas o la aplicación. Por ese motivo,
antes de realizar ningún cambio en los programas, se ejecuten y se prueben para definir una línea
de partida con respecto a la cual puedan compararse los programas y aplicaciones modificados.
Este paso es llevado a cabo por el analista y/o programador de sistemas. Los usuarios también
pueden participar en él. Las entradas principales al mismo son los problemas y programas
validados.
Los casos de juego de datos de prueba pueden definirse de dos maneras posibles. La primera
consistiría en buscar datos de prueba antiguos. Si existieran, deberían servir como juego de datos
de prueba para la ejecución del programa. Alternativamente, es posible capturar
automáticamente los datos de pruebas por medio de empleo de una herramienta de prueba
registrando pulsaciones de teclado, movimientos de ratón e instrucciones, así como las respuestas
del sistema, mientras el usuario muestra un uso típico del sistema.
En cualquier caso, las salidas serán un rendimiento actual y de datos de prueba nuevo o revisado y
programas probados con juegos de datos de prueba.
Actividad 3: Conocer la aplicación y sus programas: En términos ideales, el conocimiento de la

aplicación se obtiene del diccionario. En centros de sistemas de información no basados en
diccionarios, puede conseguirse el conocimiento de la aplicación de los programadores y analistas
anteriores, pero dicho conocimiento puede no estar al día. Sin embargo puede ser de utilidad para
alcanzar un nivel suficiente de comprensión de la aplicación y donde encajan los programas
problemáticos dentro de dicha aplicación.
El conocimiento de la aplicación y los programas proviene por lo general del estudio del código
fuente de los programas probados con juego de datos de prueba. Esta actividad se hace mas lenta
por la combinación de una serie de limitaciones.
* Una deficiente estructura modular.
* Uso de lógica no estructurada.
* Mantenimientos previos (arreglos rápidos y ampliaciones deficientemente diseñadas).

* Código muerto (instrucciones que nunca se ejecutan o las que nunca se llega, a menudo
olvidadas durante fases anteriores de prueba y depuración)
* Documentación deficiente o inadecuada.
El propósito de conocer la aplicación es conseguir tener una visión general del asunto es decir,
saber como encajan los programas en una aplicación total y como interaccionan con otros
programas. También tiene como objetivo la comprensión de los programas, conseguir suficiente
información sobre como funciona el programa, y sobre lo que no funciona.
Actividad 4: Editar y probar los programas: dado el conocimiento de la aplicación y los programas
y los cambios validados pueden entonces realizarse los cambios en los programas que han de
modificarse. Su resultado es un programa modificado.
Es de esperar que los cambios en el código sean mejores si se conocen la aplicación del programa,
si se revisan. Pero más importante aun en el mantenimiento del sistema son las pruebas:
* Pruebas de unidades (esencial), asegura que el programa considerado en solitario arregla el
error sin efectos colaterales.
* Pruebas del sistema (esencial), asegura que la aplicación en conjunto, de la que forma parte el
programa modificado aún funciona.
* Prueba de regresión (recomendada), explota el impacto de los cambios en la productividad y el
tiempo de respuesta del programa y la aplicación antes y después.
Actividad 5: Actualizar la documentación: El alto coste del mantenimiento de sistemas se debe,

en gran parte, a fallos en la actualización de la documentación de la aplicación y los programas.
Cada vez que cambie la documentación de una aplicación, debe modificarse en el diccionario y en
la biblioteca de programas. La documentación de la aplicación es, por lo genera, responsabilidad
del analista de sistemas que da soporte a dicha aplicación. La documentación de los programas
suele ser responsabilidad del programador que realiza los cambios en los programas.
Grabar los cambios de las aplicaciones y los programas en el diccionario y la biblioteca de
programas ayudará a los futuros programadores y analistas (tal vez los mismos) a reducir el
tiempo dedicado al aprendizaje de la aplicación durante futuras tareas de mantenimiento.
2) Recuperar el sistema: El analista de sistema es a menudo el encargado de arreglar el sistema o

actuar como intermediario entre los usuarios y quienes deben recuperar el sistema.
Los papeles del analista en recuperación de los sistemas:
* En muchos casos, el analista puede sentarse ante el terminal de usuario y recuperar el sistema.
Es posible que se requieran instrucciones de corrección para evitar que vuelva a producirse el fallo
generalizado.
* En ciertos casos el analista debe ponerse en contacto con el servicio de explotación de los
sistemas para corregir el problema.
* En algunos casos el analista puede tener que recurrir a la administración de datos para recuperar
archivos o bases de datos perdidos o deteriorados.
* En algunos casos el analista puede tener que recurrir a la administración de redes para resolver
un problema de redes locales o extendidas, o de interconexión de redes.
* En algunos casos el analista puede tener que recurrir a los técnicos o representantes de los
vendedores para arreglar un problema de hardware.
* En algunos casos el analista tal vez descubra el error que a provocado el fallo. Este intentará
aislar dicho error rápidamente y bloquearlo para evitar dar lugar a otro fallo.
3) Asistir a los usuarios del sistema: Independientemente de cómo haya sido la formación de
usuarios de la calidad de la documentación, los usuarios requerirán asistencia adicional. El analista
de sistemas está, por lo general, a disposición de los usuarios para ofrecerles ayuda en el uso
diario de aplicaciones específicas. En aplicaciones de máxima importancia, el analista debe estar
disponible día y noche.
Una vez más, es innecesario ofrecer un diagrama de flujo detallado para esta actividad.
Las tareas más características comprenden:
* Observación rutinaria del uso del sistema.
* Realización de estudios y reuniones para conocer el grado de satisfacción del usuario.
* Cambiar los procedimientos de empresa para que sean más claros (se escribirán y se grabarán en
le diccionario).
* Ofrecer formación adicional.
* Anotar en el diccionario las ideas y las solicitudes sobre posibles mejoras.
4) Adaptar al sistema ante nuevas necesidades (también llamado reingeniería):

La adaptación de un sistema existente a las nuevas necesidades es una posibilidad siempre abierta
en todos los sistemas de nueva implantación. El mantenimiento ligado a estas adaptaciones obliga
al analista a analizar las nuevas necesidades y volver a las fases adecuadas del análisis, del diseño y
la implantación de sistemas.
Objetivos y bloques elementales de las mejoras y la reingeniería de sistemas: La mayor parte del
mantenimiento de adaptaciones se hace como respuesta a la aparición de nuevos problemas de
empresa, nuevas necesidades de información o nuevas ideas de mejoras.
* Personas: En su mayoría las mejoras a los sistemas so propuestas por los usuarios de los
sistemas, en algunos casos pueden ser propuesto por los analistas.
* Datos: Muchas mejoras de los sistemas son demandas de nueva información que pueden
derivarse de datos almacenados existentes.
* Procesos: En su mayoría, las mejoras a los sistemas requieren la modificación de programas
existentes o la creación de nuevos programas para ampliar el ámbito general del sistema de
aplicaciones.
* Redes: En su mayoría, las mejoras a los sistemas no tienen que ver con las redes.
* Tecnología: En su mayoría, las mejoras a los sistemas se basan en la tecnología.
Los objetivo de la reingeniería son o bien adaptar el sistema ante un cambio tecnológico
importante y arreglar el sistema antes de que falle o bien hacer el sistema más sencillo de manejar
para cuando falle o tenga que ser adaptado. Estos objetivos pueden relacionarse con los bloques
elementales de los sistemas de información del modo siguiente.
* Personas: En su mayor parte, la reingeniería es llevada a cabo por personal técnico y de sistemas
de información.
* Datos: Muchos proyectos de reingeniería son debidos a la necesidad de reestructurar los datos
almacenados.
* Procesos: Muchos proyectos de reingeniería intentan reestructurar o reorganizar programas de
aplicación para hacerlos más fáciles de mantener o convertirlos a un nuevo entorno tecnológico.
* Redes: Algunos proyectos de aplicación buscan modificar las aplicaciones y adaptarlas a una
nueva tecnología de redes.
* Tecnología: En su mayoría, los proyectos de reingeniería se deben a cambios en la tecnología o a
la necesidad de aprovechar mejor la tecnología existente.
Actividad 1: analizar las solicitudes de mejoras: El propósito de esta actividad es determinar el

curso apropiado de acciones para tratar nuevos problemas de empresa o ideas de mejoras,
problemas o limitaciones técnicas o ideas de mejoras. Esta actividad estudia la documentación
existente para determinar el curso apropiado de acciones que han de emprenderse. Sobre la base
del análisis de los modelos del sistema actual estas acciones pueden incluir:
* Definir nuevas necesidades de empresa y volver al análisis de sistemas.
* Definir nuevas necesidades técnicas y volver al diseño de sistemas.
* Definir nuevas necesidades de programa y proceder a la actividad 2.
Actividad 2: escribir nuevos programas sencillos: muchas mejoras pueden conseguirse

rápidamente mediante la escritura de nuevos programas sencillos. Los programas sencillos son
aquellos que utilizan datos existentes, no actualizan los datos existentes y no introducen nuevos
datos (por motivo de almacenamiento de datos).
En otras palabras, dichos programas generan nuevos informes y responden a nuevas consultas. Las
necesidades de nuevos programas conforman la mayoría de las mejoras que se requieren hoy en
día.
Actividad 3: reestructurar archivos o bases de datos: La migración de las estructuras de datos de

una tecnología a otra constituye un empeño de primer orden mas complicado aún por la
posibilidad de deteriorar programas y datos de empresa esenciales.
El mediador clave en la reestructuración de bases de datos es analista de bases de datos. El
analista de sistemas desempeña un papel de importancia, debido al impacto potencial en las
aplicaciones existentes. Los analistas de redes pueden también verse involucrados en esta tarea si
las bases de datos están, o han de estar, distribuidas en redes informáticas.
Las estradas clave a esta acción son las estructuras de bases de datos existentes y los datos,
procesos y redes existentes (almacenados en el diccionario). Las salidas son una nueva estructura
de bases de datos y un nuevo modelo de datos, procesos y redes.
Actividad 4: Analizar la biblioteca de programas y los costes de mantenimiento: Esta actividad

casi siempre requiere software capaz de llevar a cabo el análisis. Los analistas de sistemas suelen
ser quienes interpretan los resultados. Estos softwares utilizan una amplia variedad de métricas de
software, que son un conjunto de medidas matemáticamente probadas sobre la calidad y la
productividad del software.
Las métricas de software aplicables al mantenimiento son:
* Nudos de flujos de control, o números de veces que se cruzan entre si los caminos lógicos. En
términos ideales un programa debería tener 0 nudos de flujos de control.
* Complejidad de los ciclos, o número de caminos únicos a través de un programa. En términos
ideales cuanto menos sean mejor.
La métrica de software, en combinación con la contabilidad de costes puede ayudar a identificar
los programas cuya reestructuración producirá mayores beneficios.
Las entradas a esta tarea son todos los programas de la biblioteca o la mayoría de ellos.
Las salidas en un programa o programas candidatos para reingeniería.
Actividad 5: hacer reingeniería y prueba de los programas: Dado un programa o programas

candidatos para reingeniería, existen tres tipos de reingeniería que pueden aplicarse sobre dicho
programa:
a) Reorganización de código: reestructura la organización modular y/o la lógica del programa. Por
ejemplo, los módulos pueden combinarse o separarse para reducir el acoplamiento o aumentar la
cohesión.
b) Conversión de código: Traduce el código de un lenguaje a otro. Típicamente esta traducción se
realiza de una a otra versión del mismo lenguaje.
c) Fragmentación de código: Constituye la opción de reingeniería de programas más interesante
de todas. Muchos programas contienen componentes que deberían definirse como subprogramas.
Si se hace tal descomposición se obtendrían ventajas de mantenimiento. La importancia de dividir
el programa podría ser reutilizarlo en labores posteriores. La fragmentación de código extrae un
fragmento de un programa para crear un programa, o un subprograma independiente.
Los nuevos modelos de datos, procesos y/o redes se actualizan en el diccionario.

Analisis YDiseño

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis YDiseño

Cargado por

Copyright:

Formatos disponibles

Instituto de Estudios Superiores Argentino (IESA)

Materia: Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Def. 1: Es un conjunto de partes que se relacionan entre sí (interrelacionadas) con un objetivo en

En función con su relación con el medio:

 Sistemas Artificiales: Son sistemas creados por el hombre. Pueden ser:

a) Sistemas Manuales: realizados por el hombre en forma manual.

Participantes en el Desarrollo de un Sistema de Información (Bloques Elementales)

 Administración General: son los administrativos de nivel superior que no están

Características del analista:

Ciclo del desarrollo de un sistema / Ciclo de vida de un Sistema

 Planificación (No en todos los casos).

Análisis y Diseño de Sistemas

Análisis Diseño Implantación Soporte

 La fase de exploración y análisis pudieran juntarse en una sola.

 Nada esta hecho hasta que todo esté terminado.

Ciclo de Vida Semiestructurado

Ciclo de Vida Estructurado

Ciclo de Vida Semiestructurado Análisis Clásico + Diseño Estructurado

Ciclo de Vida Estructurado Análisis y Diseño Estructurado

Más información en:

Análisis y Diseño de Sistemas

1) Investigación de Hechos (también llamada reunión de información o recogida de datos)

a) Muestreo: es el proceso de seleccionar sistemáticamente elementos representativos de una

Razones por la que necesito hacer un muestreo:

Seleccionar el tipo de muestra: los tipos de muestra son:

 Intencionales: el analista basa la muestra sobre un criterio, ahora la muestra es restringida

Decisión del tamaño de la Muestra:

Tipos de información a buscar:

b) Cuestionarios: Son documentos específicos que permiten al analista recoger la información y

Tipos Básicos de preguntas usadas:

 Preguntas Cerradas: se utilizan cuando el analista de sistemas es capaz de listar

El lenguaje de los cuestionarios es un aspecto extremadamente importante para su efectividad. A

Formato del Cuestionario:

 Preguntas con elecciones múltiples.

Ventajas de los Cuestionarios:

Desventajas de los Cuestionarios:

c) Entrevista: Antes de realizar la entrevista necesita pensar en ella. Analizar el motivo de la

Planificación de la entrevista: consta de cinco pasos:

 Pierden la riqueza del detalle.

Errores en las preguntas:

Análisis y Diseño de Sistemas

Las presentaciones son actividades relacionadas, consisten en el envío formal de la

Viabilidad: es la medida del beneficio obtenido en una Organización gracias al desarrollo de un

En otras palabras, es la medida de las ventajas que el desarrollo de un sistema de información

Cuatro Test de Viabilidad

Causas de Fracasos en los Proyectos / Causas de Proyectos Fallidos

Pasos para Planificar:

10) Determinar Costo Total y Duración del Proyecto.

Análisis y Diseño de Sistemas

Guía para la construcción de un DFD

Diagrama Entidad Relación (DER)

Diagrama de transición de estados (DTE)

Notación del Diccionario de Datos

Análisis y Diseño de Sistemas

a) Identificar el problema, oportunidad o norma.

Metodología Moderna (STRADIS):

La planificación estratégica de sistemas pretende identificar y establecer prioridades acerca de

b) Fase de Definición: (definir una arquitectura de información). El propósito de la fase de

Análisis y Diseño de Sistemas

Es el bloque más importante. Las personas se clasifican en:

3. Bloque elemental de Actividades

El analista de sistemas y otros especialistas de los sistemas de información estudian y documentan