1. Calidad del software
1.1. La calidad del software no es directamente comparable con la calidad en la fabricación. La idea de tolerancia no es aplicable a los sistemas digitales y es prácticamente imposible llegar a una conclusión objetiva sobre si un sistema de software cumple o no su especificación, por las siguientes razones:
1.1.1. Por lo general, las especificaciones integran requerimientos de varias clases de participantes. Dichos requerimientos son un compromiso ineludible y tal vez no incluyan los requerimientos de todos los grupos de participantes.
1.1.2. Es imposible medir de manera directa ciertas características de calidad (por ejemplo, mantenibilidad) y, por ende, no pueden especificarse plenamente sin ambigüedades.
1.1.2.1. Debido a estos problemas, la valoración de calidad del software es un proceso subjetivo en que el equipo de gestión de calidad tiene que usar su juicio para decidir si se logró un nivel aceptable de calidad, Por ejemplo
1.1.2.1.1. ¿En el proceso de desarrollo se siguieron los estándares de programación y documentación?
1.1.2.1.2. ¿El software se verificó de manera adecuada?
1.1.2.1.3. ¿El software es suficientemente confiable para utilizarse?
1.1.2.1.4. ¿El rendimiento del software es aceptable para uso normal?
1.1.2.1.5. ¿El software es utilizable?
1.1.2.1.6. ¿El software está bien estructurado y es comprensible?
1.1.3. Los desarrolladores y clientes de software pueden interpretar los requerimientos de diferentes formas y tal vez sea imposible llegar a acuerdos acerca de si el software se desarrolló conforme a su especificación producto
2. Estándares de software
2.1. Los estándares reflejan la sabiduría que es de valor para la organización. Se basan en conocimiento sobre la mejor o más adecuada práctica para la compañía
2.2. Los estándares proporcionan un marco para definir, en un escenario particular, lo que significa el término “calidad”. Como se dijo, la calidad del software es subjetiva, y al usar estándares se establece una base para decidir si se logró un nivel de calidad requerido
2.2.1. Estándares del producto
2.2.1.1. Se aplican al producto de software a desarrollar. Incluyen estándares de documentos (como la estructura de los documentos de requerimientos), estándares de documentación (como el encabezado de un comentario estándar para una definición de clase de objeto) y estándares de codificación, los cuales definen cómo debe usarse un lenguaje de programación.
2.2.2. Estándares de proceso
2.2.2.1. Establecen los procesos que deben seguirse durante el desarrollo del software. Deben especificar cómo es una buena práctica de desarrollo. Los estándares de proceso pueden incluir definiciones de especificación, procesos de diseño y validación, herramientas de soporte de proceso y una descripción de los documentos que deben escribirse durante dichos procesos.
2.3. Los estándares auxilian la continuidad cuando una persona retoma el trabajo iniciado por alguien más. Los estándares aseguran que todos los ingenieros dentro de una organización adopten las mismas prácticas. En consecuencia, se reduce el esfuerzo de aprendizaje requerido al iniciarse un nuevo trabajo
3. Revisiones e inspecciones
3.1. El proceso de revisión
3.1.1. Actividades previas a la revisión
3.1.1.1. Se trata de actividades preparatorias esenciales para que sea efectiva la revisión
3.1.2. La reunión de revisión
3.1.2.1. Durante la reunión de revisión un autor del documento o programa a revisar debe repasar el documento con el equipo de revisión. La revisión en sí debe ser relativamente corta, dos horas a lo sumo
3.1.2.1.1. Inspecciones del programa
3.1.3. Actividades posteriores a la revisión
3.1.3.1. Después de terminada una reunión de revisión, deben tratarse los conflictos y problemas surgidos durante la revisión. Esto puede implicar corregir bugs de software
4. Medición y métricas del software
4.1. formas en que pueden usarse las mediciones de un sistema de software
4.1.1. Para asignar un valor a los atributos de calidad del sistema
4.1.1.1. Al medir las características de los componentes del sistema, como su complejidad ciclomática, y luego agregar dichas mediciones, es posible valorar los atributos de calidad del sistema, tales como la mantenibilidad
4.1.2. Para identificar los componentes del sistema cuya calidad está por debajo de un estándar
4.1.2.1. Para identificar los componentes del sistema cuya calidad está por debajo de un estándar Las mediciones pueden identificar componentes individuales con características que se desvían de la norma. Por ejemplo, es posible medir componentes para descubrir aquéllos con la complejidad más alta. Éstos tienen más probabilidad de tener bugs porque la complejidad los hace más difíciles de entender