1. CONTENIDO
PÁG.
CONTENIDO ....................................................................................... 1
Introducción ...................................................................................... 3
1 Conceptos Básicos de Calidad ......................................................... 4
1.1 Definición de la calidad. ................................................................. 4
1.2 Definición de calidad de software. ................................................... 5
1.3 ¿Quién define la calidad? ............................................................... 6
1.4 Importancia de la calidad. ............................................................. 9
1.5 La calidad y el mundo globalizado ................................................. 12
1.6 Calidad de vida. ......................................................................... 14
1.7 Calidad Total .............................................................................. 16
1.8 Preguntas de repaso y prácticas sugeridas. .................................... 19
2 Aseguramiento de la Calidad del Software (SQA) ......................... 21
2.1 Relación de la Ingeniería del Software con SQA. ............................. 22
2.2 Definición y propósito del SQA. .................................................... 24
2.4 Calidad del software en el ciclo de vida del mismo .......................... 26
2.5 Roles y responsabilidades de los equipos de desarrollo. ................... 31
2.6 Habilidades y capacidades del personal del SQA ............................. 37
2.7 Actividades del SQA. ................................................................... 40
2.8 Métodos y herramientas. ............................................................. 41
2.9 Enfoque de Procesos en el Desarrollo de software ........................... 43
2.9.1 Definición de Proceso y Enfoque de procesos ............................ 44
2.9.2 Capacidad de proceso de software .......................................... 47
2.9.3 Madurez del proceso de software ............................................ 47
2.9.4 Modelos de proceso PSP y TSP ................................................ 47
2.10 Preguntas de repaso y prácticas sugeridas. .................................. 56
3 Estándares de calidad aplicados al software. ................................ 58
3.1 ISO........................................................................................... 58
3.1 SPICE ....................................................................................... 62
3.3 CMM (Capability Maturity Model.................................................... 73
3.3.2 Nivel inicial .......................................................................... 79
1
2. 3.3.3 Nivel repetido ....................................................................... 81
3.3.5 Nivel administrado. ............................................................... 89
3.3.6 Nivel optimizado. .................................................................. 91
3. 4 MOPROSOFT ........................................................................... 103
4 Calidad enfocada al desarrollo de software. ................................ 123
4.1 ¿Qué es la calidad del software? ................................................. 123
4.2 Cómo obtener calidad de software. ............................................. 124
4.3 Cómo controlar la calidad del software. ....................................... 125
4.4 Costo de la calidad del software. ................................................ 126
4.5 Nomenclatura y certificación ISO 9001:2000................................ 129
4.6 La norma ISO/IEC 9126 ............................................................ 134
4.7 Análisis de factores que determinan la calidad del software............ 136
4.8 Análisis del proceso del ciclo de vida del software ......................... 138
4.9 Funciones de evaluación del software .......................................... 139
4.10 Preguntas de repaso y prácticas sugeridas. ................................ 144
ANEXOS ......................................................................................... 145
Anexo 1: Tareas por roles y fases de desarrollo ................................. 145
Anexo 2 Formato para planeación y registro de tiempo individual ......... 151
Anexo 3 Formato auxiliar para postmortem y lecciones aprendidas. ..... 152
Anexo 4 Entrevistas realizadas a profesionistas del área de calidad y
desarrollo de software. ................................................................... 157
Anexo 5 Referencias ....................................................................... 164
2
3. Introducción
La calidad de los productos y servicios de software son una necesidad creciente
para todo tipo de usuarios de los mismos; por lo tanto es un factor de
competitividad de las empresas que los desarrollan y ofrecen ya que han de
satisfacer las necesidades de sus clientes, no sólo para continuar en el
mercado, sino, además para conseguir la superioridad, el liderazgo como una
meta empresarial.
La industria de software es un sector donde el concepto de calidad total ha
generado la revolución más radical, siendo la producción industrial de software
una actividad con alta participación de recursos humanos, cien por ciento
intelectual y en cierto sentido sin insumos ni materias primas.
Existen desarrolladores quienes continúan creyendo que la calidad es algo en lo
que se debe comenzar a preocupar hasta después de que se ha generado el
código pero hay que tomar conciencia que la calidad se aplica a lo largo del
proceso de software.
En el texto que se presenta a continuación trata de auxiliar a los estudiantes y
docentes de nivel superior a comprender los principales conceptos relacionados
con la calidad de software y los estándares definidos a nivel nacional e
internacional.; para que a su vez puedan ser aplicados en los proyectos en los
que se contemple el desarrollo de software.
Agradezco las colaboraciones de la empresa ADQUEM, a Luis Carlos Vargas
Herring (Microsoft USA), José Arturo Mora Soto (Universidad Carlos III
España), María del Rocío Patiño Palacios (IMB Gdl. México), Fernando Nuñez
Rojas (ITESI), Julio Armando Asato España (ITC), todos ellos exalumnos del
Instituto Tecnológico de Celaya, quienes me brindaron su apoyo y experiencia
para elaborar el presente texto.
3
4. 1 Conceptos Básicos de Calidad
1.1 Definición de la calidad.
Para comprender lo que es la calidad de software, debemos definir
primeramente los conceptos ―calidad‖ y ―software‖
Software:
El software es un elemento lógico, en lugar de físico, de un sistema, por lo
tanto tiene características diferentes a las del hardware, para este primer
capítulo y para compenetrarlo mejor con el concepto de calidad, definamos que
el software es un producto especial, el cual se desarrolla, se construye a la
medida para satisfacer la necesidad de un cliente o usuario.
Calidad:
El término calidad por si mismo, es subjetivo, ¿Qué quiere decir esto? Que si
quisiéramos definirla se obtendrían opiniones distintas, ya que un producto o
servicio puede ser juzgado de manera diferente dependiendo de la percepción
de cada persona, de la educación que tiene, su edad , experiencia, aspectos
emocionales o estados de ánimo entre otros factores.
Una definición de la misma podrá ser:
“La totalidad de características de un producto o servicio que se refieren a su
habilidad para satisfacer necesidades establecidas o implicadas.”
4
5. 1.2 Definición de calidad de software.
La calidad del software se define como:
Concordancia con los requerimientos funcionales y de rendimiento
explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente.
La definición anterior sirve para enfatizar tres puntos importantes:
1. La falta de concordancia con los requerimientos es falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de
desarrollo que guían la forma en que se aplica la ingeniería del software.
3. Al no seguir esos criterios, casi siempre se dará una falta de calidad.
Existe un conjunto de requerimientos implícitos que a menudo no se
mencionan (p. ej. Tener un buen mantenimiento). Si el software se ajusta a
sus requerimientos explícitos pero falla en alcanzar los requerimientos
implícitos, la calidad del software queda en entredicho.
El American Heritage Dictionary define Calidad como ―una característica o
atributo de algo‖. Como atributo de un elemento, la calidad se refiere a
características mensurables, es decir: cosas que se pueden comparar para
conocer estándares, como longitud, color, propiedades eléctricas y
maleabilidad, sin embargo el software, principalmente una entidad intelectual,
es más difícil de caracterizar que los objetos físicos.
5
6. Cuando se examina un elemento con base en sus características mensurables
se pueden encontrar dos tipos de calidad: calidad de diseño y calidad de
concordancia.
La calidad de diseño se refiere a las características que los diseñadores
especifican para un elemento. La calidad de concordancia es el grado en el que
las especificaciones de diseño se aplican durante la fabricación.
En el desarrollo de software, la calidad del diseño incluye requisitos,
especificaciones y el diseño del sistema, La calidad de concordancia es un tema
enfocado principalmente en la implementación. Si ésta sigue el diseño y el
sistema resultante satisface sus requisitos y metas de desempeño, la calidad
de concordancia es alta.
1.3 ¿Quién define la calidad?
Debe entenderse que en cuestión de la percepción del servicio o producto final,
el usuario es quien define la calidad; debiendo la empresa complacer a los
clientes, y no contentarse sólo con librarlos de sus problemas inmediatos, sino
ir más allá para entender a fondo sus necesidades presentes y futuras, a fin de
sorprenderlos con productos y servicios que ni siquiera imaginaban. Este
conocimiento ya no debe ser sólo del dominio exclusivo de grupos especiales de
una organización; sino que debe ser compartido y desarrollado por todos los
empleados.
Una empresa que define la calidad sin tomar en cuenta a los consumidores
corre con el riesgo de producir bienes y servicios con escasa o nula demanda,
ya sea porque los clientes tienen otras expectativas y necesidades, o bien
porque los competidores están generando bienes con un mayor valor agregado.
Por tales motivos es esencial para las empresas practicar tanto la investigación
de mercado, como la inteligencia competitiva y una evaluación comparativa.
6
7. Conocidos los deseos y necesidades de los consumidores, estos deben ser
traducidas en términos cuantitativos y tangibles. Este proceso de traducción no
es sencillo y requiere de la integración de conocimientos de mercadotecnia con
ingeniería y administración, para que las necesidades del consumidor y las
expectativas que desarrolló durante el proceso de selección del producto,
puedan ser satisfechas completamente. Entre la técnica más importante para
tales fines tenemos el Despliegue de la Función de Calidad (QFD), el cual sirve
para realizar todo este proceso de traducción, ayudando a que la voz del cliente
se despliegue a través de toda la organización.
La función de despliegue de la calidad tiene como objetivo asegurar que se
cumplan las expectativas del cliente desde el diseño del producto, durante su
proceso de manufactura, y hasta que es utilizado por el consumidor. En
japonés se le llama ―ten-kai‖ lo cuál significa ―despliegue‖, refiriéndose a la
idea de llevar las necesidades y expectativas del cliente expresados en su
lenguaje (voz del cliente) a todos los involucrados en la organización, e ir en
Cada etapa ―traduciéndolas‖ al lenguaje apropiado.
Los estándares o metodologías definen un conjunto de criterios de desarrollo
que guían la forma en que se aplica la ingeniería del software. La calidad del
software la define o avala una Gestión de la calidad del software por ejemplo:
ISO 9000, esto como política de calidad, se entiende como un conjunto de
actividades de la función general de la dirección que determina la calidad, los
objetivos, el control de la calidad. Algunos de varios estándares para software
provienen de ISO 9000 quien rige la calidad mundial. En seguida se muestra
una tabla con los diversos estándares ISO, en capítulos posteriores hablaremos
de ISO y otros estándares a nivel nacional e internacional.
7
8. Estándar o Especificación ENFOCADO A:
Ingeniería de Software - Calidad de producto- Modelos de
ISO/IEC 9126–1
calidad.
Ingeniería de software - Calidad de producto- Calidad en
ISO/IEC TR 9126–4
métricas de uso.
ISO 9241–11 Guías en Usabilidad.
Usabilidad en productos de cada día. interfaz e
Especificaciones ISO 20282
interacción
Ingeniería de software- Calidad de producto- Métricas
ISO/IEC TR 9126–2
externas.
Requisitos ergonómicos para trabajo en oficinas y
Especificaciones ISO 9241
terminales de trabajo.
Ingeniería de software- Calidad de producto- Métricas
ISO/IEC TR 9126–3
internas.
Especificaciones
Interacción de Diálogo - Control del cursor en edición de
textos.
ISO/IEC 10741–1
Requisitos ergonómicos para oficinas con terminales
ISO 9241
visuales.
Especificaciones
Iconos, símbolos y funciones.
ISO/IEC 11581
ISO 11064 Diseño ergonómico para centros de control.
Especificaciones
Requisitos ergonómicos de trabajo de paneles planos.
ISO 13406
ISO 14915 Ergonomía de software para interfaz multimedia.
Especificaciones
Interfaz de escritura manual. Interacción
ISO/IEC 14754
Guías de interfaz de usuario en equipos multimedia de uso
IEC TR 61997
general.
Especificaciones
Interfaz de usuario para dispositivos móviles.
ISO/IEC 18021
Requisitos ergonómicos y sistemas métricos para
ISO 18789
pantallas. Documentación
8
9. Estándar o Especificación ENFOCADO A:
Guías para el diseño y preparación de documentación de software de
ISO/IEC 18019
usuario.
Especificaciones
Documentación de procesos de software. de usuario proceso de
desarrollo
ISO/IEC 15910
ISO 13407 Diseño de procesos interactivos.
Evaluación de software.
ISO/IEC 14598
Métodos de soporte de diseños centrados en usuarios. capacidad de
ISO TR 16982
la empresa
ISO TR 18529 Procesos descriptivos de vida de producto, otros ISO
Introducción general.
ISO 9241–1
Guía en requisitos de acciones.
ISO 9241–2
Principios ergonómicos de carga mental, términos y definiciones.
iSO 10075–1
Guía de accesibilidad en interfaz de usuario.
iSO DTS 16071
1.4 Importancia de la calidad.
Es posible hacerlo bien a hacerlo de nuevo otra vez, si un equipo de software
subraya la calidad en todas las actividades de ingeniería del software, ello
reduce la cantidad de reelaboración que se debe realizar además de los
consecuentes beneficios que se pueden obtener como a continuación se
describe.
9
10. BENEFICIOS PARA LOS CLIENTES
• COSTO DE OPORTUNIDAD CONTROLADO
Dependiendo de la importancia de la aplicación solicitada, no contar con la
misma en el momento previsto, puede ocasionar pérdidas considerables, tanto
económicas como de imagen.
• EFICIENCIA EN LA OPERATORIA DEL DÍA A DÍA
Contar con una aplicación desarrollada bajo estándares de calidad asegurados,
garantiza la estabilidad del software, evitando interrupciones en las actividades
del negocio por defectos del sistema.
• AUMENTO EN LA PRODUCTIVIDAD
Una aplicación bien diseñada y desarrollada, facilita las actividades de trabajo
diarias, aumentando la productividad en tareas administrativas, productivas y
de control entre otras.
• REDUCCIÓN EN LOS COSTOS OPERATIVOS
La implementación de software de calidad, evita costos asociados a eventos
tales como caídas del sistema, demoras en la atención a clientes, pérdidas de
información vital del negocio.
10
11. PARA EL ÁREA DE IT
• REDUCCIÓN DE COSTOS DE DESARROLLO
Principalmente costos asociados a la no calidad, que se traducen en muchas
horas dedicadas a corregir errores de aplicaciones que ya está en producción,
necesidad de más recursos humanos para poder cumplir con los plazos
establecidos para la finalización de los proyectos y, quizás el más grave,
pérdidas económicas a nivel negocio por errores funcionales y conceptuales en
las aplicaciones.
• CLIENTES INTERNOS SATISFECHOS
Porque entregar software en tiempo y alineado con las expectativas del cliente
o usuario, genera una imagen de profesionalismo del área de IT y trasmite
confianza al resto de la organización.
• MAYOR DISPONIBILIDAD DE RECURSOS HUMANOS
Porque al eliminar los tiempos invertidos en volver a realizar el trabajo, por
cuestiones asociadas a la no calidad, baja considerablemente el número de
horas invertidas en cada proyecto, liberando anticipadamente los recursos
asignados a un determinado proyecto y dejándolos disponibles para comenzar
los próximos.
• MEJOR ORGANIZACIÓN E INTEGRACIÓN DE LOS EQUIPOS DE TRABAJOS
Desarrollar software en base a un proceso estandarizado y repetitivo, permite
controlar eficientemente varios equipos de trabajo.
11
12. 1.5 La calidad y el mundo globalizado
En un contexto dinámico y competitivo, la Calidad se ha convertido para las
organizaciones actuales en uno de los pilares para alcanzar el éxito. Y el
talento que reside en el Capital Humano de las organizaciones resulta
fundamental para hacer realidad los programas de Calidad
El mundo globalizado ha permitido que la competencia y el flujo de
conocimiento se incrementen en un ritmo vertiginoso, lo que ha traído
aparejado una evolución del cliente, quien hoy por hoy es mucho más
exigente que en tiempos pasados.
Ante este panorama, las organizaciones han adoptado a la Calidad como una
respuesta al entorno en el que se encuentran inmersas, como una forma de
mantener la competitividad y elevar la productividad, maximizando su
rentabilidad. Términos como Excelencia, Calidad Total, Mejora Continua,
Satisfacción del Cliente y otros se han convertido en vocabulario habitual de
quien forma parte de una organización.
Diversos autores han definido a la calidad de diferentes maneras, pero la
gran mayoría coincide en un punto fundamental: Calidad en una organización
supone el cumplimiento de ciertos requisitos, los cuáles son determinados en
función de las necesidades del cliente. Una organización que administra un
Sistema de Calidad recoge información acerca de las necesidades del cliente,
la registra y procesa, obteniendo los resultados necesarios que le permiten
tomar decisiones concernientes a la modificación de sus prácticas actuales
para adaptar su producto/servicio a lo que verdaderamente requiere el
cliente.
Estas prácticas son evaluadas mediante la utilización de índices que miden
los resultados de la organización en varios de sus procesos, ya que el
12
13. principio fundamental de la Calidad es que no se puede mejorar lo que no se
puede medir.
Una organización que se introduce en el tema de la Mejora Continua y la
Calidad define una estructura organizativa para tal. De esta manera,
comienza con la concepción de una Visión, punto de partida para la
generación de la Conciencia de Calidad. Esto plantea el requisito fundamental
de contar con el compromiso de quienes toman decisiones dentro de la
organización. En otras palabras, los esfuerzos para adoptar la Gestión de
Calidad Total son inútiles si la alta dirección no está comprometida.
Con el compromiso gerencial, la organización está en condiciones de
transferir la Visión de Calidad hacia todos los niveles de la organización,
definiendo una Misión, políticas, sistemas y programas de calidad. Esto
plantea la necesidad de ―educar‖ a los recursos humanos transfiriendo los
valores, factor imprescindible para instalar un modelo de gestión de estas
características en cualquier organización. Por esta razón, la Calidad está
estrechamente relacionada con el capital humano de una organización: no
puede haber calidad si no se cuenta con recursos humanos de calidad. En
otras palabras, una organización no podrá obtener productos o brindar
servicios de calidad, sino cuenta con calidad humana.
Cuando hablamos de calidad humana nos referimos al Talento, elemento
fundamental que debe poseer todo recurso humano que forme parte de una
organización. El talento de los recursos humanos está dado por una serie de
factores como la capacitación, sus valores, el potencial, su sentido de
responsabilidad, etc. De esta manera, una organización que posee un capital
humano de calidad (recursos humanos talentosos) y ha creado una
conciencia de calidad entre los mismos, puede decirse que es poseedora de
una ventaja competitiva muy importante.
13
14. Una organización solo puede considerarse de Calidad cuando está compuesta
por personas de Calidad, quienes aplican los valores de trabajar en equipo,
actuar con prevención, planificar bien para ejecutar mejor, aprender y
desarrollarse, comunicarse con eficacia, enfocarse a servir a sus clientes y
mejorar continuamente. Una organización de estas características adopta
una cultura de confianza, lo que la lleva inevitablemente a la capacitación, al
trabajo en equipo y a la auto dirección.
En definitiva, Calidad implica la determinación de las actividades que se
deben realizar, el conocimiento de los requisitos a cumplir, el adiestramiento
sobre esos requisitos, el cumplimiento estricto de los mismos, el compromiso
y predisposición positiva al trabajo y finalmente la vocación de servicio de
todo el capital humano de una organización. Por esta razón podemos afirmar
que la Conciencia de Calidad dentro de la organización es la base para la
transformación de la organización en función de los requisitos establecidos
por el análisis de las necesidades y demandas del cliente, lo cual se logra
mediante el conocimiento (la Visión Compartida), el entendimiento del
cliente y la mejora de procesos.
1.6 Calidad de vida.
La palabra calidad se deriva de cualidad que significa cada una de las
circunstancias o caracteres superiores y excelentes que distinguen a las
personas y cosas.
Vida significa: ―Fuerza interna substancial en virtud de la cual obra el ser que
la posee. Conducta o método de vivir con respecto a las acciones de los seres
humanos‖ .
14
15. La calidad de vida es un concepto que va más allá de lo físico pues implica
valores y actitudes mentales. La calidad de vida es un estado positivo desde
todos los puntos de vista. Es estar en la plenitud, es poder funcionar ciento
por ciento.
o Físicamente, significa encontrarse en buenas condiciones, fuerte, resistente
a las enfermedades o poder sobreponerse rápidamente a ellas.
o Psíquicamente, es poder disfrutar, hacerse cargo de las responsabilidades,
combatir la tensión nerviosa y el estrés.
o Emocionalmente, es estar en paz. La persona que mantiene su calidad de
vida es una persona que se siente bien, vigorosa, entusiasmada, con la
sonrisa propia del que se siente bien en todas sus dimensiones.
La calidad de vida es el bienestar, felicidad, satisfacción de la persona que le
permite una capacidad de actuación o de funcionar en un momento dado de
la vida.
La calidad de vida es: "la percepción que un individuo tiene de su lugar en la
existencia, en el contexto de la cultura y del sistema de valores en los que
vive y en relación con sus objetivos, sus expectativas, sus normas, sus
inquietudes.
15
16. La calidad de vida tiene su máxima expresión en la calidad de vida
relacionada con la salud. Las tres dimensiones que global e integralmente
comprenden la calidad de vida son:
Dimensión física: Es la percepción del estado físico o la salud, entendida
como ausencia de enfermedad, los síntomas producidos por la
enfermedad, y los efectos adversos del tratamiento. No hay duda que
estar sano es un elemento esencial para tener una vida con calidad.
Dimensión psicológica: Es la percepción del individuo de su estado
cognitivo y afectivo como el miedo, la ansiedad, la incomunicación, la
pérdida de autoestima, la incertidumbre del futuro. También incluye las
creencias personales, espirituales y religiosas como el significado de la
vida y la actitud ante el sufrimiento.
Dimensión social: Es la percepción del individuo de las relaciones
interpersonales y los roles sociales en la vida como la necesidad de apoyo
familiar y social, la relación médico-paciente y el desempeño laboral.
1.7 Calidad Total
El término TQM (Total Quality Management) se acuña en 1985 para describir
el estilo japonés de incremento de calidad. Representa un estilo de gestión
movido por conseguir éxito a largo plazo enlazando calidad y satisfacción de
usuario.
Es básica la creación de una cultura en la que todos los miembros de la
organización quienes participan en la mejora de procesos, productos y
servicios.
La adopción de ISO 9000 como estándar de gestión de calidad en la Unión
Europea ilustra la importancia de esta filosofía.
Ejemplos implementación exitosa de una estrategia TQM:
16
17. Hewlett-Packard’s Total Quality Control (TQC):
Define estrategias y planes para cada área (gestión liderazgo, cliente,
participación total, etc.) para conducir un incremento de calidad, eficiencia y
responsabilidad.
Motorola’s Six Sigma Strategy.
Se centra en conseguir niveles estrictos de calidad para obtener la
satisfacción del usuario.
IBM’s Market Driven Quality.
Los elementos clave de TQM pueden resumirse en:
Orientado al cliente: el objetivo es conseguir una satisfacción total del
cliente. Incluye estudios de las necesidades de los clientes, recolección de
requisitos de cliente, medida y gestión de su nivel de satisfacción.
Procesos: el objetivo es reducir las variaciones del proceso y conseguir
una mejora continua del proceso. Incluye tanto los procesos de negocio
como los procesos de desarrollo del producto. A través de la mejora de
los procesos se mejora la calidad del producto.
Parte humana de la calidad: el objetivo es crear una cultura de calidad
global a la compañía. Áreas objetivo son: dirección, participación total,
otorgar poderes a los empleados y otros factores sociales, psicológicos y
humanos.
17
18. Medida y análisis: el objetivo es conducir la mejora continua en todos
los parámetros de calidad, utilizando el sistema de medidas orientadas al
objetivo.
Una organización que practique TQM debe tener una jefatura ejecutiva, y debe
centrarse en infraestructura, entrenamiento y educación, además de realizar
planificación estratégica de calidad.
Se han definido varios marcos organizacionales para sustanciar la filosofía
TQM:
Plan-Do-Check-Act.
Proceso de mejora de la calidad basado en un ciclo de retroalimentación para
optimizar un único proceso de producción.
Quality Improvement Paradigm (QIP).
Pretende construir una organización que mejora continuamente, basándose en
sus objetivos evolutivos y el aseguramiento de su estado relativo a esos
objetivos.
SEI Capability Maturity Model. (CMM)
Proceso de mejora dividido en fases. Basado en la valoración con respecto a un
conjunto áreas clave de proceso. El objetivo es el nivel 5 donde se alcanza una
mejora continua de procesos. El objetivo es conseguir mejora continua de
procesos mediante prevención de defectos, innovaciones tecnológicas y gestión
del cambio de procesos. En capítulos posteriores se abarcará con mas detalle
este modelo.
Leas Enterprise Management.
Basado en el principio de concentración de la producción en actividades de
valor añadido.
18
19. 1.8 Preguntas de repaso y prácticas sugeridas.
1 Buscar en Internet artículos relacionados con el arranque de un proyecto
de desarrollo de software y recomendaciones dadas por las empresas o
profesionistas del ramo.
2. Formar equipos en donde se asignen a los participantes distintos roles de
trabajo para el desarrollo de un producto. Es importante que los
integrantes de cada equipo identifiquen cuales son las tareas que les son
asignadas y como se relacionan con otros roles, en que tareas tienen más
habilidades y en cuales requerirán capacitación.
3. Realizar un diagrama o esquema en donde se identifiquen los procesos
principales que abarcará el producto de software a construir.
4. Mediante un ejemplo ilustra el porque el concepto de calidad puede ser
subjetivo.
5. Mediante un ejemplo ilustra como la calidad de vida puede influir para la
construcción del software con calidad.
6. Buscar en Internet diversos puntos de vista que las empresas y
profesionistas tienen acerca del concepto de calidad, calidad de software,
impacto de la calidad en su calidad de vida.
7. Investigar mas sobre PSP y TSP, hacer una breve presentación indicando
los beneficios que se pueden tener al aplicar estos modelos al desarrollo
del software.
19
20. 8. Investigar y hacer una presentación sobre las empresas que han
implantado la filosofía TQM (calidad total) , discutir que ventajas puede
representar para la industria de software.
9. Discutir en equipo sobre la importancia de la calidad para el desarrollo
de un producto de software.
10. Investigar los siguientes conceptos: Control de calidad, garantía de
calidad, costo de calidad. Discuta en grupo en que fase del ciclo de vida
del software se aplican estos conceptos.
11. Investigar cuales son los organismos encargados de certificar los
procesos de calidad del software en nuestro país.
20
21. 2 Aseguramiento de la Calidad del Software (SQA)
La función de aseguramiento de la calidad tiene como finalidad primaria el
determinar si las necesidades de los usuarios están siendo satisfechas
adecuadamente. Otra de sus funciones, aunque no se tocará mucho en la
presente investigación, es la de determinar los costos que puede causar el
añadir ciertas características al producto, ya que tarde o temprano, la
economía resulta ser un factor decisivo para obtener un producto de calidad.
Para determinar si las necesidades de los usuarios están siendo satisfechas, se
deben de evaluar tres áreas:
Objetivos: Los objetivos de la organización son primero, luego vienen los
requerimientos del usuario. Los objetivos de cualquier usuario deben de estar
en armonía con los objetivos de la organización,
Métodos: Deben de utilizarse métodos que contengan u observen las políticas,
procedimientos y estándares de la organización,
Ejecución: Optimización del uso de hardware y software al implementar los
productos de software.
Para evaluar las áreas expuestas con anterioridad, es necesario que se cuente
con un programa de aseguramiento de calidad que sea efectivo y que tenga un
impacto dentro del desarrollo y prueba del producto de software final.
21
22. 2.1 Relación de la Ingeniería del Software con SQA.
El IEEE[IEEE93] define a la ingeniería del software como:
“La aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento del software; es decir la aplicación de la
ingeniería al software.”
La ingeniería de software es una tecnología estratificada, como se muestra en
la siguiente figura:
HERRAMIENTAS
METODOS
PROCESO
UN ENFOQUE DE CALIDAD
Fig. 1. Estratos de la ingeniería del software
Cualquier enfoque de la ingeniería (incluido el de la ingeniería del software)
debe estar sustentado en un compromiso con la calidad.
La gestión de la Calidad total, Seis Sigma y enfoques similares fomentan una
cultura de mejora continua del proceso, y es esta cultura la que al final
conduce al desarrollo de enfoques muy efectivos para la ingeniería del
software. La base que soporta a la ingeniería del software es un enfoque en la
calidad.
La base de la ingeniería del software es el estrato del proceso. El proceso de la
ingeniería del software es el elemento que mantiene juntos los estratos de la
tecnología y que permite el desarrollo racional y a tiempo del software de
computadora.
22
23. El proceso define un marco de trabajo que debe establecerse para la entrega
efectiva de la tecnología de la ingeniería del software. El proceso del software
forma la base para el control de la gestión de los proyectos de software y
establece el contexto en el cual se aplican los métodos técnicos, se generan los
productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.),
se establecen los fundamentos, se asegura la calidad, y el cambio se maneja
de manera apropiada.
Más adelante se abordarán los temas referentes a proceso y el enfoque de
procesos para de esta forma comprender mejor los enfoques de calidad que se
mencionaron en el párrafo anterior.
Los métodos de la ingeniería del software proporcionan los ―cómo‖ técnicos
para construir software, Los métodos abarcan un amplio espectro de tareas que
incluyen la comunicación, el análisis de requisitos, el modelado del diseño, la
construcción del programa, la realización de pruebas y el soporte. Los métodos
de la ingeniería del soltare se basan en un conjunto de principios básicos que
gobiernan cada área de la tecnología e incluye actividades de modelado y otras
técnicas descriptivas.
Las herramientas de la ingeniería del software proporcionan el soporte
automatizado o semiautomatizado para el proceso y los métodos. Cuando las
herramientas se integran de forma que la información que cree una de ellas
pueda usarla otra, se dice que se ha establecido un sistema para el soporte del
desarrollo del software, que con frecuencia se denomina ingeniería del software
asistida por computadora.
23
24. 2.2 Definición y propósito del SQA.
Antecedentes:
El control y la garantía de la calidad son actividades esenciales en cualquier
negocio que elabore productos de consumo. Antes del siglo XX el control de la
calidad era responsabilidad exclusiva del empresario que fabricaba un
producto. La primera función formal de garantía y control de la calidad la
introdujeron los Laboratorios Bell en 1916 y se extendió tan rápidamente a
través del mundo industrial. Durante el decenio de 1940 surgieron enfoques
mas formales del control de la calidad los cuales se apoyaban en la medición y
la mejora continua de los procesos como los elementos clave la gestión de la
calidad.
La historia de la garantía de la calidad en el desarrollo de software avanza
paralela a la de la calidad en la fabricación de hardware. Durante los primeros
días de la computación (décadas de 1950 y 1960), la calidad era
responsabilidad exclusiva del programador. Los estándares de garantía de
calidad para el software se introdujeron en los contratos militares de desarrollo
de software durante el decenio de 1970 y se han extendido rápidamente en el
desarrollo del software en el mundo de los negocios.
Definición y propósito:
Si se extiende la definición presentada anteriormente, la garantía de la calidad
del software es un ―patrón de acciones sistemático y planificado‖ que se
requiere para garantizar alta calidad en el software. Numerosos participantes
tienen responsabilidad en la garantía de la calidad del software: ingenieros de
24
25. software, gestores de proyecto, clientes, vendedores y los individuos que
integran el grupo de SQA.
La calidad de un producto debe asegurarse, la Garantía de Calidad del
software SQA (Software Quality Assurance), es una actividad de protección
que se aplica a todo el proceso de ingeniería del software, englobando los
siguientes aspectos:
Enfoque de gestión de calidad.
Tecnología de ingeniería del software efectiva.
Revisiones técnicas formales que se aplican durante el proceso del
software.
Estrategia de prueba multiescalada.
El control de la documentación del software y de los cambios realizados.
Procedimiento que asegure un ajuste a los estándares de desarrollo del
software.
Mecanismos de medición y de generación de informes.
2.3 Problemas que resuelve el SQA.
El grupo de SQA funciona como el representante en casa del cliente. Es decir
las personas que realizan el SQA deben observar el software desde el punto de
vista del cliente.
Existen gran variedad de tareas, realizadas tanto por los ingenieros de software
como por el grupo de SQA.
Los ingenieros realizan el trabajo técnico, aplicando métodos sólidos y
medidas, realizando revisiones y llevando a cabo pruebas de software.
25
26. El grupo de SQA realiza tareas de ayuda al equipo de ingenieros,
planifican el proceso de garantía de calidad, supervisión,
mantenimiento de registros, análisis e informes.
Establecimiento de un plan de SQA para un proyecto.
Participación en el desarrollo de la descripción del proceso de software
del proyecto.
Revisión de las actividades de ingeniería del software para verificar su
ajuste al proceso de software definido.
Auditoría de los productos de software designados para verificar el
ajuste con los definidos como parte del proceso de software.
Asegurar que las desviaciones del trabajo y los productos del software
se documenten y se manejen de acuerdo con un procedimiento
establecido.
Registrar lo que no se ajuste a los requisitos e informar a sus
superiores.
2.4 Calidad del software en el ciclo de vida del mismo
Ciclo de vida del software:
Aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación
y el mantenimiento del software. (norma IEEE 1074) [IEEE, 1999]
El ciclo de vida incluye:
Ciclo de desarrollo del sistema y Tiempo de vida del sistema
26
27. Modelo de ciclo de vida:
Marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el mantenimiento de un producto
de software, abarcando la vida del sistema desde la definición de los requisitos
hasta la finalización de su uso (norma ISO 12207-1) [ISO/IEC, 1995].
Objetivos
Proporcionar una estrategia de desarrollo y un enfoque sistemático en la
realización de las actividades de desarrollo y mantenimiento de un
sistema, ayudar a fijar objetivos. Y permitir un seguimiento de las
necesidades de recursos, las actividades del ciclo de vida del software se
pueden agrupar de la forma siguiente (norma ISO 12207-1) [ISO/IEC,
1995]:
PROCESOS PRINCIPALES PROCESOS DE SOPORTE
Adquisición Documentación
Gestión de la configuración
Suministro
Aseguramiento de la calidad
Verificación
Validación
Explotación Revisión Conjunta
Desarrollo Auditoría
Mantenimiento Resolución de problemas
PROCESOS DE LA ORGANIZACIÓN
Gestión Infraestructura
Mejora Formación
Fig. 2 Procesos del ciclo de vida.
27
28. Procesos principales:
Son los que resultan útiles a las personas que inician o realizan el desarrollo,
la explotación o el mantenimiento del software durante su ciclo de vida.
Proceso de adquisición Actividades y tareas que se realizan para comprar un
producto software.
Proceso de suministro Actividades y tareas que el suministrador realiza.
Proceso de desarrollo Contiene las actividades de análisis de requisitos, diseño,
codificación, integración, pruebas e instalación y aceptación.
Proceso de explotación Incluye la explotación del software y el soporte operativo a
los usuarios.
Aparece cuando el software necesita modificaciones, ya sea
Proceso de mantenimiento en el código o en la documentación asociada, debido a un
error, una deficiencia, un problema o la necesidad de mejora
o adaptación.
Procesos de soporte Sirven de apoyo al resto y se aplican en cualquier punto del
ciclo de vida.
Proceso de documentación Registra la información producida por un proceso o actividad
en el ciclo de vida.
Proceso de gestión de la Aplica ciertos procedimientos y técnicas durante todo el
ciclo de vida del sistema.
configuración
Proceso de aseguramiento de Aporta la confianza de que los procesos y los productos
software del ciclo de vida cumplen los requisitos
la calidad
especificados y se ajustan a los planes establecidos.
Proceso de verificación Determina si los requisitos de un sistema o del software
están completos y son correctos.
Sirve para determinar si el sistema o software final cumple
con los requisitos previstos para su uso.
Proceso de validación
Proceso de revisión conjunta Sirve para evaluar el estado del software y sus productos en
una actividad del ciclo de vida o una fase de un proyecto.
Proceso de auditoría Permite determinar, en los hitos predeterminados, si se han
cumplido los requisitos, los planes y el contrato.
Proceso de resolución de Permite analizar y eliminar los problemas descubiertos
durante el desarrollo, explotación, el mantenimiento u otro
problemas
proceso.
28
29. Procesos de soporte:
Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida.
Registra la información producida por un
Proceso de documentación:
proceso o actividad en el ciclo de vida.
Aplica ciertos procedimientos y técnicas
Proceso de gestión de la configuración: durante todo el ciclo de vida del sistema.
Aporta la confianza de que los procesos y los
productos software del ciclo de vida cumplen
Proceso de aseguramiento de la calidad los requisitos especificados y se ajustan a los
planes establecidos.
Determina si los requisitos de un sistema o del
Proceso de verificación software están completos y son correctos.
Sirve para determinar si el sistema o software
Proceso de validación final cumple con los requisitos previstos para
su uso.
Sirve para evaluar el estado del software y sus
productos en una actividad del ciclo de vida o
Proceso de revisión conjunta
una fase de un proyecto.
Permite determinar, en los hitos
Proceso de auditoría predeterminados, si se han cumplido los
requisitos, los planes y el contrato
Permite analizar y eliminar los problemas
descubiertos durante el desarrollo,
Proceso de resolución de problemas
explotación, el mantenimiento u otro proceso.
29
30. Procesos de la organización (generales):
Los emplea una organización para llevar a cabo funciones tales como la
gestión, la formación del personal o la mejora del proceso.
Actividades y tareas genéricas que puede
emplear cualquier organización que tenga que
Proceso de Gestión
gestionar sus procesos, incluyendo
planificación, seguimiento y control, y revisión
y evaluación
Establece la infraestructura necesaria para
Proceso de infraestructura
cualquier otro proceso.
Sirve para establecer, valorar, medir,
Proceso de mejora controlar y mejorar los procesos del ciclo de
vida del software.
Sirve para proporcionar y mantener al
Proceso de formación
personal formado.
De los procesos anteriores existe otro muy importante si se requiere hacer la
adaptación a la norma ISO-12207 que debe ser considerado.
Proceso de adaptación:
Sirve para realizar la adaptación básica de la norma ISO-12207 con respecto a
los proyectos software. Es necesario comprender los procesos, las
organizaciones y sus relaciones bajo diferentes puntos de vista:
Bajo el punto de vista del contrato, el comprador y el proveedor negocian
y firman un contrato, empleando los procesos de adquisición y
suministro.
30
31. Bajo el punto de vista de gestión, el comprador, el proveedor, el
desarrollador, el operador y el personal de mantenimiento gestionan sus
respectivos procesos para el proyecto software.
Bajo el punto de vista de explotación, el operador proporciona el servicio
de explotación del software a los usuarios.
Bajo el punto de vista de ingeniería, el desarrollador o el personal de
mantenimiento llevan a cabo sus respectivas tareas de ingeniería para
producir o modificar los productos software
Bajo el punto de vista de soporte, los grupos (tales como el de la gestión
de la configuración, el aseguramiento de la calidad...) proporcionan
servicios de apoyo a otros grupos en el cumplimiento de tareas únicas y
específicas.
2.5 Roles y responsabilidades de los equipos de desarrollo.
¿Qué es un equipo?
―Al menos dos personas quienes están trabajando juntos por una
meta/objetivo/misión común, donde a cada persona se le ha asignado
roles o funciones específicas a desarrollar, y en donde el cumplimiento de
la misión requiere algún tipo de dependencia entre los miembros del
grupo‖ Jean L. Dyer
El desarrollo de software es una actividad que, dada su complejidad, debe
desarrollarse en grupo. Además, esta actividad requiere de distintas
capacidades, las que no se encuentran todas en una sola persona. Por ello, se
hace necesario formar el grupo de desarrollo con las personas que cubran
todas las capacidades requeridas.
31
32. Cada una de esas personas aportará al grupo parte del total de las
capacidades necesarias para llevar a cabo con éxito el desarrollo.
Por ello, es que cada persona debe tener un rol dentro del grupo, que viene
dado por su experiencia y capacidades personales. En este capítulo se
describen los roles que tradicionalmente se consideran en el desarrollo de
software. Estos roles son:
Administrador de proyecto, analista, diseñador, programador, téster,
asegurador de calidad, documentador, ingeniero de manutención, ingeniero
de validación y verificación, administrador de la configuración y por último, el
cliente.
Para cada uno de estos roles, se definen sus objetivos, actividades,
interacción con otros roles, herramientas a utilizar, perfil de las personas en
ese rol y un plan de trabajo. Hay que señalar que es posible que no se
requieran todos los roles en un desarrollo.
Eso dependerá del tamaño y del tipo del desarrollo. Por ejemplo, el desarrollo
de un sistema de información de gran tamaño requerirá más roles que uno de
menor tamaño. Por otro lado, si el tipo del proyecto está enfocado más hacia
la parametrización e integración de sistemas, requerirá algunos roles en
menor medida y otros en mayor.
32
33. Es posible también que una persona realice las labores de más de un rol al
mismo tiempo. Esto, sobre todo en proyectos de desarrollo de software más
pequeños. No obstante, es imprescindible que dichas personas conozcan
completamente todas sus tareas.
Por otro lado, también es posible la situación de tener más de una persona
con un mismo rol en un equipo de desarrollo. Por ejemplo, en sistemas de
complejidad mediana hemos utilizado con éxito la fórmula de tener un
administrador de proyecto, dos analistas, dos diseñadores, dos
programadores y un téster. Eso hace un total de ocho personas en un grupo.
Las actividades de documentación y administración de
configuración son asumidas por todos los roles. Parte de las actividades de
aseguramiento de calidad son asumidas por el téster. El resto de las
actividades no son realizadas.
El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus
responsabilidades y actividades asociadas, hace que se produzcan problemas.
Por un lado, es posible que una o más actividades no estén asociadas a
ningún rol, con lo que el proyecto sufrirá. Por otro lado, es posible que una o
más actividades estén asociadas a más de un rol.
Esto último producirá problemas entre los miembros afectados, lo que
también redunda en problemas en el desarrollo del sistema. Por lo anterior,
se hace necesario que cada miembro conozca muy bien su rol dentro del
proyecto, así como las responsabilidades y actividades asignadas.
Es bastante común que, frente a una oferta de una empresa en busca de
personal calificado para su equipo de desarrollo de software, nos sintamos
atraídos a postular a un rol específico.
33
34. La fábula de la granja
Un día cualquiera, los animales de una granja decidieron hacer una fiesta, con el propósito
de pasar un momento agradable. Para organizar la fiesta, se reunieron el mismo día en la
mañana. Cada animal debía llevar algo a la fiesta. Como es lógico, a la vaca le pidieron la
leche. A la gallina, le tocó llevar los huevos. Y al chancho, el tocino.
En este caso, la vaca y la gallina participan de la fiesta. Sin embargo, el chancho se
encuentra involucrado. Su participación le obliga a entregar parte de si mismo como aporte
para la fiesta. Al chancho le toca aportar una cuota de sacrificio mayor. Lo anterior muestra
la diferencia entre participar en un evento y estar involucrado.
Tomemos esta fábula para caracterizar a los miembros del grupo de un
desarrollo de software. ¿Cómo se comportan, en general? ¿Participan o
están comprometidos en el proceso de desarrollo de software?
Parece claro que lo deseable, desde el punto de vista del problema
completo, es tener integrantes comprometidos.
Pero, ¿cómo se obtienen estos miembros comprometidos? ¿Es posible
―crear‖ miembros del grupo comprometidos? ¿Administrador de proyecto
comprometido, analista comprometido, diseñador comprometido,
programador comprometido, téster comprometido, asegurador de calidad
comprometido, documentador comprometido, ingeniero de manutención
comprometido, ingeniero de validación y verificación comprometido,
administrador de la configuración comprometido y cliente comprometido?
La fábula anterior nos enseña la diferencia entre participar y estar
comprometidos en una actividad. Es claro que para tener miembros del
equipo de desarrollo, comprometidos, es necesario capacitarlos en sus
deberes y derechos en el ciclo de vida del desarrollo de software.
34
35. Es muy poco probable que un miembro no capacitado pueda estar
comprometido con los objetivos del proyecto. Este presentará claras
deficiencias en el momento de participar en el proceso. Como ejemplo, se
mencionan algunas:
1. Un miembro no capacitado no entenderá el lenguaje técnico utilizado por
el resto de los miembros. Muchas veces, entenderá una cosa diferente a la
expresada por sus pares. Esto es común debido a diferencias en el
lenguaje.
2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los
problemas que se presentan durante el desarrollo. Sería muy bueno que el
miembro pudiera aportar sus conocimientos en su dominio del problema
durante todo el ciclo de desarrollo del proyecto. Saber cuando exigir y
cuando ceder, conocer los estándares de desarrollo, de documentación, de
aseguramiento de la calidad.
4. Un miembro no capacitado no presupuesta su involucramiento en el
proyecto, sólo su participación. Este solo hecho reduce las posibilidades
de éxito del proyecto. También aumenta los tiempos de desarrollo,
disminuye la calidad del sistema, aumentan los riesgos de rechazo del
sistema por parte de la comunidad de clientes, etc.
Lo anterior sugiere que es necesario contar con ―miembros comprometidos‖
para desarrollar correctamente el proyecto.
35
36. Aspectos a considerar son :
Crear un lenguaje común entre el equipo de desarrollo, así como hacer
que entiendan claramente sus deberes y obligaciones.
Por otro lado, los clientes también deben estar comprometidos con el
desarrollo. Eso significa que deben conocer el ciclo de vida escogido, cual
es su participación en cada una de las fases del ciclo, y la cantidad de
esfuerzo y recursos que se espera que pongan en cada momento del
proyecto. Es de vital importancia que participen activamente en la etapa
de análisis, así como en todas aquellas actividades de revisión y
aceptación.
En caso que el cliente no tenga dicha experiencia, se hace necesario que
antes de un desarrollo, se los capacite para convertirlos en clientes
comprometidos. Lo anterior requiere de trabajo, pero va en la senda
correcta del éxito de un proyecto de software.
Es claro entonces que todos los integrantes del equipo de desarrollo
debiesen estar comprometidos con el proyecto, incluyendo los clientes.
Lo anterior implica trabajar con el equipo completo en torno a las metas
a lograr, así como las cualidades y características deseables de cada uno
de ellos. Para ello, se requiere entender correctamente las características
de liderazgo dentro de un grupo humano.
36
37. 2.6 Habilidades y capacidades del personal del SQA
El asegurador de calidad debe ser una persona con mucha experiencia en
proyectos de desarrollo de software, con conocimientos suficientes sobre
técnicas que aseguren la calidad de un producto de software. Lo anterior lo
hace capaz de negociar con la calidad del producto, y ocasionalmente,
modificar el criterio de los desarrolladores.
Considerando el Aseguramiento de la Calidad del software como una de las
claves áreas de proceso de CMM nivel 2, las habilidades para el desempeño
para el grupo de Aseguramiento de la calidad del Software son las siguientes:
Habilidad 1: Existe un grupo de Aseguramiento de Calidad que es el
responsable de coordinar e implementar las actividades de garantía de calidad
para el proyecto.
Un grupo se considera como la colección de departamentos, gerentes e
individuos que tienen responsabilidades por un conjunto de tareas o
actividades. Un grupo puede variar desde una o varias personas asignadas a
tiempo parcial de diferentes departamentos, hasta varios individuos dedicados
a tiempo completo. Las consideraciones a tener para implementar un grupo
incluyen las tareas y actividades asignadas, el tamaño de proyecto, la
estructura y la cultura de la organización. Algunos grupos, como el de
aseguramiento de la calidad de software, están enfocados a actividades de
proyectos, y otros como el grupo de ingeniería de procesos de software, están
enfocados a actividades en el ámbito de toda la organización.
37
38. Habilidad 2: Se provee de recursos y financiamiento adecuados para la
realización de las actividades de Aseguramiento de Calidad de Software.
1. Se asigna específicamente un gerente responsable por las actividades de
SQA
2. Un gerente superior, quien es conocedor del SQA y tiene la autoridad de
tomar acciones de control, es designado para recibir y actuar sobre los
ítemes de software no conformes.
3. Se dispone de herramientas de apoyo a SQA como son : estaciones de
trabajo, programas de bases de datos, programas de planilla de cálculo y
herramientas de auditoría.
Habilidad 3: Los miembros del grupo de SQA están capacitados para realizar
las tareas asociadas a esta actividad.
Ejemplos de capacitación incluyen: Practicas y habilidades de ingeniería de
software, roles y responsabilidades del grupo de ingeniería de software y otros
grupos relacionados, métodos, estándares y procedimientos para el proyecto
de software, dominio de la aplicación del proyecto de software, métodos,
procedimientos y objetivos de garantía de calidad, involucramiento del grupo
SQA en las actividades del proyecto, un uso efectivo de los métodos y
herramientas de garantía de calidad, y comunicación interpersonal.
Habilidad 4: Los miembros del proyecto reciben orientación en los roles,
responsabilidades, autoridad y valor del grupo de SQA.
38
39. Relación con otros roles
A continuación se analiza la relación del asegurador de calidad con los otros
roles:
• Administrador de proyecto: El asegurador de calidad revisa el plan de
administración de proyecto, para asegurarse que se crea y que se sigue.
• Analista: El asegurador de calidad revisa la especificación de requisitos de
usuario y de software, para asegurarse que es una representación correcta y
completa de las expectativas del cliente, y que es suficientemente clara para
todos en el grupo de desarrollo, especialmente para el diseñador.
• Diseñador: El asegurador de calidad revisa la fase de diseño arquitectónico,
para asegurarse que el diseñador seleccionó la metodología apropiada y que el
producto final de esta fase cumple con requisitos de rendimiento, diseño y
verificación.
• Programador: El asegurador de calidad revisa la fase de diseño detallado,
para asegurarse que el código producido cumple con la especificación de
requisitos establecida y que cumple con los atributos de calidad en uso.
• Téster : El asegurador de calidad revisa el plan de testeo, para asegurarse
que es creado, que es adecuado para el proyecto específico, y que se aplica en
cada fase del proceso de desarrollo hasta la entrega del producto.
39
40. • Documentador: El asegurador de calidad revisa la documentación, para
asegurarse que corresponde con el software desarrollado, y que cumple con el
estándar en uso.
• Administrador de configuración: El asegurador de calidad revisa los registros
de cambios, errores y de configuración, para asegurarse de que los cambios
han sido implementados apropiadamente, y que las líneas bases son
almacenadas y que el producto no se puede perder.
2.7 Actividades del SQA.
A continuación se presentan las actividades y metas a cumplir por los
aseguradores de calidad.
Actividades Metas
Asegurarse que la especificación de
requisitos es una representación correcta
y completa de las expectativas del cliente,
Revisar los documentos de requisitos y que es suficientemente clara para el
de usuario y de software equipo de desarrollo, especialmente para
los diseñadores.
Revisar el plan de administración del Asegurarse que el plan es creado y se cumple.
proyecto.
Asegurarse que el plan se crea, que es adecuado
Revisar el plan de testeo al proyecto específico, y que se sigue en cada
fase del ciclo hasta que se entrega el producto.
Asegurarse que los diseñadores seleccionaron la
Revisar la fase de diseño
metodología apropiada y que el producto final
arquitectónico cumple con los requisitos de diseño y
verificación.
Asegurarse que el software producido cumple
Revisar la fase de diseño detallado con los requisitos especificados y con los
atributos de calidad impuestos.
Revisar las políticas de control de Asegurarse que se realizan monitoreos de
errores en cada fase del desarrollo y que se
cambios, control de errores y control
respaldan las líneas bases haciendo que el
de la configuración. producto no se pueda perder
Asegurarse que la documentación cumple con el
Revisar la documentación. estándar utilizado durante el desarrollo del
producto de software.
40
41. 2.8 Métodos y herramientas.
Existen varios métodos y herramientas que pueden ser aplicados durante el
desarrollo de software, pero en este apartado se enfocara más a las
actividades del Asegurador de Calidad.
Entre las actividades del Asegurador de Calidad, la más importante es la de
participar en las revisiones técnicas formales (RTF). Si estas revisiones
están bien conducidas, son la forma más efectiva de encontrar, revelar y
corregir errores mientras aún es barato encontrarlos y arreglarlos.
El estándar ESA incluye revisiones en las fases RU/R, RS/R, DA/R y DD/R.
No obstante, las RTFs son especialmente requeridas en la fase de diseño
arquitectónico. Esto, debido a que las actividades de diseño introducen entre
el 50 y 65% de todos los errores durante el proceso de desarrollo.
Se ha demostrado que las RTFs descubren del orden del 75% de los errores
de diseño. Los objetivos de las RTFs son:
Descubrir errores en funciones, lógica e implementación en cualquiera
de las representaciones del software.
Verificar que el software bajo revisión cumple con los requisitos.
Asegurarse que el software ha sido representado de acuerdo al
estándar en uso.
Alcanzar software que es desarrollado en forma uniforme.
Hacer el proyecto más manejable.
41
42. Una RTF es una reunión entre tres a cinco personas.
Cada una de ellas ha realizado una preparación de antemano de no más de
dos horas, y su duración no debe tampoco sobrepasar las dos horas.
La RTF se focaliza en un producto pequeño del software, tal como una
porción de los requisitos, el diseño detallado de un módulo, o el listado de
código fuente de un módulo.
Los participantes de una RTF son el productor (la persona que desarrolló el
producto a revisar), un encargado de la revisión que evalúa el producto
genera copias de material y lo distribuye a dos o tres revisores para que se
preparen de antemano. Uno de los revisores toma el rol de documentador
de los aspectos más relevantes aparecidos durante la revisión.
Al final de la revisión, los participantes deben decidir si:
1. Aceptar el producto sin modificación posterior.
2. Rechazar el producto debido a errores serios.
3. Aceptar el producto con errores menores que deben ser corregidos, pero
no se requiere una revisión posterior.
42
43. 2.9 Enfoque de Procesos en el Desarrollo de software
En un mundo de cambios constantes y competencia global, las organizaciones
de desarrollo de software son presionadas a alcanzar mayor eficiencia con
menores costos. Para poder lograr este objetivo, es necesario adoptar una
forma de trabajo que permita entender, controlar, comunicar, mejorar, predecir
y certificar el trabajo realizado.
Actualmente existe una gran diversidad de opciones relacionadas con procesos
de desarrollo. Constantemente se escuchan diferentes acrónimos como CMM,
CMMI, RUP, ISO, PSP, TSP, etc., que causan confusión, principalmente debido a
la mala interpretación de los mismos.
¿Porqué contar con un proceso de software?
Hasta hace poco tiempo, la producción de software era realizada con un
enfoque artístico, a diferencia de un enfoque industrial. Ante la constante
presencia de proyectos fallidos, y con el objetivo de mejorar la calidad de los
productos, en los últimos años las organizaciones introdujeron los métodos de
ingeniería de software.
A partir de estos, se formalizó el enfoque de ingeniería de producto para
desarrollar software. Factores como la globalización han obligado a las
organizaciones a contar con marcos de trabajo que las ayuden hacer las cosas
de la manera más eficiente. Fue entonces que se incorporó la ingeniería de
procesos al desarrollo de software.
43
44. 2.9.1 Definición de Proceso y Enfoque de procesos
Antes de definir lo que es un proceso de desarrollo de software, entendamos lo
que es un proceso:
Proceso:
Una definición sencilla de proceso es ―serie de acciones que conducen a un
final‖.
Esta definición parece coincidir con las ideas generales de la gente sobre
procesos, pero deja muchas preguntas abiertas:
¿El proceso es la forma en que la organización opera —desde mercadotecnia
hasta recursos humanos— o es la forma en que un desarrollador diseña,
produce código, o prueba el software?
¿El proceso se refiere a administración, ingeniería, o ambas?
¿El proceso implica demasiada documentación y nos abstiene de desarrollar el
producto objetivo?
La respuesta a éstas puede variar dependiendo de la perspectiva. Sin embargo,
siempre que para alcanzar algún fin deseado necesitemos ejecutar una serie de
acciones, y estas acciones tengan cierto orden, dependencias, roles
responsables, resultados, tiempos de ejecución y herramientas de apoyo,
estaremos hablando de procesos, que pueden ser predefinidos y
personalizados.
Proceso de software
La meta de la ingeniería de software es construir productos de software, o
mejorar los existentes; en ingeniería de procesos, la meta es desarrollar o
mejorar procesos.
44
45. Un proceso de desarrollo de software se define como:
“Un conjunto de personas, estructuras de organización, reglas, políticas,
actividades y sus procedimientos, componentes de software,
metodologías, y herramientas utilizadas o creadas específicamente para
definir, desarrollar, ofrecer un servicio, innovar y extender un producto
de software”.
Fig. 3 Proceso de software
Un proceso de software efectivo habilita a la organización a incrementar su
productividad al desarrollar software:
• Permite estandarizar esfuerzos, promover reuso, repetición y consistencia
entre proyectos.
• Provee la oportunidad de introducir mejores prácticas de la industria.
• Permite entender que las herramientas deben ser utilizadas para soportar un
proceso.
• Establece la base para una mayor consistencia y mejoras futuras.
45
46. Un proceso de software mejora los esfuerzos de mantenimiento y soporte:
• Define cómo manejar los cambios y liberaciones a sistemas de software
existentes.
• Define cómo lograr la transición del software a la operación, y cómo ejecutar
los esfuerzos de operación y soporte.
Se requiere un proceso de software cuya funcionalidad esté probada en la
práctica, y personalizado para que cumpla con necesidades específicas.
Fig. 4 Elementos típicos del proceso de software.
46
47. 2.9.2 Capacidad de proceso de software
El rango de resultados esperados que se pueden obtener tras seguir un
proceso.
2.9.3 Madurez del proceso de software
Es el punto hasta el cual un determinado proceso es explícitamente
definido, administrado, medido, controlado y efectivo.
¿Qué es un nivel de madurez?
Es una plataforma bien definida desde la cual podremos obtener un
proceso maduro de software.
2.9.4 Modelos de proceso PSP y TSP
El mejor proceso de software es el que esta cerca de la gente que realizará el
trabajo. Si un modelo de proceso de software ha sido desarrollado en un
ámbito corporativo u organizacional, puede ser efectivo sólo si es en gran
medida adaptable para satisfacer las necesidades del equipo del proyecto, que
es el que en realidad lleva a cabo el trabajo de ingeniería de software. En un
escenario ideal, cada ingeniero de software crearía un proceso que llene lo
mejor posible sus propias necesidades, y al mismo tiempo satisfaga las amplias
necesidades del equipo y la organización. De modo alternativo, el equipo
mismo crearía su propio proceso, y al mismo tiempo cubriría las necesidades
más reducidas de los individuos y las necesidades amplias de la organización.
Watts Humphrey [HUM97] y [HUM00] argumenta que es posible crear un
―proceso de software personal‖ o un ―proceso de software en equipo‖ ambos
requieren un trabajo arduo, capacitación y coordinación pero ambos se pueden
conseguir.
¿Por qué TSP /PSP para desarrolladores de software en México?
47
48. Es bien sabido que para desarrollar software de calidad de manera consistente
se requiere contar con una alta madurez de procesos. A nivel internacional, el
modelo de madurez de procesos más popular es el modelo CMMI. Sin embargo,
este modelo es complejo para implementar en empresas pequeñas. En México
se tiene la Norma Mexicana basada en MoProsoft, pero ésta se centra en los
procesos de las empresas, más no en los de las personas.
La estrategia para incrementar la madurez de la industria de software en
México, debe de contemplar no solamente los procesos de las empresas sino,
incluir el mejoramiento del elemento básico que da sustento a la industria: las
personas. Precisamente en las personas se enfoca el Personal Software Process
(PSP) y Team Software Process (TSP), creados por el Dr. Watts Humphrey del
Software Engineering Institute (SEI).
Es así que la Secretaría de Economía ha dado marcha a la Iniciativa Nacional
TSP/PSP, la cual se está trabajando directamente con el SEI y el Dr. Humphrey.
El objetivo de esta iniciativa es crear en México la infraestructura humana que
permita la introducción y expansión acelerada del uso de TSP, para que la
industria de desarrollo de software en México alcance un desempeño superior
al de su competencia internacional.
Los elementos que se conjuntan y que nos hacen creer en esta oportunidad son
los siguientes:
La gran mayoría de las empresas que desarrollan software en México son
menores a 50 empleados.
El modelo que utilizan nuestros competidores (CMMI) es complejo y
apropiado para organizaciones grandes.
48
49. El TSP/PSP, cuando se implementa correctamente, ha probado ser más
eficaz que el CMMI Nivel 5.
Con el uso de TSP/PSP las empresas en México podrían tomar ventaja y
adelantarse en la incorporación de estos procesos de calidad en menor
tiempo y obteniendo mejores resultados.
México ya ocupa el primer lugar mundial de personas certificadas en PSP, lo
que nos da ventaja sobre nuestros competidores. El SEI busca impulsar
significativamente TSP/PSP y está en busca de un socio que le ayude a cumplir
este objetivo. México, como país ha demostrado ser un aliado que permitirá
continuar con la evolución de dichos modelos.
Visión
Con la implementación de este proyecto México logrará:
Posicionarse como el país con mejor calidad y valor agregado de manera
ágil, adelantándonos a las capacidades de nuestros competidores.
Contar con un método avalado por el SEI que permitirá demostrar
objetivamente la calidad de los proyectos desarrollados por las empresas
que usan el TSP.
Que la calidad de los desarrollos con talento mexicano sean mejores que
aquellos con niveles de alta madurez de CMMI. Esto permitirá hacer
desarrollos en menor tiempo y mejor calidad, lo que se transforma en
una ventaja de costo.
Las metas para alcanzar a corto plazo con la Iniciativa Nacional TSP/PSP son:
La definición de la primera versión del método de evaluación
organizacional del uso del TSP.
49
50. La definición del método de mejora acelerada a través del TSP+CMMI.
Los estudios de impacto del TSP, para ajustar su uso y prácticas.
Desarrollar una infraestructura de instructores y coaches a un costo
competitivo que permita acelerar la incorporación del uso de TSP/PSP en
México.
Si bien, la Secretaría de Economía a través del Prosoft está fondeando el
desarrollo de la certificación para TSP organizacional en el SEI, ésta tendrá un
reconocimiento mundial. Así al mantener el sello del SEI México, será el primer
―jugador‖ en este esfuerzo, obteniendo ventajas sobre quienes le sigan.
Relación CMMI-TSP
Por lo regular se necesita de 18 a 24 meses para lograr un nivel en CMMI, lo
que se traduce en seis años para alcanzar un nivel 4 y ocho años para alcanzar
un nivel 5.
Sin embargo, incorporar TSP/PSP acelera el cumplimiento de las prácticas de
CMMI de una forma más generalizada en la organización, y recorta
significativamente el tiempo necesario para alcanzar cada nivel. Esto sucede
porque los integrantes del equipo de trabajo conocen y aplican PSP en sus
procesos personales, lo cual acelera la implementación de prácticas
organizacionales.
PSP – Personal Software Process
Personal Software Process (PSP) es un proceso diseñado para ayudar a los
ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está
50
51. basado en una motivación: La calidad de software depende del trabajo de cada
uno de los ingenieros de software. Debido a que los costos de personal
constituyen 70% del costo del desarrollo de software, las capacidades y hábitos
de trabajo de los ingenieros determinan en gran manera los resultados del
desarrollo de software.
Basado en prácticas encontradas en CMM, el PSP puede ser usado por
ingenieros para estructurar y disciplinar el desarrollo de software. El ingeniero
de software podrá planear mejor el trabajo, conocer con precisión el
desempeño, medir la calidad de productos, y mejorar las técnicas.
PSP puede ser aplicado en:
Desarrollo de programas.
Definición de requerimientos.
Documentación.
Pruebas de sistemas.
Mantenimiento de sistemas.
Fig. 5 Proceso de Software Personal (PSP)
51
52. TSP - Team Software Process
Team Software Process (TSP) es un marco para el desarrollo de software que
pone igual énfasis en el proceso, producto y trabajo en equipo. Al igual que
PSP, TSP fue propuesto por Watts Humphrey.
TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es
desarrollado por equipos, por lo que los ingenieros de software deben primero
saber controlar su trabajo, y después saber trabajar en equipo. TSP le enseña a
los ingenieros a construir equipos autodirigidos y desempeñarse como un
miembro efectivo del equipo. También muestra a los administradores como
guiar y soportar estos equipos.
Estrategia de TSP
• Proveer un proceso sencillo basado en PSP
• Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento,
Estrategia, Plan, Requerimientos, Diseño, Implementación, Pruebas,
Postmortem
• Establecer medidas estándares para calidad y desempeño
• Proveer definiciones de roles, y evaluaciones de rol y de equipo
• Requiere disciplina de proceso
• Provee guía para manejo de problemas de trabajo en equipo.
52
53. Objetivos del TSP:
Construir equipos independientes que planeen y tengan un seguimiento de su
trabajo, establezcan metas y posean sus procesos y planes. Estos grupos
pueden ser equipos de software puros o equipos de producto integrado de 3 a
20 integrantes.
Mostrar a los jefes cómo preparar y motivar a sus equipos y como
ayudarlos a sostener un alto desempeño.
Acelerar el mejoramiento del software a realizar, con el comportamiento
normal y esperado, el nivel 5 de CMM
Ofrecer una guía de mejoramiento a organizaciones de alta madurez.
Facilitar la enseñanza universitaria de habilidades de equipo industrial de
calidad.
El equipo autodirigido entiende en forma consistente sus metas y objetivos
generales. Define funciones y responsabilidades para cada uno de sus
miembros, registra datos cuantitativos del proyecto (como productividad y
calidad); identifica un proceso de equipo apropiado para el proyecto y una
estrategia para implementar el proceso; define estándares locales aplicables al
trabajo de ingeniería de software del equipo, evalúa en cada momento riesgos,
reacciones; y registra, gestiona y reporta el estatus del proyecto.
53
54. Planteamiento de la necesidad
Ciclo 1
Lanzamiento Ciclo 2
Lanzamiento
Ciclo 3
Lanzamiento
Estrategia 1
Estrategia 2
Plan 1
Plan 2 Estrategia 3
Requerimientos 1
Requerimientos 2 Plan 3
Diseño 1
Diseño 2 Requerimientos 3
Implementación 1
Implementación 2 Diseño 3
Pruebas 1
Pruebas 2 Implementación 3
Postmortem 1
Postmortem 2 Pruebas 3
Postmortem 3
Producto terminado
Evaluación final
Fig.6 Estructura y flujo del TSP
El TSP define las siguientes actividades del marco de trabajo: lanzamiento,
diseño de alto nivel, implementación, integración y prueba, análisis de
resultados. Al igual que sus contrapartes en el PSP, estas actividades permiten
al equipo planear, diseñar y construir un software de una manera disciplinada
al mismo tiempo que miden de modo cuantitativo el proceso y el producto. El
análisis de resultados muestran el escenario para el mejoramiento del proceso.
El TSP utiliza una amplia variedad de escritos, formas y estándares que sirven
para guiar a los miembros del equipo en su trabajo. Los escritos (scripts)
definen actividades específicas del proceso (por ejemplo lanzamiento, diseño,
implementación, integración y prueba de unidad) que son parte del proceso del
equipo.
54
55. La actividad inicial del proceso conocida como lanzamiento permite al equipo
establecer una base sólida para iniciar el proyecto. Se recomienda el siguiente
script general [HUM00]:
Revisar los objetivos del proyecto con las de gestión, acordar, y
documentar las metas del equipo.
Establecer las funciones del equipo.
Definir el proceso de desarrollo del equipo.
Elaborar un plan de calidad y plantear los objetivos de calidad.
Preparar un plan para las necesidades de soporte necesarias.
Producir una estrategia de desarrollo general
Elaborar un plan de desarrollo para el proyecto en su totalidad.
Hacer planes detallados para cada ingeniero en la siguiente fase.
Adaptar los planes individuales a un plan de equipo.
Hacer un balance de la cantidad de trabajo para obtener un programa
mínimo en términos generales.
Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para
cada riesgo clave.
Es importante señalar que la actividad de lanzamiento puede aplicarse antes de
cada actividad del marco de trabajo del TSP, esto se ajusta a la naturaleza
iterativa de muchos proyectos y permite que el equipo se adapte a las
necesidades cambiantes del cliente y a las lecciones aprendidas de actividades
previas.
55
56. 2.10 Preguntas de repaso y prácticas sugeridas.
1. Investigar diferentes modelos de ciclos de vida, discutir en grupo las
ventajas y desventajas de estos para aplicarlos en el desarrollo de un
producto de software.
2. Realizar una lluvia de ideas grupal en donde se lleven a cabo soluciones
que permitan tener a un grupo de desarrollo de software y
aseguramiento de calidad mas comprometidos.
3. Investigue cuales son las principales actividades que realizan los
miembros de SQA para una norma en específico (Moprosoft, CMM. CMMI,
etc.)
4. Discutir en grupo sobre la relación entre proceso y calidad del producto
obtenido.
5. Elaborar un proyecto de software tangible de manera que pueda
realizarse primero de forma individual y después de manera grupal en un
tiempo definido. Documentar las experiencias que se tienen al hacerlo de
distinto modo. Discutir cuales fueron las practicas que mejor pueden
servir para realizar el producto con mayor éxito. SE PUEDEN BASAR EN
LOS ANEXOS 1, 2 Y 3 DE ESTE TEXTO COMO APOYO EN SU
PROYECTO.
56
57. 6. Discutir en grupo sobre la responsabilidad de cada uno de los roles de los
integrantes del equipo de desarrollo de software y el porqué es
importante su comunicación con el equipo de Aseguramiento de la
Calidad.
7. Realizar un ejercicio de una revisión técnica formal sobre un producto de
software realizado anteriormente, cuidar los aspectos y recomendaciones
señaladas en este capítulo, documentar las experiencias obtenidas y
discutir las posibles mejoras que puedan realizarse.
8. Realizar una visita a una empresa que desarrolle software, observe
cuales son las actividades que se realizan antes, durante y después de
desarrollar el producto, intente clasificarlas identificando el tipo de
proceso según la norma ISO 12207-1.
9. Realizar en equipo algunas de las actividades de la fase de lanzamiento
para el TSP descritas en el script general.
57
58. 3 Estándares de calidad aplicados al software.
3.1 ISO
En el capitulo I se mencionaron las familias de normas ISO, en este punto se
detallará que es el ISO y su aplicación en la calidad de software.
¿Qué es el ISO 9000 ?
En el año de 1987, la Organización Internacional para la Estandarización (ISO
por sus siglas en inglés) con base en Génova publicó la serie de estándares
internacionales ISO 9000 para que sirvieran como base para el sistema de
administración de la calidad. Es descendiente del estándar Británico BS-5750.
Desde la publicación original, los estándares han sido revisados en los años
1994 y 2000.
El certificado ISO 9000 es otorgado por organizaciones acreditadas llamadas
certificadoras, que revisan el manual de calidad y los procedimientos de la
compañía para asegurar que cumplen con los requisitos del estándar aplicable,
y auditan los procesos para asegurar que se implementen los sistemas
documentados de forma efectiva. Una vez que se otorga la certificación, el
certificador lleva a cabo auditorías de supervisión una a dos veces por año para
asegurar que el sistema continúa siendo implementado y cumple con los
requisitos del estándar aplicable.
ISO 9000, que junta una propuesta de administración de calidad total con una
metodología de documentación para crear un sistema de auditoría interno, es
58
59. también el primer intento de crear un estándar internacional de aseguramiento
de calidad que cubra todas las industrias y el sector de servicio.
El así llamado estándar ISO 9000 está actualmente comprendido por una serie
de estándares.
Los estándares publicados el 15 de diciembre del 2000 son:
ISO 9000:2005 Sistemas de Administración de la Calidad – Fundamentos y
Vocabulario
ISO 9001:2008 Sistemas de Administración de la Calidad – Requisitos
ISO 9004:2000 Sistemas de Administración de a Calidad – Guía para la Mejora
del Desempeño
ISO 9000:2005 describe conceptos y propuestas esenciales para la familia
ISO 9000:2000 y brinda definiciones para el vocabulario. ISO 9000 no es una
especificación, sin embargo, se nombra en ISO 9001 como una referencia
normativa y así puede ser usada por los auditores para apoyar su
interpretación de los requisitos del ISO 9001, en particular con referencia al
vocabulario.
ISO 9001:2008 son los requisitos actuales para el sistema de administración
de la calidad. Sus requisitos definen el criterio para el sistema de calidad. El
papel de este estándar en las series no ha cambiado, pero su contenido y
organización son revisadas completamente.
ISO 9004:2000 describe un sistema de calidad que va más allá de los
requisitos básicos especificados en el ISO 9001. Está previsto como una guía
para organizaciones que quieren expandir y mejorar aún más el sistema de
calidad después de implementar el ISO 9001 (ejem. en las fases después de la
certificación). ISO 9004 no es un requerimiento y no debe ser usado por
auditores de terceros para auditorías de registro.
59
60. Los principios básicos en que se ha basado la revisión de esta norma son :
Organización enfocada al cliente: Para obtener la satisfacción de los mismos e
incluso superar sus expectativas.
Liderazgo: Para avanzar hacia la excelencia el liderazgo e los equipos directivos
es fundamental.
Participación de las personas: Para el proceso de mejora continua es necesario
que los conocimientos de todo el personal que integra la organización estén a
disposición del mismo.
Enfoque e procesos: Se consigue mayor efectividad cuando todas las
actividades interrelacionadas se comprenden y gestionan en forma sistemática
a partir de una información fiable.
Enfoque del sistema hacia la gestión: Por medido de la gestión de los procesos
se consigue la mejora y el logro eficiente de los objetivos.
Mejora continua: Es el procedimiento según el cual se planifican acciones
encaminadas a la mejora de las actividades, se ejecutan esas acciones,
midiendo sus resultados y actuando en consecuencia. La mejora continua debe
ser el objetivo permanente de las empresas para evitar el retroceso.
Enfoque hacia la toma de decisiones: Se debe observar y estudiar las medidas
de los procesos y en toda la información relevante y fiable que se pueda
obtener.
Relaciones mutuamente beneficiosas suministradores-proveedores.
Al final de la cadena proveedor-suministrador se encuentra el cliente final, por
lo que es necesario establecer relaciones de mutua confianza entre los
proveedores y los suministradores.
60
61. Por lo anterior, valdría la pena preguntarse: ¿Porqué los estándares son tan
importantes?
Muchas compañías requieren que sus proveedores estén certificados bajo el
estándar ISO 9000 y debido a esto, las compañías certificadas encuentras que
sus oportunidades de mercado se han incrementado. Además, la conformidad
de la compañía con el estándar ISO 9000 asegura que tiene un sistema de
aseguramiento de calidad sólido.
Las compañías certificadas han tenido reducciones dramáticas en las quejas de
cliente, reducciones significativas en costos de operación y un incremento en la
demanda de sus productos y servicios.
¿Qué es un sistema de calidad conforme a ISO 9001?
Un sistema de calidad conforme a ISO 9001 satisface los requisitos del
estándar ISO 9001 pero no ha sido formalmente evaluado y certificado por un
certificador de terceros. Esto significa que puedes disfrutar de los beneficios de
un sistema de calidad conforme a ISO 9001 sin pasar por los gastos
normalmente asociados con la certificación. Estarás en posición de certificar
cuando así lo requieras.
Beneficios de la Conformidad a ISO 9001
Los siguientes son algunos de los muchos beneficios que las compañías
reportan que han ganado al implementar los sistemas de calidad ISO 9000:
Mejor control de sus operaciones
Mejoramiento en la calidad de servicio a sus clientes con aseguramiento
Un sistema de calidad extenso y formal l
61
62. Incremento en la retroalimentación del empleado en el proceso de toma de
decisiones
Mejora en la habilidad de dar seguimiento a los procedimientos
Incremento en la habilidad para determinar la causa raíz de los errores
Una excelente herramienta de mercadotecnia.
3.1 SPICE
Antecedentes:
Debido al incremento del número de modelos y estándares aplicados a valorar
la mejora del desarrollo de software y su producto, estos mismos propiciaron al
inicio de los 90’s el sentimiento generalizado de la necesidad de promover un
estándar internacional que armonizara los modelos de referencia existentes
(CMM, Trillium, Bootstrap, etc).
El proyecto SPICE (Software Process Improvement and Capability
dEtermination) promovido por ISO surgió como un esfuerzo de colaboración
internacional que debía materializarse en un nuevo estándar para la valoración
del proceso de software. Dicho proyecto debía proporcionar el soporte
necesario para la elaboración del nuevo estándar. La realización de pruebas de
campo sería una labor fundamental de la que deberían extraer los datos
oportunos y derivar los análisis que posibilitarían la mejora del modelo en sus
diferentes versiones.
62