Bachiller: Richard Nuñez Cedula: 25.056.795 Asignatura: Sistemas II Seccion: A

1. República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Superior
Instituto Universitario Politécnico “Santiago Mariño”
Especialidad: Ing. de Sistemas
Asignatura: Sistemas II
Sección: SS
Profesora: Amalia Bachiller:
Nuñez, Richard. C.I: 25.056.795
Barcelona, Marzo de 2018
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE
REQUERIMIENTOS

2. INTRODUCCION
Las fases de captura y análisis de requisitos de usuario han recibido en general
poca atención por parte de las metodologías de desarrollo de software. La transición a las
fases de diseño, cuando se utilizan metodologías de orientación a objetos, así como la
trazabilidad de los requisitos a lo largo de éste proceso, son también aspectos poco
soportados por éstas.
La creación del software es un proceso intrínsecamente creativo y la Ingeniería
del Software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en
la consecución del objetivo creativo por medio de diversas técnicas que se han demostrado
adecuadas en base a la experiencia previa.

3. Principio del análisis
Los investigadores han identificado los problemas y sus causas y desarrollando
reglas y procedimientos para resolverlos. Cada método de análisis tiene una única notación
y punto de vista. Sin embargo, todos los métodos de análisis están relacionados por un
conjunto de principios fundamentales:
 El dominio de la información.
 El dominio funcional de un problema debe ser representado y comprendido.
 El problema debe subdividirse de forma que se descubran los detalles de una manera
progresiva (o jerárquica).
 Deben desarrollarse las representaciones lógicas y físicas del sistema.
Aplicando estos principios, el analista enfoca el problema sistemáticamente. Se
examina el dominio de la información de forma que pueda comprenderse su función mas
completamente. La partición se aplica para reducir la complejidad. La
visión lógica y física del software, es necesaria para acomodar las ligaduras lógicas
impuestas por los requerimientos de procesamiento, y las ligaduras físicas impuestas por
otros elementos del sistema.

4. Es un enfoque de la ingeniería de software que modela un sistema como un grupo
de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de
conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia
funcional.
En este método de análisis y diseño se crea un conjunto de modelos utilizando una
notación acordada como, por ejemplo, el lenguaje unificado de modelado (UML). El Análisis y
Diseño Orientado a Objetos aplica técnicas de modelado de objetos para analizar los
requerimientos para un contexto.
En lugar de examinar un problema mediante el modelo clásico de entrada-proceso-
salida (flujo de información) o mediante un modelo derivado exclusivamente de estructuras
jerárquicas de información, el AOO introduce varios conceptos nuevos. Estos conceptos nuevos
le parecen inusuales a mucha gente, pero son bastante naturales.
Análisis y Diseño Orientado a Objetos (ADOO)

5. Ventajas de la metodología orientada a objetos
 Reutilización: Las clases están diseñadas para que se reutilicen en muchos sistemas.
Para maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a
los otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la
reutilización masiva al construir el software.
 Estabilidad: Las clases diseñadas para una reutilización repetida se vuelven estables, de
la misma manera que los microprocesadores y otros chips se hacen estables.
 El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo
nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de
utilizar.
 Se construyen clases cada vez más complejas: Se construyen clases a partir de otras
clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes
de software complejos.

6. Metodología de análisis de requerimiento
Combinan procedimientos sistemáticos con una notación única para analizar los
dominios de información y funcional de un problema de software; suministra un conjunto de
heurísticas para subdividir el problema y define una forma de representación para las visiones
lógicas y físicas.
En esencia, los métodos de análisis de requerimientos del software, facilitan al
ingeniero de software aplicar principios de análisis fundamentales, dentro del contexto de un
método bien definido. La mayoría de los métodos de análisis de requerimientos son conducidos
por la información.
Método de análisis orientado al flujo de datos
La información se transforma como un flujo a través de un sistema basado en
computadora. El cual acepta entrada de distintas formas; aplica un hardware, Software y
elementos humanos para transformar la entrada en salida; y produce una salida en distintas
formas. Un modelo de flujo de datos puede aplicarse a cualquier sistema basado en
computadora independientemente del tamaño o complejidad.

7. El sistema acepta entrada de distintas formas; aplica un hardware, software y
elementos humanos para transformar la entrada en salida; y produce una salida en distintas
formas.
La entrada puede ser una señal de control transmitida por un transductor, una serie
de números escritos por un operador humano, un paquete de
información transmitido por un enlace a red, o un voluminoso archivo de datos almacenado en
memoria secundaria. La transformación puede comprender una sencilla comparación lógica, un
complejo algoritmo numérico, o un método de inferencia basado en regla de un sistema
experto.

8. Desarrollo del sistema estructurado de datos
MODELO ESTATICO (ESTRUCTURADO) - MODELO DE OBJETOS
A diferencia del enfoque estructurado, en el orientado a objetos debemos
centrarnos en caracterizar los objetos reales del mundo tal y como ellos son, concibiéndolos
de manera natural, con sus características o propiedades y sus operaciones o métodos; y no
en la división de estos en estructuras abstractas que particionan todas las características de
esos objetos, además de separar de su caracterización las operaciones que incidían sobre los
mismos.
Pero hay dos cuestiones básicas que hacen que el enfoque orientado a objetos sea
más útil en los momentos actuales:
 La reutilización de componentes de software ya creados con anterioridad (objetos que
pueden ser usados en diferentes aplicaciones y que se almacenan en bibliotecas de clase).
 La facilidad de mantenimiento por ser el Software orientado a objetos de una estructura
descompuesta.

9. El desarrollo de sistema de Jackson (DSJ) se obtuvo a partir del trabajo de M.A. Jackson
sobre el análisis del dominio de la información y sus relaciones con el diseño de programas y
sistemas. Para construir un DSJ el analista aplica los siguientes pasos:
1. Paso de las acciones y entidades: Usando un método muy similar a la técnica de análisis
orientada al objeto, en este paso se identifican las entidades (persona, objetos u organizaciones
que necesita un sistema para producir o usar información) y acciones (los sucesos que ocurren en
el mudo real que afectan a las entidades).
2. Paso de estructuración de las entidades: Las acciones que afectan a cada entidad son ordenadas
en el tiempo y representadas mediante diagramas de Jackson (una notación similar a un árbol).
3. Paso de modelación inicial: Las entidades y acciones se representan como un modelo del
proceso; se definen las conexiones entre el modelo y el mundo real.
4. Paso de las funciones: Se especifican las funciones que corresponden alas acciones definidas.
5. Paso de temporización del sistema: Se establecen y especifican las características de
planificación del proceso.
6. Paso de implementación: Se especifica el hardware y software como un diseño.
Los últimos tres pasos del DSJ están muy relacionados con el diseño de sistemas.

10. Metodología de Programación – Orientada a Objeto
Un método es una subrutina asociada exclusivamente a una clase (llamados métodos
de clase o métodos estáticos) o a un objeto (llamados métodos de instancia). Análogamente a los
procedimientos en los lenguajes imperativos, un método consiste generalmente de una serie de
sentencias para llevar a cabo una acción, un juego de parámetros de entrada que regularán dicha
acción y, posiblemente, un valor de salida (o valor de retorno) de algún tipo.
La diferencia entre un procedimiento (generalmente llamado función si devuelve un
valor) y un método es que éste último, al estar asociado con un objeto o clase en particular, puede
acceder y modificar los datos privados del objeto correspondiente de forma tal que sea
consistente con el comportamiento deseado para el mismo. Así, es recomendable entender a un
método no como una secuencia de instrucciones sino como la forma en que el objeto es útil (el
método para hacer su trabajo).

11. Tipos de Métodos
Los métodos de instancia están relacionados con un objeto en particular,
mientras que los métodos estáticos o de clase (también denominados métodos
compartidos) están asociados a una clase en particular.
En una implementación típica, a los métodos de instancia se les pasa una
referencia oculta al objeto al que pertenecen, comúnmente
denominada this o self (referencias a sí mismo por sus significados en inglés), para que
puedan acceder a los datos asociados con el mismo.
Un ejemplo típico de un método de clase sería uno que mantuviera la cuenta de
la cantidad de objetos creados dentro de esa clase.
Los llamados métodos obtener y métodos establecer (en inglés get y set)
proveen un mecanismo para leer y modificar (respectivamente) los datos privados que se
encuentran almacenados en un objeto o clase.

12. El análisis estructurado, como todos los demás métodos de análisis de requisitos, es
una actividad de construcción de modelos. Mediante una notación que es única de este método,
se crean modelos que reflejan el flujo y el contenido de la información (datos y control); se parte
el sistema funcionalmente y, según los distintos comportamientos, se establece la esencia de lo
que se debe construir. La tarea del análisis de sistemas, conlleva más que sólo realizar análisis
de requisitos, pero es en eso donde se focalizará la discusión.
Una de las principales labores del analista es descubrir detalles y documentar la
política de un negocio que pudiera existir sólo en forma implícita, "transmitidas de generación en
generación" por los usuarios, nunca documentadas formalmente. El analista debe distinguir
entre síntomas, problemas del usuario y causas. Con sus conocimientos de la tecnología de los
computadores, el analista debe ayudar al usuario a explorar aplicaciones novedosas y más
útiles de éstos así como nuevas formas de hacer negocios.
Aunque muchos de los sistemas antiguos sólo se limitaban a perpetuar el negocio
original del usuario, pero a velocidades electrónicas, hoy en día los analistas se enfrentan al
desafío de ayudar al usuario a encontrar productos y mercados radicalmente innovadores, con
la ayuda del computador.
Análisis de Lenguaje Orientado a Objeto

13. La evolución de los estudios encarados por la Ingeniería de Requerimientos se fue
dando paulatinamente. Sin embargo, a partir de los 90, los esfuerzos se concentraron en la
búsqueda de técnicas, métodos y herramientas que pudieran ser aplicados durante el proceso
de definición de requerimientos para arribar a una etapa de diseño exitosa, dejando de lado la
obtención de una metodología capaz de adaptarse a cualquier tipo de sistema y paradigma,
brindando un marco de trabajo referencial, independiente del método a aplicar.
Es muy importante mencionar que el poder formular una especificación de
requerimientos completa y consistente, es un paso muy importante para evitar cometer errores
en la definición de los requerimientos, ya que los mismos pueden resultar muy caros de corregir
una vez desarrollado el sistema. De ahí, la vital importancia que tiene la ingeniería de
requerimientos en generar una adecuada especificación que contemple claramente y sin
ambigüedades los requerimientos del sistema a desarrollar, con el fin primordial de evitar que
los proyectos fracasen debido a una mala elaboración de la definición y especificación de
requerimientos
CONCLUSION

14.  Marcelo Vendan. 11 de Agosto de 2005. Recuperado de:
http://www.wikilearning.com/curso_gratis/guia_del_desarrollo_de_software-
metodos_de_analisis_orientados_al_flujo_de_datos/3471-15
 Gonzalez J. (2011). Fundamentos del analisis de requerimientos. Recuperado de:
http://humgbgh.blogspot.com/2011/05/fundamentos-del-analisis-de.html
 Análisis y diseño orientado a objetos.16 de octubre de 2010. Recuperado de:
http://es.wikipedia.org/w/index.php?title=M%C3%A9todo_(inform
%C3%A1tica)&oldid=44861792.