Unidad 5

Unidad 5 – Aseguramiento de la Calidad
● Conceptos de calidad
● Fiabilidad, disponibilidad y seguridad
● Gestión de la calidad
● Garantía de la calidad
● Planificación de la calidad
● Control de la calidad
● Actividades de la SQA
● Modelos de calidad
● CMM
● CMMI
● Revisiones de software
● Revisiones Técnicas Formales (RTF)
IS Unidad 5 Luis Nieto 2018 2
● Pruebas del software

● Pruebas de componentes
● Pruebas del sistema
● Pruebas de integración
● Pruebas de entregas
● Pruebas de rendimiento
● Diseño de casos de prueba
Unidad 5 – Conceptos de calidad
● Para productos tangibles, la calidad depende de

la similitud entre el producto desarrollado y su
especificación
● El control de variación es la base del control de

calidad: se quiere reducir la variación entre los
productos que se fabrican
● En el SW el esfuerzo se centra en controlar la

variación en:
● el proceso que se aplica
● los recursos que se consumen
● los atributos de calidad del producto final
● En el SW se quiere reducir la diferencia entre los

recursos planificados y los reales utilizados
● Calidad: “característica o atributo de algo”

● Como un atributo de un elemento, la calidad se
refiere a las características medibles: cosas
que se pueden comparar con estándares
conocidos: longitud, color, etc
● El SW es más difícil de caracterizar que los

objetos físicos. Algunas propiedades:
complejidad, cohesión, número de puntos de
función, líneas de código, etc
● satisfacción del usuario = producto

satisfactorio + buena calidad + entrega
dentro de presupuesto y tiempo
establecidos
● La calidad es importante, pero si el usuario no
queda satisfecho nada más importa
● Esta visión de la calidad establece que si el
producto SW proporciona un beneficio sustancial
a los usuarios finales, éstos pueden estar
dispuestos a tolerar problemas ocasionales de
rendimiento o fiabilidad
● El costo de la calidad incluye todos los costos

acarreados en la búsqueda de calidad o en las
actividades relacionadas con la obtención de
calidad
● Los costos de calidad están asociados con:

● Prevención
● Evaluación
● Fallos
● Prevención: planificación, revisiones técnicas

formales, equipo de pruebas y formación
● Evaluación: actividades para tener una visión

más profunda de la condición del producto. Por
ejemplo: inspección del proceso, mantenimiento
del equipo, pruebas
● Fallos: se dividen en:

● Costos internos: se producen cuando se
detecta un error en el producto antes de su
envío (retrabajo o revisión, reparación, análisis
de las modalidades de fallos, etc)
● Costos externos: debido a defectos

encontrados una vez enviado el producto al
cliente (resolución de quejas, devolución y
sustitución de productos, soporte de línea de
ayuda, trabajo de garantía)
● Los costos relativos para encontrar y reparar un

defecto aumentan a medida que se cambia de
prevención a detección, y desde fallos internos a
externos.
40-1000
veces
Costo relativo de corregir un error
30-70
veces
15-40
veces
10 veces
3-6 veces
1 vez
Prueba de Prueba de En fase de

Requisitos Diseño Código
desarrollo sistema explotación
Unidad 5 – Fiabilidad, disponibilidad y
seguridad
● Fallo: cualquier falta de concordancia con los

requisitos del SW:
● En el HW los fallos son más probables debido
al desgaste físico que al diseño
● En el SW los fallos se producen por problemas
de diseño o de implementación
● Fiabilidad: probabilidad de operación libre de

fallos en un entorno determinado y durante un
tiempo específico
seguridad
● La fiabilidad del SW es un elemento importante

de su calidad general: si falla frecuentemente en
su funcionamiento, no importa si el resto de los
factores de calidad son aceptables
● La fiabilidad del SW, a diferencia de otros

factores de calidad, puede ser medida o estimada
mediante datos históricos o de desarrollo
seguridad
● Una medida de la fiabilidad es el tiempo medio

entre fallos (TMEF):
● TMEF = TMDF + TMDR
● TMDF: tiempo medio de fallo
● TMDR: tiempo medio de reparación
● Muchos argumentan que el TMDF es una medida

más útil que los defectos/KSLOC o defectos/PF
porque el usuario final se enfrenta a los fallos, no
al número total de errores
seguridad
● Disponibilidad: probabilidad que el SW funcione

de acuerdo con los requisitos en un momento
dado:
● Disp = [TMDF / (TMEF)] x 100%
● La disponibilidad es una medida indirecta de la

facilidad de mantenimiento del SW
seguridad
● Antes que se usara SW en sistemas críticos de

seguridad, los mismos se controlaban mediante
dispositivos electrónicos y mecánicos (no
programables)
● Las técnicas de seguridad se diseñaban para

hacer frente a fallos aleatorios en estos
dispositivos
seguridad
● Cuando se utiliza SW como parte del sistema de

control, la complejidad puede aumentar en un
orden de magnitud o más
● La seguridad del SW se centra en la identificación

y evaluación de los riesgos potenciales que
podrían producir un impacto negativo y hacer
que falle el sistema completo
Unidad 5 – Gestión de la Calidad
● La Gestión de la Calidad se estructura en 3

actividades principales:
● Garantía de la calidad (SQA):
procedimientos y estándares que conducen a
SW de alta calidad
● Planificación de la calidad: selección de
procedimientos y estándares adecuados
● Control de calidad: inspecciones, revisiones
y pruebas a lo largo del proceso SW
Unidad 5 – Garantía de la Calidad
● Durante los años '50 y '60, la calidad era

responsabilidad únicamente del programador
● Luego, durante los '70 se introdujeron estándares

de garantía de calidad para el SW en los
contratos militares
● Estos estándares se extendieron rápidamente a

los desarrollos comerciales, con lo cual, muchos
de los que constituyen una organización tienen
responsabilidad sobre la garantía de calidad
● Los responsables de SQA miran al SW desde el

punto de vista del cliente:
● ¿Satisface de forma adecuada el SW los
factores de calidad?
● ¿Se ha realizado el desarrollo de acuerdo con

estándares preestablecidos?
● SQA es el proceso que define cómo lograr la

calidad del SW y cómo conoce la organización el
nivel de calidad requerido en el SW
● Se pueden definir 2 tipos de estándares:

● Estándares del producto
● Estándares del proceso
● Estándares del producto: se aplican sobre el

producto SW que se comienza a desarrollar.
Incluyen estándares de documentación, de
codificación, etc
● Estándares del proceso: definen los procesos

que se deben seguir durante el desarrollo del SW.
Se pueden incluir definiciones de procesos de
especificación, diseño y validación, así como una
descripción de los documentos que se deben
escribir en el curso de estos procesos
● Los estándares de SW son importantes porque:

● Están basados en el conocimiento de la mejor
o más apropiada práctica de la organización
● Proveen un marco de trabajo alrededor del cual

se implementa el proceso de garantía de la
calidad
● Ayudan a la continuidad cuando una persona

continúa el trabajo que llevaba a cabo otra
Unidad 5 – Planificación de la Calidad
● La planificación de la calidad es el proceso en el

cual se desarrolla un plan de calidad para un
proyecto, el cual define la calidad del SW
deseado y describe cómo valorar la misma
(define qué es “software de alta calidad”)
● El plan de calidad selecciona los estándares

organizacionales apropiados para un producto y
proceso de desarrollo particulares
● Estructura sugerida para un plan de calidad:

● Introducción al producto: descripción del
producto, el mercado al que se dirige y las
expectativas de calidad
● Planificación del producto: fechas de

terminación y las responsabilidades
importantes junto con los planes para la
distribución y el servicio

● Descripción de procesos: procesos a utilizar
para el desarrollo y administración del
producto
● Metas de calidad: metas y planes de calidad

para el producto
● Riesgos y gestión de riesgos: riesgos clave

que podrían afectar a la calidad del producto y
las acciones para abordarlos
● Hay una gran variedad de atributos de calidad

del SW a considerar en el proceso de
planificación de la calidad:
Seguridad Reutilización
Comprensión Flexibilidad
Portabilidad Modularidad
Protección Eficacia
Usabilidad Robustez
Fiabilidad Complejidad
Adaptabilidad Aprendizaje
● En general, no es posible optimizar todos los

atributos para un sistema: el plan de calidad
define los atributos de calidad más importantes
para el producto a desarrollar
Unidad 5 – Control de la Calidad
● El control de la calidad implica vigilar el proceso

de desarrollo para asegurar que se siguen los
procedimientos y los estándares de garantía de
calidad
● Existen 2 enfoques complementarios que se

utilizan para comprobar la calidad:
● Revisiones de la calidad
● Valoración automática del software
● Revisiones de la calidad: el SW, su

documentación y los procesos utilizados en su
desarrollo son revisados por un grupo de
personas:
● Se comprueba que se han seguido los
estándares del proyecto, y que el SW y los
documentos concuerdan con los mismos
● Se anotan las desviaciones de los estándares y

se comunican al gestor del proyecto
● Valoración automática del software: el

software y los documentos producidos se
procesan por algún programa y se comparan con
los estándares que se aplican a ese proyecto de
desarrollo en particular
● Esta valoración automática comprende una
medida cuantitativa de algunos atributos del
software
Unidad 5 – Actividades de la SQA
● Actividades de SQA recomendadas por el SEI:

● Planificar SQA para un proyecto
● Describir el proceso SW
● Revisar que las actividades de IS se ajustan al
proceso SW definido
● Documentar las desviaciones
● Auditar que los productos SW se ajusten como
parte del proceso SW
● Registrar e informar lo que no se ajuste a los
requisitos
● Planificar SQA para un proyecto. El plan se

desarrolla durante la planificación del proyecto y
se revisa por todas las partes interesadas
● El plan identifica:
● Evaluaciones a realizar
● Auditorías y revisiones a realizar
● Estándares que se pueden aplicar al proyecto
● Procedimientos para información y
seguimiento de errores
● Documentos producidos por el grupo SQA
● Describir el proceso SW. El equipo de IS

selecciona un proceso para el trabajo que se va a
realizar
● El grupo de SQA revisa que la descripción del

proceso se ajuste a la política de la empresa, los
estándares internos del SW, los estándares
impuestos externamente y a otras partes del plan
de proyecto del SW
● Revisar que las actividades de IS se ajustan

al proceso SW definido. El grupo de SQA
identifica y documenta las desviaciones del
proceso y verifica que se han hecho las
correcciones
● Documentar las desviaciones. Las

desviaciones se pueden encontrar en el plan del
proyecto, en la descripción del proceso, en los
estándares, etc
● Auditar que los productos SW se ajusten

como parte del proceso SW. El grupo de SQA
revisa los productos seleccionados; identifica,
documenta y lleva el control de las desviaciones;
verifica que se han hecho las correcciones, e
informa periódicamente al gestor del proyecto
● Registrar e informar lo que no se ajuste a

los requisitos. Los elementos que no se ajustan
a los requisitos están bajo seguimiento hasta que
se resuelven
● Además de estas actividades, el grupo de SQA

coordina el control y la gestión de cambios y
ayuda a recopilar y analizar las métricas del SW
Unidad 5 – Modelos de Calidad
calidad
● El proceso SW es genérico: el ideal que debería

seguir una organización para conseguir productos
de calidad
● En realidad, cada organización debe definir su

proceso SW para detectar si es adecuado o no y
cuánto dista del ideal
calidad
● El peor de los casos (muy frecuente) es una

organización que no sigue proceso alguno para
construir SW, y por lo tanto, no hay una guía para
construir SW
● Un equipo que sigue un proceso SW puede:

● Coordinar mejor el trabajo de cada miembro
● Seguir de un modo preciso los avances tanto

individuales como del equipo completo
calidad
● Un proceso SW:
● Ayuda a asegurar que cada elemento de
trabajo se asigne y se siga adecuadamente
● Es un mecanismo para un aprendizaje

ordenado
● Permite que cada proyecto nuevo sea

construido basado en su propia experiencia y
en anteriores
calidad
● Ventajas al definir un proceso SW:

● Se facilita la comunicación entre usuarios,
desarrolladores, gestores y clientes sobre el
proceso
● Se gana una mejor comprensión de la gestión
● Se brinda una base precisa para la
automatización del proceso
● Se facilita la movilidad de las personas dentro
del proceso
calidad

● Se facilita la reutilización del proceso: cada
proyecto nuevo no necesita redefinir
completamente su modo de trabajo
(estándares reutilizables)
● Ayuda a la gestión del proceso: provee planes

claros y un modo preciso y cuantificado de
comparar el estado con los planes
calidad
● Los procesos son difíciles de establecer, pero más

difíciles aún de cambiar
● Los procesos deben cambiar continuamente para

ser mejorados
● Conclusión: no es suficiente con definir el

proceso SW de una organización, sino que
además el mismo debe sufrir una mejora
permanente
Unidad 5 – CMM
● El SEI desarrolló un marco de madurez del

proceso software, el cual permite a las
organizaciones determinar las capacidades de
sus procesos actuales y definir prioridades de
mejoras
● Este marco de madurez definido por el SEI se

llama Modelo de Capacidad y Madurez o
Capability Maturity Model (CMM), y está
organizado en 5 niveles
Unidad 5 – CMM
Unidad 5 – CMM
● Para cada nivel se definen Áreas Clave de

Proceso (KPA), las cuales proporcionan los
objetivos y prácticas a alcanzar en cada nivel
● Se lo llama modelo de madurez porque propone

adoptar un conjunto de prácticas en forma
gradual: primero deben ponerse en práctica KPAs
pertenecientes a un nivel determinado, para
luego, sobre esta base, introducir las
correspondientes al nivel siguiente
Unidad 5 – CMM
● Nivel 1 – Inicial
● Representa una situación sin ningún esfuerzo
en la garantía de calidad y gestión del
proyecto, donde cada equipo puede desarrollar
SW de cualquier forma eligiendo distintos
métodos, estándares y procedimientos
● El proceso software es ad-hoc y,
ocasionalmente, incluso caótico. El éxito
depende del esfuerzo individual
● KPA: no tiene
Unidad 5 – CMM
● Nivel 2 – Repetible
● Están establecidos ciertos procesos básicos de
gestión de proyectos para seguir el costo, el
calendario y la funcionalidad
● Hay la disciplina necesaria para repetir éxitos
conseguidos con anterioridad
Unidad 5 – CMM
● KPA:
– Gestión de configuración
– Garantía de calidad
– Gestión de la subcontratación
– Seguimiento de proyectos
– Planificación de proyectos
– Gestión de requisitos
Unidad 5 – CMM
● Nivel 3 – Definido
● Representa el hecho de que un desarrollador
ha definido tanto procesos técnicos como de
gestión
● Por ejemplo se ha detallado un estándar para

la programación, y se hace cumplir por medio
de procedimientos tales como auditorías
Unidad 5 – CMM
● KPA:
– Revisiones profundas
– Coordinación entre grupos
– Ingeniería de la producción de software
– Gestión integrada en el proceso
– Programa de formación
– Definición del proceso
– Focalización en el proceso
Unidad 5 – CMM
● Nivel 4 – Gestionado
● Comprende el concepto de medición y el uso
de métricas
● Estas métricas proporcionan alguna indicación
del esfuerzo necesario para probar el código
● Una organización de nivel 4 maneja numerosas
métricas, las cuales se utilizan para supervisar
y controlar un proyecto SW
Unidad 5 – CMM
● KPA:
– Gestión de la calidad
– Gestión cualitativa del proceso
Unidad 5 – CMM
● Nivel 5 – Optimizado
● Representa la analogía del SW con los
mecanismos de control de calidad que existen
en otras industrias de mayor madurez
● Un desarrollador de SW de nivel 5 puede

predecir resultados basado en la medición
tomada durante la ejecución de un proyecto
Unidad 5 – CMM
● KPA:
– Gestión de cambio de proceso
– Gestión de cambio de tecnología
– Prevención de defectos
Unidad 5 – CMM
● El CMM ha sido revisado y refinado por muchos

especialistas para ponerse de acuerdo en los
métodos más efectivos para alcanzar los
objetivos de cada nivel de madurez
Unidad 5 – CMMI
● El modelo de capacidad y madurez

integrado (CMMI) es un modelo de referencia o
conjunto de prácticas enfocadas a mejorar los
procesos de una organización
● El modelo utiliza el paradigma de mejora del

proceso ya que el mismo no solo refleja el estado
del arte del proceso SW, también permite
establecer metas y prioridades para la mejora del
proceso, estableciendo un plan centrado en la
medición y cuantificación objetiva de los mismos
Unidad 5 – CMMI
● El propósito de CMMI para desarrollo es ayudar a

las organizaciones a mejorar sus procesos de
desarrollo de productos
● Consiste en definir las mejores prácticas que

tratan las actividades de desarrollo
comprendiendo el ciclo de vida completo del
producto, desde la concepción hasta la entrega y
mantenimiento del mismo, adaptándose
completamente la aplicación del modelo a la
organización
Unidad 5 – CMMI
● La estrategia adoptada por CMMI produce

beneficios operativos:
● Reducción de costo y tiempo de entrega
● Mayor productividad
● Menores tiempos de desarrollo
● Disminución del retrabajo y errores
● Mayor calidad del producto y satisfacción del
cliente.
Unidad 5 – CMMI
● Al igual que CMM, fue creado por el SEI con la

colaboración de la industria, el gobierno y el
ámbito académico, con el fin de unir una gran
cantidad de modelos existentes
● En la actualidad hay 3 áreas de interés cubiertas

por los modelos de CMMI:
● Desarrollo (CMMI-DEV)
● Adquisición (CMMI-ACQ)
● Servicios (CMMI-SVC)
Unidad 5 – CMMI
● CMMI-DEV: guías para medir, monitorizar y

administrar el proceso de desarrollo
● CMMI-ACQ: guías para el proceso de adquisición

de productos y servicios
● CMMI-SVC: guías para proporcionar servicios en

una organización y a clientes externos
Unidad 5 – Revisiones de Software
● Las revisiones de software son un "filtro" para el

proceso de IS
● Las revisiones se aplican en varios momentos del
desarrollo y sirven para detectar errores y
defectos que puedan ser eliminados
● También, se necesitan revisiones porque aunque
la gente es buena descubriendo algunos de sus
propios errores, algunas clases de errores le
pasan por alto más fácilmente al que los origina
que a otras personas
● Una revisión es una forma de aprovechar la

diversidad de un grupo de personas para:
● Señalar la necesidad de mejoras (en el
producto) de una sola persona o un equipo
● Confirmar las partes de un producto en las que
no es necesaria o no es deseable una mejora
● Conseguir un trabajo técnico de una calidad
más uniforme, o al menos más predecible, que
la que puede ser conseguida sin revisiones
● Existen muchos tipos diferentes de revisiones

que se pueden llevar adelante como parte de la
IS:
● Una reunión informal es una forma de revisión
(si se discuten problemas técnicos)
● Una presentación formal de un diseño de
software a una audiencia de clientes,
ejecutivos y personal técnico es una forma de
revisión
● Una revisión técnica formal (RTF), a veces

denominada inspección, es el filtro más efectivo
desde el punto de vista de garantía de calidad
● La RTF es un medio efectivo para mejorar la

calidad del SW
● El objetivo primario de las RTF es encontrar

errores durante el proceso, de forma que no se
conviertan en defectos después de la entrega
Unidad 5 – RTF
● Los objetivos de una RTF son:

● Descubrir errores en la función, la lógica o la
implementación de cualquier representación
del SW
● Verificar que el SW alcanza sus requisitos
● Garantizar que el SW ha sido representado de
acuerdo a estándares predefinidos
● Conseguir un SW desarrollado de forma
uniforme
● Hacer que los proyectos sean más manejables
Unidad 5 – RTF
● La RTF también sirve para promover la seguridad

y la continuidad, ya que varias personas se
familiarizarán con partes del SW que, de otro
modo, no hubieran visto nunca
Unidad 5 – RTF
● Cada RTF se lleva a cabo mediante una reunión

● Cualquier reunión de revisión debe seguir las
siguientes restricciones:
● Se deben convocar entre 3 y 5 personas
● Se debe preparar por adelantado, pero sin que
requiera más de 2 horas de trabajo a cada
persona
● La duración de la reunión debe ser menor de 2
horas
Unidad 5 – RTF
● Cada RTF se centra en una parte específica (y

chica) del SW total
● Por ejemplo, en lugar de intentar revisar un

diseño completo, se hacen inspecciones a cada
módulo o pequeño grupo de módulos
● Al limitar el centro de atención de la RTF, la

probabilidad de descubrir errores es mayor
Unidad 5 – RTF
● La persona que desarrolló un producto

(productor) informa al jefe del proyecto que el
mismo está terminado y que requiere una
revisión
● El jefe del proyecto contacta con un jefe de
revisión, que evalúa la disponibilidad del
producto, genera copias del mismo y las
distribuye a 2 o 3 revisores para que se preparen
por adelantado
● Cada revisor estará entre 1 y 2 horas revisando el
producto, tomando notas y también
familiarizándose con el trabajo
Unidad 5 – RTF
● De forma concurrente, también el jefe de revisión

revisará el producto y establecerá una agenda
para la reunión de revisión que, normalmente,
queda convocada para el día siguiente
● La reunión de revisión es llevada a cabo por el

jefe de revisión, los revisores y el productor. Uno
de los revisores registra de forma escrita todos
los sucesos importantes que se produzcan
durante la revisión
Unidad 5 – RTF
● La RTF comienza con una explicación de la

agenda y una breve introducción a cargo del
productor
● El productor explica el material, mientras que los

revisores exponen los resultados de sus
revisiones basándose en su preparación previa
● Cuando se descubren problemas o errores

válidos, el que registra los va anotando
Unidad 5 – RTF
● Al final de la revisión, todos los participantes en

la RTF deben decidir si:
● Aceptan el producto sin posteriores
modificaciones
● Rechazan el producto debido a los serios
errores encontrados (una vez corregidos, ha de
hacerse otra revisión)
● Aceptan el producto provisoriamente (se han
encontrado errores menores que deben ser
corregidos, pero sin necesidad de otra revisión
posterior)
Unidad 5 – RTF
● Una vez tomada la decisión, todos los

participantes terminan firmando, indicando así
que han participado en la revisión y que están de
acuerdo con las conclusiones del equipo de
revisión
Unidad 5 – RTF
● Al final de la reunión se prepara un informe, el

cual responde a 3 preguntas:
● ¿Qué fue revisado?
● ¿Quién lo revisó?
● ¿Qué se descubrió y cuáles son las
conclusiones?
● El informe es una página simple (con posibles
suplementos). Se adjunta al registro histórico del
proyecto y puede ser enviada al jefe del proyecto
y a otras partes interesadas
Unidad 5 – RTF
● Se deben establecer de antemano directrices

para conducir las RTF, distribuyéndolas después
entre los revisores, para ser consensuadas y,
finalmente, seguidas
● Frecuentemente, una revisión incontrolada puede

ser peor que no hacer ningún tipo de revisión
Unidad 5 – RTF
● Revisar el producto, no al productor. Una

RTF involucra gente y egos. Se deben señalar los
errores educadamente; el tono de la reunión
debe ser distendido y constructivo; no debe
intentarse dificultar o batallar
● Fijar una agenda y mantenerla. Un mal de las

reuniones de todo tipo es la deriva. La RTF debe
seguir un plan de trabajo concreto. El jefe de
revisión es el responsable de mantener el plan de
la reunión
Unidad 5 – RTF
● Limitar el debate y las impugnaciones.

Cuando un revisor ponga de manifiesto otro tipo
de problema, podrá no haber unanimidad sobre
su impacto. En lugar de perder el tiempo
debatiendo la cuestión, debe registrarse el hecho
y dejar que la cuestión se lleve a cabo en otro
momento
● Tomar notas escritas. A veces es buena idea
que el que registra tome las notas en una pizarra,
de forma que las declaraciones o la asignación de
prioridades pueda ser comprobada por el resto
de los revisores
Unidad 5 – RTF
● Enunciar áreas de problemas, pero no

intentar resolver cualquier problema que se
ponga de manifiesto. Una revisión no es una
sesión de resolución de problemas. La resolución
de los problemas debe ser pospuesta para
después de la reunión de revisión
● Disponer recursos y una agenda para las

RTF. Para que las revisiones sean efectivas, se
deben planificar
Unidad 5 – RTF
● Limitar el número de participantes e insistir

en la preparación anticipada. 2 personas son
mejores que 1, pero 14 no son necesariamente
mejores que 4. Se ha de mantener el número de
participantes en el mínimo necesario
● Desarrollar una lista de comprobación para

cada producto que haya de ser revisado.
Una lista de comprobaciones ayuda al jefe de
revisión a estructurar la reunión y ayuda a cada
revisor a centrarse en los asuntos importantes
Unidad 5 – RTF
● Repasar las revisiones anteriores. Las

sesiones de información pueden ser beneficiosas
para descubrir problemas en el propio proceso de
revisión. El primer producto que se haya revisado
puede establecer las propias directivas de
revisión
● Llevar a cabo un buen entrenamiento de

todos los revisores. Por razones de efectividad,
todos los participantes en la revisión deben
recibir algún entrenamiento formal
Unidad 5 – RTF
● Como existen muchas variables (número de

participantes, tipo de productos de trabajo,
tiempo y duración, enfoque de revisión
específico) que tienen impacto en una revisión
satisfactoria, una organización deberá determinar
qué método funciona mejor en un contexto local
Unidad 5 – Pruebas del Software
software
● El proceso de pruebas comienza con la prueba de

unidades: funciones, objetos, etc
● Luego estas unidades se integran en subsistemas

y sistemas y se prueban las interacciones entre
los mismos
● Finalmente, después de entregar el sistema, el

cliente puede llevar a cabo una serie de pruebas
de aceptación para comprobar que el mismo
funciona como se especificó
software
● Este modelo de pruebas es apropiado para el

desarrollo de sistemas grandes, pero para
sistemas más chicos a veces se distinguen
menos etapas en el proceso:
Pruebas del Pruebas de

componente integración
software
● Prueba de componentes: probar las partes del

sistema. Busca descubrir defectos probando
componentes individuales (funciones, objetos,
componentes reutilizables, etc)
● Prueba del sistema: probar el sistema como un

todo. Busca establecer que el sistema satisface
sus requerimientos funcionales, y no se comporta
de forma inesperada
software
● El proceso de pruebas tiene 2 objetivos distintos:

● Demostrar al desarrollador y al cliente que el
SW satisface sus requerimientos
● Descubrir defectos en el SW (comportamiento

incorrecto o no deseable, incumplimiento de su
especificación, etc)
software
● El primer objetivo conduce a las pruebas de

validación (se espera que el sistema funcione
correctamente usando un conjunto determinado de
casos de prueba)
● Una prueba de validación exitosa demuestra
que el sistema funciona correctamente
● El segundo objetivo conduce a las pruebas de

defectos (los casos de prueba se diseñan para
exponer los defectos)
● Una prueba de defectos exitosa demuestra un
defecto en el sistema
software
● Las pruebas no pueden demostrar que el SW está

libre de defectos o que se comportará en todo
momento como está especificado:
● Las pruebas sólo pueden demostrar la

presencia de errores, no su ausencia
● El objetivo de las pruebas es convencer a los

desarrolladores y a los clientes que el SW es lo
suficientemente bueno para uso operacional
software
● Modelo general del proceso de pruebas:
Resultados de Informe de la
Casos de prueba Datos de prueba
la prueba prueba
Ejecutar el programa Comparar resultados

Diseñar casos de Preparar datos de
con los datos de con los datos de
prueba prueba
prueba prueba
software
● Casos de prueba: especificaciones de las

entradas para las pruebas y la salida esperada
del sistema (no se pueden generar
automáticamente)
● Datos de prueba: entradas que han sido

ideadas para probar el sistema (a veces pueden
generarse automáticamente)
software
● Es imposible probar cada posible secuencia de

ejecución del programa, por lo que las pruebas
tienen que basarse en un subconjunto de
posibles casos de prueba:
● Probar todas las funciones a las que se accede
a través de menús
● Probar todas las combinaciones de funciones
● Probar todas las funciones con datos correctos
e incorrectos
software
● Los gestores deciden quién será responsable de

las diferentes etapas de pruebas:
● Generalmente, los programadores tienen la
responsabilidad de probar sus componentes
● Una vez que lo hacen, el trabajo se pasa a un

equipo de integración que integra los módulos
de diferentes desarrolladores, construye el SW
y prueba el sistema como un todo
Unidad 5 – Pruebas de Componentes
● Pruebas de componentes (de unidad)

● Consisten en probar los componentes
individuales en el sistema
● Su objetivo es encontrar defectos en los

componentes del sistema
● Tipos de componentes:
● Funciones/métodos dentro de un objeto
● Clases con varios atributos y métodos
● Componentes formados por diferentes objetos

o funciones (se accede a su funcionalidad
mediante una interfaz)
● Cuando se prueban métodos se los llama con

diferentes parámetros de entrada (correctos e
incorrectos)
● Al probar las clases se deben cubrir todas sus

características:
● Todos sus métodos
● Asignación y consulta de todos sus atributos
● Comportamiento del objeto en todos sus
posibles estados
● Muchos componentes están formados por varios

objetos, accediendo a sus funcionalidades por
medio de sus interfaces
● Las pruebas de estos componentes se ocupan

principalmente de probar que la interfaz del
componente se comporta de acuerdo con su
especificación
Unidad 5 – Pruebas del sistema
● Las pruebas del sistema implican integrar y

probar 2 o más componentes que implementan
funciones o características del sistema:
● En un desarrollo iterativo, estas pruebas
prueban un incremento que va a ser entregado
al cliente
● En un desarrollo en cascada, estas pruebas

prueban el sistema completo
● Para la mayoría de los sistemas complejos,

existen 2 fases distintas de pruebas del sistema:
Unidad
Unidad5 5– –Pruebas
Pruebasde
del
integración
sistema
● Se tiene acceso al código fuente (pruebas de
caja blanca)
● Cuando se descubre un problema, se intenta

encontrar el origen del mismo e identificar los
componentes que tienen que ser depurados
● Se ocupan principalmente de encontrar

defectos en el sistema
Unidad 5 – Pruebas de integración
● El proceso de integración implica construir un

sistema a partir de sus componentes y probar el
mismo para encontrar problemas que pueden
surgir debido a la integración
● Las pruebas de integración comprueban que

estos componentes realmente funcionan juntos,
son llamados correctamente y transfieren los
datos correctos en el tiempo preciso a través de
sus interfaces
● La principal dificultad es la localización de los

errores
● Esto implica que cuando se integra un nuevo

incremento, es importante volver a ejecutar las
pruebas para incrementos previos, así como las
nuevas pruebas requeridas para verificar la
nueva funcionalidad del sistema
● Volver a ejecutar un conjunto existente de

pruebas se denomina pruebas de regresión
Unidad 5 – Pruebas de entregas
● Se prueba una versión del sistema que podría
ser entregada a los usuarios (suelen ser de
caja negra)
● Se valida que el sistema satisface sus

requerimientos y que es confiable
● Cuando los clientes se involucran se las suele

llamar pruebas de aceptación
● Prueban una entrega del sistema que será

distribuida a los clientes
● El principal objetivo es demostrar que el sistema

satisface sus requerimientos:
● Demostrar que el sistema entrega la
funcionalidad especificada
● Demostrar que el sistema tiene el rendimiento
especificado
● Demostrar que el sistema no falla durante su
uso normal
● Cuando se prueban las entregas del sistema, se

debe intentar “romper” el SW:
● Elegir entradas que fuerzan que el sistema
genere todos los mensajes de error
● Diseñar entradas que hacen que los buffers de
entrada se desborden
● Repetir la misma entrada varias veces
● Forzar a que se generen las salidas inválidas
● Forzar los resultados de los cálculos para que
sean muy grandes o muy pequeños
Unidad 5 – Pruebas de rendimiento
● Una vez que un sistema se ha integrado

completamente, es posible probar las
propiedades emergentes del mismo, como el
rendimiento y la fiabilidad
● Las pruebas de rendimiento se diseñan para

asegurar que el sistema puede procesar su carga
esperada
● Como sucede con otros tipos de pruebas, las

pruebas de rendimiento se ocupan tanto de
demostrar que el sistema satisface sus
requerimientos como de descubrir problemas y
defectos en el mismo
● Las pruebas de rendimiento implican estresar el

sistema realizando demandas que están fuera de
los límites del diseño del SW
● Estos tipos de pruebas tienen 2 funciones:

● Sobrecargar el sistema y poder provocar que
se manifiesten defectos que normalmente no
serían descubiertos
● Probar el comportamiento de fallo de ejecución

del sistema. Pueden aparecer circunstancias a
través de una combinación no esperada de
eventos en donde la carga sobre el sistema
supere la carga máxima anticipada
Unidad 5 – Diseño de casos de prueba
● En el diseño de casos de prueba se diseñan las

entradas y salidas esperadas para probar el
sistema
● El objeto es crear un conjunto de casos de prueba

que sean efectivos descubriendo defectos en los
programas y mostrando que el sistema satisface
sus requerimientos
● Diseño de un caso de prueba:

● Se selecciona una característica del sistema o
componente a probar
● Se selecciona un conjunto de entradas que

ejecutan dicha característica, se documentan
las salidas esperadas, y si es posible se diseña
una prueba automatizada que pruebe que las
salidas reales y esperadas son las mismas
● Enfoques que se pueden seguir para diseñar

casos de prueba:
● Pruebas basadas en requerimientos
● Pruebas de particiones
● Pruebas estructurales
● Pruebas de caminos

● Se diseñan los casos de prueba para probar los
requerimientos del sistema
● Se utiliza para las pruebas del sistema
● Son pruebas de validación en lugar de pruebas

de defectos: se intenta demostrar que el
sistema ha implementado sus requerimientos
de forma adecuada

● Los requerimientos deben poder probarse, por
lo que se los debe escribir de tal forma que se
pueda diseñar una prueba que permita
comprobar que los requerimientos se
satisfacen
● Los datos de E/S se pueden agrupar por
características comunes:
– Números positivos
– Números negativos
– Selecciones de menús
● A estas características o categorías se las

denomina particiones o dominios
● Se identifican todas las particiones para un
sistema o componente (los casos de prueba se
diseñan para que las E/S pertenezcan a estas
particiones)
● Una buena práctica es elegir los límites de las

particiones junto con los valores cercanos al
punto medio de la partición (entradas válidas e
inválidas)
● Con la estructura del programa, se diseñan
pruebas que ejecuten todas sus partes:
– Probar que cada sentencia se ejecuta al
menos una vez
● También se las llama “pruebas de caja blanca"
● La comprensión de la estructura del programa

ayuda a identificar particiones adicionales
● Estrategia para las pruebas estructurales
● Su objetivo es asegurar que cada camino

independiente en el programa o componente
se ejecuta al menos una vez:
– Si se prueba cada camino, todas las
sentencias del programa o componente se
habrán ejecutado al menos una vez
● La cantidad de caminos es un programa es
proporcional a su tamaño
● Como los distintos módulos se van integrando,

no se pueden usar estas pruebas (se las usa en
las pruebas de componente)
● Las pruebas de caminos no prueban todas las
posibles combinaciones de todos los caminos
(en programas con lazos hay un número
infinito de posibles combinaciones de caminos)
● Para diseñar estas pruebas se arma un grafo

de flujo del programa:
– Nodos: decisiones
– Aristas: flujo de control
public void busquedaBinaria(int clave, int[] array, Resultado r) {

int limInf = 0; //1
1
int limSup = array.length – 1; //2
int medio;
2
r.setIndice(-1); //3
r.setEncontrado(false); //4 3
while (limInf <= limSup) { //5
medio = (limInf + limSup) / 2; //6
4
if (array[medio] == clave) { //7
r.setIndice(medio); //8 limInf > 5 while (limInf <=
r.setEncontrado(true); //9 limSup limSup)
return; //10
}
6
else { array[medio]
7 != clave 11
if (array[medio] > clave) //11
array[medio]
limSup = medio – 1; //12
= clave 8 array[medio]
else > clave
limInf = medio + 1; //13 9 12 13
}
} 14 10
} IS Unidad 5 Luis Nieto 2018 //14 119
● Los caminos en el grafo son:
– 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
– 1, 2, 3, 4, 5, 14
– 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, ...
– 1, 2, 3, 4, 5, 6, 7, 11, 13, 5, ...
● Si se ejecutan todos estos caminos, se puede

asegurar que cada sentencia se ejecuta al
menos una vez, y que cada rama se ejecuta
para las condiciones verdadera y falsa
● Para encontrar el número de caminos
independientes se puede calcular la
complejidad ciclomática del grafo:
– Condición simple: expresión lógica sin
conectores “AND” u “OR”
– Condición compuesta: expresión lógica

con conectores “AND” u “OR”
● Cálculo de la complejidad ciclomática (para
programas sin sentencias GOTO):
– Es 1 más que el número de condiciones
(simples)
– Si hay condiciones compuestas, se cuenta el

número de condiciones simples en las
compuestas
● Ejemplo: programa con 6 sentencias IF, 1 lazo
WHILE y todas expresiones condicionales
simples:
– Complejidad ciclomática = 8
● Si una de las expresiones condicionales es de

la forma “IF A AND B OR C”, esto cuenta
como 3 expresiones simples (A, B y C):
● Para el algoritmo de búsqueda binaria:
– while (limiteInferior <= limiteSuperior) { //5
– if (array[medio] == clave) { //7
– if (array[medio] > clave) //11
● Complejidad ciclomática = 4
● Cantidad de caminos independientes = 4
● Luego de obtener la cantidad de caminos
independientes se diseñan los casos de prueba
para ejecutarlos
● El número mínimo de casos de prueba

necesarios para probar todos los caminos es
igual a la complejidad ciclomática

● Conceptos de calidad
● Fiabilidad, disponibilidad y seguridad
● Gestión de la calidad
● Garantía de la calidad
● Planificación de la calidad
● Control de la calidad
● Actividades de la SQA

● Modelos de calidad
● CMM
● CMMI
● Revisiones de software
● Revisiones Técnicas Formales (RTF)

● Pruebas del software

● Pruebas de componentes
● Pruebas del sistema
● Pruebas de rendimiento
● Diseño de casos de prueba

● Para productos tangibles, la calidad depende de

la similitud entre el producto desarrollado y su
especificación
● El control de variación es la base del control de

calidad: se quiere reducir la variación entre los
productos que se fabrican

● En el SW el esfuerzo se centra en controlar la

variación en:
● el proceso que se aplica
● los recursos que se consumen
● los atributos de calidad del producto final
● En el SW se quiere reducir la diferencia entre los

recursos planificados y los reales utilizados

● Calidad: “característica o atributo de algo”

● Como un atributo de un elemento, la calidad se
refiere a las características medibles: cosas
que se pueden comparar con estándares
conocidos: longitud, color, etc
● El SW es más difícil de caracterizar que los

objetos físicos. Algunas propiedades:
complejidad, cohesión, número de puntos de
función, líneas de código, etc

● satisfacción del usuario = producto

satisfactorio + buena calidad + entrega
dentro de presupuesto y tiempo
establecidos
● La calidad es importante, pero si el usuario no
queda satisfecho nada más importa
● Esta visión de la calidad establece que si el
producto SW proporciona un beneficio sustancial
a los usuarios finales, éstos pueden estar
dispuestos a tolerar problemas ocasionales de
rendimiento o fiabilidad

● El costo de la calidad incluye todos los costos

acarreados en la búsqueda de calidad o en las
actividades relacionadas con la obtención de
calidad
● Los costos de calidad están asociados con:

● Prevención
● Evaluación
● Fallos

● Prevención: planificación, revisiones técnicas

formales, equipo de pruebas y formación
● Evaluación: actividades para tener una visión

más profunda de la condición del producto. Por
ejemplo: inspección del proceso, mantenimiento
del equipo, pruebas

● Fallos: se dividen en:

● Costos internos: se producen cuando se
detecta un error en el producto antes de su
envío (retrabajo o revisión, reparación, análisis
de las modalidades de fallos, etc)
● Costos externos: debido a defectos

encontrados una vez enviado el producto al
cliente (resolución de quejas, devolución y
sustitución de productos, soporte de línea de
ayuda, trabajo de garantía)

● Los costos relativos para encontrar y reparar un

defecto aumentan a medida que se cambia de
prevención a detección, y desde fallos internos a
externos.
40-1000
veces
Costo relativo de corregir un error
30-70
veces
15-40
veces
10 veces
3-6 veces
1 vez
Prueba de Prueba de En fase de

Requisitos Diseño Código
desarrollo sistema explotación


seguridad
● Fallo: cualquier falta de concordancia con los

requisitos del SW:
● En el HW los fallos son más probables debido
al desgaste físico que al diseño
● En el SW los fallos se producen por problemas
de diseño o de implementación
● Fiabilidad: probabilidad de operación libre de

fallos en un entorno determinado y durante un
tiempo específico


seguridad
● La fiabilidad del SW es un elemento importante

de su calidad general: si falla frecuentemente en
su funcionamiento, no importa si el resto de los
factores de calidad son aceptables
● La fiabilidad del SW, a diferencia de otros

factores de calidad, puede ser medida o estimada
mediante datos históricos o de desarrollo


seguridad
● Una medida de la fiabilidad es el tiempo medio

entre fallos (TMEF):
● TMEF = TMDF + TMDR
● TMDF: tiempo medio de fallo
● TMDR: tiempo medio de reparación
● Muchos argumentan que el TMDF es una medida

más útil que los defectos/KSLOC o defectos/PF
porque el usuario final se enfrenta a los fallos, no
al número total de errores


seguridad
● Disponibilidad: probabilidad que el SW funcione

de acuerdo con los requisitos en un momento
dado:
● Disp = [TMDF / (TMEF)] x 100%
● La disponibilidad es una medida indirecta de la

facilidad de mantenimiento del SW


seguridad
● Antes que se usara SW en sistemas críticos de

seguridad, los mismos se controlaban mediante
dispositivos electrónicos y mecánicos (no
programables)
● Las técnicas de seguridad se diseñaban para

hacer frente a fallos aleatorios en estos
dispositivos


seguridad
● Cuando se utiliza SW como parte del sistema de

control, la complejidad puede aumentar en un
orden de magnitud o más
● La seguridad del SW se centra en la identificación

y evaluación de los riesgos potenciales que
podrían producir un impacto negativo y hacer
que falle el sistema completo

Unidad 5 – Gestión de la Calidad
● La Gestión de la Calidad se estructura en 3

actividades principales:
● Garantía de la calidad (SQA):
procedimientos y estándares que conducen a
SW de alta calidad
● Planificación de la calidad: selección de
procedimientos y estándares adecuados
● Control de calidad: inspecciones, revisiones
y pruebas a lo largo del proceso SW

● Durante los años '50 y '60, la calidad era

responsabilidad únicamente del programador
● Luego, durante los '70 se introdujeron estándares

de garantía de calidad para el SW en los
contratos militares
● Estos estándares se extendieron rápidamente a

los desarrollos comerciales, con lo cual, muchos
de los que constituyen una organización tienen
responsabilidad sobre la garantía de calidad

● Los responsables de SQA miran al SW desde el

punto de vista del cliente:
● ¿Satisface de forma adecuada el SW los
factores de calidad?
● ¿Se ha realizado el desarrollo de acuerdo con

estándares preestablecidos?

● SQA es el proceso que define cómo lograr la

calidad del SW y cómo conoce la organización el
nivel de calidad requerido en el SW
● Se pueden definir 2 tipos de estándares:

● Estándares del producto
● Estándares del proceso

● Estándares del producto: se aplican sobre el

producto SW que se comienza a desarrollar.
Incluyen estándares de documentación, de
codificación, etc
● Estándares del proceso: definen los procesos

que se deben seguir durante el desarrollo del SW.
Se pueden incluir definiciones de procesos de
especificación, diseño y validación, así como una
descripción de los documentos que se deben
escribir en el curso de estos procesos

● Los estándares de SW son importantes porque:

● Están basados en el conocimiento de la mejor
o más apropiada práctica de la organización
● Proveen un marco de trabajo alrededor del cual

se implementa el proceso de garantía de la
calidad
● Ayudan a la continuidad cuando una persona

continúa el trabajo que llevaba a cabo otra

● La planificación de la calidad es el proceso en el

cual se desarrolla un plan de calidad para un
proyecto, el cual define la calidad del SW
deseado y describe cómo valorar la misma
(define qué es “software de alta calidad”)
● El plan de calidad selecciona los estándares

organizacionales apropiados para un producto y
proceso de desarrollo particulares


● Introducción al producto: descripción del
producto, el mercado al que se dirige y las
expectativas de calidad
● Planificación del producto: fechas de

terminación y las responsabilidades
importantes junto con los planes para la
distribución y el servicio


● Descripción de procesos: procesos a utilizar
para el desarrollo y administración del
producto
● Metas de calidad: metas y planes de calidad

para el producto
● Riesgos y gestión de riesgos: riesgos clave

que podrían afectar a la calidad del producto y
las acciones para abordarlos

● Hay una gran variedad de atributos de calidad

del SW a considerar en el proceso de
planificación de la calidad:
Seguridad Reutilización
Comprensión Flexibilidad
Portabilidad Modularidad
Protección Eficacia
Usabilidad Robustez
Fiabilidad Complejidad
Adaptabilidad Aprendizaje

● En general, no es posible optimizar todos los

atributos para un sistema: el plan de calidad
define los atributos de calidad más importantes
para el producto a desarrollar

● El control de la calidad implica vigilar el proceso

de desarrollo para asegurar que se siguen los
procedimientos y los estándares de garantía de
calidad
● Existen 2 enfoques complementarios que se

utilizan para comprobar la calidad:
● Revisiones de la calidad
● Valoración automática del software

● Revisiones de la calidad: el SW, su

documentación y los procesos utilizados en su
desarrollo son revisados por un grupo de
personas:
● Se comprueba que se han seguido los
estándares del proyecto, y que el SW y los
documentos concuerdan con los mismos
● Se anotan las desviaciones de los estándares y

se comunican al gestor del proyecto

● Valoración automática del software: el

software y los documentos producidos se
procesan por algún programa y se comparan con
los estándares que se aplican a ese proyecto de
desarrollo en particular
● Esta valoración automática comprende una
medida cuantitativa de algunos atributos del
software

● Actividades de SQA recomendadas por el SEI:

● Planificar SQA para un proyecto
● Describir el proceso SW
● Revisar que las actividades de IS se ajustan al
proceso SW definido
● Documentar las desviaciones
● Auditar que los productos SW se ajusten como
parte del proceso SW
● Registrar e informar lo que no se ajuste a los
requisitos

● Planificar SQA para un proyecto. El plan se

desarrolla durante la planificación del proyecto y
se revisa por todas las partes interesadas
● El plan identifica:
● Evaluaciones a realizar
● Auditorías y revisiones a realizar
● Estándares que se pueden aplicar al proyecto
● Procedimientos para información y
seguimiento de errores
● Documentos producidos por el grupo SQA

● Describir el proceso SW. El equipo de IS

selecciona un proceso para el trabajo que se va a
realizar
● El grupo de SQA revisa que la descripción del

proceso se ajuste a la política de la empresa, los
estándares internos del SW, los estándares
impuestos externamente y a otras partes del plan
de proyecto del SW

● Revisar que las actividades de IS se ajustan

al proceso SW definido. El grupo de SQA
identifica y documenta las desviaciones del
proceso y verifica que se han hecho las
correcciones
● Documentar las desviaciones. Las

desviaciones se pueden encontrar en el plan del
proyecto, en la descripción del proceso, en los
estándares, etc

● Auditar que los productos SW se ajusten

como parte del proceso SW. El grupo de SQA
revisa los productos seleccionados; identifica,
documenta y lleva el control de las desviaciones;
verifica que se han hecho las correcciones, e
informa periódicamente al gestor del proyecto
● Registrar e informar lo que no se ajuste a

los requisitos. Los elementos que no se ajustan
a los requisitos están bajo seguimiento hasta que
se resuelven

● Además de estas actividades, el grupo de SQA

coordina el control y la gestión de cambios y
ayuda a recopilar y analizar las métricas del SW


calidad
● El proceso SW es genérico: el ideal que debería

seguir una organización para conseguir productos
de calidad
● En realidad, cada organización debe definir su

proceso SW para detectar si es adecuado o no y
cuánto dista del ideal


calidad
● El peor de los casos (muy frecuente) es una

organización que no sigue proceso alguno para
construir SW, y por lo tanto, no hay una guía para
construir SW
● Un equipo que sigue un proceso SW puede:

● Coordinar mejor el trabajo de cada miembro
● Seguir de un modo preciso los avances tanto

individuales como del equipo completo


calidad
● Un proceso SW:
● Ayuda a asegurar que cada elemento de
trabajo se asigne y se siga adecuadamente
● Es un mecanismo para un aprendizaje

ordenado
● Permite que cada proyecto nuevo sea

construido basado en su propia experiencia y
en anteriores


calidad

● Se facilita la comunicación entre usuarios,
desarrolladores, gestores y clientes sobre el
proceso
● Se gana una mejor comprensión de la gestión
● Se brinda una base precisa para la
automatización del proceso
● Se facilita la movilidad de las personas dentro
del proceso


calidad

● Se facilita la reutilización del proceso: cada
proyecto nuevo no necesita redefinir
completamente su modo de trabajo
(estándares reutilizables)
● Ayuda a la gestión del proceso: provee planes

claros y un modo preciso y cuantificado de
comparar el estado con los planes


calidad
● Los procesos son difíciles de establecer, pero más

difíciles aún de cambiar
● Los procesos deben cambiar continuamente para

ser mejorados
● Conclusión: no es suficiente con definir el

proceso SW de una organización, sino que
además el mismo debe sufrir una mejora
permanente

Unidad 5 – CMM
● El SEI desarrolló un marco de madurez del

proceso software, el cual permite a las
organizaciones determinar las capacidades de
sus procesos actuales y definir prioridades de
mejoras
● Este marco de madurez definido por el SEI se

llama Modelo de Capacidad y Madurez o
Capability Maturity Model (CMM), y está
organizado en 5 niveles

Unidad 5 – CMM

Unidad 5 – CMM
● Para cada nivel se definen Áreas Clave de

Proceso (KPA), las cuales proporcionan los
objetivos y prácticas a alcanzar en cada nivel
● Se lo llama modelo de madurez porque propone

adoptar un conjunto de prácticas en forma
gradual: primero deben ponerse en práctica KPAs
pertenecientes a un nivel determinado, para
luego, sobre esta base, introducir las
correspondientes al nivel siguiente

Unidad 5 – CMM
● Nivel 1 – Inicial
● Representa una situación sin ningún esfuerzo
en la garantía de calidad y gestión del
proyecto, donde cada equipo puede desarrollar
SW de cualquier forma eligiendo distintos
métodos, estándares y procedimientos
● El proceso software es ad-hoc y,
ocasionalmente, incluso caótico. El éxito
depende del esfuerzo individual
● KPA: no tiene

Unidad 5 – CMM
● Están establecidos ciertos procesos básicos de
gestión de proyectos para seguir el costo, el
calendario y la funcionalidad
● Hay la disciplina necesaria para repetir éxitos
conseguidos con anterioridad

Unidad 5 – CMM
● KPA:
– Gestión de configuración
– Garantía de calidad
– Gestión de la subcontratación
– Seguimiento de proyectos
– Planificación de proyectos
– Gestión de requisitos

Unidad 5 – CMM
● Representa el hecho de que un desarrollador
ha definido tanto procesos técnicos como de
gestión
● Por ejemplo se ha detallado un estándar para

la programación, y se hace cumplir por medio
de procedimientos tales como auditorías

Unidad 5 – CMM
● KPA:
– Revisiones profundas
– Coordinación entre grupos
– Ingeniería de la producción de software
– Gestión integrada en el proceso
– Programa de formación
– Definición del proceso
– Focalización en el proceso

Unidad 5 – CMM
● Comprende el concepto de medición y el uso
de métricas
● Estas métricas proporcionan alguna indicación
del esfuerzo necesario para probar el código
● Una organización de nivel 4 maneja numerosas
métricas, las cuales se utilizan para supervisar
y controlar un proyecto SW

Unidad 5 – CMM
● KPA:
– Gestión de la calidad
– Gestión cualitativa del proceso

Unidad 5 – CMM
● Representa la analogía del SW con los
mecanismos de control de calidad que existen
en otras industrias de mayor madurez
● Un desarrollador de SW de nivel 5 puede

predecir resultados basado en la medición
tomada durante la ejecución de un proyecto

Unidad 5 – CMM
● KPA:
– Gestión de cambio de proceso
– Gestión de cambio de tecnología
– Prevención de defectos

Unidad 5 – CMM
● El CMM ha sido revisado y refinado por muchos

especialistas para ponerse de acuerdo en los
métodos más efectivos para alcanzar los
objetivos de cada nivel de madurez

Unidad 5 – CMMI
● El modelo de capacidad y madurez

integrado (CMMI) es un modelo de referencia o
conjunto de prácticas enfocadas a mejorar los
procesos de una organización
● El modelo utiliza el paradigma de mejora del

proceso ya que el mismo no solo refleja el estado
del arte del proceso SW, también permite
establecer metas y prioridades para la mejora del
proceso, estableciendo un plan centrado en la
medición y cuantificación objetiva de los mismos

Unidad 5 – CMMI
● El propósito de CMMI para desarrollo es ayudar a

las organizaciones a mejorar sus procesos de
desarrollo de productos
● Consiste en definir las mejores prácticas que

tratan las actividades de desarrollo
comprendiendo el ciclo de vida completo del
producto, desde la concepción hasta la entrega y
mantenimiento del mismo, adaptándose
completamente la aplicación del modelo a la
organización

Unidad 5 – CMMI
● La estrategia adoptada por CMMI produce

beneficios operativos:
● Reducción de costo y tiempo de entrega
● Mayor productividad
● Menores tiempos de desarrollo
● Disminución del retrabajo y errores
● Mayor calidad del producto y satisfacción del
cliente.

Unidad 5 – CMMI
● Al igual que CMM, fue creado por el SEI con la

colaboración de la industria, el gobierno y el
ámbito académico, con el fin de unir una gran
cantidad de modelos existentes
● En la actualidad hay 3 áreas de interés cubiertas

por los modelos de CMMI:
● Desarrollo (CMMI-DEV)
● Adquisición (CMMI-ACQ)
● Servicios (CMMI-SVC)

Unidad 5 – CMMI
● CMMI-DEV: guías para medir, monitorizar y

administrar el proceso de desarrollo
● CMMI-ACQ: guías para el proceso de adquisición

de productos y servicios
● CMMI-SVC: guías para proporcionar servicios en

una organización y a clientes externos

● Las revisiones de software son un "filtro" para el

proceso de IS
● Las revisiones se aplican en varios momentos del
desarrollo y sirven para detectar errores y
defectos que puedan ser eliminados
● También, se necesitan revisiones porque aunque
la gente es buena descubriendo algunos de sus
propios errores, algunas clases de errores le
pasan por alto más fácilmente al que los origina
que a otras personas

● Una revisión es una forma de aprovechar la

diversidad de un grupo de personas para:
● Señalar la necesidad de mejoras (en el
producto) de una sola persona o un equipo
● Confirmar las partes de un producto en las que
no es necesaria o no es deseable una mejora
● Conseguir un trabajo técnico de una calidad
más uniforme, o al menos más predecible, que
la que puede ser conseguida sin revisiones

● Existen muchos tipos diferentes de revisiones

que se pueden llevar adelante como parte de la
IS:
● Una reunión informal es una forma de revisión
(si se discuten problemas técnicos)
● Una presentación formal de un diseño de
software a una audiencia de clientes,
ejecutivos y personal técnico es una forma de
revisión

● Una revisión técnica formal (RTF), a veces

denominada inspección, es el filtro más efectivo
desde el punto de vista de garantía de calidad
● La RTF es un medio efectivo para mejorar la

calidad del SW
● El objetivo primario de las RTF es encontrar

errores durante el proceso, de forma que no se
conviertan en defectos después de la entrega

Unidad 5 – RTF
● Los objetivos de una RTF son:

● Descubrir errores en la función, la lógica o la
implementación de cualquier representación
del SW
● Verificar que el SW alcanza sus requisitos
● Garantizar que el SW ha sido representado de
acuerdo a estándares predefinidos
● Conseguir un SW desarrollado de forma
uniforme
● Hacer que los proyectos sean más manejables

Unidad 5 – RTF
● La RTF también sirve para promover la seguridad

y la continuidad, ya que varias personas se
familiarizarán con partes del SW que, de otro
modo, no hubieran visto nunca

Unidad 5 – RTF
● Cada RTF se lleva a cabo mediante una reunión

● Cualquier reunión de revisión debe seguir las
siguientes restricciones:
● Se deben convocar entre 3 y 5 personas
● Se debe preparar por adelantado, pero sin que
requiera más de 2 horas de trabajo a cada
persona
● La duración de la reunión debe ser menor de 2
horas

Unidad 5 – RTF
● Cada RTF se centra en una parte específica (y

chica) del SW total
● Por ejemplo, en lugar de intentar revisar un

diseño completo, se hacen inspecciones a cada
módulo o pequeño grupo de módulos
● Al limitar el centro de atención de la RTF, la

probabilidad de descubrir errores es mayor

Unidad 5 – RTF
● La persona que desarrolló un producto

(productor) informa al jefe del proyecto que el
mismo está terminado y que requiere una
revisión
● El jefe del proyecto contacta con un jefe de
revisión, que evalúa la disponibilidad del
producto, genera copias del mismo y las
distribuye a 2 o 3 revisores para que se preparen
por adelantado
● Cada revisor estará entre 1 y 2 horas revisando el
producto, tomando notas y también
familiarizándose con el trabajo

Unidad 5 – RTF
● De forma concurrente, también el jefe de revisión

revisará el producto y establecerá una agenda
para la reunión de revisión que, normalmente,
queda convocada para el día siguiente
● La reunión de revisión es llevada a cabo por el

jefe de revisión, los revisores y el productor. Uno
de los revisores registra de forma escrita todos
los sucesos importantes que se produzcan
durante la revisión

Unidad 5 – RTF
● La RTF comienza con una explicación de la

agenda y una breve introducción a cargo del
productor
● El productor explica el material, mientras que los

revisores exponen los resultados de sus
revisiones basándose en su preparación previa
● Cuando se descubren problemas o errores

válidos, el que registra los va anotando

Unidad 5 – RTF
● Al final de la revisión, todos los participantes en

la RTF deben decidir si:
● Aceptan el producto sin posteriores
modificaciones
● Rechazan el producto debido a los serios
errores encontrados (una vez corregidos, ha de
hacerse otra revisión)
● Aceptan el producto provisoriamente (se han
encontrado errores menores que deben ser
corregidos, pero sin necesidad de otra revisión
posterior)

Unidad 5 – RTF
● Una vez tomada la decisión, todos los

participantes terminan firmando, indicando así
que han participado en la revisión y que están de
acuerdo con las conclusiones del equipo de
revisión

Unidad 5 – RTF
● Al final de la reunión se prepara un informe, el

cual responde a 3 preguntas:
● ¿Qué fue revisado?
● ¿Quién lo revisó?
● ¿Qué se descubrió y cuáles son las
conclusiones?
● El informe es una página simple (con posibles
suplementos). Se adjunta al registro histórico del
proyecto y puede ser enviada al jefe del proyecto
y a otras partes interesadas

Unidad 5 – RTF
● Se deben establecer de antemano directrices

para conducir las RTF, distribuyéndolas después
entre los revisores, para ser consensuadas y,
finalmente, seguidas
● Frecuentemente, una revisión incontrolada puede

ser peor que no hacer ningún tipo de revisión

Unidad 5 – RTF
● Revisar el producto, no al productor. Una

RTF involucra gente y egos. Se deben señalar los
errores educadamente; el tono de la reunión
debe ser distendido y constructivo; no debe
intentarse dificultar o batallar
● Fijar una agenda y mantenerla. Un mal de las

reuniones de todo tipo es la deriva. La RTF debe
seguir un plan de trabajo concreto. El jefe de
revisión es el responsable de mantener el plan de
la reunión

Unidad 5 – RTF
● Limitar el debate y las impugnaciones.

Cuando un revisor ponga de manifiesto otro tipo
de problema, podrá no haber unanimidad sobre
su impacto. En lugar de perder el tiempo
debatiendo la cuestión, debe registrarse el hecho
y dejar que la cuestión se lleve a cabo en otro
momento
● Tomar notas escritas. A veces es buena idea
que el que registra tome las notas en una pizarra,
de forma que las declaraciones o la asignación de
prioridades pueda ser comprobada por el resto
de los revisores

Unidad 5 – RTF
● Enunciar áreas de problemas, pero no

intentar resolver cualquier problema que se
ponga de manifiesto. Una revisión no es una
sesión de resolución de problemas. La resolución
de los problemas debe ser pospuesta para
después de la reunión de revisión
● Disponer recursos y una agenda para las

RTF. Para que las revisiones sean efectivas, se
deben planificar

Unidad 5 – RTF
● Limitar el número de participantes e insistir

en la preparación anticipada. 2 personas son
mejores que 1, pero 14 no son necesariamente
mejores que 4. Se ha de mantener el número de
participantes en el mínimo necesario
● Desarrollar una lista de comprobación para

cada producto que haya de ser revisado.
Una lista de comprobaciones ayuda al jefe de
revisión a estructurar la reunión y ayuda a cada
revisor a centrarse en los asuntos importantes

Unidad 5 – RTF
● Repasar las revisiones anteriores. Las

sesiones de información pueden ser beneficiosas
para descubrir problemas en el propio proceso de
revisión. El primer producto que se haya revisado
puede establecer las propias directivas de
revisión
● Llevar a cabo un buen entrenamiento de

todos los revisores. Por razones de efectividad,
todos los participantes en la revisión deben
recibir algún entrenamiento formal

Unidad 5 – RTF
● Como existen muchas variables (número de

participantes, tipo de productos de trabajo,
tiempo y duración, enfoque de revisión
específico) que tienen impacto en una revisión
satisfactoria, una organización deberá determinar
qué método funciona mejor en un contexto local


software
● El proceso de pruebas comienza con la prueba de

unidades: funciones, objetos, etc
● Luego estas unidades se integran en subsistemas

y sistemas y se prueban las interacciones entre
los mismos
● Finalmente, después de entregar el sistema, el

cliente puede llevar a cabo una serie de pruebas
de aceptación para comprobar que el mismo
funciona como se especificó


software
● Este modelo de pruebas es apropiado para el

desarrollo de sistemas grandes, pero para
sistemas más chicos a veces se distinguen
menos etapas en el proceso:
Pruebas del Pruebas de

componente integración


software
● Prueba de componentes: probar las partes del

sistema. Busca descubrir defectos probando
componentes individuales (funciones, objetos,
componentes reutilizables, etc)
● Prueba del sistema: probar el sistema como un

todo. Busca establecer que el sistema satisface
sus requerimientos funcionales, y no se comporta
de forma inesperada


software
● El proceso de pruebas tiene 2 objetivos distintos:

● Demostrar al desarrollador y al cliente que el
SW satisface sus requerimientos
● Descubrir defectos en el SW (comportamiento

incorrecto o no deseable, incumplimiento de su
especificación, etc)


software
● El primer objetivo conduce a las pruebas de

validación (se espera que el sistema funcione
correctamente usando un conjunto determinado de
casos de prueba)
● Una prueba de validación exitosa demuestra
que el sistema funciona correctamente
● El segundo objetivo conduce a las pruebas de

defectos (los casos de prueba se diseñan para
exponer los defectos)
● Una prueba de defectos exitosa demuestra un
defecto en el sistema


software
● Las pruebas no pueden demostrar que el SW está

libre de defectos o que se comportará en todo
momento como está especificado:
● Las pruebas sólo pueden demostrar la

presencia de errores, no su ausencia
● El objetivo de las pruebas es convencer a los

desarrolladores y a los clientes que el SW es lo
suficientemente bueno para uso operacional


software
● Modelo general del proceso de pruebas:
Resultados de Informe de la
Casos de prueba Datos de prueba
la prueba prueba
Ejecutar el programa Comparar resultados

Diseñar casos de Preparar datos de
con los datos de con los datos de
prueba prueba
prueba prueba


software
● Casos de prueba: especificaciones de las

entradas para las pruebas y la salida esperada
del sistema (no se pueden generar
automáticamente)
● Datos de prueba: entradas que han sido

ideadas para probar el sistema (a veces pueden
generarse automáticamente)


software
● Es imposible probar cada posible secuencia de

ejecución del programa, por lo que las pruebas
tienen que basarse en un subconjunto de
posibles casos de prueba:
● Probar todas las funciones a las que se accede
a través de menús
● Probar todas las combinaciones de funciones
● Probar todas las funciones con datos correctos
e incorrectos


software
● Los gestores deciden quién será responsable de

las diferentes etapas de pruebas:
● Generalmente, los programadores tienen la
responsabilidad de probar sus componentes
● Una vez que lo hacen, el trabajo se pasa a un

equipo de integración que integra los módulos
de diferentes desarrolladores, construye el SW
y prueba el sistema como un todo

● Pruebas de componentes (de unidad)

● Consisten en probar los componentes
individuales en el sistema
● Su objetivo es encontrar defectos en los

componentes del sistema

● Tipos de componentes:
● Funciones/métodos dentro de un objeto
● Clases con varios atributos y métodos
● Componentes formados por diferentes objetos

o funciones (se accede a su funcionalidad
mediante una interfaz)

● Cuando se prueban métodos se los llama con

diferentes parámetros de entrada (correctos e
incorrectos)
● Al probar las clases se deben cubrir todas sus

características:
● Todos sus métodos
● Asignación y consulta de todos sus atributos
● Comportamiento del objeto en todos sus
posibles estados

● Muchos componentes están formados por varios

objetos, accediendo a sus funcionalidades por
medio de sus interfaces
● Las pruebas de estos componentes se ocupan

principalmente de probar que la interfaz del
componente se comporta de acuerdo con su
especificación

● Las pruebas del sistema implican integrar y

probar 2 o más componentes que implementan
funciones o características del sistema:
● En un desarrollo iterativo, estas pruebas
prueban un incremento que va a ser entregado
al cliente
● En un desarrollo en cascada, estas pruebas

prueban el sistema completo

● Para la mayoría de los sistemas complejos,

existen 2 fases distintas de pruebas del sistema:

Unidad
Unidad5 5– –Pruebas
Pruebasde
del
integración
sistema
● Se tiene acceso al código fuente (pruebas de
caja blanca)
● Cuando se descubre un problema, se intenta

encontrar el origen del mismo e identificar los
componentes que tienen que ser depurados
● Se ocupan principalmente de encontrar

defectos en el sistema

● El proceso de integración implica construir un

sistema a partir de sus componentes y probar el
mismo para encontrar problemas que pueden
surgir debido a la integración
● Las pruebas de integración comprueban que

estos componentes realmente funcionan juntos,
son llamados correctamente y transfieren los
datos correctos en el tiempo preciso a través de
sus interfaces

● La principal dificultad es la localización de los

errores
● Esto implica que cuando se integra un nuevo

incremento, es importante volver a ejecutar las
pruebas para incrementos previos, así como las
nuevas pruebas requeridas para verificar la
nueva funcionalidad del sistema
● Volver a ejecutar un conjunto existente de

pruebas se denomina pruebas de regresión

● Se prueba una versión del sistema que podría
ser entregada a los usuarios (suelen ser de
caja negra)
● Se valida que el sistema satisface sus

requerimientos y que es confiable
● Cuando los clientes se involucran se las suele

llamar pruebas de aceptación

● Prueban una entrega del sistema que será

distribuida a los clientes
● El principal objetivo es demostrar que el sistema

satisface sus requerimientos:
● Demostrar que el sistema entrega la
funcionalidad especificada
● Demostrar que el sistema tiene el rendimiento
especificado
● Demostrar que el sistema no falla durante su
uso normal

● Cuando se prueban las entregas del sistema, se

debe intentar “romper” el SW:
● Elegir entradas que fuerzan que el sistema
genere todos los mensajes de error
● Diseñar entradas que hacen que los buffers de
entrada se desborden
● Repetir la misma entrada varias veces
● Forzar a que se generen las salidas inválidas
● Forzar los resultados de los cálculos para que
sean muy grandes o muy pequeños

● Una vez que un sistema se ha integrado

completamente, es posible probar las
propiedades emergentes del mismo, como el
rendimiento y la fiabilidad
● Las pruebas de rendimiento se diseñan para

asegurar que el sistema puede procesar su carga
esperada

● Como sucede con otros tipos de pruebas, las

pruebas de rendimiento se ocupan tanto de
demostrar que el sistema satisface sus
requerimientos como de descubrir problemas y
defectos en el mismo
● Las pruebas de rendimiento implican estresar el

sistema realizando demandas que están fuera de
los límites del diseño del SW

● Estos tipos de pruebas tienen 2 funciones:

● Sobrecargar el sistema y poder provocar que
se manifiesten defectos que normalmente no
serían descubiertos
● Probar el comportamiento de fallo de ejecución

del sistema. Pueden aparecer circunstancias a
través de una combinación no esperada de
eventos en donde la carga sobre el sistema
supere la carga máxima anticipada

● En el diseño de casos de prueba se diseñan las

entradas y salidas esperadas para probar el
sistema
● El objeto es crear un conjunto de casos de prueba

que sean efectivos descubriendo defectos en los
programas y mostrando que el sistema satisface
sus requerimientos

● Diseño de un caso de prueba:

● Se selecciona una característica del sistema o
componente a probar
● Se selecciona un conjunto de entradas que

ejecutan dicha característica, se documentan
las salidas esperadas, y si es posible se diseña
una prueba automatizada que pruebe que las
salidas reales y esperadas son las mismas

● Enfoques que se pueden seguir para diseñar

casos de prueba:


● Se diseñan los casos de prueba para probar los
requerimientos del sistema
● Se utiliza para las pruebas del sistema
● Son pruebas de validación en lugar de pruebas

de defectos: se intenta demostrar que el
sistema ha implementado sus requerimientos
de forma adecuada


● Los requerimientos deben poder probarse, por
lo que se los debe escribir de tal forma que se
pueda diseñar una prueba que permita
comprobar que los requerimientos se
satisfacen

● Los datos de E/S se pueden agrupar por
características comunes:
– Números positivos
– Números negativos
– Selecciones de menús
● A estas características o categorías se las

denomina particiones o dominios

● Se identifican todas las particiones para un
sistema o componente (los casos de prueba se
diseñan para que las E/S pertenezcan a estas
particiones)
● Una buena práctica es elegir los límites de las

particiones junto con los valores cercanos al
punto medio de la partición (entradas válidas e
inválidas)

● Con la estructura del programa, se diseñan
pruebas que ejecuten todas sus partes:
– Probar que cada sentencia se ejecuta al
menos una vez
● También se las llama “pruebas de caja blanca"
● La comprensión de la estructura del programa

ayuda a identificar particiones adicionales

● Estrategia para las pruebas estructurales
● Su objetivo es asegurar que cada camino

independiente en el programa o componente
se ejecuta al menos una vez:
– Si se prueba cada camino, todas las
sentencias del programa o componente se
habrán ejecutado al menos una vez

● La cantidad de caminos es un programa es
proporcional a su tamaño
● Como los distintos módulos se van integrando,

no se pueden usar estas pruebas (se las usa en
las pruebas de componente)

● Las pruebas de caminos no prueban todas las
posibles combinaciones de todos los caminos
(en programas con lazos hay un número
infinito de posibles combinaciones de caminos)
● Para diseñar estas pruebas se arma un grafo

de flujo del programa:
– Nodos: decisiones
– Aristas: flujo de control

public void busquedaBinaria(int clave, int[] array, Resultado r) {

int limInf = 0; //1
1
int limSup = array.length – 1; //2
int medio;
2
r.setIndice(-1); //3
r.setEncontrado(false); //4 3
while (limInf <= limSup) { //5
medio = (limInf + limSup) / 2; //6
4
if (array[medio] == clave) { //7
r.setIndice(medio); //8 limInf > 5 while (limInf <=
r.setEncontrado(true); //9 limSup limSup)
return; //10
}
6
else { array[medio]
7 != clave 11
if (array[medio] > clave) //11
array[medio]
limSup = medio – 1; //12
= clave 8 array[medio]
else > clave
limInf = medio + 1; //13 9 12 13
}
} 14 10
} IS Unidad 5 Luis Nieto 2018 //14 119

● Los caminos en el grafo son:
– 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
– 1, 2, 3, 4, 5, 14
– 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, ...
– 1, 2, 3, 4, 5, 6, 7, 11, 13, 5, ...
● Si se ejecutan todos estos caminos, se puede

asegurar que cada sentencia se ejecuta al
menos una vez, y que cada rama se ejecuta
para las condiciones verdadera y falsa

● Para encontrar el número de caminos
independientes se puede calcular la
complejidad ciclomática del grafo:
– Condición simple: expresión lógica sin
conectores “AND” u “OR”
– Condición compuesta: expresión lógica

con conectores “AND” u “OR”

● Cálculo de la complejidad ciclomática (para
programas sin sentencias GOTO):
– Es 1 más que el número de condiciones
(simples)
– Si hay condiciones compuestas, se cuenta el

número de condiciones simples en las
compuestas

● Ejemplo: programa con 6 sentencias IF, 1 lazo
WHILE y todas expresiones condicionales
simples:
● Si una de las expresiones condicionales es de

la forma “IF A AND B OR C”, esto cuenta
como 3 expresiones simples (A, B y C):

● Para el algoritmo de búsqueda binaria:
– while (limiteInferior <= limiteSuperior) { //5
– if (array[medio] == clave) { //7
– if (array[medio] > clave) //11
● Complejidad ciclomática = 4
● Cantidad de caminos independientes = 4

● Luego de obtener la cantidad de caminos
independientes se diseñan los casos de prueba
para ejecutarlos
● El número mínimo de casos de prueba

necesarios para probar todos los caminos es
igual a la complejidad ciclomática

Unidad 5

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 5

Cargado por

Copyright:

Formatos disponibles

Unidad 5 – Aseguramiento de la Calidad

● Pruebas del software

● Para productos tangibles, la calidad depende de

● El control de variación es la base del control de

● En el SW el esfuerzo se centra en controlar la

● En el SW se quiere reducir la diferencia entre los

● Calidad: “característica o atributo de algo”

● El SW es más difícil de caracterizar que los

● satisfacción del usuario = producto

● El costo de la calidad incluye todos los costos

● Los costos de calidad están asociados con:

● Prevención: planificación, revisiones técnicas

● Evaluación: actividades para tener una visión

● Fallos: se dividen en:

● Costos externos: debido a defectos

● Los costos relativos para encontrar y reparar un

Prueba de Prueba de En fase de

● Fallo: cualquier falta de concordancia con los

● Fiabilidad: probabilidad de operación libre de

● La fiabilidad del SW es un elemento importante

● La fiabilidad del SW, a diferencia de otros

● Una medida de la fiabilidad es el tiempo medio

● Muchos argumentan que el TMDF es una medida

● Disponibilidad: probabilidad que el SW funcione

● Disp = [TMDF / (TMEF)] x 100%

● La disponibilidad es una medida indirecta de la

● Antes que se usara SW en sistemas críticos de

● Las técnicas de seguridad se diseñaban para

● Cuando se utiliza SW como parte del sistema de

● La seguridad del SW se centra en la identificación

● La Gestión de la Calidad se estructura en 3

● Durante los años '50 y '60, la calidad era

● Luego, durante los '70 se introdujeron estándares

● Estos estándares se extendieron rápidamente a

● Los responsables de SQA miran al SW desde el

● ¿Se ha realizado el desarrollo de acuerdo con

● SQA es el proceso que define cómo lograr la

● Se pueden definir 2 tipos de estándares:

● Estándares del proceso

● Estándares del producto: se aplican sobre el

● Estándares del proceso: definen los procesos

● Los estándares de SW son importantes porque:

● Proveen un marco de trabajo alrededor del cual

● Ayudan a la continuidad cuando una persona

● La planificación de la calidad es el proceso en el

● El plan de calidad selecciona los estándares

● Estructura sugerida para un plan de calidad:

● Planificación del producto: fechas de

● Estructura sugerida para un plan de calidad:

● Metas de calidad: metas y planes de calidad

● Riesgos y gestión de riesgos: riesgos clave

● Hay una gran variedad de atributos de calidad

● En general, no es posible optimizar todos los

● El control de la calidad implica vigilar el proceso

● Existen 2 enfoques complementarios que se

● Revisiones de la calidad: el SW, su

● Se anotan las desviaciones de los estándares y

● Valoración automática del software: el

● Actividades de SQA recomendadas por el SEI:

● Planificar SQA para un proyecto. El plan se

● Describir el proceso SW. El equipo de IS

● El grupo de SQA revisa que la descripción del

● Revisar que las actividades de IS se ajustan

● Documentar las desviaciones. Las