Objetivo
|
Definir el ámbito y los objetivos de la revisión.
Definir los enfoques utilizados para cada combinación específica de ámbito y objetivos.
|
Para realizar la revisión se pueden utilizar distintos enfoques:
-
controlado por representaciones
-
controlado por la información
-
controlado por casos de ejemplo
Revisión controlada por representaciones
Obtenga (o cree) una representación de la arquitectura y, a continuación, formule preguntas y razónelas basándose en
esta representación.
Existe una amplia gama de situaciones, desde las organizaciones que tienen una gran cultura en arquitectura y
proporcionarán descripciones inteligibles desde el principio, a organizaciones donde deberá identificar quién es el
arquitecto de software (que puede estar oculto incluso bajo otro nombre) y extraer la información de esa persona, o
aquellas en las que la arquitectura de software es un concepto totalmente desconocido. Este proceso se denomina "minar
la arquitectura" y, a la práctica, es bastante literal: cavar y extraer el software o su documentación a pico y pala,
teniendo en cuenta el código fuente, las interfaces, los datos de configuración, etc.
Un modelo que se puede utilizar para organizar la representación se encuentra en el formato de las vistas de la
arquitectura presentadas en el Documento de arquitectura de software: la vista lógica organiza las principales clases
(el modelo de objeto), la vista de proceso describe las principales hebras de control y cómo se comunican, la vista de
desarrollo muestra los distintos subsistemas y sus dependencias, y la vista física describe la correlación de elementos
de las otras vistas en una o varias configuraciones físicas. Organice los temas según las distintas vistas.
Revisión controlada por la información
Establezca la lista de información (datos, medidas) necesaria para razonar, obtener la información y compararla con los
requisitos o con algún estándar de referencia aceptado. Esta revisión está especialmente indicada para investigar
determinados atributos de calidad como, por ejemplo, el rendimiento o la fuerza.
Revisión controlada por casos de ejemplo
Este es el enfoque sistemático de "qué ocurre si". Transforme las preguntas generales que se están realizando en un
conjunto de casos prácticos que debe pasar el sistema y formule preguntas basadas en los casos de ejemplo. Estos casos
de ejemplo son, por ejemplo:
-
El sistema se ejecuta en las plataformas X e Y. (El atributo de calidad real probado es la portabilidad).
-
El sistema ejecuta esta función F (adicional). (El atributo de calidad real es la capacidad de ampliación).
-
El sistema procesa 200 solicitudes por hora. (El atributo de calidad real es la escalabilidad).
-
El sistema está siendo instalado en este tipo de sitio por el usuario. (El atributo de calidad real es la
completitud o la utilización).
La ventaja de este tipo de enfoque es que coloca la tarea en una perspectiva muy concreta, comprensible para todas las
partes. También permite probar omisiones o defectos en los requisitos, especialmente cuando los requisitos son
informales, no se han escrito o son muy generales y ligeros. La desventaja es que no engloba la arquitectura como el
objeto que se está revisando, sino que toma el sistema como una caja negra a la que sólo se envían algunas pruebas.
En la práctica, los enfoques no están separados tan claramente y al final se acaban combinando.
Identificar problemas
El descubrimiento de problemas potenciales se realiza principalmente según el juicio humano, basándose en los
conocimientos y la experiencia. Algunos patrones de anomalía se repiten de un proyecto a otro, o de una organización a
otra. Se puede utilizar la heurística para descubrir áreas de problemas. Las listas de comprobación pueden ser muy
útiles (más adelante se proponen algunas muy genéricas), así como los resultados de las revisiones anteriores, si
existen.
Capture los problemas potenciales a medida que aparezcan y descríbalos con un tono neutro, sin juicios
acusatorios ni 'catastrofismos'. Puede utilizar pequeñas tarjetas de cartulina como hacen los revisores de AT&T, o
como hacemos nosotros con las tarjetas CRC, para la priorización, organización y eliminación.
Posteriormente, ordene los problemas candidatos en orden de ámbito o impacto decreciente y, si hay muchos, aborde
primero los que estén relacionados directamente con la pregunta específica y deje para después las "otras sugerencias",
si tiene tiempo para ellas. A continuación, valore la realidad del problema: muchas veces podemos percibir un problema,
pero luego no existe. Puede que no hayamos hablado con la persona correcta o que no hayamos encontrado la información
adecuada. Vuelva a ordenarlos. Asegúrese de tener múltiples coordenadas para verificar la realidad de un problema. (Los
evaluadores inexpertos tienden a centrarse en una única hebra).
Cuando el problema se haya confirmado, examine rápidamente qué puede eliminarlo, sin que necesariamente se tenga que
realizar el rediseño dinámico del sistema. Escriba posibles simplificaciones, reutilizaciones y alternativas (por
ejemplo, comprar en lugar de construir).
|