Sistemas de informaciónInstituto de Estudios Superiores Vygotsky

Licenciatura: tecnologías y sistemas de informaciónMateria: sistemas de información

Prof. Ing. Lucio Cesar Rafael RománAlumno : Alberto Cruz Meneses6to cuatrimestres junio-2014

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

• Equipo de programación

• Revisiones estructurales

3.1.1 CARACTERÍSTICAS DEL ANÁLISIS ESTRUCTURADO

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

• Herramientas de documentación del análisis estructurado

• Diagrama de flujo (DFDs)

• Diccionarios de datos (DD)

• Diagramas de entidades-relación (ER)

• Diagramas de transición de estado (DTEs)

• Especificaciones de estado

3.1.2 ESPECIFICACIÓN FORMAL DE DATOS

• Son una de las cuatro herramientas del análisis estructurado. Es una herramienta gráfica que se emplea para describir y analizar el movimiento de los datos a través de un sistema, ya sea este manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Los DFD, como se les conoce popularmente son la herramienta más importante y la base sobre la cual se desarrollan otros componentes. La transformación de datos de entrada en salida por medio de procesos puede describirse en forma lógica e independiente de los componentes físicos (computadoras, gabinetes de archivos, y procesadores de texto) asociados con el sistema.

3.1.2.1 DIAGRAMA DE FLUJO Y CONTROL DE DATOS

• Un diagrama de flujo es una representación gráfica de un algoritmo o de una parte del mismo. Los diagramas de flujo ayudan en la comprensión de la operación de las estructuras de control (Si, Mientras).La ventaja de utilizar un algoritmo es que se lo puede construir independiente mente de un lenguaje de programación, pues al momento de llevarlo a código se lo puede hacer en cualquier lenguaje.Dichos diagramas se construyen utilizando ciertos símbolos de uso especial como son rectángulos, diamantes, óvalos, y pequeños círculos, estos símbolos están conectados entre sí por flechas, conocidas como líneas de flujo.

3.1.2.2 DICCIONARIO DE DATOS• Un diccionario de datos contiene las características lógicas de los datos

que se van a utilizar en un sistema, 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, evitando así malas interpretaciones o ambigüedades, su contenido también se emplea durante el diseño del proyecto.

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.

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.

3.1.3.1 LENGUAJE NATURAL• Es el lenguaje hablado o escrito por humanos para propósitos

generales de comunicación. Son aquellas lenguas que han sido generadas espontáneamente en un grupo de hablantes con propósito de comunicarse.

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.

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

3.2 TÉCNICAS ORIENTADAS A OBJETOS PARA 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 , sub partes y sub-sub part.

3.2.1 CARACTERÍSTICAS ANÁLISES 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 multi parte 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

• Las técnicas de especificación formal de sistemas concurrentes pueden agruparse en general en dos niveles; en el primero se incluyen las técnicas consistentes en el desarrollo de modelos formales del sistema y en el segundo las técnicas que realizan la especificación del sistema mediante la definición de propiedades abstractas del mismo.

3.2.2.1 CASOS DE USO

• Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

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 í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 a la izquierda y a la derecha los colaboradores.

3.2.2.3 DEFINICIÓN DE ATRIBUTOS

• Los atributos presentan las siguientes características:

· Valor de un dato dentro de un objeto.· Cada atributo tiene un valor para cada objeto.· El nombre de un atributo es único dentro de una clase.· Debería ser un dato ‘puro', no un objeto (no tiene identidad): si un objeto necesita otro objeto habrá que modelarlo como asociación.· Además del nombre podemos especificar el Tipo y el Valor por defecto.· Los identificadores de objetos explícitos no se necesitan en el Modelo de Objetos.

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.

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.

• 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 finalidad de la ingeniería del Dominio es identificar, construir, catalogar y diseminar un conjunto de componentes de software que sean aplicables para el software existente y futuro en un dominio de aplicación particular.

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 (LDC)

• Orientadas a Función

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

3.3.2 IDENTIFICACIÓN CLASIFICACIÓN COMPONENTES REUTILIZABLES

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

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

• Cómo puede un componente ser reutilizado.

• Cómo es re - usado un componente en una aplicación particular.

3.3.2 IDENTIFICACIÓN CLASIFICACIÓN COMPONENTES REUTILIZABLES

• Frecuencia de reúsoEl 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.

• Frecuencia de reúsoEl 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.

3.3.3 CARACTERIZACIÓN DE COMPONENTES

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

3.3.3 CARACTERIZACIÓN DE COMPONENTES

• 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• Técnicas principales

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.

3.4 OTRAS TÉCNICAS

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

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

3.4 OTRAS TÉCNICAS

• Herramientas para la recolección de datos.

• Herramientas para la diagramación.

• Herramientas para el diccionario.

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