MECABIC Método de evaluación para la Herramienta de levantado de requerimientos: care 3.2.

Presentación del tema: "MECABIC Método de evaluación para la Herramienta de levantado de requerimientos: care 3.2."— Transcripción de la presentación:

1 Curso: análisis de requerimientos Integrantes: Joice Reyes Carmona Laura bermúdez

2 MECABIC Método de evaluación para la Herramienta de levantado de requerimientos: care 3.2

3 AGENDA: 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.

4 1. Introducción: 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).

5 2.Método de Evaluación para Arquitecturas de Software Basadas en Componentes (Mecabic)
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.

6 Fases en las que participan
2.1 Equipo del mecabic 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. Relacionados Son las personas involucradas de alguna manera con el sistema: programadores, usuarios, gerentes, entre otros Fases 1, 3 y 4.

7 2.2 Técnicas de evaluación del mecabic
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.

8 2.3 Fases del mecabic Presentación. Investigación y Análisis. Pruebas.
Resultados.

9 2.3.1 Fase de presentación Pasos fundamentales:
Presentación de MECABIC. Comprensión del método. Arquitectura a evaluar. Características de calidad esperadas.

10 2.3.2 Fase de investigación y desarrollo
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.

11 2.3.2.2 Árbol de utilidad Nodo Raíz Nodo Secundarios Nodo Hoja
Característica Sub-característica Escenario Funcionalidad Fiabilidad Eficiencia Mantenibilidad Portabilidad Factores de calidad establecidos por ISO 9126

12 2.3.3 fase de prueba 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.

13 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

14 3.1 Arquitectura de CARE

15 3.2 Funcionalidad Pantalla de Requerimientos

16 3.2 Funcionalidad - Requerimientos
Atributos de requerimientos Cambios requeridos Jerarquía de requerimientos Cumplimiento Historial

17 3.2 Funcionalidad - Asociaciones
Preguntas Criterio de aceptación

18 3.2 Funcionalidad - Consultas
Consulta por capítulo

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

20 3.2 Funcionalida - Estadísticas
Valor devengado

21 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.

22 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.

23 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.

24 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 +/-