3.1 TÉCNICAS ESTRUCTURADAS PARA EL ANÁLISIS DE REQUERIMIENTOS

Las técnicas son un método que aplica herramientas y reglas específicas para completar una o más fases del ciclo de vida del desarrollo de Sistemas. Las técnicas estructuradas utilizadas en el desarrollo de los Proyectos de Sistemas, buscaron superar el fracaso en muchos desarrollos convencionales, como son las siguientes técnicas:

Análisis estructurado Diseño estructurado Programación estructurada Desarrollo TOP-DOWN Equipos de programación Revisiones estructuradas

 ANALISIS ESTRUCTURADO El Análisis se refiere al "extremo inicial" de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados. El Análisis estructurado introduce el uso de las herramientas de documentación gráficas para producir un tipo diferente de especificación funcional: "la especificación estructurada".

Herramientas de documentación del Análisis Estructurado

Diagramas de flujo de datos (DFDs) Diccionario de Datos (DD) Diagramas de Entidad-Relación (ER) Diagramas de Transición de Estado (DTEs) Especificaciones de procesos.

DISEÑO ESTRUCTURADO Durante el desarrollo se determinan "qué módulos, interconectados de qué forma, solucionarán mejor un problema definido.

Elementos del Diseño Estructurado:

Técnicas de documentación Criterios de evaluación del Diseño Heurísticas del diseño Estrategias del Diseño

DESARROLLO TOP-DOWN Es una estrategia de proyecto que divide sucesivamente los problemas grandes y complejos en problemas menores y menos complejos, hasta

que el problema original pueda ser expresado como una combinación de problemas pequeños y fácilmente solucionables.

EQUIPOS DE PROGRAMACION Componentes:

Superprogramador o Programador jefe Copiloto Administrador Abogado de lenguaje de programación Instrumentador o experto en utilitarios Bibliotecario

4 razones por la que no es posible implementar

Costo del Superprogramador Conseguir que trabaje para uno un Superprogramador ¿Qué hacer con el personal que se tiene?

REVISIONES ESTRUCTURADAS Se trata de un procedimiento organizado para que un grupo de examinadores (Analistas de Sistemas, programadores) revisen el producto técnico para fines de corrección y garantía de calidad. La revisión estructurada (walktrough), es conducida por los miembros de un equipo que trabajan juntos en una base diaria, y su realización puede ser fijada en cualquier momento.

3.1.1 CARACTERISTÍCAS DEL ANÁLISIS ESTRUCTURADO

El desarrollo de un sistema de información, independientemente de su tamaño y complejidad, requiere muchas actividades coordinadas y el empleo de una diversidad de herramientas y modelos.

La metodología de desarrollo de sistemas es una forma estándar de organizar y coordinar estas actividades. 

El análisis de sistemas llega a la raíz del problema o a la necesidad y define los requerimientos de los usuarios de las siguientes características:

   1. Clarificación de requerimientos    2. Estudio de factibilidad    3. Aprobación del requerimiento

 

CLARIFICACION DE REQUERIMIENTOS

El analista debe de observar en forma objetiva lo que ocurre en la empresa, ya que muchas veces los requerimientos no están claramente establecidos, por lo que, el proyecto requerido debe examinarse para determinar precisamente lo que desea la empresa.

En muchos casos, los usuarios y los analistas de sistemas trabajan conjuntamente, el usuario tiene ideas bastante definidas acerca de la salida requerida, las entradas necesarias y, posiblemente una noción general de los controles necesarios.

ESTUDIO DE FACTIBILIDAD

Es determinar si el proyecto es factible. Los aspectos para determinar la factibilidad del proyecto son:

Factibilidad técnica: Se debe de investigar si se puede realizar el trabajo para el proyecto con el equipo actual, el personal y el software disponible.

Factibilidad económica: ¿Qué beneficios tendrá la creación del sistema en cuanto a costo/beneficios?

Factibilidad operativa: Se debe de investigar si el sistema que se desarrolla se pondrá en marcha, si habrá resistencia de los usuarios en cuanto a este.

APROBACION DEL REQUERIMIENTO

En muchas empresas tienen varios proyectos que se encuentran en marcha, por lo que la gerencia debe de decidir qué proyectos son más importantes y entonces se programan. Posteriormente, cuando se terminan dichos proyectos, puede iniciarse el desarrollo de la aplicación propuesta.

El resultado de estas actividades será aprobar el requerimiento para una atención posterior o rechazarlo como no factible.

3.1.2 ESPECIFICACIÓN FORMAL DE DATOS

Los métodos formales para el desarrollo de software o, simplemente métodos formales, son métodos que se utilizan para todas las etapas del ciclo de desarrollo de software y que tienen la característica que usan formalismos matemáticos para la representación o derivación de los elementos involucrados en cada etapa.

Algunas de las ventajas que podemos nombrar sobre una especificación formal son las siguientes:

Prototipado: Las especificaciones formales pueden llegar a ser ejecutables.

Corrección del programa: Verificación automática y formal de que el programa funciona correctamente.

Reusabilidad: Posibilidad de usar la especificación formal en distintos ámbitos.

En cuanto a la notación, una descripción formal constará de cuatro partes:

•NOMBRE. Nombre genérico del TAD. •CONJUNTOS. Conjuntos de datos que intervienen en la definición. •SINTAXIS. Signatura de las operaciones definidas -> <nombre_operación>:

<conj_dominio> → <conj_resultado> •SEMÁNTICA. Indica el significado de las operaciones.

Las distintas notaciones formales existentes difieren en la forma de definir la semántica:

Método axiomático o algebraico. Se establece el significado de las operaciones a través de relaciones entre operaciones (axiomas). Significado implícito de las operaciones.

Método constructivo u operacional. Se define cada operación por sí misma, independientemente de las otras. Significado explícito de las operaciones.

3.1.2.1 DRIAGRAMA DE FLUJO Y CONTROL DE DATOS

Para comprender mejor el movimiento lógico de los datos en un negocio, el analista de sistemas traza diagramas de flujo de datos (DFD).

Los diagramas de flujo de datos son análisis estructurados y herramientas de diseño que permiten que el analista comprenda visualmente el sistema y subsistemas como un juego de flujos de datos interrelacionados.

Símbolos                       Significado                               Ejemplo

La representación gráfica del movimiento, almacenamiento y transformación de datos es trazada con el uso de cuatro símbolos: un rectángulo redondeado para indicar procesamiento o transformaciones de datos, un cuadrado doble para mostrar una entidad de datos externa (origen o receptor de datos), una flecha para mostrar el flujo de datos y un rectángulo de extremo abierto para mostrar un almacén de datos.

El analista de sistemas extrae procesos, fuentes, almacenes y flujos de datos desde las primeras narraciones organizacionales, y usa un enfoque de arriba hacia abajo para

trazar primero un diagrama de contexto del sistema, dentro de la imagen más grande. Luego es trazado un diagrama de flujo de datos lógico a nivel 0. Se muestran los procesos y se añaden los almacenes de datos. Luego el analista crea un diagrama hijo para cada uno de los procesos del Diagrama 0.

Las entradas y salidas permanecen constantes, pero cambian los almacenes de datos y las fuentes.

La explosión del diagrama de flujo original permite que el analista de sistemas se enfoque en las representaciones cada vez más detalladas de los movimientos de datos dentro del sistema.

Luego, el analista desarrolla un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico, particionandolo para facilitar la programación. Cada proceso es analizado para determinar si debe ser un procedimiento manual o automatizado. Los procesos automatizados son agrupados subsecuentemente en una serie de programas de computadora diseñados para ser por lotes o en línea. Seis consideraciones para partición de diagramas de flujo incluyen si:

1.- Hay procesos ejecutados por diferentes grupos de usuarios, hay procesos que se ejecuten al mismo tiempo.

2.- Hay procesos que ejecuten tareas similares, los procesos por lotes pueden ser combinados para un procesamiento eficiente.

3.- Los procesos pueden ser combinados en un programa para tener consistencia de datos.

4.- O si los procesos pueden ser partidos en diferentes programas por razones de seguridad.

 

El diagrama de flujo de datos correcto para el ejemplo de la nómina.

Las ventajas de los diagramas de flujo de datos incluyen la simplicidad de la notación, usándola para obtener información más clara de los usuarios, permitiendo que el analista de sistemas conceptualice los flujos de datos necesarios sin estar atado a una implementación física particular, permitir que los analistas conceptualicen mejor las interrelaciones del sistema y sus subsistemas y analicen un sistema propuesto para determinar si han sido definidos los datos y procesos necesarios.

Características comunes de los diagramas de flujo de datos lógicos y físicos.

 

Diagrama de flujo de datos lógicos

 

Diagrama de flujo de datos físicos

El diagrama de flujo de datos físico (abajo) muestra determinados detalles que no se encuentran en el diagrama de flujo de datos lógico (arriba).

3.1.2.2 DICCIONARIO DE DATOS

Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos.

El diccionario de datos guarda los detalles y descripción de todos estos elementos.

Ejemplos:

Nombre = Título + Primer-nombre + Apellido-paterno + Apellido-materno Título = [Sr | Sra | Dr | Ing] Primer-nombre = {carácter} Apellido-paterno = {carácter} Apellido-materno = {carácter} Carácter = [A-Z|a-z| |’] a

Contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.

Razones para su utilización:

1- Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de datos. Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles. Por eso se registra la información, ya sea sobre hoja de papel o usando procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseñados específicamente para el análisis y diseño de software.

2- Para asignarle un solo significado a cada uno de los elementos y actividades del sistema. Los diccionarios de datos proporcionan asistencia para asegurar significados

comunes para los elementos y actividades del sistema y registrando detalles adicionales relacionados con el flujo de datos en el sistema, de tal manera que todo pueda localizarse con rapidez.

3- Para documentar las características del sistema, incluyendo partes o componentes así como los aspectos que los distinguen. También es necesario saber bajo qué circunstancias se lleva a cabo cada proceso y con qué frecuencia ocurren. Produciendo una comprensión más completa. Una vez que las características están articuladas y registradas, todos los participantes en el proyecto tendrán una fuente común de información con respecto al sistema.

4- Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema.

Determina si son necesarias nuevas características o si están en orden los cambios de cualquier tipo. Se abordan las características:

Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo mientras se emplea el sistema.

Preguntas: solicitudes para la recuperación o procesamiento de información para generar una respuesta específica.

Archivos y bases de datos: detalles de las transacciones y registros maestros que son de interés para la organización.

Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar transacciones y datos.

5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un informe. Aun en los manuales, se revelan errores. Contenido de un registro del diccionario

El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los elementos datos y estructura de datos.

Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si mismos no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos.

Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema. Cada uno está identificado con: Un nombre: para distinguir un dato de otro.Descripción: indica lo que representa en el sistema. Alias: porque un dato puede recibir varios nombres, dependiendo de quién uso este dato. Longitud: porque es de importancia de saber la cantidad de espacio necesario para cada dato. Valores de los datos: porque en algunos procesos solo son permitidos valores muy específicos para los datos.

Si los valores de los datos están restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario.

Estructura de datos: es un grupo de datos que están relacionados con otros y que en conjunto describen un componente del sistema. Descripción: Se construyen sobre cuatro

relaciones de componentes. Se pueden utilizar las siguientes combinaciones ya sea individualmente o en conjunción con alguna otra. Relación secuencial: define los componentes que siempre se incluyen en una estructura de datos. Relación de selección: (uno u otro), define las alternativas para datos o estructuras de datos incluidos en una estructura de datos. Relación de iteración: (repetitiva), define la repetición de un componente. Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteración. Notación

Los analistas usan símbolos especiales con la finalidad de no usar demasiada cantidad de texto para la descripción de las relaciones entre datos y mostrar con claridad las relaciones estructurales. En algunos casos se emplean términos diferentes para describir la misma entidad (alias) estos se representan con un signo igual (=) que vincula los datos.

3.1.3 ESPECIFICACIÓN DE PROCESOS

Es una herramienta de modelado de sistemas, que permite definir qué sucede en los procesos o funciones de un sistema.

El objetivo es definir qué debe hacerse para transformar ciertas entradas en ciertas salidas. No hay una única forma de realizar la especificación de procesos; existen múltiples herramientas que facilitan esta tarea, aunque debería emplearse aquellas que permitan fácil comprensión.

Algunas herramientas utilizadas para generar especificaciones de procesos son:

Lenguaje estructurado: se emplea un lenguaje natural limitado en palabras y construcciones, dándole más precisión y claridad, evitando ambigüedades (el lenguaje natural humano carece de precisión y es muy ambiguo). Definen un algoritmo

Uso de pre-condiciones y post-condiciones: describen la función del proceso, sin detallar un algoritmo específico

Otras: tablas de decisiones, lenguaje narrativo, diagramas de flujos, diagrama Nassi-Shneiderman, gráficas, etc.

Las especificaciones de proceso (o mini especificaciones) son creadas para los procesos primitivos en un diagrama de flujo de datos así como para algunos procesos de alto nivel que explotan a diagramas hijos.

Estas especificaciones explican la lógica de toma de decisiones y las fórmulas que transformarán los datos de entrada al proceso en salida. Los tres objetivos de la especificación de proceso son:

Reducir la ambigüedad de los procesos Obtener una descripción precisa de lo que se logra Validar el diseño de sistema.

Las especificaciones de proceso pueden ser usadas para analizar el diagrama de flujo de datos y el diccionario de datos por medio de un método llamado balanceo horizontal, que indica que todos los elementos del flujo de datos de salida deben ser obtenidos a partir de elementos de entrada y lógica de proceso. Las áreas no resueltas pueden ser planteadas como preguntas en entrevistas de averiguación.

Formato de especificación de procesos:

El nombre de proceso, como visualizaciones dentro del símbolo de proceso sobre el DFD.

Una descripción breve del lo que el proceso logra.

Una lista de la contribución y la circulación de datos de producto, usando los nombres encontrados sobre el diagrama de flujo de datos.

Los datos que los nombres usaron en las fórmulas o la lógica deben ajustarse al diccionario de datos, para la regularidad y la buena comunicación.

3.1.3.1 LENGUAJE NATURAL

El lenguaje natural se refiere a la utilización del lenguaje ordinario usado en la vida diaria como técnica para que el desarrollador del sistema extraiga los requisitos que desea el cliente. El mismo es la técnica más comúnmente usada para la extracción de requisitos. Su objetivo principal es lograr el entendimiento y especificación correcta por parte del desarrollar sobre las necesidades que posee el cliente para el comportamiento del sistema.

Esta técnica es usada durante la etapa de Análisis del proceso de desarrollo de un sistema. Más específicamente, dentro del Proceso de Ingeniería de Requisitos, se utiliza el lenguaje natural puro durante la etapa de Especificación.

El procedimiento de esta técnica en sí no está definido, por el contrario, se trata de una comunicación sin reglas ni acuerdos previos, que puede llevar a cabo de forma oral o escrita.

No se utiliza ningún tipo de soporte adicional (por ejemplo, formularios como en el lenguaje estructurado o diagramas como en la notación gráfica) ni lenguajes formales como ser los códigos de programación.

Las principales ventajas y motivos de uso de esta técnica son las siguientes:

Curva de Aprendizaje Fácil: Al no necesitar establecer pautas, acuerdos mutuos, códigos ni lenguajes de programación entre el cliente y el desarrollar, esta técnica puede ser utilizada sin enseñarle ni explicarle su uso al cliente. Para el cliente será como una comunicación más con otra persona, por lo que es accesible para cualquier persona.

Practicidad: Al no necesitar enseñanza ni acostumbramiento, esta técnica puede ser llevada a cabo rápidamente. Además, al utilizarse un lenguaje ordinario y común para el cliente, la extracción de requisitos se realiza con mayor fluidez.

3.1.3.2 LENGUAJE ESTRUCTURADO

El lenguaje estructurado es un lenguaje natural limitado en palabras y construcciones, lo que le da más precisión y claridad, evitando ambigüedades (el lenguaje natural humano carece de precisión y es muy ambiguo).

El lenguaje estructurado puede utilizarse para especificar un algoritmo. Luego, para que la computadora pueda procesarlo, deberá transformarse o “traducirse” a un lenguaje de programación específico.

El lenguaje estructurado es una herramienta que puede utilizarse en la especificación de procesos, en el desarrollo de sistemas.

3.1.3.3 TABLAS DE DECISIÓN

La tabla de decisión es una matriz de renglones y columnas que indican condiciones y acciones.

Las reglas de decisiones, incluidas en una tabla de decisión establecen el procedimiento a seguir cuando existen ciertas condiciones. Este método se emplea desde mediados de la década de los 50, cuando fue desarrollado por General Electric para el análisis de funciones de la empresa como control de inventarios, análisis de ventas, análisis de créditos y control de transporte y rutas. Se utiliza la tabla de decisión cuando existen muchas combinaciones.

Características de las Tablas de Decisión:

La tabla de decisión está integrada por cuatro secciones:

Identificación de Condiciones Entradas de Condiciones Identificación de Acciones Entradas de Acciones

La Identificación de Condiciones señala aquellas que son relevantes.

Las Entradas de Condiciones, indican que valor, si es que los hay, se debe asociar para una determinada condición Las entradas de Acciones muestran las acciones específicas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de éstas son verdaderas.

Utilidad Permite representar la descripción de situaciones decisivas, es decir, se representan las distintas alternativas, estados de la naturaleza y las consecuencias.

Nos proporcionan una descripción completa, correcta, clara y concisa de una situación que se resuelve por una decisión tomada en un momento específico del tiempo.

Como construir tablas de decisión.

Para desarrollar tablas de decisión, se deben emprender los siguientes pasos:

1. Determinar los factores considerados como más relevantes en la toma de decisiones. Esto permite identificar las condiciones en la decisión. Cada condición seleccionada de detener la característica de ocurrir quo no ocurrir; en este caso no es posible la ocurrencia parcial.

2. Determinar los pasos o actividades más factibles bajo condiciones que cambian (no sólo las condiciones actuales). Esto permite identificar las acciones.

3. Estudiar las diferentes posibilidades de combinaciones de condiciones. Para cualquier número N condiciones, existen 2n combinaciones a considerar, por ejemplo para tres condiciones es necesario examinar ocho posibles combinaciones 23= 8.

4. Llenar la tabla con reglas de decisiones. Existen dos formas para hacerlo.

La primera, escenario los renglones de condición con valores sí o no para cada combinación posible de condiciones. Esto es llenar la primera mitad del renglón consigo y la otra mitad con no.

El siguiente renglón se llena alternando con S y N, repitiéndose este proceso hasta llenar la tabla.

El otro método para llenar la tabla considera una condición a la vez y, por cada condición adicional, la añade a la tabla pero sin considerar las combinaciones de condiciones y acciones duplicadas.

A) Establece la primera condición y todas las acciones permisibles.

B) Añadir la segunda condición duplicando la primera mitad de la matriz y llenando los diferentes valores S y N de las dos mitades de la matriz aumentada con las nuevas condiciones.

C) Para cada condición adicional repite el paso b.

5. Marcar las entradas correspondientes a las acciones con una X para indicar que éstas se emprenden; dejar las celdas vacías o marcadas con un guión para señalar que en ese renglón no emprende ninguna acción.

6. Examinar la tabla para detectar reglas redundantes o contradicciones entre estas.

Estos sencillos lineamientos no sólo ahorran tiempo al construir una tabla de decisiones a partir de información recopilada durante la investigación sino que también es de ayuda para señalar donde falta información, donde no importan las condiciones en un proceso,

o donde existen relaciones o resultados importantes que otros no detectaron o consideraron. En otras palabras, el empleo de las tablas de decisión produce un análisis más completo y exacto.

3.1.3.4 ÁRBOLES DE DECISIÓN

El árbol de decisión es un diagrama que representan en forma secuencial condiciones y acciones; muestra qué condiciones se consideran en primer lugar, en segundo lugar y así sucesivamente. Este método permite mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella.

Un árbol de decisión sirve para modelar funciones discretas, en las que el objetivo es determinar el valor combinado de un conjunto de variables, y basándose en el valor de cada una de ellas, determinar la acción a ser tomada.

Los árboles de decisión son normalmente construidos a partir de la descripción de la narrativa de un problema. Ellos proveen una visión gráfica de la toma de decisión necesaria, especifican las variables que son evaluadas, qué acciones deben ser tomadas y el orden en la cual la toma de decisión será efectuada. Cada vez que se ejecuta un árbol de decisión, solo un camino será seguido dependiendo del valor actual de la variable evaluada.

Se recomienda el uso del árbol de decisión cuando el número de acciones es pequeño y no son posibles todas las combinaciones.

Uso de árboles decisiones.

El desarrollo de árboles de decisión beneficiado analista en dos formas. Primero que todo, la necesidad de describir condiciones y acciones llevan a los analistas a identificar de manera formal las decisiones que actualmente deben tomarse. De esta forma, es difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin importar que este dependa de variables cuantitativas o cualitativas. Los árboles también obligan a los analistas a considerar la consecuencia de las decisiones.

Se ha demostrado que los árboles de decisión son eficaces cuando es necesario describir problemas con más de una dimensión o condición. También son útiles para identificar los requerimientos de datos críticos que rodean al proceso de decisión, es decir, los árboles indican los conjuntos de datos que la gerencia requiere para formular decisiones o tomar acciones. El analista debe identificar y elaborar una lista de todos los datos utilizados en el proceso de decisión, aunque el árbol de decisión no muestra todo los datos.

Si los árboles de decisión se construyen después de completar el análisis de flujo de datos, entonces es posible que los datos críticos se encuentren definidos en el diccionario de datos (el cual describe los datos utilizados por el sistema y donde se emplean). Si únicamente se usan árboles de decisiones, entonces el analista debe tener la certeza de identificar con precisión cada dato necesario para tomar la decisión.

Los árboles de decisión no siempre son la mejor herramienta para el análisis de decisiones. El árbol de decisiones de un sistema complejo con muchas secuencias de

pasos y combinaciones de condiciones puede tener un tamaño considerable. El gran número de ramas que pertenecen a varias trayectorias constituye más un problema que una ayuda para el análisis. En estos casos los analistas corren el riesgo de no determinar qué políticas o estrategias de la empresa son la guía para la toma de decisiones específicas. Cuando aparecen estos problemas, entonces es momento de considerar las tablas de decisión.

3.2 TÉCNICAS ORIENTADAS A OBJETOS PARA EL ANÁLISIS DE REQUERIMIENTOS

Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de compartimiento específico.

Los propios objetos se pueden constituir a partir de otros , que a su vez pueden estar formados por otros objetos .Esto nos recuerda a una maquina compleja construida por partes , subpartes y sub-subpartes,etc.

La metodología de desarrollo de software orientada a objetos es cada día más usada, pues permite desarrollar software fácilmente extensible y reusable. Esto último es sólo posible si los desarrolladores conocen muy bien los fundamentos que estén basados esta metodología. Por eso, este curso revisa los conceptos más importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.

El curso parte dando a conocer la base del diseño y programación de buenas clases, tanto por si solas como a través del uso de herencia. Luego introduce el concepto de subtipos, como concepto teórico que está detrás de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Más tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseño, en donde se dan a conocer las distintas relaciones entre clases que podemos encontrar, provee mecanismos para verificar si una clase y las relaciones entre ellas están bien diseñadas, y en particular si la herencia está bien usada.

Esto es fundamental para que los diseños a objetos no sean más complicados de entender que los de procedimientos y para que el software que se diseñe sea reusable y fácil de extender. Finalmente presenta los aspectos más importantes de la etapa de análisis, dando énfasis a la especificación de casos de uso y a como detectar objetos y clases relevantes en el problema. Durante el curso se usa la notación UML (estándar) y los programas están en C++ o Java. Las clases prácticas son en C++ o Java y se usa una herramienta de apoyo al diseño.

3.2.1 CARACTERÍSTICAS DEL ANÁLISIS ORIENTADA A OBJETOS

El objetivo del análisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente. El AOO, como los métodos de análisis convencionales descritos, forma un modelo de análisis multiparte para satisfacer este objetivo.

El modelo de análisis ilustra información, funcionamiento y comportamiento dentro del contexto de los elementos del modelo de objetos.

3.2.2 ESPECIFICACIÓN FORMAL DE OBJETOS

No hay duda de que el modo de especificación tiene mucho que ver con la calidad de la solución. Los ingenieros del software que se han visto forzados a trabajar con especificaciones incompletas, inconsistentes o engañosas han experimentado la frustración y confusión que invariablemente provocan. La calidad, la fecha de entrega y el alcance  del software son las que sufren las consecuencias.

Principios de la especificación

La especificación, independientemente del modo como la realicemos, puede verse como un proceso de representación. Los requisitos se representan de manera que como fin último lleven al éxito de la implementación del software.

A continuación, se proponen algunos principios de especificación:

Separar la funcionalidad de la implementación. Desarrollar un modelo del comportamiento deseado de un sistema que

comprenda datos y las respuestas funcionales de un sistema a varios estímulos del entorno.

Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactúan con él. 

Definir el entorno en que va a operar el sistema e indicar como «una colección de agentes altamente entrelazados reaccionan a estímulos del entorno (cambios de objetos) producidos por esos agentes».                                              

Crear un modelo intuitivo en vez de un diseño o modelo de implementación.

Reconocer que «la especificación debe ser tolerante a un posible crecimiento si no es completa». Una especificación es siempre un modelo una abstracción de alguna situación real (o prevista) que normalmente suele ser compleja. De ahí que será incompleta y existirá a muchos niveles de detalle.

Establecer el contenido y la estructura de una especificación e manera que acepte cambios.

Esta lista de principios básicos proporciona la base para representar los requisitos del software. Sin embargo, los principios deben traducirse en realidad. En la siguiente sección examinamos un conjunto de directrices para la creación de una especificación de requisitos.

3.2.2.1 CASOS DE USO

Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. En otras palabras, un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema.

Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas

3.2.2.2 MODELADO DE CLASES, RESPONSABILIDADES Y COLABORACIONES

Una vez que se han desarrollado los escenarios de uso básicos para el sistema, es el momento de identificar las clases candidatas e indicar sus responsabilidades y colaboraciones. El modelado de clases-responsabilidades colaboraciones (CRC) aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto. Se describe el modelado CRC de la siguiente manera:

Un modelo CRC es realmente una colección de tarjetas índiceestándar que representan clases. Las tarjetas están divididas en tres secciones. A lo largo de la cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores.

En realidad, el modelo CRC puede hacer uso de tarjetas índice virtual o real. El caso es desarrollar una representación organizada de las clases. Las responsabilidades son los atributos y operaciones relevantes para la clase. Puesto de forma simple, una responsabilidad es «cualquier cosa que conoce o hace la clase». Los colaboradoresson aquellas clases necesarias para proveer a una clase con la información necesaria para completar una responsabilidad. En general, una colaboración implica una solicitud de información o una solicitud de alguna acción.

Clases

Las pautas básicas para identificar clases y objetos son las entidades externas, cosas, ocurrencias o sucesos, roles, unidades organizativas, lugares, o estructuras. Una técnica para identificarlos en el contexto de un problema del software es realizar un análisis gramatical con la narrativa de procesamiento para el sistema. Todos los nombres se transforman en objetos potenciales. Sin embargo, no todo objeto potencial podrá incluirse en el modelo.

Un objeto potencial debe satisfacer estas seis características para poder ser considerado como posible miembro del modelo:

retener información:el objeto potencial será útil durante el análisis si

la información sobre el mismo debe guardarse para que el sistema funcione

Servicios necesarios: el potencial objeto debe tener un conjunto de operaciones identificables que permitan cambiar los valores de sus atributos.

Múltiples atributos: durante el análisis de requisitos nos centramos más en la información más importante. Un objeto con un solo atributo puede, en efecto, ser Útil durante el diseño, pero probablemente será un atributo de otro objeto durante el análisis de actividades.

Atributos comunes: el conjunto de atributos definido para la clase debe ser aplicable a todas las ocurrencias del objeto.

Operaciones comunes: el objeto potencial debe definir un conjunto de operaciones aplicables, al igual que antes, a todos los objetos de la clase.

Requisitos esenciales: las entidades externas que aparecen en el espacio del problema y producen información esencial para la operación de una solución para el sistema casi siempre se definen como objetos en el modelo de requisitos

a) Diagrama de casos de uso de alto nivel.

b) Diagrama de casos de uso detallado.

Una clase potencial debe satisfacer las seis características de selección anteriores si va a ser incluida en el modelo CRC.

Se extiende las características de clasificación sugiriendo, además de las existentes, las siguientes:

Clases dispositivo. Modelan entidades externas tales como censores, motores y teclados.

Clases propiedad. Representan alguna propiedad importante del entorno del problema (por ejemplo: establecimiento de créditos dentro del contexto de una aplicación de préstamos hipotecarios).

Clases interacción. Modelan interacciones que ocurren entre otros objetos (por ejemplo: una adquisición o una licencia).

Adicionalmente, los objetos y clases pueden clarificarse por un conjunto de

características:

Fungibilidad. ¿Representa la clase algo tangible o palpable (por ejemplo, un teclado o sensor), o representa información más abstracta (por ejemplo: una salida prevista)?

Inclusividad. ¿Es la clase atómica (es decir, no incluye otras clases) o es agregada (incluye al menos un objeto anidado)?

Secuencia. ¿Es la clase concurrente (es decir posee su propio hilo de control) o secuencial (es controlada por recursos externos)?

Persistencia. La clase es temporal (se crea durante !a ejecución del programa y es eliminada una vez que éste termina), o permanente (es almacenada en una base de datos)?

Integridad. ¿Es la clase corrompible (es decir, no protege sus recursos de influencias externas) o es segura (la clase refuerza los controles de accesos a- sus recursos)? Usando estas categorías de clases, pueden ampliarse las «tarjetas índice» creadas como parte del modelo CRC para incluir el tipo de la clase y sus características.

Responsabilidades

Las pautas básicas para identificar responsabilidades (atributos y operaciones). Para resumir, los atributos representan características estables de una clase, esto es, información sobre la clase que debe retenerse para llevar a cabo los objetivos del software especificados por el cliente.

Los atributos pueden a menudo extraerse del planteamiento de alcance o discernirse a partir de la comprensión de la naturaleza de la clase. Las operaciones pueden extraerse desarrollando un análisis gramatical sobre la narrativa de procesamiento del sistema. Los verbos se transforman en candidatos a operaciones. Cada operación elegida para una clase exhibe un comportamiento de la clase.

Sugerimos cinco pautas para especificar responsabilidades para las clases:

1. La inteligencia del sistema debe distribuirse de manera igualitaria. Toda aplicación encierra un ciertogrado de inteligencia, por ejemplo, lo que sabe el sistemay lo que puede hacer. Esta inteligencia puededistribuirse ente las clases de varias maneras. Lasclases «tontas» (aquellas con pocas responsabilidades)pueden modelarse de manera que actúen comosirvientes de unas pocas clases «listas» (aquellas conmuchas responsabilidades).

Aunque este enfoquehace que el flujo de control dentro de un sistema seaclaro, posee algunas desventajas: (1) Concentra todala inteligencia en pocas clases, haciendo los cambiosmás difíciles; (2) Tiende a necesitar más clases y porlo tanto el esfuerzo de desarrollo aumenta.   Por esta razón, la inteligencia del sistema debe distribuirse de manera igualitaria     entre las clases de una aplicación. Como cada objeto conoce y actúa sobre algunos pocos elementos (generalmente bien definidos y claros), la cohesión del sistema se ve incrementada.

Adicionalmente, los efectos colaterales provocados por cambios tienden a

amortiguarse debido a que la inteligencia del sistema se ha descompuesto entre muchos objetos.  Para determinar si la inteligencia del sistema está distribuida equitativamente, las responsabilidades definidas en cada tarjeta índice del modelo CRC deben ser evaluadas para determinar si cada clase posee una lista de responsabilidades extraordinariamente grande. Esto indica una concentración de inteligencia. Además, las responsabilidades de cada clase deben mostrar el mismo nivel de abstracción.

Por ejemplo, entre la lista de operaciones de una clase agregada llamada Comprobación de cuenta existen dos responsabilidades: saldo-de-la cuenta y verificar-talones-cobrados. La primera operación (responsabilidad) implica un complejo procedimiento matemático y lógico. La segunda es una simple actividad para empleados. Debido a que estas dos actividades no están al mismo nivel de abstracción, verificar-talones-cobrados debe situarse dentro de las responsabilidades de la clase Comprobación de entradas, la cual está contenida en la clase agregada Comprobación de cuenta.

2. Cada responsabilidad debe establecerse lo más general posible. Esta directriz implica que las responsabilidades generales (tanto los atributos como las operaciones) deben residir en la parte alta de la jerarquía de clases (puesto que son genéricas, se aplicarán a todas las subclases). Adicionalmente, debe usarse el polimorfismo para definir las operaciones que generalmente se aplica a la superclase, pero que se implementan de manera diferente en cada una de las subclases.

3. La información y el comportamiento asociado a ella, debe encontrarse dentro de la misma clase. Esto implementa el principio O0 de encapsulamiento. Los datos y procesos que manipulan estos datos deben empaquetarse como una unidad cohesionada.

4. La información sobre un elemento debe estar localizada dentro de una clase, no distribuida a través de varias clases. Una clase simple debe asumir la responsabilidad de almacenamiento y manipulación de un tipo específico de información. Esta responsabilidad no debe compartirse, de manera general, entre varias clases. Si la

información está distribuida, el software se torna más difícil de mantener y probar.

5. Compartir responsabilidades entre clases relacionadas cuando sea apropiado. Existen muchos casos en los cuales una gran variedad de objetos exhibe el mismo comportamiento al mismo tiempo. Como un ejemplo, considere un videojuego que debe mostrar los siguientes objetos: jugador, cuerpo-del-jugador, brazos-del-jugador, cabeza-del-jugador. Cada uno de estos atributos tiene sus propios atributos (P: posición, orientación, color, velocidad), y todos deben actualizarse y visualizarse al mover el usuario el joystick. Las responsabilidades actualizar y visualizar deben, por lo tanto, compartirse por los objetos señalados. El jugador sabe cuándo algo ha cambiado y se requiere actualizar; colabora con los otros objetos para alcanzar una nueva posición u orientación, pero cada objeto controla su propia visualización.

Colaboradores

Las clases cumplen con sus responsabilidades de una de las dos siguientes maneras: (1) una clase puede ser sus propias operaciones para manipular sus propios tributos, cumpliendo por lo tanto con una responsabilidad articular, o (2) puede colaborar con tres clases. Definiremos las colaboraciones en la siguiente forma:

Las colaboraciones representan solicitudes de un cliente a un servidor en el cumplimiento de una responsabilidad del cliente. Una colaboración es la realización de un contrato entre cliente y el servidor. Decimos que un objeto colabora con otro, si para ejecutar una responsabilidad necesita enviar cualquier         al otro objeto.

Una colaboración simple fluye en una dirección, representando una solicitud del cliente al servidor. Desde el punto de vista del cliente, cada una de sus colaboraciones está asociada con una responsabilidad particular implementada por el servidor.

Las colaboraciones identifican relaciones entre clases. Cuando todo un conjunto de clases colabora para satisfacer algún requisito, es posible organizarlas en un subsistema (un elemento del diseño).

Las colaboraciones se identifican determinando si una clase puede satisfacer cada responsabilidad. Si no puede, entonces necesita interactuar con otra clase. De aquí surge lo que hemos llamado una colaboración.

Como un ejemplo, considere la aplicación Hogar- Seguro. Como una parte del procedimiento de activación, el objeto panel de control debe determinar si existen sensores abiertos. Se define una responsabilidad llamada determinar-estado-del-sensor. Si hay sensores abiertos, el panel de control debe poner el atributo estado al valor «no preparado». La información del sensor puede obtenerse del objeto sensor. Por lo tanto, responsabilidad determinar-estado-del-sensor puede ejecutarse solamente si el panel de control trabaja en colaboración con el sensor.

Para ayudar en la identificación de colaboradores, el analista puede examinar tres relaciones genéricas diferentes entre clases: (1) la relación es-parte-de, (2) la relación tiene-conocimiento-sobre, y (3) la relación depende-de. A través de la

creación de un diagrama de relación entre clases, el analista desarrolla las conexiones necesarias para identificar estas relaciones. Cada una de las tres relaciones genéricas se considera brevemente en los párrafos siguientes.

Todas las clases que forman parte de una clase agregada están conectadas a ésta a través de una relación. Considere las clases definidas para el juego de vídeo mencionado anteriormente, la clase cuerpo-del jugador es-parte-de, al igual que cuerpo-del-jugador, brazos-del-jugador y cabeza-del-jugador.

Cuando una clase debe obtener información sobre otra, se establece la relación tiene-conocimiento-sobre. La responsabilidad determinar-estado-del-sensor es un ejemplo de la relación tiene-conocimiento-sobre. La relación depende-de implica que dos clases poseen una dependencia no realizable a través de tiene-conocimiento- sobre o es-parte de. Por ejemplo, la cabeza-del jugador debe estar siempre conectada al cuerpo del- jugador (a menos que el videojuego en particular sea muy violento), aunque cada objeto puede existir sin conocimiento directo sobre el otro. Un atributo del objeto cabeza-del-jugador llamado posición-central se obtiene de la posición-central del objeto cuerpo-del jugador. Esta información se obtiene a través de un tercer objeto, jugador, el cual la obtiene del cuerpo-del-jugador. Por lo tanto, la cabeza-del-jugador depende-de cuerpo-del-jugador.

En todos los casos, el nombre de la clase colaboradora se registra en la tarjeta índice del modelo CRC al lado de la responsabilidad que ha generado dicha colaboración.

Por lo tanto, la tarjeta índice contiene una lista de responsabilidades y de colaboraciones correspondientes que posibilitan se realicen las responsabilidades su realización. Cuando se ha desarrollado un modelo CRC por completo, los representantes del cliente y de las organizaciones de ingeniería del software pueden recorrer el modelo haciendo uso del siguiente enfoque.

A todos los participantes de la revisión (del modelo CRC) se les da un subconjunto de las tarjetas índice del modelo CRC. Las tarjetas que colaboran deben estar separadas (esto es, ningún revisor debe poseer dos tarjetas que colaboren).

Todos los escenarios (y sus correspondientes diagramas de casos de uso) deben organizarse en categorías.

El director de la revisión lee el caso de uso con atención. Cuando el director llega a un objeto identificado, se traspasa la señal a la persona que posee la clase tarjeta índice correspondiente.

Por ejemplo, el caso de uso mencionado anteriormente contiene la siguiente narración:

El propietario de la casa observa el panel de control de Hogar seguro para determinar si el sistema está listo para entrada de datos. Si el sistema no está listo, el propietario debe cerrar, físicamente, las ventanas y puertas para que aparezca el indicador de «listo». [Un indicador no listo implica que un sensor está abierto, esto es que una puerta o ventana está abierta.  Cuando el director de la revisión llega al

«panel de control» en la narrativa del caso de uso, se pasa la señal a la persona que posee la tarjeta panel de control. La frase «implica que un sensor está abierto» requiere que la tarjeta índice contenga una responsabilidad  que validará esta implicación (la responsabilidad determinar-estado-del-sensor realiza esta acción). Al lado de la responsabilidad en la tarjeta índice está el colaborador sensor. La señal se pasa entonces al objeto sensor.

Cuando se pasa la señal, se le pide al que posee la tarjeta de la clase que describa las responsabilidades mencionadas en la tarjeta. El grupo determina si una (o más) de las responsabilidades satisface el requisito del caso de uso.

Si las responsabilidades y colaboraciones mencionadas en la tarjeta índice no pueden acomodarse al caso de uso, se hacen modificaciones a las tarjetas. Esto puede incluir la definición de nuevas clases (y sus correspondientes tarjetas índices CRC) o la especificación de responsabilidades y colaboraciones nuevas o revisadas en tarjetas existentes.

 

3.2.2.3 DEFINICIÓN DE ATRIBUTOS

Atributo: es una característica de un archivo o carpeta que lo hace oculto, de sistema, de solo lectura, etc.

Por ejemplo, se podría tener una entidad llamada “Alumno”. Esta entidad puede estar constituida por uno o más atributos, que son propiedades de la entidad “Alumno” que interesan para almacenarse en la base de datos.

Por ejemplo, la entidad “Alumno” podría tener los atributos: nombre, apellido, año de nacimiento, etc.

La elección de los atributos de una entidad depende del uso que se le dará a la base de datos. El alumno puede tener una “religión”, pero si no interesa al fin de la base de datos, no es necesario almacenarla en un atributo.

3.2.2.4 DEFINICIÓN DE SERVICIOS

El servicio es llevado a cabo por una organización o personal encargado de atender una necesidad pública o privada.

La definición de servicios es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación

temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto; así como la identificación de los servicios que va a prestar el sistema a cada usuario participante.

 

 

 

 

 http://www.tutoriales.itsa.edu.mx/sistemasinformacion1/index.php#

3.2.3 PROTOTIPOS RÁPIDOS EN LA DETERMINACIÓN DE REQUERIMIENTOS

Los prototipos son una visión preliminar del sistema futuro que se implantara.La elaboración de prototipos de un sistema de información  es una técnica valiosa para la recopilación rápida de información específica a cerca de los requerimientos de información de los usuarios.

Los prototipos efectivos deben hacerse tempranamente  en el ciclo de vida del desarrollo de sistemas, durante la fase de determinación de requerimientos.

En esta forma el analista está buscando las reacciones iníciales de los usuarios y de la administración hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisión que detallan que parte del sistema necesita realizarse primero.

Tipos de Información que busca el Analista durante la Elaboración de Prototipos.

Reacciones del usuario. Innovaciones. Sugerencias del usuario. Plan de revisión.

Reacciones: Son recopiladas por medio de observaciones, entrevista y formas de retroalimentación, diseñadas para recoger la opinión de cada persona acerca del prototipo cuando interactúa con él.

Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo incluyendo el agrado que tenga el usuari5o al sistema.

Sugerencias: El analista también está interesado en la sugerencia de los usuarios  y la administración acerca como refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de tiempo especifico.

El tiempo que pasan los usuarios con el prototipo depende por lo general de su dedicación e interés en el proyecto de sistemas.  Las sugerencias son el producto de la interacción de los usuarios con el prototipo.

Estas sugerencias deben apuntar a la analista hacia formas de refinación, cambio o limpieza del prototipo para que se ajuste mejor a las necesidades de los usuarios.

Innovaciones: Son parte de las informaciones buscada por el equipo de análisis de sistema. Son capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el prototipo.

Van más allá de las características prototípicas actuales añadiendo algo nuevo e innovador.

Plan de Revisión: Ayuda a identificar prioridades para lo que se debe construir un prototipo a continuación. En situaciones donde están involucradas muchas ramas de la organización, los planes de revisión ayuda a determinar para cuáles hay que construir un prototipo a continuación.

La información recolectada  en la fase de echadura del prototipo permite al analista asignar prioridades y redirigir los planes sin realizar gastos  con un mínimo de ruptura. La elaboración de prototipo y la planeación van mano a mano.

TIPOS DE PROTOTIPO

Prototipo Parchado: Es un sistema que tiene todas las características propuesta pero es realmente un modelo básico que eventualmente será mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante.

Prototipo no Operacional: La segunda concepción  de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseño.

 Este puede ser hecho cuando la codificación requerida por las aplicaciones es muy amplia para hacerse el prototipo y, sin embargo se puede obtener una idea útil del sistema por medio de la elaboración de prototipos  de la entrada y salida solamente.

Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido al costo y tiempo excesivo podría no ser realizado, sin embargo  se puede tomar algunas de las utilidades del sistema con base en la entrada y salida ya en el prototipo.

Prototipo Primero de una Serie: Una tercera concepción de la elaboración de prototipos involucrados la creación de un primer modelo o escala completa de un sistema, llamado también piloto.

Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interacción realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que presente.

Prototipo de Características Seleccionadas: Un prototipo de características seleccionada permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en fecha posterior.

Se refiere a la construcción de un modelo operacional que incluye algunas, pero no todas, de las características que tendrá el sistema final.

Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos, de modo que si las características  reciben una evaluación satisfactoria, éstas puedan incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo inmenso en interfaces.

Los prototipos hechos en esta forma son parte del sistema actual, no son simplemente una maqueta.

DESARROLLO DE UN PROTOTIPO

Cuando haya que decidir si hay que incluir la elaboración de prototipos como parte del ciclo de vida de desarrollo de sistemas, el analista necesita considerar cuál tipo de problema está siendo resuelto y en qué forma el sistema presenta la solución.

Lineamientos para el Desarrollo de un Prototipo.

Trabajar en módulos manejables. Construir el prototipo rápidamente. Modificar el prototipo en interacción sucesiva. Enfatizar la interfaz del usuario.

Trabajar en Módulos Manejables: Es bueno que el analista  en modelos manejables cuando se realiza el prototipo de algunas de las características de un sistema para obtener un modelo funcional.

Un modelo manejable es aquel que permite la interacción con sus características principales, pero todavía puede ser construido por separado de otros módulos del sistema. Las características del módulo que se consideran menos importantes son intencionalmente dejadas fuera del prototipo inicial.

Construcción Rápido del Prototipo: La velocidad es esencial para la elaboración satisfactoria de un prototipo  en un sistema. El prototipo ayuda a acortar el tiempo de la interacción del sistema con el usuario para que pueda empezar a experimentar con él.

Se usan técnicas de recolección de información tradicional tales como: entrevistas, las observaciones e investigaciones de datos de archivo.

La elaboración de un prototipo debe llevarse a cabo en una semana, para construir un prototipo tan rápidamente se deben de usar herramientas especiales tales como: Los sistemas de administración de las base de datos y software, existente que permitan la entrada y salida generalizada.

En esta etapa del ciclo de vida el analista sigue recopilando información acerca de lo que se necesita y quieren los usuarios del sistema.

El poner un  prototipo operacional rápidamente junto a las primeras etapas del ciclo de vida de desarrollo de sistemas, permite obtener observaciones valiosas sobre la manera en que se debe realizar el resto del proyecto. De este modo se le va mostrando al usuario como actúan las partes del sistema.

Modificaciones del Prototipo: Un tercer lineamiento para el desarrollo del prototipo es que debe ser flexible para futura modificaciones. Esto significa crearlo en módulos que no sean muy interdependientes.

Por lo general el prototipo es modificado varias veces pasando a través de varias interacciones. Los cambios al prototipo deben mover al  sistema  más cerca a lo que los usuarios dicen que es importante.

Cada modificación necesitan otras evaluaciones de los usuarios, estas modificaciones se deben realizar velozmente en uno o dos días, esto depende también del usuario y que tan rápido sea su evaluación.

Enfatizar la Interfaz de Usuarios: La interfaz del usuario con el prototipo (y eventualmente con el sistema) es muy importante debido que lo que se está tratando realmente de lograr con el prototipo es hacer que los usuarios muestren cada vez más sus requerimientos  de información, debe ser capaz de interactuar fácilmente con el prototipo del sistema.

El objetivo del analista es diseñar una interfaz que permita al usuario interactuar con el sistema con un mínimo de entrenamiento y que permita el máximo de control del usuario sobre las funciones representadas.

DESVENTAGAS DE LOS PROTOTIPOS

Puede ser bastante difícil el manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema más grande.

Es que si un sistema es muy necesario y es bienvenido rápidamente, puede ser aceptado el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin los refinamientos necesarios.  En este caso el prototipo no tendrá las funciones necesarias  y eventualmente cuando se dé cuenta  de las deficiencias  se puede desarrollar un rechazo del usuario.

VENTAJAS DE LOS PROTOTIPOS

Cambio de un Sistema en Etapas Tempranas de sus Desarrollo: La elaboración  de prototipos satisfactoria depende de la retroalimentación temprana y frecuente de los usuarios para que ayuden a modificar  el sistema y hagan que tenga una respuesta más ágil a las necesidades actuales.  Los cambios tempranos son menos caros  que los cambios hechos posteriormente  en el desarrollo del proyecto.

Desechado de Sistemas Indeseables: Una segunda ventaja del uso de prototipos como una técnica para la recopilación de información es la posibilidad de desechar un sistema que no es lo que los usuarios y analistas esperaban.

Diseño de un Sistema para las Necesidades y Expectativas de los Usuarios: Una tercera ventaja de la elaboración de prototipos es que el sistema que está siendo desarrollado debe ajustarse mejor  a las necesidades y expectativas de los usuarios. Esto quiere decir que se pueden atacar las necesidades de usuarios y expectativas más de cerca.

 

3.3 TÉCNICAS BASADAS EN COMPONENTES

Como se ha adelantado, la técnica se centra en un sistema para la resolución distribuida de problemas basado en un sistema de agentes autónomo y de componentes. En este sentido, se puede pensar en problemas concretos definidos por el usuario indicando los parámetros mínimos para hacer la descomposición jerárquica del problema en un conjunto de tareas que se distribuirán entre los agentes del sistema.

Una práctica generalizada en un proyecto Software es utilizar partes Software ya desarrolladas en proyectos previos o adquiridos por terceras partes. Esta cultura de reutilización es esencial en casi todas las organizaciones que desarrollan Software. Sin embargo, la mayoría de los desarrolladores de Software suelen utilizar métodos de desarrollo internos a la organización que conducen, en la mayoría de los casos, a aplicaciones mal construidas, retrasos en los plazos de finalización del proyecto, y un aumento en los costos finales del desarrollo.

Esto se debe a la falta de procesos y técnicas bien definidas que guíen a los desarrolladores de Software durante la construcción de la aplicación basada en reutilización.

El sueño de los especialistas en ingeniería del Software ha sido disponer de “factorías de Software” donde partes Software ya estandarizadas de una aplicación puedan ser

automáticamente seleccionadas desde un catálogo y ensambladas e implantadas fácilmente como solución a una necesidad de desarrollo de la organización.

3.3.1 INGENIERÍA DEL DOMINIO

La ingeniería de dominio se puede definir como el proceso clave que se necesita para el diseño sistemático de una arquitectura y de un conjunto de elementos software reutilizables que pueden ser usados en la construcción de una familia de aplicaciones relacionadas o subsistemas.

La  ingeniería se encarga de la definición y búsqueda de nuevos componentes, y de la realización de ensayos de investigación y validación.

El objetivo fundamental de la ingeniería de dominio es la optimización del proceso de desarrollo del software en un espectro de múltiples aplicaciones que representan un negocio común o problema de dominio.

La reutilización del software dentro de un dominio de aplicación pasa por el descubrimiento de elementos comunes a los sistemas pertenecientes a dicho dominioSe produce un cambio de un desarrollo orientado a un único producto software a un desarrollo centrado en varios productos que comparten unas

Características formando una familia

Una ingeniería de dominio deficiente puede resultar en:

• Mala absorción de los procesos de soporte.• Problemas inesperados y procesos erróneos• Pérdida de oportunidades y mala utilización de recursos.• Reducción de los niveles de calidad.

3.3.2 IDENTIFICACIÓN Y CLASIFICACIÓN DE LOS COMPONENTES REUTILIZABLES

Clasificación De Componentes:

Tamaño

El tamaño de los componentes puede ser medido por medio de las métricas utilizadas en diseño orientado a objetos. Esto significa que la medición del tamaño de un componente puede ser medido a través de:

• Líneas de Código (LDC)

• Orientadas a Función

Complejidad

En algunas ocasiones, son utilizadas métricas de tamaño para evaluar la complejidad, pero es recomendable hacer uso de otro tipo de métricas. Si un componente es

demasiado trivial no podrá sacársele mayor provecho en su reutilización, y si el componente es demasiado complejo será difícil asegurar su calidad.

Métricas de Complejidad

“Complejidad Ciclo matica”, este método mide el número de decisiones lógicas en un segmento de código:

• CPC (Component Plain Complexity): Mide la complejidad del componente por medio de la suma de clases, clases abstractas e interfaces, la complejidad de clases y métodos.

• CSC (Component Static Complexity): Se centra en la estructura interna del componente por medio de una visión estática del mismo, utilizando variables como la relación entre las clases y el peso e cada relación.

• CDC (Component Dynamic Complexity): Se centra en el número de mensajes que pasan dentro del componente por medio de una visión dinámica, evaluando variables como la frecuencia en el intercambio de mensajes entre clases y la complejidad de los mensajes.

• CCC (Component Cyclomatic Complexity): Esta medida de complejidad es utilizada cuando el componente ya ha sido finalizado. Utiliza como variables el código desarrollado, la suma de las clases, interfaces, métodos definidos en cada una de las interfaces.

Mantenibilidad

La Mantenibilidad de un sistema es la facilidad con la cual puede ser modificado frente a cambios en el ambiente, requerimientos funcionales o especificaciones funcionales.

Reusabilidad

La reusabilidad de un componente se puede medir a partir de dos diferentes perspectivas, estas son:

• Cómo puede un componente ser reutilizado: Este tipo de medida tiene en cuenta las siguientes variables: El número de cada método de interface que puede proveer funciones en común entre varias aplicaciones en un dominio, el número de métodos declarados en la interface que pertenecen al componente.

• Cómo es re - usado un componente en una aplicación particular: Las variables que se miden para este objetivo en particular son: Las líneas de código re - utilizadas por el componente en una aplicación, el total de líneas entregados en la aplicación. La combinación de estas dos variables resulta el porcentaje de funcionalidad que aporta el componente dentro de toda la aplicación

Frecuencia de rehusó

El número de veces que ha sido utilizado un componente dentro de distintas aplicaciones, es sin lugar a dudas el mejor indicador de frecuencia de re– uso. Cabe

anotar que este atributo puede ser solo medido en componentes que ya han sido expuestos al mercado.

Confiabilidad

Es la probabilidad de falló en el funcionamiento del componente dentro de cierto escenario operacional.

3.3.3 CARACTERIZACIÓN DE LOS COMPONENTES

Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios y que permita su clasificación.

Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.

Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.

Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.

Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.

Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.

Es genérico: Sus servicios debe servir para varias aplicaciones.

Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación. Independiente de la plataforma: Hardware, Software, S.O.

Caracterización de los componentes o requerimientos:

• Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

• Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

• Completo: Un requerimiento esta completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la Información suficiente para su comprensión.

• Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

• No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

• Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas

3.4 OTRAS TÉCNICAS

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio de esta es una prueba.

Análisis estructurado:

El desarrollo de un sistema de información, independientemente de su tamaño y complejidad, requiere muchas actividades coordinadas y el empleo de una diversidad de herramientas y modelos. La metodología de desarrollo de sistemas es una forma estándar de organizar y coordinar estas actividades. El análisis de sistemas llega a la raíz del problema o a la necesidad y define los requerimientos de los usuarios.

Herramientas para Análisis:

Estas herramientas ayudan a los especialistas en sistemas a documentar un sistema existente, ya sea éste manual o automatizado, u a determinar los requerimientos de una nueva aplicación. Herramientas para la recolección de datos. Capturan detalles que describen los sistemas y procedimientos en uso. Documentan procesos y actividades de decisión. Se utilizan para apoyar la tarea de identificar requerimientos.

Herramientas para la diagramación. Crean representaciones gráficas de sistemas y actividades.

Apoyan el dibujo y revisión de diagramas de flujo de datos e iconos asociados con el análisis estructurado. Asimismo incluyen programas para representación en diagramas de flujo.

Herramientas para el diccionario. Registran y mantienes descripciones de los elementos del sistema tales como grupos de datos, procesos y almacenamiento de datos. Con

frecuencia proporcionan la capacidad de examinar las descripciones del sistema para decidir si son incompletas o inconsistentes.

Métodos para la Obtención de Información:

Todo análisis y diseño de un sistema implica la búsqueda y obtención de información relevante para la estructuración y definición de problemas, generación de soluciones, validación de soluciones, etc.

La información en una organización no siempre es fácil de obtener, más bien es un proceso lento y costoso, que exige tiempo y dedicación por parte del analista de sistemas. Las fases de búsqueda de información en cualquier proyecto, suelen ser grandes consumidoras de tiempo, y el éxito de los resultados depende en gran medida de la calidad de la información.

Es muy común que la información requerida no se encuentre escrita, o inclusive que ésta no se conozca. Esto hace necesaria la interacción del analista con las personas del sistema para identificar y/o generar la información faltante. Si se cuenta con información escrita formal y adecuada utilícelas, le ahorraría tiempo y le facilitaría la comprensión del sistema.

Existen métodos básicos para recopilar información dentro de una organización o sistema social. Estos incluyen

a) Cuestionarios b) Entrevistas c) Sondeos d) Encuestas e) Collage f) Dibujos g) Diagramas de flujo de datos h) Tablas de Organización i) Descripción de puestos j) Manuales Operativos. k) Representación física de las Organizaciones. Prototipeo:

Modelo de prototipeo, como por ejemplo podemos elaborar:

• Prototipo de requerimientos: En este caso se comienza con una serie de requerimientos iníciales los cuales se van modificando de acuerdo a lo que el usuario necesite, para posteriormente para a construir el producto de software

• Prototipo de Interfaz de usuario: Para este caso se elaboran las ventanas principales del producto, para posteriormente ser mostradas al usuario, y que este a su vez realice las modificaciones que crea convenientes. También observamos lo relacionado a los enfoques de prototipaje:

• Prototipo desechable: Es una especie de muestra, que nos sirve para probar determinados requerimientos, pero la característica de este enfoque, es que no puede ser transformado en el producto final.

• Prototipo Evolutivo: Este prototipo trabaja sobre el sistema final en donde se va a implantar el producto de software, también este prototipo se va mejorando de la mano del usuario y desarrollador, hasta llegar a obtener el producto final.