Objetivo 2: Especificación de Requerimiento.

Especificaciones de Requerimiento

    Textual, Notación Gráfica y Lenguajes de Representación. (Lenguaje Unificado de Modelado UML, Notación de Requerimiento de Usuario URN).

v  Textual

Textual Tradicionalmente la especificación de requisitos se ha        realizado usando sobre todo especificaciones textuales en lenguaje natural. Las herramientas de apoyo a la gestión de requisitos se han enfocado a la manipulación de trozos de texto. Estos requisitos expresados textualmente se enlazan formando un grafo de trazabilidad el cual se usa para gestionar los requisitos y su trazabilidad. En este enfoque, las especificaciones generadas en las otras actividades del desarrollo de software pueden también ser añadidas al grafo de trazabilidad representándolas como texto.

v  Notación Grafica y Lenguajes de Representación (Lenguaje Unificado de Modelado UML, Notación de Requerimiento de Usuario URN).

Notación gráfica, Incluye todas las notaciones que pueden demostrar el flujo de información entre requisitos, apoyándose en diversas imágenes. Estas notaciones permiten al usuario del sistema tener mayor comprensión del software lo que hace y como lo hace. La más utilizada actualmente es el Lenguaje Unificado de modelado (UML).

v UML: Es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. UML, emergió en los '90 luego de la búsqueda de un lenguaje de modelamiento que unificara a la industria. A pesar de que UML evolucionó de varios métodos orientados al objeto de segunda generación (en nivel de notación), su alcance extiende su uso más allá de sus predecesores. Es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación. Como un lenguaje para modelamiento, se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo). Cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos Los tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.

UML, es en cuanto a cómo se aplica para especificar sistemas, puede ser usado para comunicar "qué" se requiere de un sistema y "cómo" un sistema puede ser realizado. En cuanto a cómo se aplica para visualizar sistemas, puede ser usado para describir visualmente un sistema antes de ser realizado. En cuanto a cómo se aplica para construir sistemas, puede ser usado para guiar la realización de un sistema similar a los "planos”. En cuanto a cómo se aplica para documentar sistemas, puede ser usado para capturar conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida.

UML, no es Un lenguaje de programación visual, sino un lenguaje de modelamiento visual Una herramienta o depósito de especificación, sino un lenguaje para modelamiento de especificación. Un proceso, sino que habilita procesos.

Otra notación que se puede usar es la notación de requerimientos de usuario (URN).

    Técnicas para Escribir Requerimientos de Alta Calidad, Estándares de Documentación.

v  Técnicas para Escribir Requerimientos de Alta Calidad y Estandares de Documentación:

Los Requerimientos deben ser:

ü  Completos. Todo lo que el software tiene que hacer está recogido en el conjunto de Requerimientos, es decir, deben describir toda la funcionalidad que el sistema deberá Implementar.    

ü No ambiguos. Cada requerimiento debe tener una sola interpretación.

ü  Debiendo poder Expresarse de una manera sencilla, clara y sin ambigüedades usando:

·         Lenguaje natural (español).

·         Lenguajes gráficos (UML)

·         Lenguajes formales (Notación Z).

    Tipos de Requerimientos: Funcionales, No-Funcionales, Del Dominio, Atributos de Calidad.

Tipos de requerimientos El proceso de requerimientos maneja diferentes tipos de requerimientos, estos se pueden clasificar en:

ü  Requerimientos de hardware: Requerimientos de rendimiento. Requerimientos de interfaz. Requerimientos especiales de la ingeniería. Requerimientos de ambiente.

ü  Requerimientos de software: Requerimientos funcionales. Requerimientos no funcionales. Requerimientos del Dominio. Requerimientos de atributos de calidad.

v     Requerimientos Funcionales: Son los requerimientos del usuario, se ocupan para asignar los requerimientos de más alto nivel.

El documento con estos requerimientos se llama Especificación Funcional, el que debe ser preciso. Es lo más parecido al contrato entre cliente y desarrollador. Corresponde a una descripción abstracta del diseño de software. Es la base para un diseño e implementación detallada. Agrega el detalle a la especificación de requerimientos.

v     Requerimientos No-Funcionales: No funcionales Son prescindibles, condicionan lo que se tiene que hacer pero no son indispensables, indican mediante restricciones globales, de dominio y tecnología como debe construirse o funcionar. Su fuente principal es tanto el usuario como el cliente. También se especifican en las SRS. Definido como característica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala una restricción del mismo.

ü  Tipos de requerimientos no funcionales: Requerimientos no funcionales Requerimientos del producto Requerimientos organizacionales Requerimientos externos Requerimientos de interoperabilidad Requerimientos éticos Requerimientos de eficiencia Requerimientos de fiabilidad Requerimientos de portabilidad Requerimientos legislativos Requerimientos de usabilidad Requerimientos de entrega Requerimientos de implementación Requerimientos de estándares Requerimientos de desempeño Requerimientos de seguridad Requerimientos de privacidad Requerimientos de espacio.

v     Requisitos funcionales Vs. Requisitos no funcionales: Me identifica, que eventos reconocer, que datos mantener y que transformaciones hacer. No funcionales: Me identifica las restricciones de los productos, De la organización y externos.

v     Requerimientos Del dominio: Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales. Se derivan del dominio del sistema más que de las necesidades específicas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.

ü  Atributos de Calidad: Atributos de Calidad expresan las limitaciones que se le imponen al desarrollo del sistema y escriben aspectos tales como:

·      Expresan las propiedades de calidad que el sistema debe satisfacer.

·         El rendimiento que la aplicación debe tener.

·         La confiabilidad que debe poseer.

·         La seguridad que debe proveer.

·         La utilidad que debe garantizar.

Objetivo 3: Análisis de Requerimiento.

Análisis de Requerimiento

Análisis y Requerimientos: Todo sistema ha de tener un periodo de definición, en el cual se han de planificar todas las etapas del mismo, tanto de creación como de corrección. Para llevarlo a cabo tenemos diferentes oportunidades, La elección será más óptima si analizamos bien los requerimientos y propiedades que se desean para el sistema. 

Análisis de Requerimientos: El análisis de requerimientos es la primera etapa de un proyecto software, en ella se tratan de definir las condiciones o capacidades necesarias para uno o varios usuarios con el fin de solucionar un problema o conseguir un objetivo.

Para la creación global del  sistema se necesita comprender todos los objetivos y necesidades del usuario. En primer lugar,  hemos de especificar el comportamiento externo del sistema desde el punto de vista del usuario. Una vez acabado, podemos pensar en la arquitectura general del sistema, en términos de componentes físicos: hardware, software, usuarios y la comunicación entre ellos. 

La determinación de los requerimientos se haya en base a la experiencia, de hablar con los usuarios finales sobre sus necesidades y analizando un sistema software existente.

Podemos modelizar los requerimientos de usuario mediante lenguajes como UML, que disponen de modelos llamados casos de uso pensados para describir las funcionalidades necesarias para los usuarios. 

Hay diferentes tipos de requerimientos: de entorno (sistema operativo, sistema gestor de base de datos, sistema de archivos, ...), ergonómicos (interfaz gráfica, etc..), funcionales(QUE debe hacer el sistema), de rendimiento, de tiempo, formato de entrega, etc...

    Inspección, Validación, Completitud, Detección de Conflictos e Inconsistencias de Requerimientos.

v  Inspección: La inspección también es conocida como revisión técnica formal, y es el punto de vista más efectivo desde el punto de vista de aseguramiento de calidad, y es dirigida por los ingenieros de software u otras personas. Para los ingenieros la inspección es un medio efectivo para descubrir errores y mejorar la calidad del software. Las inspecciones de software surgen a partir de la necesidad de producir software de alta calidad.

v  Validación: La Validación es el conjunto de actividades que aseguran que el software construido corresponde con los requisitos del cliente. En el proceso de obtención de los requisitos de un sistema de software, la validación constituye una de las tareas más complejas, ya que en muchos casos, se requiere que los clientes-usuarios posean conocimientos y habilidades especí­ficas para poder comprender los modelos resultantes de la Ilicitación y especificación de los requisitos.

v  Completitud: Completitud Significa que no hay omisiones que comprometan la integridad de los requisitos. No faltan requisitos (propiedad global), No faltan detalles en la especificación de cada requisito (propiedad individual), Es una propiedad difí­cil de determinar (tan sólo podemos alcanzar una aproximación),Contrastar con el cliente o Comparar con proyectos semejantes, Buscar la visión de conjunto, detectar huecos o partes infra-especificadas.

v  Detección de Conflictos e Inconsistencias de Requerimientos: Detección de Conflictos e Inconsistencia de Requerimientos. Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en sub-conjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios. Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que su versión es esencial por necesidades especiales.

    Documentos de Requerimientos de Software: Creación, Uso e Importancia.

v  Documentos de Requerimientos, Creación e Importancia: El documento de requerimientos del software (algunas veces denominado especificación de requerimientos del software o SRS) es la declaración oficial de que deben implementar los desarrolladores del sistema. Debe incluir 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 pueden integrar en una única descripción. En otros, los requerimientos del usuario se definen en una introducción a la especificación de los requerimientos del sistema. Si existe un gran número de requerimientos, los detalles de los requerimientos del sistema se pueden presentar en un documento separado. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos de la organización que pagan por el sistema, hasta los ingenieros responsables de desarrollar el software. La diversidad de posibles usuarios significa que el documento de requerimientos tiene que presentar un equilibrio entre la comunicación de los requerimientos a los clientes, la definición de los requerimientos en el detalle exacto para los desarrolladores y probadores, y la inclusión de información sobre la posible evolución del sistema.

    Métricas y Herramientas para la Ingeniería de Requisitos.

v Métricas Utilizadas En La Ingeniería de requisitos: Comienzo del Proyecto de Software. Antes de empezar a planificar un proyecto el desarrollador y el cliente deben ponerse de acuerdo para definir el ámbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin considerar como se llegara a ellos. El ámbito identifica las funciones primordiales del Software y más importante aún, intenta limitar esas funciones de manera cuantitativa.

v Medición y Métricas: Las mediciones y las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. Frecuentemente en la medición surgen las siguientes interrogantes:

A.- ¿Cuáles son las métricas apropiadas para el proceso y para el producto?

B.- ¿Cómo se deben utilizar los datos que se recopilan?

C.- ¿Es bueno usar medidas para comparar gente, procesos o productos? entre otras.

D.- Estimación. La Planificación es una de las actividades del proceso de Gestión de Proyectos de Software. Cuando se planifica un proyecto de Software se tiene que obtener estimaciones, del esfuerzo humano requerido (personas-mes), de la duración cronológica del proyecto (en fechas) y del costo (dólares). Las muchas técnicas del desarrollo del software tienen en común lo siguiente: Se ha de establecer de antemano el ámbito del proyecto como base para la realización de estimaciones se usan las Métricas del software (mediciones del pasado). El proyecto se desglosa en partes más pequeñas que se estiman individualmente. 

E.- Análisis de Riesgos. El análisis de riesgo es algo vital para una buena gestión del proyecto de software y sin embargo, a pesar de todo, se emprenden muchos proyectos sin que se hayan considerado los riesgos concretos.