1. ¿Qué es la calidad en el Software?
1.1. Existen diversas definiciones para el concepto de calidad en el software, sin embargo, una definición completa es la de Pressman: "Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario"
1.1.1. Algunos de los elementos que nos proporcionan mejor noción acerca de cómo se compone la Calidad en el Software son (Aludiendo a la Terminología ISO 8402):
1.1.1.1. ¿Quién es el responsable de la Gestión de la Calidad? Es responsabilidad de TODOS los niveles ejecutivos, siendo este guiado y supervisado por la alta dirección.
1.1.1.1.1. ¿Qué otro aspecto se toma en cuenta la hora de hablar de Gestión de Calidad?
1.1.1.1.2. En la Gestión de la Calidad, también se deben tomar en cuenta los criterios de rentabilidad.
1.1.1.2. Aspectos a tener en cuenta del Sistema de Gestión de la Calidad (SGC o QMS). Primero debemos saber que este es el CÓMO funciona la estructura de la organización (El conjunto de responsabilidades, procedimientos, procesos y recursos) para llevar a cabo la gestión de la calidad. - El SGC debe tener el volumen y el alcance suficiente para conseguir los objetivos de la calidad.
1.1.2. - Control de Calidad: Técnicas y Actividades de carácter operativo que se utilizan para verificar los requerimientos relativos a la calidad del producto/servicio.
1.1.3. - Garantía de la Calidad: Son las acciones planificadas y sistemáticas necesarias para brindar la confianza de que el producto/servicio cumpla los requerimientos dados sobre calidad.
1.1.4. - Gestión de la Calidad: Es el aspecto de la gestión que determina y aplica la política de la calidad, los objetivos y las responsabilidades. ( Los medios para esto son La Planificación de la Calidad - El Control de la Calidad - La Garantía de la Calidad y La Mejora de la Calidad )
2. Decálogo de la Calidad
2.1. Este tema se subdivide en 10 niveles, los cuales son:
2.1.1. - La calidad la definen los clientes. - El proceso de calidad se inicia con el liderazgo activo de la Alta Dirección. - La calidad es un factor estratégico de competitividad y diferenciación. - La calidad efectiva es garantía de rentabilidad sostenida. - La calidad involucra a todos los miembros de la organización. - La calidad involucra a los proveedores. - La calidad debe ser el criterio que configure todos los sistemas y procesos de la empresa. - La calidad debe comunicarse. - Calidad implica sensibilidad y preocupación de la empresa por su entorno social y medioambiental. - La calidad es dinámica.
2.1.1.1. ¿Para qué es importante conocer esto?
2.1.1.1.1. El hecho de saber diferenciar este decálogo en relación a las concepciones erróneas y los paradigmas que existen sobre la calidad ( Por ejemplo, "La calidad es intangible y, por consiguiente, no puede medirse ) nos permite obtener un mejor enfoque sobre la calidad; Parafraseando el texto, el objetivo es concebir la idea de la calidad como una estrategia global de negocio.
3. Factores de la Calidad
3.1. En todos los casos para determinar los factores de la calidad se debe comparar el software (Documentos, Programas y Datos) con una referencia para poder llegar a la conclusión sobre calidad.
3.1.1. Modelo de McCall y sus amigos para clasificar los factores que afectan la calidad del software:
3.1.1.1. Aspectos importantes: - Características Operativas. - Capacidad de Cambios. - Adaptabilidad a Nuevos Entornos.
3.1.1.2. Características Operativas: - Correción (¿Hace lo que quiero?) - Fiabilidad (¿Lo hace de forma fiable todo el tiempo?) - Eficiencia (¿Se ejecutará en mi hardware lo mejor que pueda?) - Seguridad o Integridad (¿Se controla el acceso al software o a los datos?) - Usabilidad o Facilidad de Uso (¿Es necesario mucho esfuerzo para aprender a operar el sistema?)
3.1.1.3. Capacidad de Soportar los Cambios (Revisión): - Facilidad de Mantenimiento (¿Puedo corregirlo? o ¿Cuánto esfuerzo es necesario para localizar y corregir un error?) - Flexibilidad (¿Puedo cambiarlo? o ¿Cuánto esfuerzo es necesario para modificar un programa que ya funciona?) - Facilidad de Prueba (¿Puedo probarlo? o ¿Cuánto esfuerzo es necesario para probar un programa y asegurarme de que funcione?)
3.1.1.4. Adaptabilidad a Nuevos Entornos (Transición): - Portabilidad (¿Podré usarlo en otra máquina?) - Reusabilidad (¿Podré reutilizar alguna parte del software?) - Interoperabilidad ¿Podré hacerlo interactuar con otro sistema?
3.2. Factores que se pueden medir directamente.
3.3. Factores que se pueden medir sólo indirectamente.
4. Garantía o Aseguramiento de la Calidad del Software (GCS / SQA )
4.1. ¿Qué es y para qué nos sirve?
4.1.1. ¿Cómo se puede llevar a cabo? y, ¿Qué etapas deben suceder en las Actividades de Aseguramiento de la Calidad (SQA)?
4.1.1.1. A. Establecimiento de un plan de SQA para un proyecto (Se debe desarrollar durante la planificación del proyecto y debe ser revisado 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. - Realimentación de información proporcionada al equipo de proyecto del software.
4.1.1.2. B. Participación en el desarrollo de la descripción del proceso de software del proyecto: El equipo de ingeniería del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa, los estándares internos del software, los estándares impuestos externamente, y a otras partes del plan de proyecto del software.
4.1.1.3. C. Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido: El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones.
4.1.1.4. D. Auditoría de los productos de software para verificar el ajuste con los definidos como parte del proceso del software: El grupo de SQA revisa los productos seleccionados; verifica que se han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al gestor del proyecto.
4.1.1.5. E. Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido: Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables o en los productos técnicos.
4.1.1.6. F. Registrar lo que no se ajuste a los requisitos e informar a sus superiores: Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.
4.1.2. ¿Cómo se coordina el control, la gestión de cambios, la recopilación y el análisis de las métricas del software?
4.1.2.1. Técnicas formales para revisión
4.1.2.1.1. Técnicas Estáticas
4.1.2.1.2. Suelen ser denominadas también como técnicas para realizar un Peer review o revisión entre colegas. ¿Qué pueden llegar a cubrir? Diferentes niveles de formalidad, rigor, efectividad y costo.
4.1.2.1.3. ¿Cómo saber cuál debemos elegir? Cada proyecto debe seleccionar la técnica o método más económico que le permita reducir a un nivel aceptable los riesgos que pueden presentar los defectos que permanecen en el producto. Se utilizan las inspecciones para productos que representan un alto riesgo y técnicas más económicas para componentes que tienen un riesgo menor.
4.2. El punto de partida de un grupo encargado de SQA es definir un marco de trabajo para lograr la calidad del software, lo que implica definir o seleccionar estándares aplicables al proceso de desarrollo o a los productos de software.
5. Revisiones Técnicas Formales (RTF)
5.1. s una actividad de garantía de calidad del software llevada a cabo por los ingenieros del software (y otros)
5.1.1. Los objetivos de la RTF son:
5.1.1.1. Descubrir errores en la función, la lógica o la implementación de cualquier representación del software;
5.1.1.2. Verificar que el software bajo revisión alcanza sus requisitos;
5.1.1.3. Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos;
5.1.1.4. Conseguir un software desarrollado de forma uniforme
5.1.1.5. Hacer que los proyectos sean más manejables
5.1.2. Al final de la revisión, todos los participantes en la RTF deben decidir si:
5.1.2.1. Aceptan el producto sin posteriores modificaciones;
5.1.2.2. Rechazan el producto debido a los serios errores encontrados (una vez corregidos, ha de hacerse otra revisión)
5.1.2.3. Aceptan el producto provisionalmente (se han encontrado errores menores que deben ser corregidos, pero sin necesidad de otra revisión).
5.2. Registro e informe de la revisión.
5.2.1. Durante la RTF, uno de los revisores (el registrador) procede a registrar todas las inconformidades que vayan surgiendo. Al final de la reunión de revisión, resume todas las inconformidades y genera una lista de sucesos de revisión. Además, prepara un informe sumario de la revisión técnica formal. El informe sumario de revisión responde a tres preguntas:
5.2.1.1. 1. ¿Qué fue revisado?
5.2.1.2. 2. ¿Quién lo revisó?
5.2.1.3. 3. ¿Qué se descubrió y cuáles son las conclusiones?