Análisis de requisitos del software

El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

Inspeccion de Requerimientos

La ingeniería de requerimientos es una fase fundamental y la mas importante en      el ciclo de vida del desarrollo de software. Esta fase tan importante o el proceso mas importante en el desarrollo, cuenta con 3 procesos claves; Elicitacion, Especificación y Validación. La validación si bien puede verse como una etapa final de los requerimientos, también se la puede considerar como un procesos que interviene en todo momento, ya sea cuando se elecita o cuando especifican requerimientos. Para validar Requerimientos de sistemas de software, debemos corroborar que los requerimientos cumplen con lo que el usuario/cliente - stakeholder - necesitaba o "requería" del sistema. Verificar requerimientos no es sinónimo de validar, antes de validar debemos verificar, es decir verificar para luego validar, para verificar podemos utilizar técnicas de inspección de requerimientos. Un concepto, comprensible para quienes no tomaron un curso de requerimientos, Inspeccionar es "inspeccionar" o cerciorarnos o medir o asegurarnos de que estamos realizando bien el trabajo de "Elicitacion" - "Especificación" - "Validación" de requerimientos del software.

Validación de requerimientos

El resultado del trabajo realizado es una consecuencia de la ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su calidad en la fase de validación. La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.

Completitud de Requisitos

La herramienta implementa un método para mejorar la completitud de los requisitos utilizando un enfoque lingüístico, basado en los casos semánticos asociados al sentido de un verbo. Se presenta también el proceso seguido en la evaluación de la efectividad de la herramienta al analizar la completitud de varios casos de estudio utilizando la precisión como indicador cuantitativo de la efectividad. Los resultados preliminares obtenidos confirman las hipótesis y muestran que la herramienta servirá de ayuda en la escritura de especificaciones de requisitos completas y el mejoramiento de la calidad del software que se desarrolla a partir de ellas.

Detección de conflictos

La detección de conflictos es una herramienta analítica que automatiza el proceso de detección de conflictos. ProjectWise Schedule Simulation permite identificar grupos de elementos comerciales o gráficos y detectar conflictos geométricos entres este grupo de elementos objeto. Después puede revisar interactiva y gráficamente estos conflictos. Las reglas de supresión se pueden aplicar para identificar conflictos que no deben ser informados. Los ajustes asociados con los conflictos de ejecución se administran y siguen como un trabajo de conflicto. Un trabajo es un contenedor de criterios, de reglas y resultados, que se configuran y guardan en el archivo activo para su reutilización. Un trabajo se pueden almacenar en una biblioteca DGN. Un trabajo se puede definir y procesar en archivo sólo de lectura, pero la definición y los resultados del trabajo no pueden ser almacenados.

Documento de requerimientos del software

Éste es la declaración oficial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una única descripción. En otros, los del usuario se definen en una introducción de la especificación de los del sistema. Si existe un gran número de requerimientos, los detalles de los requerimientos del sistema se pueden presentar como documentos separados. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los administradores principales de la organización, quienes pagan por el sistema, hasta los ingenieros responsables del software.

Las Métricas

 En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad. El principio, podría parecer que la necesidad de la medición e s algo evidente. Después de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión. La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas. Hay varias razones para medir un producto.

1. Para indicar la calidad del producto.

2. Para evaluar la productividad de la gente que desarrolla el producto.

3. Par evaluar los beneficios en términos de productividad y de calidad, derivados del uso de nuevos métodos y herramientas de la ingeniería de software.

4. Para establecer una línea de base para la estimación

5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.

Métricas del softwareSon las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia:

Métricas tecnicas: Se centran en lasa características de software pro ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.

Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

Métricas de productividad: Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.

Métricas orientadas a la persona: Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.

Métricas orientadas al tamaño: Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos.

Métricas orientadas a la función: Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función.

1 - Inicio del Plan: Determina el arranque formal del plan de sistemas, con el apoyo del nivel más alto de la organización.

2 - Definición y Organización: Detalla y concreta la descripción del PSI asignando un calendario y recursos humanos al mismo

3 - Estudio información relevante: Se analiza información de interés para el correcto desarrollo del plan de sistemas

4 - Identificación Requisitos: Obtiene la especificación de requisitos que deben tener los sistemas de información analizados por el plan de sistemas.

5 - Estudio S.I. Actuales: Obtiene una valoración de la situación actual.

6 - Diseño modelo: Identifica y define los S.I. Que van a dar soporte a los procesos afectados por el Plan de Sistemas de Información

7 - Arquitectura tecnológica: Se propone la arquitectura tecnológica que dé soporte al modelo de información y sistemas de información.

8 - Definición plan: Se elabora y detalla el plan de sistemas de información: definición de proyectos, actividades, calendario y recursos para implementar los sistemas de información e infraestructura tecnológica

9 - Revisión y aprobación: Se somete el plan a la revisión última y aprobación de la dirección.

10 – documentación: Catálogo de requisitos