FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
1. República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Superior
I.U.P.” Santiago Mariño”.
Sede Barcelona.
Bachiller:
Luisa Valentina Hurtado.
C.I: 23.997.291
Profesora:
Amelia Vásquez
Barcelona, 28 de Marzo de 2018.
FUNDAMENTOS Y MÉTODOS DE
ANÁLISIS DE REQUERIMIENTOS
2. Introducción
En la ingeniería de software, un Análisis de Requerimientos es una tarea que cubre
el hueco entre la definición del software a nivel sistema y el diseño del mismo.
Tanto el desarrollador como el cliente tienen un papel activo, pues juntos definen
en detalle los requisitos del sistema a desarrollar y los pasos a seguir. Conoce la
importancia que éste tiene durante el proceso de diseño y desarrollo de software y
aplicaciones móviles.
Es un principio de sistemas que para definir y modelar un sistema que sirve a otro,
primero tenemos que definir y modelar el sistema a servir. Generalmente el
sistema a servir es de nivel mayor o incluye al de nivel menor. Por lo que se puede
inferir, que para conocer los requerimientos del sistema menor debemos primero
conocer los requerimientos del sistema mayor a servir. Es decir, que para definir los
requerimientos de software, en el campo de las tecnologías de información,
primero debemos definir los requerimientos de los niveles mayores en el siguiente
orden: nivel organización, proceso de negocio (sistema de trabajo) y sistema de
información; para evitar convertir un problema real en un problema virtual.
3. Análisis
Es un estudio profundo de un sujeto, objeto o
situación con el fin de conocer sus
fundamentos, sus bases y motivos de su
surgimiento, creación o causas originarias.
4. Análisis orientado a
Objetos.
La finalidad del análisis orientado a objetos de una aplicación es
establecer su modelo de objetos, que captura la estructura estática
del sistema a través de identificar los objetos claves que se utilizan
el sistema, formular las relaciones entre los objetos, y caracterizar
cada clase de objetos a través de la asignación de los atributos que
describen sus características y estado y las operaciones que
describen su funcionamiento externo.
5. Análisis de
Requerimientos.
En la Ingeniería de requisitos, el análisis de los requerimientos del
software es la etapa que sigue después que estos han sido
levantados y documentados en un registro o matriz de trazabilidad.
La especificación de requerimientos, es una actividad que cada vez
toma mayor preponderancia en la gerencia de proyectos, dado que
se ha demostrado que una causa recurrente en su fracaso se
origina de una inadecuada especificación de requisitos.
Las técnicas de análisis de requerimientos expuestas a continuación
parten de la especificación de requisitos o matriz de trazabilidad de
requerimientos del proyecto.
6. 1.- Descomposición
funcional
La descomposición funcional se refiere al proceso de identificar y resolver las
relaciones funcionales en sus partes constituyentes, de tal forma que la función global
pueda ser reconstruida a partir de sus partes.
Por lo general, la descomposición funcional se realiza para identificar y entender los
componentes o partes que constituyen un todo (o función global).
En este proceso, es vital identificar las interacciones entre componentes.
Aplicado a la Ingeniería de requisitos, consiste en tomar los requerimientos de
software, dividirlos en partes y analizarlos individualmente. De ser necesario, se
pueden descomponer en más partes hasta lograr un nivel adecuado de detalle.
En cierto sentido, el proceso es similar al de la elaboración de una estructura de
desglose de trabajo de un proyecto.
En Ingeniería de sistemas, la descomposición funcional consiste en definir un sistema
en términos funcionales, para luego definir funciones de más bajo nivel y establecer
las relaciones con estas funciones de alto nivel.
7. 2.- Especificación vía
Sentencias Textuales
Es la forma tradicional de la especificación de requerimientos de software.
Se usan especificaciones textuales en lenguaje natural, que se documentan en
matrices de trazabilidad de requerimientos o definiciones del alcance.
El procedimiento consiste en tomar el requerimiento producto del levantamiento
de información, para desarrollar una narrativa más detallada.
No usa herramientas visuales como los flujogramas o estructura como los casos de
uso, es simplemente una descripción más detallada del requerimiento en lenguaje
natural.
8. 3.- Modelado del
proceso.
Comprende la elaboración de diagramas de
flujo de procesos (Flujogramas) a partir de
los requerimientos del software.
Existen diversas herramientas de modelado
de procesos, cada una de las cuales posee
sus propios símbolos y reglas.
Es muy útil para entender el trabajo
realizado en múltiples pasos, tareas, roles y
departamentos intervinientes.
Los procesos son iniciados por eventos y
pueden abarcar actividades automatizadas,
manuales o combinación entre ambas.
Su naturaleza visual ayuda a la
comprensión y comunicación a terceros.
Cuando los procesos son complejos, deben
desglosarse en componentes
(subprocesos).
La relación entre los diagramas de flujo y la
gerencia de proyectos es fundamental para
el éxito.
9. 4.- Modelo de
dominio.
En Ingeniería de software, en análisis de dominio
consiste en analizar sistemas o software
relacionados en un dominio, con la finalidad de
encontrar sus partes comunes y partes que los
diferencian.
Produce un modelo de contexto de negocio para
todo el sistema.
Un modelo de dominio comprende diagramas
conceptuales que incluyen tanto el
comportamiento de un sistema como sus datos.
Un tipo de modelo de dominio son los diagramas
de funcionalidades (Features Diagrams), que es
una representación “compacta” del sistema o
aplicación en términos de sus características.
El análisis de dominio produce modelos
orientados a objetos o modelos relacionales de
datos, que pueden ser usados por los
desarrolladores de software como base de
arquitecturas de software y aplicaciones.
10. 5.- Casos de Uso.
En el Lenguaje de Modelado Unificado (UML), un
caso de uso es una secuencia de interacciones
entre un sistema y alguien o algo que usa alguno
de sus servicios.
11. 6.- Checklists.
La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones
que se realizan sobre los requerimientos de software, que nos sean
presentados de forma escrita.
Una lista de chequeo puede realizar preguntas como:
1. ¿Se han especificado los requisitos de hardware y software?
2. ¿Se han realizado consideraciones de seguridad?
3. ¿El nivel de granularidad del requerimiento se ha incluido?
4. ¿Se ha incluido el código de referencia en para identificar el requisito
en el desglose de requerimientos?
5. ¿Está escrito el requerimiento en un lenguaje claro y conciso?
6. ¿El requerimiento es único? (no existe duplicidad con otro
requerimiento).
7. Y muchas preguntas más.
.
12. 7.- Inspección.
Revisión no destructiva de los requerimientos de software. Por ejemplo:
• Examinar un software visualmente para constatar que las pantallas
solicitadas se encuentran incluidas.
• Verificar la inclusión de los campos necesarios para el ingreso de datos.
• Verificar la existencia de los botones necesarios para iniciar la funcionalidad
que ha sido requerida.
• Verificar que el requerimiento se apega a los estándares definidos para la
aplicación. Por ejemplo estándares de navegación entre pantallas y
estándares de interfaz gráfica.
De forma similar al uso de la lista de chequeo, la inspección consiste en tomar
el requerimiento definido en la matriz de trazabilidad o definición de alcance,
leerlo y producir un resultado para su corrección.
.
13. 8.- Prototipos.
Consiste en elaborar representaciones visuales (interfaz gráfica con el
usuario) de los requerimientos de software.
Permite a desarrolladores y usuarios entender mejor los requerimientos,
determinar cuáles son indispensables y cuales deseables, e identificar
riesgos de forma temprana.
Puede enfocarse en toda la solución o sólo en áreas específicas.
Puede extenderse innecesariamente en el tiempo si las discusiones se
realizan en torno al como en lugar de en torno al que.
La elaboración de prototipos conlleva iteraciones entre desarrolladores y
usuarios, en los cuales se van elaborando varios prototipos y sometidos a
evaluación del cliente.
14. Análisis Orientados al Flujo de Datos
La información se transforma como un flujo a través de un sistema basado en
computadora. El sistema acepta entrada de distintas formas; aplica un
hardware, software y elementos humanos para transformarla 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. La salida puede encender un sencillo led o producir un
informe de 200 paginas.
15. Métodos Orientados a la Estructura de
Datos
Aunque cada método orientado a la estructura de datos tiene un
enfoque y notación distinta, todos tienen algunas características en común:
1) Todos asisten al analista en la identificación de los objetos de información
clave (también llamados entidades o ítems) y operaciones (también llamadas
acciones o procesos).
2) Todos suponen que la estructura de la información es jerárquica.
3)todos requiere que la estructura de datos se represente usando la
secuencia, selección y repetición.
4) Todos dan una conjunto de pasos para transformar una estructura de datos
jerárquica en una estructura de programa.
Como los métodos orientados al flujo de datos, los métodos de análisis
orientados a la estructura de datos proporcionan la base para el diseño de
software. Siempre puede extenderse un método de análisis para que abarque
el diseño arquitectural y procedimental del software.
16. Desarrollo de Sistemas de Jackson
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.
En palabras de Jackson: “El que desarrolla el software comienza
creando un modelo de la realidad a la que
se refiere el sistema, la realidad que proporciona su
materia objeto [del sistema]...”
17. Desarrollo de Sistemas de Jackson
Para construir un DSJ el analista aplica los siguientes pasos:
• 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).
• 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).
• 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.
18. Desarrollo de Sistemas de Jackson
Para construir un DSJ el analista aplica los siguientes pasos:
• Paso de las funciones. Se especifican las funciones que
corresponden alas acciones definidas.
• Paso de temporización del sistema. Se establecen y especifican las
características de planificación del proceso.
• 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.
19. Programación orientada a objetos.
La programación orientada a objetos (POO, u OOP según sus siglas en inglés)
es un paradigma de programación que viene a innovar la forma de obtener
resultados. Los objetos manipulan los datos de entrada para la obtención de
datos de salida específicos, donde cada objeto ofrece una funcionalidad
especial.
Muchos de los objetos pre-diseñados de los lenguajes de programación
actuales permiten la agrupación en bibliotecas o librerías, sin embargo,
muchos de estos lenguajes permiten al usuario la creación de sus propias
bibliotecas.
Está basada en varias técnicas, incluyendo herencia, cohesión, abstracción,
polimorfismo, acoplamiento y encapsulamiento.
Su uso se popularizó a principios de la década de 1990. En la actualidad,
existe una gran variedad de lenguajes de programación que soportan la
orientación a objetos.
21. Análisis y diseño orientada a objetos.
El análisis y diseño orientado a objetos (ADOO) 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 domino absoluto en términos
de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a
su dependencia funcional.
Todo sistema de información requiere de artefactos o componentes
(clases) para llevar a cabo tareas, es de gran importancia dentro de la
ingeniería de software tener un buen "análisis y diseño" para un mejor
desarrollo, que conlleva a que tan "escalable" sea un sistema de
información.
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).
22. Tareas comunes que se realizan en la
programación orientada a objetos
Definición de clases.
Crear propiedades, métodos y descriptores de acceso get y set (métodos
descriptores de acceso)
Controlar el acceso a clases, propiedades, métodos y descriptores de
acceso.
Crear propiedades y métodos estáticos.
Crear estructuras de tipo enumeración.
Definir y utilizar interfaces.
Trabajo con herencia, incluida la sustitución de elementos de clase.
23. Bases de la Programación Orientada a
Objetos
Existen cuatro conceptos fundamentales dentro de la Programación Orientada a Objetos
que se relacionan entre sí y que nos permitirán tener las riendas de nuestro código:
Abstracción: proceso mental de extracción de las características esenciales de algo,
ignorando los detalles superfluos.
Encapsulación: proceso por el que se ocultan los detalles del soporte de las
características esenciales de una abstracción.
Modularización: proceso de descomposición de un sistema en un conjunto de
módulos o piezas independientes y cohesivos (con significado propio). Lo
adecuado es conseguir los mínimos acoplamientos.
Jerarquización: proceso de estructuración por el que se produce una organización
(jerarquía) de un conjunto de elementos en grados o niveles de responsabilidad,
incumbencia o composición entre otros.
24. Conclusión
La programación hoy en día se ha dividido en 2 partes, una es la programación en base
a código simple (esta puede ser en cualquier lenguaje de programación) en donde solo
se usan líneas de programación para que el software manipule diversos datos y
posteriormente el usuario manipula el software con más lineas de programación para
que se entreguen nuevos resultados.
La segunda es la programación orientada a objetos, esta es la más común actualmente,
se basa en la manipulación de datos, objetos, patrones y cualquier elemento
programable dentro de un software, su fin básicamente es que la programación que se
asigne pueda interactuar con uno o varios objetos determinados y de esta manera
poder tener un entorno interactivo que obedezca las ordenes de un usuario con un
simple clic y sin tener que escribir más lineas dentro del código base. La programación
orientada a objetos permite agrupar partes específicas de la información dada a un
grupo de objetos, por ejemplo se puede realizar un programa en el cual se asigne un
botón para que se ingrese una imagen, dicho botón debe servir para abrir un directorio
y obtener la imagen, tras este botón hay varias lineas de código que esperan el
momento en que se obtenga la imagen para proceder con la siguiente acción o
instrucción.