Calidad del Software en el Ciclo de Vida

Mecánicas de Calidad I: en el Ciclo de Vida
Introducción
Verificación y Validación
Evaluaciones, Revisiones e Inspecciones

Aplicación de la Calidad del
Software en el Proceso de
Desarrollo

Aplicación de la Calidad del Software
en el Proceso de Desarrollo
Introducción
• Administrar la calidad se realiza por las
siguientes razones
– Para identificar los indicadores apropiados
(métricas) de calidad aceptable
– Para identificar las medidas apropiadas para ser
utilizadas en la evaluación y revisión de calidad
– Para identificar y dirigir adecuadamente asuntos que
afectan la calidad tan temprana y eficazmente como
sea posible

Introducción
• En general administrar la calidad a través del
ciclo de vida significa que se implementan, se
miden y evalúan tanto la calidad del proceso
como la calidad del producto
• Basados en proceso de desarrollo como el del
proceso unificado se pueden identificar algunos
de los esfuerzos enfocados a administrar la
calidad en cada fase

Introducción
• Requerimientos. El flujo de trabajo de esta fase
para administrar la calidad incluye analizar el
conjunto de artefactos (productos de software)
de requerimientos para su consistencia (entre
los artefactos estándar y otros artefactos),
claridad (que la información se comunique
claramente entre todos los roles) y precisión (el
nivel apropiado de detalle y exactitud

Introducción
• Análisis y Diseño. En esta fase administrar la calidad
incluye valorar el conjunto de artefactos de diseño,
incluyendo la consistencia de elementos como el
modelo de diseño, su traducción desde los elementos
de requerimientos y su traducción en los elementos de
implementación
• Implementación. En esta fase administrar la calidad
incluye valorar los elementos de implantación y evaluar
el código fuente o los elementos ejecutables contra los
elementos de requerimientos, diseño y pruebas

Introducción
• Pruebas. Esta fase está enfocada altamente hacia la
administración de la calidad y la mayoría de los
esfuerzos se enfocan en los propósitos de
administración de la calidad
• Despliegue. En esta fase se incluye valorar los
artefactos de implementación y despliegue, y evaluar
los artefactos ejecutables y de despliegue contra los
elementos apropiados de requerimientos, diseño y
prueba necesarias para entregar el software al cliente

Introducción
• El Ambiente de desarrollo, también es considerado al
administrar la calidad pues éste puede ser configurado
de la mejor manera para que el proceso de desarrollo
cumpla las necesidades
• El rol del Administrador del Proyecto (o su equivalente)
incluye la responsabilidad de muchos de los esfuerzos
para administrar la calidad, incluyendo las revisiones y
auditorías requeridas para evaluar la implantación,
apego y progreso del proceso de desarrollo

• La Verificación confirma que los productos de
trabajo reflejan adecuadamente los
requerimientos especificados para ellos. En
otras palabras, la verificación se asegura de que
“se construyó correcto”
• La Validación, por su parte, confirma que el
producto, como fue entregado, cumplirá con el
uso pretendido. En otras palabras, la validación
se asegura de que “se construyó lo correcto”

• La norma IEEE 1012:2004 (Standard for Software
Verification and Validation) Estándar para la
Verificación y Validación del software, incluye las
siguientes definiciones
• Validación
– Es el proceso de evaluar un sistema o un componente durante o
al final del proceso de desarrollo para determinar si satisface
requerimientos específicos

• Verificación
– Es el proceso de evaluar un sistema o un componente para
determinar si los productos de una fase de desarrollo
satisfacen las condiciones impuestas al inicio de cada fase

• Existen dos perspectivas fundamentales para la
verificación
• La verificación Dinámica
– Ejercitar y observar el comportamiento del producto
– Normalmente = Pruebas del sistema

• La verificación Estática
– Analizar representación estática del sistema
– Normalmente = Revisiones de productos de trabajo

Verificación y
Validación
Estática

Plan de Trabajo

Requerimientos

Prototipo

Producto de Trabajo

Arquitectura

Diseño Detallado

Código

Verificación y
Validación
Dinámica

• Según la ISO/IEC 12207, el proceso de verificación es el
proceso de determinar si los productos de software de
una actividad cumple los requerimientos o condiciones
impuestas a éste en actividades previas
• Para efectividad en los costos y desempeño, la
verificación debe estar integrada, tan temprano como
sea posible, dentro del proceso que lo emplea (tales
como proveer, desarrollar, operar o mantener)
• Este proceso puede incluir análisis, revisiones y pruebas

• La actividad de verificación consiste las
siguientes tareas, con sus respectivos criterios
a incluir en la verificación
• Verificación de Contratos
a. El proveedor tiene la capacidad de satisfacer los
requerimientos
b. Los requerimientos son consistentes y cubren las
necesidades de los usuarios

• Verificación de Contratos
c. Existen procedimientos adecuados para el control
de cambios y la escalación de problemas
d. Los procedimientos y su alcance para las interfases
y la cooperación entre las partes son estipuladas,
incluyendo la propiedad, los derechos de autor y la
confidencialidad
e. Los criterios de aceptación y sus procedimientos
están estipulados de acuerdo con los
requerimientos

• Verificación de Procesos
a. La planeación de los requerimientos del proyecto
son adecuados y oportunos
b. Los procesos seleccionados para el proceso son
adecuados, están implantados, se ejecutan de
acuerdo a lo planeado y cumplen con el contrato
c. Los estándares, procedimientos y ambientes para
los procesos del proyecto son adecuados
d. El proyecto tiene el personal entrenado como lo
define el contrato

•

Validación de Requerimientos
a. Los requerimientos del sistema son consistentes, factibles y
se pueden probar
b. Los requerimientos del sistema han sido asignados
apropiadamente a los elementos de hardware, de software y
operaciones manuales de acuerdo a los criterios de diseño
c. Los requerimientos de software son consistentes, factibles, se
pueden probar y reflejan de manera precisa los
requerimientos del sistema
d. Los requerimientos del software están relacionadas a la
seguridad, certidumbre y de manera correcta

•

Verificación de Diseño
a. El diseño es correcto y consistente con los requerimientos y
es rastreable a ellos
b. Los diseños implementan la secuencia adecuada de eventos,
entradas, salidas, interfases, flujos, asignación de
presupuestos de tiempos y de tamaños, definición de errores,
de aislamiento y de recuperación
c. El diseño seleccionado puede ser derivado de los
requerimientos
d. El diseño implementa los requerimientos de seguridad,
certidumbre y otros de manera correcta

•

Verificación de Código
a. El código es rastreable al diseño y a los requerimientos, se
puede probar, es correcto y cumple con los requerimientos y
los estándares de código
b. El código implementa la correcta secuencia de eventos,
interfases consistentes, datos correctos y flujo de control,
completitud, asignación adecuada de presupuestos de tiempo
y de tamaño, y definición de errores, aislamiento y
recuperación
c. El código seleccionado puede derivarse desde el diseño o de
los requerimientos
d. El código implementa los requerimientos de seguridad,
certidumbre y otros de manera correcta

•

Verificación de la Integración
a. Los componentes de software y las unidades de cada
componente han sido completa y correctamente integrados
dentro del elemento de software
b. Los elementos de hardware, elementos de software y
operaciones manuales del sistema han sido completa y
correctamente integrados dentro del sistema
c. Las tareas de integración han sido ejecutadas de acuerdo con
una plan de integración

• Verificación de la Documentación
a. La documentación es adecuada, completa y
consistente
b. La preparación de la documentación es oportuna
c. La administración de la configuración de los
documentos sigue los procedimientos especificados

• Según la ISO/IEC 12207, el proceso de
validación es el proceso de determinar si los
requerimientos al final de un sistema o
producto de software construido cumple con su
uso específico deseado
• La validación también puede ser conducida en
etapas tempranas del proceso de desarrollo y se
asocia comúnmente con la validación dinámica,
es decir, con las pruebas

• La actividad de validación podría consistir en
las siguientes tareas
– Preparar los requerimientos seleccionados de
pruebas, casos de pruebas, y especificaciones de
pruebas para analizar los resultados de las pruebas
– Asegurar que estos requerimientos de pruebas, casos
de prueba y especificaciones de pruebas reflejen los
requerimientos particulares para su uso específico
deseado

–

Conducir las pruebas mencionadas, que incluye
a. Probar con estrés, fronteras y entradas singulares
b. Probar los productos de software para su habilidad de
aislar y minimizar el efecto de los errores; esto es,
comportamiento adecuado ante fallas, solicitar la
asistencia del operador bajo condiciones de estrés,
frontera o singulares
c. Probar que los usuarios representativos pueden alcanzar
exitosamente las tareas propuestas utilizando el producto
de software

– Validar que el producto de software satisface su uso
deseado
– Probar que el producto de software es apropiado en
las áreas seleccionadas del ambiente destino

• A través del ciclo de vida del producto de
software, para administrar la calidad, se
ejecutan las mediciones y las valoraciones de la
calidad del proceso y del producto
• La evaluación de la calidad puede ser realizada
cuando ocurre un evento importante, tal como
el final de una fase, o puede ocurrir cuando es
producido un artefacto, tal como una revisión
estructurada de código

• Las diferentes evaluaciones que pueden ocurrir
en el ciclo de desarrollo pueden ser
– Evaluaciones de Hitos y de Estatus
– Inspecciones, Revisiones y Revisiones estructuradas
(walkthruoghs)

Evaluaciones de Hitos y Estatus
• Cada fase (o iteración, en procesos iterativos de
desarrollos) da por resultado un entregable, puede ser
un producto ejecutable o un subconjunto del producto
final en desarrollo al cual, las evaluaciones en el
tiempo son realizadas por los siguientes propósitos
– Demostrar el cumplimiento de los requerimientos (y sus
criterios)
– Sincronizar expectativas
– Sincronizar los artefactos relacionados dentro de una línea
base
– Identificar riesgos

Inspecciones, Revisiones y Revisiones
Estructuradas

• Las inspecciones, las revisiones y las revisiones
estructuradas (walkthroughs) son técnicas
específicas enfocadas en evaluar artefactos y
son métodos poderosos de mejora de la calidad
y la productividad de los procesos de desarrollo
• Llevar a cabo estas técnicas debe realizarse en
una formato de reunión, con un rol que actúe
como facilitador y un segundo rol de registro de
notas (solicitudes de cambio, pendientes, etc.)

Estructuradas
• El glosario de la IEEE incluye las siguientes
definiciones
• Revisión
– Una junta formal en la que un producto de software,
o un conjunto de ellos, son presentados a los
usuarios, clientes y otros participantes interesados
para realizar comentarios y aprobaciones

Estructuradas
• Inspección
– Es una técnica de evaluación formal en los cuales los
productos de software son examinados en detalle
por una persona o grupo diferente al autor para
detectar errores, violaciones a los estándares de
desarrollo y otros problemas

Estructuradas
• Revisiones Estructuradas (walkthroughs)
– Son un proceso de revisión en los cuales un
desarrollador dirige uno o más miembros del equipo
de desarrollo a través de una sección de un artefacto
que él haya desarrollado mientras los otros
miembros hacen preguntas y realizan comentarios
acerca de la técnica, estilo, posibles errores,
violaciones de los estándares de desarrollo y otros
problemas

Estructuradas
• El ejecutar estas revisiones son realizadas en
formato de reuniones, aunque los participantes
pueden preparar algunas revisiones por si
mismos
• El monitoreo continuo de la calidad durante las
actividades de los procesos previene a tener un
gran número de defectos que se mantengan
ocultos hasta las revisiones

Estructuradas
• Cuando se implementan estas técnicas en
equipos las revisiones también proporcionan
oportunidades para examinar el diseño y el
código desde otros grupos e incrementar las
oportunidades de detectar código fuente de uso
común, oportunidades de reuso y oportunidades
para generalización

Estructuradas
• Las revisiones también proporcionan una
manera de coordinar el estilo de la arquitectura
entre varios grupos
• En el proceso unificado las revisiones juegan
una importante segunda opinión en el
aseguramiento de calidad

Estructuradas
• Una de las principales actividades que
contribuyen a la calidad (en metodologías como
RUP o PSP) son las Revisiones de Colegas (peer
reviews) que también son un tipo de Revisiones

Estructuradas — Planeación
• Se planean las revisiones para determinar el
enfoque y el alcance de las revisiones, y para
estar seguros de que todos los participantes
entienden su papel y las metas de las revisiones
• Previo a las revisiones se define el alcance de
las revisiones para determinar las preguntas a
realizar, definir qué elementos serán evaluados
y por qué

• Para cada producto de software se pueden
definir un conjunto de puntos de revisión
(check-points) que podrán ser evaluados
• Las preguntas exactas a ser realizadas
dependerá de la fase del proyecto de
desarrollo: las revisiones tempranas se
enfocarán con aspectos de arquitectura, las
revisiones posteriores serán más específicas

• Una vez que el alcance de las revisiones ha sido
determinada, se deben definir los participantes
de las revisiones, la agenda y la información
que será requerida para ejecutar la revisión
• Al seleccionar los participantes, se debe
establecer el balance entre la habilidad de
arquitectura de software y la habilidad del
domino de negocio

• Se debe definir de manera clara y no ambigua
el líder de evaluación
• Si es necesario, se pueden tomar otros equipos
o otras partes de la organización para
proporcionar habilidad del negocio o técnica
• El número de revisores deberá ser
aproximadamente siete o menos

• Si son elegidos adecuadamente, serán capaces
sin dificultad de identificar problemas en la
arquitectura
• Un mayor número de revisores en realidad
reducen la calidad de la revisión al hacer las
reuniones más largas, la participación más
difícil y pueden inyectar problemas adicionales
y discusiones en la revisión


• Menos de cuatro revisores incrementa el riesgo
de no ver defectos así como la diversidad de
asuntos se reduce
• Los revisores deben ser experimentados en el
área a revisar, para elementos de
requerimientos, los revisores deben entender el
dominio del problema, para la arquitectura del
software se requiere conocimiento de técnicas
de diseño

• Los revisores no experimentados pueden
aprender acerca de la arquitectura al
participar, pero contribuirán poco a las
revisiones y su presencia puede ser motivo de
distracciones
• Se debe mantener el grupo pequeño, no más de
siete elementos y no menos de tres

• Un número menor de revisores arriesga la
calidad de la revisión y más revisores evitan las
discusiones interactivas esenciales para
alcanzar resultados de calidad

• Se deben seleccionar a los revisores de acuerdo
al material
– Aquellos que tienen la experiencia para entender el
material presentado
– Aquellos que tienen relación directa en la calidad
del producto de software a ser revisado

Estructuradas — Preparación

• Previo a la revisión, los artefactos serán
revisados y cualquier material de soporte
deberá ser generado y distribuido a los
participantes de la revisión
• Esto debe ser realizado con suficiente
anticipación y permitir a los revisores tener
tiempo para prepararse para la revisión, mejora
de manera significativa la calidad de los
resultados de la revisión

• La preparación de los revisores también mejora
la eficiencia y efectividad de las revisiones
• Los revisores deberán estudiar la
documentación, formular preguntas e
identificar los asuntos a analizar, todo esto,
antes de la revisión

• Pensando en la carga de trabajo normal de los
revisores, unos pocos días de trabajo serán
normalmente el tiempo mínimo suficiente para
prepararse para las revisiones

Estructuradas — Conduciendo la Revisión
• Existen diversos elementos clave para conducir
una revisión exitosa
– Entender el proceso de revisión
– Estar seguros de que los revisores entienden sus
roles
– Tener un moderador
– Mantener la revisión corta y apegarse a la agenda
– Identificar pendientes, no arreglar problemas


• Entender el Proceso de Revisión. Se refiere a
que en lo general, el proceso de revisión sigue
el siguiente ciclo
– Un asunto es identificado por el revisor
– El asunto es discutido y potencialmente confirmado
– Se identifica un defecto (lo que se haya identificado
necesita ser canalizado)
– Continuar hasta que no haya más asuntos
identificados

• Con el propósito de hacer este trabajo de
manera efectiva, todos deben entender que la
meta de una revisión es mejorar la calidad del
producto de software revisado
• Los productos deben ser revisados con un ojo
crítico para encontrar problemas


• Hacer esto puede ser difícil, así que todos los
revisores deben constantemente recordar
enfocarse en la identificación de asuntos (de
manera natural somos solucionadores de
problemas, pero los revisores deben dejar esto
a un lado)
• Todos tenemos un fuerte sentido de propiedad
de nuestro trabajo, normalmente es difícil
aceptar la crítica, aún cuando es constructiva

• Como resultado de esto, nuestro trabajo deberá
ser aún mejor para enfocarnos en las metas de
las revisiones: hacer el trabajo mejor

Estructuradas — Entender los Roles
• Con el propósito de conducir una revisión
efectiva, cada participante juega un rol
• De forma más específica, hay ciertos roles que
deben ser jugado y los revisores no pueden
intercambiar sus papeles tan fácilmente

• Los roles básicos de una revisión son
–
–
–
–

El moderador
El secretario (escribano)
El presentador
Los revisores

• El moderador asegura que los revisores se
apeguen a la agenda y permanece enfocado en
el tópico en cuestión
• El moderador asegura que las discusiones no
tomen partido, que no arruinen la revisión y
que los revisores participen equitativamente
• El escribano normalmente es subestimado, pero
es un parte esencial para el equipo de revisión

• Mantener un registro de lo que es discutido y
documentar las acciones a ser tomadas es una
tarea de tiempo completo
• Asignar esta tarea a uno de los revisores
normalmente lo mantendría fuera de la
discusión


• Peor aún, si no se documenta de forma correcta
lo que fue decidido probablemente llevará a
que el asunto revisado aparezca de nuevo en el
futuro
• Debe estarse seguro de que exista un escribano
y que éste sea el único papel que juegue esa
persona
• El presentador es el autor del producto a ser
revisado


• El presentador explica el producto de software
y cualquier información de contexto necesaria
para entenderlo (aunque si el producto no
explica por si mismo, esto probablemente
requerirá cierto trabajo)
• Es importante que los revisores no se conviertan
en jueces – el enfoque debe ser en el producto
que es revisado, no en el presentador

• Es responsabilidad del rol de moderador el
asegurar que los participantes (incluyendo al
presentador) tengan esto en mente
• El presentador está allí para iniciar la discusión
o análisis, responder preguntas y ofrecer
clarificación cuando sea necesaria
• Los revisores identifican asuntos o problemas
(issues)

• Es importante mantenerse enfocado en esto y
no caer en discusiones de cómo canalizar el
asunto
• Se deben enfocar en los resultados, no en los
medios

Estructuradas — Tener un Moderador
• Como ya se mencionó, un moderador juega un
papel crucial en evitar que la revisión pierda el
orden y pierda foco
• Es importante que el moderador esté enfocado
en mantener la revisión sobre su camino, el
moderador no debe tener responsabilidades de
revisor

Estructuradas — Tener un Moderador
• El rol de moderador está para promover la
discusión y análisis, asegurar la participación
equitativa y evitar agresividad
• Es una tarea de tiempo completo
• Fallar en moderar de manera eficiente podría
causar a los revisores que se salgan de los
objetivos buscados y podrían fallar en alcanzar
sus metas de revisión

Estructuradas — Revisiones Breves
• Las revisiones son más eficientes cuando son
breves y se enfocan en objetivos claramente
definidos
• Debido a que es difícil mantener el enfoque por
períodos de tiempo largos y también porque los
revisores tienen más trabajo que hacer, se
deben limitar las revisiones a no más de dos
horas

• Si se espera que una revisión sea más larga, es
mejor dividirla en varias reuniones más
pequeñas y más enfocadas
• Los resultados serán mejores si los revisores
pueden mantenerse enfocados
• La clave de realizar esto es tener una agenda
bien definida y con metas claramente
articuladas

• Ésta debería ser comunicada cuando se
distribuye el material de la revisión y el
moderador debe reforzarlo cuando inicie la
reunión de revisión
• El moderador debe entonces ser consistente (y
a veces muy estricto) en reforzar estas metas
durante la reunión

Inspecciones, Revisiones y Revisiones Estructuradas
— Identificar Asuntos, no Resolverlos
• Una de las principales razones por las cuales las
reuniones fracasan en alcanzar los resultados
esperados es que tienen la tendencia a
degradarse en discusiones de cómo un problema
debe ser arreglado
• El arreglar problemas normalmente requiere de
investigación y de reflexión, el formato de una
revisión no será un medio efectivo para este
tipo de discusión

• Una vez que el asunto (issue) es identificado, se
debe determinar si es un defecto que debe ser
resuelto, y entonces asignarlo a alguien para
investigarlo y resolverlo
• La reunión de revisión debe enfocarse en la
identificación solamente
• Si el asunto requiere de una mayor discusión
entre un grupo de personas, se debe realizar
una reunión por separado para enfocarse en él

• Típicamente estas reuniones requieren de
investigación y preparación, y será necesaria la
gente con las habilidades correctas para ser
involucradas en ella
• El revisor debe mantenerse enfocado en identificar
otros aspectos
• El moderador necesitará frecuentemente
emplearse con firmeza para mantener a los
revisores enfocados en esto

• Las revisiones aportan poco valor a la calidad si
no hay acciones en consecuencia de ejecutarlas
• Al concluir las revisiones se debe
– Asignar prioridades a la lista de problemas
– Crear un registro de los defectos para el seguimiento
de los problemas y de su solución
– Si se requiere investigación adicional, asignar un
pequeño equipo de trabajo para hacerlo (pero no
para resolverlo)

– Para los problemas que pueden ser resueltos en la
iteración o fase actual, se le asigna un persona o
equipo para corregirlo
– Actualizar la lista de los problemas no resueltos para
planear los esfuerzos de la siguiente fase o iteración

Mecánicas de Calidad I: en el Ciclo de Vida
Introducción

Fin de la Presentación
Continúe en la siguiente actividad

Calidad del Software en el Ciclo de Vida

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Calidad del Software en el Ciclo de Vida

Similaire à Calidad del Software en el Ciclo de Vida (20)

Calidad del Software en el Ciclo de Vida

Notes de l'éditeur