Este documento trata sobre conceptos básicos de calidad de software. Define calidad de software como la concordancia con los requerimientos funcionales y de rendimiento establecidos, así como con los estándares de desarrollo documentados. Explica que la calidad es subjetiva y depende de la percepción del usuario. También describe brevemente la diferencia entre calidad de diseño y calidad de concordancia para software. El documento proporciona una introducción general a los conceptos y definiciones clave relacionadas con la calidad de software.

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

63. El estándar resultante del proyecto debía cumplir ciertos objetivos:
Ser lo suficientemente genérico para tener un amplio horizonte de
aplicación, a la par de lo suficientemente específico como para ser útil y
manejable.
Establecer mecanismos que permitieran migrar desde estándares ya
establecidos, así como evitar la aparición de otros estándares
contrastantes.
Proporcionar un programa de transferencia tecnológica que permitiera la
adopción del nuevo estándar.
De los años 1993 a 1995 se desarrollaron y realizaron las primeras pruebas de
campo, para verano de 1996 se dieron diferentes cambios en la norma para
ajustarla a los datos recogidos en las pruebas efectuadas, para octubre de ese
mismo año se realizó en México un encuentro del grupo de trabajo numero 10
(WG10) en el que la comunidad internacional, por primera vez pudo conocer
las partes que definen el modelo. Posteriormente se entregó a la secretaria del
comité las 9 partes de documento comenzando el periodo de votaciones ( hay
que recordar como se vio en el primer capítulo cómo es que se realizan estos
estándares y los acuerdos a los mismos), la fase de revisión y votación por
parte de los miembros del comité JTC1. En los años sucesivos a la publicación
del informe técnico éste se encuentra sujeto a revisiones por el mismo comité.
Entre los principales colaboradores del proyecto SPICE se encuentran:
SEI Software Engineering Institute USA ,AT&T Bell labs USA, IBM Australia,
NTT Japón, Northen Telecom Canadá, British Telecom, Fujitsi, Defense Reseach
Agency de Gran Bretaña, ITDC Finlandia, Etnoteam Italia, CSELT Italia.
63

64. Objetivo de SPICE:
• Establecer un estándar de evaluación de procesos de software para:
_ Evaluación de la capacidad de los procesos (nivel de madurez).
- Determinación de la capacidad de los procesos.
_ Mejora continua, (mejora de los procesos).
_ Como base para el comercio internacional de software
Alcance de SPICE:
• Ejecutar, planificar, gestionar, controlar y mejorar los procesos de:
_ Adquisición
_ Suministro
_ Desarrollo
_ Operación
_ Soporte
_ Mantenimiento
_ Organización
• Independiente del tipo de organización, modelo de ciclo de vida, metodología
de desarrollo y de la tecnología utilizada
SPICE como modelo Bidimensional
El modelo a través de una aproximación estructurada, permite valorar los
procesos de software, fomentando la autoevaluación y ofreciendo un
mecanismo por lo cual los adquisidores pueden ganar confianza en los
resultados de la valoración, de esta forma los datos obtenidos pueden ser
utilizados para los fines de calificación de los suministradores, permitiendo
64

65. determinar la capacidad de los procesos, así como su adecuación para cumplir
un requisito determinado o una clase de requisitos. La norma ISO 15504 se
basa en otra norma de ISO la 12207 que describe el ciclo de vida.
El modelo ISO/IEC 15504 también está ideado para determinar la idoneidad de
los procesos de otras organizaciones, para un contrato determinado o clase de
contrato.
El modelo de referencia se fundamenta en dos dimensiones bien determinadas
y complementarias, la Fig. 7 nos muestra la Arquitectura de SPICE.
Fig. 7 Arquitectura de SPICE
65

66. Una de ellas determina los procesos a ser valorados, definiendo el proceso de
vida del software. La otra dimensión presenta una escala para evaluar la
capacidad.
La escala elegida posee cinco niveles caracterizados por un conjunto de nueve
atributos de procesos, que a su vez son tasados según el grado de
cumplimiento de los mismos indicando en tantos por cientos, como se muestra
en la Fig. 8.
Fig.9 SPICE: Relación de dimensiones y atributos del proceso.
La primera dimensión denominada dimensión del proceso define un conjunto
estándar de procesos para el ciclo de vida completo del software.
La dimensión del proceso parte de tres clases básicas de procesos: Primarios,
de Soporte y Organizativos.
66

67. Estos se dividen en nueve categorías de proceso:
PRIMARIOS:
Procesos de Adquisición – (ACQ)
Procesos de Proveedores – (SPL)
Procesos de Ingeniería – (ENG)
Procesos de Operación – (OPE)
PROCESOS DE SOPORTE (SUP)
PROCESOS ORGANIZATIVOS:
Procesos de GESTION – (MAN)
Procesos de Mejora – (PIM)
Procesos de Recursos e Infraes – (RIN)
Procesos de Reusabilidad – (REU)
Cada proceso se define desde el punto de vista de su finalidad y como un
conjunto identificado de resultados.
La dimensión de la capacidad del proceso se sustenta en un conjunto de
atributos que determinan el nivel. El objetivo de esta dimensión es definir la
escala de medida para la capacidad del proceso, para ello se considera una
escala de tipo ordinal de 6 puntos. La base fundamental para este estándar
representa la medida del software de igual forma que en el caso del estándar
CMM.
En la Fig. 10 podemos apreciar la arquitectura de los procesos y su interacción
con los niveles de madurez del proceso.
67

68. Fig.10 Arquitectura de los procesos según SPICE
Los niveles considerados por el estándar son mostrados en la Fig.10, estos
niveles de capacidad por separado, no son suficientes para evitar
ambigüedades en la cuantificación de la capacidad de los procesos, por lo que
es necesario tener una serie de atributos comunes a todos los procesos.
Estos atributos son utilizados como base para la valoración. Cada uno e ellos
está definido desde el punto de vista de las características que el proceso
debería exhibir. Para cada atributo hay una descripción general y un conjunto
de características específicas, de forma que cada uno es evaluado para cada
proceso valorado, desde el punto de vista del grado de realización del mismo.
68

69. Fig.10 Niveles de capacidad y Atributos de Proceso
Los valores son asignados en una escala de cuatro puntos (Fig.11): no
alcanzado, parcialmente alcanzado, altamente alcanzado, y totalmente
alcanzado. Considerando el valor de cada atributo se podrá determinar en qué
nivel se encuentra el proceso estudiado.
El modelo de evaluación se basa en el principio de que la capacidad del
proceso se puede evaluar si se demuestra la consecución de los atributos del
proceso.
ISO/IEC 15504 obliga a evaluar empezando desde el Nivel 1 y, en caso de que
sean alcanzados ampliamente (L) o completamente (F) los atributos de los
procesos asociados a un cierto nivel, permite evaluar un nivel superior.
69

70. Valores posibles Grado de
Situación para determinar el grado de alcance del atributo
del atributo alcance
Indica un poco o nula evidencia de que se ha alcanzado este
N No alcanzado 0% -15%
atributo en el proceso evaluado.
P Parcialmente Se evidencia una aproximación sistemática del alcance del
16% -50%
alcanzado atributo, pero algunas de sus características no se dan.
L Ampliamente Hay bastantes evidencias de que se alcanza el atributo, pero la
51% - 85%
alcanzado realización del proceso diverge en alguna área.
Hay evidencia de que el atributo se alcanza plenamente y de
F
manera sistemática en el proceso evaluado y no hay
Completamente 86%-100%
debilidades importantes en la unidad organizacional en la que
alcanzado
se ubica el proceso.
Fig. 11Escala de valoración de los atributos de los procesos según ISO/IEC 15504
Esta aproximación no solo permite conocer el nivel en que se encuentra el
proceso, sino que es una guía que permite su mejora al conocer el valor que
deben tener los atributos para conseguir un nivel superior de excelencia, según
la escala propuesta. La dimensión de la capacidad no solo sirve para cuantificar
la capacidad de la organización sino también es una guía para su optimización.
A continuación se muestran los niveles, con los atributos de los procesos
asociados y grado de cumplimiento
70

71. Nivel de Atributos de los
Descripción
Capacidad procesos (PA)
0 No hay atributos en este nivel
Representa la medida de cuándo se alcanza el
Realización del proceso
1 propósito de un proceso, transformando los
(PA.1.1)
productos de entrada en productos de salida.
Representa el grado de gestión de la realización del
Gestión de la realización
proceso, para que se obtengan productos que
(PA.2.1)
2 cumplan los objetivos definidos
Gestión de productos Representa el grado de gestión de los productos
resultantes (PA.2.2) resultantes producidos por los procesos
Representa el nivel de realización del proceso, según
Definición de los procesos
el cual utiliza una definición de proceso basada en un
(PA.3.1)
proceso estándar para conseguir sus objetivos
3
Representa el nivel de adecuación de la
Aplicación del proceso
implementación o despliegue efectivo del proceso
(PA.3.2)
estándar
Representa el nivel en el que las medidas y los
objetivos de los productos y de los procesos son
Medida del proceso (PA.4.1) utilizados para asegurar que la realización del
proceso soporte el alcance de los objetivos definidos
como apoyo en los objetivos de negocio.
4
Representa el nivel de control del proceso a través
de la recopilación, análisis y uso de medidas de
Control del proceso (PA.4.2) proceso y de producto, para corregir, en caso
necesario, su rendimiento y para conseguir los
objetivos de proceso y de producto definidos.
Representa el nivel de control de los cambios en la
Innovación de los procesos definición, gestión y realización del proceso con el fin
(PA.5.1) de alcanzar los objetivos de negocio fijados en la
organización.
5
Representa el nivel bajo el cual se identifican e
Optimización de los procesos implantan los cambios en los procesos, para
(PA.5.2) conseguir una mejora continua en el cumplimiento de
los objetivos de negocio de la organización.
Fig.12 Atributos de los procesos asociados a los niveles de capacidad
de ISO/IEC 15504
71

72. Fig.13 Ejemplo de perfil de evaluación de proceso.
La Fig. 13 muestra un ejemplo de perfil de evaluación del proceso en el que
son considerados los atributos arriba mencionados. En el mismo puede
denotarse en qué nivel de capacidad se encuentran los procesos evaluados, en
el proceso de Soporte al cliente no se tiene la suficiente evidencia que para
aprobar el atributo de Gestión de productos resultantes (PA2.2), a pesar de
haber cubierto el de Gestión de Realización del proceso (PA2.1), por lo que su
nivel de capacidad queda en 1.
De manera similar los procesos de Diseño y Construcción del software, solo
cubren parcialmente el grado del atributo al presentarse solo del 16% al 50%
de las evidencias, por lo que su nivel de capacidad también queda en 1.
72

73. En la captura de los requisitos a pesar de que se tiene ampliamente
conseguida la Aplicación del proceso (PA3.2), la realización del mismo difiere
en alguna área, por lo que no puede obtener el nivel 3 y su nivel alcanzado es
2.
Por último el proceso de Prueba del software se tiene evidencia que los
atributos de Realización del proceso (PA 1.1), Gestión de la realización(PA.2.1)
y Gestión de los productos resultantes (PA.2.2) se alcanzan plenamente y de
manera sistemática, y que no existen debilidades importantes en la
organización en la que se ubica dicho proceso, por lo cual su nivel de capacidad
es 2.
3.3 CMM (Capability Maturity Model)
El modelo Capability Maturity Model(CMM ), también denominado CMM-SW.
Fue desarrollado por el SEI (Software Engineering Institute), como marco de
referencia para la evaluación y mejora de procesos de software.
Con el fin de proporcionar al gobierno de los Estados Unidos un método para
evaluar la capacidad de sus proveedores de software, en noviembre de 1986, el
SEI junto con el Centro de Investigación Gubernamental Mitre, comenzaron a
desarrollar un nuevo marco de mejora de procesos de software. En septiembre
de 1987, publicaron el primer resultado en forma de una breve descripción del
proceso de madurez así como un cuestionario para detectar los puntos débiles
de la empresa evaluada. Después de unos cuantos años de aplicación del
primer modelo y refinamiento del mismo a partir de los resultados que se iban
obteniendo en su aplicación en diferentes empresas, el SEI desarrolló y publicó
la primera versión de CMM en 1991. Esta primera versión fue revisada y
73

74. utilizada por la comunidad de software durante 1991 y 1992, en abril de ese
año surgió la primera versión definitiva, CMM Versión 1.0.
CMM contiene los elementos esenciales para conseguir procesos eficaces en
uno o más cuerpos de conocimiento, estando estos elementos basados en los
conceptos desarrollados por Crosby, Deming, Juran y Humphey.
En el año 2000 el CMM fue actualizado hacia el modelo CMMI (Capability
Maturity Model Integration).
En junio del 2009 tuvo lugar en León (España la presentación mundial de la
traducción al castellano del Modelo de Mejora de Procesos CMMI para
Desarrollo de Software. La traducción ha sido desarrollada por la Cátedra de
Mejora de Procesos de Software en el Espacio Iberoamericano, dirigida por
Gonzalo Cuevas. España es el segundo país de Europa (con 105 evaluaciones
CMMI, por detrás de Francia que tiene 141) y el noveno a nivel mundial en
número de empresas evaluadas sobre el Modelo para el Desarrollo (CMMI-
DEV), pero sólo estaba disponible en inglés, francés, chino y japonés, lo que se
traducía en que muchas compañías, sobre todo las de menor tamaño, tuvieran
dificultades para acceder al mismo.
3.3.1 Definición del modelo
El modelo de madurez guía a las organizaciones indicando cómo mejorar los
procesos asociados al desarrollo y mantenimiento del software. La filosofía
general que rige a este modelo se fundamenta en diferentes niveles de
madurez entendidas como sucesivas etapas cuyo objetivo es la obtención de un
proceso de software optimizado, en cada nivel, además de establecer una
escala de medida de la capacidad de los procesos, se fijan unos objetivos que
74

75. ayudan a la organización a priorizar los esfuerzos dedicados a la mejora de
estos procesos.
Es importante indicar que el modelo de madurez, se fundamenta en la
secuencia de los niveles propuestos. No es aconsejable ni técnicamente
adecuado el pretender un nivel superior sin haber alcanzado el intermedio. Los
niveles de madurez pueden asemejarse a los estratos telúricos, uno sucede al
otro, lo apoya y sustenta.
Es fácil entender que no es posible el proceder a una mejora continua con la
aplicación de nuevas tecnologías como sería el caso del nivel 5, sin haber
establecido un control cuantitativo de los procesos de software, o haber
establecido estándares adecuados para, por ejemplo, la recopilación o
manipulación de datos en la que asentar la cuantificación de los procesos
productivos. El modelo de madurez propuesto por el SEI se basa en mejoras
continuas y progresivas, no en saltos cualitativos ni en revoluciones
tecnológicas de inesperadas consecuencias. La exigencia de la calidad no es
sólo para los productos materiales, también lo es para los servicios.
La Fig. 14 nos muestra los 5 niveles de madurez del proceso, cada nivel de
madurez se interpreta como la capacidad de los procesos de ingeniería de
software y de administración de proyectos usados en una organización de
desarrollo de software.
A su vez cada nivel de madurez con excepción del nivel Inicial tiene una
estructura interna como es mostrada en la Fig. 15.
75

76. Fig.14 Niveles de madurez de CMM.
Fig. 15 Estructura de los niveles de madurez de CMM
Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está
compuesto por un cierto número de Areas Claves de Proceso, conocidas a
través de la documentación del CMM por su sigla inglesa: KPA. Cada KPA
76

77. identifica una agrupación de actividades y prácticas relacionadas, las cuales
cuando son realizadas en forma colectiva permiten lograr alcanzar las metas
fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso:
Gestión, Organizacional e Ingeniería.
Las prácticas que deben ser realizadas por cada Área Clave de Proceso están
organizadas en cinco características comunes (se describen mas adelante), las
cuales constituyen atributos que indican si la implementación y la
institucionalización de un proceso clave es efectivo, repetible y duradero.
Metas:
Representan el propósito, alcance y límites de cada área clave de Proceso.
Pueden ser usadas para determinar si una organización o proyecto ha
implementado efectivamente la KPA.
Aspectos Comunes:
Son atributos que indican si la implementación e institucionalización de un área
clave de proceso es efectiva, repetible y duradera.
Las prácticas clave se dividen en cinco secciones de aspectos comunes:
Compromiso para Ejecutar
Habilidad para Ejecutar
Actividades Realizadas
Medición y Análisis
Verificación de Implementación
Prácticas Clave:
Cada área clave de proceso está descrita en términos de prácticas clave que,
cuando son implementadas, ayudan a satisfacer las metas de esa área clave.
Describen la infraestructura y actividades que mejor contribuyen a la
implementación e institucionalización del área clave de proceso
77

78. La clasificación de las KPA’s se determinan de acuerdo al nivel de Madurez que
se va alcanzando dentro del modelo CMM,cada KPA busca alcanzar ciertas
metas, cuando se alcanzan todos los KPA’s de un Nivel se alcanza ese nivel.
NIVEL 5
KPA1. Administración de Cambios al Proceso
KPA2. Administración de Cambios de Tecnología
KPA3. Prevención de defectos
NIVEL 4
KPA1. Administración de la Calidad del Software
KPA2. Administración Cuantitativa del Proceso
NIVEL 3
KPA1. Enfoque al Proceso Estándar de Software
KPA2. Definición del Proceso Estándar de Software
KPA3. Programa de Capacitación
KPA4. Administración Integrada del Software
KPA5. Ingeniería de productos de Software
KPA6. Coordinación entre grupos de trabajo
KPA7. Definición y enfoque del Proceso Organizacional
NIVEL 2
KPA1. Administración de los requerimientos
KPA2. Planeación del Proyecto (plan de trabajo)
KPA3. Seguimiento y supervisión del plan de Trabajo
KPA4. Aseguramiento de Calidad del Software en los proyectos
KPA5. Administración de la Configuración
KPA6. Administración de subcontratistas
Fig. 15 Áreas Clave de proceso por nivel de madurez en CMM
78

79. 3.3.2 Nivel inicial.
El nivel 1 o inicial es el estado primario en la evolución de las organizaciones
que desarrollan software.
Una definición amplia es que en este nivel se encuentran todas las empresas
que no han logrado implementar las prácticas básicas de gestión de proyectos
e ingeniería de software definidas a partir del nivel 2 o superiores. Una
empresa está en el nivel caótico cuando sus gerentes y personal afirmen que
los proyectos no se pueden planear, que los requerimientos no se pueden tener
bajo control, que no esté siempre en condiciones de controlar las versiones de
producto, donde la calidad sea percibida como una burocracia innecesaria,
cuando se acepte que los procesos son una cosa personal, cuando no se pueda
verificar ni validar el producto, y sobre todo, cuando sus gerentes y personal
vivan bajo condiciones de stress y frustración permanentes.
“Heroísmo, caos y emergencia permanente‖
En este tipo de empresas, el software es virtualmente producto del arte más
que de la ingeniería. Cada "artista" crea su propio proceso personal, el cual es
parte de su sello personal. La gerencia ocupa una parte significativa de su
tiempo en paliar problemas y enfrentar clientes insatisfechos. Ante una
situación de crisis permanente, se les hace difícil destinar recursos para definir
o documentar procesos, lo que lleva a un círculo sin salida.
Cuando el proyecto se termina, la inversión hecha en desarrollar el proceso es
raramente reutilizada en nuevos proyectos. Los desarrolladores de software
generalmente tienen que trabajar largas horas y paliar problemas en forma
cotidiana, lo cual les disminuye su creatividad y productividad netas. El éxito
79

80. descansa en los hombros de estos héroes, tal como en una película de acción
americana. Su nivel de frustración es elevado y es muy frecuente que, como
cualquier "diva", decidan explorar caminos en otras empresas con menor nivel
de stress. El proceso, que no está documentado ni a sido compartido, se va con
ellos, dentro de sus cerebros. Los reemplazantes heredan problemas y
dificultades, pero son raramente capaces de recuperar los procesos de
desarrollo. Esto obliga a reinventar la rueda, a un alto costo y retrasando los
proyectos. He conocido un par de empresas que han llegado a la conclusión
que es demasiado caro o difícil tratar de adivinar lo que el empleado anterior
hizo, que les sale más a cuenta echar a la basura el desarrollo anterior y
empezar todo de nuevo. En casos extremos hay que simplemente terminar el
producto para no seguir perdiendo dinero o prestigio frente a los clientes.
Futuro probable
En los orígenes de la industria de software el caos predominó y las empresas
que sobrevivieron la selección natural llegaron al mercado de nuestros días. La
mayoría se extinguió en la gloria del triunfo efímero. Muchos de los actores
actuales están predestinados a desaparecer en un futuro próximo. A pesar del
talento de su personal y el despliegue de tecnología que puedan sustentar,
derrochan su éxito debido a la debilidad de sus procesos de desarrollo.
80

81. 3.3.3 Nivel repetido.
El nivel 2 o Repetible hace posible la implementación de prácticas mínimas de
administración de proyecto, de control de requerimientos, versiones de
producto y de proyectos realizados por subcontratistas. El grupo o equipo
humano que realizó el proyecto puede aprovechar su experiencia e inversión en
procesos para aplicarla en un nuevo proyecto.
Este nivel no garantiza que todos los proyectos dentro de la empresa estén
necesariamente al mismo nivel de madurez. Algunos pueden estar todavía en
el nivel inicial. He visto algunos casos en la práctica y en todos ellos estos
proyectos fueron ineficientes con respecto a los de mayor madurez,
malgastando el éxito de estos últimos. Eventualmente algunos invirtieron los
esfuerzos necesarios para ponerse a tono, otros simplemente fueron cerrados
con un elevado costo de frustración y descalabro de carreras profesionales.
Beneficios de implantar el Nivel 2 del CMM
El mayor beneficio obtenido de la implementación del nivel 2 por la empresa en
la cual me desempeño actualmente, es la planificación realista de los
proyectos. Antes los cronogramas de proyecto expresaban más los deseos de la
gerencia que la realidad. Este principio (el mismo en la cual se basa la magia)
conducía una situación de buscar culpables y generar excusas, produciendo al
mismo tiempo frustración y desconfianza entre clientes y empleados.
Actualmente los cronogramas son cada día más confiables, y mejora a medida
que se acumula más información en las bases de datos de los proyectos
pasados. El uso generalizado de métodos de estimación permite al personal del
proyecto de justificar plazos y recursos. Aún el "olfato profesional" y la
experiencia personal juegan un papel importante en la generación de planes de
81

82. proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas
como en el pasado.
Descripción de las Áreas Clave de proceso para Nivel 2 CMM
NIVEL 2 REPETIBLE
KPA1. Administración de los requerimientos
KPA2. Planeación del Proyecto (plan de trabajo)
KPA3. Seguimiento y supervisión del plan de Trabajo
KPA4. Aseguramiento de Calidad del Software en los proyectos
KPA5. Administración de la Configuración
KPA6. Administración de subcontratistas
Gestión de Requerimientos
Propósito: Establecer una comprensión común entre el cliente y el proyecto, de
los requerimientos del cliente que debe satisfacer el proyecto.
Meta 1: Los requerimientos del sistema asignados al software son controlados
para establecer un "baseline" para uso de la ingeniería de software y la gestión.
Meta 2: Los planes, productos y actividades de software deben mantenerse
consistentes con los requerimientos del sistema asignados al software.
Planeamiento de Proyectos de Software
Propósito: Establecer planes razonables para ejecutar la Ingeniería de Software
y para administrar el proyecto de Software.
Meta 1: Las estimaciones de software están documentadas para usar en el
planeamiento y seguimiento del proyecto de software.
Meta 2: Las actividades y compromisos del proyecto de software están
planeadas y documentadas.
82

83. Meta 3: Los individuos y grupos afectados acuerdan sus compromisos
vinculados con el proyecto de software.
Seguimiento y Supervisión de Proyectos
Propósito: Establecer una adecuada visibilidad del progreso real para que la
gerencia pueda tomar medidas efectivas cuando se producen desvíos
significativos del desempeño con respecto a los planes de software.
Meta 1: Los resultados y desempeños se siguen contra los planes de software.
Meta 2: Las acciones correctivas son tomadas y administradas cuando los
resultados reales y el desempeño se desvían significativamente de los planes
de software.
Meta 3: Los cambios en los compromisos de software son acordados por los
individuos y grupos afectados.
Gestión de Subcontratación de Software
Propósito: Seleccionar subcontratistas de Software calificados y administrarlos
efectivamente.
Meta 1: El principal contratista selecciona subcontratistas de software
calificados.
Meta 2: El principal contratista y el subcontratista de software acuerdan sus
compromisos mutuos.
Meta 3: El principal contratista y el subcontratista de software mantienen una
comunicación regular.
Meta 4: El contratista principal sigue los resultados y desempeño del
subcontratista de software contra sus compromisos.
Aseguramiento de Calidad de software
83

84. Propósito: Proporcionar a la gerencia la visibilidad apropiada del proceso usado
en el proyecto y de los productos en construcción.
Meta 1: Se planean la actividades de SQA.
Meta 2: La adhesión de los productos y actividades de software a los
estándares, procedimientos y requerimientos aplicables se verifica
objetivamente.
Meta 3: Los grupos e individuos afectados son informados de las actividades y
resultados de SQA.
Meta 4: Los incumplimientos que no pueden resolverse dentro del proyecto de
software son encarados por la alta gerencia.
Gestión de Configuración de Software
Propósito: Establecer y mantener la integridad de los productos de Software del
proyecto a lo largo del ciclo de vida.
Meta 1: Se planean las actividades de Gestión de configuración de software.
Meta 2: Los Productos de trabajo de software seleccionados son identificados,
controlados y están disponibles.
Meta 3: Se controlan los cambios a productos de trabajo de software
identificados.
Meta 4: Los grupos e individuos afectados son informados del estado y
contenidos de la "baseline" de los productos de software.
84

85. 3.4 Nivel definido.
La empresa ha definido un conjunto de procesos, metodologías y herramientas
comunes a todos los proyectos iniciados por la corporación. El proceso común
está suficientemente documentado en una biblioteca accesible a todos los
desarrolladores.
Todo el personal ha recibido el entrenamiento necesario para entender el
proceso estándar. Existen pautas y criterios definidos para adaptar dicho
proceso a las necesidades y características propias de cada proyecto. El nivel
de definición es detallado y completo. La dependencia (o el riesgo de depender)
en individuos irreemplazables es baja.
Beneficios de implantar el Nivel 3 del CMM
La base de datos que reúne estadísticas de los proyectos pasados y en curso,
permite planificar y comparar el rendimiento. Existen mecanismos de
comunicación entre proyectos y departamentos, lo que garantiza una visión
común del producto y una rápida acción para enfrentar los problemas. He
conocido unas pocas empresas a este nivel y la cosa que más me resaltó fue la
satisfacción del personal. En empresas de nivel 1 habitualmente se escuchan
quejas y acusaciones. A nivel 3 los empleados tienen una alta valoración de los
procesos y entienden claramente la manera en que afectan su desempeño
habitual. Los gerentes pueden realizar su verdadera función, administrar.
El hecho de realizar revisiones tempranas en forma regular mejora
visiblemente la calidad de los productos y minimiza las reiteraciones.
Descripción de las Áreas Clave de proceso para Nivel 3 CMM
NIVEL 3 DEFINIDO
85

86. KPA1. Enfoque al Proceso de la Organización
KPA2. Definición del Proceso de software de la Organización
KPA3. Programa de Capacitación
KPA4. Administración Integrada del Software
KPA5. Ingeniería de productos de Software
KPA6. Coordinación intergrupal
KPA7. Revisiones por pares
Enfoque en el Proceso de la Organización
Propósito: Establecer la responsabilidad organizacional para las actividades del
proceso de Software que mejoran la capacidad global del proceso de software.
Meta 1: El proceso de desarrollo de software y las actividades de mejora son
coordinadas a lo largo de la organización.
Meta 2: Las fortalezas y debilidades del proceso de software utilizado están
identificadas en relación al proceso estándar.
Meta 3: Las actividades de desarrollo y mejora del proceso se planifican a nivel
de la organización.
Definición del Proceso de la Organización
Propósito: Desarrollar y mantener un conjunto de recursos del proceso que
mejoran el desempeño de los proyectos y proveen una base para obtener
beneficios a largo plazo.
Meta 1: Un proceso estándar software para la organización está desarrollado y
es mantenido.
Meta 2: La información relativa al uso por los proyectos de software del
proceso estándar de software de la organización, se reúne, revisa y está
disponible
86

87. Programa de Entrenamiento
Propósito: Desarrollar las habilidades y el conocimiento de los individuos, para
que ejecuten sus roles con efectividad y eficiencia [capacitación].
Meta 1: Las actividades de entrenamiento se planean.
Meta 2: Se provee entrenamiento para el desarrollo de las habilidades y
conocimientos necesarios para desempeñar los roles gerencial y técnico.
Gestión Integrada de Software
Propósito: Integrar las actividades de Ingeniería de Software y de Gestión en
un proceso de Software coherente y definido, que es adaptado desde el
proceso de software estándar de la organización y las evaluaciones de proceso
relacionadas.
Meta 1: El proceso de software definido para el proyecto es una versión
adaptada del proceso estándar de software de la organización.
Meta 2: El proyecto es planeado y administrado de acuerdo con el proceso de
software definido para el proyecto
Ingeniería de Producto de Software
Propósito: Ejecutar consistentemente un proceso de ingeniería bien definido
que integre todas las actividades de Ingeniería de Software para producir
efectiva y eficientemente productos de Software correctos y consistentes.
Meta 1: Las tareas de ingeniería de software están definidas, integradas y son
consistentemente ejecutadas para producir el software.
Meta 2: Los productos del trabajo de software se mantienen consistentes entre
sí.
87

88. Coordinación Intergrupal
Propósito: Establecer un medio para que el grupo de SE participe activamente
con otros ingenieros para que el proyecto esté en mejores condiciones de
satisfacer efectiva y eficientemente las necesidades del usuario.
Meta 1: Los requerimientos del usuario son acordados por todos los grupos
afectados.
Meta 2: Los compromisos entre los grupos de ingeniería son acordados por los
grupos afectados.
Meta 3: El grupo de ingeniería identifica, rastrea y resuelve los aspectos
intergrupales.
Revisiones por Pares
Propósito: Eliminar temprano y eficientemente defectos del Software.
Meta 1: Se planean las actividades de revisión por pares.
Meta 2: Se identifican y eliminan defectos de los productos de software.
88

89. 3.3.5 Nivel administrado.
En este nivel la corporación mide la calidad del producto y del proceso de
software. Ambos, producto y proceso, son seguidos en forma cuantitativa y se
controlan mediante métricas detalladas. La capacidad de rendimiento del
proceso es previsible. Las mediciones permiten detectar cuando las variaciones
del rendimiento se salen de los rangos aceptables, de manera de poder tomar
medidas correctivas para asegurar la calidad.
Beneficios de implantar el Nivel 4 del CMM
La empresa es capaz de proponerse metas cuantitativas para la calidad de los
productos y de los procesos de software. Es posible medir la productividad y
calidad de los procesos de software a través de todo el proyecto.
Los proyectos pueden controlar la variación del rendimiento de sus productos y
procesos para mantenerla dentro de fronteras cuantitativas aceptables. Es
posible discriminar las variaciones significativas en el rendimiento del proceso
de la variación (ruido) al azar, particularmente dentro de líneas de productos
establecidas.
Es necesario aclarar que el hecho de contar con un sistema de métricas de
software no significa que se esté en el nivel 4. He conocido muchas empresas
de nivel 1 que miden cuidadosamente el número de defectos detectados
durante las pruebas o tests (no es casualidad que les interese tanto!). Es una
virtual señal de alarma que les dice cuán graves son sus problemas, pero la
inmadurez de sus procesos no les permite hacer nada efectivo, excepto tal vez
abortar el producto para evitar un daño mayor que puede resultar de
distribuirlo a los clientes.
Descripción de las Áreas Clave de proceso para Nivel 4 CMM
89

90. NIVEL 4 GESTIONADO (ADMINISTRADO)
KPA1. Administración de la Calidad del Software
KPA2. Administración Cuantitativa del Proceso
Administración de la Calidad del Software
Propósito: Desarrollar una comprensión cuantitativa de la calidad de los
productos de software y alcanzar objetivos específicos de calidad.
Meta 1: Se planean las actividades de gestión de calidad del proyecto de
software.
Meta 2: Están definidas metas medibles para la calidad del producto de
software y sus prioridades.
Meta 3: El progreso real para alcanzar las metas de calidad de los productos de
software está cuantificado y administrado.
Administración cuantitativa del proceso
Propósito: Controlar cuantitativamente la performance del proceso del proyecto
de software.
Meta 1: Se planean las actividades de gestión cuantitativa el proceso.
Meta 2: El desempeño del proceso de software definido para el proyecto se
controla cuantitativamente.
Meta 3: La capacidad del proceso estándar de software de la organización es
conocido en términos cuantitativos.
90

91. 3.3.6 Nivel optimizado.
En el Nivel Optimizado, la característica principal es el mejoramiento continuo
del proceso, en base a la realimentación cuantitativa y al ensayo de ideas y
tecnologías innovadoras.
Beneficios de implantar el Nivel 5 del CMM
La organización entera se aboca al mejoramiento continuo del proceso. La
corporación cuenta con los medios para identificar las debilidades y reforzar en
forma proactiva el proceso, con objeto de prevenir la ocurrencia de defectos.
Los datos relativos a la eficacia del proceso de software se usan para analizar el
costo y el beneficio de usar nuevas tecnologías y de implementar cambios al
proceso de software.
Los proyectos de software analizan los defectos para determinar sus causas.
Los proceso de software se evalúan para prevenir que los defectos conocidos
vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros
proyectos.
Descripción de las Áreas Clave de proceso para Nivel 5 CMM
NIVEL 5 OPTIMIZADO
KPA1. Administración de Cambios al Proceso
KPA2. Administración de Cambios de Tecnología
KPA3. Prevención de defectos
91

92. Administración de Cambios al Proceso
Propósito: Mejorar continuamente el proceso para incrementar: Calidad del
Software, Productividad, Disminuir tiempo de desarrollo de productos.
Meta 1: Se planea la mejora continua del proceso de cambio.
Meta 2: Toda la organización participa en las actividades de mejora del
proceso.
Meta 3: El proceso estándar de la organización y el proceso de software
definido para el proyecto, se mejoran continuamente.
Administración de cambios de Tecnología
Propósito: Identificar las nuevas tecnologías beneficiosas (herramientas,
métodos, procesos) y transferirlos a la organización.
Meta 1: La incorporación de cambios en la tecnología se planea.
Meta 2: Las nuevas tecnologías son evaluadas para determinar su efecto sobre
la calidad y productividad.
Meta 3: Las nuevas tecnologías se transfieren a la práctica normal a los largo
de la organización.
Prevención de Defectos
Propósito: Identificar la causa de los defectos y prevenirlos.
Meta 1: Prevención de defectos.
Meta 2: Causas comunes de defectos son pesquisadas e identificadas.
Meta 3: Causas comunes de defectos son priorizadas y sistemáticamente
eliminadas.
92

93. Comparación de CMM con ISO y SPICE
Una vez presentados los modelos ISO, SPICE y CMM es conveniente hacer una
comparativa de los mismos considerando varios aspectos:
CMM – ISO
Aspecto: Énfasis
La principal diferencia entre los modelos ISO –CMM es que CMM hace
hincapié en la mejora continua del proceso.
Otra diferencia reside en que CMM focaliza estrictamente en Software,
mientras que ISO 9001 tiene un alcance mucho más amplio, que
comprende software, hardware, materiales procesados y servicios.
Aspecto: Nivel de Detalle
La principal diferencia entre los modelos ISO –CMM es el nivel de detalle
que difiere significativamente, la sección 4 en ISO 9000tiene alrededor de
12 páginas de largo, contra más de 500 páginas de CMM.
El alto nivel de abstracción de ISO puede causar que los auditores
interpreten el estándar de maneras diferentes.
Aspecto: Auditores
Los auditores son entrenados en los estándares de la Serie ISO 9000,
pero no son entrenados en conocimiento sobre aspectos específicos de
software.
Para auditorias específicas de software debería integrarse al equipo
personas con conocimientos en la disciplina.
93

94. Otra razón de discrepancia es que un Auditor puede no requerir maestría
para satisfacer la correspondencia con la cláusula de ISO 9001.
Comparación CMM -SPICE
Aspecto: Evolución del Proceso
SPICE
Los niveles de capacidad son aplicados sobre los procesos. Agrega el nivel 0:
un nivel puede no ser ejecutado para nada.
Ventaja: Mayor granularidad en la medición y análisis.
Desventaja: Procesos menos importantes pueden ocultar aspectos que no
se definieron como prioritarios.
CMM
Los niveles de madurez organizacional pueden definirse como un conjunto de
perfiles para los procesos de SPICE. Las KPA pertenecen a un único nivel de
madurez. Los procesos que no están descriptos en CMM, también existen y
evolucionan.
Ventaja: Focaliza en pocas áreas ―vitales‖ que comúnmente bloquean la
performance del proceso.
Desventaja: La gente puede perder el seguimiento de los procesos que no
están focalizados en algún nivel particular, pero que aún así deben realizarse.
94

95. Aspecto: Determinación de Prioridades de Mejoramiento
SPICE
No prescribe ningún camino particular de mejora. Las prioridades son dejadas
completamente a la organización. Los procesos individuales pueden ser
mejorados continuamente. Los niveles de capacidad miden un proceso
específico .Desventaja: Puede ser difícil decidir que aspectos atacar primero.
CMM
Construye la capacidad del proceso focalizando en pocos aspectos vitales para
la organización en su totalidad. Los niveles de madurez priorizan los problemas
de software generales. Desventaja: prescriba atacar aspectos de gestión de
proyecto antes que los de ingeniería.
Ejemplo de Aplicación sobre un Área Clave de Proceso del Nivel 2:
Planificación de Proyectos de Software
El ejemplo siguiente tiene como propósito detallar mas claramente como son
especificados cada una de las prácticas para cumplir con una área clave de
proceso (KPA), que en este caso es la Planificación de Proyectos de Software
para un nivel 2 (Repetido) de CMM.
Vale la pena hacer énfasis que se han agrupado las principales características
para una mejor comprensión, los estudiantes pueden realizar como ejercicio
propuesto investigar para otras KPAS o un buen ejercicio es checar si estas
prácticas son llevadas a cabo en algún desarrollo de un proyecto de software.
95

96. AREA CLAVE 2.2 Planificación de Proyectos de Software
Propósito: Establecer planes razonables para ejecutar la Ingeniería de
Software y para administrar el proyecto de Software. Estos planes son la base
de la gestión del proyecto, 2.3.(siguiente KPA)
_____________________________________________________________
Meta 1: Las estimaciones de software están documentadas para usar en el
planeamiento y seguimiento del proyecto el software.
Meta 2: Las actividades y compromisos del proyecto de software están
planeadas y documentadas.
Meta 3: Los individuos y grupos afectados acuerdan sus compromisos
vinculados con el proyecto de software.
______________________________________________________
Compromiso para la ejecución
1. Un gerente de proyectos de software es designado responsable de negociar
los compromisos y desarrollar el plan del proyecto de desarrollo de software.
2. Para el planeamiento de un proyecto de software (PSw), el proyecto
sigue una política organizacional escrita
Compromiso 1
Esta política comúnmente establece que:
1. Los requerimientos del sistema asignados al software son usados como base
para la planificación del proyecto de software.
2. Los compromisos del proyecto de software son negociados entre: El gerente
de proyecto, el gerente de proyecto de software, y otros administradores.
3. La intervención de otros grupos en las actividades de software es negociada
con estos grupos y documentada.
Ejemplos de otros grupos de ingeniería incluyen: Ingeniería de Sistemas,
Ingeniería de Hardware, Prueba de Sistema.
96

97. 4. Los grupos afectados revisan el proyecto de software:
Estimación de tamaño del software, Estimación del esfuerzo y el costo,
programas, y otros compromisos.
Ejemplos de otros grupos afectados:
Ingeniería de software (incluyendo todos los subgrupos tales como diseño de
software), Estimación de software, Ingeniería de sistema, Prueba de sistema,
Aseguramiento de la calidad del software, Gestión de Configuración de
Software , Gestión de contratos y, Soporte de documentación.
5. La gerencia revisa todos los compromisos del proyecto de software hechos a
individuos y grupos externos de la organización.
6. El plan de desarrollo de software del proyecto es gestionado y controlado.
_____________________________________________________________
Habilidad para ejecutar
1. Existe una orden de trabajo documentada y aprobada para el PSw.
2. Se asignan responsabilidades para el desarrollo del plan de desarrollo de
software.
3. Se proveen adecuados recursos y fondos para el planeamiento del PSw.
4. Los gerentes de software, los ingenieros de software y otrosindividuos
involucrados en el planeamiento del PSw están entrenados en los
procedimientos de estimación y planeamiento aplicables a su área de
responsabilidad.
Hab 1. Existe una orden de trabajo documentada y aprobada para el PSw.
1. La Orden de Trabajo abarca: alcance del trabajo, objetivos y metas técnicas,
identificación de clientes y usuarios finales, estándares impuestos
97

98. responsabilidades asignadas, restricciones y objetivos de costos y
cronogramas, dependencias entre el PSw y otras organizaciones, restricciones
y objetivos de los recursos, otras restricciones y objetivos para desarrollo y
mantenimiento
2. La orden de trabajo es revisada por:
gerente de proyecto, gerente del PSw, otros gerentes de software, otros grupos
afectados.
3. La directiva de trabajo es administrada y controlada.
Hab 2. Se asignan responsabilidades para el desarrollo del plan de desarrollo
de software.
1.El gerente del PSw, directamente o por delegación, coordina el planeamiento
del PSw.
2.Las responsabilidades por los productos del trabajo de software y las
actividades se asignan a los gerentes de software en una forma rastreable y
contabilizable.
Hab 3. Se proveen adecuados recursos y fondos para el planeamiento del PSw.
1.Cuando es factible individuos con experiencia se asignan al desarrollo del
plan.
2.Se dispone de herramientas para soportar el planeamiento de las actividades
del PSw
_____________________________________________________________
Actividades ejecutadas
98

99. 1. El grupo de Ingeniería de Software participa en el equipo que propone el
proyecto.
2. El planeamiento del proyecto de software se inicia en las etapas iniciales y
en paralelo con el planeamiento global del proyecto.
3. A lo largo de la vida del proyecto el grupo de Ingeniería de Software
participa junto con otros grupos afectados, en el planeamiento global del
proyecto.
4. Los compromisos del proyecto de software hechos por individuos y grupos
ajenos a la organización son revisados con la gerencia senior de acuerdo a
un procedimiento documentado.
5. Está identificado o definido un ciclo de vida con etapas predefinidas de
tamaño manejables.
6. El plan del proyecto de desarrollo de software se desarrolla de acuerdo a un
procedimiento documentado.
7. El plan para el proyecto de software está documentado.
8. Lo productos del trabajo de software que se necesitan establecer y
mantener están identificados.
9. Las estimaciones del tamaño de los productos del trabajo de software (o
cambios de ese tamaño) son derivadas de acuerdo a un procedimiento
documentado.
10. Las estimaciones del esfuerzo y costo del proyecto de software son
derivadas de acuerdo a un procedimiento documentado.
11. Las estimaciones de los recursos críticos de computadoras son derivadas
de acuerdo a un procedimiento documentado.
12. El cronograma del proyecto de software se deriva de acuerdo a un
procedimiento documentado.
13. Los riesgos de software asociados con costos, recursos, cronogramas y
aspectos técnicos del proyecto están identificados, establecidos y
documentados.
14. Se preparan planes para las facilidades y herramientas de soporte a
ingeniería de software del proyecto.
99

100. 15. Se registran los datos del planeamiento del software.
Medición y análisis
Las mediciones se hacen y se usan para determinar el estado de las actividades
de planeamiento de software.
Ejemplos de mediciones incluyen:
Trabajo completado, esfuerzo gastado, fondos gastados en las Cumplimiento
de hitos para las actividades planificadas en el proyecto de software,
comparado con el plan.
Actividades planificadas en el proyecto de software, comparadas con el plan.
_____________________________________________________________
Verificación de la implementación
1.Las actividades para planear el proyecto de software son revisadas
periódicamente con la gerencia senior.
2.Las actividades para planear el proyecto de software son revisadas
periódicamente con el gerente de proyecto y en respuesta a eventos.
3.El grupo de aseguramiento de calidad de software revisa y/o audita las
actividades y productos del trabajo para planear el proyecto de software e
informa los resultados.
Verificación 1
Las actividades para planear el proyecto de software son revisadas
periódicamente con la gerencia senior.
1.Se revisa la performance técnica, del personal, de costos y de programación.
100

101. 2.Los conflictos y aspectos no resueltos en niveles más bajos son
direccionados.
3.Los riesgos asociados al Proyecto de Software son direccionados.
4.Los ítems son asignados, revisados y rastreados hasta el cierre.
5.Un reporte de resumen de cada reunión se prepara y distribuye a los
individuos y grupos afectados.
Verificación 2
Las actividades para planear el proyecto de software son revisadas
periódicamente con el gerente de proyecto y en respuesta a eventos.
1.Están representados los grupos afectados.
2.El estado y los resultados actuales de las actividades de la planificación del
proyecto de software son revisadas con la definición del trabajo y los
requerimientos.
3.Son direccionadas las dependencias entre grupos..
4.Son direccionados los conflictos y aspectos no resueltos en los nivele más
bajos.
5.Son revisados los riesgos del proyecto.
6.Los ítems de acción son asignados, revisados y rastreados hasta su cierre.
7.Un reporte de resumen de cada reunión se prepara y distribuye a los
individuos y grupos afectados.
Verificación 3
El grupo de aseguramiento de calidad del software revisa y/o audita las
actividades y productos del trabajo para planear el proyecto de software e
informa los resultados.
Como mínimo, los revisores y/o auditores verifican:
1. Las actividades para la estimación y planificación de software.
2. Las actividades para revisión y concreción de compromisos de lproyecto..
3. Las actividades para la preparación del Plan de Desarrollo de Software.
4. El estándar utilizado para la confección del Plan de Desarrollo de Software.
101

102. 5. El contenido del Plan de Desarrollo de Software.
_____________________________________________________________
Cuestionario de madurez
¿Las estimaciones (tamaño, costo, cronograma, etc) se documentan para
usar en el planeamiento y seguimiento del proyecto de software?
¿Los planes de software documentan las actividades a ser ejecutadas y
los compromisos hechos?
¿Todos los grupos e individuos acuerdan son compromisos relacionados
con el proyecto?
¿El proyecto sigue una política organizacional escrita para planear el
proyecto?
¿Se proveen recursos adecuados para el planeamiento del proyecto
(fondos, personal con experiencia, etc.)
¿Se usan mediciones para determinar el status de las actividades de
planeamiento (ejemplo: los hitos completados se comparan con el plan)?
¿El gerente de proyecto revisa las actividades de planeamiento sobre la
base de períodos y eventos?
_____________________________________________________________
Conclusiones del CMM
Una forma de ocuparnos de la calidad es a través de la mejora del proceso de
desarrollo de software.
Como modelo de madurez y capacidad, CMM representa una de las
alternativas mas efectivas y difundidas en todo el mundo para guiar a las
organizaciones de software en la selección de estrategias para el
mejoramiento de sus procesos de desarrollo.
102

103. CMM describe un camino evolutivo de cinco niveles madurez en el cual
cada nivel nos indica áreas claves de proceso y nos lleva desde un
proceso inicial o ad hoc hasta un proceso maduro o disciplinado.
Los principales beneficios que provee son: mejorar la calidad de los
productos, aumentar tiempo de respuesta al mercado e incrementarla
productividad de la organización.
3. 4 MOPROSOFT
(Modelo de Procesos para la Industria de Software)
La Secretaría de Economía (SE) definió el Programa para el Desarrollo de la
Industria de Software (PROSOFT que formaba parte del Plan Nacional de
Desarrollo 2001-2006. PROSOFT tiene siete líneas estratégicas, siendo la sexta
la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en
capacidad de procesos". Al comenzar el desarrollo de esta línea estratégica se
evaluó la adopción de los modelos: ISO 9000, ISO 15504, SW-CMM. El
resultado de la evaluación fue: "Ninguno de los estándares o modelos cumple
con los requisitos expresados por la industria nacional", y se decidió la
elaboración de un modelo adecuado para las características de las empresas
mexicanas, que se basaría en los modelos evaluados. En base a esta decisión la
Secretaría de Economía encargó la elaboración de dicho modelo a la Asociación
Mexicana para la Calidad en Ingeniería del Software (AMCIS) en colaboración
con la Universidad Nacional Autónoma de México (UNAM). La primera versión
de MoProSoft se publicó en diciembre de 2002.
El Plan Nacional de Desarrollo (PND) 2001-2006 de México plantea el objetivo
de mejorar la competitividad del país mediante la promoción, uso y
103

104. aprovechamiento de la tecnología e información. En dicho plan la Secretaría de
Economía definió el Programa para el Desarrollo de la Industria del Software.
El propósito de este Modelo de Procesos para la Industria de Software
(MoProSoft) en México fue: fomentar la estandarización de su operación a
través de la incorporación de las mejores prácticas en gestión e ingeniería de
software, permitiendo elevar la capacidad de las organizaciones para ofrecer
servicios con calidad y alcanzar niveles internacionales de competitividad.
Para proporcionar este modelo fue necesario considerar que se debía
proporcionar a la industria de software en México, que en su gran mayoría es
pequeña y mediana, un modelo basado en las mejores prácticas internacionales
con las siguientes características:
• Fácil de entender
• Fácil de aplicar
• No costoso en su adopción
• Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas,
tales como ISO 9000:2000 [1] o CMM®1 V1.1
El modelo de procesos MoProSoft está dirigido a las empresas o áreas internas
dedicadas al desarrollo y/o mantenimiento de software.
Las organizaciones, que no cuenten con procesos establecidos, pueden usar el
modelo ajustándolo de acuerdo a sus necesidades. Mientras que las
organizaciones, que ya tienen procesos establecidos, pueden usarlo como
punto de referencia para identificar los elementos que les hace falta cubrir.
MoProSoft y su método de evaluación EvalProSoft, propuesta de Secretaría de
Economía para la PyME de desarrollo de software, fueron entregados en junio
2004 al NYCE, organismo responsable de la normalización y certificación en
México. La norma técnica a la que da contenido es la NMX-059/01-NYCE-2005
104

105. que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación
de su declaratoria en el Diario de la Federación. El objetivo de esta norma es
proveer acceso a las prácticas de ingeniería de software de clase mundial y
contar con un método de evaluación propio.
MoProSoft considera que los modelos de evaluación y mejora, CMMI e ISO/IEC
15504 no resultan apropiados para empresas pequeñas y medianas de
desarrollo y mantenimiento de software. MoProSoft se basa en los modelos de
procesos ISO 9001:2000, en las áreas de procesos de los niveles 2 y 3 de
CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y
conceptos de PMBOK Y SWEBOK.
3.4.1 Generalidades y Estructura.
Para la elaboración del modelo de procesos MoProSoft, fueron aplicados los
siguientes criterios:
1. Generar una estructura de los procesos que esté acorde con la estructura de
las organizaciones de la industria de software (Alta Dirección, Gestión y
Operación).
2. Destacar el papel de la Alta Dirección en la planificación estratégica, su
revisión y mejora continua como el promotor del buen funcionamiento de la
organización.
3. Considerar a la Gestión como proveedor de recursos, procesos y proyectos,
así como responsable de vigilar el cumplimiento de los objetivos estratégicos
de la organización.
105

106. 4. Considerar a la Operación como ejecutor de los proyectos de desarrollo y
mantenimiento de software.
5. Integrar de manera clara y consistente los elementos indispensables para la
definición de procesos y relaciones entre ellos.
6. Integrar los elementos para la administración de proyectos en un sólo
proceso.
7. Integrar los elementos para la ingeniería de productos de software en un
solo marco que incluya los procesos de soporte (verificación, validación,
documentación y control de configuración).
8. Destacar la importancia de la gestión de recursos, en particular los que
componen la base de conocimiento de la organización tales como: productos
generados por proyectos, datos de los proyectos, incluyendo las mediciones,
documentación de procesos y los datos recaudados a partir de su uso y
lecciones aprendidas.
9. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMM ® V.1.1.
Usar como marco general ISO/IEC 15504 - Software Process Assesment e
incorporar las mejores prácticas de otros modelos de referencia tales como
PMBOK, SWEBOK y otros más especializados.
106

107. Estructura
El modelo de procesos (MoProSoft) tiene tres categorías de procesos: Alta
Dirección, Gerencia y Operación que reflejan la estructura de una organización.
Fig. 16 Diagrama de categorías de los procesos en MoProSoft.
La categoría de Alta Dirección contiene el proceso de Gestión de Negocio.
La categoría de Gerencia está integrada por los procesos de Gestión de
Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está
constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo,
Bienes, Servicios e Infraestructura y Conocimiento de la Organización.
La categoría de Operación está integrada por los procesos de Administración de
Proyectos Específicos y de Desarrollo y Mantenimiento de Software.
107

108. En cada proceso están definidos los roles responsables por la ejecución de las
prácticas. Los roles se asignan al personal de la organización de acuerdo a sus
habilidades y capacitación para desempeñarlos.
En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de Proceso
y otros roles involucrados. Además se considera al Cliente y al Usuario como
roles externos a la organización.
MoProSoft al igual que otros Modelos de Proceso, también cuenta con sus
niveles de capacidades como se muestra en la Fig. 16. Los colores mostrados
representan los niveles para la versión escrita 1.3 Por niveles de capacidad,
esto quiere decir que las partes coloreadas de la norma sugieren un orden de la
implementación de las prácticas de los procesos de MoProSoft partiendo de las
prácticas básicas, correspondientes a nivel1, e incorporando las prácticas que
corresponden a los niveles más avanzados.
NIVEL Capacidad de proceso Color
1 REALIZADO Amarillo
2 GESTIÓNADO Azul
3 ESTABLECIDO Verde
4 PREDECIBLE Rosa
5 OPTIMIZADO Ninguno
Fig.16 Correspondencia de los niveles de capacidad de Moprosoft.
Así mismo para una mejor comprensión del modelo y sus procesos vale la pena
tomar en cuenta las siguientes definiciones:
108

109. Concepto Descripción
Un conjunto de procesos que abordan la misma área general de
Categoría de procesos
actividad dentro de una organización.
Conjunto de prácticas relacionadas entre si, llevadas a cabo a
través de roles y por elementos automatizados, que utilizando
Proceso
recursos y a partir de insumos producen un satisfactor de negocio
para el cliente.
Objetivo Fin a que se dirige o encamina una acción u operación.
Mecanismo que sirve para mostrar o significar una cosa con
Indicador
evidencias y hechos.
Es responsable por un conjunto de actividades de uno o más
Rol procesos. Un rol puede ser asumido por una o más personas de
tiempo parcial o completo.
Producto Cualquier elemento que se genera en un proceso.
Un conjunto de elementos, tales como actividades, roles,
Práctica infraestructura y mediciones, que al llevarse a cabo describen la
ejecución de un proceso.
Conjunto de tareas específicas asignadas para su realización a
Actividad
uno o más roles.
Actividad para confirmar que el producto refleja propiamente los
Verificación
requerimientos especificados para él.
Actividad para confirmar que el producto resultante es capaz de
Validación satisfacer los requerimientos para su aplicación especificada o uso
previsto.
Esquema que expresa las relaciones entre las actividades de un
Flujo de trabajo proceso. Una relación puede ser secuencial, paralela, cíclica, de
selección o anidada.
Modificación a las prácticas, entradas y salidas de un proceso,
Guía de ajuste
siempre y cuando no afecten al cumplimiento de sus objetivos.
Gestión Hacer diligencias conducentes al logro de un negocio.
Administración Organizar trabajo y disponer recursos.
Empresa o área interna de una organización dedicada al
Organización
desarrollo y/o mantenimiento de software.
Conjunto de elementos o servicios que se consideran necesarios
Infraestructura
para la creación y funcionamiento de una organización.
Medición Acción o efecto de medir.
Es un repositorio de todos los productos tales como productos de
Base de conocimiento software, planes, reportes, registros, lecciones aprendidas y otros
documentos.
Situación excepcional Circunstancia que impide el desarrollo de una actividad.
Experiencia positiva o negativa obtenida durante la realización de
Lección aprendida
alguna actividad.
Estudio de la potencialidad o de la capacidad que tiene alguna
Prospección cosa para producir o dar resultados en el futuro, a partir del
análisis de los datos reunidos previamente.
109

110. Patrón de procesos de MoProSoft
El patrón de procesos es un esquema de elementos que servirá para la
documentación de los procesos, se encuentra constituido por tres partes:
Definición general del proceso:
Aquí se identifica su nombre, categoría a la que pertenece, propósito,
descripción general de sus actividades, objetivos, indicadores, metas
cuantitativas, responsabilidad y autoridad, subprocesos en caso de
tenerlos, procesos relacionados, entradas, salidas, productos internos y
referencias bibliográficas.
Prácticas:
En esta parte se identifican los roles involucrados en el proceso y la
capacitación requerida, se describen las actividades en detalle,
asociándolas a los objetivos del proceso, se presenta un diagrama de
flujo de trabajo, se describen las verificaciones y validaciones
requeridas, se listan los productos que se incorporan a la base de
conocimiento, se identifican los recursos de infraestructura necesarios
para apoyar las actividades, se establecen las mediciones del proceso,
así como las prácticas para la capacitación, manejo de situaciones
excepcionales y uso de lecciones aprendidas.
Guías de ajuste:
En este apartado se sugieren modificaciones al proceso que no deben
afectar los objetivos del mismo.
A continuación se muestra la descripción del patrón de procesos, esto debe
considerarse como una guía al momento de consultar cada uno de los
procesos, el orden y las imágenes que aquí se presentan es como lo establece
la versión 1.3 y como lo encontrarán en las versiones disponibles al público
por parte del NYCE.

110

111. 
111

112. 112

113. 113

114. El patrón de procesos fue utilizado como esquema para documentar los
procesos de MoProSoft. Las organizaciones que adopten el modelo de procesos
pueden adecuarlo a sus necesidades siguiendo las reglas de la sección 6.
El patrón de procesos que utilicen las organizaciones puede ser distinto del
sugerido en este modelo, pero debe de preservar los objetivos, indicadores y
metas cuantitativas correspondientes para lograr el propósito general de
MoProSoft.
El patrón de proceso puede ser utilizado para documentar e integrar otros
procesos que no fueron contemplados en el modelo.
3.4.2 Categoría de Alta Dirección (DIR)
Categoría de procesos que aborda las prácticas de Alta Dirección relacionadas
con la gestión del negocio. Proporciona los lineamientos a los procesos de la
Categoría de Gerencia y se retroalimenta con la información generada por ellos.
El proceso que la conforma es:
DIR.1 Gestión de Negocio
El propósito de Gestión de Negocio es establecer la razón de ser de la
organización, sus objetivos y las condiciones para lograrlos, para lo cual es
necesario considerar las necesidades de los clientes, así como evaluar los
resultados para poder proponer cambios que permitan la mejora continua.
Adicionalmente habilita a la organización para responder a un ambiente de
cambio y a sus miembros para trabajar en función de los objetivos
establecidos.
Este proceso se compone de la planificación estratégica, la preparación para la
realización de la estrategia, y la valoración y mejora continua de la
organización.
114

115. Objetivos
Lograr una planificación estratégica exitosa mediante el cumplimiento del
Plan estratégico.
Lograr que la organización trabaje en función del Plan Estratégico
mediante la correcta comunicación e implantación del mismo.
Mejorar el plan estratégico mediante la implementación de la propuesta
de mejoras.
3.4.3 Categoría de Gerencia (GER)
Categoría de procesos que aborda las prácticas de gestión de procesos,
proyectos y recursos en función de los lineamientos establecidos en la
Categoría de Alta Dirección. Proporciona los elementos para el funcionamiento
de los procesos de la Categoría de Operación, recibe y evalúa la información
generada por éstos y comunica los resultados a la Categoría de Alta Dirección.
GES.1 Gestión de Procesos.
El propósito de Gestión de Procesos es establecer los procesos de la
organización, en función de los procesos requeridos identificados en el
plan estratégico. Así como definir, planificar, e implantar las actividades
de mejora en los mismos.
Se compone de las siguientes actividades: planificación de procesos,
preparación a la implantación y la evaluación y control de procesos.
Objetivos:
Planificar las actividades de definición, implantación y mejora de los
procesos en función del plan estratégico.
Dar seguimientos a las actividades de definición, implantación y mejora
de los procesos mediante el cumplimiento del plan de procesos.
Mejorar el desempeño de los procesos mediante el cumplimiento del plan
de mejora.
115

116. Mantener informado a Gestión de Negocio sobre el desempeño de los
procesos mediante el Reporte Cuantitativo y Cualitativo.
GES.2 Gestión de Proyectos.
El propósito de la Gestión de Proyectos es asegurar que los proyectos
contribuyan al cumplimiento de los objetivos y estrategias de la organización.
Se ocupa de los proyectos externos, internos y de las oportunidades de
proyectos de la organización. Para las oportunidades de proyectos, se debe
realizar la generación y cierre de oportunidades de proyectos, la presentación
de propuesta y firma de contrato. Para los proyectos internos antes de su
aprobación, se requiere evaluar diferentes alternativas de realización. Los
proyectos internos y externos aprobados requieren de una planificación general
y asignación de los recursos, asi como un seguimiento y evaluación de
desempeño.
La gestión de proyectos comprende la planificación, la realización y la
evaluación y control.
Objetivos:
Cumplir con el Plan Estratégico de la organización mediante la generación
e instrumentación de proyectos.
Mantener bajo control las actividades de Gestión de Proyectos mediante
el cumplimiento del Plan de Gestión de Proyectos.
Proveer la información del desempeño de los proyectos a Gestión de
Negocio mediante la generación del Reporte Cuantitativo y cualitativo.
Atender los comentarios y quejas del cliente mediante la definición y
ejecución de acciones preventivas o correctivas.
GES.3 Gestión de Recursos.
El propósito de GES.3 es conseguir y dotar a la organización de los recursos
humanos, infraestructura, ambiente de trabajo y proveedores, así como crear
y mantener la base de conocimiento de la organización. La finalidad es apoyar
el cumplimiento de los objetivos del plan estratégico de la organización.
116

117. Se compone de las siguientes actividades: la planificación, seguimiento y
control de recursos, e investigación de tendencias tecnológicas, apoyadas con
tres subprocesos: Recursos Humanos y ambiente de trabajo, Bienes, Servicios
e Infraestructura y Conocimiento de la Organización.
Objetivos:
Lograr los objetivos del Plan Estratégico mediante la provisión de los
recursos suficientes y calificados a la organización.
Proveer a los miembros de la organización de los medios y mecanismos
adecuados para el uso y resguardo de la información mediante la Base de
Conocimiento.
Mantener a la organización informada oportunamente sobre las
tendencias tecnológicas mediante la elaboración de propuestas
tecnológicas.
GES.3.1 Recursos Humanos y Ambiente de Trabajo.
Su propósito es proporcionar los recursos humanos adecuados para cumplir las
responsabilidades asignadas a los roles dentro de la organización, así como la
evaluación del ambiente de trabajo.
En función del Plan operativo de Recursos Humanos y ambiente de trabajo y
Acciones correctivas de Gestión de Recursos se realizan las actividades de
preparación, instrumentación y generación de reportes.
Objetivos:
Proveer a la organización de recursos humanos calificados mediante la
selección y capacitación adecuada a los roles que les asignen.
Evaluar el ambiente de trabajo de la organización mediante la encuesta
sobre el ambiente de trabajo.
117

118. GES.3.2 Bienes, Servicios e Infraestructura.
Su propósito es proporcionar proveedores de bienes, servicios e infraestructura
que satisfagan los requisitos de adquisición y proyectos.
En función del Plan Operativo de Bienes, Servicios e Infraestructura y Acciones
correctivas de Gestión de Recursos, se realizan las actividades de preparación,
instrumentación y generación de reportes.
Objetivos :
Proporcionar a la organización los bienes y servicios requeridos por los
procesos y los proyectos mediante la selección y evaluación de los
proveedores.
Mantener la infraestructura de la organización mediante el cumplimiento
del plan de mantenimiento.
GES.3.3 Conocimiento de la organización.
Su propósito es mantener disponible y administrar la base de conocimiento que
contiene la información y los productos generados por la organización.
En función del Plan Operativo de Conocimiento e la Organización y las acciones
correctivas de Gestión de Recursos se realizan las siguientes actividades:
Planificación, Realización, Evaluación y control para generar periódicamente un
reporte del estado de la Base del conocimiento.
Su objetivo es: Proporcionar ala organización la Base de Conocimiento de
forma confiable, oportuna y segura mediante el cumplimiento del plan de
administración de la Base del Conocimiento.
3.4.4 Categoría de Operación (OPE)
Esta categoría de procesos aborda las prácticas de los proyectos de desarrollo
y mantenimiento de software. Esta categoría realiza las actividades de acuerdo
118

119. a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta
la información y productos generados.
Los procesos que contiene esta categoría son los siguientes:
OPE.1 Administración de Proyectos Específicos
.Establece y lleva a cabo sistemáticamente las actividades que permitan
cumplir con los objetivos de un proyecto en tiempo y costo esperados. Aplica
conocimientos, habilidades, técnicas y herramientas, a cada una de las
siguientes actividades: Planificación, Realización, Evaluación y control y cierre.
Sus objetivos son:
Logar los objetivos del proyecto en tiempo y costo mediante la
coordinación y el manejo de los recursos del mismo.
Mantener informado al cliente mediante la realización de reuniones de
avance del proyecto.
OPE.2 Desarrollo y Mantenimiento de Software
Realizar sistemáticamente las actividades de análisis, diseño, construcción,
integración y pruebas de productos de software nuevos o modificados,
cumpliendo con los requerimientos especificados.
Para el estudiante será interesante éste apartado dado que se encuentra en
fase de aprendizaje de la construcción de sistemas de información o productos
de software, por lo que para ésta norma se mencionan las actividades en el
proceso de desarrollo.
El proceso de desarrollo y mantenimiento de software se compone de uno o
más ciclos de desarrollo, cada ciclo está compuesto de las fases siguientes:
INICIO: Se revisa el plan de desarrollo por los miembros del equipo de trabajo
para lograr un entendimiento común del proyecto y para obtener el
compromiso de su realización.
119

120. REQUERIMIENTOS: Conjunto de actividades cuya finalidad es obtener la
documentación de la Especificación de Requerimientos y Plan de Pruebas al
Sistema, para conseguir un entendimiento común entre el cliente y el proyecto.
ANALISIS Y DISEÑO: Conjunto de actividades en las cuales se analizan los
requerimientos especificados para producir una descripción de la estructura de
los componentes del software, la cual servirá de base para la construcción.
Como resultado se obtiene la documentación de análisis y diseño y Plan de
pruebas de integración.
CONSTRUCCION: Conjunto de actividades para producir componentes de
software que correspondan al análisis y Diseño así como la realización de
pruebas unitarias. Como resultado se obtienen los componentes de software
probados.
INTEGRACIÓN Y PRUEBAS: Integrar y probar los componentes de software,
basándose en los planes de pruebas de Integración y de Sistema, con la
finalidad de obtener el software que satisfaga los requerimientos especificados.
Se genera la versión final del Manual de Usuario, Manual de Operación y
Manual de mantenimiento. Como resultado se obtiene el producto de software
probado y documentado.
CIERRE: Integración final de la configuración de software generada en las fases
para su entrega, Identificación y documentación de las Lecciones Aprendidas,
Generación de Reporte de Mediciones y Sugerencias de Mejora.
120

121. Objetivos:
Lograr que los productos de salida sean consistentes con los productos de
entrada en cada fase de un ciclo de desarrollo mediante las actividades
de verificación, validación o prueba.
Sustentar la realización de ciclos posteriores o proyectos de
mantenimiento futuros mediante la integración de la configuración de
software del ciclo actual.
Llevar a cabo las actividades de fases de inicio de un ciclo mediante el
cumplimiento del plan de desarrollo actual.
3.5 Preguntas de repaso y prácticas sugeridas.
1. Investigar qué empresas se han certificado en las distintas normas aquí
presentadas, cuales han sido las ventajas obtenidas para dichas
empresas.
2. Discutir en grupo sobre las diferencias y semejanzas entre una norma
aplicada a la calidad de software.
3. Investigar las prácticas correspondientes a los primeros niveles de
madurez o de capacidad, aplicarlas o verificarlas con el proyecto de
software a realizar.
4. Comparar los diferentes modelos o normas que pueden aplicarse al
desarrollo de software.
121

122. 5. Discutir en clase sobre el impacto que ha tenido la implantación de la
norma Moprosoft en nuestro país.
6. Tomando en cuenta el ejemplo citado para la evaluación de un área de
proceso como lo es la Planeación del proyecto de software, invite a los
equipos a emular una evaluación a la planeación de su proyecto, una vez
que estos hayan realizado al menos un ciclo de desarrollo. También
puede aplicarse la realización del postmortem como se explica en el
anexo 3 de este texto.
7. Para equipos o estudiantes de semestres avanzados y con mayores
fortalezas en el desarrollo de software, puede sugerir realizar su producto
de software bajo una norma propuesta, los mismos estudiantes decidirán
las herramientas y modelos a aplicar, otros equipos también pueden
hacer el rol de evaluadores o testers de pruebas al mismo software. Se
recomienda que sean proyectos de software que han sido continuados en
otras materias o que llevan un tiempo desarrollándose.
122

123. 4 Calidad enfocada al desarrollo de software.
4.1 ¿Qué es la calidad del software?
Tal como se vio en el apartado 1.2, se definió a la calidad de software como
la ―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 calidad del software es el conjunto de cualidades que lo caracterizan y
que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia,
flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad,
usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un
programa a otro. Un software elaborado para el control de naves espaciales
debe ser confiable al nivel de "cero fallas"; un software hecho para
ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que
un producto de software para ser explotado durante un largo período (10
años o más), necesita ser confiable, mantenible y flexible para disminuir los
costos de mantenimiento y perfeccionamiento durante el tiempo de
explotación.
La calidad del software puede medirse después de elaborado el producto.
Pero esto puede resultar muy costoso si se detectan problemas deriva dos
de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta
tanto la obtención de la calidad como su control durante todas las etapas del
ciclo de vida del software.
123

124. 4.2 Cómo obtener calidad de software.
A través de todo este texto se han mostrado las distintas normas y prácticas
existentes tanto a nivel internacional como nacional, y que la mayoría de
ellas hacen especial énfasis en el proceso que implica el desarrollo así como
la gestión de recursos implicados y el desarrollo del producto.
Las diversas herramientas y métodos también fueron mostrados en el
apartado 2.8., en conjunto todas ellas hacen que las mejores prácticas de
desarrollo puedan llevarse a cabo y sean útiles en el proceso del
mejoramiento del producto de software.
La obtención de un software con calidad implica la utilización de
metodologías o procedimientos estándares para el análisis, diseño,
programación y prueba del software que permitan uniformar la filosofía de
trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad
de prueba, a la vez que eleven la productividad, tanto para la labor de
desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios básicos:
tecnológico, administrativo y ergonómico.
El principio tecnológico define las técnicas a utilizar en el proceso de
desarrollo del software.
El principio administrativo contempla las funciones de planificación y control
del desarrollo del software, así como la organización del ambiente o centro
de ingeniería de software.
El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado.
La adopción de una buena política contribuye en gran medida a lograr la
calidad del software, pero no la asegura. Para el aseguramiento de la calidad
es necesario su control o evaluación.
124

125. 4.3 Cómo controlar la calidad del software.
Para controlar la calidad del software es necesario, ante todo, definir los
parámetros, indicadores o criterios de medición, ya que, como bien plantea
Tom De Marco, "usted no puede controlar lo que no se puede medir".
Las cualidades para medir la calidad del software son definidas por
innumerables autores, los cuales las denominan y agrupan de formas
diferentes.
Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada
métrica se obtiene a partir de combinaciones de los diferentes criterios. La
Metodología para la evaluación de la calidad de los medios de programas de
la CIC, de Rusia, define indicadores de calidad estructurados en cuatro
niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde
cada nivel inferior contiene los indicadores que conforman el nivel
precedente.
Otros autores identifican la calidad con el nivel de complejidad del software
y definen dos categorías de métricas: de complejidad de programa o código,
y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices
medibles que son las bases para la calidad, el control y el perfeccionamiento
de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso
de control, que requiere los siguientes pasos:
Definir el software que va a ser controlado: clasificación por tipo, esfera
de aplicación, complejidad, etc., de acuerdo con los estándares
establecidos para el desarrollo del software.
125

126. Seleccionar una medida que pueda ser aplicada al objeto de control. Para
cada clase de software es necesario definir los indicadores y sus
magnitudes.
Crear o determinar los métodos de valoración de los indicadores:
métodos manuales como cuestionarios o encuestas estándares para la
medición de criterios periciales y herramientas automatizadas para medir
los criterios de cálculo.
Definir las regulaciones organizativas para realizar el control: quiénes
participan en el control de la calidad, cuándo se realiza, qué documentos
deben ser revisados y elaborados, etc.
4.4 Costo de la calidad del software.
Incluye costos tanto de la búsqueda de calidad como de las acciones realizadas
para su obtención.
Los costes de calidad pueden dividirse según el enfoque en:
Costos de prevención: Planificación de la calidad, revisiones técnicas
formales, equipo de pruebas, formación.
Costos de evaluación: para tener una visión de la calidad real del producto,
incluye la inspección en el proceso y entre procesos,calibrado y mantenimiento
del equipo.
Costes de fallos, que pueden dividirse en costos internos o externos.
Internos: errores antes de la entrega del producto al cliente( Revisión,
reparación, análisis de las modalidades de fallos).
Externos: errores o defectos detectados después del envío al cliente
(Resolución de quejas, devolución y sustitución de productos, soporte de línea
de ayuda, trabajo de garantía).
Los costos relativos de calidad aumentan rápidamente de prevención a
detección y de error interno a externo.
126

127. La distribución de costos a través de las distintas actividades en el proceso de
software depende del proceso utilizado y del tipo de software que se vaya a
desarrollar. Por ejemplo, el software de tiempo real normalmente requiere una
validación y pruebas más extensas que los sistemas basados en web. Sin
embargo cada uno de los diferentes enfoques genéricos al desarrollo del
software tiene un perfil de distribución de costos diferente a través de las
actividades del proceso del software. Si se considera que el costo total del
desarrollo de un sistema de software complejo es de 100 unidades de costo, la
Fig.20 muestra cómo se gastan éstas en las diferentes actividades del proceso.
Fig.20 Distribución de costos de las actividades de la Ing. Software
En un enfoque en cascada, los costos de especificación, diseño, implementación
e integración se miden de forma separada, la integración y pruebas del sistema
son las actividades de desarrollo más caras. Normalmente, éste supone
alrededor del 40% del costo de desarrollo total, pero para algunos sistemas
críticos, es probable que sea al menos el 50% de los costos de desarrollo del
sistema.
127

128. Si el software se desarrolla utilizando un enfoque interativo, no existe división
entre la especificación, el diseño y el desarrollo. En este enfoque, los costos de
la especificación se reducen debido a que sólo se produce la especificación de
alto nivel antes que el desarrollo. La especificación, el diseño, la
implementación, la integración y las pruebas se llevan a cabo en paralelo
dentro de una actividad de desarrollo. Sin embargo, aun se necesita una
actividad independiente de pruebas del sistema una vez que la implementación
inicial esté completa.
La ingeniería de software basada en componentes sólo ha sido ampliamente
utilizada durante un corto periodo de tiempo, en este enfoque no se tiene datos
exactos para los costos de las diferentes actividades de desarrollo de software,
sin embargo, se sabe que los costos de desarrollo se reducen en relación a los
costos de integración y pruebas. Los costos de integración y pruebas se
incrementan porque se tiene que asegurar que los componentes utilizados
cumplen realmente su especificación y funcionan como se espera con otros
componentes.
Además de los costos de desarrollo, existen costos asociados a los cambios
realizados cuando el software ya está en uso. Los costos de evolución varían
drásticamente dependiendo del tipo de sistema. Para sistemas de larga vida,
tales como los sistemas de orden y control que pueden ser usados durante 10 o
más años, estos costos exceden a los de desarrollo por un factor de 3 o 4,
como se muestra en la penúltima barra de la Fig. 20. Sin embargo, los
sistemas de negocio más pequeños tienen una vida mucho más corta y, por lo
tanto costos de evolución más reducidos.
Esta distribución de costos se cumple para el software personalizado, el cual es
especificado por un cliente y desarrollado por un contratista. Para productos de
software que se venden de manera comercial, el perfil del costo es diferente.
128

129. Estos productos comúnmente se desarrollan a partir de una especificación
inicial utilizando un enfoque de desarrollo evolutivo. Los costos de la
especificación son relativamente bajos. Sin embargo, debido a que se pretende
utilizarlos en distintas configuraciones, deben ser probados a fondo. En la
última barra de la Fig. 20 se muestra el perfil del costo que se puede esperar
para estos productos.
Los costos de evolución para productos de software genéricos son difíciles de
estimar. En muchos casos, existe poca evolución de un producto. Una vez que
una versión de producto se entrega, se inicia el trabajo para entregar la
siguiente y, por razones de mercadotecnia, ésta se presenta como un producto
nuevo (pero compatible) más que como una versión modificada de un producto
que el usuario ya adquirió. Por lo tanto, los costos de evolución no se
consideran de forma separada como en el caso del software personalizado, sino
que son sencillamente los costos del desarrollo para la siguiente versión del
sistema.
4.5 Nomenclatura y certificación ISO 9001:2000
La nomenclatura de la norma de calidad en caso específico de la ISO
9000: 2000 es la siguiente:
1 Parte ISO
Esta sección de la nomenclatura indica la norma de la que se trata, en este
caso es la norma ISO, la cual significa para la traducción en español como
Organización Internacional de estándares, en esta sección se indica el tipo
de norma, como ejemplo otra nomenclatura puede ser la QS la cual es la
usada en las empresas de giro automotriz, etc.
2 Parte 9000
Esta sección indica el tipo de norma de la que se esta hablando en este caso
la 9000 es el vocabulario, términos y definiciones solamente, la 9001 son los
129

130. requisitos, mucha gente por no conocer esta diferencia ,hace referencia a
que "esta certificada por ISO 9000" esto es un error la certificación
se realiza mediante el cumplimiento de requisitos, entonces la ISO 9000 es
un apoyo de todo el vocabulario que se incluye en la ISO 9001
3 Parte 2000
Esta sección es para indicar desde cuando es vigente la norma , en este
caso la ultima vigencia de la ISO 9001 es desde el año 2000
La norma ISO 9001:200 (ISO,2000), especifica los requisitos para un
sistema de gestión de calidad cuando una organización:
Necesite demostrar su capacidad para proporcionar de forma coherente
productos que satisfagan los requisitos del cliente y los reglamentos
aplicables.
Aspira a aumentar la satisfacción del cliente a través de la aplicación
eficaz del sistema, incluyendo los procesos para la mejora continua del
sistema y el aseguramiento de la conformidad con los requisitos del
cliente.
Los principios básicos de la norma ISO 9001, constituyen la parte medular
del sistema son:
Enfoque al Cliente: Las organizaciones dependen de sus clientes y por
tanto deberían comprender las necesidades actuales y futuras de los
clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las
expectativas de los clientes.
Liderazgo: Los líderes establecen la unidad de propósito y la orientación de
la organización Ellos deberían crear y mantener un ambiente interno, en el
cual el personal pueda llegar a involucrarse totalmente en el logro de los
objetivos de la organización.
130

131. Participación del personal: El personal, a todos los niveles, es la esencia
de una organización y su total compromiso posibilita que sus habilidades
sean usadas para el beneficio de la organización.
Enfoque basado en procesos: Un resultado deseado se alcanza mas
eficientemente cuando las actividades y los recursos relacionados se
gestionan como un proceso
Enfoque de sistema para la gestión: Identificar, entender y gestionar los
procesos interrelacionados como un sistema, contribuye a la eficacia y
eficiencia de una organización en el logro de sus objetivos.
Mejora Continua: La mejora continua del desempeño global de la
organización debería ser un objetivo permanente de ésta.
Enfoque basado en hechos para la toma de decisión:
Las decisiones eficaces se basan en el análisis de los datos y la información.
Relaciones mutuamente beneficiosas con el proveedor: Una
organización y sus proveedores son interdependientes y una relación
mutuamente beneficiosa aumenta la capacidad de ambos para crear valor.
Estos ocho principios de gestión de la calidad constituyen la base de las
normas de sistemas de gestión de la calidad(SGC).
La norma ISO 9001 está dividida en ocho puntos, de los cuales, los cinco
últimos definen los requisitos del SGC (Sistema de Gestión de Calidad).
PARTE 1, 2, 3 INTRODUCCION A LA NORMA
En la cual se destacan los siguientes conceptos: Los objetivos y campo de
aplicación de la norma, son demostrar la capacidad para cumplir los
131

132. requisitos reglamentarios y los del cliente y satisfacerle mediante la mejora
continua y la prevención de no conformidades. Se pueden excluir ciertos
requerimientos de la norma en función de la naturaleza de los productos o
servicios, los requerimientos del cliente o los requisitos reglamentarios.
En la parte 2 se indica que la norma de consulta es la ISO 9000:2000
relativa a los ―Sistemas de Gestión de la calidad, principios y vocabulario‖.
PARTE 4 SISTEMA DE GESTION DE CALIDAD
Aquí se definen los requisitos generales y los requisitos generales de
documentación.
Los requisitos generales son:
Planificar: Identificar de todos los procesos que, afectar a la calidad del
producto, determinar la secuencia y relacion que estos procesos tienen entre
sí.
Ejecutar: Determinar metodos y criterios para asegurar el correcto
funcionamiento y control de los procesos, los procesos deben estar
documentados y medidos mediante parámetros relevantes, y se establecen
los responsables de los procesos.
Medir: asegurar la disponibilidad de la información suficiente que permita el
seguimiento del proceso.
Actuar: Medir y realizar el seguimiento del proceso, para analizar y
conseguir una mejora continua.
132

133. PARTE 5 RESPONSABILIDAD DE LA DIRECCIÓN
Aquí se indica las series de responsabilidades o acciones en las cuales el
Gerente General debe de participar directamente o mínimo estar enterado
de ellas, entre las que se destacan:
Compromiso de la dirección, el enfoque al cliente, política de calidad,
planificación, administración, revisión por la dirección.
PARTE 6 GESTION DE RECURSOS
Aquí se indica lo mínimo necesario que la organización debe de gestionar en
cuanto a recursos, esto para garantizar al cliente que la falta de los mismos
no generará un producto de mala calidad. Se detallan cuatro subpartes:
Suministro de recursos, Recursos humanos, Instalaciones, Entorno de
trabajo.
PARTE 7 REALIZACIÓN DEL PRODUCTO
Aquí se indican los requisitos mínimos necesarios para realizar las
actividades que garanticen producto que cumplan con lo estipulado, esta se
subdivide en 6 partes:
Planificación de los procesos de realización, Procesos relacionados con los
clientes, Diseño y/o desarrollo, Compras, Operaciones de producción y
prestación de servicios, control de equipos de medición y de seguimiento.
PARTE 8 MEDICIÓN , ANALISIS Y MEJORA
Este punto hace referencia a la medición que se debe realizar al producto
en sus diferentes fases y al producto final, es decir describe los requisitos
relacionados con la detección, el seguimiento y el análisis de las mejoras. Se
subdivide en 5 subpartes: Planificación, medición y seguimiento, control de
las no conformidades, análisis de datos, mejora.
133

134. Dentro de la medición y seguimiento se incluyen las siguientes áreas:
Satisfacción del cliente, auditoría interna, medición y seguimiento de los
procesos, medición y seguimiento del producto.
4.6 La norma ISO/IEC 9126
La norma ISO/IEC 9126 está enfocada a la calidad de Producto y consta de
las siguientes partes:
Parte 1: Modelo de Calidad
Define un modelo de calidad basado en dos partes bien identificadas: la
calidad interna y externa, y la calidad de uso.
Calidad interna: totalidad de las características del producto de software
desde un punto de vista interno.
Calidad externa: totalidad de las características del producto de software
desde un puesto de vista externo.
Calidad de uso: capacidad del software que posibilita la obtención de
objetivos específicos con efectividad, productividad, satisfacción y
seguridad‖.
La calidad del proceso influye en la calidad del producto que a su vez es
relevante en la calidad de uso. La figura 17 muestra el modelo de calidad
según ISO/IEC 9126.
134

135. Fig. 17 Modelo de calidad según ISO/IEC 9126
Parte 2: Métricas externas
Son medidas del producto de software obtenidas del comportamiento del
sistema en la fase de ejecución del mismo. Finalmente las métricas de
calidad de uso, como tercer gran concepto propuesto por la norma, mide la
extensión en la que un producto alcanza las necesidades expuestas por el
usuario de forma específica en relación a los objetivos de efectividad,
seguridad, productividad, y satisfacción.
Parte 3: Métricas internas
Son aquellas medidas que se realizan sobre un producto de software no
ejecutable, tal como la norma indica ―un producto de software intermedio
debería ser evaluado usando métricas internas‖.
Parte 4: Calidad en las métricas de uso.
Comprende la eficacia, productividad, seguridad y satisfacción definidas
como:
135

136. Eficacia: Capacidad del software para permitir a los usuarios alcanzar
objetivos específicos con precisión y completamente en un contexto
específico de uso.
Productividad: Capacidad del producto de software para alcanzar niveles
aceptables de riesgo hacia la gente, negocio, software, propiedad o medio
ambiente, en un contexto específico de uso.
Satisfacción: La capacidad del producto de software para satisfacer al
usuario en un contexto específico de uso.
4.7 Análisis de factores que determinan la calidad del software.
Desde un punto de vista más formal, se puede decir que un producto
software es de calidad si cumple o tiene algunos o todos de los siguientes
factores de calidad:
Corrección: cumple la especificación de requisitos.
Mantenibilidad: facilidad para cambiar el software.
Portabilidad: esfuerzo para trasladar el software de una a otra
plataforma.
„Testabilidad‟: facilidad para probar que el software es correcto.
Facilidad de uso: esfuerzo para aprender, usar e interrumpir un sistema
en marcha.
Confiabilidad: capacidad para continuar el trabajo aunque haya
interrupciones. (sistemas seguros)
136

137. Eficiencia: recursos que se necesita para la aplicación.
Integridad: datos y sistemas inaccesible por personas no autorizadas.
Reusabilidad: facilidad para reutilizar cosas en otros proyectos.
Interoperabilidad: habilidad para operar con otros sistemas.
¿Qué es un factor de calidad?
Un factor de calidad también llamado parámetro de calidad es una cualidad
cuya presencia o ausencia en un producto software condiciona su calidad.
Factores externos:
– Detectados por los usuarios.
– Son los factores que realmente interesan(objetivo).
Factores internos:
– Únicamente percibidos por los desarrolladores.
– Un medio para conseguir la calidad externa.
Factores de calidad de McCall
Clasifica los factores de calidad de acuerdo a las etapas por las que un
producto pasa: Transición de producto, Revision de producto y Operación del
producto.
Los factores responden a las interrogativas mostradas a continuación en la
Fig.18.
137

138. Fig.18 Factores de calidad de Mc Call
4.8 Análisis del proceso del ciclo de vida del software
En el apartado 2.4 de este mismo texto se explicó la calidad del software en
el proceso de ciclo de vida de software, los procesos que lo conforman, así
como la definición del modelo de ciclo de vida; por lo que únicamente en
este mismo apartado se limitará a mencionar los principales modelos de
ciclo de vida.
Modelos tradicionales
Formados por un conjunto de fases o actividades en las que no tienen en
cuenta la naturaleza evolutiva del software:
Clásico, lineal o en cascada
Estructurado
Iterativo o basado en prototipos
Desarrollo rápido de aplicaciones (RAD)
Modelos evolutivos
Son modelos que se adaptan a la evolución que sufren los requisitos del
138

139. sistema en función del tiempo.
En espiral
Evolutivo
Incremental
Modelo de desarrollo concurrente
Modelos para sistemas orientados a objetos
Modelos con un alto grado de iteratividad y solapamiento entre fases.
De agrupamiento
Fuente
Remolino
Pinball
Basado en componentes
UP
4.9 Funciones de evaluación del software
Con base en los estándares de calidad sugeridos la norma ISO/IEC 9126, de
la ISO (Organización Internacional de Normalización) y la IEC (Comisión
Electrotécnica Internacional) se presenta el proceso de evaluación de
software.
El proceso de evaluación de software se inicia con una visión cualitativa y
deriva en una evaluación cuantitativa, siendo todo el proceso documentado
y cumpliendo los siguientes pasos:
1 Estado del Software:
Conocimiento del el estado del software, estableciendo si se trata de un
desarrollo sin terminar o un producto terminado para la entrega al cliente.
139

140. 2 Identificar el tipo de software:
Especificar el tipo de software a evaluar, si es un sistema operativo,
software de seguridad, software de ofimática, lenguaje de programación,
base de datos, aplicativo a la medida, entre otros.
3 Perfiles de Evaluadores:
Teniendo como marco conceptual al estándar ISO [ISO/IEC9126], se
consideran tres perfiles de usuario, a un alto nivel de abstracción para
desarrollo de software, usuarios finales, desarrolladores, y gerentes.
El estándar afirma que la relativa importancia de las características de
calidad (como usabilidad, funcionalidad, confiabilidad, eficiencia,
portabilidad, y mantenibilidad y calidad en uso) varían dependiendo del
punto de vista considerado y de la critica de los componentes del software a
evaluar. La visión del usuario final, concierne al interés de los mismos en
usar el software, como así también su ejecución, su eficiencia, su facilidad
de uso, entre otros aspectos. Los usuarios finales no están interesados en
características internas o de desarrollo del software (sin embargo, atributos
internos contribuyen a la calidad de uso).
La visión de calidad del desarrollador debe considerar no sólo los
requerimientos del software para la visión del usuario sino también la
calidad para los desarrollos intermedios resultantes de las actividades de la
fase de desarrollo.
Se debe tener en cuenta que los desarrolladores están preocupados en
características de calidad del software como mantenibilidad y portabilidad.
La visión de calidad del gerente es una visión integradora, que incorporar
requerimientos de negocio a las características individuales.
Ejemplo, un gerente esta interesado en el equilibrio entre la mejora del
software y los costos y tiempos establecidos.
140

141. 4 Especificar los Objetivos
Conocer los objetivos tanto generales como específicos del software.
5 Aplicar el modelo de calidad
Elaborar un instrumento o formato donde aplique el modelo de calidad
externo e interno y calidad de uso.
Si existe un comité o conjunto de personas encargadas de la evaluación, el
instrumento debe ser aprobado por los participantes.
6 Criterios de la evaluación
Los criterios parten de los 7 indicadores principales los cuales fueron
socializados anteriormente.
Los criterios para evaluar el software se dividen en dos grandes bloques:
uno dedicado a criterios que son aplicables a cualquier tipo de software
(criterios generales), y otro conjunto compuesto por criterios adaptables al
grupo de software evaluados (criterios específicos). En este caso se definen
los criterios en la Fig.19 de la evaluación según el tipo de software, para el
cual debe conformar un equipo evaluador, este ejercicio ayuda a definir que
opciones se deben evaluar con más detalle y valor.
Fig.19 Criterios al evaluar un software.
141

142. 7 Seleccionar métricas
La selección de métricas se obtiene a partir de los indicadores especificados
en el modelo.
Niveles o escalas
• A cada métrica seleccionada le asigna un puntaje máximo de referencia.
• La suma de los puntajes máximos de todas las métricas debe ser igual o
aproximado a 100 puntos.
• El personal que participa en la evaluación debe establecer niveles de
calificación cualitativa con base a los puntajes, por ejemplo:
De 0 a 1 Inaceptable.
De 2 a 3 mínimo aceptable
Mas de 3 Aceptable o satisfactorio
Otro ejemplo de calificación cualitativa puede ser:
Deficiente
Insuficiente
Aceptable
Sobresaliente
Excelente
• Se permite usar números enteros o hasta con un decimal de
aproximación.
• Definir por cada métrica, un puntaje mínimo de aprobación, y al final de
la evaluación, dependiendo del puntaje si es mayor o menor a lo propuesto,
considerar si el software cumple o no cumple con los objetivos propuestos.
142

143. 8 Establecer criterios
Las persona que participa en el proceso de evaluación debe tener criterios
con respecto al indicador que se esta analizando, Es importante tener en
cuenta que el criterio debe ajustar al tipo de software que se va a evaluar.
9 Tomar medidas
Para la medición, las métricas seleccionadas se aplican al software. Los
resultados son valores expresados en las escalas de las métricas, definidos
previamente.
10 Resultados
El proceso de evaluación genera un cuadro de resultados por cada uno de
los principales indicadores y el total final de resultado.
11 Documentación
El proceso de evaluación se documenta, indicando la fecha, empresa, los
cargos, nombres y apellidos, dependencia de las personas que participan en
el proceso de evaluación, especificando las etapas en las que participaron.
6.12 Seguimiento
Si el resultado de la evaluación tiene observaciones o indicadores de calidad
bajos, y el personal que lo evalúa permite realizar la corrección, se
programa otra evaluación donde se verifique que el proceso mejora, el
tiempo que se estime debe influir en los criterios de la aproxima evaluación.
143

144. 4.10 Preguntas de repaso y prácticas sugeridas.
1. Investigar y participar en un foro de discusión en clase para abordar las
diferencias que existen así como las ventajas y desventajas de aplicar un
modelo de ciclo de vida respecto a otro.
2. Realizar la revisión técnica formal del producto de software teniendo
como base los factores de calidad de McCall, ésta revisión puede llevarse
a cabo dentro de la clase en donde para corroborar la existencia de los
mismos se le pide a los integrantes del equipo identifiquen y justifiquen
como fueron aplicados a su producto de software.
3. Integrar como parte de las estrategias de un nuevo ciclo de desarrollo,
los factores de calidad, de manera que durante el análisis, diseño y
desarrollo del producto se mantenga como objetivo lograr que estos
factores estén presentes y puedan ser demostrados para una nueva
revisión.
4. Llevar a cabo el resumen final del proyecto, donde se integre la
información, lecciones aprendidas y mediciones realizadas a través del
proyecto. Un buen ejercicio final puede ser documentar adecuadamente
la base de conocimiento adquirida para futuros proyectos a realizar.
5. Investigar y discutir a manera de lluvia de ideas en clase cuales fueron
las mejores practicas que pueden ayudar a que la calidad de un producto
de software se obtenga.
6. Investigar más sobre los costos que acarrea el implantar o buscar calidad
en los productos de software.
144

145. ANEXOS
Anexo 1: Tareas por roles y fases de desarrollo
Las siguientes tablas contienen actividades propuestas para un ciclo de
desarrollo de software, se han citado las mas comunes que se pueden
encontrar para realizar en un proyecto de clase, por lo cual puede ser usado
como referencia para los alumnos pudiendo agregar o eliminar aquellas que
consideren mas adecuadas a su proyecto. Es conveniente que en base a la
experiencia adquirida en otros proyectos, se planee el tiempo requerido para
efectuarlas, y se registre en la hoja de avance de proyecto individual (Anexo
2). Al concluir las fases en un ciclo de desarrollo (se recomienda efectuar
todas, y limitar el producto resultante para cada ciclo) se realizará una
retroalimentación (POSTMORTEM) de dicho ciclo para que cada equipo vea
cuales prácticas concensuadas pudieron ser llevadas a cabo y cuales no, de
tal forma que puedan plantear o replantear estrategias que les permitan
alcanzar sus metas en el próximo ciclo de desarrollo.
Se recomienda que sea el instructor o profesor quien aplique una Revisión
Técnica Formal (RTF) con el fin de corroborar los objetivos planteados y los
obtenidos.
También es recomendable que los estudiantes adquieran el hábito de
registrar sus actividades y documentarlas adecuadamente, de modo que
éstas puedan servir de evidencia en cada ciclo para comparar la madurez del
proceso de desarrollo de software. Es importante señalar que los formatos
consideran al PSP y TSP como procesos a implantar para el desarrollo del
proyecto de software no importando su trabajo y que tienen como finalidad
el aprendizaje práctico y aplicación de las disciplinas y mejores prácticas de
desarrollo.
Para iniciar el proyecto el equipo deberá estar compuesto de al menos 5
personas quienes tomarán los roles de Líder, Analista, Diseñador,
145

146. Programador, Tester y Asegurador de Calidad para el caso de equipos mas
pequeños, pueden asumirse 2 roles o repartir las tareas asignadas.. Como
podrá observarse hay actividades para todos ellos en todas las fases, esto
fomenta el trabajo colaborativo pero también debe recalcarse la importancia
de la comunicación y responsabilidad de cada integrante para cumplir con
las tareas que le sean encomendadas.
En cada actividad existe un responsable de coordinarla, para el caso de la
actividad en que Todos sean responsables, el líder de proyecto será quien
verifique que realmente la actividad fue efectuada por todos los miembros.
Se recomienda como línea base establecer un tiempo máximo por dia (una
hora por ejemplo) con el cual debe contribuir cada miembro del equipo, así
como hacer una distribución equitativa del numero de horas por ciclo.
Ejemplo de pasos a seguir:
1.-El equipo se reúne y decide cual será el objetivo a cumplir para el primer
ciclo: el producto A.
2.- El equipo designa los roles que cada integrante tendrá y analiza la lista
de tareas asignando un tiempo para cada actividad, teniendo en cuenta la
fecha de entrega para no sobrepasar el tiempo.
3.- El número de horas (o tiempo total) se divide entre el número de
integrantes, por ejemplo 150 hrs./5 = 30 hrs/hombre  este es el número
máximo de horas que cada elemento aportara durante el primer ciclo, por lo
cual las tareas asignadas no deben sobrepasar este rango y si faltan deberá
completarlas con tareas de apoyo a otro miembro. De esta forma el esfuerzo
de cada miembro podrá equilibrarse. Las actividades deberá registrarlas en
un formato, que se ve en el Anexo 2.
146

147. FASE: LANZAMIENTO E L A D P T Q
Formar equipo de trabajo R
Definir proyecto/Investigar que proyecto hacer R
Definición de lugar y horas de trabajo R
Definición de estándares de documentos R
Definir un presupuesto general investiga precios R
Asignación de roles y tareas preeliminares X R
Capturar toda la información anterior con base
X X X X X X
en la plantilla de equipo
Impresión de los documentos X X X X X
DEFINICION DE ESTRATEGIAS PARA EL CICLO A
DESARROLLAR
Lectura-Revisión solicita corrección
R
de los documentos emitidos
Bitácora de equipo R
Preservar documentación y archivos
X R
DURANTE TODO EL CICLO
RESPALDO DE TODOS LOS ARCHIVOS DURANTE
x R
TODOS LOS CICLOS /Elaborar un plan de respaldo
VERIFICA TIEMPOS Y ACTIVIDADES QUE SE
R X
ESTEN REALIZANDO A TIEMPO
Simbología
R = Responsable X = colaborador
E= Todos (EQUIPO) L=Líder de proyecto A=Analista D=Diseñador
P=Programador T=Tester Q= Asegurador de Calidad
147

148. FASE: PLANEACION Y
E L A D P T Q
ANALISIS DE REQUERIMIENTOS
Definir tareas generales de acuerdo al
X R
proyecto en formato TSP ciclo N
Definir tareas particulares de acuerdo al
Rol y proyecto seleccionado formato PSP X R
ciclo N
Realización de actividades del análisis
X R
general de acuerdo al proyecto
Definición de requerimientos R
Elaboración de modelos que representen
R X
dichos requerimientos
Revisión de modelos de acuerdo a
X R
requerimientos
Formular estrategias de capacitación para
el desarrollo del producto o capacitar al R
equipo
Análisis de alternativas, riesgos, etc X R
Actualización de formatos TSP X R
Actualización de formatos PSP R
Elaboración de documentos del análisis
X R
general
Elaboración de prototipo de acuerdo a los
requerimientos o elaboración diseño R R R
preeliminar
Prueba a los prototipos (en caso de
haberlos realizados) verifica x R X
requerimientos
Lectura-Revisión y solicita corrección
x x R
de los documentos emitidos
Entrega de avances R
148

149. FASE: DISEÑO E L A D P T Q
Diseño físico del producto x x R
Diseño lógico del producto x x R x
Diseño de controles preventivos, detectivos
R x
correctivos del producto
Diseño de pruebas al producto x x R
Diseño de la seguridad del producto (física,
x R x x
integridad,
Verificación del diseño con base en los
x x x R
requerimientos antes definidos
Pruebas al diseño(s) del producto x x R X
Elaboración de algoritmos de solución x X R
Capacitación en herramientas de desarrollo a
x x R x
miembros del equipo
Elaboración de documentos del diseño en
X R X
general
Presentación del diseño al cliente R x x x
Rectificación de requerimientos solicitados
x x x x R
por el cliente en el diseño del producto
Actualización de formatos TSP X R
Actualización de formatos PSP R
Lectura-Revisión y solicita corrección
x x R
de los documentos emitidos
Entrega de avances/ Bitácora R
Simbología
R = Responsable X = colaborador
E= Todos L=Líder de proyecto A=Analista D=Diseñador
P=Programador T=Tester Q= Asegurador de Calidad
149

150. FASE: IMPLEMENTACION Y PRUEBAS E L A D P T Q
Desarrollo de programas con base en los diseños x R
Elaboración de pruebas al producto de software
x R x
documentación del resultado de las mismas
Verificación del cumplimiento de los
requerimientos en el producto de software. R x
Solicitud de correcciones
Documentar tiempos y errores durante
R
programación
Actualización de formatos TSP X R
Actualización de formatos PSP R
Lectura-Revisión y solicita corrección
x x R
de los documentos emitidos
Entrega de avances/ Bitácora R
FASE: POSTMORTEM E L A D P T Q
Cierre de formato PSP de acuerdo al ciclo
R
progamado
Cierre de formato TSP de acuerdo al ciclo
R
programado
Resumen de tiempos, esfuerzo, errores R X x
Análisis de los resultados obtenidos vs estrategias
R
utilizadas
Resumen de conclusiones para el ciclo concluido R
Cierre de toda la documentación emitida durante
R
el ciclo
Verificación de la documentación a entregar x x R
Diseño de presentación del producto
x R
verificación de la misma
Entrega de avances/ Bitácora R
(en su caso) Preparación de capacitación al
x R
usuario
150

151. Anexo 2 Formato para planeación y registro de tiempo individual
Ejemplo (continuación)
4.-Cada integrante es responsable de registrar y documentar sus
actividades, al término de las mismas reportar al responsable de la actividad
y lider del equipo. Al concluir el ciclo de desarrollo deberá obtener el numero
total de horas para cada actividad y participar con su equipo en el
postmortem.(Anexo 3)
151

152. Anexo 3 Formato auxiliar para postmortem y lecciones aprendidas.
FASE: LANZAMIENTO SI NO Observaciones
¿Se llevo a cabo la formación del equipo en
forma adecuada?
El proyecto fue definido en su objetivo
general?
Se definieron las horas y lugar de trabajo de
equipo
Fueron definidos los estándares de
documentación y trabajo en esta fase?
Los roles están asignados de acuerdo a las
características y fortalezas de cada
integrante?
Fueron reconocidas las habilidades y se
formularon estrategias para fortalecer las
deficiencias en cada integrante del equipo?
Los participantes del equipo conocen sus
roles asignados y las
tareas a realizar
Cada integrante cuenta con su documento
PSP impreso y actualizado
Se definieron estrategias para el proyecto en
esta etapa y fueron seguidas por todos y
cada uno de los integrantes
Se llevó a cabo un plan de presupuesto y
estrategias para asumir los costos inherentes
a la realización del proyecto?
Se llevo a cabo la lectura y corrección de los
documentos que forman parte de esta fase
El equipo tomó como parte de sus estrategias
el asesoramiento por parte del profesor?
En la bitácora de equipo pueden identificarse
las actividades referentes a esta fase
Se realizo una estrategia de respaldo y
resguardo de los documentos y archivos
generados
Se formularon estrategias de capacitación
para el desarrollo del producto o capacitar al
equipo?
Todos los participantes del equipo terminaron
al mismo tiempo esta fase?
Se realizo la verificación de tiempos
asignados para esta fase de forma adecuada
y oportuna
152

153. Los formatos de TSP se refieren a un cronograma general que el equipo
puede plantear con los tiempos como se explicó en el anexo 1, y el formato
de PSP se refiere al formato de planeación de actividades individual.
FASE: PLANEACION Y
ANALISIS DE REQUERIMIENTOS SI NO OBSERVACIONES
Fueron definidas las tareas y tiempos en el
formato TSP,
Fueron definidas las tareas particulares de
acuerdo al Rol y proyecto seleccionado
utilizando el formato de PSP?
Cada integrante realizó su PSP considerando
los tiempos y fases marcadas en el TSP del
equipo? El formato fue verificado por
el líder de proyecto y SQA?
Cada integrante contó con su PSP impreso y
fue actualizado diariamente?
El analista definió otras tareas o actividades
de apoyo para los compañeros del equipo?
Se elaboraron estrategias para conocer los
requerimientos del cliente?
Se obtuvieron los requerimientos del cliente o
usuario potencial directamente?
Los requerimientos están expresados por
documentos y/o modelos que son claramente
entendidos por los miembros del equipo?
Las técnicas empleadas durante el análisis
fueron suficientes para la obtención de los
requerimientos?
Se formularon alternativas de desarrollo y/o
solución al producto a desarrollar?
Se realizó un análisis de factibilidad para el
proyecto?
Se desarrollo un análisis de riesgos
congruente con el proyecto a desarrollar?
Fueron planeadas en esta fase los tiempos
para realizar las pruebas al proyecto?
Hubo algún prototipo preeliminar desarrollado
para la mayor comprensión de los
requerimientos al cliente.?
Hubo una buena comunicación del analista
hacia los demás integrantes del equipo
durante esta fase?
Los documentos elaborados para esta fase
fueron previamente revisados y aprobados por
el líder de proyecto y SQA?
Las actividades de esta fase están reflejadas
en la bitácora de equipo y en los formatos de
planeación individual de los integrantes?
153

154. FASE: DISEÑO SI NO Observaciones
El diseñador recibió las especificaciones del analista en
forma adecuada y oportuna (a tiempo)?
Fueron considerados los riesgos y alternativas de la fase
de análisis para el diseño del producto?
Se cuenta con un diseño optimo para la prevención,
detección y corrección de errores del producto?
Fueron diseñadas las pruebas al producto tomando en
cuenta los diseños y requerimientos señalados?
Fue verificado el diseño del producto de software en
base a los requerimientos antes definidos
Verificación del diseño con base en los
requerimientos antes definidos
Fueron elaborados y documentados los algoritmos,
rutinas, componentes durante su diseño?
Los algoritmos fueron comprendidos por todos los
miembros del equipo?
En esta fase se dio inicio a la capacitación del equipo en
lo referente a la programacion u otros aspectos a
mejorar?
Fueron revisados y verificados los documentos durante
esta fase?
Se presentaron los diseños al cliente o usuario potencial?
Fueron rectificados los diseños de acuerdo a las
observaciones hechas por el cliente o usuario potencial?
Hubo una buena comunicación del diseñador hacia los
demás integrantes del equipo durante esta fase?
Los documentos elaborados para esta fase fueron
previamente revisados y aprobados por el líder de
proyecto y SQA?
154

155. Las actividades de esta fase están reflejadas en la
bitácora de equipo y en los psp de los integrantes?
Se formuló como estrategia la reutilización de diseños?
FASE: IMPLEMENTACION Y PRUEBAS Si NO OBSERVACIONES
Se desarrollaron los programas con base en los diseños
aprobados ?
Fueron elaboradas las pruebas de acuerdo a un
procedimiento establecido y documentado?
Se verificó por parte del SQA y tester el cumplimiento
de los requerimientos en el
producto de software. Solicitud de correcciones
Se documentaron la solicitud de correcciones
Se documentaron los errores y tiempos de corrección
Se tuvo la participación de todos los miembros del
equipo durante la programación
Las actividades de esta fase están reflejadas en la
bitácora de equipo y en los psp de los integrantes?
Existió buena comunicación del programador hacia los
demás integrantes del equipo en esta fase?
Existió buena comunicación del SQA hacia los demás
integrantes del equipo en esta fase?
Existió buena comunicación del tester hacia los demás
integrantes del equipo en esta fase?
Fueron revisados y verificados los documentos durante
esta fase?
S N OBSERVACIONE
FASE: POSTMORTEM
I O S
Se realizó el cierre de formato PSP de acuerdo al ciclo
programado
Se realizo el cierre del formato TSP del ciclo
Se obtuvieron los valores de tiempo, esfuerzo, recursos
financieros
El análisis de los resultados obtenidos vs estrategias
utilizadas se hizo por todos los integrantes?
Se documento las conclusiones del ciclo presente
155

156. SE hizo la entrega oportuna de la documentación final
por parte de todos los integrantes del equipo?
Verificación de la documentación a entregar
Realización del CHECKLIST de postmortem.
Ejemplo (Continuación)
5.- Los integrantes del equipo al concluir la fase de postmortem y observar
los datos recolectados, así como los tiempos aportados, y las diferencias
obtenidas, podrán replantear estrategias para un nuevo ciclo de desarrollo y
documentar aquellas experiencias (lecciones aprendidas) que tuvieron
durante el primer ciclo y ciclos siguientes.
Todas las fases se repiten para cada ciclo, para un semestre normal de 16
semanas pueden dividirse en 2 ciclos de 8 semanas de desarrollo o en
pequeños ciclos de 4 semanas (en productos de software no grandes). La
finalidad de aplicar estos formatos es únicamente que el estudiante pueda
controlar sus procesos de desarrollo, documentarlos y aprender de él mismo
cómo puede mejorarlos, y cómo puede trabajar en un equipo efectivamente.
156

157. Anexo 4 Entrevistas realizadas a profesionistas del área de calidad y
desarrollo de software.
Durante el periodo de recabar información para el texto presente, se presentó
la oportunidad de platicar y entrevistar a profesionistas del área de calidad o
desarrollo de software. Quise incluir en este anexo, algunas de estas pláticas a
modo de conclusión, ya que existen numerosos libros, revistas, artículos y
referencias, pero sin embargo es importante considerar la experiencia que se
vive diariamente o que se ha acumulado por parte de quienes son responsables
directos de aplicar las normas, prácticas, modelos, etc., que aquí se han
mencionado.
Entrevista a Mario Segura Velazquez
Mario Segura Velazquez
Es Ingeniero Mecánico eléctrico, egresado de la Escuela Nacional de Estudios Profesionales
Aragón ENEP Aragón UNAM, de 2001 a 2005 fungió como instructor de calidad y mejora
continua de la empresa Coordinados de México Oriente de una de las empresas del Grupo
ADO. Actualmente es Promotor de Calidad y Mejora Continua de la empresa ADQUEM (empresa
de desarrollo de software a la medida).
__________________________________________________________________
ERG: ¿Cómo defines el término Calidad?
MSV: Calidad es una cultura que nos permite realizar y ofrecer servicios y productos
cumpliendo con los requerimientos del cliente
ERG: ¿Crees que la calidad sea una cuestión de percepción que tiene finalmente el
cliente?
Es sólo una parte, el que el cliente perciba que está bien hecho con lleva a que se estén
cumpliendo con los procesos y métodos que definen la realización de un producto y un servicio,
por eso podemos hablar de mala calidad, mediana calidad, alta calidad.
ERG: ¿La calidad tiene que ver con el proceso de elaboración del producto o servicio?
157

158. MSV: Absoutamente.
ERG:¿Quien define entonces la calidad: el proceso, el cliente...quien o qué?
MSV: Bueno si es desde ahí, tienes que irte desde mucho más atrás, desde lo que vas a
ofrecer un servicio y un producto, verificar los requerimientos de ese servicio y producto, en
base a un estudio de mercado, definir un proceso, aplicarlo, detectar áreas de oportunidad y
mejorarlo. Es todo un ciclo como el PHVA (Planear-Verificar-Hacer-Actuar) de Deming.
Se realiza el análisis de una necesidad, luego la construcción de un proceso que satisficiera esa
necesidad, la detección de áreas de oportunidad, y la mejora del mismo para cumplir con esas
necesidades del cliente
ERG: Hay autores que dicen que quien define la calidad es el cliente, otros
dependiendo de cómo es realizado hacia el proceso y otros mas hacia el
cumplimiento de normas ya preestablecidas. ¿Qué opinas de eso?
MSV: Yo voy mas a un análisis de las necesidades del cliente y si es así lo define el cliente no
podemos construir ni ofrecer lo que no van a compara o no usarán.
ERG: Siendo así, ¿Podríamos decir que se cumple aquello de "al cliente lo que pida" y
traducirlo a que "si hacemos lo que el cliente pidió tenemos un producto o servicio
con mas calidad"?
MSV: Si cumple con la satisfacción del cliente, sí. Por ejemplo: si te atienden bien... ¿Estas
contenta?, si compras algo que funciona ... ¿Estas conforme?
ERG:¿Que importancia tiene entonces la calidad para los procesos de desarrollo de
software?
MSV: Mucha y no creo que solo sea para procesos de software es para cualquier proceso en
general.
ERG: ¿Consideras que la Calidad solo un “termino de moda”?
MSV: Bueno en realidad creo que la actualidad, se entiende por ―moda‖ de que las empresas
solo quieren obtener certificados de diestra a siniestra: ISO 9001,CMMI nivel de madurez 5,
Six Sigma, TIL Cobit, y un sin numero de certificaciones que hay, porque creen que les da
prestigio, y si lo da, pero de nada les sirve tener un certificado en lo que quieran sino mejoran
sus procesos e implementan una cultura de calidad cuando salga una nueva norma, como "esta
de moda", la tomas y consigues el certificado,‖lo compras‖ y descuidas el proceso.
ERG: ¿El contar con un certificado de calidad asegura que tu proceso de desarrollo es
correcto, eficiente?
MSV: No, el tener un título ¿Te asegura que eres un buen ingeniero? Un ―doctor en calidad‖
puede ser muy bueno en la teoría, ¿Pero lo será en la práctica? Conseguir una certificación es
fácil, mantener el sistema de calidad es diferente
ERG:¿Cuales serian los “cuidados”, por así decirlo que deben considerar las
empresas para mantener su sistema de calidad?
158

159. MSV: Compromiso de la dirección, análisis de fortalezas y debilidades, documentación de
procesos, capacitación del personal, comité de seguimiento, tener un método de recabar
quejas y sugerencias, y un plan de comunicación adecuado.
ERG: Para la industria mexicana ¿Qué tan difícil ha sido “entrar” a todo esto de la
calidad a comparación de otras industrias como la India, EU, Union Europea?
¿Influye la cultura?
MSV: Observo la resistencia al cambio, a la gente no le gusta mejorar quiere seguir haciendo
lo mismo, le da miedo.
ERG: ¿Consideras que el mexicano es conformista por no querer mejorar?
MSV: Sí en el sentido de que no tenemos planeación, si no hay planeación no hay objetivos,
si no hay objetivos no hay metas, y sin metas no hay acciones.
ERG: y ¿Visualizas alguna ventaja que tengamos?
MSV: Muchas. Tenemos recursos, gente, es un buen principio.
ERG: ¿A que te refieres con recursos y gente? ¿Qué es lo que ves en ellos?
MSV: En que en México tenemos medios al alcance de la tecnología, conocimientos los hay, y
hay personas con hambre de mejorar, pero en ocasiones nosotros mismos ―nos ponemos el
pie‖.
ERG: ¿Cuántas PYMES que inician en México logran “sobrevivir” sin una cultura de
calidad?
MSV: La vida de una PYME sin esas condiciones es de 2 años, por falta de planeación.
ERG: ¿Falta preparación en este rubro?
MSV: Bastante. En sí desde las bases en la ecuación primaria. Hablamos de Calidad Educativa,
Calidad de vida, utilizamos mucho la palabra calidad pero no le damos el sentido verdadero.
ERG: Ya que lo has mencionado, ¿Que relación existe entre la calidad de vida y la
calidad del producto o servicio que puede ofrecer una persona?
MSV: Mucha. Si la gente no está satisfecha con su trabajo, no lo hará bien y eso afecta a la
calidad de lo que hace u ofrece.
ERG: ¿Y que pasa para un profesionista?
MSV: Pasa lo mismo, si no estás contento con tu trabajo y las condiciones del mismo no son
las mejores, no lo realizas bien.
ERG: ¿Existen otros factores, además del trabajo que puedan afectar a la calidad del
servicio o producto que ofrece una persona?
MSV: Sí, una remuneración justa y equitativa, un ambiente de trabajo agradable, un desarrollo
profesional, un reconocimiento de su trabajo, una retroalimentación de lo que hace. Si no hay
eso, esta desmotivado y no hace bien su trabajo, sea el trabajo que sea o la actividad que
realice.
159

160. ERG: Por último,¿Qué recomendaciones harías para adentrarse a estos temas de
calidad: para los estudiantes quienes se están preparando en alguna profesión y
para las industrias (cual sea su tamaño) que desean iniciar alguna certificación?
MSV: Para los estudiantes inculcarles que los conocimientos sin un enfoque a la planeación y
mejora de las cosas no sirven de nada. Y a las industrias el compromiso de impulsar la mejora
de sus productos y servicios pero mejorando la calidad de vida de sus colaboradores.
ENTREVISTA CON DR. LUIS CARLOS VARGAS HERRING
Luis Carlos Vargas Herring es Dr. En Sistemas computacionales (Sistemas Distribuidos)
egresado de la Universidad de Cambridge, estudió su maestria en Sistemas
Computacionales en la Universidad de Essex, y la carrera de Ingeniero en Sistemas
Computacionales en el Tecnologico de Celaya.
Cuenta con las certificaciones MCSD(Microsoft Certified Solution Developer),
MCDBA(Microsoft Certified DataBase Administrador), ha trabajado como Technical Leader
en General Electric Treasury Sistem , Software Developer en GMatrix y actualmente se
desempeña como Program Manager en SQL Server en Microsoft En Estados unidos.
________________________________________________________
ERG: ¿Como podrías resumir tu experiencia en el desarrollo de productos de
software? ¿Ha cambiado o mejorado?
LCVH: Cada vez ha sido más estructurada, con más normas y cada vez ha sido más dinámica.
Me he tenido que adaptar mas rápido Cuando empezaba a trabajar en México, no había
división de roles, así que empecé realizando varios roles o tareas pero en sí no había una
clasificación de los roles que debía fungir.
Tampoco había normas que seguir, así que yo me encargaba de la calidad del producto. Mas
tarde en GE había mas estructura, ya que me tocó los roles de desarrollador y tester para
asegurar la calidad, el diseño ya estaba en base de los requerimientos y teníamos junta con los
analistas de negocio quienes decidían cuales eran las características que debía tener el
software, en juntas platicábamos que características debía tener el producto. Así que cuando se
empezaba a desarrollar ya teníamos una idea mas clara sobre lo que se quería hacer, incluso
se tenían algunos procesos ya identificados y existían patrones a seguir para el desarrollo,
recomendaciones a seguir, y esto nos servia como una guía para el mismo desarrollo.
En cuanto al testing, no había mucho proceso, el desarrollador hacia las pruebas y se ponía en
lugar del usuario, así que ahí si faltaba definir mas cosas.
Ya una vez que el software estaba probado, existía ya documentación para realizar el montaje
del producto en los servidores, de forma que si había alguna duda o error se podía consultar
esta documentación, este proceso se debía hacer con mucho cuidado.
De aquí y después de mi doctorado mi experiencia hasta ahora ha sido en Microsoft, en donde
existe un mayor numero de procesos ya definidos desde el diseño de software, en el
desarrollo si hay un conjunto de practicas que se deben seguir así como un conjunto de
herramientas, por ejemplo hay herramientas para el control del módulo para asegurar que los
módulos no se vean afectados unos al otro.
El testing es completamente estructurado, está el líder de proyecto, cuya función es decidir
cual es la siguiente versión del producto a realizar, teniendo información de nuestros clientes,
de otros productos o referencias en revistas, esto es para hacerlo mas competitivo en el
mercado. El líder decide la funcionalidad que va a tener el producto de software y el criterio
160

161. de éxito, esto es algo que al final de que el producto esta realizado, se puede calificar y decidir
si fue exitoso o no.
P ej. Se quiere una funcionalidad para hacer una replicar información de una BD El criterio de
éxito seria que esa funcionalidad tenga un nivel bajo de fallos y que el proceso de replicación
va a durar menos de determinado tiempo.
Se tienen que tomar criterios que sean mesurables de tal forma que al finalizar el equipo que
desarrolló la funcionalidad pueda saber si en realidad funcionó o no. Por lo tanto los criterios
son importantes ya que cuando se está desarrollando se tiene que tener en mente que dicho
criterio debe cumplirse.
ERG: ¿Estos criterios ya vienen definidos por parte de Microsoft?
CVH: Dentro de cada producto por ejemplo SWL tiene varios equipos, un equipo se encarga de
cierta parte del producto. Se tiene un consejo (no añaden nada de funcionalidad que asegura
que lo que los equipos hacen tenga o cumpla ciertas normas de calidad; entonces ese consejo
se encarga de varios aspectos, por ejemplo dentro de ese consejo hay un equipo que se
encarga de seguridad conformado de 3 o 4 personas expertas en seguridad y que es encargan
que cualquier funcionalidad que nuestros equipos añaden al producto cumpla con las normas
de seguridad de Microsoft. Así como éste equipo hay otro encargado del desempeño, otro de
privacidad, otro de globalización, esto último es importante porque siendo SQL Server un
producto que se usa a nivel mundial, cualquier funcionalidad que añadamos tiene que funcionar
para cualquier idioma, ya que hay idiomas que utilizan palabras muy largas, imagínate que
quieras poner un mensaje de error y éste sea demasiado largo para el lugar donde lo quieras
ubicar…entonces ese consejo tiene sus grupos para cuidar cada aspecto, y se tiene que tener la
aprobación de todos ellos antes de escribir cualquier línea de código.
Antes de escribir este código debe existir un documento de diseño (pseudocódigo, y estructuras
de datos a implementar en la funcionalidad) ese lo revisa el líder de proyecto y el tester, en
base a este documento se crea el documento de testing, que indica que es lo que se va a
aprobar y cómo se va a probar (también aprobado por el líder de proyecto y el desarrollador)
ERG: ¿Qué pasa si ninguno de estos documentos está aprobado? ¿Les implica tiempo
y costo?
LCVH: Si, básicamente si el documento no esta aprobado no puedes implementar, es tiempo
perdido y tienes que ponerte de acuerdo y poder solucionar el problema.
ERG: ¿Te dan algún tiempo límite para que pueda llevarse a cabo la aprobación?
LCVH: Yo como líder de proyecto establezco los tiempos, desde que empiezo a escribir las
especificaciones funcionales yo tengo que darle una fecha a mi jefe y esa es la fecha en la que
vamos a empezar a desarrollar, si llegado ese plazo no se ha empezado a desarrollar mi jefe
empieza a presionar obviamente, entonces yo como líder tengo que preocuparme por que mi
equipo pueda empezar a desarrollar en esa fecha.
ERG: ¿ Y qué pasa si tu te adelantas a las fechas?
LCVH: No pasa nada, cualquier tiempo que tu puedas ahorrar y tienes la aprobación de todas
las personas requeridas, del consejo y mi equipo, pues adelante. Generalmente no pasa.
Cuando ocurre esto puede significar que el líder de proyecto no es muy bueno estimando los
tiempos.
161

162. ERG:¿Te ha pasado?
LCVH:No, generalmente tiendo a ser estricto con las fechas y mas bien me ha pasado de estar
un poco mas tarde.
ERG: Con lo que me has dicho, me quedo con la idea de que en Microsoft el desarrollo
de producto es mas estructurado ya que hay procesos roles y actividades bien
definidas, además hay un elemento consejo que cuida estos procesos , ¿Ellos mismos
cuidan la calidad del producto y el proceso para obtenerla?
LCVH:Bueno la calidad es responsabilidad de cada uno de los grupos de hacerla, y el consejo
por decirlo así es quien revisa.
ERG: ¿Cómo le haces para obtener un producto de calidad?
LCVH: Yo creo que la calidad depende de 2 aspectos. Para mi es hacer lo que me indican los
requerimientos en el tiempo en el que se planeó, yo no creo que hacer calidad sea hacer el
producto que tenga la mayor cantidad de características o hacer un producto perfecto sin
ningún error.
¿Como se logra? Teniendo buenas especificaciones, buenos diseños y un buen equipo. Los
documentos se pueden cambiar fácil pero una vez escrito el código, eso es lo mas caro a
cambiar. Yo creo que el tener especificaciones claras y que todo mundo esté de acuerdo eso te
da casi el 80% de éxito del proyecto.
ERG: A través de todo este tiempo ¿Qué prácticas te han servido para obtener un
mejor producto o para lograr esa calidad?
LCVH: Lo primero y lo principal es entender los requerimientos del cliente. Eso desde la escuela
nos lo han dicho pero a veces se olvida. Básicamente como desarrollador de software queremos
hacer lo que creemos que es la mejor solución, pero el cliente tiene su propia concepción que
incluso puede llegar a ser mas simple de lo que nosotros pensábamos.
Tienes que estar en contacto con el cliente, por ejemplo mientras escribo las especificaciones
funcionales yo hago juntas o tengo llamadas telefónicas cada 2 semanas para asegurarme de
que lo que estoy planeando, lo que estoy diseñando es lo que ellos realmente quieren.
También es importante especificar claramente las fechas de cuando se va a revisar el avance
del proyecto y qué es lo que se va a revisar, dependiendo que tan grande es el proyecto puede
ser cada 3 semanas o cada mes, pero debe reunirse todo el equipo y preguntarse si en el punto
en el que están es el punto que originalmente pensaron que debieron estar.
ERG: ¿Tu recomendarías entonces que existan revisiones continuas a manera de
puntos de control del producto?
LCVH: Si, obviamente es un balance, no quiere decir tener juntas cada semana porque es
tiempo perdido de desarrollo y tester. Yo procuro tener juntas cada 3 semanas, y otra cosa
importante es tratar de ser totalmente abiertos con el equipo. Por ejemplo si el desarrollador
tiene alguna duda que él mismo lo platique con su equipo; yo tengo 4 desarrolladores y si
alguno tiene un problema grave, por ejemplo un código que no puede resolver, entonces que
en lugar de que se pase todo el día tratando de resolver el problema él solo, tenemos la política
de que él debe enviar un mail a todo el grupo desarrollador y si alguien ya ha tenido un
problema similar entonces trata de ayudarle, de esa forma no se pierde tiempo.
ERG: ¿Entonces el trabajo en equipo es esencial para el desarrollo del producto?
162

163. LCVH: Si.
ERG:¿Qué recomendaciones que tu harías para que quienes van empezando a
desarrollar software, a quienes están estudiando?
LCVH: Práctica. La práctica les va a ayudar, hay obviamente ciertos mecanismos en la carrera
donde puedes practicar como son las residencias, pero si se quieren dedicar a la industria de
software que entonces tomen sus residencias en una empresa dedicada al desarrollo de
software sino van a estar perdiendo su tiempo. Y lo otro de eso, antes de eso hay muchos
proyectos de Open Source, de código libre que están abiertos para que los que quieran pueden
participar colaborando con ellos, ellos cuentan con una estructura de cómo trabajar, hay
personas que se encargan de revisar código, otras dar consejos sobre cómo codificar, otras de
cómo diseñar para las próximas versiones. Que busquen que es lo que quieren hacer, hay de
todo, desde videojuegos hasta páginas web, pero también lo pueden hacer en su tiempo libre
para que vayan agarrando práctica de cómo debe trabajarse en equipo.
163

164. Anexo 5 Referencias
“Apuntes para análisis de sistemas”
María N. Moreno García
1 Departamento de Informática y Automática
Universidad de Salamanca
“Calidad en el Software”
Memoria de Experiencia Profesional,
2 María del Rocío Patiño Palacios,
ITCelaya, Junio 2004.
“Capital humano y conciencia de calidad”
Matías Sales, Portal de estudiantes de RRHH,
3 Universidad Champagnat, Argentina
matiassalesarrobauch.edu.ar
“CMM y la calidad en el desarrollo de software”
Innevo
4
www.innevo.com, junio 2009
“Garantía de la calidad de software”
Basado en CMU/SEI-93-tr-25
5 Traducción de SET consultores.
Versión 1.3 no liberada.
“Gestion de la calidad”
Humberto Cárdenas Sierra
6
21 Feb 2005, curso en línea www. mailxmail.com
“Guia Tecnica para la evaluacion del software”
7 Carlos Alberto Largo Garcia, Erledy Marin Mazo,
1ª.Edicion. www.puntoexe.com.co, 2005
―Ingeniería del Software, un enfoque práctico‖
8 Pressman, R. S.
6ª Edición. Mc Graw Hill, 2005.
164

165. “Ingeniería del Software”
9 Ian Sommerville 7a. Edición
Pearson Educación, SA, Madrid 2005
“Iniciativa Nacional TSP/PSP”
Beatriz Velazquez Soto‖,
10
SoftwareGuru, 31 julio 2008
2008 © SG Software Guru
“ISO/IEC 15504 (SPICE) Modelo de Evaluación, Mejora
y capacidad de Software”
Carmen Golobart,
11
Prisma Calidad y Medio ambiente consultores,
España. 21 abril 2009.
“La calidad del software y su medida”
Jesús M. Minguet Melian, Juan Francisco Hernández Ballesteros ,
12 Editorial Centro de Estudios Ramón Areces, S.A.
España.
“Manual de Calidad ISO 9001 para Negocios Pequeños”
Quality Sistems Innovations, Inc.
13
http://www.qsinnovations.com/iso9001espanol.htm ,
“Mejoramiento de los procesos de software”
Luciano Guerrero,
http://www.geocities.com/SiliconValley/Lab/3629/mejorami.htm
14
2000
“Modelo de procesos para la industria de Software”
Hanna Oktaba, Claudia Alquicira Esquivel, Angélica Su Ramos
15
Ver 1.3 Agosto 2005, Secretaria de Economía México.
“Modelo de Procesos”
16 Fanny Ruiz Castro.
“Presentación mundial de la versión en español del CMMI”
SG Software Guru - 15 de septiembre de 2009
17
2009 © SG Software Guru
“Procesos de Software”
18
Mara Ruvalcaba
165

166. SG Software Guru 16 de marzo de 2009
2009 © SG Software Guru
“Roles en el desarrollo de software”
David Fuller Padilla
Escuela de Ingeniería Civil Informática
19
Universidad Católica del Maule
Chile
www.eici.ucm.cl
“Técnicas cuantitativas para la gestión en la
Ingeniería de Software”
Tuya Javier, Ramos Román Isabel, Dolado Cosín Javier
20
NETBIBLO editorial
2007, España.
“The Capability Maturity Model for Software”
Mark C. Paulk, Software Engineering Institute
21
Carnegie Mellon University
Pittsburgh, PA 15213-3890
“The Capability Maturity Model”
Medellin Janzel
22 Proyecto de Fomento a la industria de software
en el Estado de Guanajuato, México .
“Un enfoque actual sobre la calidad del software”
Informe técnico Oscar M. Fernández Carrasco, Delba García
23 León y Alfa Beltrán Benavides. ACIMED 3(3):40-42, septiembre-
diciembre, 1995
cmm-cmu-sei-tr24-93 (CMM 1.1)
24
cmm-cmu-sei-tr25-93 (Key pract.)
25
166

167. 167