Clase 2 - Análisis y Especificación de Requerimientos de Software Flashcards
¿Cuál es la diferencia entre la etapa análisis y la etapa de especificación?
Análisis del problema
Objetivo: lograr una buena comprensión de las necesidades, requerimientos y restricciones del **software**** interactuando con el cliente, intentando **asegurar completitud y consistencia, evitando el diseño interno.
<aside>
💡 En esta etapa, el analista puede cumplir un **********************rol pasivo********************** recolectando y organizando la información o un **********************rol activo********************** ayudando al cliente a darse cuenta de aquellas cosas que necesita, actuando como consultor.
</aside>
El ******principio básico****** dentro del análisis es usar la estrategia de dividir y conquistar, donde dividiremos el problema en sub-problemas entendiendo cada uno de estos y estableciendo las relaciones entre ellos.
Las relaciones conformadas en el análisis del problema pueden establecerse respecto a 3 enfoques distintos
- Funciones (Análisis estructural).
- Objetos (Análisis orientado a objetos).
- Eventos del sistema (Particionado de eventos).
Es importante entender que los métodos de análisis y las estructuras que se construyen en esta etapa son similares a las de diseño, pero tienen objetivos y alcances distintos. Dado a que el análisis trata el dominio del problema y el diseño el dominio de la solución.
Especificación de requerimientos
****Objetivo:****** producir una SRS.
Durante la etapa de especificación de requerimientos se utiliza los conocimientos adquiridos durante la etapa de análisis para producir un documento de especificación de los requisitos del software (SRS).
¿A que le llamamos requerimientos?
Según la IEEE, tenemos dos definiciones válidas:
- Son una condición o capacidad necesaria de un usuario, para resolver un problema o alcanzar objetivos.
- Son una condición o capacidad que debe poseer un sistema para satisfacer un contrato, especificación u otro documento formalmente impuesto.
¿En qué consiste la metodología de análisis estructurado? (que hace, para que sirve y sus pasos)
Método de análisis estructurado
Enfoque: el sistema es visto como una **************red de transformadores de datos************** sobre la cual fluye información. Para identificar estos transformadores se usa **********descomposición funcional**********, dividiendo el sistema en funciones a las cuales luego se le analiza sus entradas y salidas.
Es un una forma de hacer un modelado de flujo de datos sumamente utilizado para automatizar sistemas manuales ya existentes en tres pasos principales:
- Dibujar el diagrama de contexto del sistema actual: conforma una vista de alto nivel del sistema entero, donde todo el sistema es tratado como un proceso simple y todos las entradas, salidas, fuentes **y sumideros de datos son identificados y mostrados.
- Dibujar el DFD del sistema existente para comprender el funcionamiento del sistema actual.
- Será un refinamiento del diagrama de contexto.
- Transformadores que no transformen datos son eliminados.
- Involucra mucha interacción con el usuario con el fin completar el DFD.
- Dibujar el DFD del sistema propuesto e identificar la frontera hombre-máquina.
- El DFD debe modelar el sistema propuesto de forma completa, involucrando procesos automáticos y manuales.
- Debe ser validado por el usuario.
- La frontera hombre-máquina se debe establecer para ver que cosas se pueden automatizar y que cosas no.
- Ejemplo (método de análisis estructurado)
¿En qué consiste el modelado orientado a objetos?
Modelo orientado a objetos
Enfoque: el sistema es visto como un conjunto de objetos que interactúan entre ellos o con el usuario, mediante los servicios que cada **objeto provee.
Los objetivos del modelado orientado a objetos **son identificar las objetos que están presentes en el dominio del problema, definir las clases y atributos en base a que información de estado encapsula cada objeto y identificar las relaciones **que existen entre los objetos de las distintas clases.
Este tiene algunas ventajas, pues se cree que la transición de modelado orientado a objetos al diseño y implementación usando programación orientada a objetos, es sencilla, y los sistemas orientados a objetos son más fáciles de construir y mantener. Además como los objetos son más estables que las funciones, el análisis orientado a objetos es más inmune a los cambios.
****Conceptos básicos******
- Un sistema consta de un conjunto de objetos.
- Los objetos constan de atributos, los cuales son valores de datos puros (como integer, string,…), por lo que no pueden ser otro objeto.
- Los objetos con tipos similares, se agrupan en clases.
- Las clases definen el espacio de estados de los objetos y el tipo, junto con sus operaciones.
- Un objeto provee servicios o realiza operaciones.
- Los servicios son la única manera de que algo externo pueda cambiar o ver el estado de un objeto.
- El servicio es solicitado a través de mensajes.
- Esos servicios son definidos en las clases y se proveen por los objetos de esas clases.
- Los atributos son los que mantienen y definen el estado de un objeto.
Realizar el análisis
Si bien no hay un “algoritmo” para realizar el análisis, existen algunas pautas:
- Identificar objetos y clases: se hace un breve resumen del problema y se identifica los sustantivos presentes. Luego, se arma una lista de candidatos y se elimina de ella aquellos “posibles objetos” que no brinden ningún servicio o en los que el sistema no necesite guardar información en ellos.
-
Identificar estructuras: las estructuras representan jerarquía entre clases, por lo que se debe considerar las clases previamente identificadas y ver si alguna generaliza o especializa a otra; o si alguna clase “es parte de” otra.
- Para identificar la estructura de generalización-especialización ver si existen clases que pueden ser una generalización o especialización de otras (prestar especial atención a los atributos). Por ejemplo, si el problema es encender un televisor, sin hacer enfoque en que tipo de televisor es, no vale la pena generar dos clases distintas para televisores LED y SMART TV.
- Para identificar la estructura de agregación debemos ver si un objeto es parte de otro.
💡 Las especializaciones deben ser **significativas** para el dominio del problema.
</aside> -
Identificar atributos: los atributos representan características que definen los objetos, para identificarlos considere cada clase y vea que atributos son necesarios para el dominio del problema. Luego, estos atributos deben ser correctamente colocados en la jerarquía de clases.<aside>
💡 Tener especial cuidado con objetos que solo tienen **un** **atributo**.
</aside> - Identificar asociaciones: las asociaciones capturan las relaciones entre objetos. y se derivan directamente del dominio del problema una vez que los objetos son identificados.
- Definir servicios: un objeto provee una serie de servicios cuando recibe un mensaje. Primero, debemos identificar aquellos servicios usados para crear, destruir, y mantener las instancias de una clase (estos no se colocan en el diagrama). Para el resto, se debe definir los estados del sistema y después en cada estado, listar los eventos externos y las respuestas requeridas, luego estas actividades serán asociadas con las clases.
- Ejemplo de un diagrama de clases
¿Qué es el prototipado?
Prototipado
Se desarrolla un ******sistema parcial******, el cual es utilizado por el cliente, los usuarios y desarrolladores para comprender mejor el problema y entender los requisitos que el sistema debe proveer. La ******razón principal****** para usar prototipado es que al cliente se le hace más difícil visualizar como el eventual software funcionará leyendo un documento de especificación, con el prototipado, podemos mostrarle al cliente el funcionamiento del sistema dentro de su entorno, permitiendo evaluar sus necesidades de mejor manera.
<aside>
💡 El prototipado se centra en que la practica, en la **experiencia real**.
</aside>
Enfoques para el prototipado
Existen dos enfoques para realizar el prototipado
- Descartable: el prototipo se construye con la idea de desecharlo luego de culminada la fase de requerimientos.
- Evolucionario: se construye el prototipo con la idea de que este evolucionará hasta convertirse en el sistema final.
<aside>
💡 El enfoque descartable se considerara más adecuado.
</aside>
¿Cuándo debemos crear un prototipo?
Ahora, veremos cuando debemos crear un prototipo, para eso debemos entender que los requisitos se pueden dividir en tres conjuntos
- Requisitos bien entendidos.
- Requisitos pobremente entendidos.
- Requisitos desconocidos.
Debemos usar prototipado descartable, cuando deseemos transformar a los requisitos pobremente entendidos en bien entendidos, usando la experiencia con el prototipo.
A su vez, es posible dividir el conjunto de los pobremente entendidos en dos conjuntos más: los críticos para el diseño y los no críticos, donde no crítico significa que se puede incorporar de manera sencilla más adelante. Si se puede determinar cuales son críticos y cuales no, entonces el prototipado descartable se centrará en aquellos que lo son. Entonces, podemos afirmar que si el conjunto de requisitos pobremente entendidos es de un tamaño importante conviene usar prototipado (aunque también suele implementarse cuando se desea comprobar la utilidad del sistema en el entorno del cliente).
Sin embargo para que la creación de prototipos para el análisis de requisitos sea factible, su costo debe mantenerse bajo. En consecuencia, solo se incluyen en el prototipo aquellas características que tendrán un retorno valioso de la experiencia del usuario y se reducen la cantidad de pruebas realizadas al prototipo.
<aside>
💡 El enfoque básico durante la creación de prototipos es mantener los costos bajos y minimizar el tiempo de producción del prototipo.
</aside>
********************************Proceso de desarrollo de un prototipado descartable********************************
El proceso de desarrollo del prototipo comienza con la producción de una SRS para el prototipo donde se detallará que funciones incluirá. Dependiendo del tipo de funciones que se agreguen el prototipo puede considerarse como
-
Horizontal: el sistema es visto como un conjunto de capas y se hace foco en alguna de esas capas en el prototipo.
- Frecuentemente se hace foco en la capa de **user interface**.
-
Vertical: se centra en una parte del sistema que no se comprende bien y se la desarrolla de forma completa.
- Útil para validar alguna funcionalidad o capacidad.
- Ejemplo de herramientas de prototipado
¿Cuales son las características de una SRS?
Características de una SRS
La SRS producida debe ser de buena calidad, y para que esto sea así dicha SRS debe poseer ciertas características. Entonces, una buena SRS debe ser:
- Correcta: es decir, cada requerimiento dentro de la SRS representa precisamente alguna característica deseada por el cliente en el sistema final.
- Completa: es decir, todas las características deseadas por el cliente están descritas en la SRS.
-
No ambigua: cada requerimiento tiene exactamente un significado.<aside>
⚠️ El problema está en que si usamos lenguaje natural, debemos ser muy cuidadosos para no ser ambiguos, la solución podría ser usar algún lenguaje formal, pero esto incrementa la dificultad de escritura y de lectura.
</aside> - Consistente: ningún requerimiento contradice al otro.
- Verificable: que cada requerimiento se puede verificar, es decir, existe un proceso efectivo que verifica que el software final satisface el requerimiento.
-
Rastreable: se debe poder determinar el origen de cada requerimiento y como este se relaciona con los elementos del software.
- Hacia delante: dado un requisito, tengo que poder mostrar en que elemento de diseño o de código tiene impacto.
- Hacia atrás: dado un elemento del código debo poder rastrear que requerimiento está atendiendo.
-
Modificable, es decir, la estructura y estilo de la SRS es tal que permite incorporar cambios de manera fácil, preservando completitud y consistencia.<aside>
⚠️ La redundancia es un gran estorbo para esta característica.
</aside> -
Ordenada en aspectos de importancia y estabilidad. Los requerimientos pueden ser:
- Críticos.
- Importantes pero no críticos.
- Deseables pero no importantes.
¿Qué es la especificación funcional por casos de uso?
Especificación funcional con casos de uso
Como ya mencionamos antes, los requerimientos funcionales a menudo forman parte del corazón de la SRS. Los casos de uso son un enfoque tradicional, donde se debe especificar cada función provista por el sistema.
En los casos de uso se captura el comportamiento del sistema como interacción de los usuarios con el sistema y se enfoca solamente en la especificación de la funcionalidad. Es decir, un caso de uso captura un contrato entre el usuario y el comportamiento del sistema. A continuación, veremos algunos temas relacionados a esta forma de especificación funcional.
-
Conceptos básicos
- Un actor es una entidad lógica (una persona o un sistema) que usa el sistema para lograr algún objetivo.
- Un actor receptor no es lo mismo que un actor transmisor, inclusive si estos son el mismo individuo.
- Un actor primario es el actor principal que inicia el caso de uso para lograr un objetivo.
- El caso de uso debe satisfacer su objetivo.
- La ejecución real puede ser realizada por otro sistema u otra persona en representación del actor primario.
- Un escenario es un conjunto de acciones llevadas a cabo para lograr un objetivo bajo determinadas condiciones.
- El conjunto de acciones es especificado como una secuencia.
- Un paso es una acción lógica realizada por un actor para lograr una meta o un cambio de estado interno de un actor para satisfacer una meta.
- Es una interacción entre el usuario y el sistema.
- Un escenario exitoso principal es el conjunto de acciones donde todo funciona correctamente y se alcanza el objetivo.
- Los escenarios de extensión son aquellos que describen el comportamiento del sistema si alguno de los pasos del escenario exitoso principal falla (no deben ser exhaustivos).
- Un caso de uso es una colección de todos los escenarios (exitosos y de extensión) relacionados a un objetivo.
- Los casos de uso especifican funcionalidades describiendo la interacción entre actores y sistema enfocándose en el comportamiento externo.
- Un actor es una entidad lógica (una persona o un sistema) que usa el sistema para lograr algún objetivo.
-
Formato que usaremos para los casos de uso
- Los casos de uso se enumeran para hacer referencia a ellos luego.
- El nombre del caso de uso especifica el objetivo del actor primario.
- La precondición describe lo que el sistema debe asegurar antes de iniciar el caso de uso.
- La lista de acciones puede contener acciones que no son necesarias para el objetivo del actor primario. Pero, el sistema debe asegurar que el objetivo final, así como los otros objetivos puedan cumplirse.
- El campo ámbito especifica el subsistema al cual se aplica el caso de uso.
- Ejemplo
-
Elaboración de los casos de uso### Elaboración de los casos de usoLos casos de uso no solo especifican requerimientos, sino que además puede ser un buen medio para la discusión y la lluvia de ideas. Los casos de uso, pueden ir evolucionando paso a paso, añadiendo más y más nivel de detalle creando diferentes niveles de abstracción.Cuatro niveles de abstracción surgen de forma natural con este enfoque
-
Actores y objetivos
- Preparar una lista de actores y sus objetivos.
- El nombre de los actores suele ser generalmente la meta que quieren conseguir.
- Proveer un breve resumen del caso de uso, dando una vista general de que se trata el caso.
- Esto define el ámbito del caso de uso.
- Nos provee un visión general sobre las capacidades del sistema.
- Se puede evaluar la completitud.
- Preparar una lista de actores y sus objetivos.
-
Escenarios exitosos principales
- Se expande cada caso de uso con los escenarios exitosos principales.
- Esto provee el comportamiento principal del sistema.
- Puede revisarse para asegurar que se satisface el interés de los interesados y actores.
-
Condiciones de falla
- Se enlista del escenario principal de éxito para cada caso de uso los pasos, y por cada paso se identifica si puede fallar, o no. Luego, en caso de los pasos que pueden fallar se debe identificar cómo y por qué falla.
- Se descubre las situaciones especiales.
-
Manipulación de fallas
- Especificar como debe comportarse el sistema para cada falla antes listada.
- Surgirán nuevas situaciones y nuevos actores.
-
Actores y objetivos
<aside>
⚠️ Los casos de uso pueden ser utilizados durante el análisis también.
</aside>
¿Qué son las métricas y para que se usan?
Métrica
El mayor problema después de terminar los requerimientos es estimar el esfuerzo y el cronograma del proyecto. Sin embargo, algunas métricas que pueden ser extraídas de los requerimientos pueden ser útiles para esto. El propósito básico de tener ****métricas **es proveer información cuantitativa al proceso de gestión del proyecto, para que esta pueda ser utilizada para controlar efectivamente el proceso de desarrollo, controlando el costo, cronograma o la calidad de un proyecto.
El primer factor que determina el costo de un proyecto de software, **es el tamaño. Sin embargo, desde los requerimientos del proyecto no podemos obtener un valor exacto del tamaño que tendrá el sistema, sólo podemos obtener una estimación del mismo.
<aside>
⚠️ Podríamos pensar que un buen estimador es el tamaño de la SRS, pero este **depende** mucho del autor.
</aside>
¿Qué es el punto función y cómo se calcula?
Punto función
El punto función es una de las estimaciones más usadas para estimar el tamaño del software a partir de su SRS. La idea **detrás de esta medida **es que lo que realiza el sistema, es una forma de estimar el tamaño del sistema.
Los puntos de función se han utilizado ampliamente como una medida para estimación del tamaño de un sistema y la estimación de costos. También se han realizado estudios para establecer la correlación entre el punto de función y el tamaño final del software (medido en líneas de código), en donde, podemos nombrar que 1 punto de función equivale a 125 líneas en C y 50 líneas en C++ o Java aproximadamente.
<aside>
💡 Esta medida es más estable que el tamaño de la SRS pues la funcionalidad es **independiente** de **como estén especificados** los requisitos.
</aside>
Calculo del punto función
La funcionalidad del sistema es calculada en términos de cinco tipos de funciones diferentes que a su vez de dividen en simples, promedio y compleja para tener en cuenta la complejidad como se detalla a continuación:
- Entradas externas.
- Es un tipo de entrada (datos/control) externa a la aplicación.
- Una entrada se considera simple si tiene algunos elementos de datos y afecta solo a algunos archivos internos de la aplicación.
- Una entrada se considera compleja si tiene muchos elementos de datos y se necesitan muchos archivos lógicos internos para procesarlos.
- Una entrada se considera promedio si está entre las dos anteriores. **
- Salidas externas.
- Salidas que dejan al sistema.
- Una salida se considera simple si tiene algunas columnas.
- Una salida se considera promedio si tiene varias columnas.
- Una salida se considera compleja si tiene una estructura compleja de datos y hace referencia a muchos archivos.
- Archivos lógicos internos.
- Cada grupo lógico de datos generado, usado y mantenido por una aplicación los cuales mantienen información interna para desarrollar una funcionalidad.
- Un archivo lógico interno es simple si contiene algunos tipos de registro.
- Un archivo lógico es complejo si tiene muchos tipos de registros.
- Un archivo lógico es promedio si está entre ambos.
- Archivos de interfaz externa.
- Archivos compartidos o pasados entre aplicaciones.
- La complejidad se define igual que para los tipos de archivos interno lógico.
- Transacciones externas.
- Los sistemas pueden tener consultas (queries), que consisten en entradas y salidas, donde cada par cuenta como una transacción externa.
- Para la la complejidad de las query se clasifican las entradas y las salidas como archivos entradas externas y salidas externas, la complejidad de la transacción es la mayor de las dos.
En base a esto, se cuentan la cantidad de funcionalidades presentes de cada tipo que existen en el sistema y luego que los números son conocidos, el punto de función bruto o no ajustado (UFP) se calcula con la siguiente fórmula
$$
\text{UFP}=\sum_{i=1}^{5}\sum_{j=1}^{3}w_{ij}C_{ij}
$$
<aside>
💡 $i$ representa la fila y $j$ la columna de la tabla que mostramos a continuación. Entonces, $w_{ij}$ (el **peso**) es la entrada de la $i$-ésima fila y la $j$-ésima columna de la tabla presentada; luego $C_{ij}$ es la cantidad de elementos encontrados de ese tipo $i$ y complejidad $j$.
</aside>
Tabla de los pesos.
Una vez obtenido el UFP, este se debe ajustar a la complejidad del entorno. Para esto, se dan 14 características diferentes del sistema, para ver como estas influencian dentro del entorno, estas son
- Comunicación de datos.
- Proceso distribuido.
- Objetivos de desempeño.
- Carga en la configuración de operación.
- Tasa de transacción.
- Ingreso de datos online.
- Eficiencia del usuario final.
- Actualización online.
- Complejidad del procesamiento lógico.
- Reusabilidad.
- Facilidad para la instalación.
- Facilidad para la operación.
- Múltiples sitios.
- Intención de facilitar cambios.
El grado de influencia de cada uno de estos factores se toma desde 0 hasta 5, representando los 6 siguientes niveles. (0). no presente, (1) influencia insignificante, (2) influencia moderada, (3) influencia promedio, (4) influencia significante, (5) influencia fuerte. Luego, los 14 grados de influencia del sistema son sumados, dándonos un total de $N$, y ese valor es usado para calcular factor de ajuste de complejidad, usando
$$
\text{CAF}=0.65+0.01\times N=0.65+0.01\times \sum_{i=1}^{14}p_i
$$
<aside>
💡 Donde $p_i$ es el grado de influencia del sistema en la característica $i$ e $\text{CAF}\in [0.65,1.35]$
</aside>
Luego, ese valor es usado para obtener el punto de función con la formula
$$
\text{Punto función}=\text{CAF}\times \text{UFP}
$$
<aside>
💡 La **mayor** **desventaja** es que el proceso de cálculo de los puntos de función implica una evaluación subjetiva en varios puntos y el punto de función final calculado para un SRS dado puede no ser único y puede depender del analista.
</aside>
