El documento habla sobre la implementación de estándares de calidad en el desarrollo de software. Explica que existen organizaciones como ISO que establecen normas y estándares de calidad a nivel internacional. Luego describe algunos estándares y marcos de calidad específicos para software como ISO 9001, CMM e ISO/IEC 15504 (SPICE), enfocándose en sus objetivos y características.

1. ESTANDARES DE CALIDAD
APPLICADOS AL SOFTWARE

2. Estándares de calidad del software
Los primeros años de la era informática se vieron
marcados por el desafío del desarrollo del hardware
de los ordenadores. Este desafío se ha visto superado
por los vertiginosos avances de la microelectrónica.
Hoy en día el principal problema al que nos
enfrentamos es la llamada “crisis del software”. La
causa principal de esta crisis es el aumento de la
complejidad de las aplicaciones sin la adopción de los
procesos adecuados de desarrollo que contribuirían a
obtener un producto de mayor calidad y menor coste.
Mediante a esto nos hacemos varias preguntas por las
cuales han de ser contestadas

3. ¿Por qué implementar
estándares de calidad?
Satisfacción del cliente
Competencia
Defectos

4. TIPOS DE ESTANDARES

5. ISO
Es el organismo encargado de promover el
desarrollo de normas internacionales de
fabricación, comercio y comunicación para todas
las ramas industriales a excepción de la eléctrica
y la electrónica. Su función principal es la de
buscar la estandarización de normas de
productos y seguridad para las empresas u
organizaciones a nivel internacional.

6. ISO 90001/9000–3
ISO 9000 conjunto de normas de calidad
establecidas para la estandarización que
pueden ser usadas por cualquier
organización. Características:
-muy útil en compañías que además de
fabricar software fabrican equipos.
-define los procesos de calidad en
compañías que desarrollan software.

7. Beneficios:
1. Mejor documentación de los sistemas.
2. Cambio cultural positivo.
3. Incremento en la eficiencia y productividad.
4. Mayor percepción de calidad.
5. Se amplía la satisfacción del cliente.
6. Se reducen las auditorías de calidad de los
clientes.
7. Agiliza el tiempo de desarrollo de un sistema.

8. Metodología:
Responsabilidades de la Estado de Inspección y pruebas:
dirección:
 Control de producto no
 Sistemas de calidad: conforme:
 Revisión del contrato:  Acciones correctivas y
preventivas:
 Control de documentos y
datos:  Manejo, almacenaje, empaque,
preservación y embargue:
 Productos provistos por el
comprador:  Control de registros de
calidad:
 Identificación y trazabilidad
 Auditorías internas de calidad:
del producto:
 Capacitación:
 Inspección y pruebas:
 Técnicas estadísticas.
 Equipos de Inspección,
medición y pruebas:

9. ISO 15504 (SPICE, Software Process
Improvement and Capability
determination)
ISO/IEC 15504 es un emergente estándar
internacional de evaluación y determinación de la
capacidad y mejora continua de procesos de
ingeniería del software, con la filosofía de
desarrollar un conjunto de medidas de capacidad
estructuradas para todos los procesos del ciclo de
vida y para todos los participantes. Es el resultado
de un esfuerzo internacional de trabajo y
colaboración y tiene la innovación, en
comparación con otros modelos, del proceso
paralelo de evaluación empírica del resultado.

10. Características:
En el desarrollo de software se Relativas a la persona
centro en los proyectos de
construcción que presentan Relativas a la comunicación
características particulares. Relativas al riesgo
Metodología: Relativas a los
Relativas a la estrategia aprovisionamientos
Relativas a la gestión
Relativas al alcance
Relativas al tiempo
Relativas al costo
Relativas a los recursos

11. SPICE es un acrónimo inglés de Simulation
Program with Integrated Circuits Emphasis
(Programa de simulación con énfasis en circuitos
integrados). Fue desarrollado por la Universidad
de California, Berkeley en 1975 por Donald
Pederson.
Es un estándar internacional cuyo objetivo es
simular circuitos electrónicos analógicos
compuestos por resistencias, condensadores,
diodos, transistores, etc. Para ello hay que
describir los componentes, describir el circuito y
luego elegir el tipo de simulación (temporal, en
frecuencia, en continua, parámetrico.

12. CMM
CMM nace de la necesidad de asegurar
lineamientos de calidad de las empresas de
desarrollo de Software, debido a que existía una
problemática generada principalmente por una
mala planeación de desarrollo, por lo cual se
decidió licitar un proyecto para estandarizar
dichos lineamientos ( Licitación ganada por la
Universidad Carnegie Mellon de Pittsburgh
Pensilvania ), y que esto pudiera servir como
instrumento de medición para clasificar el niveles
de madurez de cada paso dentro del proceso de
desarrollo de SW.

13. CMM consta de cinco niveles
Inicial
Repetible
Definido
Cuantitativamente
gestionado
Optimizado

14. Nivel 1 o Nivel inicial CMM
En este nivel se encuentran clasificadas
todas las empresas que no tienen
plantación de procesos para desarrollo, por
lo tanto se crea una gran problemática en
serie como presupuestos altos, no es
posible entregar el proyecto en fechas que
no se establecieron, el trabajo que realiza
el personal carece de objetivo, o es
cambiante. No existe control sobre el
estado del proyecto, etc.

15. CMM NIVEL REPETIDO
En este nivel las organizaciones disponen
de unas prácticas institucionalizadas de
gestión de proyectos, existen unas métricas
básicas y un razonable seguimiento de la
calidad. La relación con subcontratistas y
clientes está gestionada sistemáticamente.

16. CMM NIVEL DEFINIDO
Definido. Además de una buena gestión de proyectos,
a este nivel las organizaciones disponen de correctos
procedimientos de coordinación entre grupos,
formación del personal, técnicas de ingeniería más
detalladas y un nivel más avanzado de métricas en
los procesos. Se implementan técnicas de revisión
por pares (peer reviews).
En este nivel de madurez, se recomienda evaluar la
complejidad de los requerimientos, el diseño, el
código y los planes de prueba, y evaluar la calidad de
los requerimientos del diseño del código y de las
pruebas. En términos de complejidad, se sugiere que
los siguientes puntos se midan a este nivel:

17. 1. Complejidad de los requerimientos (Número de
distintos objetos y acciones llevadas a cabo en los
requerimientos).
2. Complejidad del Diseño (Número de módulos de
diseño, Complejidad Ciclomática, Complejidad de
Diseño de McCabe.
3. Complejidad del Código (Números de Módulos
de Código, Complejidad Ciclomática.
4. Complejidad de las pruebas (Número de
Caminos a probar, Si el desarrollo es orientado a
objetos, debe de considerarse el número de
interfaces de objetos a probar.

18. Se puede evaluar la minuciosidad de las pruebas. Así, por
mencionar algunas métricas recomendadas de calidad,
podemos decir las siguientes:
a) Defectos descubiertos,
b) Defectos descubiertos por unidad de tamaño (densidad
de defectos)
c) Fallas de requerimientos descubiertos,
d) Fallas de diseño descubiertas,
e) Fallas de Código descubiertas,
f) Densidad de fallas por cada producto. Se enfatiza que
este conjunto no es representativo del espectro completo
de medidas que pueden ser empleadas. Aspectos tales
como facilidad de mantenimientos, grado de utilización
facilidad de uso y otros atributos de calidad de software
que no son considerados por la cuenta de defectos.

19. CMM NIVEL ADMINISTRADO
Se caracteriza porque las organizaciones
disponen de un conjunto de métricas
significativas de calidad y productividad,
que se usan de modo sistemático para la
toma de decisiones y la gestión de riesgos.
El software resultante es de alta calidad.

20. CMM NIVEL OPTIMIZADO
La organización completa está volcada en
la mejora continua de los procesos. Se hace
uso intensivo de las métricas y se gestiona
el proceso de innovación.

21. ● En un procesador de textos, elaborar un documento
donde describa tu punto de vista con respecto al
tema, envíalo por correo electrónico a tu profesor.