Transcript PPT Investigacion CARE

CURSO: ANÁLISIS DE REQUERIMIENTOS
INTEGRANTES:
JOICE REYES CARMONA
LAURA BERMÚDEZ
MECABIC
MÉTODO DE EVALUACIÓN PARA LA
HERRAMIENTA DE LEVANTADO DE
REQUERIMIENTOS: CARE 3.2
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.

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).
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.
2.1 EQUIPO DEL MECABIC
Equipo
Arquitectos
Evaluador
Relacionados
Característica
Responsables de generar y documentar una
Arquitectura de Software para el sistema
estudiado
Integrado por personas expertas en asuntos
de calidad quienes guiarán el proceso de
evaluación de la arquitectura.
Fases en las
que participan
Todas
Todas
Son las personas involucradas de alguna
manera con el sistema: programadores,
Fases 1, 3 y 4.
usuarios, gerentes, entre otros
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.

2.3 FASES DEL MECABIC

Presentación.

Investigación y Análisis.

Pruebas.

Resultados.
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.
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.
2.3.2.2 ÁRBOL DE UTILIDAD
Nodo Raíz
Característica
Funcionalidad
Factores de
calidad
establecidos
por ISO 9126
Fiabilidad
Eficiencia
Mantenibilidad
Portabilidad
Nodo Secundarios
Sub-característica
Nodo Hoja
Escenario
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.
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
Seguridad
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.
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
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.
Fiabilidad
3.3 Resultados de la evaluación
Característica
Sub-caract
Escenario
Resultado
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.
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.
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.
Eficiencia
Tiempo de
comportamiento
Mantenibilidad
Habilidad de cambio,
estabilidad, prueba
Portabilidad
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 +/-