SlideShare una empresa de Scribd logo
1 de 167
Descargar para leer sin conexión
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...
Seminario de t...

Más contenido relacionado

La actualidad más candente

calidad para el producto del software
calidad para el producto del softwarecalidad para el producto del software
calidad para el producto del softwarearidesbetava15
 
Introduccion a calidad de software
Introduccion a calidad de softwareIntroduccion a calidad de software
Introduccion a calidad de softwareguest871c816
 
Unidad 5. calidad del software
Unidad 5. calidad del softwareUnidad 5. calidad del software
Unidad 5. calidad del softwareMaricela Ramirez
 
265570212 ensayo-debilidades-de-la-norma-iso-9126
265570212 ensayo-debilidades-de-la-norma-iso-9126265570212 ensayo-debilidades-de-la-norma-iso-9126
265570212 ensayo-debilidades-de-la-norma-iso-9126Andreita Guevara Trujillo
 
Fundamentos de la calidad del software
Fundamentos de la calidad del softwareFundamentos de la calidad del software
Fundamentos de la calidad del softwareJonathan
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de softwareMrEdHy
 
Calidad Del Producto Software
Calidad Del Producto SoftwareCalidad Del Producto Software
Calidad Del Producto Softwarealbert317
 
C32CM31 EQ2- Norma ISO 9126
C32CM31 EQ2- Norma ISO 9126C32CM31 EQ2- Norma ISO 9126
C32CM31 EQ2- Norma ISO 9126Aída M. Gómez
 
Control de Calidad del Software
Control de  Calidad del SoftwareControl de  Calidad del Software
Control de Calidad del SoftwareIntellimedia
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del softwareflaco_mendez
 
Norma iso 9126 español
Norma iso 9126 españolNorma iso 9126 español
Norma iso 9126 españolJuan Cortes
 
CALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRE
CALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRECALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRE
CALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTREJuan Raul Vergara
 
Estandares Iso,Spice Y Cmm Y Empresas
Estandares Iso,Spice Y Cmm Y  EmpresasEstandares Iso,Spice Y Cmm Y  Empresas
Estandares Iso,Spice Y Cmm Y Empresasguest8e0579
 

La actualidad más candente (20)

calidad para el producto del software
calidad para el producto del softwarecalidad para el producto del software
calidad para el producto del software
 
Introduccion a calidad de software
Introduccion a calidad de softwareIntroduccion a calidad de software
Introduccion a calidad de software
 
Unidad 5. calidad del software
Unidad 5. calidad del softwareUnidad 5. calidad del software
Unidad 5. calidad del software
 
265570212 ensayo-debilidades-de-la-norma-iso-9126
265570212 ensayo-debilidades-de-la-norma-iso-9126265570212 ensayo-debilidades-de-la-norma-iso-9126
265570212 ensayo-debilidades-de-la-norma-iso-9126
 
Fundamentos de la calidad del software
Fundamentos de la calidad del softwareFundamentos de la calidad del software
Fundamentos de la calidad del software
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
Ensayo
EnsayoEnsayo
Ensayo
 
Calidad Del Producto Software
Calidad Del Producto SoftwareCalidad Del Producto Software
Calidad Del Producto Software
 
C32CM31 EQ2- Norma ISO 9126
C32CM31 EQ2- Norma ISO 9126C32CM31 EQ2- Norma ISO 9126
C32CM31 EQ2- Norma ISO 9126
 
Control de Calidad del Software
Control de  Calidad del SoftwareControl de  Calidad del Software
Control de Calidad del Software
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
Conceptos basicos calidad software
Conceptos basicos calidad softwareConceptos basicos calidad software
Conceptos basicos calidad software
 
Norma iso 9126 español
Norma iso 9126 españolNorma iso 9126 español
Norma iso 9126 español
 
Norma iso 9126
Norma iso 9126Norma iso 9126
Norma iso 9126
 
CALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRE
CALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRECALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRE
CALIDAD DE SOFTWARE-SOLO SEPTIMO SEMESTRE
 
Calidad De Software Diapositivas
Calidad De Software DiapositivasCalidad De Software Diapositivas
Calidad De Software Diapositivas
 
Iso 9126
Iso 9126Iso 9126
Iso 9126
 
Estandares Iso,Spice Y Cmm Y Empresas
Estandares Iso,Spice Y Cmm Y  EmpresasEstandares Iso,Spice Y Cmm Y  Empresas
Estandares Iso,Spice Y Cmm Y Empresas
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
SEGUNDA PARTE - Gestion de la calidad del software
SEGUNDA PARTE - Gestion de la calidad del softwareSEGUNDA PARTE - Gestion de la calidad del software
SEGUNDA PARTE - Gestion de la calidad del software
 

Similar a Seminario de t...

Trabajo de analisis y diseño
Trabajo de analisis y diseñoTrabajo de analisis y diseño
Trabajo de analisis y diseñomary taipe
 
SQA versión 2: la calidad en el proceso y el producto
SQA versión 2: la calidad en el proceso y el productoSQA versión 2: la calidad en el proceso y el producto
SQA versión 2: la calidad en el proceso y el productoLuis Eduardo Pelaez Valencia
 
SQA-Sesión 01-Presentación de Fundamentos SQA-16x9
SQA-Sesión 01-Presentación de Fundamentos SQA-16x9SQA-Sesión 01-Presentación de Fundamentos SQA-16x9
SQA-Sesión 01-Presentación de Fundamentos SQA-16x9Luis Eduardo Pelaez Valencia
 
calidad en desarrollo de software y sus atributos
calidad en desarrollo de software y sus atributoscalidad en desarrollo de software y sus atributos
calidad en desarrollo de software y sus atributosArturoDelAngel9
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareKelvin Abdiel Alvarado
 
Calidad de software alex
Calidad de software alexCalidad de software alex
Calidad de software alexAlexander Ortis
 
Guía 2. Estandares de Calidad de Software - Sullin Santaella
Guía 2. Estandares de Calidad de Software - Sullin SantaellaGuía 2. Estandares de Calidad de Software - Sullin Santaella
Guía 2. Estandares de Calidad de Software - Sullin SantaellaJosé Ricardo Tillero Giménez
 
Articulo Calidad Del Software El Camino Al Exito Ver. Revisada
Articulo Calidad Del Software El Camino Al Exito Ver. RevisadaArticulo Calidad Del Software El Camino Al Exito Ver. Revisada
Articulo Calidad Del Software El Camino Al Exito Ver. Revisadainstituto tecnologico de colima
 
Guia de certificacion
Guia de certificacionGuia de certificacion
Guia de certificacionChumy Cima
 
331161221 santaella u2-estandaresenedisenodealgoritmos
331161221 santaella u2-estandaresenedisenodealgoritmos331161221 santaella u2-estandaresenedisenodealgoritmos
331161221 santaella u2-estandaresenedisenodealgoritmosSol Hernández
 
Material de apoyo unidad 2. estandares en el diseño de algoritmos
Material de apoyo unidad 2. estandares en el diseño de algoritmosMaterial de apoyo unidad 2. estandares en el diseño de algoritmos
Material de apoyo unidad 2. estandares en el diseño de algoritmosLeany González
 
Javierperez ensayo
Javierperez ensayoJavierperez ensayo
Javierperez ensayojavier peeez
 

Similar a Seminario de t... (20)

Trabajo de analisis y diseño
Trabajo de analisis y diseñoTrabajo de analisis y diseño
Trabajo de analisis y diseño
 
SQA versión 2: la calidad en el proceso y el producto
SQA versión 2: la calidad en el proceso y el productoSQA versión 2: la calidad en el proceso y el producto
SQA versión 2: la calidad en el proceso y el producto
 
SQA-Sesión 01-Presentación de Fundamentos SQA-16x9
SQA-Sesión 01-Presentación de Fundamentos SQA-16x9SQA-Sesión 01-Presentación de Fundamentos SQA-16x9
SQA-Sesión 01-Presentación de Fundamentos SQA-16x9
 
calidad en desarrollo de software y sus atributos
calidad en desarrollo de software y sus atributoscalidad en desarrollo de software y sus atributos
calidad en desarrollo de software y sus atributos
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de Software
 
1ra Unidad Calidad Del Software
1ra Unidad  Calidad Del  Software1ra Unidad  Calidad Del  Software
1ra Unidad Calidad Del Software
 
Calidad de software alex
Calidad de software alexCalidad de software alex
Calidad de software alex
 
14.administración de la calidad
14.administración de la calidad14.administración de la calidad
14.administración de la calidad
 
Guía 2. Estandares de Calidad de Software - Sullin Santaella
Guía 2. Estandares de Calidad de Software - Sullin SantaellaGuía 2. Estandares de Calidad de Software - Sullin Santaella
Guía 2. Estandares de Calidad de Software - Sullin Santaella
 
Articulo Calidad Del Software El Camino Al Exito Ver. Revisada
Articulo Calidad Del Software El Camino Al Exito Ver. RevisadaArticulo Calidad Del Software El Camino Al Exito Ver. Revisada
Articulo Calidad Del Software El Camino Al Exito Ver. Revisada
 
Calidadtarea1
Calidadtarea1Calidadtarea1
Calidadtarea1
 
Guia de certificacion
Guia de certificacionGuia de certificacion
Guia de certificacion
 
331161221 santaella u2-estandaresenedisenodealgoritmos
331161221 santaella u2-estandaresenedisenodealgoritmos331161221 santaella u2-estandaresenedisenodealgoritmos
331161221 santaella u2-estandaresenedisenodealgoritmos
 
Material de apoyo unidad 2. estandares en el diseño de algoritmos
Material de apoyo unidad 2. estandares en el diseño de algoritmosMaterial de apoyo unidad 2. estandares en el diseño de algoritmos
Material de apoyo unidad 2. estandares en el diseño de algoritmos
 
BoLeTiN N° 2
BoLeTiN N° 2BoLeTiN N° 2
BoLeTiN N° 2
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Como se mide la Calidad de software
Como se mide la Calidad de softwareComo se mide la Calidad de software
Como se mide la Calidad de software
 
Javierperez ensayo
Javierperez ensayoJavierperez ensayo
Javierperez ensayo
 

Seminario de t...

  • 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