Instituto Vygotsky

Licenciatura: Tecnologías y Sistemas de Información

Materia: Sistemas de Información

Profe: Lucio Cesar Román Rafael

Alumno: Guillermo Alexis Hernández Miranda

6° Cuatrimestre

Sistemas de Información

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

3.1.1 CARACTERÍSTICAS DEL ANÁLISIS ESTRUCTURADO

El desarrollo de un sistema de información, independientemente de su tamaño y complejidad, requieren muchas actividades coordinadas y el empleo de una diversidad de herramientas y de 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 aprobaciones de requerimiento

3.1.2 ESPECIFICACIÓN FORMAL DE DATOS

Los métodos formales para el desarrollo de software, 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:

Prototipito: 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 constara de cuatro partes

+NOMBRE. Nombre genérico

+CONJUNTOS. Conjuntos de datos que intervienen en la definición.

+SINTAXIS. Signatura de las operaciones definidas nombre operación

+SEMANTICA. Indica el significado de las operaciones.

3.1.2.1 DIAGRAMA DE FLUJO Y CONTROL DE DATOS

Para comprender el mejor movimiento lógico de los datos en un negocio, el analista de sistemas traza diagramas de flujo de datos. El diagrama 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. La representación gráfica de movimientos, almacenamiento y transformación de datos es trazada con el uso de cuatro símbolos: un rectángulo redondeado para indicar procesamientos o transformaciones de datos, cuadrado doble para indicar una entidad de datos externa (origen o receptor de datos), una flecha para mostrar el flujo de datos un rectángulo de extremo abierto para mostrar un almacén de datos.

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.

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 análisis 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 más importantes son flujos de datos, almacenes de datos y procesos.

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

3.1.3 ESPECIFICACIÓN DE PROCESOS

Es una herramienta modelado de sistemas, que permite definir que 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, a un que debería emplearse a aquella que permite 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: describe la función del proceso, sin detallar un algoritmo específico.

Otras: tablas de decisiones, lenguaje narrativo, diagrama de flujo, diagrama NassiShneiderman gráficas, etc.

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, 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 proceso de esta técnica en si no está definido, por el contrario, se trata de una comunicación sin reglas ni acuerdos previos, que puede llevar acabo de forma oral o escrita.

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 programa 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 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.

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

+ Identificación de Condiciones

+ Entradas de condiciones

+ Identificación de acciones

+ Entradas de acciones

3.1.3.4 ARBOLES 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 la 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 lección de ser tomada.

Los arboles de decisión son normalmente construidos a partir de la descripción de la narrativa de un problema. Ellos prevén una visión grafica de la toma de decisiones necesaria, especifican las variables que son evaluadas, que acciones deben ser tomadas y el orden en la cual la toma de decisiones será efectuada.

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

REQUERIMIENTOS

El análisis y diseño orientados a objetos empieza (DOO) a destacar en los 80’s. La programación orientada a objetos (POO) es la implementación del DOO, y a su vez, el DOO es la abstracción del AOO. La programación estructurada parte del diseño Top-Down. En esta se presta atención al conjunto de acciones que manipulan el flujo de datos. El enfoque principal de la POO se centra en las estructuras de datos y las acciones a realizar sobre ellos.

3.2.1 CARACTERÍSTICAS ANÁLISIS ORIENTADO 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 mutilarte 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 en la calidad de la solución. Los ingenieros del software se han visto forzados a trabajar con especificaciones incompletas, inconsistentes o engañosas han experimentado la frustración y condición que variablemente provocan. La calidad la fecha de entrega y el alcance del software son las que sufren las consecuencias.

 

Principios de las especificaciones

La especificación independiente del modo como la relacionemos, puede verse como un proceso de representación. Los requisitos se presentan de manera que como fin último lleven el éxito de la implementación del software.

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 de software. Cada caso de uso proporciona uno o varios 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 un usuario sin experiencia junto a los analistas para el desarrollo de casos de usos. En otras palabas un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un acto sobre el propio sistema. Los diagramas de caso 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 de requisitos del producto.

Un modelo CRC es realmente una colección de tarjetas índice está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 izquierda y a la derecha los colaboradores.

3.2.2.3 DEFINICIÓN DE ATRIBUTOS

Atributo es un carácter 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 ser 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 sino interesa al final de la base no es necesario almacenar en un atributo

3.2.2.4 DEFINICIÓN DE SERVICIOS

El servicio es llevado acabo por una organización o personal encargado de atender una necesidad pública o privada. La definición de servicio 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 identificar las metas globales, se analizan las respectivas del cliente, sus necesidades y requerimientos , sobre la planificación temporal y presupuestal, líneas de mercado y otros puntos que pueden ayudar a la identificación y desarrollo del proyecto; así como la identificación de los servicios que va a presentar el sistema a cada usuario participante.

3.2.3 PROTOTIPOS RÁPIDOS EN 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 iniciales 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.

3.3 TÉCNICAS BASADAS EN COMPONENTES

Un componente es un grupo de objetos o componentes más pequeños que interaccionan entre ellos y se combinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios del componente se especifican por su interface o interfaces, sin ofrecer conocimiento del diseño e implementación internas del componente. El desarrollo basado en componentes es el proceso de ensamblar la combinación correcta de componentes en la configuración correcta para llevar acabo la funcionalidad deseada para un sistema. Los componentes se representan en el diagrama de clases de UML especificando la interfaz de una clase o paquete. Hay dos notaciones para mostrar una interfaz - una es mostrar la interfaz como una 'regular class symbol' con el estereotipo "interfaz", con una lista de operaciones soportadas por esta interfaz, detalladas en el “operation department” (departamento de operación). “ The alternate, shortcut notation” es mostrar la interfaz como un circulo pequeño junto con la clase con una línea sólida, con el nombre de la interfaz en el círculo

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 reutilizable que pueden ser usados en la construcción de una familia de aplicaciones relacionadas o subsistemas. La ingeniera se carga 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 aspecto de multiplanes aplicaciones que representan un negocio común o problema de dominio.

Una ingeniería de dominio deficiente puede resultar en malas absorciones 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 CLASIFICACIÓN COMPONENTES

REUTILIZABLES

Clasificación De Componentes:

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 (LCD) Orientado a Función Complejidad: En algunas ocasiones, son utilizadas matrices de

tamaño para evaluar la complejidad, pero es recomendable hacer uso de otro tipo de métricas.

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: mide la complejidad del componente por medio de la suma de clases, clases abstractas e interfaces, la complejidad de clases y métodos.

Reusabilidad: La reusabilidad de un componente se puede medir a partir de dos diferentes perspectivas, estas son: reutilizado y re – usado.

3.3.3 CARACTERIZACIÓN DE COMPONENTES

Identificable: Debe tener una identificación que permite acceder fácilmente 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 otros componentes que lo remplace y mejore.

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

Sus servicios no varían 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, adoptarlo, etc.

Es genérico: Sus servicios debe servir para varias aplicaciones. Reutilizados dinámicamente: puede ser cargado en tiempo de

ejecución en una aplicación Independiente de la plataforma: Hardware, Software, SO

3.4 OTRAS TÉCNICAS

La ingeniería de requisitos puede ser un proceso largo y arduo para él 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 prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleara 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.

3.4 OTRAS TÉCNICAS

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 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.