Unidad 3 Verificación 

3.1 Marco de Referencia para el desarrollo de
software.
3.2 Herramientas para apoyar al proceso y la
ejecución de las revisiones de software.
3.3 Manejo de Requerimientos (Verificación).
3.4 Verificación en este proceso.
3.5 Entradas propuestas para el proceso de
verificación de requerimientos.
3.6 Método de verificación.
3.7 Aspectos a verificar en esta etapa.
3.8 Entendimiento de problema (Verificación).
3.9 Revisión general de requerimientos.
3.10 Fase de manejo de requerimientos.

3.1 Marco de Referencia para el desarrollo de software.

Verificación es la acción de verificar (comprobar o examinar la verdad de algo). La verificación suele ser el proceso que se realiza para revisar si una determinada cosa está cumpliendo con los requisitos y normas previstos.

Antecedentes: La industria del software, a diferencia de otras industrias, tiene muy poco tiempo de vida.

Desde hace ya más de 50 años, en Walter Shewhart comenzó a trabajar en la mejora de procesos estableciendo los principios del control estadístico de la calidad,Glenford J. Myers en 1979 promovió que la Ingeniería del Software separase las disciplinas fundamentales del desarrollo del software de la verificación y validación del mismo.

Los principios de Shewhart fueron refinados por W

Los principios de Shewhart fueron refinados por W. Edwards Deming dando lugar al ciclo Deming, el cual fue utilizado entre otras cosas para la mejora continua de la calidad dentro de una empresa. Estos pasos son: Planear, Hacer, Verificar y Actuar.

Etapa 1:  La orientación de las pruebas a la solución de errores.

Hasta 1956, La orientación de las pruebas a la solución de errores.

Durante los comienzos de la TI, a pesar de ser notoria la aparición de problemas relacionados con el software desarrollado, éstos fueron dados de lado en pro de los aspectos hardware.  El primer artículo basado en las pruebas del software fue escrito por Alan Turing en 1949 En este artículo se hablaba de “pruebas de corrección”. 

Etapa 2: La orientación de las pruebas a la demostración

En 1957, Charles Baker distinguió el concepto de “depuración” del de “prueba” en su revisión “Mathematical Tables and Other Aids to Computation”. En la cual se destacaba que la verificación de los programas perseguía dos objetivos fundamentales: “Asegurar el funcionamiento de la aplicación” Asegurar que la aplicación resolvía el problema para el que había sido planteada”.

En esta etapa, debido a que llevar a cabo las pruebas suponía un esfuerzo comprendido de entre un 30% y un 50% como mínimo, del coste total de un desarrollo software. Autores como Ince y Jessop llegaron a la conclusión de que si el proceso de pruebas pudiese ser automático se reduciría significativamente su coste. 

Etapa 4: La orientación de las pruebas a la evaluación

 Filosofía de FIPS“Ninguna técnica de verificación y validación puede garantizar la corrección, es decir, un software libre de errores. Sin embargo, una cuidadosa elección de técnicas para un proyecto específico puede ayudar a asegurar el desarrollo y el mantenimiento de la calidad del software de un proyecto”.

Etapa 5: La orientación de las pruebas a la prevención

Calidad del Software.

3.2 Herramientas para apoyar al proceso y la ejecución de las revisiones de software.

¿Que son las revisiones?

ü  Son el conjunto de actividades que suceden como resultado del análisis, el diseño y la codificación y que sirven para depurar las actividades de ingeniería del software. Una revisión, tiene como objetivos:

ü  Señalar la necesidad de mejoras en el producto

ü  Continuar las partes de un producto en las que no es necesaria o no es deseable una mejora

ü  Conseguir un trabajo técnico de una calidad más uniforme, o al menos más predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el trabajo técnico.

ü  En cada paso del proceso de desarrollo de software, se presentan errores que pasan inadvertidos y que producen un mayor número de errores si las revisiones no lo detectan.

ü  Los errores amplificados corresponden, a aquellos errores que pasan inadvertidos desde pasos anteriores. De igual forma se representa el porcentaje de eficiencia de la detección de errores.

Revisión técnica formales.

Una revisión técnica formal (RTF) es un medio efectivo para mejorar la calidad del software.

•         Los objetivos de la RTF son:

•         Descubrir errores en la función, la lógica o la implementación de cualquier representación del software

•         Verificar que el software bajo revisión alcanza sus requisitos

•         Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos

•         Conseguir un software desarrollado de forma uniforme

•         Hacer que los proyectos sean manejables

La RTF incluye:

•         Recorridos

•         Inspecciones

•         Revisiones cíclicas

•         Evaluaciones técnicas del software

•         Cada RTF debe estar debidamente planificada, controlada y atendida por el grupo encargado de cada RTF.

Directrices de revisión.

1. Revisar el producto, no al productor: Se deben señalar los errores de forma constructiva y no dificultar el proceso de revisión. Es importante mantener el control de la reunión y descartar situaciones que se escapen de control.

2. Fijar una agenda y mantenerla: Se debe tener un plan de trabajo antes de la reunión. Se debe seguir el orden del plan para que la reunión tenga éxito y cumplir con los tiempos asignados al plan.

3. Limitar el debate y las impugnaciones: No se debe perder tiempo debatiendo situaciones que no presenten unanimidad, es importante registrar el hecho y dedicar otros tiempos para su debate.

4. Enunciar áreas problemas, pero no intentar resolver los problemas que se pongan de manifiesto: La resolución de problemas se debe programar para otros espacios después de la reunión de revisión.

5. Tomar notas escritas: Es buena idea utilizar diferentes herramientas para la toma de notas, por ejemplo, pizarras, tableros, computador, para que se pueda hacer seguimiento a la asignación de prioridades.

6. Limitar el número de participantes e insistir en la preparación anticipada:  Se debe limitar el número de revisores, los cuales deben estar preparados para cada reunión y participar activamente en el proceso de revisión.

7. Desarrollar una lista de comprobación para cada producto que haya de ser revisado: Se deben desarrollar listas de comprobación para los documentos de análisis, diseño, codificación y pruebas.

8. Disponer recursos y una agenda para las RTF: Cada RTF debe estar planificada e involucrar modificaciones.

9. Capacitación y entrenamiento de los revisores: Todas las personas que participen en el proceso de revisión deben recibir un entrenamiento que se debe basar en: · El proceso · Psicología humana

10. Revisar las revisiones anteriores: Son beneficiosas porque permiten descubrir problemas del proceso de revisión

3.3 Manejo de Requerimientos (Verificación).

Validación de requisitos:

•         Este proceso generalmente se realiza una vez obtenida una primera versión de la documentación de requisitos.

•         Tiene por finalidad comprobar que los requisitos del software poseen todos los atributos de calidad enunciados a continuación.

1. Consistentes, Completos, Precisos, Realistas, Verificables

•         Estas actividades pretenden evitar los altos costos que significaría el tener que corregir una vez avanzado el desarrollo.

Métodos más habituales.

Revisión de requisitos: consisten en reuniones donde el equipo de analistas intenta localizar los errores en el documento de la especificación.

Prototipado: consiste en construir una maqueta del futuro sistema a partir de requisitos recogidos en la especificación. (evaluada por el cliente y usuarios).

Generación de casos de prueba: consiste en la definición de casos de prueba que permitan verificar el complimiento de los requisitos funcionales.

Revisión de los requisitos

Consisten en una o varias reuniones, planificadas donde se intenta confirmar que los requisitos poseen los atributos de calidad deseados.

El resultado final de las reuniones de revisión es un documento que contiene la lista de defectos localizados y una lista de acciones recomendadas.

La revisión de los requisitos es uno de los mejores métodos de validación de requisitos ya que permiten

1. Descubrir una gran cantidad de defectos en los requisitos

2. Reducir los costos de desarrollo entre un 20% y un 30%

3. Reducir el tiempo de pruebas entre un 50% y un 90%

Dichas reuniones se realizan en 6 pasos

1. Preparar el plan de revisión (las tareas a realizar, planificación temporal y las personas participantes).

2. Distribuir el documento a revisar (generalmente el único documento a revisar será el documento de especificación).

3. Preparar la reunión generalmente es muy diferente para quien la realice

v  Analista promotor de la reunión –logística

v  Analistas - revisión deben leer cuidadosamente los documentos recibidos y anotar aquellos defectos con la finalidad de ponerlos en manifiesto durante la reunión

1. Realizar la reunión de revisión. El formato de la reunión puede ser muy diverso, puede ser una total falta de control o puede ser muy formalizado y sujeto a protocolos de actuación.

2. Identificar los defectos y acciones a realizar. La lista de defectos y acciones recomendadas es el documento final obtenido en las revisiones de requisitos

3. Realizar correcciones que sean precisas: el promotor de la reunión debe evaluar y llevar a cabo las acciones recomendadas que han surgido en la reunión.

4. Informar de las modificaciones realizadas: una vez que los defectos han sido subsanados, se envía un informe de tareas realizadas y una copia corregida de los documentos de especificación a los participantes de la reunión.

PROTOTIPOS

Consiste en la creación de una maqueta o versión del producto, existen varios tipos de prototipos cada uno de los cuales permiten la realización de un tipo determinado de pruebas, los prototipos más comunes son:

Mock-up: se trata de pantallas, dibujadas típicamente a mano, que representan un aspecto concreto del sistema (el soporte que proporciona a la validación es muy limitado)

Storyboards: son una evolución de los anteriores ya que además de la interfaz, se muestra la secuencia de acciones, o escenarios, que se deben realizar con el programa

Maquetas- una maqueta representa únicamente la interfaz del sistema y, opcionalmente las conexiones entre pantallas mediante la utilización de elementos activos como los botones.

¿Qué tipos de prototipos de deben construir?

Generación de casos de prueba.

Son artefactos bien definidos en el contexto de la prueba de software, un caso de prueba es la descripción de una acción bien definida que se debe realizar con el software (que están perfectamente descritos tanto los datos de entrada como las tareas a realizar y los resultados esperados)

3.4 Verificación en este proceso.

Se verifican las prácticas implantadas en los procesos de la organización con auxilio de cuestionarios y entrevistas acordes con los requisitos establecidos en la norma aplicable. con base en los resultados obtenidos de esta investigación, se determina el nivel de madurez de capacidades de los procesos verificados hasta el nivel objetivo requerido, según la solicitud de la organización.

Ejemplo de hoja de verificación

Al final, se emite un dictamen de cumplimiento formalizando el resultado obtenido, mismo que proporciona certidumbre en la capacidad de la organización para cumplir sus objetivos.

Las inspecciones de software se pueden planificar y ejecutar en diversas etapas del desarrollo. la ejecución de este proceso dará como resultado un conjunto de defectos, con los cuales se debe lograr un análisis y conclusiones para la mejora de los procesos específicos y, de forma general, del proceso de desarrollo de software.

Es el proceso de prueba del software para asegurar que cumple su especificación.

Identificar los casos y escenarios de la prueba.

Si el software funciona correctamente.

3.5 Entradas propuestas para el proceso de verificación de requerimientos.

v  La verificación se da en torno a tres procesos básicos:

v  Inspección: Es una revisión técnica a fondo, rigurosa y formal, diseñada para identificar problemas tan cerca de su punto de origen como sea posible.

v  Medición: Es el proceso por medio del cual se miden la mayor cantidad de atributos del producto y proceso, con el fin de tener información cuantificable útil para la mejora continua.

Administración de la configuración

Proceso: Ingeniería de Requerimientos

Proceso por el cual se determina si la especificación es consistente con las necesidades del cliente.

Incluye verificar trazabilidad entre la especificación y el documento de requerimientos.

Se trabaja con un bosquejo completo del documento a diferencia de la verificación del análisis.

Se realizan las siguientes verificaciones en el documento de requerimientos:

•         Validez: compromiso con el usuario, que valide que es lo que quiere.

•         Consistencia: que no haya contradicciones.

•         Realismo: que se puedan implementar (incluye: tecnología, presupuesto y calendario).

•         Verificabilidad: Diseñar conjunto de pruebas para demostrar que el sistema cumple esos requerimientos.

El equipo

•         Moderador

•         Diseñador

•         Implementador/Codificador

•         Encargado de pruebas

El proceso

Fagan propone un proceso de inspección constituido por las siguientes actividades

•         Vista general

•         Preparación

•         Inspección

•         Retrabajo

•         Seguimiento

Proceso: Ingeniería de Requerimiento

Verificación de Requerimientos no funcionales.

ü  Son difíciles de verificar.

ü  Se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva (esto es IDEAL).

ü  Proceso: Ingeniería de Requerimientos

ü  Técnicas: Validación de Requerimientos

Participan representantes

ü  Del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus gerentes.

ü  Del equipo de desarrollo: analistas de requerimientos, diseñadores, encargados de pruebas y gestión de configuración.

Incluye:

ü  Revisar objetivos del sistema.

ü  Evaluar alineamiento de requerimientos con los objetivos (necesidad).

ü  Revisar el ambiente de operación y las interfaces con otros sistemas.

ü  Funciones completas, restricciones realistas.

ü  Evaluar riesgos.

ü  Considerar:

ü  Pruebas del sistema.

ü  Cambios en los requerimientos en el proyecto, su verificación y validación.

Medición de Requerimientos

La medición de requerimientos está enfoca a tres áreas: Producto, Proceso y Recursos.

Los productos de los requerimientos (definición y especificación) pueden ser evaluados en primer lugar considerando el número de requerimientos.

De manera similar se puede medir la cantidad de cambios introducidos a los requerimientos. Un gran número de cambios indica cierta inestabilidad o incertidumbre en la comprensión de lo que el sistema debe hacer o cómo comportarse. También es bueno evaluar la incertidumbre por tipo de requerimiento. Esto permite seccionar.

Medición de Requerimientos

Debido a que los requerimientos son utilizados por los diseñadores y verificadores, pueden utilizarse medidas que reflejen cuando los requerimientos están preparados para derivar a ellos. Existe una forma de evaluación utilizada para verificadores y diseñadores, donde califican los requerimientos en una escala de 1 a 5 para saber si estos están listos.

La escala es la siguiente:

1. Lo comprende por completo, ha diseñado (verificado) requerimiento similar antes y no debería tener problema.

2. El requerimiento posee algún elemento que le resulta nuevo, pero no es radicalmente distinto de lo que ha diseñado (verificado) con éxito antes.

3. Hay elementos nuevos que lo hacen muy diferente de los que ha diseñado (verificado) antes, pero los comprende y piensa que a partir de ellos puede desarrollar un buen diseño (prueba).

4. Hay partes del requerimiento que no entiende bien y no está seguro de poder desarrollar un buen diseño (prueba).

5. No comprende este requerimiento en absoluto y no puede desarrollar un diseño (prueba) para él.

3.6 Método de verificación.

Clasificación

Métodos formales, en los cuales se trata de determinar analíticamente que las transformaciones realizadas sean correctas.

Métodos basados en la simulación, en los cuales se trata de determinar la corrección del sistema a través de la simulación, ya sea lógica o eléctrica. Estos métodos suponen la generación de un testbench (banco de pruebas) que deben tener una serie de patrones de test.

Métodos basados en la emulación, los cuales son similares a la simulación excepto en que la emulación se lleva a cabo sobre prototipos hardware, y la simulación sobre netlist lógicos y/o eléctricos.

I Métodos Formales

ü  La verificación formal utiliza razonamientos rigurosamente matemáticos para demostrar que un sistema mostrará todo o parte del comportamiento especificado.

ü  No obstante, los métodos formales no son una panacea. Aunque se verifique que el netlist de un sistema satisfaga una especificación formal, no existe una completa seguridad de que el sistema físico se comporte como se pretende.

I.I Especificaciones formales

ü  Para poder utilizar unos razonamientos matemáticos, se deben especificar formalmente tanto las propiedades que se desean verificar como el sistema a verificar. En este caso, el sistema va a ser modelado con un diagrama de estados, como vimos en el tema II.

ü  En cambio, las propiedades van a ser especificadas utilizando una lógica temporal (ya que las propiedades suelen tener una connotación temporal).

Lógica Temporal

ü  Dirigida a verificar propiedades que cambian con el tiempo; por lo tanto, estamos ante una lógica (usualmente proposicional) enriquecida con operadores temporales que permite razonar sobre cómo cambiarán las afirmaciones en el tiempo. Dentro de las lógicas temporales, vamos a centrarnos en la lógica de árboles de computación, CTL (Computation Tree Logic), que utiliza un modelo discreto de tiempos en el que el tiempo se puede dividir en más de un posible futuro partiendo desde un mismo estado inicial.

ü  En este caso, y considerando la porción de diagrama de estado, tenemos un ciclo entre los estados p1 y p3; otro camino es el que continua con el estado p2 y después los estados p4 o p5.

Métodos basados en la simulación y emulación

ü  Para el resto de niveles de abstracción, el método más utilizado para la verificación es la simulación, tanto eléctrica como lógica.

ü  Para realizar una simulación, debemos tener una descripción estructural del sistema.

Así que con la simulación debemos verificar dos hechos fundamentalmente:

ü  La comunicación entre los diferentes bloques del sistema, y la funcionalidad de cada uno de dichos bloques.

ü  Para llevar a cabo la simulación es necesario disponer de tres objetos: un banco de patrones de test (o testbench),

Métodos basados en la simulación y emulación

ü  El banco de pruebas no es más que una secuencia en los puertos de entrada al diseño bajo test (DUT, Design Under Test).

ü  El comportamiento del DUT con dichos valores en los puertos de entrada es comparado con un modelo de referencia para determinar el grado de corrección del DUT.

3.7 Aspectos a verificar en esta etapa.

ü  Documento de requerimientos

ü  Verificación del cumplimiento de requerimientos

ü  Calidad

ü  Comprobación y análisis del sistema

ü  Aspectos a considerar en requerimientos

Los requerimientos son lo que el software debe hacer y/o características que el software debe tener.

ü  Deben ser consistentes, completos, realizables y verificables

ü  Que los requerimientos expresan las necesidades y las restricciones puestas en un producto.

ü  En los requerimientos funcionales se considera que describa las funciones que el software debe realizar.

ü  En cuanto a los requerimientos no funcionales son las restricciones a las posibles soluciones.

Verificación del cumplimiento de los requerimientos

ü  Ayudan a realizar revisión de técnicas antes de iniciar su diseño

ü  Identificando los aspectos más débiles y los que pueden generar problemas; como debe estas completos, ayuda a asegurar que no existen requerimientos que no se puedan comprobar

Calidad

La calidad del software es el grado o medida en que el producto cumple con sus especificaciones.

“La calidad implica excelencia, es decir, que el software funcione correctamente y cumpla con todos los requisitos del cliente”. Los requisitos del software son la base de las medidas de la calidad.

Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software, Si no se distinguen esos criterios no habrá calidad del software.

Existe un conjunto de requisitos implícitos que a menudo no se mencionan, si no se alcanzan estos requerimientos podría la calidad quedar en entredicho. Los requisitos son llamados por los usuarios finales llaman elementos obvios, los cuales el diseñador no debe dejar pasar sin explicación.

Comprobación y análisis de sistemas

·         Inspecciones del software: analizan y comprueban las representaciones del sistema como el documento de requerimientos, los diagramas de diseño y el código fuente del programa.

·         Las inspecciones de software y los análisis automatizados son técnicas estáticas puesto que no requieren que el sistema se ejecute.

·         Las pruebas del software: Llevan a cabo una implementación del software con los datos de prueba y examinan las salidas del software y su comportamiento operacional para comprobar que se desempeñe conforme a lo requerido.

Factores que pueden ser medidos directamente (errores, líneas, tiempo, …)

Factores que sólo pueden ser medidos indirectamente (facilidad de uso, mantenimiento, …)

Factor 1

Características operativas, relacionadas con las operaciones del producto.

·         Corrección

·         Fiabilidad

·         Eficiencia

·         Integridad

·         Facilidad de uso

Factor 2

Capacidad de soportar cambios, relacionado con la revisión del producto.

·         Facilidad de mantenimiento

·         Flexibilidad

·         Facilidad de prueba

Factor 3

Adaptabilidad, relacionado con la transición del producto.

·         Portabilidad

·         Reusabilidad - Reutilizabilidad

·         Interoperabilidad

·         Cumplir con los requerimientos

3.8 Entendimiento de problema (Verificación).

¿POR QUÉ FALLA EL SOFTWARE?

No hace lo requerido (o hace algo que no debería)

Razones:

•         Las especificaciones no estipulan exactamente lo que el cliente precisa

•         Requerimiento no se puede implementar

•         Faltas en el diseño

•         Faltas en el código

•         La idea es detectar y corregir estas faltas ates de liberar el producto

Verificación

•         Es el proceso de determinar si los productos de una determinada fase del ciclo del proceso de desarrollo cumplen los requerimientos establecidos durante la fase previa.

Objetivos.

•         Descubrir defectos (para corregirlos)

•         Provocar fallas (una forma de detectar defectos)

•         Revisar los productos

•         Evaluar la calidad del proyecto

Identificación y corrección de defectos

Identificación de defectos

•         Es el proceso para determinar que defectos causaron la falla

Corrección de defectos

•         Es el proceso de cambiar el sistema para remover los defectos

3.9 Revisión general de requerimientos.

Ingeniería de requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

Los requerimientos son la pieza fundamental en un proyecto de desarrollo de software, en ellos se basan muchos participantes del proyecto.

Los requerimientos deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos partes posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo sabemos si cumplimos con él o no?

Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo) Lo más abstracto y conciso posible. Para evitar malas interpretaciones.

La revisión de requerimientos trata de demostrar que estos realmente definen el sistema que el cliente desea. Coincide principalmente con el análisis ya que este implica encontrar problemas con los requerimientos.

La validación de requerimientos es importante debido a errores en el documento de requerimientos pueden conducir a importantes costes al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema esté en uso.

Durante el proceso de REVISION de requerimientos, se deben llevar acabo verificaciones sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden:

1. Verificaciones de validez: Un usuario puede pensar que se necesitan un sistema para llevar acabo ciertas funciones. sin embargo, el razonamiento y el análisis pueden identificar que se requieren funciones adicionales o diferentes.

2. Verificaciones de consistencia: Los requerimientos en el documento no deben contradecirse. Esto es, no debe haber restricciones propuestas por el usuario del sistema.

3. Verificaciones de completitud: El documento de requerimientos debe incluir requerimientos que definan todas las funciones y restricciones propuestas por el usuario del sistema.

4. Verificación del realismo: Utilizando el conocimiento de la tecnología existente, los requerimientos deben verificarse para asegurar que se pueden implementar. Estas verificaciones también deben tener en cuenta el presupuesto y la confección de agendas para el desarrollo del sistema.

5. Verificabilidad: Para reducir la posibilidad de discusiones entre el cliente y el contratista, los requerimientos del sistema siempre deben redactarse de tal forma que seas verificables. Esto significa que debe poder escribir un conjunto de pruebas que demuestren que el sistema a entregar cumple cada uno de los requerimientos especificados.

En la revisión formal de requerimientos, el equipo de desarrollo debe <> al cliente a través de los requerimientos del sistema, explicándolo las implicaciones de cada requerimiento. El equipo de revisión deba cada requerimiento para la consistencia además de verificar los requerimientos como un todo para la completitud.

3.10 Fase de manejo de requerimientos.

v  Los requisitos son la parte más incomprendida de la Ingeniería de Software y sin embargo, es la más crucial.

v  Estudios apuntan a que más del 60% de las fallas en los proyectos de software en los Estados Unidos, se deben a una pobre definición de requisitos.

v  La gestión de requisitos es una parte importante de una organización que desarrolla sus propios proyectos de software, puesto que es vital para reducir los riesgos inherentes a ellos.

v  La Ingeniería de Requisitos es el proceso de descubrir, analizar, documentar y verificar los servicios proporcionados por el sistema y sus restricciones operativas.

v  La Ingeniería de Requisitos también puede ser vista como una actividad de “Ingeniería” y “Gestión”; porque es concerniente con la identificación de metodologías apropiadas para desarrollar soluciones de software bajo unos costos que sean apropiados para su implementación.

REQUISITOS Y CLASIFICACIÓN

v  Los requisitos pueden ser considerados como las funcionalidades y/o servicios proporcionados por el sistema y sus restricciones operativas.

v  En otra aproximación, los requisitos son una colección de necesidades provenientes del usuario y otros stakeholders.

TIPOS DE REQUISITOS

MODELOS DE INGENIERÍA DE SOFTWARE

Modelo de Pohl

Ø  Elicitación: buscar formas explícitas el conocimiento oculto sobre las necesidades de clientes y usuarios y el sistema a desarrollar, de manera que todos los stakeholders sean capaces de entenderlo.

Ø  Negociación: busca alcanzar acuerdos y/o entendimientos entre todos los participantes sobre los requisitos propuestos en la fase anterior.

Ø  Especificación/Documentación de requisitos: busca documentar los requisitos documentados y elicitados, utilizando varias notaciones, con el fin de ser lo más explícito posible.

Ø  Validación/Verificación de requisitos: busca que los requisitos documentados corresponden con las necesidades de los clientes y usuarios (validación) y comprobará que la especificación cumple los criterios de calidad oportunos (verificación).

MODELO ESPIRAL

Ø  Haciendo la comparativa con el modelo de Pohl, la obtención de requerimientos equivale a las actividades de elicitación y negociación, la especificación de requerimientos a la especificación y documentación de requisitos, y la validación de requerimientos con la validación y la verificación.

Ø  MODELO SWEBOK

Ø  MODELO BORLAND

GESTIÓN DE REQUISITOS

Ø  La gestión de los requisitos implica establecer un entendimiento compartido entre los stakeholders (personas relacionadas con el proyecto) y los requisitos que ellos han especificado para ser incluidos en el producto de software.