Participantes en el proyecto de sistemas

 Usuario: Es el personaje mas importante. Es aquel (o aquellos) para el cual se construye el sistema. No
necesariamente usa el sistema.
Existen tres tipos según la categoría de trabajo que realiza:
 Operacional: Aquel que tiene contacto directo con el sistema, preocupado por la parte operativa.
Desconoce el aspecto técnico y no sabe distinguir que parte del circuito esta trabajando mal.
Tiene visión local o física del sistema, no sabe como el sistema afecta a la organización.
Tiene un factor de resistencia al cambio (RC) muy alto.
 Supervisor: En gral. es operacional devenido a supervisor (por antigüedad). Usualmente administra a un
grupo de usuarios operacionales y es responsable de sus logros. Tiene una mejor visión de
los beneficios que el sistema le da (lo mide en tiempo). Desconoce el aspecto técnico y es el
interlocutor natural con los demás analistas.
 Ejecutivo: Preocupado por los beneficios que trae el sistema (ganancias a largo plazo). Le importa más la
visión estratégica que la operacional. No desconoce lo que pasa en el nivel operativo. Tiene
un panorama global del sistema, no se interesa por los detalles. Se preocupa por los
indicadores y por la evolución de los mismos. Ve las tendencias de mercado. Provee la
iniciativa para el proyecto.

Ciclo de Vida Tradicional

Es de desarrollo en cascada.
 Las fases se suceden en orden secuencial
 El costo es mayor a medida que avanza el proyecto
 Nada esta hecho hasta que todo esta terminado
 La eliminación de fallas es difícil en las ultimas etapas

Desventajas
 Es lento
 Poco Flexible
 Los resultados no son visibles hasta el final

Requerimientos
del sistema

Requerimientos
del software

Análisis

Diseño del
Programa

Codificación

Pruebas

Mantenimiento

Ciclo de Vida Estructurado

Es de desarrollo iterativo.
 Tiene origen en el relevamiento
 Las actividades pueden desarrollarse en forma paralela con progresivos niveles de refinamiento
 Existe retroalimentación entre actividades
 Las fallas y desvíos se detectan y corrigen tempranamente
 La fase de análisis esta basada en modelos
 Ambiental
 De comportamiento
 Implantación de usuarios
 La fase de diseño convierte el análisis en diseño de programas a través de modelos.
 La fase de implantación utiliza programación estructurada (desarrollo)
 Generación de pruebas de aceptación
 Fase Calidad
 Descripción de procedimientos
 Conversiones de Base de datos
 Instalación

Modelo esencial

Definición, objetivos y características

 Modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario tratando de describir lo
menos posible acerca de la implementación.
Componentes
 Modelo ambiental
 Modelo de comportamiento: Describe el comportamiento que el sistema tendrá para interactuar de manera
exitosa con el ambiente.

Modelo ambiental

Definición, objetivos y características

 Define la frontera entre el sistema y el resto del mundo o ambiente en el cual el sistema existe.
 Determina qué es parte del sistema y que no.
 Todo sistema es parte de un subsistema.
 El interior es llamado dominio de cambio.
 Modela el exterior del sistema.
 Determina qué información entra (estímulos) y qué información se va (respuestas).
 Debido a que construimos sistemas racionales, las respuestas son una reacción ante los estímulos. Sin
embargo no todos los estímulos deben tener una reacción asociada, no todos los estímulos nos
preocupan o interesan, solo los que requieran una respuesta.
Componentes
 Declaración de propósitos.
 Objetivos organizacionales (valor que se agrega a la organización)
 Objetivos funcionales (funcionalidad del sistema)
 Alcances del sistema.
 Supuestos asumidos.
 Diagrama de contexto.
 Lista de eventos

Declaración de propositos

Definición, objetivos, características y consejos de construcción

 Declaración textual y breve de los propósitos del sistema.
 Dirigida a niveles administrativos.
 No es una descripción detallada, sino un resumen, un pantallazo, vaga en detalles.
 Nunca, más de 1 párrafo.
 Algunos piensan que tiene que explicitar los beneficios tangibles y cuantificables que se logren con el sistema.
Útil en proyectos chicos.

Diagrama de contexto.

Definición, objetivos, características y consejos de construcción

 Modeliza la frontera e interacción del sistema con el exterior.
 Caso especial del DFD donde 1 sola burbuja representa todo el sistema.
 Describe terminadores con los que se comunica.
 Describe flujos de datos que intercambia con ellos (tanto recibe como envía).
 Describe los almacenes que el sistema comparte con los terminadores.

Lista de acontecimientos

Definición, objetivos, características y consejos de construcción

 Lista de los estímulos a los cuales el sistema responde.
 Cada estimulo debe producir respuestas, almacenar datos u ocasionar cambio en el estado del sistema.
 Describe acontecimientos desde el punto de vista del ambiente, desde afuera.
 Para identificar mejor acontecimientos investigar efectos de acciones de cada terminador sobre el sistema.
Tener en cuenta situaciones de falla de los terminadores, como acciona el terminador y la reacción del
sistema.

Modelo de comportamiento
 Modela el comportamiento que debe tener el sistema para realizar con éxito sus tareas.
Componentes
 DFD
 Especificaciones de procesos.
 DER
 Diccionario de datos.
 DTE

DFD

Definición, objetivo y características

 Modela los procesos que lleva a cabo un sistema. Modela aspecto funcional.
 Permite visualizar un sistema como una red de procesos funcionales conectados mediante flujos y
almacenamientos de datos.
 Cabe en 1 página  Fácil visualización.
 No requiere explicación por su fácil interpretación  Bueno para el usuario.
 No es puramente descendente, sino que se asciende y desciende según etapas.
Enfoque clásico
 Partiendo del diagrama de contexto, se desciende hasta el nivel 0 o superior donde se ve al sistema como un
conjunto de subsistemas, representados por burbujas. Luego se explota cada burbuja hasta el nivel de una
burbuja atómica donde no se requiera mayor descomposición.
 No es malo, pero presenta problemas:
Componentes
 Proceso: Parte del sistema que transforma datos de entrada en datos de salida.
 Flujo: Describe movimiento de información entre componentes del sistema. Representa datos en movimiento.
 Diálogo: Flujos que empacan una pregunta y respuesta en el mismo flujo.
 Almacenes: Modelizan colección de datos en reposo.
 Físicamente puede ser un archivo, una cinta, una tarjeta perforada…
 Puede existir como requerimiento fundamental del usuario (sincronización o comunicación entre 2
procesos no sincronizados) o conveniencia del sistema.
 El almacén es pasivo. Los datos viajan a través del flujo porque el proceso lo solicita.
 Lectura no destructiva: Por convenio no se modifica un almacén cuando se lo lee, se recupera copia.
 Terminadores: Entidades externas con las cuales el sistema se comunica.
 Están fuera del control del sistema que esta modelando.
 Los flujos que conectan a los terminadores con el sistema son la interfaz.
 No se muestran las relaciones que existen entre los terminadores.
Consejos para la construccion
 Evitar sumideros infinitos, burbujas que tienen entrada pero no salidas.
 Evitar burbujas de generación espontánea, tienen salidas pero no entrada.
 Cuidado con flujos y procesos no etiquetados. Revisar que algo no halla sido olvidado.
 Cuidado con almacenes de solo lectura o solo escritura. Si nadie lo actualiza, esta vacío. Si nadie lo lee, no
tiene sentido su existencia. La excepción son los almacenes externos que sirven como interfaz entre sistema y
entidad externa.
 Puede ser que 1 proceso necesite flujos de entrada de otros terminadores (sin ser acontecimientos) para
realizar su tarea.
 Existen acontecimientos que causan múltiples respuestas (todas las respuestas son independientes y usan
igual flujo de entrada) y acontecimientos múltiples que causen igual respuesta (flujos de entradas y salida y
respuesta son siempre iguales para todos los acontecimientos).
 Los procesos no se comunican entre si, sino a través de almacenes, porque los acontecimientos no son
necesariamente sincronizados, ocurren en ambiente externo no controlado por nosotros.
 Métodos para armado de nivel 0 a partir de DFD preliminar:
 Datos relacionados: Cada agrupación involucra respuestas relacionadas cercanas.
 Almacenes locales: Se busca enterrar los almacenes de forma que solo los procesos de la agrupación
haga uso de los almacenes locales enterrados.
 Capacidad de visualización: Regla de Miller (7 +/- 2).
 Métodos para descomposición:
 Secuencia de sub-tareas.
 Procesar entradas, combinar, componer salidas.

Organización en niveles
 Permite ver mejor la información. Dá más detalle sobre porciones del nivel anterior.
 Se usa sistema de numeración para relacionar diagramas de distintos niveles.
 Diagrama de contexto: 1 sola burbuja representando el sistema completo.
 Muestra la relación entre sistema y el ambiente que lo rodea.
 DFD 0: Vista de más alto nivel con las principales funciones e interfaces del sistema.
 DFD 1: 1 por cada proceso del DFD 0. describiendo el proceso en cuestión.
 DFD N: Muestran en mas detalle el desarrollo de porciones de un proceso.
 Se termina con una especificación de proceso.
Observaciones de la organización en niveles
 Debe haber los niveles necesarios para describir las primitivas de forma simple.
 No todas las burbujas deben tener el mismo nivel de detalle. Depende de la complejidad.
 Los flujos que salen y entran de una burbuja a nivel N deben ser iguales a los que salen y entran de todo el
nivel N + 1 correspondiente.
 Los almacenes que se muestran en un nivel deben conectar burbujas. Sino los son, son locales y están
incluidas implícitamente en un nivel inferior.

Especificación de proceso

Definición, objetivo y características

 Define lo que hay que hacer para realizar sus tareas: transformar entrada en salida.
 Solo se realiza para procesos primitivos de más bajo nivel. Para los de alto nivel, la especificación son los
DFD inferiores.
 Debe cumplir 2 requerimientos, mas allá de la forma en que se exprese la especificación:
 La especificación debe poder ser verificada por el usuario y el analista asi como debe poder ser
comunicada a al publico amplio. Por su ambigüedad al expresar ciclos o condiciones booleanas se evita el
lenguaje narrativo.
 No debe imponer decisiones de diseño o implantación. Ej: Definir limites de un ciclo.
Tipos de especificaciones de proceso
 Lenguaje estructurado.
 Pre y Post condiciones.
 Tablas de decisión.
 Árboles de decisión.

Lenguaje estructurado
 Lenguaje nativo con estructura.
 Describe de gran manera el algoritmo a utilizar.
 Se formaliza el lenguaje común. Se balancea precisión de lenguaje formal de programacion e informalidad de
lenguaje común.
 Se dice que con 40 o 50 verbos suficientes.
 Los objetos o sustantivos que se usan debe estar definidos en el DD o ser términos locales (se definen dentro
de la especificación).
 Puede ser que la especificación quede muy complejo. Cuidar que la especificación no use mucho espacio,
tenga como mucho 3 niveles de anidamiento utilizando sangrías.
Construcciones - Estructuras
 Si - Entonces - Otro - Fin si
 Hacer caso - Caso - Otro - Fin caso
 Hacer mientras - Fin hacer
 Repite - Hasta

Pre y post condiciones

 Describen propósito sin decir mucho del algoritmo.
 Útil cuando no es importante especificar el algoritmo.
 Precondición garantiza cosas que deben darse antes del comienzo del proceso.
 Generalmente, describe entradas disponibles, relación entre ellas y con almacenamientos y relación entre
almacenamientos.
 Postcondición describe las cosas que deben darse después del fin del proceso.
 Generalmente, describe salidas que se generaran, relaciones con entradas y almacenes y cambios en los
últimos.
 Debe poner pre y post condiciones de error. Igualmente, no debe ser muy complicada.

Tablas de decisión
 Describe proceso de decisión de toma de acción, relación entre acciones y condiciones.
 Útil para decisiones complejas. Difícil cuando muchas condiciones  2n combinaciones.

DER

Definición, objetivo y características

 Herramienta efectiva de modelado para comunicarse con el grupo de administración de bases de datos.
 Para el análisis representa un gran beneficio porque enfatiza las relaciones entre los almacenes de datos en el
DFD que de otra forma se hubiera visto solo en la especificación de procesos.
 Pueden verse las relaciones (conexiones) que en el DFD no pueden verse a simple vista.
 Es una herramienta de modelado de sistemas, que se concentra en los datos almacenados en el sistema y las
relaciones entre éstos. Es un modelo de red que describe la distribución de los datos almacenados en un
sistema de forma abstracta.
Componentes
1. Tipos de objetos.
 Se representa en un DER por medio de una caja rectangular. Representa una colección o conjunto de
objetos (cosas) del mundo real cuyos miembros individuales o instancias tienen las siguientes
características:
 Cada una puede identificarse de manera única por algún medio. Existe alguna forma de diferenciar
entre instancias individuales del tipo de objeto.
 Cada uno juega un papel necesario en el sistema que se construye. Es decir para que el tipo de objeto
sea legítimo, debe poder decirse que el sistema no puede operar sin tener acceso a esos miembros.
 Cada uno puede describirse por uno o más datos.

2. Relaciones.
 Los objetos se conectan entre si mediante relaciones. Una relación representa un conjunto de conexiones
entre objetos. Cada instancia de la relación representa una asociación entre cero o más ocurrencias de un
objeto y cero o más ocurrencias del otro.
 La relación representa algo que debe ser recordado por el sistema, no pudo haberse calculado o derivado
mecánicamente.
 Puede existir más de una relación entre dos objetos.
3. Indicadores asociativos de tipos de datos.
 Esta es una notación especial, representa algo que funciona como objeto como relación. Otra forma de
considerarlo es que el tipo asociativo de objeto representa una relación acerca de la cual se desea
mantener alguna información.

4. Indicadores de supertipo/subtipo.
 Los tipos de objetos de objetos de Subtipo / Supertipo consisten en tipos de objetos de una o más sub-
categorías conectados por una relación.

Diccionario de datos

Definición, objetivo y características

 Listado organizado de los datos pertinentes al sistema. Inherencia en varias etapas.
 Permite que el usuario y el analista conozcan los distintos elementos usados.
 Describe significado y composición de los flujos y almacenes.
 Describe composición de paquetes complejos incluidos en definiciones anteriores.
 Describe detalles de las relaciones que se muestran en el DER.
 Describe valores y unidades de piezas elementales incluidas anteriormente.
 Describe alias de ciertos términos para mayor facilidad y flexibilidad.
 La definición de un dato elemental consta de los siguientes pasos:
 Significado del dato dentro del contexto. Se pone como comentario.
 Composición del dato.
 Valores que puede tomar si es un dato elemental.
Pruebas de consistencia y lógica
 Todos los flujos y almacén deben estar definidos.
 Todos los paquetes complejos deben estar definidos.
 Todos los datos deben estar relacionados con algún modelo. (DFD, DER,…)

DTE

Definición, objetivo y características

 El diagrama de transición de estados o DTE, enfatiza el comportamiento dependiente del tiempo del
sistema.
 Hasta hace un tiempo, los modelos del comportamiento dependiente del tiempo del sistema importaban
solo para una categoría especial de sistemas conocidos como sistemas de tiempo real, por ejemplo
sistemas de conmutación telefónica.

Componentes

* ESTADOS: comportamiento del sistema que es observable en el tiempo. Los sistemas tienen un estado inicial,
pero pueden tener múltiples estados finales (mutuamente excluyentes).
 Cualquier estado observable en el que el sistema pueda estar solo pueden corresponder a períodos en los
que 1) esta esperando que algo ocurra en el ambiente externo o, 2) esta esperando a que alguna actividad
que se esté dando en ese momento en el ambiente cambie a otra.
 Un estado representa algún comportamiento del sistema que es observable y perdura durante un periodo
finito.

* Cambios de estados: condiciones y acciones.

 Para completar el DTE necesitamos agregar dos cosas: las condiciones que causan un cambio de estado
y las acciones que el sistema toma cuando cambia de estado. Las condiciones y acciones se muestran
junto a la flecha que conecta los dos estados relacionados.
Balanceo DFD – Diccionario de Datos (DD)
 Cada flujo de datos y cada almacenamiento de datos debe estar definidos en el DD.
 Cada dato y cada almacenamiento de datos definido en el DD debe aparecer en algún lado del DFD.

Balanceo DFD - Especificación de proceso

 Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una especificación de proceso, pero
no los dos.
 Cada especificación de proceso debe tener una burbuja de nivel inferior en el DFD.

Balanceo del DFD - DTE

 Cada burbuja de control de un DFD se asocia con un diagrama de transición de estados como su
especificación de procesos, y viceversa.
 Cada condición del DTE se corresponde con un flujo de datos entrante, y viceversa.
 Cada acción del DTE se corresponde con un flujo de datos de salida y viceversa.

Balanceo DFD – Especificación de proceso – DD

 Cada referencia de un dato en la especificación de proceso debe satisfacer una de las siguientes condiciones:
 Coincide con el nombre de un flujo de datos o almacenamiento descripto por la especificación de proceso.
 Es un Terminal local.
 Aparece como un componente de una entrada en el DD para un flujo o un almacenamiento asociado a
una burbuja.
 El DD es consistente con el resto del modelo si cumple la siguiente regla:
 Cada entrada del DD debe tener una referencia en una especificación de proceso, un DFD u otro DD.
 El DD es el menos riguroso en cuanto a su balanceo, si la deficiencia es por exceso.

Balanceo DFD - DER - Especificación de proceso

 Cada almacenamiento del DFD debe corresponder con un elemento o una combinación de elementos del
DER, una relación asociativa de elemento. También viceversa.
 Debe haber procesos que creen y eliminen instancias de cada tipo de objeto. Debe haber procesos que
actualicen y lean los almacenes.
 Las entradas del DD deben aplicarse tanto al modelo de DFD como al DER.

Modelo de implantación

Definición, objetivo y características

 Modela consideraciones del usuario a tener en cuenta para la implantación.
Frontera de automatización
 Que funciones y que datos se manejaran manualmente o automáticamente.
 Responsabilidad del usuario determinarla en colaboración con el equipo.
Tópicos
1. Distribución del modelo esencial entre personas y maquinas (determinación de la frontera de la
automatización).
 Casos extremos:
 El usuario puede escoger tener un sistema totalmente automatizado.
 El usuario no automatiza nada, simplemente reorganiza la forma en que se desempeñan
actualmente las actividades de la organización.
 Al usuario no le interesa la frontera entre lo automatizado y lo manual.

2. Detalles de interacción Humano-Maquina. (Dispositivos).

 La elección de los dispositivos de entrada y salida (ej: terminales de video, dispositivos de
reconocimiento óptico de caracteres, tarjetas perforadas, etc. para las entradas y reportes en papel,
despliegues en pantalla o luces como salidas).
 El formato de todas las entradas que fluyen desde los terminales hasta el sistema.
 El formato de todas las salidas que fluyen desde el sistema hasta los terminales.
 La secuencia y los tiempos de entradas y salidas en un sistema de línea.
 3. Actividades manuales que se vayan a analizar.
 Actividades manuales reflejadas en manuales de procedimientos (ej: cambios en la introducción de
datos al sistema).
4. Restricciones operativas (requerimientos No Funcionales).
 Restricciones que se le imponen al sistema (ej: tiempo de respuesta de una transacción, sistema
escalable, multiplataformas (portabilidad)).
 Restricciones ambientales (ej: ruidos, radiofrecuencias).
 Restricciones de confiabilidad (ej: MTBF-tiempo mínimo entre fallas-, MTTR-tiempo mínimo de
respuesta-, tiempo de disponibilidad).
 Restricciones de seguridad (Ej: clave de 8 dígitos, clave alfanumérica, etc.).

5. Administración de cambios (Change Manager)

 Incertidumbre de los Usuarios (operadores)
 Plan de comunicación: Informar, clarificar dudas.
 Plan de capacitación: Operadores, supervisores, mesa de ayuda.
 Plan de contingencia.

Interfaz humana
 Más interés de los usuarios con el desarrollo de los sistemas y los dispositivos de E/S.
 Elección de dispositivos de E/S y formato de la información que fluye a través de ellos.

Entrada Salida
 Tarjetas perforadas  Salidas impresas
 Cinta magnética  Tarjetas perforadas
 Discos flexibles  Terminal
 Terminales y PC  Voz
 Lectores ópticos y de código de barras  Graficador
 Teléfono  Cinta magnética o disco.
 Voz  COM

 Secuencia (diag. trans. estados) y tiempos relacionados con esas E/S.

 Reglas para una buena interfaz
 El sistema debe pedir y producir E/S de forma consistente y lógica.
 Haga obvio al usuario cual y donde esta el error cometido. Pero la revisión debe ser dependiente del
usuario.
 Distinga entre edición de campos (individual) y de pantalla (global).
 Permitir cancelación parcial o total de la transacción.
 Proporcionar mecanismos de ayuda conveniente.
 Use convenientemente sistemas guiados por menús o por órdenes.
 Desplegar información consistente mas aun para procesos largos.
 Proporcionar alternativas por omisión.
 Aproveche color y sonido pero sin abusar.
 Los formularios siempre tienen 3 partes:
 Titulo: Distingue la forma entre las demás.
 Instrucciones: Indica al usuario como llenar la misma.
 Cuerpo: Lugar donde se ingresan los datos.
Tareas adicionales
 Es importante tener en cuenta posibles errores de uso del sistema, de HW o de SW y tomar las
consideraciones necesarias como puede ser la redundancia en algunas partes.
Restricciones operacionales
 Combinación de HW, SO, lenguaje de programación y estrategia de diseño.
 Parámetros a tener en cuenta para mejor decisión:
 Volúmenes de datos.
 Tiempo de respuesta a las entradas.
 Restricciones políticas sobre modalidades de implantación.
 Restricciones ambientales.
 Restricciones de confiabilidad (promedio de fallas).
 Restricciones de seguridad de datos.