curso: análisis de requerimientos integrantes: joice reyes carmona laura bermúdez

MECABIC

1.Introducción. 2.Descripción del método MECABIC. 3.Descripción de la herramienta CARE

3.2 4.Resultados de la evaluación. 5.Conclusiones.

En la actualidad la proliferación de software en el mercado es increíblemente masiva, podemos encontrar cualquier tipo de software en cualquier categoría y/o clasificación que se nos pueda ocurrir, es por ello que las organizaciones han buscado la manera de establecer metodologías asociadas a técnicas que les permitan listar, evaluar, medir y finalmente escoger la herramienta o software que mejor se adapte a su necesidad

La presente investigación consiste en evaluar la herramienta de levantado de requerimientos CARE 3.2, para lo cual hemos decidido utilizar, y con base a lo descrito anteriormente hemos decidido utilizar el Método de Evaluación para Arquitecturas de Software Basadas en Componentes, MECABIC. Cuyo principal objetivo consiste en evaluar y analizar la calidad exigida por los usuarios sobre AS Basadas en Componentes (ASBC).

Evalúa y analiza calidad esperada por los usuarios.

Inspirado en otros métodos. i.e: ATAM

Está compuesto por: Equipo de colaboradores. Técnicas de evaluación. Fases.

Equipo Característica Fases en las

que participan

Arquitectos Responsables de generar y documentar una Arquitectura de Software para el sistema estudiado

Todas

Evaluador

Integrado por personas expertas en asuntos de calidad quienes guiarán el proceso de evaluación de la arquitectura.

Todas

Relacionados

Son las personas involucradas de alguna manera con el sistema: programadores, usuarios, gerentes, entre otros

Fases 1, 3 y 4.

Evaluación de la Arquitectura del Software Arbol de utilidad compuesto de:

Nodo Raíz: Utilidad del sistema. Nodos Secundarios: Características de calidad Nodos Hojas: Escenarios a tomar en cuenta.

Permite establecer prioridades. Ayuda de cuestionarios.

Presentación.

Investigación y Análisis.

Pruebas.

Resultados.

Pasos fundamentales:

Presentación de MECABIC. Comprensión del método. Arquitectura a evaluar. Características de calidad esperadas.

Forma en que se va a estudiar la arquitectura.

Escenarios de calidad a tomar en cuenta por los tomadores de decisiones.

Análisis de la arquitectura. Pasos:

1.Identificación de elementos de diseño. 2.Generación de árbol de utilidad. 3.Análisis de elementos de diseño.

Característica Sub-característica Escenario

Funcionalidad

Fiabilidad

Eficiencia

Mantenibilidad

Portabilidad

Nodo Raíz Nodo Secundarios

Nodo Hoja

Factores de calidadestablecidos por ISO 9126

Evaluación de decisiones realizadas hasta el momento.

Participación de todos los involucrados Producir la arquitectura final. Contempla:

Revisión del árbol de utilidad. Revisión de los elementos de diseño

definidos.

3. Descripción de la herramienta CARE 3.2 CARE 3.2 (Computer Aided Requirements

Engeneering) de Sophist Group

CARE es una herramienta basada en Lotus Notes que sirve para guiar al desarrollador en el proceso de administración de los requerimientos de un sistema, al recolectar, optimizar y trazar los requerimientos

3.1 Arquitectura de CARE

3.2 Funcionalidad

Pantalla de Requerimientos

3.2 Funcionalidad - Requerimientos

Atributos de requerimientos Cambios requeridos Jerarquía de requerimientos Cumplimiento Historial

3.2 Funcionalidad - Asociaciones

Preguntas Criterio de aceptación

3.2 Funcionalidad - Consultas

Consulta por capítulo

3.2 Funcionalidad - Consultas Historial en orden alfabético o por fecha

3.2 Funcionalida - Estadísticas Valor devengado

3.3 Resultados de la evaluación

Característica Sub-caract Escenario Resultado

Funcionalidad

Interoperabilidad El sistema posee componentes capaces de leer datos provenientes de otros sistemas.

El sistema importa y exporta documentos de productos Microsoft.Permite también adjuntar archivos en las entidades (requerimientos, entrevistas, etc.)

El sistema posee componentes capaces de producir datos para otro sistema.

El sistema es capaz de exportar a XML. Esto permite una gran comunicación con otros sistemas ya que el XML es ampliamente utilizado.

Seguridad El sistema detecta la actuación de un intruso e impide acceso a los componentes que manejen información sensible

El sistema maneja usuarios con roles específicos que filtran la información y la funcionalidad a la que cada usuario tiene derecho. Por otro lado, al utilizarse junto con Lotus Notes, hay un paso de seguridad extra ya que los usuarios debe autenticarse primero en Notes para luego utilizar la herramienta.

3.3 Resultados de la evaluación

Característica Sub-caract Escenario Resultado

Fiabilidad

Madurez Los componentes del sistema manejan entradas de datos de datos incorrectas

El sistema es bastante abierto a texto libre en la mayoría de los casos y esto es correcto. Sin embargo, también cuenta con una serie de “combo boxes” que aseguran la integridad de los datos de entrada y la consistencia a lo largo de los distintos componentes del sistema.

Tolerancia a fallos Todas las operaciones ejecutadas por los componentes se realizan correctamente bajo condiciones adversas.

Durante las pruebas, en una ocasión el software generó un error al visualizar los cambios requeridos de un requerimiento. En general, el sistema tolera los fallos correctamente.

Capacidad de recuperación

Los componentes del sistema no fallan bajo ciertas condiciones especificadas

Ciertamente al ser una aplicación web, la recuperación de errores es más sencilla, ya que se utilizan frames y pop ups para las distintas operaciones. Cuando éstas fallan, la pantalla o los frames principales permiten al usuario continuar trabajando.

Durante las pruebas, la ventana para criterios de aceptación se quedó “pegada” en una ocasión. Esto no evitó continuar trabajando con la aplicación al levantarse la operación en una ventana aparte.

3.3 Resultados de la evaluación

Característica Sub-caract Escenario Resultado

Eficiencia

Tiempo de comportamiento El sistema debe recibir los servicios de sus componentes en el transcurso de un tiempo indicado.

El sistema tiene un tiempo de respuesta lento. Debe cargar una gran cantidad de datos en las diferentes vistas y toma un tiempo notable pero manejable.

Por la falta de disponibilidad de la herramienta completa, no se pudo probar su integración con un Lotus Notes local. Esto tiene la ventaja de que se puede trabajar con bases de datos locales que luego se sincronizan para mejorar el tiempo de respuesta.

Mantenibilidad

Habilidad de cambio, estabilidad, prueba

Es posible verificar el estado de los componentes del sistema.

La facilidad de cambio se debe negociar con el proveedor. Las versiones con mejoras no son muy frecuentes (1 al año) pero sí constantes.

Portabilidad

Adaptabilidad El sistema debe continuar funcionando correctamente aun cuando los servicios de los componentes provistos por el ambiente varíen

En diferentes browsers la aplicación se comporta correctamente.

Capacidad de Instalación Los componentes pueden instalarse fácilmente en todos los ambientes donde debe funcionar

Al ser un sistema con acceso Web, la instalación es sumamente sencilla.

Dependencia con Lotus Notes.

5.Conclusiones.

Completa para administración de requerimientos

Calidad adecuada Puntos en contra:

Tiempo de respuesta Interfaz Trazabilidad a lo largo de todo el proyecto

Dependencia con Lotus Notes +/-