Existen varios Software Quality Design Attributes for Product and Process. En la presente diapositiva solo menciono uno de cada uno.

1. A. Integridad Conceptual.
Fred Brooks, uno de los padres fundadores del software como disciplina, fue quien mencionó
por primera vez la ​Integridad Conceptual​.
Sostendré que la Integridad Conceptual es la consideración más importante en el diseño del
sistema. Es mejor tener un sistema que omita ciertas características y mejoras anómalas, pero
que refleje un conjunto de ideas de diseño, que tener uno que contenga muchas ideas buenas
pero independientes y descoordinadas.
Fred Brooks
Para apreciar la importancia de la Integridad Conceptual, necesitamos examinar más de cerca
su significado. La palabra "integridad" está asociada con la idea de "estar integrado" o "ser uno"
y la palabra "conceptual" se asocia con el proceso cognitivo del concepto. Habiendo entendido
esto, notamos que la Integridad Conceptual es esencial para:
● Innovación, con un profundo conocimiento del estado actual del diseño del sistema,
los desarrolladores pueden relacionar conceptos en el diseño del sistema más fácilmente con
nuevas ideas.
● Diseño de Sistema Flexible: un diseño de sistema con integridad conceptual puede ser
más fácilmente adaptable a un posible cambio de requisitos;
● Gestión Efectiva del Proyecto: mejor conocimiento sobre el estado del diseño hace que
sea más fácil ajustar los recursos disponibles.
Brook pasó mucho tiempo en la década de 1960 pensando y escribiendo sobre el problema de
lograr que los equipos de desarrollo tengan una ​mente colectiva ​con la misma visión para un
determinado proyecto.
Amenazas Para la Integridad Conceptual.
Requerimientos No Claros.
Aun en la actualidad este problema sigue latente. Es bastante complicado comunicar la visión
de un producto de software que aún no existe. Es especialmente difícil comunicar la visión
cuando algunos requerimientos relacionados con la visión del producto pueden cambiar. Todos
hemos escuchado alguna vez la frase “El Cliente no sabe lo que quiere”, y gracias al Agile
Manifesto cada vez que el cliente tiene un nuevo requerimiento, nosotros decimos bienvenido
con una sonrisa :) Sin embargo, pueden darse casos en los cuales el cliente sea demasiado
cambiante en cuanto a sus requerimientos, siendo el peor caso aquellos requerimientos que
contradicen o van contra requerimientos ya implementados en el sistema.
Los Ingenieros de Software.
No olvidemos que los ingenieros de software no son conocidos por sus habilidades de
comunicación. Generalmente, los ingenieros de software tienden a tener opiniones firmes sobre
cómo se deberían resolver ciertos problemas. Para empeorarlo, pueden ser increíblemente

2. tercos con respecto a esas ideas, incluso cuando sus ideas entran en conflicto con la visión
adoptada.
El Tiempo.
Es común encontrarse con proyectos de software que tienen más de 5 años. Durante el tiempo
de desarrollo del producto, la gente va y viene, algunas veces solo cambian de equipo o
proyecto y en otras ocasiones estas personas dejan la empresa. Como consecuencia la
pérdida de visión parece inevitable.
Cómo lo logramos la Integridad Conceptual?
Fred Brooks ofrece una solución elegante y obvia:
"... la acción más importante es la puesta en marcha de una mente para ser el arquitecto del
producto, que es responsable de la integridad conceptual de todos los aspectos del producto
perceptibles por el usuario".
Para sistemas bastante grandes, una mente no puede contener toda la arquitectura. Por lo
tanto, es necesario que el arquitecto principal del sistema particione el sistema en subsistemas.
De esta manera cada subsistema tendrá su propio arquitecto, el cual debe informar al
arquitecto principal del sistema todos los detalles de la arquitectura del subsistema.

3. B. Confiabilidad
Según ANSI, la confiabilidad del software se define como la probabilidad de que el software
opere libre de fallas durante un período de tiempo específico en un entorno específico. Puede
ser escrita de esta manera:
Confiabilidad = 1 - Probabilidad de Falla
Aunque la confiabilidad del software se define como una función probabilística en función del
tiempo, debemos tener en cuenta que a diferencia de un producto físico como el hardware, el
software no se desgasta, pero se deteriora. Esta afirmación ya la hizo Roger Pressman en su
libro Software Engineering a Practitioner’s Approach, en el cual mediante dos gráficas (Taza de
Fallo Vs Tiempo) realiza un análisis de esta afirmación.
Para resumir, las piezas electrónicas y mecánicas pueden volverse "viejas" y desgastarse con
el tiempo y el uso, pero el software no se oxidará ni desgastará durante su ciclo de vida. El
software no cambiará con el tiempo a menos que se cambie o actualice intencionalmente, es
en este punto donde pueden introducirse las fallas.
Aca quisiera hacer un Stop, y mostrar mediante el siguiente video las diferencias entre:
Error , Fault and Failure
https://www.youtube.com/watch?v=rRlhm2E06l8
Por que?
La confiabilidad del software es difícil de lograr en sistemas complejos. Es común que un
producto de software pequeño tenga éxito, y con ello se vengan nuevas demandas por parte de
los usuarios. Esto hace que el crecimiento del tamaño del sistema sea más rápido y la
necesidad de actualizar el software existente sea mayor, es así que los ingenieros de software
durante este proceso de desarrollo tienden a introducir más complejidad a dicho software.
Si bien la complejidad del software está inversamente relacionada con la confiabilidad del
software, está directamente relacionada con otros factores importantes en la calidad del
software, especialmente la funcionalidad, la capacidad de rendimiento, etc. Enfatizar estas
características tenderá a agregar más complejidad al software.

4. Como medirlo?
Es frustrante que aún hoy en día no exista una manera cuantitativa precisa para la medición de
la confiabilidad de software, esto es porque no tenemos una buena comprensión de la
naturaleza del software. No hay una definición clara de qué aspectos están relacionados con la
confiabilidad del software.
Sin embargo, existen ciertas prácticas de medición para la confiabilidad del software que se
pueden dividir en cuatro categorías:
1. Product Metrics
Se cree que el ​tamaño del software​ refleja la complejidad, el esfuerzo de desarrollo y la
confiabilidad. Lines of Code (LOC), o LOC en miles (KLOC), es un enfoque inicial intuitivo para
medir el tamaño del software. Pero no hay una forma estándar de contar. Normalmente, se
utiliza el código fuente (SLOC, KSLOC) y los comentarios y otras declaraciones no ejecutables
no se cuentan. Este método no puede comparar fielmente el software no escrito en el mismo
idioma. El advenimiento de las nuevas tecnologías de reutilización de códigos y la técnica de
generación de códigos también arrojan dudas sobre este método simple.
https://courses.cs.washington.edu/courses/cse503/11sp/lect-3-complexity-proving-adts.pdf
La ​métrica del punto de función​ es un método para medir la funcionalidad de un desarrollo de
software propuesto basado en un recuento de entradas, salidas, archivos maestros, consultas e
interfaces. El método se puede usar para estimar el tamaño de un sistema de software tan
pronto como se puedan identificar estas funciones. Es una medida de la complejidad funcional
del programa. Mide la funcionalidad entregada al usuario y es independiente del lenguaje de
programación. Se usa principalmente para sistemas comerciales; no está probado en
aplicaciones científicas o en tiempo real.
https://www.softwaremetrics.com/files/15minutes.pdf
La ​complejidad ​está directamente relacionada con la fiabilidad del software, por lo que
representar la complejidad es importante. Las métricas orientadas a la complejidad son un
método para determinar la complejidad de la estructura de control de un programa, mediante la
simplificación del código en una representación gráfica. La métrica representativa es la Métrica
de Complejidad de McCabe.
http://www.chambers.com.au/glossary/mc_cabe_cyclomatic_complexity.php
Las métricas de cobertura de prueba​ son una forma de estimar fallas y confiabilidad al
realizar pruebas en productos de software, basados ​​en la suposición de que la confiabilidad del
software es una función de la parte del software que se ha verificado o probado con éxito.
https://reqtest.com/testing-blog/test-coverage-metrics/

5. 2. Project Management Metrics
Los investigadores se han dado cuenta de que una buena gestión puede dar como resultado
mejores productos. La investigación ha demostrado que existe una relación entre el proceso de
desarrollo y la capacidad de completar proyectos a tiempo y dentro de los objetivos de calidad
deseados. Los costos aumentan cuando los desarrolladores usan procesos inadecuados. Se
puede lograr una mayor confiabilidad mediante el uso de un mejor proceso de desarrollo,
proceso de gestión de riesgos, proceso de gestión de la configuración, etc.
http://blog.mavenlink.com/the-top-10-performance-metrics-examples-project-managers-cant-aff
ord-to-miss
3. Process Metrics
Con base en la suposición de que la calidad del producto es una función directa del proceso,
las medidas del proceso se pueden utilizar para estimar, controlar y mejorar la confiabilidad y la
calidad del software. La certificación ISO-9000, o "estándares de gestión de calidad", es la
referencia genérica para una familia de normas desarrollada por la Organización Internacional
de Normalización (ISO).
http://askartsolutions.com/iso-9001-consulting-what-are-process-measureables/
4. Fault and Failure Metrics
El objetivo de recopilar métricas de falla y falla es poder determinar cuándo se aproxima el
software a una ejecución sin fallas. Como mínimo, tanto el número de fallas encontradas
durante la prueba (es decir, antes de la entrega) como los fallos (u otros problemas) informados
por los usuarios después de la entrega se recopilan, resumen y analizan para lograr este
objetivo. La estrategia de prueba es altamente relativa a la efectividad de las métricas de falla,
porque si el escenario de prueba no cubre la funcionalidad completa del software, el software
puede pasar todas las pruebas y, sin embargo, ser propenso a fallas una vez entregado. Por lo
general, las métricas de falla se basan en la información del cliente con respecto a fallas
encontradas después del lanzamiento del software. Por lo tanto, los datos de falla recopilados
se utilizan para calcular la densidad de fallas, el Tiempo medio entre fallas (MTBF) u otros
parámetros para medir o predecir la confiabilidad del software.
http://www.bb-elec.com/Learning-Center/All-White-Papers/Fiber/MTBF,-MTTR,-MTTF,-FIT-Expl
anation-of-Terms/MTBF-MTTR-MTTF-FIT-10262012-pdf.pdf
https://www.youtube.com/watch?v=-xFJEisMWnI

6. Cómo mejorarlo?
La aplicación de buenos métodos de ingeniería pueden mejorar en gran medida la confiabilidad
del software. Antes del despliegue de los productos de software, las pruebas, la verificación y la
validación son pasos necesarios. Las pruebas de software se utilizan mucho para activar,
localizar y eliminar los defectos del software. Las pruebas de software todavía están en su
etapa infantil; las pruebas se diseñan para satisfacer necesidades específicas en varios
proyectos de desarrollo de software de una manera ad-hoc. Varias herramientas de análisis
como Trend Analysis, Fault-Tree Analysis, Orthogonal.
https://www.schwab.com/active-trader/insights/content/trend-analysis-methods
https://www.weibull.com/basics/fault-tree/index.htm