2. Justificación del análisis
Las actividades de análisis garantizan el éxito del desarrollo.
Tanto el cliente como el desarrollador juegan un papel muy
activo, donde la buena comunicación entre ambos es un factor
esencial.
El análisis es un proceso de descubrimiento, refinamiento,
modelado y especificación, cuyo principal objetivo es obtener
modelos lógicos que definan el software que se desea construir.
4. Áreas de problemas
Las dificultades que se presentan están asociadas con la adquisición de la
información pertinente, el manejo de la complejidad del problema y la
gestión de los cambios que puedan producirse.
Las causas de estas dificultades son:
• la pobre comunicación,
• el uso de técnicas y herramientas inadecuadas,
Técnicas para los requerimientos de análisis de información
El muestreo y la investigación de datos
La entrevista
Uso de cuestionarios
Observaciones al comportamiento de la toma de decisiones y al ambiente de
oficina.
Prototipos. …………………………………… KENDALL & KENDALL
5. Áreas de problemas
• La tendencia a simplificar las actividades de análisis, y
el no considerar alternativas antes de especificar el
software.
6. Principios del análisis
Representar y entender el dominio de información del problema.
Definir las funciones que debe realizar el software.
Representar el comportamiento del software (en función de los
eventos externos)
Dividir los modelos que representen información, función y
comportamiento de manera que se descubran los detalles de manera
progresiva (o jerárquicamente) con el fin de reducir la complejidad.
Ir desde la información esencial hasta el detalle de la implementación
con el objeto de acomodar las restricciones lógicas impuestas por los
requisitos de procesamiento y las restricciones físicas impuestas por
otros elementos del sistema.
7. Principios del análisis
(cont.)
Estos principios son independientes del método de análisis elegido.
Además, se sugiere el siguiente conjunto de principios para la
ingeniería de requisitos: (Fundamentos del análisis de requisitos.
Roger S. Pressman cap 4,5,6,7 séptima edición)
• Entender el problema antes de empezar a crear el modelo de análisis.
• Desarrollar prototipos que permitan al usuario entender cómo será la
interacción hombre-máquina.
• Registrar el origen y la razón de cada requisito.
• Usar múltiples planteamientos de requisitos (modelos de datos,
funcionales y de comportamiento).
• Dar prioridad a los requisitos.
• Trabajar para eliminar la ambigüedad. (redundancia, inconsistencia,
duplicidad, integridad en bases de datos)
8. El dominio de la información
El software se construye para aceptar una entrada de información,
manipularla de alguna manera y producir una salida de información.
El software procesa datos (números, caracteres, imágenes, sonidos,
etc.) y acontecimientos (dato binario que representa algún aspecto de
control del sistema). (Diferencia entre datos e información)
Tanto los datos como el control residen dentro del dominio de la
información de un problema.
El dominio de la información contiene tres visiones diferentes de los
datos y del control:
• contenido de la información y relaciones,
• flujo de la información, y
• estructura de la información.
9. Modelado
Durante el análisis de requisitos del software, se crean modelos del sistema a
construir mediante notaciones gráficas y textuales que muestran el ámbito del
sistema (software).
El modelo se centra en qué debe hacer el software y no en cómo lo
tiene que hacer. Se refiere al Que? Del desarrollo de nuestros sistemas.
Ventajas que proporcionan los modelos
• Ayudan a entender el ámbito del sistema (información, función y
comportamiento) haciendo más fácil y sistemática las actividades del
análisis.
• Son la clave para determinar la integridad (completitud), consistencia
(coherencia) y eficacia de la especificación.
• Constituyen la base del diseño, al proporcionar una representación
esencial del software que se puede relacionar con un contexto de
implementación.
10. Modelado (cont.)
Modelos funcionales
• Representan de manera minuciosa toda la funcionalidad del sistema.
• Se empieza con un sencillo modelo a nivel de contexto y después de
una serie de iteraciones se consiguen más detalles funcionales.
Modelos de comportamiento
• Representan los estados del software y los acontecimientos que
causan que cambie de estado.
• El software responde a los acontecimientos del mundo exterior; esta
característica estímulo-respuesta forma la base del modelo de
comportamiento.
11. Partición
Consiste en descomponer un sistema (problema, modelo,...) en sus
partes constituyentes estableciendo las relaciones correspondientes
entre las partes.
A medida que se parte el sistema, se obtienen las interfaces entre las
funciones. Los datos y los elementos de control que se mueven a
través de una interfaz deberían restringirse a las entradas necesarias
para realizar la función en cuestión y a las salidas requeridas por otras
funciones o elementos del sistema.
La partición permite una mayor manejabilidad del sistema facilitando
su entendimiento y se puede aplicar al ámbito de información, al
ámbito del comportamiento y al ámbito de la función.
12. Visión esencial y de implementación
Una visión esencial (o lógica) de los requisitos del software presenta
las funciones y la información sin tener en cuenta los detalles de
implementación.
La visión esencial se obtiene en las primeras fases del análisis de
requisitos.
Una visión de implementación (o física) de los requisitos del software
introduce la manifestación en el mundo real de las funciones de
procesamiento y las estructuras de la información.
La visión de implementación se obtiene durante las fases posteriores
de la especificación de requisitos o en la primera fase del diseño de
software.
13. Visión esencial y de implementación (cont.)
Un modelo de implementación representa el modo de
operación, es decir la asignación existente o propuesta de
todos los elementos del sistema.
Un modelo de implementación no debería por tanto
interpretarse como una representación del cómo .
14. Especificación
Es un proceso de representación de los requisitos de forma que
conduzcan a una correcta implementación del software.
Principios de una buena especificación
• Separar funcionalidad (qué se desea realizar) de implementación
(cómo se va a realizar).
• Desarrollar un modelo del comportamiento deseado de un sistema que
comprenda datos y las respuestas funcionales de un sistema a varios
estímulos del entorno.
• Establecer el contexto en el que operará el software especificando la
interacción con otros componentes del sistema.
• Definir el entorno en que va a operar el sistema e indicar cómo
reacciona a estímulos del entorno.
• Crear un modelo que sea intuitivo.
15. Especificación (cont.)
Principios de una buena especificación (cont.)
• Reconocer que debe ser tolerante a la incompletitud y ampliable y, por
último, debe aceptar cambios. Sistemas flexibles.
Directrices para una buena representación
• El formato de la representación y el contenido deberían estar
relacionados con el problema.
• La información contenida dentro de la especificación debería estar
escalonada.
• La numeración de párrafos y diagramas debería indicar el nivel de
detalle que se muestra.
• Los diagramas y otras formas de representación deberían restringirse en
número y ser consistentes en su empleo.
• Las representaciones deben permitir revisiones.
16. Referencias bibliográficas
Pressman, R. Ingeniería del software: un enfoque
práctico. McGraw-Hill.
Kendall & Kendall. Análisi y diseño de Sistemas.
Prentice-Hall.
James Senn. Analisis y diseño de sistemas.
Yourdon, Edward. Analisis estructurado
moderno.
Prentice-Hall
