Ingeniería de Requisitos

 Métodos:

Pressman:

En el proceso de análisis de requerimientos del software se puede identificar

cinco tareas o etapas fundamentales:

1. Reconocimiento del problema: Se deben de estudiar inicialmente las

especificaciones del sistema y el plan del proyecto del software. Realmente
se necesita llegar a comprender el software dentro del contexto del sistema.
El analista debe establecer un canal adecuado de comunicación con el equipo
de trabajo involucrado en el proyecto. En esta etapa la función primordial del
analista en todo momento es reconocer los elementos del problema tal y como
los percibe el usuario.

2. Evaluación y síntesis: En esta etapa el analista debe centrarse en el flujo

y estructura de la información, definir las funciones del software, determinar
los factores que afectan el desarrollo de nuestro sistema, establecer las
características de la interfaz del sistema y descubrir las restricciones del
diseño. Todas las tareas anteriores conducen fácilmente a la determinación
del problema de forma sintetizada.

3. Modelización: Durante la evaluación y síntesis de la solución, se crean

modelos del sistema que servirán al analista para comprender mejor el
proceso funcional, operativo y de contenido de la información. El modelo
servirá de pilar para el diseño del software y como base para la creación de
una especificación del software.

4. Especificación: Las tareas asociadas con la especificación intenta

proporcionar una representación del software. Esto más adelante permitirá
llegar a determinar si se ha llegado a comprender el software, en los casos
que se lleguen a modelar se pueden dejar plasmados manuales.

5. Revisión: Una vez que se han descrito la información básica, se

especifican los criterios de validación que han de servir para demostrar que
se ha llegado a un buen entendimiento de la forma de implementar con éxito
el software. La documentación del análisis de requerimientos y manuales,
permitirán una revisión por parte del cliente, la cual posiblemente traerá
consigo modificaciones en las funciones del sistema por lo que deberán
revisarse el plan de desarrollo y las estimaciones previstas inicialmente.
CORE:

Consiste en siete etapas. Cada una produce salidas que alimentan a la etapa
subsecuente como entrada o que forman parte de la especificación de
requerimientos final. CORE pretende examinar el sistema y su ambiente en
un número de niveles, con detalles más finos progresivamente en cada nivel.
Las siete etapas se presentan a continuación:

1. Definición del problema. El propósito de la definición del problema es

identificar los límites del mismo. Contiene detalles de los objetivos de la
empresa de los usuarios del sistema, la base para la necesidad de un nuevo
sistema, limitaciones de costo y tiempo, y quién va a ser el responsable de la
revisión y aceptación de los resultados finales.

2. Estructuración del punto de vista. El propósito de esta etapa es

descomponer el ambiente del sistema en los elementos para que el sistema
propuesto pueda ser analizado desde los puntos de vista de todas las
entidades que se comunican con él, la más importante de las cuales son los
usuarios. Durante esta etapa, todas las entidades que son fuentes potenciales
de información deben ser identificadas

3. Colección tabular. Esta etapa es cuando la información sobre los flujos de

datos entre los puntos de vista y el procesamiento de éstos son reunidos. Esto
ayuda a establecer la totalidad y consistencia.

4. Estructuración de datos. En la etapa previa, los elementos de información

que pasan entre los puntos de vista son referidos por sus nombres generales.
En esta etapa, se da una vista más cercana al contenido, a la estructura y a
la derivación de datos, al producir diagramas de estructura de datos.

5. Modelación individual de puntos de vista. Esta etapa puede dividirse en

dos partes. Lo único concerniente a la primera es convertir las TCF'S en una
notación diferente para producir los diagramas individuales del modelo de
punto de vista. La segunda parte se refiere a agregar alguna información
nueva perteneciente a flujos de datos internos, control de acciones y tiempo
de acciones.

6. Modelación combinada de punto de vista. Esta etapa facilita el análisis

de una secuencia de eventos de más de un punto de vista. Cada diagrama
de modelo combinado de punto de vista producido durante esta etapa es una
representación del procesamiento de información que ocurre entre puntos de
vista.
 7. Análisis de restricciones. En esta etapa, se consideran restricciones
adicionales tales como desempeño y seguridad. Éstas pueden afectar los
diagramas de puntos de vista ya producidos. Las restricciones se documentan
en una especificación de restricción del sistema.

 Herramienta

CASE:
Las herramientas CASE agilizan y facilitan la optimización de un producto
software, ofreciendo apoyo permanente al grupo de desarrollo. En el mercado
existen herramientas CASE de apoyo a las diversas fases del proceso de
desarrollo de software. Algunas, atadas a una metodología específica, otras
totalmente independientes de la misma. la mayoría de ellas son comerciales y
presentan mayor funcionalidad, aunque debido a los altos costos de sus
licencias son de difícil y/o limitado acceso. La ingeniería de requisitos es una
tarea que aún tiene mucho por explorar para optimizar sus tareas y cumplir a
cabalidad los objetivos propuestos. Igualmente, es necesario realizar una
evaluación de funcionalidad y rendimiento de las herramientas existentes, con
el fin de depurarlas, ya que al aumentar su número se hace más difícil la
elección para la gestión de recursos.

Arquitectura

 Métodos:

ALMA

Es un método de evaluación orientado a metas. Existen tres para las que se

puede usar:

• Predicción del costo de mantenimiento. Consiste en estimar el esfuerzo

requerido para modificar la arquitectura a cambios requeridos en un futuro.
• Evaluación de riesgos. Identifica los tipos de cambios que pueden ser
complejos o que sean inflexibles en la arquitectura de software.
• Selección de un conjunto de arquitecturas. Compara dos o más
arquitecturas propuestas y selecciona aquella que proporcione mayor
soporte a cambios.

Este método se realiza a través de los siguientes pasos:

1. Definir la meta de evaluación. Dependiendo del objetivo de la evaluación,
se selecciona alguna de las tres metas.

2. Describir la arquitectura de software. Se colecta la información más

relevante de la arquitectura: sus principales componentes, las relaciones
entre éstos, así como las relaciones con el entorno del sistema.

3. Obtener escenarios. Se definen los escenarios de cambio y se agrupan

en categorías. Se eligen aquellos escenarios relacionados con el propósito
de evaluación. Por ejemplo: si la meta es estimar el esfuerzo de
mantenimiento, se recomienda seleccionar aquellos escenarios que
corresponden a los cambios que tienen una alta probabilidad de que ocurran
durante la vida operacional del sistema.

4. Evaluar escenarios. Se realiza un análisis de impacto, que consiste en

identificar los componentes afectados por los escenarios previamente
definidos, determinar el efecto del cambio sobre los componentes, así como
determinar los efectos del cambio en otros componentes. Los resultados de
este análisis se deben expresar ya sea de manera cuantitativa o cualitativa.

5. Interpretar resultados. Finalmente se interpretan los resultados, así como

las conclusiones del análisis dependiendo de la meta de evaluación
seleccionada.

PASA
Este método se interesa por conocer, qué tanto tiempo le toma al sistema de
software responder cuando uno o varios eventos ocurren, así como
determinar el número de eventos procesados en un intervalo de tiempo dado.
PASA es el trabajo resultante de Williams y Smith, y utiliza diversas técnicas
para la evaluación, tales como la aplicación de estilos arquitectónicos, anti-
patrones, guías de diseño y modelos.

Para utilizar este método, la arquitectura de software debe estar previamente

documentada. En caso de que se encuentre parcialmente documentada, es
necesario extraer la información faltante de los miembros del equipo, así
como de códigos fuente.

Los pasos para llevar a cabo este método son:

1. Presentar el método de evaluación. Se comunica al equipo y directivos

el objetivo de la evaluación, y se explica el método PASA.

2. Presentar la arquitectura. El equipo de desarrollo presenta la arquitectura

actual de una manera general y sin entrar en detalles.
3. Identificar casos de uso críticos. Se seleccionan los casos de uso que
son importantes para la operación del sistema, así como aquellos que
demandan una respuesta de tiempo rápida para el usuario, u otros que
presentan algún riesgo de desempeño. Recordemos que un caso de uso
puede contener varios escenarios, que describen las diferentes formas en
que se puede realizar el caso de uso. Los escenarios se especifican en UML
como diagramas de secuencia.

4. Seleccionar los escenarios de desempeño principales. Por cada caso

de uso crítico, se debe identificar los escenarios significativos con respecto
al desempeño.

5. Identificar objetivos de desempeño. Por cada escenario de desempeño

principal, se debe especificar al menos un objetivo de desempeño. Mismos
que pueden ser expresados de distintas maneras. Por ejemplo: expresarlos
en tiempo de respuesta, capacidad de respuesta, restricciones o utilización
de recursos. Para poder medirlo, el objetivo de desempeño debe ser
cuantitativo.

6. Clarificar la arquitectura y discutirla. En este paso se estudia más a

detalle la arquitectura, por lo que se tienen reuniones con el arquitecto y
equipo de desarrollo para aclarar dudas. Si existe información acerca del
desempeño del sistema, se colectan métricas.

7. Analizar la arquitectura. En este paso se utilizan diferentes técnicas para

analizar el desempeño de la arquitectura. Por ejemplo: se identifican estilos
arquitectónicos, con la finalidad de detectar efectos negativos en el
desempeño, se identifican anti-patrones de desempeño que documentan
problemas comunes. Se elaboran modelos de desempeño con el objetivo de
identificar problemas en la arquitectura.

8. Identificar alternativas. Si se encontraron problemas de desempeño, se

identifican alternativas de solución. Estas pueden incluir el cambio de estilo
arquitectónico, modificar la arquitectura para eliminar anti-patrones de
desempeño, o alternativas para optimizar la interacción entre componentes.

9. Presentar resultados. Finalmente se elabora un documento con los

resultados de la evaluación que incluye los objetivos de la evaluación,
hallazgos encontrados, pasos específicos a seguir y recomendaciones.
  Herramienta

RADS

Es una herramienta que ha sido creada para lograr el objetivo planteado,

permitiendo:

 Capturar las experiencias de los arquitectos de una forma estructurada, de

manera tal que brinda la posibilidad de efectuar comparaciones entre ellas

 Almacenar dichas experiencias en un repositorio común y compartido

 Recuperar las experiencias almacenadas en el repositorio a partir de la

identificación de una nueva experiencia

 Articular los medios necesarios para que las soluciones empleadas en las
experiencias recuperadas sean aplicadas en la nueva experiencia de diseño
arquitectónico a llevar a cabo.

Pruebas

 Métodos:
SCENT:
Permite derivar casos de prueba tomando como insumo la definición de
escenarios y actores que interactúan con el sistema, para luego definir
prioridades, pasando por la elaboración de diagramas de dependencia,
diagramas de estados y por último generar casos de prueba.

Riebisch et al.
Está centrada en la transformación automática de un modelo de casos de uso a
un modelo de uso que sirve como entrada para realizar pruebas estadísticas
automáticas, que mejoran el nivel de cobertura, partiendo de que diferentes
partes de un software no necesitan ser probadas con la misma minuciosidad. El
método comienza con el refinamiento de los casos de uso ampliándolos con
precondiciones y pos condiciones, alternativas al camino de ejecución principal
y referencia a otros casos de uso relacionados. Después se traducen a
diagramas de estado y se elabora el modelo de uso donde se indica la
probabilidad de que ocurra una transición y se identifican los caminos de
ejecución más frecuentes. Por último, se extraen los modelos de prueba a partir
de los modelos de uso y se generan recorridos aleatorios sobre cada modelo de
uso. Cada camino aleatorio será un caso de prueba.

 Herramienta
Open-HMI Tester (OHT)
Se trata de una arquitectura abierta (no está ligada a ningún sistema operativo
ni sistema de ventanas) para pruebas de interfaz gráfica. Esta arquitectura está
compuesta por una serie de módulos que implementan una funcionalidad gen
Érica, y que por lo tanto nunca cambian (representados en la figura por las cajas
no coloreadas); y un conjunto de módulos que deben ser adaptados con el fin
de dotar a la arquitectura de la funcionalidad necesaria para poder operar sobre
un sistema operativo y sistema de ventanas concretos (estos módulos están
representados en la figura por cajas coloreadas). La arquitectura OHT se divide
en dos módulos principales: el módulo HMI Tester (encargado del control de los
procesos) y el Módulo Preload (es el módulo inyectado en la aplicación testada).
El módulo HMI Tester tiene como principal cometido el controlar los procesos
de grabación (captura de eventos) y de reproducción (ejecución de eventos),
así como la gestión completa de la creación y el mantenimiento de los archivos
de pruebas (test suites). El módulo HMI Tester contiene una serie de sub-
módulos que deben ser adaptados: Data Model Manager and Adapter
submodules: estos módulos permiten integrar en la arquitectura Open-HMI
Tester la implementación de cualquier representación del modelo de datos.
Preloading Action module: el principal objetivo de este módulo es llevar a cabo
el proceso de precarga, permitiendo la inyección del Módulo Preload al lanzar
la aplicación a testar.

Jeyson Amado Aguillon

201711551
Bibliografía

 Alarcón, A., & Sandoval, E. (2008). Herramientas CASE para ingeniería de

Requisitos. Cultura Científica, (6), 70-74. Recuperado a partir de
https://www.jdc.edu.co/revistas/index.php/Cult_cient/article/view/305

 González Palacio, L. (2011). Método para generar casos de prueba

funcional en el desarrollo de software. Revista Ingenierías Universidad
De Medellín, 8(15 Sup. 1), 29-36. Recuperado a partir de
https://revistas.udem.edu.co/index.php/ingenierias/article/view/175

 G. D. Gil, Herramienta para implementar LEL y escenarios, La Plata, 2002.

 M. C. |. G. S. M. |. L. H. P. Carignano, RADS: una herramienta para

reutilizar estrategias en diseños de arquitecturas de software, La Plata,
2016.