INGENIERÍA DE REQUISITOS

 

MINISTERIO DEL PODER POPULAR PARA LA EDUCACION

UNIVERSITARIA PROGRAMA NACIONAL DE FORMACION  I.U.T.Ll

Núcleo - Calabozo.
Unidad Curricular Ingeniería del Software
Sección 01
Prof. Neris Alfonzo

Autora: Nesnyd Beatriz Cadenas Rincón
V 11797941

INGENIERÍA DE REQUISITOS

-          Fases de la Ingeniería de Requisitos

-          Técnicas para el Levantamiento y Recolección de Requisitos (Joint Aplication Desing, JAD)

 

INGENIERÍA DE REQUISITOS

            La Ingeniería de Requisitos, es el proceso de desarrollar una especificación de Software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente con los desarrolladores del sistema. Trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.

Según Pressman (2005), “es un conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto de un modo sistemático” (p. 42). En definitiva, facilita los mecanismos adecuados para comprender las necesidades del cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. En definitiva, facilita los mecanismos adecuados para comprender las necesidades del cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional.

 

Fases de la Ingeniería de Requisitos

 

El proceso se cumple en cinco fases: 1.         Estudio de viabilidad: Este permitirá rendir un informe tanto al equipo de desarrollo del proyecto como al usuario o cliente, donde se verificará si el proyecto vale la pena desarrollarlo. Es de vital importancia para la satisfacción de los objetivos del negocio. 2.         Captura y Análisis: En esta fase el desarrollador o su equipo de desarrollo entran en contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema que se desea construir, además, se debe identificar cuáles son los servicios que prestará el sistema, su rendimiento, sus necesidades y restricciones, y cuáles son los objetivos esperados. 3.         Especificación: Aquí se debe obtener un documento de especificación de requisitos, en cual se llega a definir de una forma completa, precisa y verificable cada uno de los requerimientos o necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware). 4.         Validación: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos, definen el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa solamente entran aquellos requisitos que se mencionaron ya en la especificación. 5.         Gestión: Se realiza la comprensión y control de los cambios de cada una de los requisitos, sean estos requisitos estables (corresponden al estado del sistema) o volátiles (representan eventos que hacen que el sistema realice una función dada)   Modelado de Requisitos           El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.      Asimismo, el modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. Actualmente esta metodología es parte del Proceso Unificado de Rational(RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos: Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante. Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación. Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más. Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación. Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración. Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración.   Análisis de Requerimientos 1.         Es un estudio profundo de una necesidad tecnológica que tiene una empresa, organización o negocio. 2.         Especifica las características operacionales que tendrá el software a desarrollar. 3.         Se realiza a través de entrevistas, observación, indagación y demás técnicas específicas. 4.         Describe el plan del proyecto a seguir. 5.         Es fundamental entregar el proyecto dentro del tiempo y presupuesto acordados y de los objetivos de negocio. Proporciona un mapa para llegar con éxito al desarrollo del software o app. Si necesitas examinar una determinada situación o el área de oportunidad de tu empresa con el propósito de mejorar -con métodos y procedimientos- la comunicación, el manejo de información, disminuir costos, reducir procesos, etcétera; no dudes en contactarnos. Juntos podemos realizar un Análisis de Requerimientos para ofrecer la solución correcta al desarrollo de tu sistema web o aplicación móvil.   Ingeniería De Requisitos Gestión               La gestión de requisitos es un enfoque sistemático para encontrar, documentar, organizar y hacer el seguimiento de los requisitos cambiantes de un sistema. Definimos un requisito como: Una condición o capacidad que debe cumplir el sistema. La definición formal de gestión de requisitos es: propuesta sistemática para lo siguiente: •          Obtener, organizar y documentar los requisitos del sistema •          Establecer y mantener un acuerdo entre el cliente y el equipo del proyecto sobre el cambio de requisitos del sistema Las claves para la gestión eficaz de requisitos incluyen el mantenimiento de una sentencia clara de los requisitos, junto con atributos aplicables para cada tipo de requisito y rastreabilidad a otros requisitos y otros productos de trabajo del proyecto. Puede que la recopilación de requisitos suene como una tarea bastante sencilla. Sin embargo, en los proyectos reales, se encontrará con dificultades, porque: •          Los requisitos no siempre son obvios y pueden tener muchos orígenes. •          No siempre es fácil expresar los requisitos con claridad en palabras. •          Hay muchos tipos diferentes de requisitos con niveles diferentes de detalle. •          Si no se controla, el número de requisitos puede llegar a ser ingestionable. •          Los requisitos están relacionados entre sí y también con otros productos de trabajo del proceso de ingeniería de software. •          Los requisitos tienen valores de propiedad o propiedades exclusivas. Por ejemplo, no tienen la misma importancia ni resulta igual de fácil satisfacerlos. •          Hay muchas partes interesadas, lo que implica que los requisitos deben gestionarse por grupos de personas de funciones cruzadas. •          Cambio de requisitos.   Análisis de problemas: El análisis de problemas se realiza para entender los problemas y las necesidades iniciales del interesado, y proponer soluciones de alto nivel. Es un acto de razonamiento y análisis para encontrar "el problema que se esconde tras el problema". Durante el análisis de problemas, se debe llegar a un acuerdo sobre cuál es el problema real y quiénes son los interesados. También debe definir cuáles son, desde una perspectiva empresarial, los límites de la solución y las restricciones empresariales de la solución. Además, debe haber analizado el caso de negocio del proyecto para que haya un buen conocimiento de qué rentabilidad se espera de la inversión realizada en el sistema que se está construyendo. Conocimiento de las necesidades del interesado: Los requisitos provienen de muchos orígenes; por ejemplo, clientes, socios, usuarios y expertos en dominios. Debe saber cómo se determina mejor cuáles deberían ser los orígenes, cómo se obtiene acceso a estos orígenes y cómo se obtiene información de ellos. Los individuales que proporcionan los orígenes principales de esta información se conocen como interesados en el proyecto. Si va a desarrollar un sistema de información para uso interno de la empresa, puede incluir personas con experiencia de usuario y especialista en dominios empresariales en el equipo de desarrollo. Con mucha frecuencia, las discusiones empezarán en el nivel de modelo empresarial, en vez de en el nivel del sistema. Si va a desarrollar un producto para venderlo en un mercado, recurra constantemente al personal de marketing para conocer mejor las necesidades de los clientes de dicho mercado. Las actividades de obtención pueden realizarse con técnicas como entrevistas, tormenta de ideas, creación de prototipos conceptuales, cuestionarios y análisis competitivo. El resultado de esta actividad debe ser una lista de solicitudes o necesidades descritas textual y gráficamente, y que se han priorizado relativamente entre sí. Definición del sistema: Definir el sistema significa convertir y organizar el conocimiento de las necesidades del interesado en una descripción significativa del sistema que se va a construir. Al principio de la definición del sistema, se toman decisiones sobre qué constituye un requisito, formato de documentación, formalidad del lenguaje, grado de especificación de los requisitos (cuántos hay y qué grado de detalle tienen), prioridad de solicitud y esfuerzo calculado (dos valoraciones muy diferentes normalmente asignadas por personas diferentes en ejercicios separados), riesgos técnicos y de gestión y ámbito inicial. Parte de esta actividad puede incluir primeros prototipos y modelos de diseño relacionados directamente con las solicitudes de interesados más importantes. El resultado de la definición del sistema es una descripción del sistema gráfica y en lenguaje natural. Gestión del ámbito del proyecto: Para ejecutar eficazmente un proyecto, debe priorizar los requisitos cuidadosamente, en función de la entrada de todos los interesados, y gestionar el ámbito. En muchos proyectos, los desarrolladores se dedican a trabajar en los conocidos "huevos de pascua" (funciones que el desarrollador considera interesantes y desafiantes), en vez de centrarse en tareas que mitiguen un riesgo del proyecto o estabilicen la arquitectura de la aplicación. Para asegurarse de que elimina o mitiga los riesgos de un proyecto lo antes posible, debe desarrollar el sistema incrementalmente, escogiendo cuidadosamente los requisitos de cada incremento que mitigue riesgos conocidos del proyecto. Para ello, debe negociar el ámbito (de cada iteración) con los interesados en el proyecto. Esto suele requerir buenas habilidades para gestionar las expectativas de resultado del proyecto en las diferentes fases. También debe controlar los orígenes de requisitos, el aspecto que tienen los productos de trabajo del proyecto y el propio proceso de desarrollo. Perfeccionamiento de la definición del sistema: La definición detallada del sistema debe presentarse de manera que los interesados la entiendan, estén de acuerdo con ella y la den por terminada. La definición no debe incluir únicamente las funciones, sino también la conformidad con los posibles requisitos legales o reguladores, la utilización, la fiabilidad, el rendimiento, la capacidad de soporte y el mantenimiento. Uno de los errores que se cometen es creer que lo que es difícil de construir debe tener una definición compleja. Esta idea lleva a dificultades a la hora de explicar el objetivo del proyecto y el sistema. Es posible que las personas se quedan impresionadas, pero no aportarán nada adecuado porque no entienden la definición. Debería esforzarse mucho en conocer a los receptores de los documentos que está creando para describir el sistema. Es posible que a menudo considere necesario crear diferentes clases de descripciones para receptores diferentes. Hemos visto que la metodología de casos de uso, a menudo combinada con prototipos visuales simples, es una manera muy eficaz de comunicar el objetivo del sistema y definir sus detalles. Los casos de uso ayudan a colocar los requisitos en un contexto; cuentan una historia sobre cómo se utilizará el sistema. Gestión del cambio de requisitos: Independientemente de lo cuidadoso que sea a la hora de definir los requisitos, siempre tendrá que cambiar algo. Los requisitos cambiantes son difíciles de gestionar no sólo porque un requisito cambiado implique más o menos tiempo invertido en la implementación de una función nueva en particular, sino también porque un cambio en un requisito puede afectar a otros requisitos. Debe asegurarse de que proporciona a los requisitos una estructura resistente a los cambios y que utiliza enlaces de rastreabilidad para representar dependencias entre requisitos y otros productos de trabajo del ciclo de vida de desarrollo. La gestión de cambios incluye actividades como establecer una línea base, determinar qué dependencias es importante rastrear, establecer la rastreabilidad entre elementos relacionados y el control de cambios.    Técnicas para el Levantamiento y Recolección de Requisitos (Joint Aplication Desing, JAD)   1.         Entrevistas: por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Según Tamayo se define entrevista como “La relación directa establecida entre el investigador y su objeto de estudio a través de individuos o grupos, con el fin de obtener testimonios reales”. (p.100). 2.         Talleres: los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. 3.         Forma de contrato: en lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas. Según Arias Schreiber, al referirse a la forma del contrato señala que la doctrina distingue entre la forma entendida en sentido amplio y la forma en sentido estricto. (p.01). 4.         Objetivos medibles: los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. 5.         Prototipos: Los prototipos son una representación limitada de un producto, permite a las partes probarlo en situaciones reales o explorar su uso, creando así un proceso de diseño de iteración que genera calidad. Según Kendall & Kendall [2005], define prototipo como una visión preliminar del sistema futuro que se implantara. La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información específica acerca de los requerimientos de información de los usuarios. Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinación de requerimientos. Casos de uso: es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas       ANÁLISIS Y ESPECIFICACIÓN DE REQUISITOS   Estándares para escribir requisitos de alta calidad. Documento De Requisitos (DRS) Métricas Modelo de Análisis     Análisis y Especificación de Requisitos             El análisis global de los requisitos de una aplicación es un proceso de conceptualización y formulación de los conceptos que involucra de forma concreta. Es una parte fundamental del proceso de desarrollo de una aplicación, la mayor parte de los defectos encontrados en el software entregado se originan en la fase de análisis de requisitos, y además son los más caros de reparar. Siempre se ha discutido quién es el dueño de los requisitos: el cliente o el desarrollador. Para gestionar esto, es habitual presentar el análisis de requisitos en dos secciones: Requisitos de cliente: documentan los deseos y necesidades de los clientes y se expresan en lenguaje claro para él.  Requisitos detallados: Determina los requisitos de manera específica y estructurada y están destinadas específicamente hacia los desarrolladores. Los objetivos de este tema son: ü  Distinguir entre requisitos de clientes y requisitos detallados. ü  Disponer de recursos para formular de forma clara y sistemática los requisitos del cliente.- Casos de uso- Diagramas de actividad- Diagramas de interacciones, colaboraciones y flujo de datos.- Descripción de las interfaces de usuario y sus protocolos de uso. ü  Ser capaz de describir los documentos de la especificación de requisitos de software. El resultado del proceso es el documento “Especificación de Requisitos Software”         Estándares para escribir requisitos de alta calidad.   -  Técnica JAD (Diseño de Aplicación Conjunta). -  Técnica FPA (Análisis de Puntos de Función).         La técnica más usada mundialmente es la JAD debido a su efectividad por logra requerimientos de alta calidad. Técnica JAD: El Diseño de Aplicación Conjunta es una técnica o proceso usado en el Ciclo de Vida del Desarrollo de Sistemas para elicitar requerimientos de Sistemas de información para una compañía. Le técnica JAD también incluye enfoques para mejorar la participación de los usuarios, agilizar el desarrollo y mejorar la calidad de las especificaciones de requerimientos. Consiste en un taller donde los trabajadores del conocimiento y especialistas de TI se reúnen, a veces por varios días, para definir y revisar los requerimientos del negocio para el sistema. Sus principales ventajas son la optimización del tiempo, organización  y resolución de conflictos intrínsecos al ámbito de la gestión.  Fundamentos del JAD. El proceso de JAD se basa en cuatro ideas simples: ·         La gente que hace un trabajo tiene la mejor comprensión de ese trabajo ·     La gente entrenada en Tecnologías de la Información tiene la mejor comprensión de las posibilidades de esas tecnologías. ·         Los sistemas de información y los procesos del negocio raramente existen en forma aislada. Más bien trascienden los límites de cualquier sistema u oficina y afectan el trabajo en departamentos relacionados. La gente que trabaja en estas áreas relacionadas tiene una percepción valiosa del papel del sistema dentro de una comunidad más amplia. ·         Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan juntos en un proyecto como socios iguales. Roles del JAD. Patrocinador del proyecto: Es quien presupuesta el proyecto, el dueño del sistema. Tienen el lugar más alto en la organización, de modo que ellos pueden tomar las decisiones y proporcionar los recursos necesarios y apoyar para el proyecto. Responsabilidades: ·         Asegurar que los clientes correctos son parte del grupo. ·         Asegurar que hay suficiente personal de soporte técnico en el proyecto. ·         Ayudar en la selección de casos de la prueba. ·         Ayudar en la definición del alcance y funcionalidad. ·         Ayudar en el benchmarking contra los sistemas actuales y los sistemas externos. Líder del proyecto: Tiene que estar comprometido al proyecto, tener un conocimiento de fondo del área comercial y sistemas de información actuales relacionados. Ellos necesitan ser entusiastas y objetivos y no permitirle a ningún solo individuo dominar el grupo. Responsabilidades: ·         Asegurar que todos los roles de su equipo estén ocupados(que no falte nadie). ·         Asegurar que las reuniones se planifiquen y publiquen con agenda. ·         Asegurar que las agendas se planifican y se siguen. ·         Asegurar que se asignan las tareas y se cumplen, y que el listado de tareas se ejecutan en la secuencia prevista con su línea de tiempo. ·         Coordinar el esfuerzo de los analistas del equipo. Registrador:  Toma los apuntes durante una sesión, y entonces los revisa en un resumen conciso de discusiones y decisiones. Es importante que las notas resultantes no son una transcripción de quién lo dijo. Este papel puede compartirse entre varios miembros del equipo según la necesidad. Estas notas sirven como una referencia al grupo al retomar las discusiones, y para la referencia del retorno en los puntos complejos.  Responsabilidades: ·         Tomar notas durante las reuniones. ·         Resumir y condensar notas después de la reunión. ·         Asegura que el líder del proyecto así como el patrocinador revisen las notas y las corrijan antes de publicarlas. ·         Guardar un historial de notas previendo la entrada de nuevos miembros al equipo en fases adelantadas del proyecto. Time Keeper: Son los responsables de asegurar que se cumpla la agenda establecida a fin de optimizar el tiempo. Clientes: Son los que conocen cómo funcionara el sistema y cómo se usa. Ellos ayudarán al equipo a comprender las tareas manipuladas por el sistema. Responsabilidades: ·         Definir la información con la que el proceso tiene que tratar. ·         Crear casos de uso para su prueba. ·         Analizar los obstáculos al éxito en el ambiente actual.       Documento De Requisitos (DRS)            El documento de requerimientos de software, es el lugar donde se da descripción a las características y requisitos de un software, producto, programa o conjunto de programas. Los requisitos se expresan en lenguaje natural, sin consideraciones ni términos técnicos.          La especificación de requisitos de software es el resultado del levantamiento de información con el usuario o cliente del producto. Son un método para una comunicación más concisa y clara entre los encargados de desarrollar el software y el área de negocio o clientes que usaran el producto.          Un modelo de como elaborar un documento de requerimientos de software. La plantilla sigue los lineamientos establecidos en el estándar IEEE 830, según  el cual la especificación de requisitos debe contener la descripción de la funcionalidad de la aplicación, relación con sistemas externos y requerimientos no funcionales como de rendimiento, disponibilidad, tiempos de respuesta, mantenibilidad entre otros. Descripción de la plantilla de documento de requerimientos de software La plantilla para elaborar el documento de requerimientos de software se divide en las siguientes secciones: Propósito: Nombre o título del software que se está especificado en el documento, incluyendo su número de versión o Release. También se describen cuales componentes o partes del alcance del producto están incluidas en el documento, estableciendo si cubre la totalidad del software, sólo una parte del sistema, subsistema o subgrupo de procesos. Alcance del producto / Software: Descripción corta del alcance del software que se está especificando, incluyendo: Propósito u objetivo general, beneficios que brinda al área de negocio y organización, relación de los objetivos del software con los objetivos corporativos y estrategias de negocio. Se puede hacer referencia a otros documentos.  Referencias: Aquí se pueden incluir otros documentos impresos, documentos electrónicos o direcciones electrónicas que complementen la documentación de requerimientos de software. Funcionalidades del producto: Lista de las funcionalidades del software que se están especificando en el documento de requerimientos. Cada funcionalidad puede estar compuesta por uno o varios requerimientos funcionales de software. Solo se incluye una lista numerada de las principales funcionalidades. Clases y características de usuarios:  Se clasifican los usuarios que utilizaran el producto. La clasificación puede ser en función a la frecuencia de uso, grupo de funcionalidades utilizadas, privilegios de seguridad, nivel de experiencia y otros parámetros. Entorno operativo: Se describe el entorno operativo en el que se desenvolverá el sistema, software, módulo o grupo de funcionalidades, mencionando aspectos como la plataforma de hardware, versiones de sistema operativo y otros sistemas o componentes con los que debe coexistir.  Requerimientos funcionales: En esta •          sección de la plantilla, ilustramos como organizar los requerimientos funcionales de software por funcionalidad de producto o sistema. Aquí se listan las funcionalidades y para cada una a su vez se listan los requerimientos funcionales. Los requerimientos funcionales también se pueden documentar en una matriz de trazabilidad de requerimientos. Reglas de negocio: Listado de reglas y principios que aplican a todo el conjunto de requerimientos de software contenidos en el documento. Un ejemplo es cuales individuos o roles pueden desempeñar cierta función bajo ciertas circunstancias. Requerimientos de interfaces externas: Describe las características y atributos de las interfaces con el usuario (GUI), interfaces con el hardware, interfaces con otros sistemas y las interfaces de comunicaciones.  Requerimientos no funcionales: Los requerimientos no funcionales son los que especifican criterios para evaluar la operación de un servicio de tecnología de información, en contraste con los requerimientos funcionales que especifican los comportamientos específicos.   Métricas Modelo de Análisis       La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de sistemas no es una excepción. Las métricas de sistemas se refieren a un amplio rango de medidas para el sistema de computadoras dentro del contexto de la planificación del proyecto de sistemas, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos. En este existen métricas que podemos utilizar para evaluar lo que estamos haciendo en ingeniería de sistema. Y es lo que veremos más adelante: 1) Criterios-Atributos que debe tener toda métrica para poder ser aceptable. Métricas para: Análisis Diseño Codificación Prueba de Proyecto orientadas a (tamaño y funcionalidad) Atributos de una Métrica La métrica tiene varios atributos importantes en lo que cabe mencionar: A. Simple y calculable Persuasiva. B. Consistente y Objetiva C. Consistente en sus unidades D. Independiente del lenguaje Eficaz. Métricas para Análisis En esta fase es deseable que las métricas-técnicas proporcionen una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el “tamaño” del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados. Otras Métricas para el Modelo de Análisis   La Métrica Bang Puede aplicarse para desarrollar una indicación del tamaño del sistema a implementar como consecuencia del modelo del análisis. Métricas de la Calidad de la Especificación En estas métricas se emplea una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos.   Métricas Para Diseño En este se genera la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del Sistema de Información. Métricas de alto nivel: Las métricas de alto nivel nos ayudan a localizar los módulos más complejos y, por lo tanto, aquellos en los que debemos poner especial atención. También es utilizada para saber el número de módulos asignados a cada trabajador. Métricas de bajo nivel: Las métricas de bajo nivel también llamadas métricas de caja blanca son las que nos ayudan a conocer las interioridades del sistema. Hay tres tipos de métricas de bajo nivel: A. De cohesión B. De acoplamiento C. De complejidad Métricas de código D. La teoría de la ciencia del sistema propuesta por Halstead es probablemente la medida de complejidad mejor conocida y minuciosamente estudiada. La ciencia del sistema propuso la primera ley analítica y cuantitativa para el sistema de computadora. Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño. Estas medidas son: número de operadores diferentes que aparecen en el programa. A.  N2: número de operandos diferentes que aparecen en el programa. B. N1: número total de veces que aparece el operador. C. N2: número total de veces que aparecen el operando. Halstead utiliza medidas primitivas para desarrollar expresiones para la longitud global del programa; volumen mínimo potencial para un algoritmo; el volumen real (número de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del sistema); nivel del lenguaje (una constante para un lenguaje dado); y otras características tales como el esfuerzo de desarrollo, tiempo de desarrollo e incluso el número esperado de fallos en el sistema. Halstead propone las siguientes métricas: 1. Longitud N se puede estimar como: N = n1log2n1+n2log2n2. Volumen de programa se define como: V = N n1log2 (n1+ n2). Tomando en cuenta que V variará con el lenguaje de programación y representa el volumen de información (en bits) necesarios para especificar un programa. Teoría de Halstead Métricas De Prueba 1. La mayoría de las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba. 2. El esfuerzo de las pruebas también se puede estimar utilizando métricas obtenidas de las medidas de Halstead. Usando la definición del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software puede calcularse como: NP = 1/ [(n1/2) x (N2/n2)] n1: no de operadores diferentes n2: no de operandos diferentes N2: no total de Operandos Métricas de Proyecto. En este punto, trataremos de reflejar lo que es la productividad y los dos tipos fundamentales que tiene que ver con: 1.            El tamaño del código. 2.             La funcionalidad del código. Este se utiliza para evaluar el trabajo y los resultados, así como par a poder estimar lo que va a ocurrir en distintas fases del proyecto. Productividad • Cuando se produce soluciones con diferentes atributos, no tiene sentido comparar tasas de productividad, sin embargo las estimaciones son necesarias para las estimaciones del proyecto y para valorar si los procesos o las mejoras tecnológicas son efectivos. • Por lo general estas estimaciones se basan en medir algunos atributos del sistema y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Relacionadas con el Tamaño: • Se relacionan con el tamaño de alguna salida de una actividad. La medida más común son las líneas de código fuente entregadas. • También se utiliza el número de instrucciones de código objeto entregado o el número de páginas de la documentación del sistema. Relacionadas con el Tamaño: Con estas se pueden mantener un registro del sistema desarrollado por la empresa. Estos valores y sus proporciones pueden variar mucho de una empresa a otra. Por eso es muy importante la particularización. Para cada proyecto podemos Obtener A. Productividad = KLDC/p-mesoCalidad = Errores/KLDC B. Coste = Dinero/ KLDC             La empresa puede intentar mantener unos estándares y evaluar la productividad de equipos de trabajos, e incluso las personas involucradas en ella. Pero con la Desventaja de que este tipo de métrica varía con cada lenguaje de Programación. Relacionadas con la función: A. Se relacionan con la funcionalidad total del sistema entregado. B.   La productividad se expresa en términos de la cantidad de funcionalidad útil producida en un tiempo dado. Ejemplos de estas medidas son puntos de función y puntos de objetos. Punto Función La Métrica Del Punto De Función (PF)             Se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto defunción: Métricas Basadas en Función La métrica de punto de función (PF) se puede usar como medio para predecir el tamaño de un sistema que se va a obtener de un modelo de análisis. Para instruir el empleo de la métrica PF, se considerará una sencilla representación del modelo de análisis. En donde se representa un diagrama de flujo de datos, de una función de una aplicación de software llamada Hogar Seguro. La función administra la interacción con el usuario, aceptando una contraseña de usuario para activar/ desactivar el sistema y permitiendo consultas sobre el estado de las zonas de seguridad y varios censores de seguridad. La función muestra una serie de mensajes de petición y envía señales apropiadas de control a varios componentes del sistema de seguridad.