Análisis de requerimientos (parte 2)

TÉCNICAS DE DETERMINACIÓN DE REQUERIMIENTOS

- Conversaciones, entrevistas, reuniones con el cliente. Podemos encontrarnos con los varios problemas:

• con la existencia de diferencias entre los usuarios, obtenemos puntos de vista muy diversos. La idea es la realización de todas las entrevistas posibles para poder contemplar todos esos puntos y analizar mejor.
• los usuarios no suelen tener experiencia o conocimiento del sistema.
• hacernos una idea del sistema, definiendo solo esta técnica, es complicado. Tendremos que utilizar técnicas alternativas para conseguir más información.

FASES ENTREVISTAS

1. Preparación. Determinamos las preguntas que van a hacerse (obtendremos un estudio sobre el dominio del problema), seleccionamos a un subconjunto de personas para obtener el mayor número de información posible, determinamos el objetivo y contenido de la misma y las planificamos.
   
2. Realización. Consta de 3 partes. En la apertura se deja claro al usuario cuál es el objetivo de la entrevista y se aclaran conceptos o notación específica que se vaya a utilizar durante la misma. En el desarrollo, máximo de 2 horas, hemos de mantener el control y dejar que el usuario se explique; hay que evitar monólogos por parte de los entrevistadores. Al final se debe hacer una recapitulación de la información dada por el usuario.
3. Análisis de las entrevistas, extraemos la información recogida por la mi

- Obtener requerimientos a partir de un Sistema de Información (sinónimo de sistema informático) desarrollado. Podemos utilizar esta técnica como complemento de la anterior ya que puede darnos mucha información más útil (en algunos casos que los usuarios no colaboran con datos concretos). Eso si, su problemática radica en sistemas complejos y en sistemas que nunca han existido.

- Obtener los requerimientos a partir del Sistema de Información mismo. Es necesario que los analistas conozcan lo que existe ya en la empresa donde vamos a poner el nuevo sistema. El problema de esta técnica es que tiene un coste elevado ya que se añade a esta fase un análisis de todo lo que ya hay y eso necesita tiempo y más personal que lo haga.

- Construcción de un prototipo. Definimos un prototipo con las características generales del sistema y vamos conociendo los requerimientos en función de las versiones. Es una técnica muy costosa.

- Casos de uso. Se identifican los requerimientos funcionales y no funcionales y se relacionan entre ellos. Nos preguntamos cuales son las funciones del sistema por cada actor (persona relacionada con el sistema).


¿QUÉ SE HACE EN EL ANÁLISIS DE REQUERIMIENTOS?

1. Comprensión del problema mediante la comprensión (valga la redundancia) del software dentro del contexto y la evaluación y síntesis del propio problema (definición de flujos, estructura y contenido de la información, funciones y entendimiento del comportamiento)
2. Modelización del sistema
3. Especificación del sistema mediante una representación formal y comprovación de que lo que ha recogido el analista es lo que realmente necesita el cliente.

Problemática
- Uno de los primeros conflictos con los que nos encontramos es en el momento de decidir que personas podrán darnos la información que necesitamos para plantear las necesidades del cliente. Nos encontramos con que un alto porcentaje de la gente que preguntamos no nos la da realmente.
- Es probable que para una misma función nos encontremos con diferente información de diferentes personas, por lo que se convierte en información inconsistente.
- Podemos encontrar problemas en el momento de integrar nuestro nuevo sistema por culpa del funcionamiento y rendimiento de otros elementos del sistema. Por ejemplo, puedo encontrarme con errores en el momento que decido conectarme a otro software para obtener datos.
- La percepción de los objetivos puede cambiar con el paso del tiempo.
- A medida que crece el tamaño del problema, crece la complejidad del análisis.
- El cliente no suele valorar la etapa de análisis.

Métodos de modelado
Cada método de análisis tiene una notación y un punto de vista propio, pero siempre se tiene que cumplir 3 reglas:

1. Partición. un sistema complejo solo puede entenderse si se divide en partes más pequeñas que se relacionan entre ellas; esto nos permite ver el problema en pequeñas partes y luego, de su relación, llegar a tener una visión general de él.
2. Abstracción. nos debe permitir ver el sistema en términos generales, sin tener en cuenta cómo generamos entradas y salidas del sistema.
3. Proyección. permite definir el problema teniendo en cuenta los diferentes puntos de vista.

Especificación de requerimientos
Es el resultado del análisis. Se trata de un documento que sirve de contrato entre el desarrollador y el cliente, y de base de trabajo para el diseñador.

- Explica qué hace el sistema, y no el cómo lo hace.
- Debe ser un documento comprensible para cualquier persona. Se precisa la explicación de los tecnicismos en el caso de que los haya.
- Los conceptos a explicar deben estar claros.
- La información debe estar completa, debe recoger todos los requerimientos y a su vez, estos deben de ser verificados por el cliente.
- No debe haber requisitos contradictorios.
- Debe ser un documento fácilmente modificable.
- Debe tener un índice.
- Deber poder ser usable durante el diseño y la implementación, y el mantenimiento del sistema.

- Un estándar de este documentos es el de ANSI/IEEE.

- Posteriormente el documento debe ser revisado y validado en dos niveles: macroscópico (especificación completa, consistente y precisa) y detallado (precisar temas concretos).

Análisis de requerimientos (parte 1)

Aprovechando que estoy estudiando teórico y soy una negada para retener las cosas como si fuera un loro, he querido redactar un poco sobre análisis de requerimientos para la asignatura de Ingenieria del Software. Creo que es la única manera de aprenderme conceptos tan teóricos.

El post tendrá dos partes: la primera es la que se muestra a continuación, introduciendo unos cuantos conceptos básicos y explicando en que consiste el análisis del sistema y que cosas hay que tener en cuenta; la segunda la subiré más tarde, o mañana, y englobará las técnicas de determinación de requerimientos, su posterior análisis y cómo han de especificarse.

Para empezar, vamos a definir unos cuantos conceptos...

Un sistema informático es un conjunto de elementos organizados para realizar algún método, procedimiento o control mediante el procesamiento de información. Dentro de un sistema informático no sólo encontramos software o hardware, sino que también diferentes roles de personas, bases de datos, documentos o procedimientos.

Un requisito, propiamente dicho, es la condición o capacidad necesitada por el usuario para poder llegar a solucionar un problema (o cumplir unos objetivos). En otras palabras, es lo que tiene que llegar a hacer el sistema.

La solución a un problema, puede resolverse de 4 maneras: manualmente, mediante software, mediante hardware o mediante la combinación de las tres.
Dicha solución puede ser simple (mediante un software simple) o compuesta (mediante un sistema más complejo, automatizando todas las acciones). En el caso del sistema compuesto es necesario diseñar el sistema global antes de diseñar el software que se integre.

La ingeniería de sistemas informáticos es la actividad que se encarga de resolver estos problemas. Para ello, es necesario que el cliente que nos pide la integración participe en el desarrollo (en general) del producto aportando los objetivos y restricciones que debe tener el sistema. El ingeniero es quién desarrolla la solución; en un primer momento será él el que analice el sistema delimitando el ámbito de funcionamiento, el rendimiento y las funciones. Con esta información tendrá que determinar una serie de soluciones entre las que escogerá la mejor teniendo en cuenta, entre otras cosas, la existencia de un producto en el mercado que resuelva sus necesidades (“es el caso de la necesidad de tener una hoja de cálculo, no la desarrollaremos porque ya existe”), el coste que podría suponer, el tipo de tecnología o las necesidades reales a cubrir.

ETAPAS DEL ANÁLISIS DEL SISTEMA

1. Identificar las necesidades del cliente. Podremos determinar los objetivos a conseguir. Si se trata de un producto con el que se espere mucho impacto entre los usuarios, se deberá hacer un estudio de mercado.
2. Estudiar la viabilidad del sistema. Esto incluye la económica (analizar impacto del coste-beneficio), la técnica (ver si se puede realizar o no), la legal (determinar las infracciones o ilegalidades que pueda provocar el sistema) y las alternativas (estudiar las diferentes soluciones presentadas).
3. Hacer un análisis económico-técnico más profundo.
4. Determinar las funciones necesarias y asignarlas a elementos del sistema.
5. Crear un documento donde se especifique la definición del sistema. Este documento servirá como base para todo el desarrollo del sistema posterior.

Tanto si la solución es simple, como si es compuesta (sistema complejo) tendremos que realizar un análisis de los requerimientos del software. Una vez comprendamos el problema mediante el estudio del sistema hemos de plasmar esta comprensión es un documento. Esto es lo que se llama especificación de requerimientos. Los requerimientos que hemos de tener en cuenta pueden ser:

• Funcionales: describen las entradas y salidas del sistema, y las operaciones que se hacen entre ellas.
• No funcionales: definen las cualidades generales que ha de tener el sistema. En otras palabras, podemos definir estos requerimientos como los límites de las posibles soluciones. Estos pueden ser de rendimiento, de diseño (cumplimiento de estándares, requisitos hardware, control de errores, seguridad), de interfícies externas (todo lo relacionado con la interacción de las personas, con el hardware o con otro tipo de software), de calidad (que sea fácil de usar, de mantener, que sea ampliable...) o sobre decisiones de diseño (implementaciones de módulos).