Este documento describe varias técnicas estructuradas y orientadas a objetos para el análisis de requerimientos en el desarrollo de sistemas de información. Explica herramientas como diagramas de flujo de datos, diccionarios de datos, casos de uso, modelado de clases, atributos y servicios. También cubre técnicas basadas en componentes como ingeniería de dominio e identificación y clasificación de componentes reutilizables.

1. Sistemas de información
Instituto de Estudios Superiores Vygotsky
Licenciatura: tecnologías y sistemas de información
Materia: sistemas de información
Prof. Ing. Lucio Cesar Rafael Román
Alumno : Alberto Cruz Meneses
6to cuatrimestres junio-2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. 3.3.2 IDENTIFICACIÓN CLASIFICACIÓN
COMPONENTES REUTILIZABLES
• 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.
• Cómo es re - usado un componente en una aplicación particular.

24. 3.3.2 IDENTIFICACIÓN CLASIFICACIÓN
COMPONENTES REUTILIZABLES
• Frecuencia de reúso
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.
• Frecuencia de reúso
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.

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

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

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

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

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