Botta - Análisis de Sistemas

Página 1 de 142 Autor: Adrián Botta

Resumen de Teoría de:

Análisis de Sistemas

Autor: Adrián Botta Año: 2008

Fuentes: Análisis Esencial Estructurado – Yourdon y Pressman Sistemas de Información Administrativa – Murdick y Munson Ing. Del Software: Un enfoque práctico – Pressman UML: proceso unificado y Manual de referencia – Rumbaugh, Jacobson, Booch UML y patrones – Larman Ing. Del Software Orientado a objetos con UML, Java e Internet - Weitzenfeld Análisis y Diseño Orientado a objetos con aplicaciones – Booch Análisis y Diseño de Sistemas – Kendall y Kendall Análisis y Diseño de Sistemas de Información - Senn Análisis Estructurado Moderno - Yourdon



UNIDAD 1

Autor: Adrián Botta - Año 2008


De Definición De Desarrollo De Mantenimiento Lineal, Secuencial, Ciclo de vida Básico o Cascada DRA Incremental Espiral Ciclo de Vida Estructurado T4G Prototipos Reutilización de Componentes

Definición

Fases Modelos Modelos Evolutivos

Estrategias

Características Ciclo

Ing. Sistemas / Información Planificación del Proyecto de Software Análisis de Requisitos Diseño de Software Generación de Código Prueba de Software M. Correctivo M. Adaptativo M. Perfectivo M. Preventivo 1- Ing. Sistemas / Información 2- Análisis de los requisitos del Software 3- Diseño 4- Generación de Código 5- Pruebas 6- Mantenimiento

1- Modelado de Gestión 2- Modelado de Datos 3- Modelado de Proceso 4- Generación de Aplicaciones 5- Prueba y Entrega 1- Encuesta 2- Análisis de Sistemas 3- Diseño 4- Implantación 5- Generación de Pruebas de Aceptación 6- Prueba final de Aceptación 7- Descripción del Procedimiento 8- Conversión de Bases de Datos 9- Instalación De Requisitos De Análisis De Diseño De Factibilidad Verticales Producción Consumo

Dirigido Por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental

1- Fase de Inicio 2- Fase de Elaboración 3- Fase de Construcción 4- Fase de Transición

Ing. Del Software Proceso Unificado


UNIDAD 1: INGENIERÍA DEL SOFTWARE (IDS)

Es la aplicación (y estudio) de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software.

La IDS es una tecnología multicapa. Cualquier enfoque de la ingeniería debe apoyarse sobre un compromiso de organización de calidad. El fundamento de la IDS es la capa de proceso, que permite un desarrollo racional y oportuno de la IDS. El proceso define un marco de trabajo para un conjunto de Áreas clave de proceso (ACPs), que forman la base de control de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos de trabajo, se establecen

hitos, se asegura la calidad y el cambio se gestiona adecuadamente. Los métodos indican cómo construir técnicamente el software. Abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Las herramientas proporcionan un enfoque automático o semi-automático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (CASE). Para construir la IS adecuadamente, se debe definir un proceso de desarrollo de software. El trabajo que se asocia a la IS se puede dividir en 3 fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto: Fase de Definición: Se centra sobre el qué (que inf. ha de ser procesada, que interfaces se

colocarán, etc.). Han de definirse los requisitos clave del sistema y del software. Tendrán lugar aquí 3 tareas principales: - Ing. De sistemas o de Información - Planificación del proyecto del software - Análisis de los requisitos

Fase de Desarrollo: Se centra en el cómo (como han de diseñarse las BD, como ha de implementarse una función, etc.). Tendrán lugar aquí 3 técnicas principales: - Diseño de software - Generación de código - Prueba del software

Fase de Mantenimiento: Se centra en el cambio. Hay 4 tipos de cambio: - Corrección (Mantenimiento Correctivo): Se cambia el software para corregir los defectos - Adaptación (M. Adaptativo): Produce modificación en el software para acomodarlo a los cambios

de su entorno externo - Mejora (M. Perfectivo): Lleva al software más allá de sus requisitos funcionales originales - Prevención (M. Preventivo o Reingeniería del Software): Hace cambios en programas a fin de que

se puedan corregir, adaptar y mejorar más fácilmente. Además de estas actividades, los usuarios requieren de un mantenimiento continuo

El proceso del Software Se establece un marco común de proceso definiendo un pequeño nº de actividades del marco de trabajo

que son aplicables a todos los proyectos del software. Un nº de conjuntos de tareas que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de protección abarcan el modelo de procesos. Últimamente se hace énfasis en la madurez del proceso. El Instituto de IS ha desarrollado un modelo completo que se basa en un conjunto de


funciones de IS que deberían estar presentes conforme organizaciones alcanzan diferentes niveles de madurez del proceso. El estado actual se categoriza en un nivel según un cuestionario. El esquema de grados determina la conformidad con un modelo de capacidad de madurez que define las actividades clave que se requieren en los diferentes niveles de madurez del proceso.

MODELOS DE PROCESO DEL SOFTWARE

A fin de resolver problemas reales, se selecciona un modelo de proceso para la IS según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren. Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas (ver imagen). Raccoon sugiere un “Modelo del caos”, que describe el desarrollo de software como una extensión desde el usuario hasta el desarrollador y la tecnología. Conforme progresa el trabajo hacia un sistema completo, las etapas descritas anteriormente se aplican recursivamente a las necesidades del usuario y a la especificación técnica del desarrollador del software. Modelo Lineal Secuencial, Ciclo de vida Básico o Cascada

1- Ing. de Sistemas / Información: El trabajo comienza estableciendo requisitos de todos los

elementos del sistema y asignando al software algún subgrupo de estos requisitos. La Ing. de información abarca los requisitos que se recogen a nivel de empresa estratégico y en el nivel del área de negocio

2- Análisis de los requisitos del software: Referido a la función requerida, comportamiento, rendimiento e interconexión.

3- Diseño: Estructura de datos, arquitectura de software, representaciones de interfaz y algoritmo 4- Generación de código 5- Pruebas 6- Mantenimiento: Algunos problemas son

Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo A menudo es difícil que el cliente exponga explícitamente todos los requisitos El cliente debe tener paciencia: una versión de trabajo del programa no estará disponible hasta

que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa

Modelo DRA (Diseño Rápido de Aplicaciones) Es un proceso de desarrollo lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rápido. Utiliza una construcción basada en componentes. El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos cortos de tiempo. Sus fases son:

1- Modelado de Gestión: ¿Qué inf. circula, a dónde va, quién la genera, etc..?

2- Modelado de Datos: Se definen las características de cada uno de

Análisis Diseño Prueba Código

Ing. de sistemas / Inf.


los objetos y las relaciones entre estos objetos 3- Modelado del proceso: Los objetos de datos definidos en la fase de modelado de datos quedan

transformados para lograr el flujo de información necesario para implementar una función de gestión

4- Generación de Aplicaciones: El DRA trabaja para volver a utilizar componentes de programas ya existentes y/o crear componentes reutilizables. Utiliza técnicas de 4º generación

5- Prueba y entrega: La reutilización reduce tiempos de pruebas, sin embargo se deben probar todos los componentes nuevos y ejecutar todas las interfaces a fondo

Cada una de las funciones puede ser afrontada por un equipo DRA separado y ser integradas en un solo conjunto.

Inconvenientes del modelo DRA: Para proyectos grandes requiere muchos recursos humanos DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades No todos los tipos de aplicaciones son apropiadas para DRA (componentes) DRA no es adecuado cuando los riesgos técnicos son altos (Ej: nuevas tecnologías)

MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE

En ninguno de los paradigmas de la IS se tiene en cuenta la naturaleza evolutiva del software. Los modelos evolutivos son iterativos; se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del software Modelo Incremental Combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía iterativa de construcción de prototipos. Este modelo aplica secuencias lineales de forma escalonada mientras progresa en el tiempo en el calendario. Cada secuencia lineal produce un “incremento” del software. Cuando se utiliza un modelo incremental, el 1º incremento a menudo es un producto esencial, es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias quedan sin extraer. El cliente utiliza el producto central, y como resultado de su utilización, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Este modelo se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación. Este tipo de desarrollo es útil cuando la dotación de personal no estará disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto. El modelo Espiral Conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones


incrementales. Durante las primeras interacciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado. El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas (ver imagen)

Cada una de las regiones está compuesta por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse. Este modelo puede adaptarse y aplicarse a lo largo de la vida del software de computadora. La espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. El

modelo utiliza la construcción de prototipos como mecanismo de reducción de riesgos. El modelo espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Técnicas de Cuarta Generación (T4G) Abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera el código fuente basándose en la especificación del técnico. Cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa. T4G comienza con el paso de reunión de requisitos, que se traducen en un prototipo operativo. Sin embargo, en la práctica no siempre se puede hacer esto, ya que el cliente puede ser ambiguo en sus especificaciones, o puede que no esté dispuesto a especificar la información en la forma que puede aceptar una herramienta T4G. Por eso el contacto desarrollador-cliente es esencial.

T4G tiene ventajas e inconvenientes. 1- T4G ofrece una solución fiable a muchos problemas del software 2- El tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y medias. 3- El uso de T4G para grandes trabajos exige el mismo o más tiempo de análisis diseño y prueba,

para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación

Ciclo de Vida Estructurado

(S) Está involucrado el analista;(N) No está involucrado;(S/N) Puede o no estar 1- La Encuesta (S/N): Empieza cuando el usuario solicita que una o más partes de su sistema se

automaticen. Tiene como objetivos: Identificar a los usuarios responsables y crear un campo de actividad inicial del sistema Identificar las deficiencias actuales en el ambiente del usuario Establecer metas y objetivos para el nuevo sistema Determinar si es factible automatizar el sistema, y de ser así, sugerir escenarios aceptables. Esto

implicará estimaciones de costo (Margen error + 50 %) Preparar el esquema que se utilizará para guiar el resto del proyecto

2- Análisis de Sistemas (S): Su propósito es transformar las políticas del usuario y el esquema del proyecto en una especificación estructurada. Implica el desarrollo de un modelo ambiental y uno de comportamiento, que se combinan para formar el modelo esencial, que representará una descripción formal del lo que el nuevo sistema debe hacer.

3- El Diseño (S): Asigna porciones del modelo esencial a procesadores adecuados y a labores apropiadas. Dentro de cada labor se define una jerarquía de módulos de programas y de interfaces entre ellos para implantar la especificación creada en el análisis. Se diseñan las Bases de Datos. Se desarrolla el modelo de implantación del usuario, que describe las interfaces y fronteras hombre-máquina.


4- Implantación (N): Incluye la codificación y la integración de módulos en un esqueleto progresivamente más completo del sistema final

5- Generación de pruebas de Aceptación (S/N) 6- Garantía de Calidad o Prueba final de aceptación (S/N) 7- Descripción del procedimiento (S): Aquí se desarrolla el manual del usuario 8- Conversión de bases de datos (Participación variable): Convierte o adapta la vieja base de datos a

una nueva que se adapte al nuevo sistema 9- Instalación (N): Puede ser total o gradual

ESTRATEGIAS

Una estrategia es un plan para lograr un objetivo. Las estrategias de desarrollo incluyen la selección de una tecnología y lenguaje de programación particular. Otras estrategias son los prototipos y la reutilización de componentes. Prototipos Un prototipo es una versión preliminar, incompleta o reducida de un sistema. Su propósito es obtener rápidamente la información necesaria para ayudar en la toma de decisiones. Los tipos de prototipos son: Prototipos de requisitos (o de Relevamiento): Permite que los usuarios perciban la funcionalidad del

producto final a través del diseño de interfaces o pantallas del sistema Prototipos de Análisis: Hacen posible generar rápidamente una arquitectura general de acuerdo a la

especificación de requisitos Prototipos de Diseño: Permiten explorar y comprender la arquitectura particular del sistema Prototipos verticales: Ayudan a comprender parte de un problema y desarrollar su solución

completa Prototipos de factibilidad: Demuestra si es posible lograr ciertos objetivos del proyecto

Un prototipo no es un producto de calidad que deba mantenerse a largo plazo, sino que son creados y probados rápidamente para luego desecharlos. Los prototipos tienen éxito cuando:

- Se tiene claro el propósito del prototipo y se usa adecuadamente - Se comprende la tecnología a usar y su relación con el proceso de prototipos - Se integra un grupo de técnicos apropiado para hacer el prototipo - Se evalúa al grupo y las entregas finales - Se involucra a tiempo en el proceso a los usuarios finales

Los prototipos fallan cuando: - No se entiende qué es un prototipo y cómo debe usarse - No se comprende bien como organizar al grupo de trabajo - Los prototipos nunca terminan - Se cree que un prototipo es un producto aceptable

Reutilización de Componentes Es la explotación de componentes desarrollados anteriormente dentro de un mismo proyecto o entre proyectos. Se clasifican en:

Dentro de la reutilización, existen 2 partes:

Consumo de componentes reutilizables: Requiere identificar si ya existe una solución disponible, parcial o completa. La ventaja es que el componente ya está testeado.

Según el Nivel

Bajo nivel Mismo Proyecto Herencia, Procedimientos Alto Nivel Distintos proyectos Paquetes, Bibliotecas


Producción de componentes reutilizables: Significa tener una perspectiva de múltiples proyectos. El esfuerzo para producir componentes reutilizables es mayor al esfuerzo para producir componentes normales.

La Reutilización es valiosa cuando: - Se desea estandarizar - Se desea reducir costos - Se desea mejorar la calidad del producto y el tiempo de entrega

La Reutilización no es valiosa cuando: - No se reducen los tiempos de prueba - Se deben ajustar los componentes - No se comprenden las interfaces de los componentes

HERRAMIENTAS

Son aplicaciones que apoyan la administración del proceso de software. El conjunto de estas herramientas se conoce como Ing. de Software asistida por computadora (CASE), cuyo objetivo es asistir al desarrollador durante las diferentes actividades del ciclo de vida del proceso del software. Las herramientas incluyen editores de texto, generadores de diagramas, verificadores, depuradores, etc.

EL PROCESO UNIFICADO

El proceso unificado (PU) es un proceso de desarrollo de software. Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. El proceso unificado es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. Este proceso está basado en componentes interconectados a través de interfaces bien definidas. El Proceso unificado utiliza el Lenguaje de Modelado Unificado (UML) para preparar todos los esquemas de un sistema de software. Los aspectos definitorios del PU son:

- Dirigido por casos de usos: Un sistema software dará servicio a sus usuarios, por tanto, debemos conocer lo que sus futuros usuarios necesitan y desean, ya que el usuario interactuará con el sistema. Una interacción de este tipo es un caso de uso. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad total del sistema. Debemos preguntarnos ¿Qué debe hacer el sistema….para cada usuario?, por eso los casos de uso guían el proceso de desarrollo, proporcionan un hilo conductor para el proceso. Aunque los casos de uso guían el proceso, se desarrollan conjuntamente con la arquitectura del sistema, y ambos maduran según avanza el ciclo de desarrollo.

- Centrado en la arquitectura: El concepto de arquitectura incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, como la perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, también se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de construcción reutilizables que se disponen, un marco de trabajo, consideraciones de implantación, sistemas heredados y requisitos no funcionales. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. Los casos de uso deben encajar en la arquitectura cuando se llevan a cabo, y la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. Los arquitectos modelan el sistema para darle una forma. La arquitectura debe diseñarse para permitir que el sistema evolucione en su desarrollo inicial y a lo largo de las futuras generaciones. Para encontrar esa forma, los arquitectos deben trabajar sobre la comprensión general de las funciones clave, es decir, sobre los casos de uso claves del sistema.


- Iterativo e Incremental: Los desarrolladores basan la selección de lo que se implementará en una iteración en dos factores. En 1º lugar, la iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora. En 2º lugar, la iteración trata los riesgos más importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la última iteración. En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si una iteración cumple con sus objetivos, el desarrollo continúa con la siguiente iteración. Sino, se prueba con un nuevo enfoque. Los beneficios de un proceso iterativo controlado son:

- Reducción del coste de riesgo a los costes de un solo incremento - Reducción del riesgo de no sacar al mercado el producto en el calendario previsto - Acelera el ritmo del esfuerzo de desarrollo en su totalidad, ya que se obtienen resultados claros a corto

plazo - Reconoce la realidad de que las necesidades del usuario y los requisitos no pueden definirse

completamente al principio, sino que se refinan en iteraciones sucesivas.

La vida del proceso unificado El Proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo consta de 4 fases: inicio, elaboración, construcción y transición (c/fase se subdivide en iteraciones). Cada ciclo produce una nueva versión del sistema, y cada versión es un producto preparado para su entrega. El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual. Para llevar a cabo el siguiente ciclo de manera eficiente, los desarrolladores necesitan todas las representaciones del producto software.

Todos estos modelos están relacionados. Juntos representan el sistema como un todo. Los elementos de un modelo poseen dependencias de traza hacia atrás y hacia delante, mediante enlaces hacia otros modelos. Fases dentro de un ciclo

1- Fase de inicio: Se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis de negocio para el producto

2- Fase de Elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. El resultado de esta fase es una línea base de la arquitectura, y la disposición del director de planificar las actividades y estimar los recursos necesarios para terminar el proyecto

3- Fase de Construcción: Se crea el producto. Aquí la línea base de la arquitectura crece hasta convertirse en el sistema completo. Al final de esta fase, el producto tiene todos los casos de uso que la dirección y el cliente han acordado para el desarrollo de esta versión. Sin embargo, puede tener defectos

4- Fase de Transición: Cubre el periodo comprendido durante el cual el producto se convierte en versión beta. Esta fase corrige errores antes de la entrega. El equipo de mantenimiento divide los errores en 2 categorías: los que tienen suficiente impacto en la operación para justificar una versión incrementada y los que pueden corregirse en la siguiente versión normal.

Modelo de casos de uso

Especificado por Realizado por Distribuido por Implementado por Verificado por

Modelo de Análisis

Modelo de Diseño

Modelo de Despliegue

Modelo de Implementación

Modelo de Prueba



UNIDAD 2



Auditores, Control de Calidad y Departamento de normas o Estándares Analista de Sistemas Diseñadores de Sistemas Programadores Personal de Operaciones

Usuarios Administradores

Según Categoría de Trabajo o nivel de Supervisión

Según nivel de Experiencia Administradores Usuarios Administradores de Informática Administradores Generales

U. Operacionales U. Supervisores U. Ejecutivos U. Amateur U. Novato Presuntuoso U. Experto

1- Planificación

2- Estimación de Costes y Plazos

3- Seguimiento y Supervisión del Proyecto Software

4- Gestión de Riesgos del Soft

A) Definición del Ámbito del Software

B) Plan de Proyecto

Calendario

Técnicas para Realizar Calendario

C) Gestión de Compromisos

1- Comparar los resultados actuales con planes previstos 2- Tomar acciones correctivas cuando hayan desviaciones

Riesgos Estratégicos Riesgos Comerciales Riesgos Contractuales y financieros Riesgos de Gestión Riesgos de Proyecto Riesgos de Explotación Riesgos de Mantenimiento

1- Obtención de la Inf. Necesaria 2- Recursos (Humanos, de Software

Reutilizable y de Entorno) 3- La decisión Desarrollar-Comprar

1- Def. de objetivos del proyecto 2- Descomposición de las actividades 3- Relación entre las actividades 4- Estimación de los tiempos y costos de

las actividades 5- Reajuste del programa de tiempos a

las restricciones del proyecto 6- Asignación de recursos y definición de

la organización del equipo 7- Revisión del calendario Diagrama de Hitos Diagrama de Gantt Full-Wall Redes de Precedencia

Participantes del Juego de los Sistemas Gestión de Proyectos de Software


UNIDAD 2: PARTICIPANTES DEL JUEGO DE LOS SISTEMAS

Usuarios: Es el participante más importante. El usuario es aquel (o aquellos) para quien se construye el sistema. Es la persona a la que tendrá que entrevistar, a fin de conocer las características que deberá tener el nuevo sistema para tener éxito. Se identifica al usuario también con el término “cliente”. Debemos recordar que el cliente siempre tiene la razón, y que es el cliente el que a fin de cuentas paga el sistema y usualmente tiene el derecho de rehusarse a pagar si no está conforme con el producto. En la mayoría de los casos es fácil identificar al usuario: es aquel que formalmente solicita un sistema. Pero hay un gran nº de situaciones en las que no se conoce la identidad del verdadero usuario o bien en las que hay poca oportunidad en que éste interactúe con el analista. El “verdadero” usuario pudiera nombrar a un representante para trabajar con el analista por estar demasiado ocupado personalmente con otros asuntos. Obviamente, en situaciones de este tipo, hay una gran posibilidad de malos entendidos: lo que el usuario quiere que el sistema haga, pudiera no serle comunicado de manera correcta al analista, y lo que éste crea que está construyendo para el usuario pudiera no serle comunicado tampoco de manera correcta, hasta que ya estuviera todo terminado, cuando ya sería demasiado tarde. Por lo tanto, como conclusiones, podemos decir que el analista debe en lo posible tratar de establecer contacto directo con el usuario; y de no ser posible, la documentación generada por el analista se vuelve aún más importante, para evitar reclamos futuros.

Uno de los errores más comunes, es el de suponer que todos los usuarios son iguales. Se tiene la tendencia a pensar que son un grupo de humanos amorfo y homogéneo. Se clasifican en:

Clasificación de usuarios por categoría de trabajo o nivel de supervisión - Usuarios Operacionales: Son oficinistas, administradores y operadores que son los que más

probablemente tendrán contacto diario con el nuevo sistema. Por eso, en una organización grande, se deberá entrevistar a secretarias, oficinistas, ayudantes, etc. En caso de un sistema de tiempo real, pudiera tener que hablar con usuarios operacionales como ingenieros, físicos, etc. Hay que tener en cuenta:

1- Estos usuarios se preocupan mucho por la interfaz, y en menor medida, por las funciones que tendrá el sistema

2- Estos usuarios tienden a poseer un panorama “local” del sistema, es decir, a menudo no están familiarizados en como encaja su trabajo en la organización global

3- El analista puede tener que hablar con terminología familiar para estos usuarios - Usuarios Supervisores: Usualmente administran a un grupo de usuarios operacionales y son

responsables de sus logros. Hay que tener en cuenta: 1- Muchos son usuarios operacionales que han sido promovidos, por lo que se puede suponer que

están de acuerdo con las necesidades, preocupaciones y perspectivas de los usuarios operacionales

2- Se interesan en el nuevo sistema por la posibilidad de incrementar el volumen de trabajo realizado disminuyendo a la vez el costo de procesar las transacciones, y reduciendo también los errores en el trabajo

3- El usuario supervisor ve al nuevo sistema como una forma de reducir el nº de usuarios operacionales. Esto es punto focal de batallas políticas en las que el analista suele quedar en medio.

4- El U. Supervisor a veces actúa de intermediario entre el analista y el U. Operacional, aduciendo que estos últimos están muy ocupados

5- El U. Supervisor a veces también tiene un panorama “local”


6- El U. Supervisor será el que nos brindará el contacto cotidiano primario, y definirá los requerimientos y las políticas de la empresa que su sistema debiera realizar.

- Usuarios Ejecutivos: En general no se involucran directamente con el proyecto de desarrollo del sistema. Este usuario suele estar 2 o 3 niveles arriba de la acción asociada con el proyecto.

1- Pueden proporcionar la iniciativa para el proyecto 2- No se encuentran en posición que los permita definir los requerimientos del sistema para

aquellos que lo están manejando cotidianamente. Como excepción tenemos un sistema de apoyo a las decisiones

3- Los U. Ejecutivos se preocupan más por los detalles estratégicos y las ganancias/pérdidas a largo plazo.

4- Los U. Ejecutivos se interesan más en el panorama global del sistema

Se encuentra que algunos usuarios se resisten a la idea de tener un nuevo sistema, ya que les preocupa la pérdida de su empleo, o porque temen estar encadenados a una terminal todo el día, sin contacto con otros humanos

Clasificación de los usuarios por nivel de experiencia - Usuario Amateur: Jamás ha visto una computadora y exclama que no entiende todo este asunto de

las computadoras. El problema con este usuario es que puede que encuentre difícil entender el lenguaje que el analista usa para describir las características, funciones y opciones que ofrece el nuevo sistema.

- Usuario Novato Presuntuoso: Alega conocer exactamente lo que quiere que el sistema haga y suele señalar los errores que se cometieron en el sistema anterior. Cree que sabe por haber estado en un par de proyectos anteriormente.

- Usuarios Expertos Administración: La principal interacción entre el analista y todos los administradores tiene que ver con los recursos que se asignarán al proyecto. De aquí que finalmente el analista hará un documento que diga: “El nuevo sistema deberá llevar a cabo las funciones X, Y y Z, deberá desarrollarse en K meses, con no más de J programadores y con un costo máximo de R pesos”. Existen 3 tipos de administradores Administradores Usuarios: Son administradores que están a cargo de varias personas en el área

operacional donde se va a implantar el nuevo sistema. Desean sistemas que produzcan una variedad de informes internos y de análisis a corto plazo.

Administradores de informática: Son las personas encargadas del proyecto en sí de sistemas, y los administradores de nivel superior encargados de la administración global y distribución de los recursos de todo el personal técnico de la organización de creación o desarrollo de sistemas

Administración General: Pudiera ser el presidente de la organización o el jefe de finanzas. Generalmente se interesan por los sistemas de planeación estratégica y de apoyo a decisiones.

Se debe tener en mente con los administradores: 1- Cuanto más alto nivel ocupen, menos probable es que sepan de la tecnología de las computadoras,

por lo que como analista, debe concentrarse en tratar de las características esenciales del sistema cuando esté hablando con ellos

2- Las metas y prioridades de la administración pudieran entrar en conflicto con las de los usuarios, principalmente operacionales y supervisores

3- A veces la administración no presta suficiente tiempo y/o recursos para que el sistema sea efectivo 4- Dentro de la administración pueden haber distintos puntos de vista acerca de un nuevo sistema 5- La administración a veces quiere apurar el proyecto


Auditores, Control de Calidad y Dpto. de Normas o Estándares: Se ha agrupado a estas personas en una sola categoría ya que su objetivo y perspectiva se parecen en general. El objetivo de este equipo es asegurar que su sistema se desarrolle de acuerdo con diversos estándares o normas externas (estándares de contabilidad, estándares de un dpto. de la organización, estándares del gobierno, etc.). Se debe prever:

1- A menudo no se involucran sino hasta el final en el proyecto. A estas alturas es difícil hacer cambios importantes en el sistema

2- A menudo están familiarizados con alguna notación o formato antiguos para documentación de requerimientos de sistemas (diagramas de flujo). Por eso es importante que los modelos que desarrolle sean comprensibles

3- Los miembros de este grupo a menudo se interesan más en la forma de presentación que por el contenido: pueden llegar a rechazar un documento si no está como ellos quieren.

Analista de Sistemas: Este es usted. Los papeles que desempeña son:

1- Arqueólogo y escribano: Descubrir detalles y documentar la política de un negocio que pudieran existir sólo como “tradiciones tribales”, transmitidas de generación en generación

2- Innovador 3- Mediador: Entre usuarios, administradores y otros participantes, los cuales a menudo están en

desacuerdo entre sí sobre el nuevo sistema. Aquí el analista puede imponer su punto de vista con el arte de la diplomacia y negociación

4- Jefe de Proyecto: Debido a la experiencia y a la tendencia natural.

El analista, además, debe tener facilidad en el manejo de personas, tener conocimientos de aplicación, habilidad en computación, y obviamente, necesita una mente lógica y organizada. Diseñadores de Sistemas: Es quien percibe los resultados del trabajo de análisis. La labor de él es transformar la petición, libre de consideraciones de tecnología, emanada de los requerimientos del usuario, en un diseño arquitectónico de alto nivel que servirá de base para el trabajo de los programadores. En muchos casos, el analista y diseñador son la misma persona, o el mismo grupo unificado de personas. Aún cuando son personas distintas, se deben mantener en contacto directo, provocando retroalimentación continua, ya que el analista tiene que ofrecer información detallada suficiente como para que el diseñador pueda elaborar un diseño tecnológicamente superior y el diseñador debe proveer suficiente información para que el analista pueda darse cuenta de si los requerimientos que el usuario está documentando son tecnológicamente posibles. Basándose en la inf. recibida, el analista posiblemente tendrá que negociar con el usuario para modificar otros requerimientos. Programadores: Se puede argumentar que no habría contacto entre un analista y un programador, debido a que la labor del analista se hace primero y se termina por completo antes de que comience la programación. Esto significa que muy probablemente el analista estará incluso asignado a otro proyecto cuando el programador intervenga en el actual. Sin embargo, es posible que haya un contacto entre programadores y analistas:

1- En los proyectos pequeños, analista, diseñador y programador suelen ser una sola persona 2- El analista a veces sirve de administrador de proyecto 3- El programador puede llegar a descubrir errores/ambigüedades en la propuesta de requerimientos

entregada por el analista 4- A veces se necesita mantenimiento de un sistema y nadie en la organización conoce los

requerimientos del sistema debido a que no son las mismas personas que definieron los


requerimientos del sistema anterior. Puede que el analista sea otro, y los que quedan del sistema anterior son los programadores.

Personal de Operaciones: Este personal va a definir las restricciones para el nuevo sistema: restricciones del tipo hardware, físicas, etc. Sin la aprobación del nuevo sistema por el personal de operaciones sólo se podrá construir un sistema independiente. Estos asuntos operacionales se documentan como parte de la tarea del análisis conocida como modelo de puesta en práctica o implantación del usuario.

GESTIÓN DE PROYECTOS DE SOFTWARE

El trabajo a través de proyectos es la forma habitual de actuación en el desarrollo de software. Un proyecto es un conjunto de etapas, actividades y tareas para alcanzar un objetivo que implica un trabajo no inmediato a un plazo relativamente largo. Precisamente es la división en trabajos más sencillos lo que permite al personal de proyecto dominar la complejidad del software que debe desarrollarse. Desarrollaremos a continuación la gestión de proyectos a través de sus distintos procesos: planificación, dirección, organización y control.

PLANIFICACIÓN

El objetivo es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal. Estas estimaciones se hacen dentro de un tiempo limitado y debería actualizarse a medida que progresa el proyecto. A) Ámbito del Software La primera actividad de la planificación del proyecto de software es determinar el ámbito del software. Se deben evaluar la función y el rendimiento que se asignarán al software. El ámbito del software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad. Las consideraciones de rendimiento abarcan los requisitos de tiempo de respuesta y de procesamiento. Las restricciones identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

1- Obtención de la información necesaria para el ámbito: La técnica utilizada es establecer una reunión o una entrevista preliminar. En la primera reunión entre un ingeniero de software y el cliente, ninguna persona sabe que decir o preguntar: ambos están preocupados por si lo que dicen es malinterpretado. Los 2 tienen expectativas diferentes: ambos quieren quitarse al otro de encima, pero quieren que todo salga bien. Sin embargo, se debe iniciar la comunicación. Se sugiere que el analista comience haciendo una serie de preguntas de contexto libre, es decir, que lleven a un entendimiento básico del problema.

El primer conjunto de cuestiones de contexto libre se centran en el cliente, en los objetivos globales y en los beneficios. Las preguntas siguientes permiten que el analista comprenda mejor el problema y que el cliente exprese sus percepciones sobre una solución. La última serie de preguntas se centra en la efectividad de la reunión. Estas preguntas (y otras) ayudarán a “romper el hielo” y a iniciar la comunicación esencial para establecer el ámbito del proyecto. Sin embargo, una reunión basada en preguntas y respuestas sólo se debería utilizar para el primer encuentro, reemplazándose posteriormente por un tipo de reunión que combine elementos de resolución de problemas, negociación y especificación.

Un grupo de investigadores independientes ha desarrollado un enfoque que alienta a la creación de un equipo compuesto de clientes y de desarrolladores que trabajen juntos para identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos.


2- Recursos: La segunda tarea de la planificación del desarrollo de software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de software. Hay 3 tipos de recursos que se debe verificar que estén disponibles: Recursos Humanos Recursos de software reutilizables: Hay 4 tipos. Componentes ya desarrollados, ya

experimentados, con experiencia parcial (requerirán una modificación sustancial) y componentes nuevos. A la hora de reutilizar se debe evaluar:

a) Si los componentes ya desarrollados cumplen los requisitos del proyecto, adquiéralos. El coste de la adquisición y de la integración serán casi siempre menores que el coste para desarrollar el software equivalente. Además, el riesgo es relativamente bajo.

b) Si se dispone de componentes ya experimentados, los riesgos asociados a la modificación e integración, se aceptan.

c) Si se dispone de componentes de experiencia parcial para el proyecto, su uso de debe analizar con detalle.

Recursos de Entorno: El entorno incorpora hardware y software. El hardware proporciona una plataforma con las herramientas software requeridas para producir los productos que son el resultado de una buena práctica de la ingeniería del software.

3- La Decisión Desarrollar-comprar: Se debe evaluar en un árbol de decisiones, especificando riesgos y costos. Dentro de esto, se debe destacar el outsourcing o subcontratación. Aquí, las actividades de ingeniería de software se contratan con un tercero quien hace el trabajo a bajo coste, asegurando una alta calidad. El trabajo de software llevado dentro de la compañía se reduce a una actividad de gestión de contratos. La decisión de contratar fuentes externas puede ser estratégica o táctica, aunque a menudo es financiera. En el lado positivo, están los ahorros de costos que se pueden lograr al reducir el nº de personas e instalaciones. En el lado negativo, una compañía puede perder el control sobre el software que necesita, es decir, se corre el riesgo de poner el destino de la compañía en manos de un tercero.

B) Plan de Proyecto Dentro del área de planificación de proyectos se deben cubrir 2 aspectos importantes: la realización de un plan de proyecto por parte del jefe de proyecto, y la gestión de compromisos. El director de proyecto es una persona que tiene la responsabilidad de planificar, controlar y dirigir las actividades del proyecto. Su primer cometido es el de realizar el plan de proyecto, un documento que describe los trabajos que se van a realizar y la forma en la que el director de proyecto va a dirigir su desarrollo. Independientemente del tamaño del proyecto, éste debe contener un plan que especifique aquello que hay que hacer, dónde y quién lo realizará. El plan de proyecto debe proporcionar un resumen del proyecto, ser orientado al cliente, actualizable, y permitir al director del proyecto y a los clientes supervisar el progreso del proyecto. El plan de proyecto debe incluir: resumen del proyecto, lista de hitos alcanzables, procedimientos y estándares que se van a aplicar, una especificación del proceso de revisión, un diagrama de descomposición del trabajo (WBS), una lista del personal del proyecto, una red de actividades, y presupuestos y calendarios para todas las actividades

Director de Proyecto Plan de proyecto Plan de Desarrollo Calendario

Una de las partes del plan de proyecto es la determinación del plan de desarrollo. Éste es una representación gráfica de todas las actividades del proyecto necesarias para producir el resultado final que permite al director de proyecto coordinar de una forma efectiva al equipo de desarrollo durante el transcurso del mismo. El calendario es dinámico, y sin él, el control del proyecto se hace casi imposible. El control de proyecto se basa en la supervisión periódica y en la comparación de los resultados con los previstos en el calendario. Para que un programa de tiempos sea efectivo, debe ser comprensible, suficientemente detallado, capaz de señalar las actividades críticas, ser flexible, fácilmente modificable,


basado en estimaciones de tiempos fidedignas, y compatible con los planes de otros proyectos que comparten los mismos recursos. Para desarrollar un calendario, es necesario realizar los siguientes pasos:

1- Definición de objetivos del proyecto: Consiste en especificar los objetivos en términos cuantificables. Un objetivo de proyecto es un enunciado que especifica los resultados que se deben conseguir. Estas declaraciones forman el fundamento de todo el proceso de planificación, incluyendo el desarrollo del calendario. Para que un objetivo de proyecto quede bien definido, debe ser: Asequible: El objetivo identifica una meta que puede conseguirse con unos tiempos y unas

restricciones dadas Definitivo: Especifica concretamente qué es lo que se debe lograr y en qué grado de detalle Cuantificable: Especifica un criterio de finalización De duración específica

2- Descomposición de las actividades: Una vez que se han determinado los objetivos, el director de proyecto puede producir un diagrama de descomposición del trabajo (WBS). Es una técnica que permite representar las actividades que hay que realizar a distinto nivel de detalle por medio de un diagrama de estructuras. Para ello, en la parte superior se representa la actividad más general y, a continuación, se subdivide en actividades más sencillas. Inicialmente se identifican los paquetes de trabajo. Luego, las tareas necesarias para producir esos paquetes. Estas tareas, a su vez, pueden descomponerse en subtareas. Además de mostrar las tareas, se indican las personas responsables de su finalización (no figura en la imagen). Con este diagrama, el director de proyecto aumenta su capacidad de supervisión.

3- Relación entre las actividades: Las actividades tienen que estar relacionadas, por lo que hay que determinar sus secuencias y dependencias. Para esto, se utilizan técnicas basadas en las redes de precedencia (como PERT), que permiten visualizar actividades críticas.

4- Estimación de los tiempos y costos de las actividades: Es necesario realizar una estimación del tiempo que debe transcurrir entre el comienzo y el final de la actividad. Estas estimaciones se basan en el tiempo requerido para finalizar una actividad, y deben incluir los retrasos normales

5- Reajuste del programa de tiempos a las restricciones del proyecto: Tiene como objetivos determinar la duración total del proyecto, identificar las actividades críticas y calcular las holguras de las actividades no-críticas.

6- Asignación de los recursos/Definición de la organización del equipo: Consiste en ajustar el calendario respecto a los recursos disponibles. Para suavizar la posible carga de trabajo, el director de proyecto debe fijarse en todas las actividades que tengan holguras, y ajustar las fechas. Si no se puede hacer esto, se deberá aumentar la duración de las actividades críticas.

7- Revisión del calendario: Para determinar si es o no realista. Se deben considerar los efectos de las revisiones técnicas y de gestión, los periodos vacacionales, los conflictos o las restricciones de recursos, etc. Debe asegurar que el calendario sea lo suficientemente flexible para acomodarse a retrasos no previstos


Técnicas a utilizar en la realización del calendario Diagrama de hitos: Es una tabla formada por 2 columnas: una en la que se señalan las

actividades, y otra donde se indican sus fechas de finalización. Tiene como ventaja la facilidad de uso y el mínimo coste de preparación. Sus desventajas son la incertidumbre sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interacciones entre ellas

Diagramas de Gantt: Es un diagrama de barras en forma de tabla, donde se hace una referencia cruzada entre las tareas (filas) y los tiempos de duración de las mismas (Columnas). Se utiliza en proyectos pequeños. No permiten representar las dependencias entre las actividades.

Programa de tiempos full-wall: En una sala de reunión se forma un cuadro en una pared en el que las líneas verticales representan semanas de trabajo, y las horizontales representan las actividades que debe hacer el equipo de proyecto. Cada actividad se escribe en 2 tarjetas, una de <inicio> y la otra de <final>. A cada miembro del equipo se le dan las tarjetas apropiadas y las clava en la pared en la semana de su elección. La disposición de tarjetas se modificará reiteradamente hasta que se hayan tratado todas las interacciones y restricciones de las actividades, y el calendario sea asequible.

Redes de precedencia (PERT y CPM): La red es un modelo gráfico que señala las relaciones secuenciales entre los sucesos clave en un proyecto. Pueden mostrar el camino crítico, que es la base para la planificación y el control.

C) Gestión de compromisos Es importante que los directivos tomen las decisiones y adopten compromisos después de que el grupo de software haya emitido sus opiniones sobre si los compromisos se consideran o no factibles. Si los directivos se deciden a adoptar un compromiso poco factible, deben estar preparados para un posible aumento de los costes o un retraso en la fecha de entrega.

ESTIMACIÓN DE COSTES Y PLAZOS

Ya que el software es un producto sin existencia física ni propia y cuyo coste principal reside en su desarrollo o diseño, es lógico que se asuma que el coste de su producción está dominado por los gastos de personal. Por eso, la principal unidad de medición de costo del proyecto suele ser el nº de salarios mensuales o anuales que deben pagarse. Los salarios suelen especificarse en personas-mes o personas-año. La estimación en los proyectos de software tiene dificultades particulares (es inexacta), ya que es habitual desarrollar un nuevo producto cada vez, empleando distintas técnicas y herramientas. Además, algunas razones como las presiones políticas en la empresa, dificultan la estimación. Para una buena previsión de costos, es necesario invertir en la implantación de mecanismos para la recogida de datos que sirvan para mejorar las predicciones futuras, así como el desarrollo de métodos apropiados de estimación. En cualquier caso, se pretende responder a: ¿Cuánto costará? y ¿Qué plazo de tiempo requerirá su desarrollo? Todos los métodos actuales dependen de la cantidad de información disponible. A medida que se avanza en el proyecto, se dispone de más información, lo cual precisa más la estimación. Por ello, la estimación siempre debe ser un proceso continuo, con constantes refinamientos y mejoras.

SEGUIMIENTO Y SUPERVISIÓN DEL PROYECTO SOFTWARE

Los objetivos que se pretenden conseguir con el seguimiento y supervisión son: 1- Comparar los resultados actuales con los planes previstos Se han de desarrollar estándares que establezcan las condiciones o medidas que deben cumplirse cuando se realicen correctamente las diferentes tareas del proyecto; establecer sistemas de supervisión y de informes; y medir los resultados.


El reto es utilizar las herramientas y las técnicas disponibles en forma efectiva, es decir, gestionar el esfuerzo de tal forma que el personal acepte los objetivos que debe cumplir dentro de unos tiempos y recursos dados. Algunos criterios a tener en cuenta para controlar los proyectos son:

- Planificación detallada del proyecto - Descomponer el proyecto global en actividades y tareas (con WBS) - Definir los resultados entregables - Definir los hitos a realizar - Compromiso del personal - Seguimiento del proyecto - Medición de resultados - Revisiones regulares

2- Tomar acciones correctivas cuando existan desviaciones significativas, y Acordar compromisos con el personal afectado por las acciones correctivas

Las acciones correctivas se realizan y gestionan cuando los resultados reales se desvían significativamente de los planes. Aquí, los grupos y los individuos afectados llegan al acuerdo de los cambios en los compromisos. En general, las acciones correctivas pueden ser: añadir personal, reducir el alcance o el contenido de una entrega, y alargar/retrasar el calendario.

GESTIÓN DE RIESGOS DEL SOFTWARE

Podríamos definir riesgo como cualquier elemento potencial que provoca resultados insatisfactorios en un proyecto. Debido al gran porcentaje de proyectos cancelados, entregados fuera de plazo, presupuestos excedidos, problemas operativos, conflictos con usuarios, etc., surge el tratamiento de los riesgos software como un factor importante en la realización de un proyecto. Las áreas típicas de riesgo que debe tratar un director de proyecto son las siguientes:

Riesgos estratégicos: Relacionados con la estrategia de la organización, pérdidas, beneficios, inversiones, etc. Ej: Pérdida de mercado, déficit

Riesgos comerciales: Problemas relacionados con la venta del proyecto, el seguimiento del cliente, el precio y las posibles actualizaciones. Ej: esfuerzo de venta desperdiciado, pérdida del cliente, vender por debajo del precio real

Riesgos contractuales y financieros: Relacionados con los términos contractuales negociados antes de la firma del contrato, como penalizaciones, niveles de calidad, calendarios de pagos, etc. Ej: Pago de daños e intereses

Riesgos de Gestión: Relacionados con la organización de los proyectos, recursos, equipos, calendarios, subcontratistas, estimaciones, etc.

Riesgos de Proyecto: Causados por los aspectos técnicos del software: especificación, diseño, realización, integración y validación.

Riesgos de Explotación: Se refieren a fallos ocurridos durante el uso del software, los cuales pueden causar daños significativos, y eventualmente pueden ser peligrosos para la vida de las personas. Ej: Fallo del sistema que provoca accidente

Riesgos de Mantenimiento: Causados principalmente por sobrecostos en mantenimiento correctivo, preventivo y soporte

Una vez identificados los riesgos que son significativos en el proyecto es necesario realizar un seguimiento y un control de éstos, y así dichos riesgos se reducen hasta niveles aceptables para el director del proyecto.


UNIDAD 3



Formas de Captura de Requisitos

Planeación Tipos Registro Participantes Usa Escalas Administración

1- Entrevistas 2- JAD

3- Cuestionarios 4- Observación Del tomador de Decisiones 5- Muestreo

1- Leer el material a fondo 2- Establecer objetivos de la entrevista 3- Decidir a quién entrevistar 4- Preparar al entrevistado 5- Decidir sobre

5.1- Tipos de Preguntas (Abiertas, Cerradas, Averiguaciones)

5.2- Tipos de Estructuras (Pirámide, Embudo, Rombo)

Estructurada No Estructurada

Grabador Notas

Patrocinador Ejecutivo (Líder) 8 a 12 Usuarios Analista en Sistemas 1 o 2 Observadores 1 escribano

Tipos

Evaluación Problemas

1- Nominal 2- Ordinal 3- De intervalo 4- De relación

Validez Confiabilidad Consistencia

Lenidad Tendencia central Efecto de Halo

1- Reunir a todos los interlocutores involucrados 2- Manejar cuestionarios personalmente 3- Interlocutores manejan los cuestionarios 4- Cuestionarios por correo

Comportamiento

Lenguaje Corporal

Ambiente físico Diseño Inf. Buscada

Muestreo de tiempos Muestreo de eventos Pares de adjetivos y categorías Guión del analista

STROBE Elementos (7) Estrategias (4)

1- Det. Los datos a ser recolectados 2- Det. La población a ser muestrada 3- Seleccionar tipo de muestra (De conveniencia,

Intencionadas, Aleatorias Simples/Complejas) 4- Determinar tamaño de muestra

Datos Impresos Cuantitativa Cualitativa Datos Archivados


Captura de Requisitos

como Casos de uso

1- Artefactos

2- Trabajadores y responsabilidades

3- Flujo de trabajo

Modelo de C.U (Actores y C.U) Descripción de Arquitectura Glosario Prototipo de Interfaz con el Usuario

Modelo C.U A. Sistemas Actor

Glosario

Especificador de C.U C.U

Diseñador de Prototipo de Interfaz de Usuario Interfaz

Arquitecto Descripción de Arquitectura

1- Encontrar actores y Casos de Uso (En la unidad siguiente se desarrolla)

2- Priorizar Casos de uso 3- Detallar Casos de Uso 4- Prototipar la interfaz de Usuario


UNIDAD 3:

ENTREVISTAS

Antes de que entreviste a alguien, primero debe entrevistarse usted mismo. Necesita pensar a fondo la entrevista antes de ir a ella. Visualizar por qué está yendo, qué preguntará y qué es lo que constituirá una entrevista satisfactoria ante sus ojos. La otra mitad de esto es el individuo al que entrevistará. Debe anticipar cómo hacer que la entrevista sea satisfactoria también para él. Tipo de Información Buscada Una entrevista para la recolección de información es una conversación dirigida con un propósito específico que usa un formato de preguntas y respuestas. En la entrevista se quiere obtener la opinión del entrevistado y sus sentimientos acerca del estado actual del sistema, los objetivos de la organización, los personales y los procedimientos informales. Las opiniones del entrevistado pueden ser más importantes y más reveladoras que los hechos. Además, se debe tratar de capturar los sentimientos del entrevistado. Recuerde que el entrevistado conoce la organización mejor que usted. Usted puede comprender la cultura de la organización más a fondo escuchando los sentimientos de quienes responden. También se puede determinar el grado de optimismo existente. Los objetivos son información importante que puede ser recogida de las entrevistas. Los objetivos proyectan el futuro de la organización. Trate de encontrar tantos objetivos como sea posible a partir de las entrevistas. Tal vez no sea capaz de determinar los objetivos por medio de ningún otro método de recopilación de datos. En la entrevista, se necesita dar confianza y comprensión rápidamente, pero al mismo tiempo, se debe mantener el control de la entrevista. Planeación de la entrevista

1- Leer el material a fondo acerca del entrevistado y su organización. Se debe prestar mucha atención en el lenguaje que usan los miembros de la organización. El objetivo es no perder el tiempo en la entrevista

2- Establecer los objetivos de la entrevista: Consiste en determinar las áreas de la empresa que se van a relevar, y en que profundidad cada una. Estas áreas incluyen fuentes de información, formatos de información, frecuencia de toma de decisiones, cualidades de la información y estilo en la toma de decisiones

3- Decidir a quién entrevistar: Se deben incluir personas clave de todos los niveles que serán afectados por el sistema en alguna forma

4- Preparar al entrevistado: Avisándole con anticipación y permitiendo que el entrevistado tenga tiempo de pensar acerca de la entrevista. Las entrevistas deben durar entre 45 minutos y una hora, a lo sumo.

5- Decidir sobre: 5.1- Tipos de preguntas: Preguntas Abiertas: Las opciones de respuesta del entrevistado pueden ser de 2 palabras o 2

párrafos: están abiertas. Los beneficios, entre otros: pone confortable al entrevistado, permite al entrevistador conocer el lenguaje del entrevistado, permite más espontaneidad e interés. Las desventajas: mucho detalle relevante, pérdida de control en la entrevista.

Preguntas Cerradas: Las respuestas posibles son un nº finito. Los beneficios: se ahorra tiempo, se facilita la comparación de entrevistas, se mantiene el control, los datos son relevantes. Las desventajas: aburridas, pocos detalles, se pierde la relación armoniosa.

Averiguaciones: ¿Por qué? ¿Puede darme un ejemplo? Explique, etc. El objetivo es ir más allá de la respuesta inicial para aclarar, expandir un punto de vista. Las averiguaciones pueden ser de preguntas abiertas o cerradas.


Fallas en las preguntas: o Elusión de preguntas conducentes o conductoras (preguntas con respuesta predeterminada) o Elusión de preguntas dobles (2 preguntas en una)

5.2- Tipos de Estructura Pirámide: El entrevistador comienza con preguntas muy detalladas, cerradas, y va

expandiendo luego los temas, permitiendo preguntas abiertas y respuestas más generalizadas. Se utiliza cuando el entrevistador necesita ambientarse en el tema, o cuando el entrevistado se resiste a entrar en tema

Embudo: Tiene un enfoque deductivo. Va de lo más general (abiertas) a lo más particular (cerradas). Es útil cuando el entrevistado se siente interesado acerca del tema y necesita libertad para expresar sus emociones

Rombo: Es una combinación de las anteriores. Empieza de forma muy específica, luego examina temas generales, y por último se llega a una conclusión muy específica. Tiene como ventaja que conserva el interés y la atención del entrevistado. La desventaja es que lleva más tiempo.

Estructurada No estructurada Estructurada No

estructurada Evaluación Fácil Difícil Flexibilidad Pequeño Grande Tiempo requerido

Bajo Alto Control del entrevistador

Alto Bajo

Entrenamiento requerido

Limitado Muy necesario Precisión Alto Bajo

Permite espontaneidad

Pequeño Mucha Confiabilidad Alto Bajo

Perspicacia del entrevistado

Muy Pequeño Mucha oportunidad Amplitud y profundidad

Bajo Alto

Registro de la entrevista Se realiza sobre los aspectos más importantes de la entrevista. El que se tomen notas o se use una grabadora de cinta depende, en parte, de a quién se está entrevistando y de lo que se hará con la información una vez que haya pasado la entrevista.

Grabadora de cinta: Tiene como ventajas que el registro es exacto, libera al entrevistador para escuchar y responder más rápidamente, permite mejor contacto visual, y permite una reproducción exacta de la entrevista para otros miembros del equipo. Tiene como desventajas que hace posiblemente inquietante la entrevista, la dificultad de buscar diálogos determinados en la cinta, y el relevamiento de datos.

Toma de Notas: Se utiliza cuando el entrevistado se rehúsa a la petición de la grabación en cinta. Tiene como ventajas que mantiene alerta al entrevistador, ayuda a recordar preguntas importantes, demuestra preparación e interés del entrevistador. Como desventajas, tenemos la pérdida de contacto visual y del hilo de la conversación, y un exceso de atención sobre los hechos.

Antes y durante la entrevista Se debe vestir adecuadamente, ya que las respuestas del entrevistado están orientadas por su percepción inicial. Debe llegar temprano a la entrevista. Salude de mano y con firmeza al entrevistado, para establecer credibilidad y confianza. Recuérdele al entrevistado su nombre, y describa una vez más brevemente el motivo por el cual está ahí y el por qué escogió entrevistarlo. En cuanto se siente, tome inmediatamente la grabadora y/o su cuaderno de notas. Dígale al entrevistado lo que hará con los datos que recolecte y vuelva a afirmarle la confidencialidad. Al comenzar la entrevista, trate de captar el vocabulario y jerga. Mencione el tipo de detalle que le gustaría recibir en las respuestas. De vez en cuando, regrese algunas de las respuestas del entrevistado por


medio de parafraseo o sumarización, para volver a confirmar que se comprendió lo que quería decir. Si en cualquier otro momento no está seguro, inmediatamente pida definiciones o aclaraciones. Al final de la entrevista, pregunte “¿Hay algo de lo que no hayamos hablado y que usted siente que es importante que yo sepa?”. Resuma y haga saber sus impresiones generales. Infórmele al entrevistado acerca de los pasos siguientes a tomar y qué es lo que harán a continuación con usted y otros miembros del equipo. Fije citas futuras para entrevistas de seguimiento, déle las gracias al entrevistado por haberle dado su tiempo y despídase con un apretón de mano. Tan pronto como sea posible se debe realizar la escritura del reporte de la entrevista.

Diseño conjunto de aplicaciones (JAD)

Inevitablemente experimentará situaciones donde las entrevistas persona a persona no parecen ser tan útiles como uno quisiera. Un enfoque alternativo a la entrevista de usuarios uno en uno, es el llamado Diseño conjunto de Aplicaciones (JAD). La motivación para el uso del JAD es reducir el tiempo (y por lo tanto el costo) requerido por las entrevistas personales, mejorar la calidad de los resultados de la valoración de requerimientos de información y la creación de más identificación del usuario con el nuevo sistema de información a consecuencia del proceso participativo. Además, con el JAD, se logran los requerimientos de análisis y diseño de la interfaz de usuario conjuntamente con los usuarios en un grupo. Condiciones que dan soporte al uso de JAD

1- Los grupos de usuarios están impacientes y quieren algo nuevo, y no una solución estándar a un problema típico

2- La cultura organizacional da soporte a los comportamientos de la solución de problemas en conjunto entre varios niveles de empleados

3- Los analistas predicen que la cantidad de ideas generadas por medio de entrevistas persona a persona no será tan abundante con la cantidad de ideas posibles del ejercicio de un grupo amplio

4- El flujo de trabajo organizacional permite la ausencia de personas importantes durante un bloque de tiempo de 2 a 4 días

Quienes están involucrados Las sesiones de JAD incluyen una gran variedad de participantes, analistas, ejecutivos, etc. Que contribuirán con sus diferentes experiencias y aptitudes a las sesiones. Un patrocinador ejecutivo: una persona de alto nivel que abra y cierre las sesiones de JAD. De

preferencia, seleccione a un ejecutivo del grupo de usuarios que tenga algún tipo de autoridad sobre las gentes del sistema de información que están trabajando en el proyecto. Esta persona será un símbolo visible e importante de la disposición organizacional al proyecto de sistema.

8 a 12 usuarios de cualquier rango. Al menos un analista de sistemas de información, pero tomando un papel pasivo, escuchando lo que

dicen los usuarios y lo que requieren. Adicionalmente, se querrá dar una opinión de experto acerca de cualquier costo desproporcionado o soluciones propuestas durante la sesión.

El líder de la sesión debe ser alguien que tenga habilidades excelentes de comunicación para facilitar las interacciones adecuadas.

1 o 2 observadores que sean analistas o expertos técnicos de otras áreas funcionales para proporcionar explicaciones técnicas y consejos al grupo.

Un escribano para escribir formalmente todo lo que se hace. Asegúrese que el escribano publique el registro de los resultados de JAD rápidamente.

Planificación de la sesión de JAD Se deben definir el alcance del proyecto, seleccionar los participantes, y el líder.


Se recomienda que las sesiones se realicen de 2 a 4 días en un lugar aparte, fuera de la organización, en ambientes agradables. La idea es minimizar las distracciones y responsabilidades diarias del trabajo regular de los participantes. Dé la importancia adecuada a la creación de confort para los participantes. Disponga de suficiente comida y bebidas durante los cortes planeados. Calendarice las sesiones de JAD cuando todos los participantes puedan estar dispuestos a asistir. Esto es crítico para el éxito de las sesiones. Considere la realización de una reunión de orientación, con duración de medio día, una semana antes aproximadamente, para que los que estén involucrados sepan lo que se espera de ellos. Esto permite que usted se mueva rápidamente y actúe con confianza una vez que ha sido convenida la reunión actual. Logro de un análisis estructurado de las actividades del Proyecto Siendo el analista involucrado con las sesiones JAD, usted debe recibir las notas del escribano y preparar un documento de las especificaciones, basado en lo que sucedió en la reunión. Presente los objetivos de administración, así como el alcance y las fronteras del proyecto. Beneficios potenciales del uso de JAD en vez de entrevistas tradicionales

1. Ahorro de tiempo sobre las entrevistas uno a uno 2. Posibilidad de una propiedad mejorada de sistema de información, ya que el JAD involucra a los

usuarios desde el principio en el proyecto de sistema, con lo cual tratan la retroalimentación seriamente

3. Desarrollo creativo de los diseños: hay una “lluvia de ideas” Desventajas potenciales del uso de JAD

1. Requiere la dedicación de un gran bloque de tiempo por parte de los 18/20 participantes 2. Cuando la preparación de las sesiones JAD es inadecuada o cuando el reporte de seguimiento y la

documentación es incompleta 3. Las habilidades organizacionales necesarias y la cultura organizacional pueden no estar

desarrolladas lo suficiente para el esfuerzo concertado que se requiere para ser productivo en un ambiente JAD

CUESTIONARIOS

Los cuestionarios permiten que los analistas estudien actitudes, creencias, comportamientos y características de varias personas principales en la organización que pueden ser afectadas por los sistemas actual y propuesto. Las actitudes son lo que la gente de la organización dice que quiere, las creencias son lo que la gente piensa que es, el comportamiento es lo que hacen los miembros de la organización y las características son propiedades de las personas o cosas. Mediante el uso de cuestionarios el analista puede estar buscando cuantificar lo que ha encontrado en las entrevistas. En forma inversa, los cuestionarios pueden ser usados para investigar a una gran muestra de usuarios de sistemas, para tratar de encontrar problemas o recoger cosas importantes antes de que las entrevistas sean realizadas. El desarrollo de un cuestionario útil requiere gran tiempo de planeación. Algunos lineamientos que ayudarán a decidir si es adecuado el uso de cuestionarios son:

1- Las personas a preguntarles están dispersas 2- En el proyecto de sistema está involucrada gran cantidad de personas y tiene sentido saber qué

proporción de un grupo dado aprueba o desaprueba una característica particular del sistema propuesto

3- Se está haciendo un estudio exploratorio y se quiere medir la opinión general antes de darle al proyecto de sistema una dirección específica


4- Se desea asegurar que cualquier problema con el sistema actual esté identificado y atacado en las entrevistas de averiguación

Una vez decidido a utilizar cuestionario, se puede comenzar a formular preguntas. En los cuestionarios, a diferencia de las entrevistas, es muy difícil refinar o aclarar preguntas dudosas. Lo que significa que las preguntas deben ser muy claras, el flujo de preguntas coherente, las preguntas del interlocutor anticipadas y la administración del cuestionario planeada a detalle. Recordemos que había 2 tipos de preguntas:

Preguntas Abiertas: En un cuestionario, se deben anticipar el tipo de respuesta que se va a obtener. Es importante que las respuestas que reciba sean capaces de una interpretación correcta. Este tipo de preguntas es adecuado 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. También se utilizan en situaciones exploratorias

Preguntas Cerradas: Deben ser usadas cuando el analista de sistemas sea capaz de listar efectivamente todas las respuestas posibles a la pregunta y cuando todas las respuestas listadas sean mutuamente excluyentes, para que la selección de una impida la selección de cualquier otra. Se deben usar para investigar a una gran muestra de personas, debido a la cantidad de datos que se obtendrán.

Cabe desatacar que es muy importante la selección de palabras, ya que los interlocutores aprecian los esfuerzos de alguien que se preocupa por escribir un cuestionario que refleje su propio uso del lenguaje. Para confirmar si el lenguaje usado es el adecuado, puede probarlo sobre un grupo piloto. Uso de Escalas El escalamiento es el proceso de asignar números u otros símbolos a un atributo o característica con objeto de medir ese atributo o característica. Las escalas son frecuentemente arbitrarias y pueden no ser únicas. Se utilizan escalas para:

Medir las actitudes o características de quienes responden el cuestionario Hacer que los interlocutores juzguen los temas del cuestionario

Las escalas son medibles, y hay 4 formas diferentes para la medición: 1- Escala Nominal: Son la forma más débil de medición. Sólo se pueden obtener totales. Ej: ¿Qué

programa usa más? 1=Proc. Texto; 2=P. Cálculos; 3=BD 2- Escala Ordinal: Permiten clasificación, implica ordenamiento de rango. Son útiles debido a que

una clase es mayor o menor que otra. Ej: El personal de secretaría es: 1. Extremadamente útil; 2. Muy útil; 3.No muy útil; 4.Inútil

3- Escala de Intervalo: Los intervalos entre c/u de los nº son iguales. Debido a esto, se pueden realizar operaciones matemáticas sobre los datos. Ej: ¿Qué tan útil es el soporte dado por el personal de Laboratorio? Inútil Extremadamente útil 1 2 3 4 5

4- Escala de Relación: No permite jerarquización, aunque dan una idea general. Ej: ¿Qué tantas horas usa la computadora? 0 2 4 6 8

Validez y Confiabilidad: Hay dos mediciones de desempeño en la construcción de escalas: validez y confiabilidad. Validez es el grado con el cual la pregunta mide lo que el analista trata de medir. Ej: Si el objetivo del cuestionario es determinar si la org. se encuentra lista para un cambio, ¿mide eso las preguntas?

Confiabilidad mide consistencia: Si el cuestionario fue administrado una vez, y luego nuevamente bajo las mismas condiciones se obtuvieron los mismos resultados, se dice que el instrumento tiene consistencia externa. Si el cuestionario contiene subpartes y estas tienen resultados equivalentes, se dice que tiene consistencia interna. Tanto la consistencia interna como la externa son importantes.


Construcción de escalas Se presentan 3 problemas cuando se construyen escalas:

1- Lenidad: Es cuando los interlocutores califican a la ligera. Se puede evitar moviendo la categoría “promedio” a la izquierda o derecha del centro

2- Tendencia Central: Los interlocutores califican todo como promedio. Se puede arreglar creando escalas con más puntos, achicando diferencias, etc.

3- Efecto de halo: Cuando la impresión formada en una pregunta se transporta a la siguiente pregunta Diseño y Administración del cuestionario Se debe poner mucha atención a esto para evitar que los interlocutores lo contesten a desgano o simplemente no lo contesten. Un cuestionario relevante y bien diseñado puede ayudar a superar algo de esta resistencia a responder. Algunas consideraciones:

Dejar bastante espacio en blanco Dejar suficiente espacio para las respuestas Pedir al interlocutor que encierre con un círculo las respuestas Usar objetivos que ayuden a determinar el formato Ser consistente en estilo Guardar un orden en las preguntas Colocar las preguntas importantes para los interlocutores al principio Agrupar conceptos de contenido similar Emplear las tendencias asociativas de los interlocutores Poner primero los conceptos menos controvertidos

Una vez diseñado el cuestionario, se deben determinar a los interlocutores. Hay que asegurarse de que haya suficientes interlocutores para permitir una muestra razonable en caso de que se pierdan cuestionarios o que sean llenados incorrectamente, y deban ser desechados. Existen 4 formas de administrar el cuestionario:

1- Reunir a todos los interlocutores involucrados a la vez: No hay tiempo de espera y no se pierden cuestionarios. Sin embargo, tiene como desventaja la presión del grupo

2- Manejar personalmente cuestionarios en blanco y recoger los llenos: Requiere mucho tiempo y suele haber escepticismo en las respuestas.

3- Permitir a los interlocutores que administren el cuestionario por sí mismos y los depositen en una caja: Tiene como ventaja que las personas se sienten en el anonimato, pero sin embargo pueden perderse cuestionarios

4- Enviar por correo los cuestionarios, con instrucciones para el retorno: Tiene muy baja tasa de respuesta

OBSERVACIÓN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE OFICINA

El analista examina los elementos físicos del espacio de trabajo del tomador para ver su influencia sobre el comportamiento del mismo. Además, mediante la observación de los elementos físicos sobre los que el tomador de decisiones tiene control, el analista puede determinar el mensaje que está enviando este tomador de decisiones, y la influencia que provoca sobre las demás personas de la organización. Observación del comportamiento del tomador de decisiones La observación también ayuda a confirmar o negar e invertir lo que ha sido encontrado por medio de entrevistas, cuestionarios y otros métodos. La observación debe ser estructurada y sistemática si es que se quiere que los hallazgos sean interpretables.


Para que el analista de sistemas aprecie adecuadamente la forma en que los gerentes caracterizan su trabajo se usan las entrevistas y cuestionarios. Sin embargo, la observación permite que el analista vea de primera mano cómo los gerentes recopilan, procesan, comparten y usan la información para hacer que el trabajo se realice. Los pasos para la observación de las actividades típicas de un gerente son:

1- Decidir lo que va a ser observado 2- Decidir a qué nivel de concreción van a ser observadas las actividades 3- Crear categorías que capturen adecuadamente las actividades principales 4- Preparar escalas, listas de verificación y otros materiales adecuados 5- Decidir cuando observar

Muestreo de tiempo Muestreo de eventos Def. Visitas aleatorias frecuentes en

intervalos cortos de tiempo Visitas programadas en eventos especiales.

Ventajas - Elimina la tendencia con la aleatoriedad de observaciones

- Permite una vista representativa de actividades frecuentes

- Permite la observación de comportamientos conforme suceden

- Permite la observación de un evento considerado importante

Desventajas - Recolecta datos en forma fragmentada que no da tiempo para que se desarrolle una decisión

- Se pierden decisiones importantes poco frecuentes

- Se lleva gran cantidad de tiempo del analista

- Se pierde una muestra representativa de decisiones frecuentes

Observación del Lenguaje corporal del tomador de decisiones Hay 2 formas de realizar este análisis:

1- Pares de Adjetivos y Categorías: Se listan categorías de la siguiente forma: decidido/indeciso, confiado/desconfiado, etc. y se va eligiendo la correcta

2- El guión del analista: Se listan en una tabla las tareas que realiza el tomador de decisiones. Puede agregarse la frecuencia, total, porcentaje, etc.

Observación del ambiente físico Más frecuentemente, esto significa examinar sistemáticamente las oficinas de los tomadores de decisiones, debido a que las oficinas constituyen su lugar de trabajo principal. Los tomadores de decisiones influencian y a la vez son influenciados por sus ambientes físicos. La observación estructurada del ambiente de trabajo del tomador de decisiones se realiza mediante el método STROBE. Este método se integra por 7 elementos, que pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y comparte información, así como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo. Los 7 elementos son:

1- Ubicación de la oficina respecto a las demás oficinas: Dan un panorama de la accesibilidad hacia otras personas del tomador de decisiones

2- Ubicación del escritorio: Dan una idea de cómo consideran su poder 3- Equipo de oficina fijo: (Archiveros, libreros, etc). Permiten saber con que grado valora la

información 4- Propiedades: (calculadoras, pc, etc.). Da idea sobre el grado de delegación 5- Revistas y periódicos del negocio: Permiten saber si se apoya en información interna o externa

para tomar las decisiones 6- Iluminación y color de la oficina: Indican la manera que recopila información 7- Vestimenta usada por los tomadores de decisiones: Dan credibilidad


Mediante el uso de STROBE el analista puede obtener una mejor comprensión sobre la manera en que los gerentes recopilan, procesan, almacenan y usan información. Los analistas pueden usar el enfoque STROBE utilizando distintas estrategias, que varían desde muy estructuradas hasta sin estructurar. Estas estrategias son:

1- Análisis de fotografías: Se fotografía el ambiente y luego se analiza. Tiene como ventajas que se puede hacer referencia a las fotografías repetidamente; permite al analista enfocarse en otras cosas; reducen limitaciones de espacio/tiempo; la fotografía puede proporcionar detalles que fácilmente se descuidan. Como desventajas, está el decidir qué fotografiar; y que el tomador de decisiones puede reubicar elementos ante la visita del analista

2- Enfoque de la lista de verificación / Escala Likert: Son escalas de 1 a 5 puntos en relación con 7 características del tomador de decisiones que fueron observables por elementos físicos en los ambientes organizacionales

3- Listas anecdóticas (con símbolos): Es una lista de verificación donde se comparan hechos dichos por los miembros de la organización, contra lo que dice el tomador de decisiones. Según se confirme/niegue/invierta lo que se dijo, se coloca un símbolo determinado en la característica y se determina si se debe averiguar más.

4- Comparación de la observación/narrativa: Es el método menos estructurado. Se examina el ambiente y se compara con las narraciones, y mediante el resultado de la comparación se determina el investigar más o no.

MUESTREO

El muestreo es el proceso de seleccionar sistemáticamente elementos representativos de una población. Cuando estos elementos seleccionados son examinados de cerca, se supone que el análisis revelará información útil acerca de la población como un todo. El analista de sistemas tiene que tomar una decisión sobre 2 puntos. Primero, hay muchos reportes, formas, documentos, que han sido generados por los miembros de la organización ¿A cuáles de éstos debe prestar atención el analista de sistemas y cuáles debe ignorar? Segundo, gran cantidad de empleados pueden ser afectados por el sistema de información propuesto. ¿A qué personas debe entrevistar el analista? El muestreo es necesario debido a:

Los costos contenidos La agilización en la recolección de datos La mejora de la efectividad en la recolección de datos La reducción de la ascendencia

Diseño del muestreo

1- Determinar los datos a ser recolectados o descritos: El analista debe identificar las variables, atributos y conceptos de datos asociados que necesitan ser recolectados en la muestra. Se deben considerar los objetivos del estudio, así como el método de recolección de datos a ser usado.

2- Determinar la población a ser muestrada: 3- Seleccionar el tipo de muestra: Hay 4 tipos principales de muestras: Muestras de conveniencia: Son muestras no restringidas y no probables. La muestra es la más

fácil que se podría recolectar, pero al mismo tiempo es la menos confiable. Ej: el analista pone una noticia en el boletín de la compañía pidiendo a cualquier interesado en el nuevo reporte de desempeño de ventas que asista a una reunión el 2/4/08 a las 1:00pm.

Muestras intencionadas: Un analista puede seleccionar a un grupo de individuos que parecen tener conocimiento e interés en el nuevo sistema de información. Es moderadamente confiable

Muestras aleatorias simples: El analista obtiene una lista numerada de la población, y elige una cierta cantidad al azar.


Muestras aleatorias complejas: Se pueden elegir 3 enfoques - Muestreo Sistemático: Ej: Elegir entrevistar a cada enésima persona de una lista de

empleados de la compañía - Muestreo Estratificado: - Muestreo Aglomerado:

4- Decidir el tamaño de la muestra: El tamaño de la muestra depende frecuentemente del costo involucrado en el tiempo requerido por el analista de sistemas, o hasta el tiempo disponible de las personas de la organización

Tipos de información buscada en la investigación

Conforme el analista de sistemas trabaja para comprender a la organización y a sus requerimientos de información, llega a ser importante el examen de diferentes tipos de datos impresos que proporcionan información que no se encuentra disponible por ningún otro método de recopilación de datos. Los datos impresos revelan dónde ha estado la organización y hacia donde creen sus miembros que está yendo. El analista necesita examinar los datos en forma: Cuantitativa: Reportes usados para la toma de decisiones, reportes de desempeño, registros,

formas para la captura de datos. Mediante éste análisis se puede descubrir que los datos no fluyen como se pretende, que hay cuellos de botella, que se duplica innecesariamente el trabajo, etc.

Cualitativa: Este análisis es crítico para la comprensión de la manera en que los miembros de la organización engranan en el proceso o en la organización. Los documentos cualitativos incluyen memorándums (reflejan la política), consignas en tableros de noticias y en áreas de trabajo (reflejan los valores/cultura organizacional), manuales de procedimientos y manuales de política. Un lineamiento a seguir para iniciar la interpretación de los documentos es:

1- Examinar los documentos en busca de claves o metáforas de lineamientos, ya que pueden ser persuasivas en la organización, así como para comprender cómo puede ser caracterizado metafóricamente el nuevo sistema

2- Buscar referencia a mentalidad “nosotros vs ellos” en documentos, a fin de conocer de antemano posibles problemas de cooperación del personal

3- Listar términos que caractericen el bien y el mal, y aparezcan repetidamente en los documentos, para saber qué es bueno y qué malo en el negocio

4- Reconocer el sentido del humor en caso de estar presente, a fin de determinar la moral/cultura de una persona de la organización

Otra fuente de información, además de los recién mencionados datos impresos, son los datos archivados.

Ventajas del uso de datos archivados

Desventajas del uso de datos archivados

Ya fueron pagados por alguien más

Los datos no son cambiados, debido a que el productor no está consciente de que está siendo estudiado

Existe incertidumbre sobre si los datos son un subconjunto de los datos originales

Los registros que sobreviven pueden no ser los más importantes

Pueden tener ascendencias, ya que alguien decidió originalmente lo que había que archivar

Es difícil obtener nuevos datos de muestras equivalentes


UN PROCESO DIRIGIDO POR CASOS DE USO (CU)

El objetivo del Proceso Unificado es guiar a los desarrolladores en la implementación y distribución eficiente de sistemas que se ajusten a las necesidades de los clientes. La eficiencia se mide en términos de coste, calidad y tiempo de desarrollo. El paso desde la determinación de las necesidades del cliente hasta la implementación no es trivial. En primer lugar, las necesidades del cliente no son fáciles de distinguir. Esto nos obliga a que tengamos algún modo de capturar las necesidades del usuario de forma que puedan comunicarse fácilmente a todas las personas implicadas en el proyecto. Después, debemos ser capaces de diseñar una implementación funcional que se ajuste a esas necesidades. Por último, debemos verificar que las necesidades del cliente se han cumplido mediante la prueba del sistema. Debido a esta complejidad, el proceso se describe como una serie de flujos de trabajo que construyen el sistema gradualmente.

Los desarrolladores comienzan capturando los requisitos del cliente en la forma de casos de uso en el modelo de casos de uso. Después analizan y diseñan el sistema para cumplir los casos de uso, creando en primer lugar un modelo de análisis, después uno de diseño y después otro de implementación, el cual incluye todo el código, es decir, los componentes. Por último, los desarrolladores preparan un modelo de prueba que les permite verificar que el sistema proporciona la funcionalidad descrita en los casos de uso. El modelo de implementación es el más formal, mientras que el modelo de casos de uso es el menos formal, en el sentido de poder ser interpretado por la máquina. Los casos de uso son mucho más que una herramienta para capturar requisitos. Dirigen el proceso de desarrollo en su totalidad. Los casos de uso son la entrada fundamental cuando se identifican y especifican clases, subsistemas e interfaces, cuando se identifican y especializan casos de prueba y cuando se planifican las iteraciones del desarrollo y la integración del sistema. Para cada iteración, nos guían a través del conjunto completo de flujos de trabajo, desde la captura de requisitos, pasando por el análisis, diseño e implementación, hasta la prueba, enlazando estos diferentes flujos de trabajo. Desarrollo dirigido por casos de uso en pocas palabras La captura de requisitos tiene 2 objetivos: encontrar los verdaderos requisitos y representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Normalmente, un sistema tiene muchos tipos de usuarios. Cada tipo de usuario se representa por un actor. Los actores utilizan el sistema interactuando con los casos de uso. Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer algún resultado de valor para un actor. El modelo de casos de uso está compuesto por todos los actores y todos los casos de uso de un sistema. Durante el análisis y el diseño, el modelo de casos de uso se transforma en un modelo de diseño a través de un modelo de análisis.


El modelo de análisis es una especificación detallada de los requisitos y funciona como primera aproximación del modelo de diseño, aunque es un modelo con entidad propia. Los desarrolladores lo utilizan para comprender de manera más precisa los casos de uso descritos en el flujo de trabajo de los requisitos, refinándolos en forma de colaboraciones entre clasificaciones conceptuales. El modelo de análisis también se utiliza para crear un sistema robusto y flexible que emplea la reutilización de componentes de manera considerable. El modelo de análisis puede ser transitorio y sobrevivir sólo al primer par de iteraciones. Sin embargo, en algunos casos, especialmente para sistemas grandes y complejos, el modelo de análisis debe mantenerse durante toda la vida del sistema. ¿Por qué casos de uso? Para capturar los requisitos que aportan valor añadido al usuario: Si comenzamos pensando en

un conjunto de buenas funciones del sistema sin pensar en los casos de uso que emplean los usuarios concretos, será difícil decir si estas funciones son importantes o incluso si son buenas. Los mejores casos de uso son aquellos que añaden el mayor valor al negocio que implanta el sistema. Un caso de uso que aporta un valor negativo o que permite hacer al usuario cosas que no debería poder hacer, no es un caso de uso. Además, los casos de uso son intuitivos, se pueden redactar en lenguaje natural la mayor parte del tiempo, lo que hace más fácil la lectura de los casos de uso y la propuesta de cambios. El modelo de casos de uso se utiliza para conseguir un acuerdo con los usuarios y clientes sobre qué debería hacer el sistema para los usuarios. Podemos pensar en el modelo de casos de uso como una especificación completa de todas las formas posibles de utilizar el sistema. Esta especificación puede utilizarse como parte del contrato con el cliente.

Para dirigir el proceso: El que un proyecto de desarrollo esté dirigido por los casos de uso significa que progresa a través de una serie de flujos de trabajo que se inician a partir de los casos de uso. Los casos de uso ayudan a los desarrolladores a encontrar las clases. Las clases se recogen de las descripciones de los casos de uso a medida que las leen los desarrolladores, buscando clases que sean adecuadas para la realización de los casos de uso. Los casos de uso ayudan a desarrollar interfaces de usuario que hacen más fácil a los usuarios el desempeño de sus tareas. Más adelante, las realizaciones de los casos de uso se prueban para verificar que las instancias de las clases pueden llevar a cabo los casos de uso. Los casos de uso no sólo inician un proceso de desarrollo, sino que lo enlazan. Los casos de uso ayudan a los jefes de proyecto a planificar, asignar y controlar muchas de las tareas que los desarrolladores realizan. Los casos de uso son un importante mecanismo para dar soporte a la trazabilidad a través de todos los modelos. La trazabilidad entre los casos de uso y el resto de los elementos del modelo hace más fácil mantener la integridad del sistema y conservar actualizado al sistema en su conjunto cuando tenemos requisitos cambiantes.

Para idear la arquitectura y más….: Los casos de uso nos ayudan a llevar a cabo el desarrollo. En otras palabras, en cada iteración se identifican e implementan unos cuantos casos de uso. Mediante la selección del conjunto correcto de casos de uso para llevarlos a cabo durante las primeras iteraciones, podemos implementar un sistema con una arquitectura estable, que pueda utilizarse en muchos ciclos de desarrollo subsiguientes. Los casos de uso también se utilizan como punto de partida para escribir el manual de usuario. Ya que cada caso de uso describe una forma de utilizar el sistema, son el punto de partida ideal para explicar como puede el usuario interactuar con el sistema.


La captura de casos de uso El modelo de casos de uso representa los requisitos funcionales La mayoría de los sistemas tienen muchos tipos de usuarios. Cada tipo de usuario se representa mediante un actor. Los actores utilizan el sistema al interactuar con los casos de uso. Un diagrama de casos de uso describe parte del modelo de casos de uso y muestra un conjunto de casos de uso y actores con una asociación entre cada par actor/caso de uso que interactúan.

Los actores son el entorno del sistema No todos los actores representan a personas. Pueden ser actores otros sistemas o hardware externo que interactuará con el sistema. Cada actor asume un conjunto coherente de papeles cuando interactúa con el sistema. Un usuario físico puede actuar como uno o varios actores desempeñando los papeles de estos actores en su interacción con el sistema. Los actores se comunican con el sistema mediante el envío y recepción de mensajes hacia y desde el sistema según éste lleva a cabo los casos de uso Los casos de uso especifican el sistema Definiremos un caso de uso de manera precisa como sigue: Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede llevar a cabo, y que producen un resultado observable de valor para un actor concreto. Identificamos los casos de uso examinando como los usuarios necesitan utilizar el sistema para realizar su trabajo. Cada uno de esos modos de utilizar el sistema que añaden valor al usuario es un caso de uso candidato. Estos candidatos se ampliarán, cambiarán, se dividirán en casos de uso más pequeños o se integrarán en casos de uso más completos. El modelo de casos de uso está casi terminado cuando recoge todos los requisitos funcionales correctamente de un modo que puedan comprender los clientes, usuarios y desarrolladores. La secuencia de acciones realizada por un caso de uso durante su operación (es decir, una instancia del caso de uso) es un camino específico a través del caso de uso. Ejemplo: El caso de uso sacar dinero La secuencia de acciones para un camino a través de este caso de uso es:

- El cliente del banco se identifica - El cliente del banco elige de que cuenta sacar dinero y especifica qué cantidad - El sistema deduce la cantidad de la cuenta y entrega el dinero

Los casos de uso también se utilizan como “contenedores” de los requisitos no funcionales, tales como los requisitos de rendimiento, disponibilidad, exactitud y seguridad que son específicos de un caso de uso. Captura de requisitos como casos de uso El esfuerzo principal en la fase de requisitos es desarrollar un modelo del sistema que se va a construir, y la utilización de los casos de uso es una forma adecuada de crear ese modelo. Esto es debido a que los requisitos funcionales se estructuran de forma natural mediante casos de uso, y a que la mayoría de los


otros requisitos no funcionales son específicos de un solo caso de uso, y pueden tratarse en el contexto de ese caso de uso. Los requisitos no funcionales restantes, aquellos que son comunes para muchos o para todos los casos de uso, se mantienen en un documento aparte y se denominan requisitos adicionales. El papel clave de los casos de uso en la dirección del resto del trabajo de desarrollo ha sido un motivo importante para su aceptación en la mayoría de los métodos de la ingeniería moderna del software. Vamos a describir el flujo de trabajo de los requisitos en 3 pasos:

1- Los artefactos creados en el flujo de trabajo de los requisitos 2- Los trabajadores participantes en el flujo de trabajo de los requisitos 3- El flujo de trabajo de captura de requisitos, incluyendo cada actividad en más detalle

1- Artefactos Los artefactos fundamentales que se utilizan en la captura de requisitos son el modelo de casos de uso, que incluye los casos de uso y los actores, la descripción de la arquitectura, el glosario y el prototipo de interfaz con el usuario.

Modelo de casos de uso El modelo de casos de uso puede hacerse bastante grande y difícil de digerir de un solo mordisco, de forma que es necesario algún medio de abordarlo en trozos más pequeños. UML nos permite presentar el modelo en diagramas que muestran los actores y los casos de uso desde diferentes puntos de vista y con diferentes propósitos.

Actor El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada uno de estos se representa mediante uno o más actores. Una vez que hemos identificado todos los actores del sistema, tenemos identificado el entorno externo al sistema. Los actores suelen corresponderse con trabajadores en un negocio. Cada trabajador se lo dota con un caso de uso del sistema para cada uno de sus roles. Ese caso de uso proporciona un valor al actor cuando representa el papel del trabajador.

Ejemplo: Actor El sistema pagos y facturación interactúa con un tipo de usuario que empleará el sistema para pedir bienes, confirmar pedidos, pagar facturas y demás. Este tipo de usuario se representa mediante el actor comprador

Casos de uso Cada forma en que los actores usan el sistema se representa con un caso de uso. De manera más precisa, un caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia. Por lo tanto, un caso de uso es una especificación. Especifica el comportamiento de “cosas” dinámicas, en este caso, instancias de los casos de uso. Una instancia de caso de uso es la realización (o ejecución) de un caso de uso. Cuando se lleva a cabo una instancia de un caso de uso, esta interactúa con instancias de actores, y ejecuta una secuencia de acciones según se especifica en el caso de uso. Esta secuencia se especifica en un diagrama de estados o un diagrama de actividad; es un camino a lo largo de un caso de uso. Puede haber muchos caminos, y muchos de ellos pueden ser muy parecidos. Estas son alternativas de la secuencia de acciones para el caso de uso. La mayoría de las veces es una instancia de un actor la que invoca a la instancia del caso de uso, pero también puede ser un evento interno al sistema el que invoque a la instancia, como cuando un temporizador programado interno al sistema se dispara. Las instancias de los casos de uso no interactúan con otras instancias de casos de uso. El único tipo de interacciones en el modelo de casos de uso tiene lugar entre instancias de actores e instancias de casos de uso. El motivo es que queremos que el modelo de casos de uso sea simple e intuitivo para permitir discusiones fructíferas con los usuarios finales y otros interesados, sin quedar atrapados en los detalles. Consideramos atómicas las instancias de casos de uso, es decir, cada una de ellas se ejecuta por completo o no se ejecuta nada. El considerar los casos de uso como atómicos no tiene nada que ver con que haya un gestor de transacciones subyacente que se encargue de


los conflictos. Lo hacemos solamente para garantizar que podamos leer y comprender el modelo de casos de uso. El flujo de sucesos especifica lo que el sistema hace cuando se lleva a cabo el caso de uso especificado. También especifica cómo interactúa el sistema con los actores cuando se lleva a cabo el caso de uso. Llamamos requisitos especiales a todos los requisitos no funcionales sobre el caso de uso. 2- Trabajadores y Responsabilidades

3- Flujo de Trabajo En la sección anterior, describimos la captura de requisitos en términos estáticos. Ahora vamos a utilizar un diagrama de actividad para describir el comportamiento dinámico. El diagrama utiliza calles para mostrar qué trabajadores ejecutan qué actividades; cada actividad (representada por ruedas dentadas) se sitúa en el mismo campo que el trabajador que la ejecuta. Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos. Describimos los flujos de trabajo como una secuencia de actividades que están ordenadas, así que una actividad produce una salida que sirve de entrada para la siguiente actividad. No obstante, el diagrama de actividad presenta solamente el flujo lógico. En el mundo real, no es necesario trabajar mediante actividades en secuencia. De hecho, podemos trabajar por múltiples vías que producen un resultado final equivalente.

Una actividad puede ser retomada muchas veces, y cada una de éstas puede acarrear la ejecución de una sola fracción de la actividad. Por tanto, los caminos de una actividad a otra, ilustran tan solo la secuencia lógica de actividades utilizando los resultados de la ejecución de una actividad como entrada para ejecutar otra.


Los resultados de la primera iteración a través de éste flujo de trabajo consiste en una primera versión del modelo de casos de uso, los casos de uso y cualquier prototipo de interfaz de usuario asociado. Los resultados de cualquier iteración subsiguiente consistirán entonces en nuevas versiones de estos artefactos. Las distintas actividades en el modelado de casos de uso adoptan formas diferentes en diferentes fases del proyecto. Las actividades que típicamente aparecen en la iteración de elaboración son:

Actividad 1: Encontrar actores y casos de uso: Identificamos los actores y casos de uso para: - Delimitar el sistema de su entorno - Esbozar quién y qué (actores) interactuarán con el sistema, y qué funcionalidad (casos de uso)

se espera del sistema - Capturar y definir un glosario de términos comunes esenciales para la creación de

descripciones detalladas de las funcionalidades del sistema La identificación de actores y casos de uso es responsabilidad del analista de sistemas.

Pero el analista de sistemas no puede hacer este trabajo sólo. El analista requiere entradas de un equipo que incluye al cliente, los usuarios y otros analistas que participan en talleres de modelado dirigidos por el analista de sistemas. Esta actividad consta de 4 pasos, a realizar en cualquier orden:

- Encontrar los actores - Encontrar los casos de uso - Describir brevemente cada caso de uso - Describir el modelo de casos de uso completo y preparar el glosario

El resultado de esta actividad es una nueva versión del modelo de casos de uso con actores y casos de usos nuevos o cambiados.

Encontrar los actores: Cuando tenemos un modelo del negocio del cual partir, encontrar los actores resulta sencillo. El analista de sistemas puede asignar un actor a cada actor del negocio (es decir, a cada cliente del negocio) que utilizará la información del sistema. En otro caso, con o sin un modelo del dominio, el analista del sistema, junto con el cliente, identifica los usuarios e intenta organizarlos en categorías representadas por actores. En ambos casos, debemos identificar los actores que representan sistemas externos y los actores para el mantenimiento y operación del sistema. Hay 2 criterios útiles a la hora de elegir los candidatos a actores: primero, debería ser posible identificar al menos un usuario que pueda representar al actor candidato. Esto nos ayudará a encontrar solamente a los actores relevantes, y eliminará a los actores que sólo son fantasmas.


Segundo, debería existir una coincidencia mínima entre los roles que desempeñan las instancias de los diferentes actores en lección con el sistema. No queremos dos o más actores que tengan en esencia los mismos roles. Si esto ocurre, debemos intentar combinar los papeles en un conjunto de roles que asignaremos exclusivamente a un actor. El analista de sistemas da nombre a los actores y describe brevemente los papeles de cada actor y para qué utiliza el sistema el actor. Encontrar nombres relevantes para los actores es importante para comunicar la semántica deseada. La descripción breve de cada actor debe esbozar sus necesidades y responsabilidades. El resultado de éste paso es una nueva versión del artefacto modelo de casos de uso con un conjunto de actores actualizado, cada uno con una breve descripción. Estos atcores brevemente descritos pueden utilizarse ahora como punto de partida para encontrar los casos de uso. Encontrar los casos de uso: El analista de sistemas va repasando los actores uno por uno y proponiendo los casos de uso para cada actor. El actor necesitará normalmente casos de uso para soportar su trabajo de creación, cambio, rastreo, eliminación o estudio de los objetos del negocio. El actor también puede informar al sistema acerca de algunos sucesos externos u otras formas de representación. Puede haber también actores adicionales que ejecuten el inicio del sistema, su mantenimiento o su terminación. Algunos de los candidatos no llegarán a ser casos de uso por sí mismos, en cambio, serán parte de otros casos de uso. Elegimos un nombre para cada caso de uso de forma que nos haga pensar en la secuencia de acciones concreta que añade valor a un actor. El nombre de un caso de uso a menudo comienza con un verbo, y debe reflejar cuál es el objetivo de la interacción entre el actor y el sistema. Ej: Pagar factura, Solicitar Bienes Los casos de uso y la arquitectura del sistema se desarrollan mediante iteraciones. Una vez que ya tenemos la arquitectura, los nuevos casos de uso que capturemos deben ser adaptados a la arquitectura existente. Los casos de uso que no se ajusten a la arquitectura elegida, deben ser modificados para que encajen mejor con la arquitectura (podemos también mejorar la arquitectura para acomodar los nuevos casos de uso). No obstante, se pueden requerir cambios más drásticos… Describir brevemente cada caso de uso: Consiste en describir aisladamente un caso de uso Descripción del modelo de casos de uso en su totalidad: No hay una regla estricta sobre lo que se debe incluir en el diagrama. De hecho, elegimos el conjunto de diagramas que describan más claramente el sistema. El modelo de casos de uso requiere ser un modelo plano, como el que se describe aquí. También puede organizarse en conjuntos de casos de uso llamados paquetes de casos de uso. La salida de este paso es también una descripción general del modelo de casos de uso. Esta descripción explica el modelo de casos de uso como un todo. Describe cómo interactúan los actores y casos de uso y cómo se relacionan entre sí los casos de uso. Cuando la descripción del modelo de casos de uso esté preparada, dejamos que dé el visto bueno del modelo de casos de uso la gente que no forma parte del equipo de desarrollo (es decir, clientes y usuarios), convocando una revisión informal para determinar si: Se han capturado como casos de uso todos los requisitos funcionales necesarios La secuencia de acciones es correcta, completa y comprensible para cada caso de uso Se identifica algún caso de uso que no proporcione valor. Si es así, ese caso de uso debería

reconsiderarse


Actividad 2: Priorizar casos de uso: El propósito de esta actividad es determinar cuáles casos de uso son necesarios para el desarrollo en las primeras iteraciones, y cuáles pueden dejarse para más tarde. Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso. Después, esta vista se revisa con el jefe de proyecto, y se utiliza como entrada al hacer la planificación de lo que debe desarrollarse dentro de una iteración. Hay que darse cuenta de que esta planificación también necesita la consideración de otros aspectos no técnicos, como los aspectos económicos o del negocio del sistema que va a ser desarrollado. La vista de la arquitectura del modelo de casos de uso debe mostrar los casos de uso significativos desde el punto de vista de la arquitectura.

Actividad 3: Detallar un caso de uso: El objetivo principal de detallar cada caso de uso es

describir su flujo de sucesos en detalle, incluyendo cómo comienza, termina e interactúan con los actores. El especificador de casos de uso detalla paso a paso la descripción de cada caso de uso en una especificación precisa de la secuencia de acciones. Cada especificador de casos de uso debe trabajar estrechamente con los usuarios reales de los casos de uso. El resultado de esta actividad es la descripción detallada de un caso de uso en particular, en forma de texto y diagramas. En esta sección veremos: Estructuración de la descripción de casos de uso: Ya hemos mencionado que un caso de uso define los estados que las instancias de los casos de uso pueden tener y la posible transición entre estos estados. Cada transición es una secuencia de acciones que se ejecutan en una instancia del caso de uso cuando ésta se dispara por efecto de un suceso, como podría ser un mensaje. El gráfico de transición de estados puede llegar a ser bastante intrincado. Por ello, debemos describir la posible transición de estados de manera simple y precisa.

Una técnica probada es elegir un camino básico completo desde el estado de inicio al estado final, y describir ese camino en una sección de la descripción. Entonces podemos describir en secciones separadas el resto de los caminos como caminos alternativos o desviaciones del camino básico. Hay que recordar que el objetivo es hacer una descripción precisa pero fácil de leer. Con cualquier técnica que elijamos, tendremos que describir todas las alternativas, sino no habremos especificado un caso de uso. Las alternativas, desviaciones o excepciones del camino básico pueden ocurrir por muchas razones:

- El actor puede elegir entre diferentes caminos en el caso de uso - Si está implicado más de un actor en el caso de uso - El sistema puede detectar entradas erróneas de los actores - Algunos recursos del sistema pueden tener un mal funcionamiento y así impedir que el

sistema realice de forma adecuada su trabajo El camino básico debe ser el camino “normal”, esto es, el que el usuario percibe como el que más habitualmente va a seguir y aquel que proporciona el valor más obvio al actor.

¿Qué incluir en una descripción de caso de uso? - Cómo y cuando comienza el caso de uso - El orden requerido en el que las acciones se deben ejecutar - Cómo y cuado terminan los casos de uso - Los posibles estados finales


- Los caminos de ejecución que no están permitidos, es decir, que el usuario no puede tomar - Las descripciones de caminos alternativos que están incluidos con la descripción del camino

básico - Las descripciones de los caminos alternativos que han sido extraídas de la descripción del

camino básico - La interacción del sistema con los actores y que cambios producen - La utilización de objetos, valores y recursos del sistema. Dicho de otra forma, hemos descrito

la secuencia de acciones en la utilización de un caso de uso, y hemos asignado valores a los atributos de un caso de uso

- Debemos describir explícitamente qué hace el sistema. Debemos ser capaces de separar las responsabilidades del sistema y las de los actores

Hemos hablado a menudo sobre los requisitos funcionales y cómo representarlos mediante casos de uso, pero también necesitamos especificar los requisitos no funcionales. Estos requisitos se asocian como requisitos especiales con el caso de uso en cuestión Si el sistema interactúa con algunos otros sistemas (actores no humanos), es necesario especificar esta interacción. Esto se debe hacer en las primeras iteraciones, durante la fase de elaboración, debido a que la realización de comunicaciones entre sistemas tiene habitualmente influencia en la arquitectura. La descripción de casos de uso se da por finalizada cuando se consideran las descripciones comprensibles, correctas, completas y consistentes. Solamente los clientes y los usuarios pueden verificar si los casos de uso son los correctos.

Actividad 4: Prototipar la interfaz de usuario: El objetivo de esta actividad es construir un prototipo de interfaz de usuario. Necesitamos diseñar la interfaz de usuario que permita al usuario llevar a cabo los casos de uso de manera eficiente. Lo haremos en varios pasos. Comenzamos con los casos de uso e intentamos discernir qué se necesita de las interfaces de usuario para habilitar los casos de uso para cada actor. Esto es, hacemos un diseño lógico de la interfaz de usuario. Después, creamos el diseño físico de la interfaz de usuario y desarrollamos prototipos que ilustren cómo pueden utilizar el sistema los usuarios para ejecutar los casos de uso. Mediante la especificación de qué se necesita antes de decidir cómo realizar la interfaz de usuario, llegamos a comprender las necesidades antes de intentar realizarlas. El resultado final de esta actividad es un conjunto de esquemas de interfaces de usuario y prototipos de interfaces de usuario que especifican la apariencia de esas interfaces de cara a los actores más importantes.


LA VISTA DE LOS CASOS DE USO

En el modelo, la ejecución de cada caso de uso es independiente de las demás, aunque una implementación de casos de uso puede crear dependencias implícitas entre ellas, debido a los objetos compartidos. Cada caso de uso representa una pieza ortogonal de la funcionalidad, cuya ejecución se puede mezclar con la ejecución de otros casos de uso. Cuando se implementan, los casos de uso son realizados mediante colaboraciones entre clases del sistema. Una clase puede participar en múltiples colaboraciones y, por lo tanto, en múltiples casos de uso. Cada caso de uso se debe corresponder con las clases que implementan un sistema. El comportamiento del caso de uso se corresponde con las transiciones y operaciones de las clases. Ya que una clase puede desempeñar roles múltiples en la implementación de un sistema, puede por lo tanto realizar porciones de múltiples casos de uso. La implementación de un caso de uso se puede modelar como un conjunto de una o más colaboraciones. Una colaboración es una realización de un caso de uso. Un caso de uso se dibuja como una elipse con su nombre dentro o debajo de ella. Se conecta por líneas con trazo fino continuo con los actores que se comunican con el. Un caso de uso puede incorporar simplemente el comportamiento de otros casos de uso como fragmentos de su propio comportamiento. Esto se llama relación de inclusión. Un caso de uso se puede también definir por una extensión incremental de un caso de uso base. Esto se llama relación de extensión. Puede haber varias extensiones del mismo caso de uso base, que puedan ser aplicadas conjuntamente. Las extensiones a un caso de uso base se agregan a su semántica; que es el caso de uso base instanciado, no los casos de uso de la extensión.


UNIDAD 4



Ingeniería de Requerimientos

Gestión de Requerim.

Captura de Requisitos: 1-Encontrar Actores y CU: > Flujo de Trabajo Arquetípico

1- Enumerar Requisitos candidatos

2- Comprender Contexto del Sistema

3- Capturar Requisitos Funcionales 4- Capturar Requisitos No Funcionales

Mod. Dominio Diagrama Clases

Mod. Negocio Mod. Objetos y CU

Proceso

1- Estudios de Viabilidad 2- Obtención, Análisis y Especificación de Req. 3- Validación de Requerimientos

1- Descubrimiento Puntos Vista 2- Clasificación y organización 3- Ordenación por prioridades y negociación

Documentación

De Interlocutores Indirectos Del Dominio

Verificaciones de Técnicas

Validez Consistencia Completitud Realismo Verificabilidad

Revisiones de Requerimientos Construcción de Prototipos Generación de casos de prueba

Clasificación de Requerimientos Planificación

Duraderos Volátiles 1- Identificación de Requerimientos 2- Proceso de Gestión de Cambios

2.1. Análisis del Problema y especificación del cambio 2.2. Análisis del cambio y cálculo de costos 2.3. Implementación del cambio

3- Políticas de Rastreo 4- Ayuda de Herramientas CASE

Cambiantes Emergentes Consecuentes De compatibilidad


UNIDAD 4: CAPTURA DE REQUISITOS

Llamamos captura de requisitos al proceso de averiguar normalmente en circunstancias difíciles, lo que se debe construir. De hecho es tan difícil que todavía no es poco común para los equipos de proyecto comenzar a escribir el código (lo cual es bastante fácil) antes de que se haya firmado simplemente lo que se supone que debe hacer el código (lo cual es difícil de determinar). La captura de requisitos es complicada ya que con frecuencia, los usuarios no saben cuáles son los requisitos, ni tampoco cómo especificarlos de una forma precisa. La aproximación tradicional a este problema ha sido asignar intermediarios (analistas) para obtener una lista de requisitos de cada usuario con la esperanza de que el analista fuese capaz de tener una visión en conjunto y de componer una especificación de requisitos completa, correcta y consistente. Pero incluso con la ayuda de los analistas, los usuarios no comprendían del todo lo que el sistema software debería hacer hasta que el sistema estaba casi terminado. El sistema debería proporcionar valor al negocio que lo utiliza y a sus clientes. Con frecuencia, es difícil comprender qué es este valor, y a veces es imposible hacer que el sistema lo proporcione. Aún con estas ideas, la captura de requisitos sigue siendo difícil, y la industria lleva buscando un proceso bueno, sistemático para llevarla a cabo desde hace mucho tiempo. El objeto del flujo de trabajo de los requisitos El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una descripción de los requisitos del sistema suficientemente buena como para que pueda llegarse a un acuerdo entre el cliente y los desarrolladores sobre qué debe y qué no debe hacer el sistema. Un reto fundamental para conseguirlo es que el cliente sea capaz de leer y comprender el resultado de la captura de requisitos. Para alcanzar este objetivo debemos utilizar el lenguaje del cliente para describir estos resultados. Visión general de la captura de requisitos Existen muchos puntos de partida (en cuanto a los requisitos conocidos) para el desarrollo del sistema. Pueden ser tan dispares como una vaga noción, o tan específicos como una especificación detallada de los requisitos. Esto sugiere que los analistas sean capaces de adaptar sus técnicas a la captura de requisitos en cada situación. Aparte de las diferencias entre los puntos de partida, ciertos pasos son factibles en la mayoría de los casos, lo que nos permite sugerir un flujo de trabajo arquetípico:

1- Enumerar los requisitos candidatos: Durante la vida del sistema, los clientes, usuarios, analistas y desarrolladores aparecen con muy buenas ideas que podrían convertirse en verdaderos requisitos. Mantenemos una lista de estas ideas, que consideramos como un conjunto de requisitos candidatos que podemos decidir implementar o no en una versión futura del sistema.

2- Comprender el contexto del sistema: Para capturar los requisitos correctos y para construir el sistema correcto, los desarrolladores clave requieren un firme conocimiento del contexto en el que se emplaza el sistema. Hay 2 formas de expresar el contexto de un sistema en forma utilizable para los desarrolladores de software: el modelo de dominio y el de negocio. El modelo de dominio se aplica cuando el analista es experto en ese tipo de sistema, con lo que evita gran parte de la captura de requisitos, realizando afirmaciones sobre determinados aspectos del sistema. El modelo de negocio, es un supraconjunto del modelo de dominio, e incluye la captura de requisitos en su totalidad

3- Capturar requisitos funcionales: Se basa en los casos de uso. Estos casos de uso capturan tanto los requisitos funcionales como los no funcionales, que son específicos de cada caso de uso. Recordemos que para el usuario, un caso de uso es un modo de utilizar el sistema. En consecuencia, si los analistas pueden describir todos los casos de uso que necesita el usuario, entonces saben lo que debe hacer el sistema.


4- Capturar requisitos no funcionales: Especifican propiedades del sistema, como restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad y fiabilidad. Algunos requisitos no funcionales son más genéricos y no pueden relacionarse con un caso de uso concreto o con una clase concreta del mundo real. Estos deberían gestionarse aparte en una lista de requisitos adicionales.

Trabajo a Realizar Artefactos Resultantes

Enumerar requisitos candidatos Lista de características Comprender el contexto del sistema Modelo del Dominio o de Negocio Capturar los requisitos funcionales Modelo de casos de uso

Capturar los requisitos no funcionales Requisitos adicionales o casos de uso concretos (para requisitos específicos de un caso de uso)

El papel de los requisitos en el ciclo de vida del software

El modelo de casos de uso se desarrolla a lo largo de varios incrementos de desarrollo, donde las iteraciones añadirán nuevos casos de uso y/o añadirán detalle a las descripciones de los casos de uso existentes. Comprensión del contexto del sistema El Modelo del Dominio

Un modelo de dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos de dominio representan las “cosas” que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos de dominio o clases pueden obtenerse de una especificación de requisitos o mediante la entrevista con los expertos del dominio. Las clases de dominio aparecen en 3 formas típicas:

Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas y contratos

Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviación enemiga, misiles y trayectorias

Sucesos que ocurrirán o que han ocurrido, como la llegada de un avión, su salida, la hora de la comida, etc.

El modelo de dominio se describe mediante diagramas de UML (especialmente diagramas de clases. Estos diagramas muestran a los clientes, usuarios, revisores y a otros desarrolladores las clases del dominio y cómo se relacionan unas con otras mediante asociaciones. El objetivo del modelado del dominio es comprender y describir las clases más importantes dentro del contexto del sistema. Las restantes clases candidatas que los analistas pueden extraer del dominio se guardan como definiciones en un glosario de términos, que se utilizan en el desarrollo de modelos de casos de uso y análisis. Se usan:

Al describir los casos de uso y al diseñar la interfaz del usuario Para sugerir clases internas al sistema en desarrollo durante el análisis

Sin embargo, existe una forma más sistemática aún de identificar los casos de uso y encontrar las clases dentro del sistema: desarrollar un modelo del negocio. Como veremos, un modelo del dominio es en realidad un caso especial de un modelo del negocio más completo. Por tanto, desarrollar un modelo de negocio es una alternativa más potente que desarrollar un modelo del dominio.


Comprensión del contexto del sistema El Modelo del Negocio

El modelado del negocio es una técnica para comprender los procesos de negocio de la organización. El objetivo es identificar los casos de uso del software y las entidades de negocio relevantes que el software debe soportar, de forma que podríamos modelar sólo lo necesario para comprender el contexto. El resultado de esta actividad es un modelo del dominio derivado de la comprensión del funcionamiento del “sistema negocio” que lo rodea. El modelado de negocio está soportado por 2 tipos de modelos de UML: Modelo de casos de uso: Describe los procesos de negocio de una empresa en términos de casos de

uso y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. El modelo de casos de uso del negocio presenta un sistema desde la perspectiva de su uso, y esquematiza cómo proporciona valor a sus usuarios. Este modelo de describe mediante diagramas de casos de uso.

Modelo de objetos: Es un modelo interno a un negocio. Describe cómo cada caso de uso del negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y de unidades de trabajo. Cada realización de un caso de uso del negocio puede mostrarse en diagramas de interacción y diagramas de actividad. Una entidad del negocio representa algo, como una factura, que los trabajadores toman, inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio. Una unidad de trabajo es un conjunto de esas entidades que conforma un todo reconocible para un usuario final. Las entidades del negocio y las unidades de trabajo se utilizan para representar los mismos tipos de conceptos que las clases del dominio. Cada trabajador, entidad del negocio y unidad de trabajo pueden participar en la realización de más de un caso de uso del negocio.

Un modelo del negocio, se desarrolla por lo tanto en 2 pasos: 1- Los modeladores del negocio deben confeccionar un modelo de casos de uso del negocio que

identifique los actores del negocio y los casos de uso del negocio que utilicen los actores 2- Los modeladores deben desarrollar un modelo de objetos del negocio compuesto por trabajadores,

entidades del negocio, y unidades de trabajo que juntos realizan los casos de uso del negocio En primer lugar, el analista identifica un actor por cada trabajador y por cada actor del negocio que se convertirá en usuario del sistema de información. Cada trabajador que vaya a ser usuario del sistema de información requerirá un soporte por parte del mismo. Para cada trabajador, identificamos todas las realizaciones de casos de uso del negocio diferentes en las que participa. Una vez que hemos encontrado todos los roles de un trabajador o de un actor del negocio, uno por cada caso de uso del negocio en el que participa, podemos encontrar los casos de uso de los actores del sistema en el sistema de información. Por cada papel de un trabajador o un actor del negocio, necesitamos un caso de uso para el actor del sistema correspondiente. Por tanto, la manera más directa de identificar un conjunto tentativo de casos de uso es crear un caso de uso para el actor correspondiente a cada rol de cada trabajador y de cada actor del negocio. Como resultado, obtendremos para cada caso de uso del negocio un caso de uso por cada trabajador y por cada actor del sistema. Los analistas deben también decidir cuántas de las tareas de los trabajadores o de los actores del sistema deberían automatizarse mediante sistemas de información y reorganizar los casos de uso para que se ajusten mejor a las necesidades de los actores.


Similitudes entre Modelo de Negocio y de Dominio Podemos pensar el Modelado de dominio como una variante simplificada del modelado del negocio, en el cual nos centramos sólo en las ”cosas”, es decir, las clases del dominio o entidades del negocio que necesitan usar los trabajadores. Por tanto, las clases del dominio equivaldrían a mencionar las entidades del negocio. Diferencias entre Modelo de Negocio y de Dominio

- Las clases del dominio se obtienen de la base del conocimiento de unos pocos expertos del dominio, o posiblemente del conocimiento asociado con sistemas similares al que estamos desarrollando. Las entidades del negocio, por otro lado, se derivan a partir de los clientes del negocio, identificando los casos de uso del negocio, y después buscando las entidades. Estas 2 técnicas normalmente acaban con conjuntos diferentes de clases, asociaciones, atributos y operaciones. La técnica de modelado del dominio puede hacer la traza de las clases hasta la experiencia de los expertos del dominio. La técnica de modelado del negocio puede hacer la traza de la necesidad de cada elemento del modelo hasta los clientes

- Las clases del dominio tienen atributos y normalmente ninguna o muy pocas operaciones. No es así para las entidades del negocio

- Los trabajadores identificados en el modelado del negocio se utilizan como punto de partida para derivar un primer conjunto de actores y casos de uso para el sistema de información en construcción. Esto nos permite hacer la traza de cada caso de uso del sistema de información, a través de los trabajadores y los casos de uso del negocio hasta los clientes del negocio .Además, puede hacerse la traza de cada caso de uso hasta los componentes que implementan el sistema. Por tanto, podemos concluir que el modelado del negocio nos permite hacer el seguimiento de las necesidades del cliente a lo largo del camino completo a través de procesos de negocio, trabajadores, y casos de uso, hasta el código del software. Sin embargo, cuando se utiliza solamente un modelo del dominio, no hay una forma evidente de hacer la traza entre el modelo del dominio y los casos de uso del sistema.

PROCESOS DE LA INGENIERÍA DE REQUERIMIENTOS La meta del proceso de ingeniería de requerimientos es crear y mantener un documento de requerimientos del sistema. El proceso general tiene 4 subprocesos de alto nivel de la ingeniería de requerimientos.

1- Estudios de Viabilidad: La entrada de este estudio es un conjunto de requerimientos de negocio

preliminares, una descripción resumida del sistema y de cómo este pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.

Estudio de viabilidad

Obtención y análisis de

requerimientos Especificación de requerimientos Validación de

requerimientos Informe de viabilidad

Modelos del sistema Requerimientos del

usuario del sistema Documento de Requerimientos


Un estudio de viabilidad es un estudio corto y orientado a resolver varias cuestiones: - ¿Contribuye el sistema a los objetivos generales de la organización? - ¿Se puede implementar el sistema utilizando la tecnología actual y dentro de las restricciones de

coste y tiempo? - ¿Puede integrarse el sistema con otros sistemas existentes en la organización?

Llevar a cabo un estudio de viabilidad comprende la evaluación y recopilación de la información, y la redacción de informes. La fase de evaluación de la información identifica la información requerida para contestar las 3 preguntas anteriores. Una vez que dicha información se ha identificado, se debería hablar con las fuentes de información para descubrir las respuestas a estas preguntas. Una vez que se tiene la información, se redacta el informe de estudio de viabilidad. Debería hacerse una recomendación sobre si se debe continuar o no el desarrollo del sistema. En el informe, se pueden proponer cambios en el alcance, el presupuesto y la confección de agendas del sistema y sugerir requerimientos adicionales de alto nivel para éste.

2- Obtención, Análisis y Especificación de Requerimientos: En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones de hardware, etc. La obtención y análisis de requerimientos pueden afectar a varias personas de la organización. El término stakeholder se utiliza para referirse a cualquier persona o grupo que se verá afectado por el sistema, directa o indirectamente. Obtener y comprender los requerimientos de los stakeholder es difícil ya que a veces no suelen expresar lo que quieren del sistema, lo expresan en lenguaje común, puede haber intereses en la organización, etc. Las actividades de este proceso de obtención y análisis de requerimientos son:

1. Descubrimiento de requerimientos: Es el proceso de recoger información sobre el sistema propuesto y los existentes, y extraer los requerimientos del usuario y del sistema de esta información. Se pueden utilizar enfoques orientados a puntos de vista, que permiten determinar los requerimientos según determinados puntos de vista. Existen 3 puntos de vista genéricos: - Puntos de vista de los interlocutores: Representan a las personas u otros sistemas que

interactúan directamente con el sistema - Puntos de vista indirectos: Representan los stakeholder que no utilizan el sistema ellos

mismos, pero que influyen en los requerimientos de algún modo - Puntos de vista del dominio: Representan las características y restricciones del dominio que

influyen en los requerimientos del sistema Por lo general, estos puntos de vista proporcionan diferentes tipos de requerimientos.

2. Clasificación y organización de los requerimientos 3. Ordenación por prioridades y negociación de requerimientos 4. Documentación de Requerimientos

3- Validación de Requerimientos: Trata de mostrar que los requerimientos realmente definen el sistema que el cliente desea. Es importante debido a que los errores en el documento de requerimientos pueden conducir a importantes costos al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema esté en uso. El costo de arreglar un problema en los requerimientos haciendo un cambio en el sistema es mucho mayor que reparar los errores de diseño o los de codificación. Durante el proceso de validación de los requerimientos, se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden:

1. Verificaciones de validez 2. Verificaciones de consistencia


3. Verificaciones de completitud 4. Verificaciones de realismo 5. Verificabilidad: Para reducir discusiones con el cliente.

Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación de requerimientos: Revisiones de requerimientos: Los requerimientos son analizados sistemáticamente por un

equipo de revisores Construcción de prototipos: Es este enfoque de validación, se muestra un modelo ejecutable del

sistema a los usuarios finales y a los clientes. Éstos pueden experimentar con este modelo para ver si cumple sus necesidades reales

Generación de casos de prueba: Los requerimientos deben poder probarse. Si las pruebas para estos se conciben como parte del proceso de validación, a menudo revela los problemas en los requerimientos

No deben subestimarse los problemas en la validación de requerimientos. Es difícil demostrar que un conjunto de requerimientos cumple con las necesidades del usuario. Los usuarios deben imaginarse el sistema en funcionamiento y cómo éste encajaría en su trabajo. Para los informáticos expertos es difícil llevar a cabo este tipo de análisis abstracto, pero para los usuarios del sistema es aún más difícil.

GESTIÓN DE REQUERIMIENTOS

En casi todos los sistemas los requerimientos cambian con el tiempo. La gestión de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema. Desde una perspectiva evolutiva, los requerimientos se dividen en 2 clases:

1- Requerimientos duraderos: Son requerimientos relativamente estables que se derivan de la actividad principal de la organización y que están relacionados directamente con el dominio del sistema

2- Requerimientos volátiles: Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o después de que éste se haya puesto en funcionamiento. Ej: políticas gubernamentales. Se clasifican en:

a) Req. Cambiantes: Están afectados por el entorno de la organización b) Req. Emergentes: Emergen al incrementarse la comprensión del cliente en el desarrollo del

sistema c) Req. Consecuentes: Son el resultado de la introducción del sistema informático. El sistema

puede cambiar la forma de trabajar en la organización, y esto genera nuevos requerimientos d) Req. De Compatibilidad: Dependen de otros sistemas presentes en la organización

Planificación de la gestión de requerimientos

La planificación es una primera etapa esencial del proceso de gestión de requerimientos. Durante la etapa de Gestión de requerimientos, habrá que decidir sobre:

1- La identificación de requerimientos 2- Un proceso de gestión del cambio: Este es el conjunto de actividades que evalúan el impacto y

coste de los cambios 1) Análisis del problema y especificación del cambio 2) Análisis del cambio y cálculo de costos 3) Implementación del cambio

3- Políticas de rastreo: Estas políticas definen las relaciones entre los requerimientos, y entre éstos y el diseño del sistema que se debe registrar y la manera en que éstos registros se deben mantener

4- Ayuda de Herramientas CASE: Se precisan herramientas de ayuda para: - Almacenar requerimientos - Gestionar el cambio - Gestionar el rastreo


UNIDAD 5



UNIDAD 5: MODELOS

Un modelo es una representación, en cierto medio, de algo en el mismo u otro medio. El modelo capta los aspectos importantes de lo que estamos modelando, desde cierto punto de vista, y simplifica u omite el resto. Un modelo se expresa en un medio adecuado para el trabajo que se está realizando. Un modelo de un sistema software está construido en un lenguaje de modelado, como UML. El modelo tiene semántica y notación y puede adoptar varios formatos que incluyen texto y gráficos. El modelo pretende ser más fácil de usar para ciertos propósitos que el sistema final.

¿Para qué sirven los modelos? Para captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento de forma que

todos los implicados pueden entenderlos y estar de acuerdo con ellos Para pensar el diseño de un sistema Para capturar decisiones del diseño de una forma mutable a partir de los requisitos Para generar productos aprovechables para el trabajo Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en grandes

sistemas Para explorar económicamente múltiples soluciones Para simplificar visualmente los sistemas complejos

¿Qué hay en un modelo?

Semántica: El aspecto semántico capta el significado de una aplicación como una red de construcciones lógicas. Los elementos semánticos del modelo se utilizan para la generación del código, la comprobación de la validez, las métricas de complejidad, etc. El aspecto visual es irrelevante para la mayoría de las herramientas que procesan modelos. La información semántica a menudo es llamada el modelo

Presentación visual: Muestra la información semántica de modo que pueda ser considerada, hojeada y corregida por los seres humanos. No agrega significado, sino que organiza la presentación para acentuar la organización del modelo de una manera útil. Por lo tanto, dirigen la comprensión humana del modelo

Contexto: Los modelos son artefactos en un sistema informático y se utilizan dentro de un contexto más grande que les dé significado completo. Es decir, que no se construyen ni utilizan aislados. Son parte de un entorno más grande que incluye herramientas de modelado, lenguajes y compiladores, sistemas operativos, redes, etc.

¿Cuál es el significado de un modelo? Un modelo es un generador de potenciales configuraciones de sistemas: los posibles sistemas son sus extensiones o valores. Un modelo es siempre una abstracción a un cierto nivel. Captura los aspectos esenciales de un sistema y omite algunos de los detalles. En los modelos hay que considerar los siguientes aspectos:

Abstracción frente al detalle Especificación frente a la implementación Descripción frente a la instancia Variaciones en la interpretación


Niveles de los modelos Los modelos adquieren diversas formas para diferentes propósitos, y aparecen en diversos niveles de abstracción. La cantidad de detalle del modelo debe adaptarse a uno de los siguientes propósitos:

Guías al proceso de pensamiento: los modelos de alto nivel construidos al principio de un proyecto sirven para enfocar el proceso del pensamiento de los participantes y destacar determinadas opciones. Capturan requisitos y representan un punto de partida hacia un diseño del sistema. Los primeros modelos ayudan a los autores a explorar las opciones posibles antes de converger en un concepto de sistema. Según progresa el diseño, los primeros modelos son sustituidos por otros modelos más exactos.

Especificaciones abstractas de la estructura esencial de un sistema: Los modelos es en análisis o las etapas preliminares del diseño se centran en los conceptos y mecanismos claves del probable sistema. Se corresponden de cierta manera con el sistema final, pero faltan los detalles que se deben agregar explícitamente durante el proceso de diseño. El propósito de los modelos abstractos es conseguir que los aspectos de alto nivel estén correctos, antes de abordar los detalles más localizados

Especificaciones completas de un sistema final: Un modelo de implementación incluye suficiente información para construir el sistema. Debe incluir, no solamente la semántica lógica del sistema y los algoritmos, las estructuras de datos y los mecanismos que aseguran funcionamiento apropiado, sino también las decisiones de organización sobre los artefactos del sistema que son necesarios, permitiendo así el trabajo cooperativo de las personas y el procesamiento por parte de las herramientas.

Ejemplos de sistemas típicos o posibles: Algunos bien elegidos pueden facilitar el entendimiento a las personas, y pueden validar las especificaciones e implementación del sistema. Una gran colección de ejemplos, sin embargo, no elimina la necesidad de una descripción definitiva

Descripciones completas o parciales del sistema: Un modelo puede ser una descripción completa de un solo sistema, sin referencias externas. Más a menudo se organiza como un conjunto de unidades distintas, discretas, cada una de las cuales se puede almacenar y manipular por separado, como parte de la descripción completa.

Metamodelo Especificación de Requisitos

Especificaciones lógicas que el sistema debería hacer Especificaciones de las restricciones del sistema Roles externos que interactúan con el sistema

Especificaciones funcionales Asociaciones entre Actores y Casos de uso


MODELO DEL DOMINIO Un modelo del dominio muestra (a los modeladores) clases conceptuales significativas del mundo real en un dominio del problema (o de interés). Es el artefacto más importante que se crea durante el análisis orientado a objetos. La identificación de las clases conceptuales forma parte del estudio del dominio del problema. Un modelo del dominio no muestra componentes software, como bases de datos o métodos; no se trata de un conjunto de diagramas que describen clases software u objetos software con responsabilidades. También suele llamarse al modelo del dominio como modelos conceptuales, modelos de objetos del dominio o modelos de objetos de análisis. Los modelos del dominio se representan en UML con un conjunto de diagramas de clases sin métodos. Pueden mostrar:

Clases conceptuales (u objetos del dominio): Podría considerarse en términos de su símbolo, intensión y extensión

Asociaciones entre las clases conceptuales Atributos de las clases conceptuales

Podemos considerar el modelo del dominio como un diccionario visual de las abstracciones relevantes, vocabulario e información del dominio. Modelos y descomposición del dominio Como los problemas del software pueden ser complejos, la descomposición es una estrategia común para tratar ésta complejidad mediante la división del espacio del problema en unidades fáciles de comprender. Identificación de clases conceptuales Consiste en analizar el dominio del problema e identificar las posibles clases. Es mejor especificar en exceso que por defecto. Es válido tener clases conceptuales sin atributos, o clases conceptuales con un rol puramente de compromiso entre el dominio, en lugar de un rol de información. Algunas estrategias para identificar clases conceptuales son:

Siguiendo una lista de categorías que por lo general, son clases (esta lista está hecha en base a la experiencia previa de otros analistas)

Identificando frases nominales en la descripción del problema A partir del análisis anterior, obtendremos una lista de clases conceptuales candidatas del dominio. No existe una lista “correcta”. Es una colección algo arbitraria de abstracciones y vocabulario del dominio que el modelador considera relevantes. Luego de identificar las clases conceptuales, se deben representar éstas en un modelo del dominio, y se deben agregar las asociaciones y atributos que se consideren necesarios para satisfacer los requisitos del problema. Modelado del mundo irreal Algunos sistemas son para dominios que presentan muy poca analogía con dominios naturales. Se puede de todas formas crear un modelo del dominio, pero requiere un alto grado de abstracción y olvidarse de diseños familiares.


UNIDAD 6



UML

Objetivos Modelo Conceptual Arquitectura

Bloques Básicos Reglas de Combinación De bloques Mecanismos

Elementos Estructurales (Clasificadores) Elementos de Comportamiento Elementos de Agrupación Elementos de Anotación 1. Dependencia 2. Asociación 3. Generalización 4. Realización

Elementos Relaciones

Diagramas De…

1. Clases 2. Objetos 3. Componentes 4. Estructura

compuesta 5. Casos de uso 6. Secuencia

7. Colaboración 8. Estados 9. Actividades 10. Despliegue 11. Paquetes 12. Tiempos 13. Interacciones

- Nombres - Alcance - Visibilidad - Integridad - Ejecución 1- Especificaciones 2- Adornos 3- Divisiones comunes 4- Mecanismos de Extensibilidad

- Estereotipos - Valores Etiquetados - Restricciones

- Vista de Casos de uso - Vista de Diseño - Vista de Interacción - Vista de Implementación - Vista de Despliegue

- Visualizar - Especificar - Construir - Documentar

Clase Interfaz Colaboración Caso de uso Clase activa Componente Artefacto Nodo

Interacción Máquina de Estados Actividad

Paquetes

Nota

Inclusión Extensión


Análisis

Artefactos Trabajadores

Flujo de Trabajo

(Actividades)

1- Modelo de Análisis 2-Clase de Análisis 3-Realización de un Caso de uso-Análisis 4-Paquete del Análisis

5-Descripción de la Arquitectura (Vista del modelo de Análisis) 1- Arquitecto 2- Ing. De Casos de Uso 3- Ing. De Componentes

Clase de Interfaz Clase de Entidad Clase de Control

Diagrama de Clases Diagramas de Interacción Flujo de sucesos-análisis Requisitos Especiales

Paquetes de Servicio

1- Análisis de la

Arquitectura 2- Analizar un

Caso de Uso

3- Analizar una Clase

4- Analizar un

paquete

1- Identificación de paquetes de Análisis

2- Identificación de clases de entidad obvias 3- Identificación de requisitos especiales comunes

1- Gestión de los aspectos comunes entre paquetes del análisis

2- Identificación de paquetes de servicio

3- Definición de dependencia entre paquetes del análisis

1- Identificación de clases de análisis 2- Descripción de interacciones entre objetos del análisis 3- Captura de requisitos especiales 1- Identificar Responsabilidades 2- Identificar Atributos 3- Identificar Asociaciones y negociaciones 4- Identificar Generalizaciones 5- Captura de requisitos especiales

Vista Estática

Clasificadores

Relaciones

- Clases - Actor - Rol - ….

- Asociación - Generalización - Realización - Dependencia


UNIDAD 6: UML Y SUS VISTAS

UML es un lenguaje de modelado para: Visualizar Especificar Construir Documentar

los artefactos de un sistema con gran cantidad de software. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema. El vocabulario y las reglas de UML indican como crear y leer modelos bien formados, pero no dicen qué modelos se deben crear ni cuando se deberían crear. Ésta es la tarea del proceso de desarrollo de software. Normalmente, los proyectos y las organizaciones desarrollan su propio lenguaje, y es difícil comprender lo que está pasando para alguien nuevo o ajeno al grupo. Además, hay cuestiones sobre un sistema que no se pueden entender a menos que se construyan modelos que trasciendan el lenguaje de programación textual. Otro punto a destacar, es que si el desarrollador que escribió el código no dejó documentación escrita sobre los modelos que había en su cabeza, esa información se perderá para siempre, o como mucho, será sólo parcialmente reproducible a partir de la implementación.

MODELO CONCEPTUAL DE UML

Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto requiere aprender 3 elementos principales:

1. Bloques Básicos de construcción UML

Elementos

- Estructurales o Clasificadores: Son las partes estáticas de los modelos Clase: Es una descripción de un conjunto de objetos que comparten los mismos atributos,

operaciones, relaciones y semántica Interfaz: Es una colección de operaciones que especifican un servicio de una clase o

componente. Por tanto, una interfaz describe el comportamiento visible externamente de ese elemento Colaboración: Define una interacción y es una sociedad de roles y otros elementos que

colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos Caso de uso Clase Activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución y, por

tanto, pueden dar origen a actividades de control. Componente: Es una parte modular del diseño del sistema que oculta su implementación tras un

conjunto de interfaces externas. Artefacto: Es una parte física y reemplazable de un sistema que contiene información física. Un

artefacto representa típicamente el empaquetamiento físico de código o información en tiempo de ejecución. Nodo: Es un elemento físico que existe en tiempo de ejecución y representa un recurso

computacional, que por lo general dispone de algo de memoria y/o capacidad de procesamiento. - De Comportamiento: Son las partes dinámicas de los modelos

Interacción: Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico.


Máquina de Estados: Es un comportamiento que especifica las secuencias de estados por las que pasa un objetos durante su vida en respuesta a eventos. Puede incluir transiciones, eventos, acciones. Actividad: Es un comportamiento que especifica la secuencia de pasos que ejecuta un proceso.

- De Agrupación: Son las partes organizativas de los modelos UML Paquete: Es puramente conceptual (sólo existe en tiempo de desarrollo).

- De Anotación: Son las partes explicativas de los modelos UML Nota: Muestra comentarios

Relaciones

Dependencia: Es una relación semántica entre 2 elementos, en la cual un cambio al elemento independiente puede afectar a la semántica del elemento dependiente

Asociación: Es una relación estructural entre clases que describe un conjunto de enlaces, los cuales son conexiones entre objetos. Algunos tipos especiales de asociación son la composición y agregación.

Generalización: Es una relación de especialización, en la cual el elemento especializado (hijo) se basa en la especificación del elemento generalizado (padre). El hijo comparte la estructura y el comportamiento del padre

Realización: Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá.

Existen variaciones entre las cuatro anteriores, como la inclusión y extensión.

Diagramas de… Clases: Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones.

Abarcan la vista de diseño estática de un sistema Objetos: Muestra un conjunto de objetos y sus relaciones. Representan instantáneas estáticas de

instancias de los elementos de un diagrama de clases. Componentes: Representa la encapsulación de una clase, juntos con sus interfaces, puertos y

estructura interna. Abarcan la vista de implementación estática del diseño de un sistema Casos de Uso: Muestra un conjunto de CU, sus actores y relaciones. Abarcan la vista de casos

de uso estática de un sistema. De interacción (Secuencia y Comunicación/Colaboración): Cubren la vista dinámica de un

sistema. Muestran el flujo de mensajes entre objetos. Estados: Muestra una máquina de estados. Abarca la vista dinámica de un objeto. Actividades: Muestra la estructura de un proceso. Abarca la vista dinámica. Despliegue: Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los

artefactos que residen en ellos. Abarcan la vista de despliegue estática de una arquitectura. Paquetes: Muestra la descomposición del propio modelo en unidades organizativas y sus

dependencias Tiempos: Es un diagrama de interacción que muestra las tiempos reales en el sistema. Visión Global de Interacciones: Es un híbrido entre un diagrama de actividades y uno de

secuencia. 2. Reglas de Combinación de Bloques

UML tiene reglas sintácticas y semánticas para: Nombres: Cómo llamar a los elementos, nombres y diagramas Alcance: El contexto que da un significado específico a un nombre Visibilidad: Cómo se pueden ver y utilizar esos nombres por otros Integridad: Cómo se relacionan apropiada y consistentemente unos elementos con otros


Ejecución: Qué significa ejecutar o simular un modelo dinámico 3. Mecanismos comunes en UML

UML incorpora 4 mecanismos para simplificar la modelización:

Especificaciones: Implica la representación de un concepto mediante una figura. Ej: El óvalo de caso de uso, rectángulo de 3 compartimientos de clase, etc. Adornos: Ej: símbolos +,-,# en atributos de clase Divisiones Comunes: Utilizar con una misma forma gráfica 2 conceptos Mecanismos de Extensibilidad

Estereotipos: Construcción de nuevos bloques a partir de bloques ya existentes Valores Etiquetados: Son detalles agregados Restricciones

ARQUITECTURA

La arquitectura de un sistema puede describirse mediante 5 vistas:

1. Vista de Casos de Uso: Comprende los casos de uso que describen el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas. Esta vista no especifica realmente la organización de un sistema software.

a. Aspectos Estáticos Diagrama de Casos de Uso b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

2. Vista de Diseño: Comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solución. Esta vista soporta principalmente los requisitos funcionales del sistema.

a. Aspectos Estáticos Diagramas de Clases y Objetos b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

3. Vista de Interacción: Muestra el flujo de control entre sus diversas partes. Abarca el rendimiento, escalabilidad y capacidad de procesamiento del sistema. Los aspectos son los mismos que en la vista de diseño.

4. Vista de Implementación: Comprende los artefactos que se utilizan para ensamblar y poner en producción el sistema físico.

a. Aspectos Estáticos Diagramas de Artefactos b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

5. Vista de Despliegue: Contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema. Esta vista se ocupa de la distribución, entrega e instalación de las partes que constituyen el sistema físico.

a. Aspectos Estáticos Diagramas de Despliegue b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades


LA VISTA ESTÁTICA

La vista estática es la base de UML. Los elementos de la vista estática de un modelo son todo tipo de conceptos encontrados en los sistemas. Esta vista captura la estructura del objeto, e incluye todo lo concerniente a las estructuras de datos tradicionales, así como la organización de las operaciones sobre los datos. Los datos y las operaciones son cuantificados en clases. La vista estática describe entidades de comportamiento, pero no contiene los detalles de su comportamiento dinámico. Los trata como elementos para ser nombrados, poseídos por las clases e invocados. Hay 2 elementos clave en esta vista:

1. Clasificadores Un clasificador es un concepto discreto en el modelo, que tiene identidad, estado, comportamiento y relaciones. Algunos clasificadores son las clases, actores, rol, componente, caso de uso, nodo, señal, interfaz, etc. 2. Relaciones Asociación: Lleva la información entre objetos en un sistema. Sin asociaciones, habrían sólo

clases aisladas. Una clase se puede asociar a sí misma, o hacia otra clase. Los extremos de la asociación pueden tener multiplicidad, es decir, cuántas instancias de una clase se pueden relacionar con una instancia de otra. Si una asociación puede tener atributos por sí misma, surge una clase asociativa. Durante el análisis, las asociaciones representan relaciones lógicas entre objetos. La asociación se representa con una línea continua. Hay 2 subtipos: o Agregación: Es una asociación que representa una relación todo-parte. Se muestra adornado

con un diamante hueco en el extremo de la trayectoria unida a la clase agregada o Composición: Es una asociación más fuerte, en la cual el compuesto es el responsable único

de gestionar sus partes. Se muestra con un diamante relleno adornando el extremo compuesto.

Generalización: Es una relación taxonómica entre una descripción más general (padre) y una descripción más específica (hijo), que se construye sobre ella y la extiende. La descripción más específica es completamente consistente con la más general, y puede contener información adicional. En el caso de clases, se habla de superclase y subclase. Una generalización se dibuja como una flecha que va desde el padre al hijo, con un triángulo hueco en el extremo del padre. La generalización tiene 2 propósitos:

o Principio de sustitución (del padre por el hijo, que es más especializado), lo que posibilita el polimorfismo

o Permitir la herencia Realización: Conecta un elemento del modelo con otro que especifica su comportamiento, pero

no su estructura o implementación. Se indica con una flecha de línea discontinua con una punta hueca cerrada

Dependencia: Indica una relación semántica entre dos o más elementos del modelo. Indica una situación, en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia.


ANÁLISIS

Durante el análisis, analizamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero. Reflexionemos un poco sobre los resultados de la captura de requisitos. Si conseguimos llegar a un acuerdo con el cliente sobre lo que debería hacer el sistema, es probable que aún queden aspectos sin resolver relativos a los requisitos del sistema. Éste es el precio que hay que pagar por usar el un lenguaje intuitivo pero impreciso del cliente durante la captura de requisitos. A fin de comunicar eficientemente las funciones del sistema al cliente:

Los casos de uso deben mantenerse tan independientes unos de otros como sea posible. Los casos de uso deben describirse utilizando el lenguaje del cliente Debe estructurarse cada caso de uso para que forme una especificación de funcionalidad completa

e intuitiva Dados esos temas sin tratar, el propósito fundamental del análisis es resolverlos analizando los requisitos con mayor profundidad, pero con la gran diferencia de que puede utilizarse el lenguaje de los desarrolladores para describir resultados. En consecuencia, en el análisis podemos refinar los requisitos y estructurarlos como más nos convenga. Esta estructura (basada en clases de análisis y paquetes) es independiente de la estructura que se dio a los requisitos, aunque existe una trazabilidad directa entre ambas.

Modelo de Casos de Uso Modelo de Análisis Descrito con el lenguaje del cliente Descrito con el lenguaje del desarrollador Vista externa del sistema Vista interna del sistema Estructurado por los casos de uso Estructurado por clases y paquetes Utilizado como contrato entre el cliente y desarrolladores

Utilizado por los desarrolladores para comprender como se debería diseñar e implementar el sistema

Puede contener redundancias, inconsistencias, etc., entre requisitos

No debería contener redundancias, inconsistencias, etc., entre requisitos

Captura la funcionalidad del sistema, incluida la funcionalidad significativa para la arquitectura

Esboza cómo llevar a cabo la funcionalidad dentro del sistema, incluida la funcionalidad significativa para la arquitectura. Sirve como una 1º aproximación al diseño.

Define casos de uso que se analizarán con más profundidad en el modelo de análisis

Define realizaciones de casos de uso, y cada una de ellas representa el análisis de un caso de uso del modelo de casos de uso

El lenguaje que utilizamos en el análisis se basa en un modelos de objetos conceptual, el modelo de análisis. Un modelo de análisis ofrece una especificación más precisa de los requisitos que la que tenemos

como resultado de la captura de requisitos, incluyendo el modelo de casos de uso Un modelo de análisis se describe utilizando el lenguaje de los desarrolladores, por lo que

introduce un mayor formalismo y la posibilidad de ser utilizado para tratar funcionamientos internos del sistema

Un modelo de análisis estructura los requisitos de un modo que facilita su comprensión, preparación, modificación y mantenimiento

Un modelo de análisis puede considerarse como una primera aproximación al modelo de diseño, y es por tanto una entrada fundamental cuando se da forma al sistema en el diseño y la implementación.


Artefactos del Modelo de Análisis

1. Modelo de Análisis

2. Clase del análisis Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Este tipo de clase se centra en el tratamiento de los requisitos funcionales y pospone los no funcionales (especiales). Además define atributos, pero con gran abstracción. Participa en relaciones del tipo conceptual, es decir, son distintas a las relaciones de implementación. Se clasifican en:

2.1. Clase de Interfaz: Se utilizan para modelar la interacción entre el sistema y sus actores. Esta interacción a menudo implica recibir (y presentar) información y peticiones de (y hacia) los usuarios y los sistemas externos. Las clases de interfaz representan a menudo abstracciones de ventanas, formularios, sensores, API’s, etc. Cada clase de interfaz debería asociarse con un actor y viceversa.

2.2. Clase de Entidad: Se utilizan para modelar información que posee una vida larga y que es a menudo persistente. Reflejan la información de un modo que beneficia a los desarrolladores al diseñar e implementar el sistema, incluyendo su soporte de persistencia

2.3. Clase de Control: Representan coordinación, secuencia, transacciones y control de otros objetos. Se usan con frecuencia para encapsular el control de un caso de uso en concreto. También se utilizan para representar derivaciones y cálculos complejos, que no pueden asociarse con ninguna información concreta. Los aspectos dinámicos del sistema se modelan con clases de control

3. Realización de caso de uso-análisis Una realización de caso de uso – análisis es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis y de sus objetos del análisis en interacción. Una realización de caso de uso proporciona por tanto una traza directa hacia un caso de uso concreto del modelo de casos de uso.

3.1. Diagramas de Clases: (¡Cuidado! Se hace con clases de análisis) 3.2. Diagramas de Interacción: (¡Cuidado! Se hace con clases de análisis) 3.3. Flujo de sucesos-análisis: A veces resulta útil adicionar un texto que explique los diagramas

anteriores. Debería de escribirse en términos de objetos. 3.4. Requisitos especiales: Son descripciones textuales que recogen todos los requisitos no

funcionales sobre una realización de caso de uso. 4. Paquete del análisis Los paquetes del análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases de análisis, realizaciones de casos de uso, e incluso otros paquetes. Los paquetes del análisis deberían ser:


Cohesivos Débilmente acoplados

Además, los paquetes del análisis pueden representar una separación de intereses de análisis. Deberían crearse basándose en los requisitos funcionales y en el dominio del problema, y deberían ser reconocibles por las personas con conocimiento del dominio. Probablemente estos paquetes se conviertan en subsistemas a futuro.

4.1. Paquetes de Servicio: Son un tipo particular de paquete, proporcionado por el sistema al cliente, para que ofrezca a sus usuarios los casos de uso necesarios para llevar a cabo su negocio. Los paquetes de servicio contienen un conjunto de clases relacionadas funcionalmente. Estos paquetes son indivisibles, reutilizables, y son fundamentales para el diseño y la implementación.

5. Descripción de la Arquitectura (Vista del modelo de análisis) Mediante la vista de la arquitectura del modelo de análisis podemos ver la descomposición del modelo de análisis en paquetes de análisis y sus dependencias; las clases fundamentales del análisis y las realizaciones de casos de uso

Trabajadores 1. Arquitecto: Es el responsable de la integridad y la arquitectura del modelo de análisis, garantizando que éste sea correcto, consistente y legible como un todo. El modelo de análisis es correcto si cumple con el modelo de casos de uso 2. Ingeniero de Casos de Uso: Es responsable de la integridad de una o más realizaciones de casos de uso, garantizando que cumplen los requisitos que recaen sobre ellos. Una realización de caso de uso debe llevar a cabo correctamente el comportamiento de su correspondiente caso de uso del modelo de casos de uso, y sólo ese comportamiento. 3. Ingeniero de componentes: Se encarga de definir y mantener las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases y paquetes del análisis, asegurándose de que cada clase del análisis cumple con los requisitos que se esperan de ella de acuerdo a las realizaciones de caso de uso en las que participa.

Flujo de Trabajo 1. Análisis de la arquitectura

1.1. Identificación de paquetes del análisis 1.1.1. Gestión de los aspectos comunes entre paquetes del análisis 1.1.2. Identificación de paquetes de servicio 1.1.3. Definición de dependencias entre paquetes de análisis

1.2. Identificación de clases de entidad obvias 1.3. Identificación de requisitos especiales comunes: como gestión de transacciones, persistencia, distribución,

concurrencia, seguridad, tolerancia a fallos. 2. Analizar un Caso de Uso

2.1. Identificación de clases del análisis 2.2. Descripción de interacciones entre objetos del análisis 2.3. Captura de requisitos especiales

3. Analizar una Clase 3.1. Identificar responsabilidades 3.2. Identificar atributos 3.3. Identificar asociaciones y agregaciones 3.4. Identificar generalizaciones 3.5. Captura de requisitos especiales

4. Analizar un paquete: Se debe tener en cuenta Garantizar que el paquete sea lo más independiente posible de otros paquetes Garantizar que el paquete cumple con sus objetivos Describir las dependencias para poder estimar el efecto de cambios futuros


UNIDAD 7




UNIDAD 7: Objetos y Clases

OBJETOS

Definimos objeto como una entidad discreta con un límite bien definido que encapsula el estado y comportamiento; una instancia de una clase. Por lo general, la única forma de llegar a la parte de datos de un objeto es al invocar una de las funciones que pone disponible el objeto. Estas funciones se denominan operaciones. Ocultar la parte de datos de un objeto detrás de esta capa de operaciones se conoce como encapsulación. La encapsulación no se aplica en UML ya que algunos leguajes orientados a objetos no lo demandan. Todo objeto es una instancia de cierta clase que define el conjunto común de características (atributos y operaciones) que se comparten por todas las instancias de esta clase. Los objetos tienen ciertas propiedades que lo caracterizan:

Identidad (ID): Ésta es la existencia única del objeto en tiempo y espacio. Es lo que lo diferencia de otros objetos

Estado: Esto está determinado por los valores de atributo de un objeto y las relaciones que tiene el objeto con otros objetos en un punto en el tiempo en particular.

Comportamiento: Son las operaciones. Una operación es la especificación de una pieza del comportamiento. Una implementación de ese comportamiento se denomina método. Invocar una operación sobre un objeto causará un cambio en los valores de uno o más de sus atributos o en sus relaciones con otros objetos, y esto puede constituir una transición de estado.

Encapsulación La encapsulación es una de las ventajas principales de la programación orientada a objetos, y puede llevar a software más robusto y ampliable. Esta técnica consiste en utilizar métodos para la manipulación de los datos de un objeto. Esto hace que se disminuya la tasa de error al programar. Mensajería Los objetos colaboran para realizar las funciones del sistema. Lo que esto significa es que los objetos forman vínculos a otros objetos y envían mensajes a lo largo de esos vínculos. Cuando un objeto recibe un mensaje, mira en su conjunto de operaciones para ver si existe una operación cuya firma coincide con la figura del mensaje. Si existe, entonces invoca la operación. Estas firmas se componen del nombre del mensaje (método), tipos de parámetro y valor de retorno


Notación de un objeto con UML Existen 3 formas de representar con UML un objeto, pero siempre subrayado:

Solamente con el nombre de la clase: Ej: :Cuenta. Esto significa que tiene un objeto anónimo o instancia de esa clase. Los objetos anónimos a menudo se utilizan cuando solamente un objeto de una clase en particular está en un diagrama dado.

Solamente el nombre del objeto: Ej: jimCuenta. Esto identifica un objeto específico, pero no identifica a qué clase pertenece

El nombre del objeto concatenado con el nombre de la clase, separado por “:”: Ej: jimCuenta:Cuenta. Se pueden leer los 2 puntos como “una instancia de la clase…”

Los objetos se nombran normalmente con una combinación de mayúsculas y minúsculas, empezando con una minúscula. Se evitan caracteres especiales y abreviaciones. Puesto que todos los objetos de la misma clase tienen el mismo conjunto de operaciones, las operaciones se listan en el ícono de clase, y no en el de objeto. Los atributos se pueden mostrar opcionalmente en el compartimiento inferior del ícono de objeto. Estos atributos que se elijan mostrar deben tener nombre y pueden tener un tipo y valor opcional.

CLASES

Una clase es el descriptor para un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento. Las clases le permiten describir el conjunto de características que todo objeto de la clase debe tener sin tener que describir cada uno de esos objetos. La relación entre una clase y objetos de esa clase es una relación <<instantiate>>. Como ya se vio antes, cualquier cosa dentro de <<…>>, se conoce como un estereotipo, y los estereotipos son uno de los 3 mecanismos de ampliación UML. Un estereotipo es una forma de personalizar elementos de modelado, una forma de crear variaciones con nueva semántica. En éste caso, el estereotipo <<instantiate>> convierte una dependencia ordinaria en una relación de instanciación entre una clase y los objetos de esa clase. Una dependencia es una relación entre 2 o más elementos en los que un cambio en el elemento proveedor puede afectar o proporcionar información necesaria al el/los clientes. Instanciar es la creación de nuevas instancias de elementos de modelo. Es éste caso, estamos instanciando objetos a partir de clases. En la mayoría de los lenguajes de programación OO, existen operaciones especiales, denominadas constructores, que realmente pertenecen a la propia clase en lugar de a los objetos de esa clase. Estas operaciones especiales se dice que tienen un ámbito de clase. La finalidad de las operaciones de constructores es crear nuevas instancias de la clase. El constructor destina memoria para el nuevo objeto, le asigna una identidad única y establece los valores iniciales de atributo para el objeto. También establece cualquier vínculo a otros objetos.


Notación de una Clase con UML La única parte obligatoria de la sintaxis visual es el compartimiento de nombre con el nombre de la clase en él.

Los compartimientos y adornos que incluya en una clase en un diagrama de clases dependen por completo de la finalidad del diagrama. Compartimiento de Nombre El nombre de la clase empieza con una letra mayúscula y luego una combinación de mayúsculas y minúsculas, con cada palabra comenzando en mayúscula. Se deben evitar abreviaciones, símbolos especiales y acrónimos propios del dominio del sistema. Compartimiento de Atributo La única parte obligatoria es el nombre. Los atributos se nombran poniendo en minúscula la primera letra, y la primera letra de cada palabra en mayúscula. Se deben evitar símbolos especiales y abreviaturas.

Visibilidad nombre: tipo[multiplicidad] = valorInicial


Visibilidad Adorno Nombre Visibilidad Semántica

+ Visibilidad Pública Cualquier elemento que puede acceder a la clase puede acceder a cualquiera de sus características

- Visibilidad Privada Solamente las operaciones dentro de la clase pueden acceder a las características

# Visibilidad Protegida Sólo las operaciones dentro de la clase o dentro de los hijos de la clase pueden acceder

~ Visibilidad de Paquete

Cualquier elemento que esté en el mismo paquete que la clase o en un subpaquete anidado puede acceder

Tipo El tipo de un atributo puede ser otra clase o un tipo primitivo. UML define 4 tipos primitivos (Integer, NaturalIlimitado, Boolean y String) y OCL define 1 más (Real), que se utilizan en la propia especificación UML y puede utilizarse en los modelos para mantener independencia de plataforma. Multiplicidad La multiplicidad permite modelar dos elementos totalmente diferentes al utilizar una expresión de multiplicidad sobre un atributo de la clase. Ej: nombre: String [2..*] No tiene limite superior Ej: dirección: String[3] Colección de elementos Ej: direccionMail: String[0..1] Con valor nulo Valor Inicial El valor inicial permite especificar el valor que tomará un atributo cuando se instancia un objeto desde la clase. Esto se conoce como el valor inicial del atributo porque es el valor que el atributo toma en el momento de la creación del objeto. En diseño, es un buen estilo utilizar valores iniciales para asegurarse que los objetos se creen en un estado válido y útil. Compartimiento de Operación Las operaciones son funciones que están unidas a una clase en particular. Como tal, tienen todas las características de funciones (nombre, lista de parámetros, tipo de retorno). La combinación del nombre de operación, tipos de todos los parámetros y el tipo de retorno, es la firma de la operación. Toda operación de una clase debe tener una firma única ya que ésta firma es la que asigna a la operación su identidad. Cuando un mensaje se envía a un objeto, la firma del mensaje se compara con las firmas de la operación definidas en la clase del objeto, y si se encuentra coincidencia, la operación apropiada se invoca en el objeto.

Visibilidad nombre (dirección nombreParámetro: tipoParámetro = valorPredet, …): tipoRetorno

Las operaciones y los parámetros se nombran poniendo la primera letra en minúscula, y la primera letra de cada palabra en mayúscula. Se deben evitar abreviaturas y símbolos especiales. Una operación puede tener de cero a muchos parámetros y tiene la forma: Dirección del parámetro Los parámetros de dirección pueden tener asignado una dirección. Si la dirección no se especifica, se asume in por defecto

Parámetro Semántica in Predeterminado. De entrada

inout De entrada-salida out De salida

return De retorno


Valor Predeterminado de Parámetros Se puede asignar un valor predeterminado a un parámetro. En caso de que se invoque la operación sin dicho parámetro, se asumirá el valor predeterminado. Operaciones de Consulta Toda operación tiene una propiedad denominada isQuery. Si establece esta propiedad en verdadero, la operación es una operación de consulta. Un estándar de nombrado para las operaciones de consulta es construir el nombre de la operación al prefijar el nombre de aquello que se consulte con get. Ej: getSaldo():double Sintaxis de Estereotipo de Clase Existe numerosa flexibilidad en cómo se pueden mostrar los estereotipos. Sin embargo, se utiliza por lo general el nombre entre <<…>> o el ícono .


UN PASEO POR UML: VISTAS DE UML

Una vista es simplemente un subconjunto de UML que modela construcciones que representan un aspecto de un sistema. En el nivel superior, las vistas se pueden dividir en 3 áreas:

Clasificación estructural: describe los elementos del sistema y sus relaciones con otros elementos Comportamiento dinámico: describe el comportamiento de un sistema en el tiempo Gestión de modelo: describe la organización de los propios modelos en unidades jerárquicas

Área Vista Diagramas Conceptos Principales

Vista Estática Diagrama de Clases Clase, asociación, generalización, dependencia, realización, interfaz

Vista de Casos de Uso Diagrama de Casos de uso

Caso de uso, actor, asociación, extensión, inclusión, generalización

de CU Vista de

Implementación Diagrama de Componentes Componente, interfaz, dependencia, realización

Estructural

Vista de Despliegue Diagrama de Despliegue Nodo, componente, dependencia,

localización Vista de

Máquina de estados

Diagrama de Estados Estado, evento, transición, acción

Vista de Actividad Diagrama de Actividad Estado, actividad, transición de

terminación, división, unión

Diagrama de Secuencia Interacción, objeto, mensaje, activación

Dinámica

Vista de Interacción Diagrama de Colaboración Colaboración, interacción, rol de

colaboración, mensaje Gestión del

Modelo Vista de Gestión

del modelo Diagrama de Clases Paquete, subsistema, modelo

Extensión de UML Todas Todos Restricción, estereotipo, valores

etiquetados 1- Área Estructural

1.1 Vista Estática La vista Estática modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación de la aplicación. Los componentes principales de la vista estática son las clases y sus relaciones. Las clases son el centro alrededor del cual se organiza la vista de clases: otros elementos pertenecen o se unen a las clases. Las clases se dibujan como rectángulos. Las listas de atributos y de operaciones se muestran en compartimientos separados, que pueden ser suprimidos cuando no es necesario el detalle completo. Las relaciones entre clases se dibujan como las líneas que conectan rectángulos de clases. Las diversas clases de relaciones se diferencian por la textura de la línea y por los adornes en las líneas o en sus extremos.


1.2 Vista de Casos de Uso La vista de los casos de uso modela la funcionalidad del sistema según lo perciben los usuarios externos, llamados actores. Un caso de uso es una unidad coherente de funcionalidad, expresada como transición entre los actores y el sistema. El propósito de la vista de casos de uso es enumerar a los actores y los casos de uso, y demostrar qué actores participan en cada caso de uso Los casos de uso se pueden describir en varios niveles de detalle. Se pueden sacar partes como factor común y ser descritos en términos de otros casos de uso más simples. Un caso de uso se implementa como una colaboración en la vista de interacción.


1.3 Vistas Físicas Las vistas físicas modelan la estructura de la implementación de la aplicación por sí misma, se organización en componentes, y su despliegue en nodos de ejecución. Estas vistas proporcionan una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos. Hay 2 vistas físicas:

1.3.1 Vista de Implementación La vista de implementación modela los componentes de un sistema, así como las dependencias entre los componentes, para poder determinar el impacto de un cambio propuesto. También modela la asignación de clases y de otros elementos del modelo a los componentes. Esta vista se representa en diagramas de componentes. Un círculo pequeño con un nombre es una interfaz. Una línea sólida que va desde un componente a una interfaz, indica que el componente proporciona los servicios de la interfaz. Una flecha de guiones de un componente a una interfaz indica que el componente requiere los servicios proporcionados por la interfaz.

1.3.2 Vista de Despliegue La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos. Un nodo es un recurso de ejecución, tal como una PC, un dispositivo o memoria. Esta vista permite determinar las consecuencias de la distribución y de la asignación de recursos. La vista de despliegue se representa en diagramas de despliegue. Este diagrama muestra los tipos de nodos del sistema y los tipos de componentes que contienen. Un nodo se representa como un cubo.



2- Área Dinámica

2.1 Vista de Maquina de Estados Una máquina de estados modela las posibles historias de vida de un objeto de una clase. Una máquina de estados contiene los estados conectados por transiciones. Cada estado modela un periodo de tiempo durante la vida de un objeto, en el que satisface ciertas condiciones. Cuando ocurre un evento se puede desencadenar una transición que lleve el objeto a un nuevo estado. Cuando se dispara una transición, se puede ejecutar una acción unida a la transición.

Las máquinas de estados se pueden utilizar para describir interfaces de usuario, controladores de dispositivo, y otros subsistemas reactivos. También pueden usarse para describir los objetos pasivos que pasan por varias fases cualitativas distintas, durante su tiempo de vida, cada una de las cuales tiene su propio comportamiento especial. 2.2 Vista de Actividad Un grafo de actividades es una forma especial de máquina de estados, prevista para modelar cómputos y flujos de trabajos. Los estados del grafo de actividades representan los estados de ejecución del cómputo, no los estados de un objeto ordinario.

Un grafo de actividades contiene estados de actividad. Un estado de actividad representa la ejecución de una sentencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un evento, se espera a la finalización del cómputo del momento. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad dentro del grafo. Los estados


de actividad no tienen generalmente transiciones con eventos explícitos, pero pueden ser abortados por transiciones en estados que los incluyen. Un diagrama de actividades es la notación para un grafo de actividades. A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de asignación puede mostrarse organizando las actividades en regiones distintas separadas por líneas en el diagrama, llamadas calles. Un diagrama de actividades puede mostrar el flujo de objetos como valores, además del flujo de objeto. Se puede representar un objeto que sea la entrada o la salida de una actividad dibujando un objeto; también el estado del objeto, para indicar su evolución o flujo, dibujando un estado de flujo de objeto. Para un valor de salida, se dibuja una flecha con línea discontinua desde una actividad al objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua desde el objeto a una actividad.

2.3 Vista de Interacción La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol de clasificador, o simplemente “rol”, es la descripción de un objeto, que desempeña un determinado papel dentro de un interacción, distinto de los otros objetos de la misma clase. La vista de interacción se exhibe en dos diagramas centrados en distintos aspectos: diagramas de secuencia y diagramas de colaboración Diagrama de Secuencia: Muestra un conjunto de mensajes, dispuestos en una secuencia temporal. Cada rol en la secuencia se muestra como una línea de vida, es decir, una línea vertical que representa el rol durante cierto plazo de tiempo, con la interacción completa. Los mensajes se muestran como flechas entre las líneas de vida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historia individual de una transacción.

Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso. Cuando está implementado el comportamiento, cada mensaje en un diagrama de secuencia corresponde a una operación en una clase, a un evento disparador, o a una transición en una máquina de estados. Diagrama de Colaboración: Una colaboración modela los objetos y los enlaces significativos dentro de una interacción. Un rol describe un objeto, y un rol en la asociación describe un enlace dentro de una colaboración. Un diagrama de colaboración muestra los roles en la interacción en una disposición geométrica. Los mensajes se muestran como flechas, ligadas a las líneas de la relación, que conectan a


los roles. La secuencia de mensajes se indica con números secuenciales que preceden a las descripciones de los mensajes. Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La colaboración muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa.

3- Gestión del Modelo La vista de Gestión del modelo modela la organización del modelo en sí mismo. Un modelo abarca un conjunto de paquetes que contienen los elementos del modelo, tales como clases, máquinas de estados y casos de uso. Los paquetes pueden contener otros paquetes. Los paquetes son unidades para manipular el contenido de un modelo, así como unidades para el control de acceso y el control de configuración. Cada elemento del modelo pertenece a un paquete o a otro elemento. Un modelo es una descripción completa de un sistema, con una determinada precisión, desde un punto de vista. Un subsistema es otro paquete especial. Representa una porción de un sistema, con una interfaz perfectamente determinada, que puede ser implementado como un componente distinto. Generalmente, la información de gestión del modelo se representa en diagramas de clases.


4- Extensión de UML UML incluye tres construcciones principales de extensión: restricciones, estereotipos y valores etiquetados. Una restricción es una declaración textual de una relación semántica expresada en un cierto lenguaje natural o formal. Un estereotipo es una nueva clase de elemento del modelo, ideada por el modelador, y basada en un tipo existente de elemento del modelo. Un valor etiquetado es una porción de información con nombre, unida a cualquier elemento del modelo. Estas construcciones permiten muchas clases de extensiones UML, sin requerir cambios al metamodelo básico de UML. Pueden ser utilizadas para crear versiones adaptadas a un área de aplicación.


LA VISTA DE LA MÁQUINA DE ESTADOS

La vista de la máquina de estados describe el comportamiento dinámico de los objetos, en un cierto plazo, modelando los ciclos de vida de los objetos de cada clase. Cada objeto se trata como una entidad aislada que se comunica con el resto del mundo detectando eventos y respondiendo a ellos. Los eventos representan las clases de cambio que un objeto puede detectar. Los sucesos del mundo real se modelan como señales del mundo exterior al sistema. Todos los objetos con el mismo estado ejecutan la misma acción cuando reciben el mismo evento. Sin embargo, los objetos en diferentes estados pueden reaccionar de diferente forma al mismo evento, realizando distintas acciones. Las máquinas de estados describen el comportamiento de las clases, pero también describen el comportamiento dinámico de los casos de uso, colaboraciones y métodos. Para uno de estos objetos, un estado representa un paso en su ejecución.

Una máquina de estados es un gráfico de estados y transiciones. Cuando se une a una clase describe, por lo general, la respuesta de una instancia de la clase a los eventos que recibe. También se pueden unir a operaciones, casos de uso y colaboraciones. Las máquinas de estados son útiles para entender los mecanismos de control, tales como interfaces de usuario o controladores de dispositivo. Una máquina de estados es un modelo de todas las posibles historias de vida de un objeto de una clase. El objeto se analiza aisladamente. Cualquier influencia externa del resto del mundo se resume como evento. Cuando el objeto detecta un evento, responde de una manera que depende de su estado actual. Esta respuesta puede incluir la ejecución de una acción y un cambio a un nuevo estado.

Evento Un evento es una ocurrencia significativa que tiene una localización en tiempo y espacio, y no tiene duración. Una ocurrencia específica de un evento se llama instancia de evento. Los eventos pueden tener parámetros que caractericen cada instancia individual del evento. Hay 4 tipos de eventos: de llamada, de cambio, de señal, y de tiempo.

Estado Un estado describe un periodo de tiempo durante la vida de un objeto de una clase. Puede tener nombre. En una máquina de estados, un conjunto de estados está conectado mediante transiciones. Cuando un objeto está en un estado, es sensible a los eventos correspondientes a las transiciones que salen del estado. Puede ser caracterizado como:

Un conjunto de valores de objeto cualitativamente similares Periodo de tiempo, durante el cual un objeto espera que ocurran eventos Periodo de tiempo, durante el cual un objeto realiza una cierta actividad

Se representa con un rectángulo con esquinas redondeadas. Un aspecto a destacar, es que pueden anidarse los estados, formando subestados.

Transición Una transición que deja un estado define la respuesta de un objeto en ese estado a la ocurrencia de un evento. Por lo general, la estructura de una transición es:

Estado Inicial[EventoDisparador] [Condición guarda] [/Acción()] Estado Destino

La condición de guarda es una expresión lógica opcional, que se evalúa como verdadera o falsa. Se evalúa sólo cuando ocurre el evento disparador. Si la expresión se evalúa como verdadero, se ejecuta la acción (si hay), y se desencadena la transición.


PAQUETES Todos los sistemas grandes se jerarquizan en niveles. De hecho, quizás la única forma de comprender un sistema complejo sea agrupando las abstracciones en grupos cada vez mayores. La mayoría de las abstracciones básicas son abstracciones de la misma naturaleza que las clases. La mayoría de las abstracciones mayores son puramente conceptuales (como el área comercial), para las que no existen instancias reales. Ellas nunca se manifiestan en el sistema real, sino más bien existen con el único objetivo de comprender el sistema. En UML, las abstracciones que organizan un modelo se llaman paquetes. Un paquete es un mecanismo de propósito general para organizar elementos en grupos, y así comprenderlos más fácilmente. Los paquetes también permiten controlar el acceso a sus contenidos para controlar las líneas de separación de la arquitectura del sistema. Cada paquete ha de tener un nombre que lo distinga de otros paquetes. Si el nombre está solo, se denomina nombre simple. Si consta del nombre del paquete seguido del precedido por el nombre del paquete que lo contiene, se denomina nombre de camino. Un paquete se dibuja normalmente mostrando sólo su nombre. Al igual que las clases, se pueden dibujar paquetes adornados con valores etiquetados o con apartados adicionales para mostrar sus detalles.

Un paquete puede contener otros elementos, incluyendo clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas, e incluso otros paquetes. La posesión es una relación compuesta, lo que significa que el elemento se declara en el paquete. Si el paquete se destruye, el elemento es destruido. Cada elemento pertenece exclusivamente a un único paquete. Un paquete forma un espacio de nombres, lo que quiere decir que los elementos de la misma categoría deben tener nombres únicos en el contexto de su paquete contenedor. Diferentes tipos de elementos pueden tener el mismo nombre. Los paquetes pueden contener a otros paquetes. Esto significa que es posible descomponer los modelos jerárquicamente. Es mejor evitar paquetes muy anidados. Aproximadamente, dos o tres niveles de anidamiento es el límite manejable. En vez de anidamiento, se usará la importación para organizar los paquetes.

Esta semántica de posesión convierte los paquetes en un mecanismo importante para enfrentarse al crecimiento. Sin los paquetes, se acabaría con grandes modelos planos en los que todos los elementos


deberían tener nombres únicos (una situación inmanejable). Los paquetes ayudan a controlar los elementos que componen un sistema mientras evolucionan a diferentes velocidades a lo largo del tiempo. Se puede mostrar explícitamente el contenido de un paquete, bien textualmente o bien gráficamente. Cuando se muestran los elementos que posee, el nombre del paquete se coloca en la pestaña de la carpeta. Se puede controlar la visibilidad de los elementos contenidos en un paquete del mismo modo que se puede controlar la visibilidad de los atributos y operaciones de una clase. Para especificar la visibilidad de un elemento contenido en un paquete se antepone al nombre del elemento el símbolo de visibilidad apropiado. Importación y Exportación La importación concede un permiso de un solo sentido para que los elementos de un paquete accedan a los elementos de otros. En UML, una relación de importación se modela como una dependencia con el estereotipo import. Al empaquetar las abstracciones en bloques significativos y luego controlar los accesos mediante la importación, se puede controlar la complejidad de tener un gran número de abstracciones. Las partes públicas de un paquete son sus exportaciones

Las dependencias de importación y acceso no son transitivas. En este ejemplo, Cliente importa Políticas, y Políticas importa GUI, pero Cliente no importa GUI por implicación. Por ello, el contenido de Cliente tiene acceso a las exportaciones de Políticas, pero no tiene acceso a las de GUI. Para conseguir el acceso, Cliente tendría que importar a GUI explícitamente. Generalización La generalización entre paquetes es muy parecida a la generalización entre clases. Los paquetes especializados heredan los elementos públicos y protegidos del paquete más general. Pero, al igual que con la herencia entre clases, los paquetes pueden reemplazar a los elementos más generales y añadir nuevos. Los paquetes implicados en las generalizaciones siguen el mismo principio de sustitución que las clases. Un paquete especializado puede usarse dondequiera que se use un paquete más general. Elementos Estándar Todos los mecanismos de extensibilidad UML se aplican a los paquetes. Con mucha frecuencia, se utilizan valores etiquetados para añadir nuevas propiedades al paquete y estereotipos para especificar nuevas categorías de paquetes.


UML define 5 estereotipos estándar que se aplican a los paquetes: 1- Facade: Especifica un paquete que es sólo una vista de algún otro paquete 2- Framework: Especifica un paquete que consta principalmente de patrones 3- Stub: Especifica un paquete que sirve de Proxy para el contenido público de otro paquete 4- Subsystem: Especifica un paquete que representa una parte independiente del sistema completo

que se está modelando 5- System: Especifica un paquete que representa el sistema completo que se está modelando

Técnicas Comunes de modelado

1- Modelado de Grupos de Elementos: El objetivo más frecuente para el que se utilizan los paquetes es organizar elementos de modelado en grupos a los que se puede dar un nombre y manejar como un conjunto. Los paquetes no tienen identidad (es decir, no pueden haber instancias de paquetes), por lo que son invisibles para el sistema en ejecución. La mayoría de las veces, los paquetes se utilizarán para agrupar el mismo tipo de elementos. Es frecuente emplear los paquetes para agrupar elementos de modelado y sus diagramas asociados. En un sistema trivial, se podrían agrupar todas las abstracciones en un paquete. Pero al organizar las clases y demás elementos de la vista de diseño en tres paquetes, no sólo se hace más comprensible el sistema, sino que se puede controlar el acceso a los elementos del modelo, ocultando unos y exportando otros.

2- Modelado de vistas Arquitectónicas: Los paquetes se pueden emplear para modelar las vistas de una arquitectura. Una vista es una proyección de la organización y estructura de un sistema, centrada en un aspecto particular del sistema. Esta definición tiene dos implicaciones. Primera, se puede descomponer un sistema en paquetes casi ortogonales, cada uno de los cuales cubre un conjunto de decisiones significativas arquitectónicamente. Segunda, esos paquetes contienen todas las abstracciones pertinentes para esa vista.



UNIDAD 8



Componentes del modelo

Esencial

A) Modelo Ambiental B) Modelo de Comportamiento

Herramientas Básicas

Herramientas

Adicionales

1- Declaración de Propósitos 2- Diagrama de Contexto 3- Lista de Acontecimientos o Diccionario de datos Inicial, para flujos y almacenes

externos o Modelo de Entidad-Relación, para almacenes

Enfoques Herramientas

Clásico De partición por Acontecimientos (x)

1- DFD

2- DER 3- DD 4- DTE 5- EP

Componentes

Niveles (Ascendente/Descendente)

Componentes Definiciones Elementos de Datos básicos Datos Opcionales Iteración Selección Alias

Componentes DTE Particionados Herramientas:

1- Lenguaje Estructurado 2- Pre/Post Condiciones 3- Tablas de Decisión 4- Gráficos y Diagramas 5- Lenguaje Narrativo 6- Diagrama de Flujo 7- Diagramas de Nassi-Shneidermart

Proceso o Burbuja Flujo Almacén Terminadores

Tipos de Objetos Relaciones Indicadores asociativos Indicadores de subtipo

/ supertipo

Estados Condiciones/Acciones


CAPÍTULO 9 – DIAGRAMAS DE FLUJO DE DATOS (DFD) Esta es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Otros nombres que toma el DFD son carta de burbujas, diagrama de burbujas, modelo de proceso, diagrama de flujo de trabajo, modelo de función, “una imagen de lo que está sucediendo aquí". Los DFD se utilizaron por primera vez en la ingeniería de software como notación para el estudio del diseño de sistemas. Estos diagramas se pueden utilizar para modelar sistemas de sistemas de proceso de información, y también para modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios. Componentes de un DFD La figura siguiente muestra un DFD típico para un sistema pequeño. Nótese que:

Prácticamente no requiere explicación. La notación es sencilla, clara e intuitiva, lo que sirve para

que el usuario lo entienda El diagrama cabe fácilmente en una página, por lo que se puede mirar sin problemas Se puede hacer en computadora, lo que lo hace mas claro a la vista

1. El proceso (también llamado burbuja, función o transformación)

El proceso muestra una parte del sistema que transforma entradas en salidas. El proceso se representa gráficamente como un círculo, como se muestra en la figura. El proceso se nombra o describe con una sola palabra, frase u oración sencilla, que por lo general indica la función que realiza. En algunos casos, el proceso describe quién o qué lo está efectuando, más que describir el proceso mismo.

2. El flujo El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Por ello, los flujos representan datos en movimiento. Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso, como se muestra en la figura. La dirección de la flecha determina si los


datos se están moviendo desde o hacia un proceso. Un flujo bidireccional es un diálogo, es decir, una pregunta y una respuesta en el mismo flujo.

El nombre del flujo representa el significado del paquete que se mueve a lo largo del mismo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo indica su nombre. El analista no debe dar al flujo un nombre como MANZANAS Y NARANJAS Y BANANAS. Debería ser un flujo llamado FRUTAS en este caso. Aunque parezca obvio, el mismo contenido de un flujo pudiera tener distintos significados en distintas partes del sistema. Cabe destacar que mediante el DFD no podemos indagar acerca de qué entradas producen cuáles salidas, ni en que secuencia llegan los flujos de datos. Los flujos de datos pueden ser: Convergentes: Varios paquetes elementales de

datos se están uniendo para formar agregados más complejos de paquetes de datos.

Divergentes: Se están mandando copias por duplicado de un paquete de datos a diferentes partes del sistema, o que un paquete complejo de datos se está dividiendo en varios paquetes individuales, o que el ducto de flujo de datos lleva artículos con distintos valores (por ejemplo, vegetales papa, cebolla, tomate, etc.) que están siendo separados.

3. Almacén

El almacén se utiliza para modelar una colección de paquetes de datos en reposo. El nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos (por convención). Cuando una burbuja debe enviar a otra un flujo de datos, puede colocarse un almacén entre medio debido a que los procesos ocurren en tiempos diferentes. Esto constituye un “almacén necesario”.

Otro tipo de almacenes son los “de implantación”. Se pueden colocar porque: Si ambos procesos se ejecutan en la misma computadora, pero no hay suficiente cantidad de algún

recurso de hardware para cubrir ambos al mismo tiempo, el almacén se crea como archivo intermedio, pues la tecnología de implantación disponible ha forzado a que los procesos se ejecuten en tiempos distintos.

Si el hardware es malo, se crea un almacén como respaldo de información Si diferentes programadores implantan los dos procesos, el almacén se crea para probar y corregir

posibles problemas El analista o el diseñador preveen necesidades futuras del usuario

Un flujo que sale de un almacén se interpreta como una lectura o un acceso a la información del almacén. Esto significa específicamente que:


Si el flujo no está etiquetado, significa que todo el paquete de información se está recuperando (es simplemente una convención cómoda).

Sí la etiqueta, del flujo es la misma que la del almacén significa que se recupera todo un paquete (o múltiples Instancias de uno completo). Ej: Almacén CLIENTES, donde cada paquete contiene nombre, domicilio y teléfono de los clientes Individuales. Así, un flujo típico del almacén podría implicar la recuperación de un paquete completo de información acerca de un cliente; Ej: se recuperan todos los clientes de Mendoza del almacén CLIENTES

Si la etiqueta del flujo es diferente del nombre del almacén, entonces se están recuperando uno o más componentes de uno o más paquetes. Ej: Recuperar sólo el teléfono; Recuperar los códigos postales de todos los clientes de MENDOZA

Debemos mencionar que el almacén es pasivo, y los datos no viajarán a lo largo del flujo a menos que el proceso lo solicite explícitamente. Además, la lectura de un almacén es no destructiva. Un flujo hacia un almacén habitualmente se describe como una escritura, una actualización o posiblemente una eliminación. Un punto que debiera ser evidente es que los flujos conectados a un almacén sólo pueden transportar paquetes de información que el almacén sea capaz de guardar. 4. Terminador

Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente, un terminador es una persona o un grupo, pero fuera del control del sistema que se está modelando. En algunos casos, un terminador puede

ser otro sistema, como algún otro sistema computacional con el cual se comunica éste. Existen tres cosas importantes que debemos recordar acerca de los terminadores:

Son externos al sistema que se está modelando; los flujos que conectan los terminadores a diversos procesos (o almacenes) en el sistema representan la interfaz entre él y el mundo externo.

El analista no puede modificar los contenidos, la organización ni los procedimientos internos asociados con los terminadores.

Las relaciones que existan entre los terminadores no se muestran en el modelo de DFD. Si existen relaciones entre los terminadores y si es esencial para el analista modelarlos para poder documentar los requerimientos del sistema, entonces, por definición, los terminadores son en realidad parte del sistema y debieran modelarse como procesos.

Construcción de un DFD

1- Escoger nombres con significado para los procesos, flujos, almacenes y terminadores. En vez de colocar el nombre de la persona que realiza el proceso, se debe colocar la función que el sistema está llevando a cabo. Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto.

Nombres Adecuados de procesos: Ej: calcular trayectoria del proyectil, producir informe de inventario, validar número telefónico, asignar estudiantes a la clase. Nombres Inadecuados de procesos: Ej: hacer algo, funciones misceláneas, manejar entradas, encargarse de clientes, datos de procesos, edición general, etc.

Los nombres de los procesos (al igual que los nombres de flujos y de terminadores) deben provenir de un vocabulario que tenga algún significado para el usuario. Esto sucederá de manera muy natural si el DFD se dibuja como resultado de una serie de entrevistas con los usuarios y si el analista tiene algún entendimiento mínimo de la materia de aplicación subyacente. Pero se deben tener en cuenta dos precauciones:


Hay una tendencia natural de los usuarios de utilizar abreviaturas y acrónimos específicos con los que están familiarizados, por lo que hay que evitar colocarlos en el DFD

Si el DFD lo dibuja alguien que tenga bases de programación, habrá la tendencia a utilizar terminología orientada a la programación. A menos que oiga a los usuarios utilizar esta terminología en su propia conversación, evite utilizarlas en su DFD.

2- Numerar el proceso

Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas numeran cada burbuja. No importa mucho cómo se haga esto, mientras haya constancia en la forma de aplicar los números. Lo único que se debe tener en mente es que el sistema de numeración implicará, para algunos lectores de su DFD, una cierta secuencia de ejecución. Esto no es así en absoluto. El modelo de DFD es una red de procesos asincrónicos que se intercomunican. Alguna secuencia pudiera implicarse por la presencia o ausencia de datos, pero el esquema de numeración no tiene nada que ver con eso. ¿Para qué numerar entonces las burbujas? Es una manera muy conveniente de referirse a los procesos. Es más fácil en una discusión animada sobre un DFD decir "burbuja 1" en lugar de "EDITAR TRANSACCIÓN Y REPORTAR ERRORES". Pero de mayor importancia aún es el hecho de que los números se convierten en base para la numeración jerárquica cuando se introduzcan los diagramas de flujo por niveles.

3- Evitar los DFD demasiado complejos

El propósito de un DFD es modelar de manera precisa las funciones que debe llevar a cabo un sistema y las interacciones entre ellas. Pero otro propósito del DFD es ser leído y comprendido, no sólo por el analista que construyó el modelo, sino por los usuarios. No se debe crear un DFD con demasiados procesos, flujos, almacenes y terminadores. En la mayoría de los casos, esto significa que no debiera haber más de media docena de cada uno de los elementos por diagrama. Otra manera de decir esto es que el DFD debe caber cómodamente en una hoja normal. Existe una excepción importante a esto: el diagrama de contexto, que representa el sistema entero como un solo proceso y destaca las interfaces entre el sistema y los terminadores externos.

4- Redibujar el DFD tantas veces como sea necesario

El DFD se redibujará tantas veces como sea necesario, es decir, hasta que: Sea técnicamente correcto Sea aceptable para el usuario Esté lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a la

dirección de la organización. ¿Que hace estéticamente agradable a un DFD? La estética de cualquier diagrama es subjetiva, pero podemos destacar:

Tamaño y forma de las burbujas Flujos curvos vs. rectos Diagramas hechos a mano vs. diagramas generados por máquina.

5- Asegúrese de que su DFD sea lógicamente consistente

Las principales reglas de consistencia son: Evitar sumideros infinitos (agujeros negros): Son burbujas que tienen entradas pero no

salidas Evitar burbujas de generación espontánea, que tienen salidas sin tener entradas, porque son

sumamente sospechosas y generalmente incorrectas.


Tenga cuidado con los flujos y procesos no etiquetados. Esto suele ser un indicio de falta de esmero, pero puede esconder un error aún más grave: a veces el analista no etiqueta un flujo o un proceso porque simplemente no se le ocurre algún nombre razonable.

Tenga cuidado con los almacenes de "sólo lectura" o "sólo escritura". Esta regla es análoga a la de los procesos de "únicamente entradas" o "únicamente salidas".

DFD por niveles Consideremos por ejemplo el DFD que se muestra en la figura. ¿Puede imaginarse mostrándole esto al usuario típico? Debemos evitar

diagramas como el de la figura. ¿Pero cómo, si el sistema es intrínsecamente complejo y tiene docenas o incluso cientos de funciones que modelar? La respuesta es organizar el DFD global en una serie de niveles de modo que cada uno proporcione sucesivamente más detalles sobre una porción del nivel anterior.

El DFD del primer nivel (Diagrama de Contexto) consta sólo de una burbuja, que representa el sistema completo; los flujos de datos muestran las interfaces entre el sistema y los terminadores y almacenes externos.

El DFD que sigue se conoce como la figura 0. Representa la vista de más alto nivel de las principales funciones del sistema, al igual que sus principales interfaces. Recordemos que era conveniente numerar las burbujas. Los números también sirven como una manera adecuada de relacionar una burbuja con el siguiente nivel del DFD que la describe más a fondo.

Por ejemplo: La burbuja 2 en la figura 0 se asocia con un DFD inferior conocido como figura 2. Las burbujas

de la figura 2 se numeran 21, 2.2, 2.3, etc. La burbuja 3 de la figura 0 se asocia con un DFD inferior conocido como figura 3, las burbujas de

la figura 3 se numeran 3.1, 3.2, 3.3, etc. La burbuja 2.2 de la figura 2 se asocia con un DFD de nivel inferior conocido como figura 2.2.

Las burbujas de ésta se numeran 2.2.1. 2.2.2, 2.2.3, etc.


Sí una burbuja tiene nombre (que en realidad debiera tenerlo) entonces dicho nombre se reutiliza en la figura de nivel inmediato inferior. Así, si la burbuja 2.2 se llama CALCULAR IMPUESTO DE VENTA, entonces la figura 2.2, que parte la burbuja 2.2 en más detalles, debe etiquetarse "figura 2.2: CALCULAR IMPUESTO DE VENTA".

FAQ: ¿Cómo saber cuántos niveles debe haber en un DFD? Cada DFD debe tener no más de media docena de burbujas y almacenes relacionados. Otra alternativa de verificación: si no podemos escribir una especificación de proceso razonable para una burbuja en alrededor de una página, entonces es probable que sea demasiado compleja y debiera partirse en DFD de menor nivel.

¿Existen reglas acerca del número de niveles que debieran esperarse en un sistema típico? En un sistema simple, probablemente se encentrarán dos o tres niveles; uno mediano tendrá generalmente de tres a seis niveles; uno grande tendrá de cinco a ocho niveles.

¿Deben partirse todas las partes del sistema con el mismo nivel de detalle? No. Algunas partes del sistema pueden ser más complejas que otras y pueden requerir uno o más niveles de partición.

¿Cómo se muestran estos niveles al usuario? Si alguien quiere ver una parte más extensa del sistema, o tal vez todo, entonces tiene sentido presentar los diagramas de una manera descendente:

¿Cómo asegurar que los niveles del DFD sean consistentes entre sí?: Los flujos de datos que salen y entran de una burbuja en un nivel dado deben corresponder con los que entran y salen de toda la figura en el nivel inmediato inferior que la describe.

¿Cómo se muestran los almacenes en los diversos niveles? Se debe mostrar un almacén en el nivel más alto donde primeramente sirve de interfaz entre dos o más burbujas; luego, mostrarlo de nuevo en CADA diagrama de nivel inferior que describa más a fondo (o parta más) dichas burbujas de interfase. Los almacenes locales, que utilizan sólo las burbujas en una figura de menor nivel, no se mostrarán en niveles superiores, dado que se incluyen de manera implícita en un proceso del nivel inmediato superior. Extensiones del DFD para sistemas de tiempo real Para los sistemas de tiempo real, necesitamos alguna manera de modelar flujos de control (es decir señales o interrupciones). Y se requiere una manera de mostrar procesos de control (burbujas cuya única labor es coordinar y sincronizar las actividades de otras burbujas del DFD). Las mismas se muestran gráficamente con líneas punteadas en el DFD, como lo ilustra la figura. Un proceso de control puede considerarse como una burbuja supervisora o ejecutiva, cuya labor es coordinar las actividades de otras burbujas en el diagrama; sus entradas y salidas consisten sólo de flujos de control. Un flujo de control saliente puede imaginarse como un conducto que porta sólo una señal binaria, que se envía desde un proceso de control hacia otras burbujas con el fin de “despertarlas”, para que realicen su labor descripta en la especificación de procesos. Los flujos de control entrantes generalmente indican que una de las burbujas ha terminado su labor o que se ha presentado alguna situación extraordinaria, de la cual necesita informarse a la burbuja de control. Por lo común sólo hay un proceso de control de estos en un DFD dado. El comportamiento interno de un proceso de control es diferente. El interior del proceso de control se modela con un diagrama de transición de estados, que muestra los varios estados en los que se puede encontrar todo el sistema y las circunstancias que lo llevan a cambiar de estado.



CAPÍTULO 10 - EL DICCIONARIO DE DATOS (DD)

El 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. Sin él, el usuario se extraviará y no podría estar seguro de que entendió los detalles de la aplicación. El diccionario de datos define los datos haciendo lo siguiente:

Describe el significado de los flujos y almacenes que se muestran en los DFD. Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los flujos,

es decir, paquetes complejos, que pueden descomponerse en unidades más elementales Ej: domicilio se compone de ciudad, estado y código postal

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 se enfatizan en un DER.

Notación del diccionario de datos = está compuesto de + y () optativo (puede estar presente o ausente) {} iteración [] seleccionar una de varias alternativas ** comentario @ identificador (campo clave) para un almacén | separa opciones alternativas en la construcción Por ejemplo, se puede definir el nombre así: nombre = título de cortesía + nombre + (segundo nombre)+ apellido título de cortesía = [Sr. | Srta. | Sra. | Dr. | Profesor] nombre = {carácter legal} segundo nombre = {carácter legal} apellido = {carácter legal} carácter legal = [A-Z | a-z | 0-9 | ' | |-|] Definiciones La definición de un dato se introduce con el símbolo "=". En este contexto, el "=" se lee: "se define como", o "se compone de", o "significa".

Por ejemplo: A = B + C puede leerse de las siguientes maneras: Cuando digamos A, queremos decir una B y una C A se compone de B y C A se define como B y C

Para definir por completo un dato, nuestra definición debe incluir lo siguiente: El significado del dato dentro del contexto de la aplicación de este usuario. Por lo común se ofrece

como comentario utilizando la notación "**" La composición del dato, si se compone de partes elementales con significado. Los valores que puede tomar el dato, si es un dato elemental


Por ejemplo: peso = *peso del paciente al ser admitido al hospital* *unidades: kilogramos; gama 1-200* estatura = *estatura del paciente al ser admitido al hospital*

*unidades: centímetros; escala: 20-200*

Además de las unidades y la escala, podría requerirse la especificación de la precisión de la medición del dato. Elementos de datos básicos Las partes elementales de los datos son aquellas para las cuales ya no existe una descomposición con significado dentro del contexto del ambiente del usuario. Esto usualmente es una cuestión de aplicación y es algo que se debe explorar cuidadosamente con el usuario. Cuando se han identificado los datos elementales, deben introducirse al diccionario de datos. Como se indicó anteriormente, el diccionario de datos debe proporcionar una breve narrativa, encerrada entre caracteres "*", que describa el significado del término en el contexto del usuario. Desde luego, habrá términos que se definan solos, es decir, cuyo significado es universal para todos los sistemas de información, o donde el analista pudiera estar de acuerdo en que no se necesita aclarar más.

Por ejemplo, los siguientes pudieran considerarse términos que se autodefinen en un sistema que maneja información sobre personas:

estatura actual; peso actual; fecha de nacimiento; sexo; teléfono particular

En estos casos no se necesita un comentario narrativo; muchos analistas usan la notación "**" para indicar "sin comentarios" cuando el dato se defina solo. Sin embargo, es importante especificar los valores y unidades de medida que los datos elementales pueden tomar.

Por ejemplo: peso actual = ** *unidades:kilogramos; escala: 1-400* fecha de nacimiento = **

*Unidades: días a partir del 1- de enero de 1900; escala: 0- 36500* sexo = ** *valores: [M | F]*

Datos opcionales Un dato opcional, como la frase implica, es aquel que puede estar o no presente en un dato compuesto.

Existen muchos ejemplos como: El nombre de un cliente pudiera no incluir un segundo nombre El domicilio de un cliente pudiera incluir o no información secundaria, como el número de

departamento. El pedido de un cliente pudiera contener el domicilio al que se tiene que mandar la cuenta, el

domicilio al que hay que hacer el envío, o ambos.

Las situaciones de este tipo deben verificarse con cuidado con el usuario y deben documentarse precisamente en el diccionario de datos.

Por ejemplo, la notación domicilio de cliente = (domicilio de envío) + (domicilio para cuenta) significa, literalmente, que el domicilio del cliente pudiera consistir en:

sólo un domicilio de envío sólo un domicilio para enviar cuentas un domicilio de envío y uno para cuentas ninguno de los dos


Desde luego, la única manera de saber esto es pedirle al usuario que explique con cuidado las implicaciones de las diferentes notaciones que se mostraron. Iteración La notación de iteración se usa para indicar la ocurrencia repetida de un componente de un dato. Se lee como "cero o más ocurrencias de".

Así, la notación solicitud = nombre del cliente + domicilio de envío + {artículo} Significa que la solicitud siempre debe contener un nombre de cliente, un domicilio de envío, y también cero o más ocurrencias de un artículo. En muchas situaciones reales, el usuario querrá especificar los límites inferior y superior de la iteración. Puede indicarse esto de la siguiente forma:

solicitud = nombre del cliente + domicilio de envío + 1{artículo}10 donde 1 es el límite inferior y 10 el límite superior

Es correcto especificar sólo el límite inferior, sólo el límite superior, ambos, o ninguno. Selección La notación de selección indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Las opciones se encierran en corchetes "[" y "]" y se separan por una barra vertical "|". Como ejemplo típico tenemos:

sexo = [Femenino | Masculino]

Es importante revisar las opciones de selección con el usuario para asegurarse de cubrir todas las posibilidades. Alias Un alias es una alternativa de nombre para un dato. Esto es una ocurrencia común cuando se trata con diversos grupos de usuarios en diferentes departamentos o ubicaciones geográficas (y a veces con diferentes nacionalidades e idiomas), que insisten en utilizar distintos nombres para decir lo mismo. El alias se incluye en el diccionario de datos para que esté completo, y se relaciona con el nombre primario u oficial del dato. Por ejemplo:

comprador = *alias de cliente*

Aun cuando el diccionario de datos relaciona correctamente los alias con el nombre primario de los datos, debe evitarse el uso de alias hasta donde sea posible. Es mejor, de ser posible, lograr que todos los usuarios se pongan de acuerdo en un solo nombre.

Implantación del diccionario de datos Como el diccionario de datos suele ser de tamaño considerable, conviene utilizar una PC para realizarlo, verificar que estén completas y consistentes las entradas, y producir reportes apropiados. Si su organización está utilizando cualquier sistema moderno de administración de bases de datos, se debe tener cuidado de las siguientes limitaciones posibles:

Pudiera verse forzado a limitar los nombres de datos a cierta longitud Podría haber otras limitaciones artificiales para el nombre. Podría verse obligado a asignarle atributos físicos (por ejemplo, número de bytes, o bloques de

almacenamiento en disco, o representaciones como decimales redondeados) a un dato, aun cuando no sea cuestión del usuario.

Las mismas pueden consultarse en la ayuda de tales Sistemas de Bases de Datos


CAPÍTULO 11- ESPECIFICACIONES DE PROCESO En este capítulo se explora la especificación del proceso, la descripción de qué es lo que sucede en cada burbuja primitiva de nivel más bajo en un DFD, es decir, definir lo 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. Las especificaciones de proceso pueden realizarse con herramientas como tablas de decisiones, lenguaje estructurado, pre/post condiciones, diagramas de flujo, diagramas de Nassi/Shneiderman, etc. A pesar de que la mayoría de los analistas están a favor del lenguaje estructurado, se puede usar cualquier método mientras satisfaga dos requerimientos cruciales:

La especificación del proceso debe expresarse de una manera que puedan verificar tanto el usuario como el analista: Precisamente por esta razón se evita el lenguaje narrativo como herramienta de especificación.

El proceso debe especificarse en una forma que pueda ser comunicado efectivamente al público amplio que esté involucrado.

Como analista, uno debe sentirse libre para utilizar una combinación de herramientas de especificación, según las preferencias del usuario, las propias preferencias y la naturaleza propia de los diversos procesos. Una buena herramienta de especificación de proceso no debe imponer (o implicar) decisiones de diseño e implantación arbitrarias. Las especificaciones de proceso sólo se desarrollan para los procesos de más bajo nivel en un conjunto de diagramas por niveles en un DFD. En este capítulo nos concentraremos en tres herramientas principales de especificación de proceso:

Lenguaje estructurado (español, inglés, etc.) Pre/post condiciones Tablas de decisión

1- Lenguaje Estructurado (Psl o Pdl) El lenguaje estructurado 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 que pueden utilizarse y la manera en que pueden juntarse dichas frases. Su propósito es hacer un balance razonable entre la precisión del lenguaje formal de programación, y la informalidad y legibilidad del lenguaje cotidiano. Una frase en lenguaje estructurado puede consistir en una ecuación algebraica, o en una sencilla frase imperativa que consista en un verbo y un objeto. Nótese que las frases que describen los cálculos pueden usarse con prefijos de los verbos CALCULAR, AÑADIR, FIJAR, etc. X = (Y*Z)/(Q+14) CALCULAR X = (Y*Z)/(Q+14) Los verbos deben escogerse de entre un pequeño grupo de verbos orientados a la acción: Ej: conseguir ( o aceptar o leer), poner (o mostrar o escribir), encontrar (o buscar o localizar), sumar, restar, multiplicar, dividir, calcular, borrar, encontrar, validar, mover, reemplazar, fijar, ordenar En muchas organizaciones se llega a la conclusión de que entre 40 y 50 verbos son suficientes para describir cualquier política dentro de una especificación de proceso. Los objetos (el tema de las frases imperativas sencillas) deben consistir sólo en datos que se han definido en el diccionario o ser términos locales. Los términos locales son aquellos que se definen explícitamente en una especificación de proceso individual, y sólo son conocidos, relevantes y con significado dentro de


dicha especificación de proceso. Un ejemplo típico de término local es un cálculo intermedio, que se utiliza para producir una salida final del proceso. El lenguaje estructurado permite que se combinen frases en unas cuantas formas limitadas que se toman de las construcciones acostumbradas de la programación estructurada, como por ejemplo:

SI <condición> , [OTRO] FinSI HACER CASO. CASO 1 …. CASO n . OTRO HACER-MIENTRAS <acciones> FINHACER REPITE-HASTA

Se pueden construir frases compuestas a partir de combinaciones de frases sencillas y las estructuras sencillas que se presentaron anteriormente, de acuerdo con las siguientes reglas:

1. Una secuencia lineal de frases sencillas equivale estructuralmente a una frase sencilla única y puede ser sustituida dondequiera que se espere una frase sencilla

2. Una construcción SI-ENTONCES-OTRO sencilla se considera estructuralmente equivalente a una frase única sencilla. Esto permite que las estructuras SI-ENTONCES-OTRO se aniden dentro de otras estructuras iguales, o dentro de estructuras HACER-MIENTRAS, o dentro de estructuras CASO.

3. Una estructura HACER-MIENTRAS sencilla se considera estructuralmente equivalente a una frase única sencilla. Esto permite que las estructuras HACER-MIENTRAS se aniden dentro de otras estructuras iguales, o dentro de estructuras SI-ENTONCES-OTRO, o dentro de estructuras CASO.

4. Una estructura sencilla CASO se considera estructuralmente equivalente a una frase única sencilla. Esto permite que las estructuras CASO se aniden dentro de otras iguales, dentro de estructuras SI-ENTONCES-OTRO o dentro de estructuras HACER-MIENTRAS.

Como puede verse, esto permite construir arbitrariamente descripciones complejas de políticas de negocios, que a la vez mantienen un control estricto sobre el vocabulario, organización y estructura de la descripción. Sin embargo, esta complejidad es también la principal desventaja del lenguaje estructurado: si el analista compone una especificación de proceso demasiado compleja para ser entendida y verificada por el usuario, entonces falló. Esto usualmente se puede evitar mediante las siguientes tres reglas:

1. Restrinja la especificación de proceso en lenguaje estructurado a una sola página de texto. Si la especificación ocupa más de una página, entonces el analista debe pensar en una forma totalmente distinta de formular la política. Si no se puede, entonces es posible que el proceso mismo (esto es, la burbuja dentro del DFD) sea demasiado complejo, y debe partirse en una red de procesos más simples de nivel inferior.

2. No permita más de tres niveles de anidamiento 3. Evite confusiones acerca de los niveles de anidamiento utilizando sangrías.

¿Se puede esperar que el usuario lea y entienda una especificación de proceso escrita en lenguaje estructurado? Sí, pero con las siguientes advertencias:

1. Se debe revisar el documento para asegurarse de que entiendan el formato y las diversas construcciones.

2. No se refiera a la especificación del proceso como "lenguaje estructurado", sino como "una descripción formal de la política de negocios para realizar esta actividad".

3. Ponga mucha atención al formato global y la distribución del documento 2- 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á. Es útil cuando:

1. 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. 2. El analista está razonablemente seguro de que existen muchos algoritmos distintos que podrían

usarse. 3. El analista desea que el programador explore varios de estos algoritmos, pero no quiere

involucrarse personalmente con tales detalles y, sobre todo, no quiere enredarse en discusiones con el usuario acerca del mérito relativo de cada uno.

ESPECIFICACIÓN DE PROCESO: CALCULAR EL IMPUESTO SOBRE VENTAS

Precondición 1 Ocurre DATOS-VENTA con TIPO-ÍTEM que corresponde con CATEGORÍA-ÍTEM en CATEGORÍAS-IMPUESTO Postcondición 1

IMPUESTO-SOBRE-VENTA se hace igual a MONTO-VENTA * IMPUESTO

Precondición 2 Ocurre DATOS-VENTA con TIPO-ITEM que no concuerda con CATEGORIA-ITEM en CATEGORÍAS-IMPUESTO Postcondición 2 Se genera MENSAJE-ERROR

Las precondiciones describen todas las cosas (si hay) que deben darse antes de que el proceso pueda comenzar a ejecutarse. Típicamente, las precondiciones describirán:

1. Qué entradas se encuentran disponibles: Estas entradas llegan mediante un flujo conectado con un proceso, como se muestra en el DFD. Nótese que puede haber casos en los que diversos flujos entran a un proceso, pero sólo uno de ellos es precondición necesaria para que se active el proceso.

2. Qué relación debe existir entre las entradas: Muy a menudo, una precondición especificará que deben llegar dos entradas con campos que corresponden (Ej: detalles de pedidos y detalles de envío con el mismo número de cuenta). O bien, la precondición puede especificar que un componente de un dato de entrada debe estar dentro de cierto intervalo. Ej: "pedido con fecha de entrega a más de 60 días"

3. Qué relaciones deben existir entre entradas y almacenes de datos: Una precondición pudiera estipular que exista un registro dentro de un almacén que corresponda con algún aspecto de un dato de entrada. Ej. la precondición puede establecer que "hay un pedido-de-cliente con número-de-cuenta-de-cliente que corresponde con un número-de-cuenta, de-cliente del almacén de clientes"

4. Qué relaciones deben existir entre diferentes almacenes o dentro de un almacén dado: Es decir, la precondición podría establecer que "hay un pedido en el almacén de pedidos cuyo número-de-cuenta-de-cliente corresponde con el número-de-cuenta-del-cliente en el almacén de clientes"

Las postcondiciones describen lo que debe darse cuando el proceso ha concluido. Las postcondiciones típicamente describen lo siguiente:

1. Las salidas que generará o producirá el proceso. Esta es la forma más común de postcondición. Ej: "se producirá una factura"

2. Las relaciones que existirán entre los valores de salida y los valores originales de entrada. Esto es común para la situación donde una salida es una función matemática directa de un valor de entrada. Ej: "la factura-total se calcula como la suma de precios-unitarios-de-artículos más costos-de-envío"

3. Las relaciones que existirán entre valores de salida y los valores en uno o varios de los almacenes. Esto es común cuando la información debe recuperarse de un almacén y utilizarse como parte de la salida de un proceso. Ej: "el balance-actual en el almacén INVENTARIO se incrementará con cantidad-recibida, y el nuevo balance-actual se producirá como salida de este proceso."

4. Los cambios que se hayan dado en los almacenes: nuevos artículos añadidos, artículos existentes


que se hayan modificado, o artículos existentes que se hayan eliminado. Ej: "el pedido se anexará al almacén de PEDIDOS"

Cuando se esté construyendo una especificación de pre/post condiciones se debe comenzar por describir las situaciones normales de proceso. Después de haber descrito las situaciones normales de proceso, deben incluirse precondiciones y postcondiciones apropiadas para los casos de error y casos anormales.

Ejemplo de especificación narrativa Si un cliente dice que está clasificado como cliente que puede llevar mercancía "a su cuenta" cuando llega a la caja a pagar, entonces busco su cuenta en mi archivo. Si la encuentro, y no está señalada como "suspendida" o "cancelada", entonces cargo ¡a mercancía a su cuenta con el número de ésta y el monto de la venta. De otra manera, le digo que tendrá que pagar en efectivo o hablar con el gerente.

Ejemplo de pre/post condiciones Precondición 1 El comprador llega con un número-de-cuenta que corresponde con un número de cuenta en CUENTAS, cuyo código-de-status se pone en "válido". Postcondición 1 Se produce una factura con número-de-cuenta y monto-de- venta. Precondición 2 La precondición 1 falla por algún motivo (el número-de- cuenta no se encuentra en CUENTAS, o el código-de status no es "válido"). Postcondición 2 Se produce un mensaje de error.

Aunque el enfoque de pre/post condiciones sea bastante útil y tenga un gran número de ventajas, hay ocasiones en las cuales puede no ser apropiado. Si existen relaciones complejas entre entradas y salidas, podría ser más fácil escribir una especificación utilizando lenguaje estructurado. 3- Tablas de Decisión Si las decisiones se basan en diversas variables distintas, y si dichas variables pueden tornar diversos valores, entonces la lógica expresada por el lenguaje estructurado o por las pre/post condiciones probablemente sea tan compleja que el usuario no la comprenderá. Probablemente sea preferible una tabla de decisiones. Una tabla de decisiones se crea listando todas las variables relevantes (condiciones o entradas) y todas las acciones relevantes en su lado izquierdo. En muchas aplicaciones es fácil y preferible, expresar las variables como binarias, pero también se pueden construir las tablas de decisión a partir de variables multivaluadas. En columnas separadas (o regla) se lista cada combinación posible de valores de las variables. 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 debe especificarse una acción para cada regla o el comportamiento del sistema para tal situación no quedará especificado.

1 2 3 4 5 6 7 8 Edad>21 Y Y Y Y N N N N Sexo M M F F M M F F Peso>100 Y N Y N Y N Y N Medicamento 1 X X X Medicamento 2 X X Medicamento 3 X X X Ningún medicamento X X


Es bastante común, al hacer esto, encontrar que el usuario jamás ha pensado en ciertas combinaciones de variables, o que nunca hayan ocurrido en su experiencia. La ventaja del enfoque de la tabla de decisiones es que el analista se puede concentrar en una regla a la vez. Otra ventaja del enfoque de la tabla de decisiones es que no implica ninguna forma particular de implantación. Pasos para crear una tabla de decisiones para una especificación de proceso:

1. Identificar todas las condiciones, o variables, de la especificación, identificar todos los valores que cada variable pueda tomar.

2. Calcular el número de combinaciones de las condiciones. 3. Identificar cada posible acción que se pide en la especificación. 4. Crear una tabla de decisiones "vacía", listando todas las condiciones y acciones en el lado

izquierdo y numerando las combinaciones de las condiciones en la parte superior de la tabla. 5. Listar todas las combinaciones de condiciones, una para cada columna de la tabla.

6. Examinar cada columna (regla) e identificar las acciones apropiadas que se deben tomar. 7. Identificar con el usuario las omisiones, contradicciones o ambigüedades.

4- Gráficas y diagramas En algunos casos puede ser apropiado expresar una especificación de proceso como una gráfica o diagrama. El usuario pudiera tener ya una gráfica o diagrama que se esté utilizando para llevar a cabo aquella parte de la aplicación. De ser así, úsela, y deje que el programador traduzca la gráfica directamente al lenguaje de programación, cuando sea el momento de implantar el sistema. Ej: Una especificación de proceso que determina el monto del seguro del cliente como función de su edad. El usuario dijo que la política actual de negocio es determinar el monto a partir de una gráfica 5- Lenguaje Narrativo El lenguaje narrativo no es una herramienta recomendable para escribir especificaciones de proceso, debido a que:

1. Un vocabulario no restringido hace que sea probable que la descripción del proceso incluya términos que no estén en el diccionario de datos y cuyo significado no quede claro.

2. Las acciones alternativas y ciclos (o decisiones) a menudo se expresan de una manera burda y ambigua. Esto se vuelve aún más peligroso cuando se expresan decisiones y ciclos anidados.

3. El concepto de estructuras de bloque sólo se puede expresar con sangrías o con una presentación de "silueta", por lo que conviene el lenguaje estructurado.

Si por alguna razón se ve obligado a usar lenguaje narrativo, se debe tratar de escribir la especificación lo más corta posible. 6- Diagramas de Flujo Se ha evitado hasta ahora el uso de diagramas de flujo en el análisis, debido a la falta de interés actual por ellos. Como herramienta de alto nivel de modelado de sistemas, los diagramas de flujo son muy malos; conviene utilizar los DFD. Sin embargo, no hay nada que impida que el analista pueda crear un diagrama de flujo no estructurado y arbitrariamente complejo. Si el diagrama de flujo se usa sólo para describir lógica detallada y el analista se limita a los símbolos de elaboración de diagramas de flujo equivalentes a las construcciones del español (u otro lenguaje) estructurado, entonces no tiene nada de incorrecto su uso. Debe señalarse que muy pocos analistas utilizan diagramas de flujo para especificaciones de proceso (ni, para diseño), debido a que son más difíciles de crear y mantener.


7- Diagramas de Nassi-Shneidermart Cuando por primera vez se empezó a volver popular la programación estructurada a mediados de los años 70, los diagramas de Nassi-Shneiderman se introdujeron como una técnica estructurada de creación de diagramas de flujo. Estos diagramas usualmente son más organizados, más estructurados y más comprensibles que un diagrama de flujo típico; por ello, a veces se los prefiere como herramienta para crear especificaciones de proceso. Sin embargo, aún requieren una cantidad notoria de gráficos, y no está claro que los gráficos añadan mucho valor.


CAPÍTULO 12 - DIAGRAMAS DE ENTIDAD – RELACIÓN (DER o ER) El diagrama de entidad-relación es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema. Es muy diferente del DFD, que modela las funciones que lleva a cabo un sistema; y es diferente del diagrama de transición de estados, que modela el comportamiento dependiente del tiempo de un sistema. ¿Por qué podríamos estar interesados en modelar los datos de un sistema? Primero, porque las estructuras de datos y las relaciones pueden ser tan complejas que se desea enfatizarlas y examinarlas independientemente del proceso que se llevará a cabo. Esto se da, por ejemplo, si mostramos el modelo del sistema a los usuarios ejecutivos de una organización, quienes podrían no estar interesados en los detalles funcionales cotidianos del sistema. Tales usuarios a menudo se preocupan más por los datos. El DER es una herramienta efectiva de modelado para comunicarse con el grupo de administración de bases de datos (ABD) de una organización. Basándose en la información presentada por el DER, el grupo de ABD puede ver el tipo de claves o índices o apuntadores que se necesitarán para llegar de manera eficiente a los registros de las bases de datos. Para el analista, el DER destaca las relaciones entre almacenes de datos en el DFD que de otra forma se hubieran visto sólo en la especificación de proceso.

En la figura, un DER, cada una de las cajas rectangulares corresponde a un almacén de datos en un DFD, y puede verse que hay relaciones que normalmente no se aprecian en un DFD. Esto se debe a que el DFD enfoca la atención del lector a las funciones que el sistema efectúa, no a los datos que ocupa. Los componentes de un DER son: 1. Tipos de objetos

Se grafica por medio de una caja rectangular. Representa un conjunto de objetos (cosas) del mundo real cuyas instancias tienen las siguientes características:

Cada una puede identificarse de manera única por algún medio: Si se tiene un tipo de objeto conocido como CLIENTE, debemos ser capaces de distinguir uno de otro (tal vez por un número de cuenta, por su apellido, o por su número de Seguro Social).

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: Es decir, un CLIENTE puede describirse por medio de datos tales como nombre, domicilio, límite de crédito y número telefónico.

En muchos de los sistemas que desarrolle, los tipos de objetos serán la representación en el sistema de algo material del mundo real.


Ej: clientes, artículos de inventario, empleados, etc. Son objetos típicos. El objeto es el algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo, un objeto también pudiera ser algo no material: por ejemplo, horarios, planes, estándares, estrategias y mapas. Nótese que en todos los ejemplos de un objeto se ha usado un sustantivo singular. Esto no es necesario, pero es un convenio útil; ya que, como se verá mas adelante, existe una correspondencia entre objetos en el DER y almacenes en el DFD. Así, si existe un objeto CLIENTE en el DER, debe haber un almacén de CLIENTES en el DFD. 2. Relaciones

Los objetos se conectan entre sí mediante relaciones. Una relación representa un conjunto de conexiones entre objetos, y se representa por medio de un rombo

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. Así, en la figura, 1a relación COMPRAS puede contener las siguientes instancias individuales:

Instancia 1: el cliente 1 compra el artículo 1 Instancia 2: el cliente 2 compra los artículos 2 y 3 Etc…

La relación representa algo que debe ser recordado por el sistema, es decir, la memoria del sistema. Así, la figura nos indica que existe alguna razón relacionada con el usuario para recordar el hecho de que el cliente 1 compra el artículo 1, etc. Y la relación también indica que no existe nada a priori que hubiera permitido determinar que el cliente 1 compró el artículo 1 y nada más.

Puede existir más de una relación entre dos objetos. La figura implica que la relación de recibos está completamente separada de la relación de tratamiento: tal vez a algunos pacientes se les dan recibos sólo por su primer tratamiento, mientras que a otros se les dan para cada tratamiento y a otros jamás se les dan.

Una situación más común es ver múltiples relaciones entre múltiples objetos. Con un diagrama complejo como el de la figura, la relación y sus tipos de objetos deben leerse como una unidad. La relación se puede describir desde la perspectiva de cualquiera de los tipos de objetos participantes, y todas esas perspectivas son válidas. De hecho, el conjunto de todos estos puntos de vista es el que describe completamente la relación.


Por ejemplo, en la figura puede verse la relación de negociación de precios en cualquiera de las siguientes tres formas: El agente de bienes raíces negocia el precio entre el cliente y el vendedor. El cliente negocia el precio con el vendedor, mediante el agente de bienes raíces. El vendedor negocia el precio con el cliente, mediante el agente de bienes raíces.

Notación Alternativa En el DER, las relaciones son multidireccionales y no muestran la cardinalidad. Una notación alternativa utilizada por algunos analistas muestra tanto la cardinalidad como la ordinalidad.

Figura 12.6(b): Notación alternativa para relaciones de uno a muchos

3. Indicadores asociativos de tipo de objeto Una notación especial en el DER es el indicador asociativo de tipo de objeto, que representa algo que funciona como objeto y como relación. Es decir, representa una relación acerca de la cual se desea mantener alguna información.

4. Indicadores de supertipo/subtipo Los tipos de objeto de subtipo/supertipo consisten en tipos de objeto de una o más subcategorías, conectados por una relación. Los subtipos se conectan al supertipo por medio de una relación sin nombre; el supertipo se conecta a la relación con una línea que contiene una barra.


En esta notación el supertipo se describe por datos que se aplican a todos los subtipos. Sin embargo, cada subtipo se describe por medio de datos diferentes; de otro modo, no tendría caso hacer distinción entre ellos.

Reglas para la construcción de diagramas de entidad-relación No espere que el primer diagrama E-R que haga sea el final. Como los diagramas de flujo de datos y todas las demás herramientas de modelado, los diagramas E-R deben revisarse y mejorarse muchas veces; la primera versión típicamente no será más que un borrador, y las versiones subsecuentes se producirán utilizando una serie de reglas de refinamiento que se presentan en esta sección. Algunas de las reglas de refinamiento llevan a la creación de tipos adicionales de objeto, mientras que otras llevarán a la eliminación de objetos y/o relaciones. Añadir tipos de objetos adicionales Después de haber desarrollado el primer DER, debemos asignar los datos del sistema a los diversos tipos de objetos. Se supone, desde luego, que sabe cuáles son los datos.

El proceso de asignación puede ofrecer una de tres razones para crear nuevos tipos de objetos:

Es posible descubrir datos que se pueden asignar a algunas instancias de un tipo de objeto pero no a otras.

Pudieran descubrirse datos aplicables a todas las instancias de dos objetos distintos. Podría descubrirse que algunos datos describen relaciones entre otros tipos de objetos.

Si durante el proceso de asignar datos a tipos de objetos encuentra que algunos datos no se pueden aplicar a todas las instancias de algún tipo de objeto dado, necesitará crear un conjunto de subtipos abajo del tipo de objeto con el que ha estado trabajando, y asignar los datos específicos a los subtipos apropiados. En la mayoría de los casos el proceso de crear nuevos subtipos y asignarles datos de manera apropiada es bastante directo. Sin embargo, debe tenerse siempre en mente una situación excepcional: pudiera suceder que todos los datos relevantes se atribuyan a uno de los subtipos, y que ninguno de los datos se pueda asignar al objeto supertipo. En este caso, el supertipo no se aplica También puede ocurrir la situación inversa: los datos pueden describir instancias de dos (o más) tipos distintos de objetos de la misma manera. Si esto ocurre, debe crearse un supertipo nuevo y asignarte los datos comunes al supertipo. Finalmente, tenemos el caso de grupos que se repiten. Considere, por ejemplo, el tipo de objeto EMPLEADO, contiene múltiples instancias de información de HIJO. En este caso, el tipo de objeto que


inicialmente se imaginó de la forma que muestra la primera figura debe transformarse en dos objetos tipo conectados por una nueva relación.

Eliminar tipos de objetos Existe un buen número de situaciones en las que los refinamientos del DER llevan a la eliminación de tipos de objetos y relaciones redundantes o erróneas. Examinaremos cuatro situaciones comunes:

1. Tipos de objetos que consisten sólo en un identificador: Si se tiene un diagrama E-R en el cual uno de los tipos de objeto tiene sólo un identificador asignado como dato, existe la oportunidad de eliminar el tipo de objeto y asignar el identificador, como dato, a un tipo de objeto relacionado. Esto se puede siempre y cuando la relación sea 1 a 1.

2. Tipos de objeto para los cuales existe una sola instancia 3. Tipos asociativos de objetos flotantes (un objeto con otro de una sola instancia) 4. Relaciones derivadas o calculadas

Extensiones al diccionario de datos para DER Finalmente, observamos que el diccionario de datos necesita extenderse para tomar en cuenta la notación de DER discutida en este capítulo. En general, los objetos del DER corresponden con almacenes del DFD. Esto significa que en la definición sacada del diccionario de datos que se da a continuación, CLIENTE es tanto definición del tipo de objeto como instancia del almacén CLIENTES. CLIENTES = {CLIENTE} CLIENTE = @nombre-del-cliente + domicilio + número- telefónico Nótese también que la definición de un CLIENTE incluye la especificación del campo llave (@), que es el dato (o atributo) que diferencia una instancia de un cliente de cualquier otra. Sin embargo, también hay que incluir en el diccionario de datos una definición de todas las relaciones que se muestran en el DER. La definición de relación debe incluir una descripción de su significado en el contexto de la aplicación, y debe indicar los objetos que forman la asociación. Los límites superiores e inferiores apropiados deben especificarse para indicar si la asociación es de uno a uno, de uno a muchos o de muchos a muchos. Por ejemplo, la relación compras compras = *la asociación de un cliente y uno o más artículos* @ identidad-del-cliente + 1{@identidad-del-artículo + cantidad-comprada}


CAPÍTULO 13 – DIAGRAMAS DE TRANSICIÓN DE ESTADOS (DTE) El DTE enfatiza el comportamiento dependiente del tiempo del sistema. Hasta hace poco, los modelos del comportamiento dependiente del tiempo del sistema importaban sólo para una categoría especial de sistemas conocidos como sistemas de tiempo-real. Notación de los DTE En la figura se muestra un DTE típico. Este diagrama muestra el comportamiento de una máquina contestadora de teléfono normal. Los principales componentes del diagrama son estados, y flechas que representan los cambios de estado.

Estados del sistema Cada rectángulo representa un estado en el que se puede encontrar el sistema. Un estado es un conjunto de circunstancias o atributos que caracterizan a una persona o cosa en un tiempo dado. Algunos ejemplos de estados pueden ser:

Calentar una mezcla de sustancias químicas Esperar la siguiente orden Acelerar el motor Mezclar los ingredientes Esperar los datos del instrumento Esperar a que el usuario dé su contraseña Llenar el tanque Aguardar en reposo

Muchos de estos ejemplos implican que el sistema está esperando a que algo ocurra, y no se expresan en términos de que la computadora esté haciendo algo. Esto se debe a que el diagrama de transición de estados se usa para desarrollar un modelo esencial del sistema, es decir, un modelo de cómo se comportaría el sistema si hubiera tecnología perfecta. Un aspecto de la tecnología perfecta sería que la computadora trabaje de manera infinitamente rápida, de modo que cualquier proceso o cálculo que tenga que hacer, o cualquier acción que deba tomar, se haga en cero momentos. Un estado representa algún comportamiento del sistema que es observable y que perdura durante algún periodo finito.


Cambios de estado Se muestran los cambios de estado válidos en el DTE conectando pares relevantes de estados con una flecha. La mayoría de los sistemas tienen un estado Inicial reconocible y un estado final reconocible; esto se muestra en la figura 13.3 El estado inicial típicamente se identifica con una es la flecha "desnuda" que no está conectada a ningún otro estado. De manera similar, el estado final suele ser el que se dibuja en la parte inferior, pero tampoco esto es obligatorio. Lo que realmente identifica al estado final es la ausencia de una flecha que salga de él. El sentido común dice que un sistema sólo puede tener un estado inicial; sin embargo, puede tener múltiples estados finales. Los diversos estados finales son mutuamente excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante alguna ejecución del sistema.

Condiciones y acciones Para completar nuestro DTE necesitamos añadir dos cosas más: 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 dos estados relacionados.

Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar; típicamente es una señal, una interrupción o la llegada de un paquete de datos. Esto usualmente hace que el sistema cambie de un estado de esperar X a un estado de esperar Y; o de llevar a cabo la actividad X a llevar a cabo la actividad Y. Como parte del cambio de estado, normalmente el sistema hará una o más acciones: producirá una salida, desplegará una señal en la terminal del usuario, llevará a cabo un cálculo, etc. Así que las acciones que se muestran en un DTE son respuestas regresadas al ambiente externo o bien cálculos cuyos resultados el sistema recuerda (típicamente en un almacén de datos que se muestra en el DFD) para poder responder a algún acontecimiento futuro.


Diagramas Particionados En un sistema complejo puede haber docenas de estados distintos del sistema; tratar de ponerlos todos en un mismo diagrama sería difícil, si no es imposible. Se pueden usar las particiones con los DTE.

Nótese que, en este caso, cualquier estado individual de un diagrama de mayor nivel puede convertirse en un estado inicial para un diagrama de nivel inferior que describe más a fondo ese estado de mayor nivel; y el o los estados finales en un diagrama de nivel inferior corresponden a las condiciones de salida en el estado asociado de nivel superior. Construcción del DTE Se puede comenzar por identificar todos los posibles estados del sistema y representar cada uno como una caja separada en una hoja de papel. Luego, se pueden explorar todas las conexiones con significado (cambios de estado) entre las cajas. Como alternativa, se puede comenzar por el estado inicial, y luego metódicamente ir siguiendo un camino hasta el o los estados restante. Cuando se termine de construir el DTE preliminar, deben seguirse las siguientes reglas para verificar la consistencia: ¿Se han definido todos los estados? ¿Se pueden alcanzar todos los estados? ¿Se han definido estados que no tengan caminos que lleven a ellos? ¿Se puede salir de todos los estados? En cada estado, ¿el sistema responde adecuadamente a todas las condiciones posibles? Este es el

error más común cuando se construye un DTE: el analista identifica los cambios de estado cuando ocurren condiciones normales, pero no especifica el comportamiento del sistema ante condiciones inesperadas.


La relación del DTE con los demás componentes del modelo El DTE puede usarse por sí solo como herramienta de modelado. Sin embargo puede, y en general debiera, ser utilizado en conjunto con otras herramientas. En la mayoría de los casos, el DTE representa una especificación de proceso para una burbuja de control en un DFD. Las condiciones en un DTE corresponden a los flujos de control entrantes en un DFD, y las acciones en el DTE corresponden a los flujos de control de salida en el DFD. Como herramienta de modelado de alto nivel, el DTE puede servir incluso como especificación de proceso para todo el sistema. Si se representa todo el sistema con un diagrama de una burbuja, puede usarse el DTE para mostrar la secuencia de actividades en el sistema.


CAPÍTULO 14 – BALANCEO DE MODELOS En los últimos cinco capítulos hemos examinado diversas herramientas de modelado para el análisis estructurado:

Diagrama de flujo de datos Se enfoca en las funciones del sistema Diccionario de datos Especificación de proceso Diagrama de entidad-relación Se enfoca en las relaciones entre datos Diagrama de transición de estados Se enfoca en las características del tiempo

Pero llega el momento de reunir todas las herramientas. Cuando se modelan tres aspectos distintos de un sistema (funciones, datos y tiempos), además de modelar las características detalladas del sistema en un diccionario de datos y un conjunto de especificaciones de proceso, es fácil desarrollar diversas interpretaciones diferentes e inconsistentes de esa misma realidad. Este es un peligro particularmente serio cuando se trata de proyectos muy grandes, donde es probable que estén involucrados varios grupos de interés y varias personas. También existe el peligro cuando el equipo que realiza el proyecto (y/o la comunidad usuaria) involucra personas con muy diferente preparación. Además, al balancear los modelos, podemos ver si existe consistencia entre los modelos, pudiendo detectar, si los hubiere, los errores. Es diez veces más económico corregir un error del análisis durante la fase misma de análisis que durante la fase de diseño. Balanceo del DFD y el DD 1. Cada flujo de datos (es decir, cada flecha del DFD) y cada almacén de datos deben estar definidos

en el diccionario de datos. Si falta la definición en el diccionario, el flujo o el almacén se considera indefinido.

2. De manera, inversa, cada dato y cada almacén que se define en el diccionario de datos debe aparecer en alguna parte del DFD. Si no aparece, dicho dato o almacén es un "fantasma", es decir, algo definido pero que no se "usa" en el sistema.

Balanceo del DFD y la especificación de proceso

1. Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una especificación de proceso, pero no ambos. Si el DFD muestra una burbuja que se identifica como 1.4.2, entonces debe existir ya sea una figura correspondiente identificada como 1.4.2, cuyas burbujas se identifiquen como 1.4.2.1, 1.4.2.2, etc., o bien la especificación estructurada debe contener una especificación de proceso para la burbuja 1.4.2. Si ambas existen, el modelo es innecesario (y peligrosamente) redundante.

2. Cada especificación de proceso debe tener una burbuja de nivel inferior asociada en el DFD. Dado que la especificación de proceso requiere de mucho trabajo, podría pensarse que es altamente improbable que existan especificaciones de proceso "vagabundas" rondando por el sistema.

3. Las entradas y salidas deben coincidir. El DFD muestra flujos de entrada y salida para cada burbuja, al igual que las conexiones con los almacenes. Esto debe ser evidente en la especificación de proceso también:

Observe que estos comentarios se aplican específicamente a las burbujas de proceso. Para las burbujas de control en un DFD existe correspondencia entre las burbujas y los diagramas de transición de estados asociados.


Balanceo de las especificaciones del proceso con el DFD y el DD Cada referencia de un dato en la especificación de proceso (típicamente, un sustantivo) debe satisfacer una de las siguientes reglas:

1. Coincide con el nombre de un flujo de datos o almacén conectado a la burbuja descrita por la especificación de proceso

2. Es un término local, definido explícitamente en la especificación de proceso 3. Aparece como componente en una entrada del diccionario de datos para un flujo o almacén

conectado con la burbuja. Así, los datos X y Y aparecen en la especificación de proceso de la figura 14.2, pero no aparecen como flujo de datos conectado en el DFD que se muestra en la figura 14.3. Sin embargo, el diccionario de datos, del cual se muestra un fragmento en la figura 14.4, indica que X y Y son componentes de Z; y en la figura 14.3 vemos que Z es en efecto un flujo de datos conectado a la burbuja, por lo que concluimos que el modelo está balanceado.

Especificación de proceso: calculo del factor w

* P Y Q SON TÉRMINOS LOCALES UTILIZADOS PARA OBTENER RESULTADOS INTERMEDIOS *

P = 3.14156 * X O = 2.78128 * Y - 13 FACTOR-W = P'Q+2

DFD

Componente del diccionario de datos de un modelo de sistema

X = * componente horizontal del factor frammís * * unidades: centímetros; escala: 0 - 100 *

Y = * componente vertical del tactor frammis *

* unidades: centímetros; escala: 0 -10 *

Z = * factor frammis, como lo definió el Dr. Frammis * X + Y Balanceo del diccionario de datos con el DFD y las especificaciones del proceso El diccionario de datos es consistente con el resto del modelo si: Cada entrada del diccionario de datos debe tener referencia en una especificación de proceso, un

DFD, u otro diccionario de datos. Esto supone, desde luego, que se está modelando el comportamiento esencial de un sistema. Un diccionario de datos complejo y exhaustivo de una implantación existente de un sistema puede contener algunos datos que ya no se usan. También se podría argumentar que el diccionario de datos se planee de forma tal que permita una expansión futura; es decir, que contenga elementos que no se ocupen hoy pero que pudieran ser útiles en un futuro.


Balanceo del DER con el DFD y las especificaciones de proceso 1. Cada almacén del DFD debe corresponder con un tipo de objeto, una relación o un tipo asociativo

de objeto en el DER. Si en el DFD existe un almacén que no aparece en el DER, algo anda mal; y si hay un objeto o relación en el DER que no aparece en el DFD, algo anda mal.

2. Los nombres de objetos en el DER y los nombres de almacenes de datos en el DFD deben coincidir. La convención que seguimos es usar la forma plural (es decir, CLIENTES), en el DFD y la forma singular en el DER (CLIENTE)

3. Las entradas del diccionario de datos deben aplicarse tanto al modelo de DFD como al de DER. Así, la entrada del diccionario de datos para el ejemplo anterior debe incluir definiciones tanto para el objeto del DER como para el almacén del DFD. Esto lleva a una definición de diccionario de datos como la siguiente:

CLIENTES = {CLIENTE} CLIENTE = nombre + domicilio + número-telefónico + ...

Las entradas del diccionario de datos para la forma singular (por ejemplo, CLIENTE) deben proporcionar el significado y composición de una sola instancia del conjunto de objetos a los que se refiere (en singular) en el DER, y (en plural) en el almacén del DFD. Las entradas del diccionario para la forma plural (por ejemplo, CLIENTES) proporcionan significado a la composición de un conjunto de instancias. De manera similar, hay reglas que aseguran que el DER sea consistente con la porción de la especificación de proceso del modelo orientado a las funciones. Las reglas son que el conjunto combinado de todas las especificaciones de proceso deben, en su totalidad:

1) Crear y eliminar instancias de cada tipo de objeto y relación que se muestra en el DER. Ej: el almacén CLIENTES corresponde al objeto CLIENTE. Algo debe ser capaz de crear y eliminar instancias de un cliente, lo cual significa que alguna burbuja en el DFD debe tener un flujo de datos conectado con el almacén CLIENTES. Pero el trabajo mismo de escribir el almacén (es decir, crear o eliminar una instancia del objeto CLIENTE relacionado en el DER) debe darse dentro de la burbuja, lo cual significa que debe documentarse en la especificación de proceso asociada con ella

2) Alguna burbuja de DFD define valores para cada dato asignado a cada instancia de cada tipo de objeto, y algún proceso del DFD usa (o lee) valores de cada dato.


Balanceo del DFD y DTE

1. Cada burbuja de control del DFD se asocia con un DTE, como su especificación de proceso. De manera similar, cada DTE en el modelo global del sistema debe asociarse con un proceso (burbuja) de control en el DFD.

2. Cada condición del DTE debe corresponder con un flujo de datos de entrada al proceso de control asociado con el DTE. De manera similar, cada flujo de control que entra en la burbuja de control debe asociarse con una condición apropiada en el DTE correspondiente.

3. Cada acción en el DTE debe corresponder con un flujo de control de salida del proceso de control asociado con dicho diagrama. De manera similar, cada flujo de control de salida de la burbuja de control debe asociarse con una acción apropiada en el DTE correspondiente.


CAPÍTULO 17 – EL MODELO ESENCIAL El Enfoque del Modelado Clásico y por que no funciono

Cuando se introdujo el análisis estructurado, comúnmente se argumentaba que el analista debería desarrollar los cuatro modelos distintos que se muestran en la Figura.

El modelo físico actual: es un modelo del sistema que actualmente está empleando el usuario. Puede ser un sistema manual, automatizado o mezcla de ambos. Típicamente, los procesos (burbujas) del diagrama de flujo de datos para el sistema físico actual se titulan con nombres de personas, de unidades organizacionales o de sistemas de cómputo que hacen la labor de transformar entradas en salidas.

El modelo lógico nuevo: es un modelo de los requerimientos puros o esenciales del sistema nuevo que el usuario quiere. En el caso ideal (desde el punto de vista del analista), es igual que el modelo lógico actual; es decir, contiene las mismas funciones y datos. Esta situación es factible si el usuario está completamente satisfecho con la funcionalidad del sistema actual, pero no con su implantación. En la mayoría de los casos, sin embargo, el usuario pedirá funciones adicionales. Aquí se eliminan los detalles de la implantación arbitraria, y el modelo que resulta muestra lo que el sistema haría si hubiera disponible una tecnología perfecta.

El nuevo modelo físico: es un modelo que muestra las limitaciones de implantación impuestas por el usuario. Una de las limitaciones más importantes es la determinación de la frontera de automatización (es decir, la determinación de cuáles funciones del nuevo sistema se automatizarán y cuáles se harán manualmente). El nuevo modelo físico corresponde a lo que ahora llamamos el modelo de implantación del usuario.

El enfoque clásico descrito anteriormente se basaba en tres suposiciones principales:

1. El analista pudiera no estar familiarizado con el área de aplicación o del negocio. Por ello es importante que el analista comience con un modelo físico actual como medio para educarse, para luego seguir con el modelo lógico

2. El usuario pudiera estar imposibilitado para trabajar con el nuevo modelo lógico al principio del proyecto. La razón más común de esto es la duda sobre la capacidad del analista para desarrollar


un modelo lógico del nuevo sistema. Aun si el analista cree que es un experto en el área de negocios del usuario, éste pudiera no estar de acuerdo.

3. La transformación de un modelo lógico actual en un modelo lógico nuevo no requiere mucho trabajo, ya que consistirá solo en unos cuantos agregados al modelo lógico actual.

Estas suposiciones de hecho resultaron ser correctas en muchos proyectos, pero ignoran que el proceso de desarrollar un modelo del sistema actual puede requerir tanto tiempo y esfuerzo que el usuario se frustre e impaciente y termine por cancelar el proyecto. Hay que considerar:

Algunos usuarios consideran cualquier tipo de análisis de sistemas como una pérdida de tiempo Muchos usuarios comprensiblemente dudan de los méritos que pueda tener el modelado cuidadoso

de un sistema que se superará y reemplazará como resultado del desarrollo del nuevo sistema. El problema ocurre más frecuentemente porque el analista se distrae con la tarea de modelar el sistema actual y empieza a pensar en él como un fin en sí mismo. Desafortunadamente, este enfoque casi siempre involucra un gran desperdicio de tiempo. Normalmente podrá esperarse que hasta un 75% del modelo físico se deseche en la transición al modelo lógico actual. Esto se debe a la redundancia. Muchas veces, los analistas se involucran tanto en el proceso de modelar, que olvidan el objetivo del usuario: producir un sistema que funcione. Consecuentemente, este libro recomienda que el analista evite modelar el sistema actual de ser posible. El Modelo Esencial: ¿Qué es? El modelo esencial del sistema es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo posible (o nada) acerca de cómo se implantará. El analista debe evitar describir cómo se implementará un proceso en el sistema. Lo mismo se da para los flujos y almacenes de datos: el modelo esencial debe describir el contenido de los flujos o almacenes de datos, sin describir el medio u organización física de los datos. Dificultades en la construcción de un modelo esencial Aunque las reglas anteriores parecen simples y obvias, a menudo resulta muy difícil eliminar completamente todos los detalles de la implantación en el modelo esencial. Algunos ejemplos:

Secuenciado arbitrario de las actividades en un modelo de flujo de datos. El único secuenciado en el diagrama de flujo de datos debe ser el que requieren los datos (por ejemplo, la burbuja 2 puede requerir un dato producido por la burbuja 1 y por tanto no trabajar sino hasta que aquella haya terminado) o los acontecimientos externos al sistema.

Archivos innecesarios: los almacenes de datos que no se requerirían de existir una tecnología perfecta

Revisión de errores y validación innecesarios de datos y procesos dentro del sistema. Datos redundantes o derivados.

Componentes del modelo esencial El modelo esencial consiste en dos componentes principales:

Modelo ambiental: define la frontera entre el sistema y el resto del mundo Modelo de comportamiento: describe el comportamiento que del sistema se requiere para que

interactúe de manera exitosa con el ambiente ¿Qué hacer si se debe construir un modelo de implantación? Existen circunstancias en las cuales podría ser deseable o necesario construir un modelo de implantación antes de construir el modelo esencial del sistema. Si decide proceder de este modo, lo principal a recordar es que su primer objetivo es llegar a un entendimiento y una visión generales del sistema existente.

No se trata de documentar el sistema actual con detalle. Probablemente sea útil crear uno o más niveles de DFD del sistema actual.


Probablemente sea apropiado generar un DER y escribir las especificaciones del proceso para algunas de las funciones más críticas del sistema.

Podría ser útil reunir algunos de los documentos físicos No intente escribir especificaciones de proceso para todas las funciones, ni trate de desarrollar un

diccionario de datos completo para el sistema existente. Cuando haya terminado de desarrollar el modelo de la implantación actual, tendrá que definirlo en términos lógicos. Esto usualmente abarcará los siguientes pasos:

1. Buscar y separar flujos esenciales que hayan sido empaquetados de manera arbitraría en el mismo medio.

2. Buscar flujos empaquetados o agregados que se envían a burbujas que no requieren de todos los datos que hay en dichos flujos.

3. Distinguir entre el trabajo esencial realizado por un proceso y la identificación del procesador que aparece en el modelo de implantación.

4. Eliminar procesos cuyo único propósito sea transportar datos de un lugar a otro dentro del sistema. Además, elimine las burbujas responsables de entradas y salidas físicas entre el sistema y el ambiente exterior. Muchos DFD físicos tienen procesos con nombres como "obtener entradas del usuario" o "imprimir reporte"; también deben eliminarse.

5. Eliminar procesos cuya labor sea verificar datos que se producen y usan dentro del sistema. Dado que en el modelo esencial se supone una tecnología perfecta, esa verificación y revisión interna no es necesaria.

6. Buscar situaciones donde los almacenes esenciales se hayan empaquetado en el mismo almacén de implantación para separarlos (por ejemplo, archivos en disco, en cinta o en papel); esto es muy común en los sistemas de segunda generación y en sistemas que se han optimizado a lo largo de años para manejar grandes volúmenes de datos de manera eficiente.

7. Eliminar datos de los almacenes si ningún proceso los usa. Además, elimine datos de los almacenes si se pueden calcular o derivar directamente a partir de otros.

8. Eliminar almacenes de datos que sólo existan como separadores de tiempo entre procesos, y que sean dependientes de la implantación. Esto incluye archivos intermedios, archivos de reportes, archivos de impresión diferida y otros similares.


CAPÍTULO 18 – EL MODELO AMBIENTAL Para el analista, la labor más difícil en la especificación de un sistema es a menudo determinar qué es parte del sistema y qué no. Cualquier sistema será parte de un sistema aún mayor. Así, el primer modelo importante que se debe desarrollar es uno que defina las interfaces entre el sistema y el ambiente. Además de determinar qué está en el interior del sistema y qué en el exterior (lo que se logra definiendo la frontera entre el sistema y el ambiente), también es críticamente importante definir las interfaces entre el sistema y el ambiente. Se necesita saber qué información entra al sistema desde el ambiente exterior, y qué información produce como salida al ambiente externo. Los sistemas que construimos producen salidas como respuesta a algún acontecimiento, o estímulo del ambiente. Otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. La frontera entre un sistema y su ambiente es arbitraria. Puede haberse creado por algún decreto administrativo, como resultado de alguna negociación política, o simplemente por accidente. Y eso es algo que el analista de sistemas usualmente tiene oportunidad de influenciar. Generalmente el usuario tendrá una buena idea de la frontera general entre el sistema y el ambiente. Pero a menudo existe un "área gris" que está abierta a negociaciones, es decir, un área sobre la cual el usuario no está seguro, no había pensado, tenía algunas ideas preconcebidas que está dispuesto a reflexionar o, todas las anteriores. Si el analista escoge una perspectiva demasiado pequeña o grande para un proyecto, está condenado al fracaso. Por lo tanto, es importante dedicar bastante tiempo y tener suficiente participación del usuario en la elección de una frontera apropiada para el sistema. En un sistema grande se puede tomar en cuenta una gran cantidad de factores cuando se está escogiendo la perspectiva del proyecto. Entre los más importantes están los siguientes:

El deseo del usuario de lograr una cierta participación en el mercado para el producto, o incrementarla a más de su nivel actual.

Podría tenerse que hacer un nuevo sistema para considerar los cambios en las leyes Deseo del usuario por minimizar gastos operativos de algún área de su negocio.. Deseo del usuario por lograr alguna ventaja estratégica para la línea de productos o área de

negocios que opera El área dentro de la frontera del sistema a veces se conoce como el dominio de cambios. Por esto, simplemente queremos decir que todo lo que está dentro de la frontera del sistema está sujeto a cambios, mientras que todo lo que está fuera se queda en su forma actual y no es investigado por el analista. Herramientas usadas para definir el ambiente 1. Declaración de propósitos Es una declaración textual breve y concisa del propósito del sistema, dirigida al nivel administrativo superior. 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. Como resultado, la declaración de propósitos será deliberadamente vaga en cuanto a muchos detalles, que se aclararán viendo el modelo de comportamiento 2. Diagrama de contexto El diagrama de contexto es un caso especial del DFD, en donde una sola burbuja representa todo el sistema. El diagrama de contexto muestra 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 procesarse 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. Estos almacenes de datos

se crean fuera del sistema para su uso, o bien son creados en él y usados fuera. La frontera entre el sistema y el resto del mundo.

3. Lista de acontecimientos La lista de acontecimientos es una lista narrativa de los "estímulos" que ocurren en el mundo exterior a los cuales el sistema debe responder.

Ejemplo: Un cliente hace un pedido. (F) Un cliente cancela un pedido. (F) La administración pide un reporte de ventas. (T) Llega un pedido de reimpresión de un libro a la bodega. (C)

Observe que cada acontecimiento se etiqueta como F (Flujo), T (Temporal) o C (Control). El orientado a flujos es el que se asocia con un flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algún dato. Esto corresponderá al flujo de datos en el diagrama de contexto. Sin embargo, no todos los flujos de datos del diagrama de contexto necesaria mente son acontecimientos de tipo flujo. Considere, por ejemplo, el diagrama de contexto parcial que se muestra en la Figura.

A primera vista, uno pudiera verse tentado a concluir que los flujos de datos A, B y C son todos indicadores de acontecimientos separados y discretos. Sin embargo, pudiera resultar que sólo el flujo de datos A esté asociado con un acontecimiento (por ejemplo, al flujo de datos lo inicia el terminador). Para procesar un acontecimiento el sistema explícitamente podría pedir entradas a otros terminadores a lo largo de los flujos de datos B y C para obtener alguna respuesta. Así que no necesariamente existe una correspondencia uno a uno entre

los flujos de datos del diagrama de contexto y los acontecimientos de la lista de acontecimientos. En general, cada flujo de datos es un acontecimiento (o, más precisamente, la indicación de que ha ocurrido), o bien es requerido por el sistema para poder procesar un acontecimiento. Un sistema puede también tener acontecimientos temporales, que arrancan en un momento dado en el tiempo. Ejemplos:

A las 9:00 de la mañana se requiere un reporte diario de todos los pedidos de libros Las facturas deben generarse a las 3:00 PM. Se deben generar reportes administrativos una vez por hora.

Observe que los acontecimientos temporales no se inician con flujos de datos de entrada. Hay que considerar que un acontecimiento temporal podría requerir que el sistema solicite entradas de terminadores. Por ello, podrían asociarse uno o más flujos de datos con un acontecimiento temporal, aunque los flujos de datos en sí, no representan el acontecimiento mismo. Los acontecimientos de control deben considerarse un caso especial del acontecimiento temporal: un estímulo externo que ocurre en algún momento impredecible. Un acontecimiento de control se asocia con un flujo de control en el diagrama de contexto.


El flujo de control puede considerarse como un flujo de datos binario: está encendido o apagado, y puede cambiar de un estado al otro en cualquier momento, señalando así al sistema que se necesita tomar alguna acción inmediata. Los flujos de control son bastante comunes en los sistemas de tiempo real. Componentes adicionales del modelo ambiental En la mayor parte de los proyectos, las 3 herramientas mencionadas anteriormente bastan. Pero a veces, puede ser útil:

El diccionario de datos inicial, que define todos los flujos y almacenes externos El modelo de entidad-relación de los almacenes externos

Construcción del modelo ambiental A menudo resulta que el modelo ambiental requiere de una gran cantidad de trabajo. Además, usualmente se desarrolla como una serie de refinamientos iterativos, con datos adicionales que se añaden y retinan. Esto es así ya que normalmente una sola persona no puede comprender la perspectiva completa del sistema como se definió inicialmente, y los diversos usuarios generalmente solo están familiarizados con una porción, y sus diversas opiniones a veces entran en conflicto. Es importante dedicar una buena cantidad de tiempo y energía al modelo ambiental, pues a menudo es el punto focal de juntas y presentaciones importantes al comienzo de la vida de un proyecto de desarrollo de sistemas. Construcción del diagrama de contexto El diagrama de contexto, como hemos visto, consiste en terminadores, flujos de datos y flujos de control, almacenes de datos y un solo proceso que representa a todo el sistema. Se analizan uno por uno a continuación. La parte más fácil del diagrama de contexto es el proceso: consiste en una sola burbuja, cuyo nombre suele ser el nombre del sistema completo o un acrónimo convenido. Los terminadores se representan con rectángulos, y se comunican directamente con el sistema a través de flujos de datos o de control, o a través de almacenes externos

Los terminadores si se comunican entre sí pero, dado que por definición son externos al sistema, la naturaleza y contenido de las interacciones terminador-terminador son irrelevantes para el sistema, por lo que en los diagramas de contexto no debemos conectarlos entre sí.

Algunos terminadores tienen un buen número de entradas y salidas. Para evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador más de una vez, destacándolo con un “ * ” o una diagonal en una esquina

Cuando el terminador es una persona individual, generalmente es preferible indicar el rol que desempeña, más que su identidad, ya que una misma persona puede desempeñar varios papeles distintos en el sistema. En lugar de mostrar un terminador etiquetado "Juan Pérez" con varios


flujos de entrada y salida no relacionados, es más significativo mostrar los diversos papeles que Juan Pérez desempeña, cada uno como terminador separado.

Debemos distinguir entre fuentes y manejadores cuando se dibujan terminadores en el diagrama de contexto. Un manejador es un mecanismo, dispositivo, o medio físico usado para transportar datos hacia dentro o fuera del sistema. Como estos manejadores son familiares y visibles para los usuarios, existe la tendencia de mostrar al manejador, en lugar de la verdadera fuente de los datos. Sin embargo, el manejador no debe mostrarse.

Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema, además de las señales de control que recibe o genera. Los flujos de datos se incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan (como datos) para producir una respuesta. Los flujos de datos también pueden aparecer en el diagrama de contexto para ilustrar datos que estén siendo transportados entre terminadores por el sistema. Finalmente, los flujos de datos se muestran en el diagrama de contexto cuando el sistema produce datos para responder a un acontecimiento. Debe dibujarse el diagrama de contexto bajo el supuesto de que las entradas son causadas e iniciadas por los terminadores. y que las salidas son causadas e iniciadas por el sistema. Al evitar mensajes extraños y entradas y salidas orientadas a la implantación, se modela sólo el flujo neto de datos. Sin embargo, habrá ocasiones en las que un terminador no inicie las entradas pues, aun con tecnología perfecta, el terminador no sabe que el sistema requiere sus entradas. Similarmente, hay ocasiones en las que el sistema no inicia la generación de salidas, debido a que no sabe que el terminador las necesita o desea. En ambos casos, el mensaje es una parte esencial del sistema, y debe mostrarse en el diagrama de contexto.

Construcción de la lista de acontecimientos La lista de acontecimientos, 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 un flujo relacionado con un acontecimiento. Por ejemplo, lo siguiente probablemente no sea un acontecimiento: "El sistema recibe el pedido del cliente". Más bien, probablemente sea el flujo de datos de entrada mediante el cual el sistema se da cuenta de que ha ocurrido el acontecimiento. Un nombre más apropiado para el acontecimiento sería: "El cliente hace un pedido".


Siempre se trata de describir los acontecimientos desde el punto de vista del ambiente (es decir, desde fuera, viendo hacia dentro). En la mayor parte de los casos, la manera más fácil de identificar los acontecimientos relevantes para un sistema es visualizarlo en acción: examinar cada terminador y preguntar qué efecto pueden tener sus acciones sobre el sistema. Esto usualmente se hace en conjunto con los usuarios del sistema desempeñando el papel de terminadores. Sin embargo, debe distinguirse cuidadosamente entre acontecimientos discretos que se han ''empaquetado" accidentalmente como si fueran uno solo; esto sucede a menudo con acontecimientos de tipo flujo. Por ejemplo, si se ve de cerca el acontecimiento "el cliente hace un pedido", se encontraría que algunas instancias incluyen el dato "identificación del vendedor" y otros no; y podría encontrarse que la respuesta del sistema es diferente cuando participa un vendedor que cuando no. Por ello, podría ser más apropiado tener dos acontecimientos separados: "el cliente hace un pedido" y "el vendedor tramita el pedido del cliente". Además, la lista de acontecimientos debe incluir también situaciones de falla. Dado que se está creando un modelo esencial, no hay que preocuparse por fallas del sistema; pero se deben tomar en cuenta posibles fallas o errores causadas por los terminadores. ¿Qué se hace primero, el diagrama de contexto o la lista de acontecimientos? En realidad no importa mientras finalmente se produzcan ambos y sean consistentes. Cuando se termine con ambos componentes del modelo ambiental será posible confirmar lo siguiente:

El sistema necesita cada flujo de entrada del diagrama de contexto para reconocer que ha ocurrido un acontecimiento; debe necesitarlo para producir una respuesta a un acontecimiento, o ambas cosas.

Cada flujo de salida debe ser respuesta a un acontecimiento. Cada acontecimiento no temporal de la lista de acontecimientos debe tener entradas a partir de las

cuales el sistema pueda detectarlo. Cada acontecimiento debe producir salidas inmediatas como respuesta o bien almacenar los datos

que luego serán salidas (como respuesta o parte de una respuesta a algún otro acontecimiento), o debiera ocasionar un cambio en el estado del sistema (como indica el diagrama de transición de estados).


CAPÍTULO 19 – CONSTRUCCIÓN DE UN MODELO PRELIMINAR DE COMPORTAMIENTO

Una vez realizado el modelo ambiental, debemos comenzar a construir el modelo de comportamiento final que el sistema debe tener para manejar con éxito el ambiente. Esto involucrará el desarrollo de un diagrama de flujo de datos (DFD) y un diagrama de entidad-relación (DER) preliminares, además de la elaboración de las entradas iniciales del diccionario de datos (DD). Básicamente, este enfoque implica dibujar el borrador del DFD, con un proceso (burbuja) para la respuesta del sistema ante cada acontecimiento que se identificó en la lista de acontecimientos. A continuación se dibujan almacenes en el borrador del DFD para modelar los datos que deben recordarse entre acontecimientos no sincronizados. Finalmente, se conectan los flujos de entrada y salida apropiados a las burbujas y se compara el conjunto de diagramas de flujo de datos contra el diagrama de contexto para asegurar la consistencia. Una vez hecho esto se procede a un proceso de limpieza, descrito en el Capítulo 20, para producir un modelo bien organizado del proceso y un modelo de datos para presentarlo al usuario final. Este enfoque se llamó partición por acontecimientos. Comenzamos por comparar este enfoque con el enfoque descendente clásico. El Enfoque Clásico El enfoque clásico supone que ya se dibujó el diagrama de contexto, pero supone que se procederá directamente de la burbuja única del diagrama de contexto a un DFD de nivel superior (conocido como figura 0), en donde cada burbuja representa un subsistema principal. Cada burbuja de la figura 0 se parte a continuación en figuras de nivel inferior, y así sucesivamente, hasta haber alcanzado el nivel de una burbuja "atómica" que no requiera de mayor descomposición.

Este enfoque descendente tiene algunos problemas, tales como:

Parálisis del análisis. En muchos sistemas grandes y complejos, simplemente no existe pista alguna que guíe al analista para dibujar una figura apropiada desde el diagrama de contexto.

El fenómeno de los seis analistas. En un sistema grande y complejo suele haber más de un analista viendo el diagrama de contexto. Para dividir el trabajo en forma equitativa y no estorbarse unos a otros, arbitrariamente crean una figura 0 con. una burbuja para cada analista. Así, si hay seis analistas, la figura 0 constará de seis burbujas. Desde luego, ésta pudiera no ser la partición óptima para el sistema

Una partición física arbitraria. En muchos casos, un sistema nuevo se basa en uno existente, o representa la computarización de una organización existente. La partición de alto nivel del sistema


actual suele utilizarse como parámetro para la partición del nuevo. Así, si el sistema existente se representa con un Departamento de Compras y un Departamento de Control de Calidad, el nuevo sistema también tendrá un Subsistema de Compras y un Subsistema de Control de Calidad aun cuando tal vez no sean (y muchas veces no son) la mejor manera de partir el sistema (desde un punto de vista funcional).

El enfoque que se describe en este capítulo no es puramente descendente ni puramente ascendente. Es, en cierto sentido, un enfoque "medio"; después de desarrollar el DFD inicial, se requiere alguna nivelación ascendente, y luego podría necesitarse alguna partición descendente. Identificación de respuestas a acontecimientos El enfoque de partición por acontecimientos incluye los siguientes cuatro pasos:

1. Se dibuja una burbuja, o proceso, para cada acontecimiento de la lista. Se pueden numerar las burbujas y los acontecimientos para tener una referencia directa

2. La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado. Ej: Si el acontecimiento es CLIENTE REALIZA PAGO, un nombre de burbuja apropiado pudiera ser ACTUALIZAR CUENTAS POR COBRAR (si ésa es la única respuesta del sistema), en lugar de PROCESAR PAGO DE CLIENTE (que nada dice acerca de la naturaleza de la respuesta).

3. Se dibujan las entradas y salidas apropiadas de tal forma que la burbuja pueda dar la respuesta requerida, y se dibujan los almacenes, como sea apropiado, para la comunicación entre burbujas. En muchos casos el acontecimiento está determinado por el flujo. Esto significa que el sistema detecta la ocurrencia de un acontecimiento por la llegada de algún dato de un terminador externo. Obviamente, esto significa que el flujo de datos apropiado debe estar conectado al proceso requerido para responder a tal acontecimiento. Pero se pueden llegar a requerir entradas adicionales (de otros terminadores, y posiblemente de almacenes de datos) para que un proceso produzca su salida requerida.

De manera similar, como parte de la respuesta dibuje las salidas adecuadas producidas por el proceso. En muchos casos, esto implicará devolver salidas a los terminadores fuera del sistema; sin embargo, puede también involucrar salidas que se envían a los almacenes de datos, para ser usadas como entradas de otros procesos.

4. El borrador de DFD que resulta, se compara con el diagrama de contexto y la lista de acontecimientos para asegurar que esté completo y sea consistente. Existen dos casos especiales:

a. Acontecimientos únicos que causan respuestas múltiples: cada una de las respuestas se modela con su propia burbuja en el DFD preliminar. Sólo es apropiado si todas las respuestas usan el mismo flujo de datos de entrada, y sólo si todas las respuestas son independientes entre sí. Ninguna salida de alguna parte de la respuesta global debe ser requerida como entrada por alguna otra parte de la respuesta global.


b. Acontecimientos múltiples que causan la misma respuesta. Es válido y apropiado sólo si la respuesta de la burbuja es idéntica para los diversos acontecimientos, y sólo si los datos de entrada y salida son idénticos para las diversas respuestas a acontecimientos.

Conexión de las respuestas a acontecimientos Las burbujas no se comunican directamente con otras. En vez de eso se comunican entre sí a través de otros almacenes de datos. ¿Por qué? Simplemente porque las burbujas del DFD preliminar representan respuestas a un acontecimiento, y los acontecimientos que ocurren en el ambiente externo son, en el caso general, no sincronizados. Los acontecimientos ocurren en el ambiente externo cuando éste desea que sucedan. Y, dado que: La respuesta a un acontecimiento puede requerir datos producidos por algún otro No hay forma de saber cuándo ocurrirán los acontecimientos Debe suponerse, en un modelo esencial, que cada proceso realizará su labor de manera

infinitamente rápida, Cada flujo de datos actúa como conducto que puede transmitir datos con rapidez infinita

se sigue que la única forma de sincronizar múltiples acontecimientos interdependientes es mediante un almacén. Éste es un almacén esencial, que se necesita por consideraciones de tiempo en el ambiente. Desarrollo del modelo inicial de datos Como hemos visto, el procedimiento de dibujar el DFD inicial implica el dibujo de almacenes de datos entre procesos no sincronizados. En muchos casos su naturaleza será obvia, y los nombres pueden escogerse de la comprensión del tema del proyecto. Si el DER y el DFD se están desarrollando en paralelo, pueden usarse para revisarse entre sí. Los almacenes que se definieron tentativamente en el DFD preliminar pueden usarse para sugerir objetos en el DER preliminar, y viceversa. Ningún modelo debe considerarse el dominante que controla al otro; cada uno es equivalente y puede proporcionar asistencia invaluable al otro. Podría también encontrar que la lista de acontecimientos es tan útil para crear el DER inicial como para crear el DFD inicial. Sucederá que los sustantivos de la lista de acontecimientos sean objetos del DER. Por ejemplo, sí un acontecimiento es "Cliente hace pedido", inmediatamente se identificaría cliente y pedido como objetos tentativos. Similarmente, se puede usar una lista de acontecimientos para verificar el DER inicial: todos los tipos de objetos del DER deben corresponder con sustantivos de la lista de acontecimientos.


CAPÍTULO 20 – TERMINADO EL MODELO DE COMPORTAMIENTO El modelo de comportamiento desarrollado en el capítulo anterior no puede presentarse al usuario para su verificación, ya que es demasiado complicado. Un segundo problema es que el modelo consiste principalmente en gráficos, con poco o ningún apoyo textual. Aunque el DFD y el DER son excelentes vehículos para presentar una visión global del sistema al usuario, necesitan el apoyo de un diccionario de datos completo y un juego completo de especificaciones de proceso. Terminando el modelo del proceso 1- Nivelación del DFD

Como vimos, el DFD consiste en un solo nivel, con demasiadas burbujas. Por ello, se necesita una nivelación ascendente del DFD preliminar. Esto significa que se desea agrupar procesos relacionados en agregados con significado, cada uno de los cuales representará una burbuja de un diagrama de nivel superior. Existen tres reglas que se debe tener en mente al hacer esto:

1. Cada agrupación de procesos deben involucrar respuestas relacionadas cercanamente. Esto usualmente significa que los procesos manejan datos relacionados cercanamente. 2. Busque la oportunidad de esconder o "enterrar" datos almacenados que aparecen en el nivel inferior. Si ve un grupo de procesos en los DFD preliminares que se refieren a un almacén común, y no hay otros procesos en el DFD preliminar que se refieran a este almacén, entonces puede crear una burbuja de nivel superior para esconderlo. 3. Tenga en mente que la persona que ve sus DFD no querrá ver demasiado a la vez. Por ello, cree agregados o grupos del DFD preliminar que consistan en aproximadamente 7 más o menos 2 bloques de información, donde un proceso se considere como un bloque.

Desde fuego, esto significa que tal vez se necesiten varios intentos de nivelación ascendente. Note también que podría requerirse nivelación descendente. Esto sólo significa que los procesos iniciales, cada uno de los cuales es responsable de producir la respuesta a un acontecimiento, pudieran resultar demasiado complejos para ser descritos adecuadamente en una especificación de proceso de una página. Muchas veces esto se volverá evidente tan pronto como vea el proceso con cuidado, o cuando pida al usuario una explicación de lo que la burbuja debe hacer, o cuando intente escribir la especificación del proceso. Algunas reglas para llevar a cabo la nivelación descendente:

1. En algunos casos es apropiado un enfoque de descomposición funcional pura. Es decir, si encuentra una burbuja de proceso que realiza una función compleja, trate de identificar subfunciones,

2. En otros casos, los flujos de datos de entrada y salida proporcionarán la mejor guía para la nivelación descendente.

Tenga en mente al realizar esta actividad de nivelación ascendente y descendente, que el balanceo es importante


2- Completar el Diccionario de datos

Al desarrollar el DFD y DER preliminar debió haberse comenzado a desarrollar y/o actualizar el diccionario de datos. Sin embargo, de ninguna manera estará completo aún. Al irse completando el diccionario de datos, también verifique que esté completo y sea consistente. Revise que el diccionario sea consistente internamente, que esté balanceado con el DFD por niveles, el DER y las especificaciones del proceso.

3- Completar las Especificaciones de proceso

Cuando se desarrolló el DFD preliminar, utilizando el enfoque de partición por niveles, es probable que no hayan escrito especificaciones de proceso. De hecho, suele ser mala idea dedicar tiempo a la escritura de las especificaciones del proceso antes de terminar el DFD preliminar, porque el desarrollo inicial del DFD se ve sujeto a muchos cambios, correcciones y revisiones. Cuando el DFD preliminar empieza a estabilizarse, y cuando ha pasado la prueba de la nivelación ascendente, entonces puede comenzar a escribir las especificaciones del proceso. Esto a menudo será un esfuerzo largo y consumirá mucho tiempo, porque cada burbuja de nivel inferior en el conjunto de DFD requiere una especificación de proceso. Al irse completando las especificaciones de proceso deben balancearse y compararse con el diccionario de datos y el DER.

Terminando el Modelo de Datos El DER se desarrolla de una manera similar a la descrita para el DFD: se desarrolla un DER tosco, y luego se refina y se mejora. Sin embargo, hay que tener en cuenta que muchas veces el DER se desarrolla casi al mismo tiempo que el DFD. En este caso, los conocimientos que se obtienen del DFD pueden usarse para retinar y revisar el DER, y viceversa. Terminando el DTE Si su sistema tiene características de tiempo real, estará desarrollando un DTE. El conocimiento detallado del comportamiento del sistema le ayudará a refinar este modelo. Examine el DTE en busca de los siguientes errores comunes:

¿Se han definido todos los estados? ¿Se puede llegar a todos los estados? ¿Se puede salir de todos los estados? En cada estado, ¿responde el sistema adecuadamente a todas las condiciones posibles?


UNIDAD 9



Hardware, materiales y equipo relacionados

Software Personas Mantenimiento Planta física (facilidades)

Análisis de Costos

Análisis de Beneficios

Análisis de Riesgos

1- El costo de construir el sistema 2- El costo de instalar el sistema 3- El costo del dinero 4- Los costos operacionales 5- Los costos del fracaso 6- Distinguir entre costos de

capital y de operación

Beneficios Tácticos Beneficios Estratégicos

Reducción de Personal Ahorro en tiempo de transacciones Ahorros en equipos Ahorro en mantenimiento Nuevos clientes Entrar a nuevos mercados Proporcionar nuevos productos Hacer popular el conocimiento

Métodos para mostrar el análisis de costo-beneficio

Flujo de efectivo Rendimiento de inversiones (ROI) Tasa interna de Rendimiento (IRR) Valor neto actual (NVP)

Costos mayores que lo estimado Los beneficios estimados no se materializan


UNIDAD 9 – CÁLCULO DE COSTO-BENEFICIO El propósito es mostrar a los usuarios del nuevo sistema, y a administradores de la organización, que los beneficios que se espera obtener con el nuevo sistema superan a los costos esperados. Como analista, no está en posición de insistir en que se realice un estudio de costo/beneficio, pero es conveniente ya que se permite prever si los beneficios son muy difusos (o si se subestimaron exageradamente los costos) y así estar consciente de que el proyecto es vulnerable. A veces el administrativo que autorizó el proyecto no se encuentra el día de mañana en la empresa, y tal vez quién lo reemplaza, si no hay un análisis de costo/beneficio, no está dispuesto a seguir con el proyecto.

ANÁLISIS DE COSTOS

1- El costo de construir el sistema - Los salarios y gastos extra para todo el personal relacionado con el proyecto. - Costos de capacitación - Tiempo de computadora y herramientas de desarrollo para el personal - Costos de reclutamiento del personal nuevo - Espacio de oficina y equipo para el personal nuevo - Gastos de viaje para visitar a usuarios lejanos

2- El costo de instalar el sistema En un proyecto sencillo, pudiera ser suficiente llamar por teléfono al usuario y decirle que se terminó de desarrollar el sistema; puede entregarse en un disco flexible y dejar que él mismo lo instale en su computadora personal. Pero en un proyecto grande y complejo, el proceso de instalación es más difícil e incluye muchos gastos, como por ejemplo:

- Gastos de capacitación de usuarios: clases, cursos, manuales, lugares de capacitación, tiempo del usuario, etc

- Gastos de conversión de bases de datos - Gastos de instalación comercial: Referido al hardware - Gastos de aprobación reglamentaria: licencias, pruebas ambientales, etc. - Gastos de ejecuciones paralelas entre el nuevo y viejo sistema - Gastos del equipo de desarrollo durante la instalación

3- El costo del dinero El dinero que se requiere para desarrollar e instalar un sistema no se da en los árboles; la organización tiene que pedirlo prestado, o bien debe sacarse de sus fondos actuales. Por tanto, existe un costo asociado con el uso del dinero. Dependiendo de su organización, se le puede pedir que exprese esto en términos del costo del dinero prestado, o de los intereses que ganaría si se tuviera invertido en lugar de estarse usando para el proyecto. Esta es un área en la que debe recurrir al consejo del departamento de contabilidad. Ellos tendrán casi seguramente una regla estándar acerca de cómo tratar tales cuestiones, y es importante que su proyecto utilice el mismo enfoque. 4- Los costos operacionales Una vez instalado el sistema, al usuario le costará dinero continuar operándolo. Sin embargo, esto también debe representar un área en la que el nuevo sistema ahorrará dinero, dado que es de suponerse que será más económico que el que actualmente tiene el usuario (a menos que haya añadido mayor funcionalidad). Algunos ejemplos son:

- Costos de hardware y materiales y equipo relacionados, ya sean nuevos usados o reparaciones


- Costos de software: Licencias de sistemas operativos, bases de datos, etc. - Costos de personas: Personal de operaciones, apoyo técnico, programadores, etc. - Costos de mantenimiento: mantenimiento preventivo, reparaciones, etc. Suelen estimarse en base

a: o Si el sistema reemplaza a uno anterior, puede estimar el mismo costo de mantenimiento o Una estimación optimista puede basarse en el ahorro esperado respecto al mantenimiento

del sistema actual. o Si actualmente no se está utilizando algún sistema que pueda servir de comparación (o si

desea evitar estimaciones demasiado optimistas o pesimistas), trate de determinar el costo promedio de mantenimiento para sistemas similares

- Costos de planta física (o facilidades): Se dan cuando se necesita construir un lugar físico para instalar, por ejemplo, un servidor

5- Los costos del fracaso Es el costo de posibles fallas del nuevo sistema. Es conveniente sepultar esto en la categoría de costos operacionales, pero tiende a ocultar lo que se convertirá en un aspecto importante de los sistemas de información en un futuro: su confiabilidad. Existen varias formas de falla de sistemas. En algunos casos, el sistema queda totalmente fuera de operación hasta que se corrige la falla, mientras que en otros, continúa operando, pero una o varias de sus salidas son incorrectas. En algunos casos, algunas funciones pueden ser inoperables y en otros puede ser que los usuarios no puedan tener acceso al sistema. Todas estas formas de falla tienen un costo asociado: costos de hardware, costos de software, costos de personal relacionado con la corrección del error, costes legales en el caso de que la falla del sistema haya ocasionado pérdidas financieras u otras pérdidas lamentables, y costos asociados con la posible pérdida de ganancias o pérdida de clientes. ¿Cómo se debe estimar esto? Estudiando la relación de fallas del sistema actual, si se está construyendo uno nuevo para reemplazarlo, y viendo la relación de fallas de todos los demás sistemas de su organización. Así puede hacer algunas suposiciones razonables sobre la relación de fallas que tendrá el sistema nuevo. Con suerte, su proyecto se podrá construir con una cantidad substancialmente menor de errores que la del actual. Si no existen estadísticas disponibles para la confiabilidad del software del sistema actual de su organización, y no tiene una base sobre la cual hacer una estimación para el nuevo, entonces por lo menos debe considerar este hecho en su documento de análisis de riesgos. 6- Distinguir entre costos de Capital y de Operación Algunos costos asociados con el nuevo sistema, se desembolsarán durante el año en el que se presentan; es decir, su organización los reconocerá en su declaración de impuestos durante el año en el cual ocurren. Otros se capitalizan; es decir, se reparten a lo largo de un periodo de varios años. Aunque esto no afecta al costo global del sistema, su clasificación como costo capitalizable o costo de operación puede tener un impacto enorme sobre los impuestos de la organización. Típicamente, las compras de hardware se consideran gastos de capital, y su costo se reparte a lo largo de un periodo de 5 a 7 años (dependiendo de los reglamentos de impuestos prevalecientes). El costo de desarrollar software puede capitalizarse o no. Y los costos de instalación y operación normalmente se contabilizan cuando ocurren, aunque pueden existir pequeñas variantes en esta área. Obviamente, aquí no puede inventar su propia política de contabilidad. Es importante investigar qué parámetros financieros se usan en su organización y seguirlos de manera consistente.


ANÁLISIS DE BENEFICIOS

Es mucho más difícil calcular los beneficios de un nuevo sistema de información que calcular su costo. En algunos casos, hasta puede ser imposible, debido tal vez a que el sistema es obligatorio, o porque el usuario decidió que quiere el sistema sin importar si se pueden identificar beneficios tangibles o no. El intento de calcular beneficios tangibles es el que ocasiona tantos problemas. Los usuarios probablemente hablarán entusiastamente acerca de "mejor control" o "información más oportuna" o "mejores marcos para toma de decisiones", pero estos términos no tienen mucha cabida en hojas de cálculo que muestran comparaciones numéricas de costo/beneficio. Para esto, se deberá acorralar a los usuarios y hacer que identifiquen beneficios tangibles que puedan medirse y calcularse de manera cuantitativa. Si no lo puede lograr, trate de lograr que comparen su nuevo sistema con algún otro con beneficios conocidos. 1- Beneficios Tácticos Los beneficios tácticos suelen asociarse con reducciones en el personal administrativo o de oficina. Un nuevo sistema de información puede permitir que se realice la misma función con la mitad o menos del número de usuarios que se ocupaban antes. Aunque éste sea un beneficio obvio del nuevo sistema, tenga cuidado de no sobreestimar el efecto. En algunos casos, habrá menos ahorro de lo que puede haber estimado; los reglamentos del sindicato y la bondad de algunos administradores intermedios de la organización usuaria pueden evitar el despido de algunos de esos usuarios oficinistas. Un tipo de beneficio táctico mucho más interesante es el ahorro que resulta de poder procesar transacciones de negocios más rápidamente. Poder manejar más transacciones por segundo no sólo permite reducir costos de oficina, sino que puede llevar a un mejor flujo de efectivo para la organización (convirtiendo el pedido del cliente en efectivo más rápidamente, acelerando el tiempo de entrega, etc.). Un nuevo sistema también puede reportar ahorros en equipo de cómputo; el sistema anterior puede estar funcionando en una computadora principal cara, mientras que el nuevo funciona en una pequeña PC colocada en el escritorio del usuario. Y si el nuevo sistema reduce la cantidad de papel y de formas impresas, también ahí debe reflejarse un ahorro. Tenga en cuenta que pueden requerirse menos archiveros, menos espacio de oficina, menos máquinas de escribir, y posiblemente menos llamadas telefónicas entre su organización y los clientes, etc. Los costos de mantenimiento de hardware deben reducirse (a menos que esté ejecutando su nuevo sistema en el mismo equipo de cómputo que ya está instalado en la organización), y los costos de mantenimiento de software es de suponerse que serán inferiores a los del sistema actual. 2- Beneficios Estratégicos Representan la posibilidad de permitirle a la organización hacer cosas que le serían imposibles con el sistema actual. Existen varios ejemplos de beneficios estratégicos potenciales:

Identificar o atraer nuevos clientes que de otra manera no podría identificar la organización Entrar a nuevos mercados o proporcionar nuevos productos que previamente no estaban

disponibles Capturar, reproducir o distribuir conocimientos y experiencia a los que previamente sólo tenían

acceso una o dos personas dentro de la organización.

En una economía tan competitiva como la actual, un sistema de información que puede atraer nuevos clientes o evitar la pérdida de los actuales por la competencia es realmente muy valioso. Sea cual sea la situación, trate de cuantificar este beneficio en términos del aumento de clientes o de mercado y, de ahí, en términos de ganancias. Una forma más difícil de beneficio estratégico es la capacidad del sistema para proporcionar información que anteriormente no se tenía. Por ejemplo, la capacidad de identificar tendencias y patrones (tendencias de ventas por territorio, por estación, o por preferencias del cliente hacia ciertos productos).


En tanto que las técnicas de inteligencia artificial continúan creciendo, identificaremos como beneficio la capacidad de un sistema de extender el conocimiento que alguna vez fue sólo de unos cuantos expertos humanos de la organización. Así, un experto humano dentro de la organización puede tener reglas de juicio que utiliza para diagnosticar la posible causa de fallas en algún sistema mecánico. Obviamente, sería de beneficio estratégico capturar el conocimiento de dicho experto humano y duplicarlo para el uso de otros; pero podría ser aún más valioso extender la experiencia e incrementar la capacidad de diagnóstico para tratar con las fallas del sistema.

¿CÓMO EXPRESAR LOS COSTOS Y BENEFICIOS DEL SISTEMA?

Como los costos y los beneficios no se dan repentinamente, en un instante, se tendrá que demostrar los costos y beneficios que del sistema a lo largo de cierto período de tiempo. Existen cuatro métodos comunes para hacer esto:

Flujo de efectivo Rendimientos de inversiones (en inglés, ROI) Tasa interna de rendimiento (IRR) Valor neto actual (NPV)

ANÁLISIS DE RIESGOS

Como parte de los cálculos de costo-beneficio, se debe hacer un análisis de riesgos del nuevo sistema, aunque la administración no le pida uno. La razón de esto es que no podemos suponer con certeza que se lograrán los beneficios estimados, ni que se incurrirá en los gastos estimados. Las cosas pueden ser mejores, pero resulta de mayor preocupación la posibilidad de que sean peores. La administración generalmente deseará saber las consecuencias de que las cosas salgan mal durante el proyecto, y desearán saber cuáles pueden ir mal. Específicamente, querrán saber bajo qué condiciones los costos estimados podrían ser significativamente mayores, así como las condiciones bajo las cuales los beneficios fueran bastante menores de lo estimado. ¿Cómo pueden los costos ser mayores de lo estimado?

El vendedor del hardware podría quebrar. El equipo del proyecto pudiera sufrir un cambio extremo, enfermedad u otros problemas. La tecnología usada para el proyecto pudiera no funcionar como se anunció, sobre todo si jamás se

había usado antes. Podría perderse la oportunidad; por ejemplo, el sistema podría no estar listo para su instalación

sino hasta el 2 de enero, y los reglamentos gubernamentales impiden su instalación hasta el siguiente 1º de enero.

Pueden surgir problemas políticos o de contrato con sindicatos, contratistas externos, etc. El equipo del proyecto podría no tener el conocimiento necesario de la aplicación, u otras

deficiencias (preparación o experiencia inadecuadas) que lleven a una productividad menor a la esperada.

Circunstancias económicas o de negocios turbulentas podrían obligar a cancelar el contrato. Puede surgir una diversidad de gastos ocultos, por ejemplo, costos extras o trámites que no fueron

necesarios en el sistema anterior.


¿Cómo podrían no materializarse los beneficios estimados? Los usuarios operacionales podrían encontrar el uso del nuevo sistema más difícil de lo esperado,

llevando a demoras e interrupciones. (Esto es de particular importancia sí los beneficios del sistema se habían previsto en el sentido de una mayor productividad del usuario)

Podrían no ocurrir mejoras esperadas en la participación en el mercado. Tal vez el sistema no produzca más clientes, más pedidos, más negocios o más rendimientos.

El sistema podría no comportarse como se espera. Por ejemplo, no procesar tantas transacciones por segundo como se esperaba.

El valor de la nueva información disponible gracias al sistema podría resultar no tener beneficios tangibles.

Para tratar estos riesgos, a menudo resulta ser buena idea considerar el peor escenario posible, el mejor y el esperado. Será mejor entre más preciso y realista sea esto: no tiene caso engañarse a sí mismo y a la administración con suposiciones innecesariamente optimistas respecto a los costos y beneficios. De manera similar, aunque nadie espera que la situación del peor caso ocurra, es importante que la administración entienda cuan malas se podrían poner las cosas. Un punto a tener en cuenta, es que muchas veces la administración sabe de muchos más riesgos que usted (por ejemplo, una potencial fusión entre su compañía y otra, que volverá inútil al sistema). Ellos pueden evaluar dichos riesgos, y a menudo ni siquiera se los comunicarán; a usted lo necesitan para evaluar los riesgos técnicos del proyecto.


UNIDAD 10



UNIDAD 10 – HERRRAMIENTAS CASE ¿Que significa CASE? Un Ingeniero de Software debería tener en su “taller”:

Herramientas útiles que le ayuden en todos los pasos de la construcción del software Una disposición organizada que permita hallar rápidamente las herramientas y utilizarlas con

eficacia Alguien que entienda la forma de utilizar las herramientas de manera eficaz

El taller de ingeniería del software se denomina un entorno de apoyo integrado a proyectos y el conjunto de herramientas que llena ese taller se denomina ingeniería del software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería, así como de garantizar que la calidad se diseñe antes de llegar a construir el producto. Construcción De Bloques Básicos Para Case CASE puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o tan compleja como todo un entorno que abarque «herramientas», una base de datos, personas, hardware, una red, sistemas operativos, estándares, etc.

Existen 6 Bloques CASE. Cada bloque de construcción forma el fundamento del siguiente, estando las herramientas situadas en la parte superior del montón. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entornos para la ingeniería del software se construyen con éxito sobre una arquitectura de entornos que abarca un hardware y un software de sistemas adecuados. Además, la arquitectura del entorno deberá tener en cuenta los patrones de trabajo humano que se aplicarán durante el proceso de ingeniería del software. Los bloques de construcción representados en la figura representan un fundamento completo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE que se utilizan en la

actualidad no han sido construidas empleando todos los bloques de construcción anteriormente descritos. Aunque esta situación no es la ideal, se puede utilizar una herramienta CASE bastante eficiente, aunque se trate de una solicitud puntual. La integración de fuente única se produce cuando un único vendedor de herramientas CASE integra una cierta cantidad de herramientas distintas y las vende en forma de paquete. En el extremo superior del espectro de integración se encuentra el entorno de apoyo integrado a proyectos integrado (EAIP). Se han creado estándares en cada uno de los bloques de construcción descritos anterior-mente. Los fabricantes de herramientas CASE utilizan los estándares EAIP para construir herramientas que sean compatibles con el EAIP, y que por tanto sean compatibles entre sí. Clasificación de Herramientas Case Es difícil categorizar las Herramientas CASE debido a que algunas abarcan más de un nivel. Las herramientas CASE se pueden clasificar por su función, por su papel como instrumentos para admi-nistradores o personal técnico, por su utilización en los distintos pasos del proceso de ingeniería del software, por la arquitectura del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o coste. Utilizaremos la clasificación por función: (Herramientas de…)


Entornos CASE INTEGRADOS (ICASE Aunque se pueden obtener beneficios individualmente de las herramientas CASE que abarcan actividades de ingeniería del software por separado, la verdadera potencia de CASE solamente se puede lograr mediante la integración. Los beneficios son:

1. Una transferencia regular de información (modelos, programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniería y el siguiente

2. Una reducción del esfuerzo necesario para efectuar actividades globales tales como la gestión de configuración de software, el control de calidad y la producción de documentos

3. Un aumento del control del proyecto que se logra mediante una mejor planificación, monitorización y comunicación

4. Una mejor coordinación entre los miembros del personal que estén trabajando en grandes proyectos de software.

Un entorno CASE integrado debería:

Proporcionar un mecanismo para compartir la información de la ingeniería del software entre todas las herramientas dentro del entorno; • hacer posible que un cambio de un elemento de infor-mación se siga hasta los demás elementos de información relacionados;

Proporcionar un control de versiones y una gestión de configuración general para toda la información de la ingeniería del software;

Permitir un acceso directo y no secuencia1 a cualquier herramienta del entorno; Establecer un apoyo automatizado para el modelo de procesos de software que se haya

seleccionado, integrando herramientas CASE y elementos de configuración del software en una estructura estándar de desglose de trabajo;

Permitir que los usuarios de cada una de las herramientas puedan experimentar con el aspecto e interacción de la interfaz hombre-máquina

Dar soporte a la comunicación entre ingenieros del software; y Recoger métricas tanto técnicas como de gestión que se puedan utilizar para mejorar el proceso y

el producto. Para alcanzar estos objetivos, cada uno de los bloques de construcción de una arquitectura deberá encajar con los demás sin ningún tipo de limitación. Los bloques de construcción fundamentales (arquitectura del entorno, plataforma hardware y sistema operativo) deberán “unirse” a través de un conjunto de servicios de portabilidad a un marco de referencia de integración que alcance los objetivos indicados anteriormente.

Ingeniería de procesos de negocio. Modelado de procesos y gestión. Planificación de proyectos. Análisis de riesgos. Gestión de proyectos. Seguimiento de requisitos. Métricas y de gestión. Documentación. Software de sistema. Gestión de configuración de software. Control de calidad. Análisis y diseño.

Gestión de bases de datos. Herramientas PRO/SIM. Desarrollo y diseño de interfaz. Integración y pruebas. Construcción de prototipos. Programación. Desarrollo de Webs. Análisis estático. Análisis dinámico. Gestión de pruebas. Pruebas cliente/servidor. Reingeniería.


La Arquitectura De Integración Para lograr la integración, deberán existir los siguientes componentes de arquitectura:

Una base de datos (para almacenar la información) Un sistema de gestión de objetos (para gestionar los cambios efectuados en la información) Un mecanismo de control de herramientas (para coordinar la utilización de herramientas CASE) Una interfaz de usuario que proporcione una ruta consecuente entre las acciones efectuadas por el

usuario y las herramientas que están dentro del entorno. La mayoría de los modelos del marco de referencia de integración representan a estos componentes como si fueran capas, como en la figura.

Capa de Interfaz de Usuario: - Kit de Herramientas de Interfaz: contiene software

para la gestión de la interfaz hombre-máquina, y una biblioteca de objetos de visualización

- Protocolo de Presentación: es el conjunto de líneas generales que proporciona un mismo aspecto a todas las herramientas CASE

Capa de herramientas: incorpora un conjunto de servicios de gestión de herramientas con las herramientas CASE en sí. Los servicios de gestión de herramientas (SGH) controlan el comportamiento de las herramientas dentro del entorno, es decir, la multitarea. Capa de gestión de objetos (CGO): El software de esta capa

proporciona el mecanismo para la integración de herramientas. Cada herramienta CASE “se enchufa” en la capa de gestión de objetos. Capa de repositorio compartido: Es la base de datos CASE y las funciones de control de acceso que hacen posible que la capa de gestión de objetos interactúe con la base de datos. El Repositorio Case (o Base De Datos) Repositorio es un lugar de acumulación y almacenamiento. El ingeniero del software debe interactuar con el repositorio empleando herramientas CASE. El papel del repositorio en I-CASE El repositorio de un entorno I-CASE es el conjunto de mecanismos y de estructuras de datos que consiguen la integración entre datos y herramientas, y entre datos y datos. Proporciona las funciones obvias de un sistema de gestión de bases de datos, pero, además, el repositorio lleva a cabo las funciones siguientes:

Integridad de datos: Validación de las entradas efectuadas en el repositorio, para asegurar la consistencia, y efectuar automáticamente modificaciones en cascada

Información compartida: entre múltiples desarrolladores y entre múltiples herramientas; Integración datos-herramientas: establece un modelo de datos al que pueden acceder todas las

herramientas del entorno I-CASE Integración duros-datos: el sistema de gestión de bases de datos relaciona los objetos de datos de

tal manera que se puedan alcanzar las demás funciones


Imposición de la metodología Estandarización de documentos: la definición de objetos de la base de datos da lugar directamente

a un enfoque estándar para la creación de documentos de ingeniería del software. Para conseguir estas funciones, se define el repositorio en función de un metamodelo. El metamodelo determina la forma en que se almacena la información en el repositorio, la forma en que las herramientas pueden acceder a los datos y estos datos pueden ser visualizados por los ingenieros de software, el grado hasta el cual se puede mantener la seguridad e integridad de los datos, y la facilidad con que se puede ampliar el modelo ya existente para admitir nuevas necesidades. Características y contenidos Las características y contenido del repositorio se entienden especialmente bien examinándolo desde dos perspectivas: ¿Qué es lo que hay que almacenar en el repositorio, y qué servicios específicos son los que proporciona el repositorio? En general, los tipos de cosas que habrá que almacenar en el repositorio incluyen:

El problema que hay que resolver Información acerca del dominio del problema La solución del sistema a medida que va surgiendo Las reglas e instrucciones relativas al proceso de software (metodología) que se está siguiendo El plan del proyecto, sus recursos y su historia Información acerca del contexto organizativo.

Un repositorio CASE robusto proporciona dos clases distintas de servicios:

Los mismos tipos de servicios que puede uno esperar de cualquier sistema de gestión de bases de datos sofisticados (SGBD)

o Almacenamiento de datos no redundante o Acceso de alto nivel o Independencia de datos de la arquitectura o Control de transacciones o Seguridad o Consultas e informes de datos ad hoc o Apertura (Importación/Exportación de datos) o Soporte multiusuario

Servicios que son específicos del entorno CASE. o Almacenamiento de estructuras de datos sofisticadas, como diagramas, documentos y

archivos o Imposición de una integridad, para verificar los datos de un objeto en base a reglas del

negocio o Interfaz de herramientas ricas en términos semánticos, para facilitar la integración o Gestión de procesos y proyectos. o Versiones o Seguimiento de dependencias, gestión de cambios y administración de enlaces. o Seguimiento de requisitos. o Gestión de configuración o Seguimiento de auditoría

Documents

Botta - Análisis de Sistemas