CONTENIDOPG. CONTENIDO ....................................................................................... 1 Introduccin ...................................................................................... 3 1 Conceptos Bsicos de Calidad ......................................................... 4 1.1 Definicin de la calidad. ................................................................. 4 1.2 Definicin de calidad de software. ................................................... 5 1.3 Quin 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 prcticas sugeridas. .................................... 19 2 Aseguramiento de la Calidad del Software (SQA) ......................... 21 2.1 Relacin de la Ingeniera del Software con SQA. ............................. 22 2.2 Definicin y propsito 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 Mtodos y herramientas. ............................................................. 41 2.9 Enfoque de Procesos en el Desarrollo de software ........................... 43 2.9.1 Definicin 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 prcticas sugeridas. .................................. 56 3 Estndares 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 Cmo obtener calidad de software. ............................................. 124 4.3 Cmo controlar la calidad del software. ....................................... 125 4.4 Costo de la calidad del software. ................................................ 126 4.5 Nomenclatura y certificacin ISO 9001:2000................................ 129 4.6 La norma ISO/IEC 9126 ............................................................ 134 4.7 Anlisis de factores que determinan la calidad del software............ 136 4.8 Anlisis del proceso del ciclo de vida del software ......................... 138 4.9 Funciones de evaluacin del software .......................................... 139 4.10 Preguntas de repaso y prcticas sugeridas. ................................ 144 ANEXOS ......................................................................................... 145 Anexo 1: Tareas por roles y fases de desarrollo ................................. 145 Anexo 2 Formato para planeacin 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

IntroduccinLa 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 slo para continuar en el mercado, sino, adems 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 revolucin ms radical, siendo la produccin industrial de software una actividad con alta participacin de recursos humanos, cien por ciento intelectual y en cierto sentido sin insumos ni materias primas. Existen desarrolladores quienes continan creyendo que la calidad es algo en lo que se debe comenzar a preocupar hasta despus de que se ha generado el cdigo pero hay que tomar conciencia que la calidad se aplica a lo largo del proceso de software. En el texto que se presenta a continuacin trata de auxiliar a los estudiantes y docentes de nivel superior a comprender los principales conceptos relacionados con la calidad de software y los estndares 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 Espaa), Mara del Roco Patio Palacios (IMB Gdl. Mxico), Fernando Nuez Rojas (ITESI), Julio Armando Asato Espaa (ITC), todos ellos exalumnos del Instituto Tecnolgico de Celaya, quienes me brindaron su apoyo y experiencia para elaborar el presente texto.

3

1 Conceptos Bsicos de Calidad

1.1 Definicin 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 lgico, en lugar de fsico, de un sistema, por lo tanto tiene caractersticas diferentes a las del hardware, para este primer captulo 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 trmino calidad por si mismo, es subjetivo, Qu quiere decir esto? Que si quisiramos definirla se obtendran opiniones distintas, ya que un producto o servicio puede ser juzgado de manera diferente dependiendo de la percepcin de cada persona, de la educacin que tiene, su edad , experiencia, aspectos emocionales o estados de nimo entre otros factores.

Una definicin de la misma podr ser: La totalidad de caractersticas de un producto o servicio que se refieren a su habilidad para satisfacer necesidades establecidas o implicadas.

4

1.2 Definicin de calidad de software.La calidad del software se define como: Concordancia con los requerimientos funcionales y de rendimiento

explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.

La definicin anterior sirve para enfatizar tres puntos importantes:

1. La falta de concordancia con los requerimientos es falta de calidad. 2. Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. 3. Al no seguir esos criterios, casi siempre se dar una falta de calidad.

Existe un conjunto de requerimientos implcitos que a menudo no se mencionan (p. ej. Tener un buen mantenimiento). Si el software se ajusta a sus requerimientos explcitos pero falla en alcanzar los requerimientos implcitos, la calidad del software queda en entredicho. El American Heritage Dictionary define Calidad como una caracterstica o atributo de algo. Como atributo de un elemento, la calidad se refiere a caractersticas mensurables, es decir: cosas que se pueden comparar para conocer estndares, como longitud, color, propiedades elctricas y maleabilidad, sin embargo el software, principalmente una entidad intelectual, es ms difcil de caracterizar que los objetos fsicos. 5

Cuando se examina un elemento con base en sus caractersticas mensurables se pueden encontrar dos tipos de calidad: calidad de diseo y calidad de concordancia. La calidad de diseo se refiere a las caractersticas que los diseadores especifican para un elemento. La calidad de concordancia es el grado en el que las especificaciones de diseo se aplican durante la fabricacin. En el desarrollo de software, la calidad del diseo incluye requisitos, especificaciones y el diseo del sistema, La calidad de concordancia es un tema enfocado principalmente en la implementacin. Si sta sigue el diseo y el sistema resultante satisface sus requisitos y metas de desempeo, la calidad de concordancia es alta.

1.3 Quin define la calidad?Debe entenderse que en cuestin de la percepcin del servicio o producto final, el usuario es quien define la calidad; debiendo la empresa complacer a los clientes, y no contentarse slo con librarlos de sus problemas inmediatos, sino ir ms 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 slo del dominio exclusivo de grupos especiales de una organizacin; 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 estn generando bienes con un mayor valor agregado. Por tales motivos es esencial para las empresas practicar tanto la investigacin de mercado, como la inteligencia competitiva y una evaluacin comparativa. 6

Conocidos los deseos y necesidades de los consumidores, estos deben ser traducidas en trminos cuantitativos y tangibles. Este proceso de traduccin no es sencillo y requiere de la integracin de conocimientos de mercadotecnia con ingeniera y administracin, para que las necesidades del consumidor y las expectativas que desarroll durante el proceso de seleccin del producto, puedan ser satisfechas completamente. Entre la tcnica ms importante para tales fines tenemos el Despliegue de la Funcin de Calidad (QFD), el cual sirve para realizar todo este proceso de traduccin, ayudando a que la voz del cliente se despliegue a travs de toda la organizacin. La funcin de despliegue de la calidad tiene como objetivo asegurar que se cumplan las expectativas del cliente desde el diseo del producto, durante su proceso de manufactura, y hasta que es utilizado por el consumidor. En japons se le llama ten-kai lo cul significa despliegue, refirindose a la idea de llevar las necesidades y expectativas del cliente expresados en su lenguaje (voz del cliente) a todos los involucrados en la organizacin, e ir en Cada etapa traducindolas al lenguaje apropiado. Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. La calidad del software la define o avala una Gestin de la calidad del software por ejemplo: ISO 9000, esto como poltica de calidad, se entiende como un conjunto de actividades de la funcin general de la direccin que determina la calidad, los objetivos, el control de la calidad. Algunos de varios estndares para software provienen de ISO 9000 quien rige la calidad mundial. En seguida se muestra una tabla con los diversos estndares ISO, en captulos posteriores hablaremos de ISO y otros estndares a nivel nacional e internacional.

7

Estndar o EspecificacinISO/IEC 91261 ISO/IEC TR 91264 ISO 924111 Especificaciones ISO 20282 ISO/IEC TR 91262 Especificaciones ISO 9241 ISO/IEC TR 91263 Especificaciones ISO/IEC 107411 ISO 9241 Especificaciones

ENFOCADO A:Ingeniera de Software - Calidad de producto- Modelos de calidad. Ingeniera de software - Calidad de producto- Calidad en mtricas de uso. Guas en Usabilidad. Usabilidad en productos de cada da. interfaz e interaccin Ingeniera de software- Calidad de producto- Mtricas externas. Requisitos ergonmicos para trabajo en oficinas y terminales de trabajo. Ingeniera de software- Calidad de producto- Mtricas internas. Interaccin de Dilogo - Control del cursor en edicin de textos. Requisitos ergonmicos para oficinas con terminales visuales. Iconos, smbolos y funciones.

ISO/IEC 11581 ISO 11064 Especificaciones Requisitos ergonmicos de trabajo de paneles planos. ISO 13406 ISO 14915 Especificaciones Interfaz de escritura manual. Interaccin ISO/IEC 14754 IEC TR 61997 Especificaciones Interfaz de usuario para dispositivos mviles. ISO/IEC 18021 ISO 18789 Requisitos ergonmicos y sistemas mtricos para pantallas. Documentacin Guas de interfaz de usuario en equipos multimedia de uso general. Ergonoma de software para interfaz multimedia. Diseo ergonmico para centros de control.

8

Estndar o EspecificacinISO/IEC 18019 Especificaciones ISO/IEC 15910

ENFOCADO A:Guas para el diseo y preparacin de documentacin de software de usuario. Documentacin de procesos de software. de usuario proceso de desarrollo

ISO 13407

Diseo de procesos interactivos. Evaluacin de software.

ISO/IEC 14598 ISO TR 16982 ISO TR 18529 Mtodos de soporte de diseos centrados en usuarios. capacidad de la empresa Procesos descriptivos de vida de producto, otros ISO Introduccin general. ISO 92411 Gua en requisitos de acciones. ISO 92412 Principios ergonmicos de carga mental, trminos y definiciones. iSO 100751 Gua 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 ingeniera del software, ello reduce la cantidad de reelaboracin que se debe realizar adems de los consecuentes beneficios que se pueden obtener como a continuacin se describe. 9

BENEFICIOS PARA LOS CLIENTES

COSTO DE OPORTUNIDAD CONTROLADO

Dependiendo de la importancia de la aplicacin solicitada, no contar con la misma en el momento previsto, puede ocasionar prdidas considerables, tanto econmicas como de imagen.

EFICIENCIA EN LA OPERATORIA DEL DA A DA

Contar con una aplicacin desarrollada bajo estndares de calidad asegurados, garantiza la estabilidad del software, evitando interrupciones en las actividades del negocio por defectos del sistema.

AUMENTO EN LA PRODUCTIVIDAD

Una aplicacin bien diseada y desarrollada, facilita las actividades de trabajo diarias, aumentando la productividad en tareas administrativas, productivas y de control entre otras.

REDUCCIN EN LOS COSTOS OPERATIVOS

La implementacin de software de calidad, evita costos asociados a eventos tales como cadas del sistema, demoras en la atencin a clientes, prdidas de informacin vital del negocio.

10

PARA EL REA DE IT

REDUCCIN 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 produccin, necesidad de ms recursos humanos para poder cumplir con los plazos establecidos para la finalizacin de los proyectos y, quizs el ms grave, prdidas econmicas 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 organizacin.

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 nmero de horas invertidas en cada proyecto, liberando anticipadamente los recursos asignados a un determinado proyecto y dejndolos disponibles para comenzar los prximos.

MEJOR ORGANIZACIN E INTEGRACIN 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 globalizadoEn un contexto dinmico 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 trado aparejado una evolucin del cliente, quien hoy por hoy es mucho ms 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. Trminos como Excelencia, Calidad Total, Mejora Continua, Satisfaccin del Cliente y otros se han convertido en vocabulario habitual de quien forma parte de una organizacin. Diversos autores han definido a la calidad de diferentes maneras, pero la gran mayora coincide en un punto fundamental: Calidad en una organizacin supone el cumplimiento de ciertos requisitos, los cules son determinados en funcin de las necesidades del cliente. Una organizacin que administra un Sistema de Calidad recoge informacin acerca de las necesidades del cliente, la registra y procesa, obteniendo los resultados necesarios que le permiten tomar decisiones concernientes a la modificacin de sus prcticas actuales para adaptar su producto/servicio a lo que verdaderamente requiere el cliente. Estas prcticas son evaluadas mediante la utilizacin de ndices que miden los resultados de la organizacin 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 organizacin 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 concepcin de una Visin, punto de partida para la generacin de la Conciencia de Calidad. Esto plantea el requisito fundamental de contar con el compromiso de quienes toman decisiones dentro de la organizacin. En otras palabras, los esfuerzos para adoptar la Gestin de Calidad Total son intiles si la alta direccin no est comprometida. Con el compromiso gerencial, la organizacin est en condiciones de transferir la Visin de Calidad hacia todos los niveles de la organizacin, definiendo una Misin, polticas, 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 gestin de estas caractersticas en cualquier organizacin. Por esta razn, la Calidad est estrechamente relacionada con el capital humano de una organizacin: no puede haber calidad si no se cuenta con recursos humanos de calidad. En otras palabras, una organizacin 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 organizacin. El talento de los recursos humanos est dado por una serie de factores como la capacitacin, sus valores, el potencial, su sentido de responsabilidad, etc. De esta manera, una organizacin 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 organizacin solo puede considerarse de Calidad cuando est compuesta por personas de Calidad, quienes aplican los valores de trabajar en equipo, actuar con prevencin, planificar bien para ejecutar mejor, aprender y desarrollarse, comunicarse con eficacia, enfocarse a servir a sus clientes y mejorar continuamente. Una organizacin de estas caractersticas adopta una cultura de confianza, lo que la lleva inevitablemente a la capacitacin, al trabajo en equipo y a la auto direccin. En definitiva, Calidad implica la determinacin 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 predisposicin positiva al trabajo y finalmente la vocacin de servicio de todo el capital humano de una organizacin. Por esta razn podemos afirmar que la Conciencia de Calidad dentro de la organizacin es la base para la transformacin de la organizacin en funcin de los requisitos establecidos por el anlisis de las necesidades y demandas del cliente, lo cual se logra mediante el conocimiento (la Visin 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 mtodo de vivir con respecto a las acciones de los seres humanos .

14

La calidad de vida es un concepto que va ms all de lo fsico 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 Fsicamente, significa encontrarse en buenas condiciones, fuerte, resistente a las enfermedades o poder sobreponerse rpidamente a ellas. o Psquicamente, es poder disfrutar, hacerse cargo de las responsabilidades, combatir la tensin nerviosa y el estrs. 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, satisfaccin de la persona que le permite una capacidad de actuacin o de funcionar en un momento dado de la vida. La calidad de vida es: "la percepcin 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 relacin con sus objetivos, sus expectativas, sus normas, sus inquietudes.

15

La calidad de vida tiene su mxima expresin en la calidad de vida relacionada con la salud. Las tres dimensiones que global e integralmente comprenden la calidad de vida son:

Dimensin fsica: Es la percepcin del estado fsico o la salud, entendida como ausencia de enfermedad, los sntomas 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. Dimensin psicolgica: Es la percepcin del individuo de su estado cognitivo y afectivo como el miedo, la ansiedad, la incomunicacin, la prdida de autoestima, la incertidumbre del futuro. Tambin incluye las creencias personales, espirituales y religiosas como el significado de la vida y la actitud ante el sufrimiento. Dimensin social: Es la percepcin del individuo de las relaciones interpersonales y los roles sociales en la vida como la necesidad de apoyo familiar y social, la relacin mdico-paciente y el desempeo laboral.

1.7 Calidad TotalEl trmino TQM (Total Quality Management) se acua en 1985 para describir el estilo japons de incremento de calidad. Representa un estilo de gestin movido por conseguir xito a largo plazo enlazando calidad y satisfaccin de usuario. Es bsica la creacin de una cultura en la que todos los miembros de la organizacin quienes participan en la mejora de procesos, productos y servicios. La adopcin de ISO 9000 como estndar de gestin de calidad en la Unin Europea ilustra la importancia de esta filosofa. Ejemplos implementacin exitosa de una estrategia TQM: 16

Hewlett-Packards Total Quality Control (TQC): Define estrategias y planes para cada rea (gestin liderazgo, cliente, participacin total, etc.) para conducir un incremento de calidad, eficiencia y responsabilidad. Motorolas Six Sigma Strategy. Se centra en conseguir niveles estrictos de calidad para obtener la satisfaccin del usuario. IBMs Market Driven Quality.

Los elementos clave de TQM pueden resumirse en: Orientado al cliente: el objetivo es conseguir una satisfaccin total del cliente. Incluye estudios de las necesidades de los clientes, recoleccin de requisitos de cliente, medida y gestin de su nivel de satisfaccin. 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 travs 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 compaa. reas objetivo son: direccin, participacin total, otorgar poderes a los empleados y otros factores sociales, psicolgicos y humanos.

17

Medida y anlisis: el objetivo es conducir la mejora continua en todos los parmetros de calidad, utilizando el sistema de medidas orientadas al objetivo. Una organizacin que practique TQM debe tener una jefatura ejecutiva, y debe centrarse en infraestructura, entrenamiento y educacin, adems de realizar planificacin estratgica de calidad. Se han definido varios marcos organizacionales para sustanciar la filosofa TQM: Plan-Do-Check-Act. Proceso de mejora de la calidad basado en un ciclo de retroalimentacin para optimizar un nico proceso de produccin. Quality Improvement Paradigm (QIP). Pretende construir una organizacin que mejora continuamente, basndose 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 valoracin 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 prevencin de defectos, innovaciones tecnolgicas y gestin del cambio de procesos. En captulos posteriores se abarcar con mas detalle este modelo. Leas Enterprise Management. Basado en el principio de concentracin de la produccin en actividades de valor aadido.

18

1.8 Preguntas de repaso y prcticas sugeridas.1 Buscar en Internet artculos 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 ms habilidades y en cuales requerirn capacitacin.

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 construccin 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 presentacin indicando los beneficios que se pueden tener al aplicar estos modelos al desarrollo del software. 19

8. Investigar y hacer una presentacin sobre las empresas que han implantado la filosofa 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, garanta 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 pas.

20

2 Aseguramiento de la Calidad del Software (SQA)La funcin de aseguramiento de la calidad tiene como finalidad primaria el determinar si las necesidades de los usuarios estn siendo satisfechas adecuadamente. Otra de sus funciones, aunque no se tocar mucho en la presente investigacin, es la de determinar los costos que puede causar el aadir ciertas caractersticas al producto, ya que tarde o temprano, la economa resulta ser un factor decisivo para obtener un producto de calidad. Para determinar si las necesidades de los usuarios estn siendo satisfechas, se deben de evaluar tres reas: Objetivos: Los objetivos de la organizacin son primero, luego vienen los requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en armona con los objetivos de la organizacin,

Mtodos: Deben de utilizarse mtodos que contengan u observen las polticas, procedimientos y estndares de la organizacin,

Ejecucin: Optimizacin 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 Relacin de la Ingeniera del Software con SQA.El IEEE[IEEE93] define a la ingeniera del software como: La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; es decir la aplicacin de la ingeniera al software. La ingeniera de software es una tecnologa estratificada, como se muestra en la siguiente figura:

HERRAMIENTAS METODOS PROCESO UN ENFOQUE DE CALIDADFig. 1. Estratos de la ingeniera del software

Cualquier enfoque de la ingeniera (incluido el de la ingeniera del software) debe estar sustentado en un compromiso con la calidad. La gestin 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 ingeniera del software. La base que soporta a la ingeniera del software es un enfoque en la calidad. La base de la ingeniera del software es el estrato del proceso. El proceso de la ingeniera del software es el elemento que mantiene juntos los estratos de la tecnologa 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 tecnologa de la ingeniera del software. El proceso del software forma la base para el control de la gestin de los proyectos de software y establece el contexto en el cual se aplican los mtodos tcnicos, 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.

Ms adelante se abordarn

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 prrafo anterior. Los mtodos de la ingeniera del software proporcionan los cmo tcnicos para construir software, Los mtodos abarcan un amplio espectro de tareas que incluyen la comunicacin, el anlisis de requisitos, el modelado del diseo, la construccin del programa, la realizacin de pruebas y el soporte. Los mtodos de la ingeniera del soltare se basan en un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluye actividades de modelado y otras tcnicas descriptivas.

Las herramientas de la ingeniera del software proporcionan el soporte automatizado o semiautomatizado para el proceso y los mtodos. Cuando las herramientas se integran de forma que la informacin 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 ingeniera del software asistida por computadora.

23

2.2 Definicin y propsito del SQA.Antecedentes: El control y la garanta 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 producto. travs empresario que fabricaba un La primera funcin formal de garanta y control de la calidad la

introdujeron los Laboratorios Bell en 1916 y se extendi tan rpidamente a del mundo industrial. Durante el decenio de 1940 surgieron enfoques mas formales del control de la calidad los cuales se apoyaban en la medicin y la mejora continua de los procesos como los elementos clave la gestin de la calidad. La historia de la garanta de la calidad en el desarrollo de software avanza paralela a la de la calidad en la fabricacin de hardware. Durante los primeros das de la computacin (dcadas de 1950 y 1960), la calidad era responsabilidad exclusiva del programador. Los estndares de garanta de calidad para el software se introdujeron en los contratos militares de desarrollo de software durante el decenio de 1970 y se han extendido rpidamente en el desarrollo del software en el mundo de los negocios.

Definicin y propsito: Si se extiende la definicin presentada anteriormente, la garanta de la calidad del software es un patrn de acciones sistemtico y planificado que se requiere para garantizar alta calidad en el software. Numerosos participantes tienen responsabilidad en la garanta 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 Garanta de Calidad del

software SQA (Software Quality Assurance), es una actividad de proteccin

que se aplica a todo el proceso de ingeniera del software, englobando los siguientes aspectos:Enfoque de gestin de calidad. Tecnologa de ingeniera del software efectiva. Revisiones tcnicas formales que se aplican durante el proceso del software. Estrategia de prueba multiescalada. El control de la documentacin del software y de los cambios realizados. Procedimiento que asegure un ajuste a los estndares de desarrollo del software. Mecanismos de medicin y de generacin 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 tcnico, aplicando mtodos slidos 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 garanta de calidad, supervisin, mantenimiento de registros, anlisis e informes. Establecimiento de un plan de SQA para un proyecto. Participacin en el desarrollo de la descripcin del proceso de software del proyecto. Revisin de las actividades de ingeniera del software para verificar su ajuste al proceso de software definido. Auditora 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 mismoCiclo de vida del software: Aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin 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 explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso (norma ISO 12207-1) [ISO/IEC, 1995]. Objetivos Proporcionar una estrategia de desarrollo y un enfoque sistemtico en la realizacin 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 PRINCIPALESAdquisicin Suministro

PROCESOS DE SOPORTEDocumentacin Gestin de la configuracinAseguramiento de la calidad Verificacin Validacin Revisin Conjunta Auditora

Desarrollo

ExplotacinMantenimiento

Resolucin de problemas

PROCESOS DE LA ORGANIZACINGestin Mejora Infraestructura Formacin

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 explotacin o el mantenimiento del software durante su ciclo de vida.

Proceso de adquisicin Proceso de suministro Proceso de desarrollo Proceso de explotacin

Actividades y tareas que se realizan para comprar un producto software. Actividades y tareas que el suministrador realiza. Contiene las actividades de anlisis de requisitos, diseo, codificacin, integracin, pruebas e instalacin y aceptacin. Incluye la explotacin del software y el soporte operativo a los usuarios. Aparece cuando el software necesita modificaciones, ya sea en el cdigo o en la documentacin asociada, debido a un error, una deficiencia, un problema o la necesidad de mejora o adaptacin. Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida. Registra la informacin producida por un proceso o actividad en el ciclo de vida. Aplica ciertos procedimientos y tcnicas durante todo el ciclo de vida del sistema. Aporta la confianza de que los procesos y los productos software del ciclo de vida cumplen los requisitos especificados y se ajustan a los planes establecidos. Determina si los requisitos de un sistema o del software estn completos y son correctos. Sirve para determinar si el sistema o software final cumple con los requisitos previstos para su uso.

Proceso de mantenimiento

Procesos de soporte Proceso de documentacin Proceso de gestin de la configuracin Proceso de aseguramiento de la calidad Proceso de verificacin

Proceso de validacin Proceso de revisin conjunta Proceso de auditora Proceso de resolucin de problemas Sirve para evaluar el estado del software y sus productos en una actividad del ciclo de vida o una fase de un proyecto. Permite determinar, en los hitos predeterminados, si se han cumplido los requisitos, los planes y el contrato. Permite analizar y eliminar los problemas descubiertos durante el desarrollo, explotacin, el mantenimiento u otro proceso.

28

Procesos de soporte: Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida.Proceso de documentacin: Registra la informacin producida por un proceso o actividad en el ciclo de vida. Aplica ciertos procedimientos y tcnicas Proceso de gestin de la configuracin: 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 verificacin software estn completos y son correctos.

Sirve para determinar si el sistema o software Proceso de validacin 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 revisin conjunta una fase de un proyecto. Permite determinar, en los hitos Proceso de auditora predeterminados, si se han cumplido los requisitos, los planes y el contrato Permite analizar y eliminar los problemas descubiertos durante el desarrollo, Proceso de resolucin de problemas explotacin, el mantenimiento u otro proceso.

29

Procesos de la organizacin (generales): Los emplea una organizacin para llevar a cabo funciones tales como la gestin, la formacin del personal o la mejora del proceso.

Actividades y tareas genricas que puede Proceso de Gestin emplear cualquier organizacin que tenga que gestionar sus procesos, incluyendo planificacin, seguimiento y control, y revisin y evaluacin Proceso de infraestructura Establece la infraestructura necesaria para cualquier otro proceso. Sirve Proceso de mejora para establecer, valorar, medir,

controlar y mejorar los procesos del ciclo de vida del software.

Proceso de formacin

Sirve

para

proporcionar

y

mantener

al

personal formado.

De los procesos anteriores existe otro muy importante si se requiere hacer la adaptacin a la norma ISO-12207 que debe ser considerado. Proceso de adaptacin: Sirve para realizar la adaptacin bsica 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 suministro. contrato, empleando los procesos de adquisicin y

30

Bajo el punto de vista de gestin, 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 explotacin, el operador proporciona el servicio de explotacin del software a los usuarios. Bajo el punto de vista de ingeniera, el desarrollador o el personal de mantenimiento llevan a cabo sus respectivas tareas de ingeniera para producir o modificar los productos software Bajo el punto de vista de soporte, los grupos (tales como el de la gestin de la configuracin, el aseguramiento de la calidad...) proporcionan servicios de apoyo a otros grupos en el cumplimiento de tareas nicas y especficas.

2.5 Roles y responsabilidades de los equipos de desarrollo.

Qu es un equipo? Al menos dos personas quienes estn trabajando juntos por una

meta/objetivo/misin comn, donde a cada persona se le ha asignado roles o funciones especficas a desarrollar, y en donde el cumplimiento de la misin requiere algn 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. Adems, 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 captulo se describen los roles que tradicionalmente se consideran en el desarrollo de software. Estos roles son:

Administrador

de

proyecto,

analista,

diseador,

programador,

tster,

asegurador de calidad, documentador, ingeniero de manutencin, ingeniero de validacin y verificacin, administrador de la configuracin y por ltimo, el cliente.

Para cada uno de estos roles, se definen sus objetivos, actividades, interaccin con otros roles, herramientas a utilizar, perfil de las personas en ese rol y un plan de trabajo. Hay que sealar que es posible que no se requieran todos los roles en un desarrollo.

Eso depender del tamao y del tipo del desarrollo. Por ejemplo, el desarrollo de un sistema de informacin de gran tamao requerir ms roles que uno de menor tamao. Por otro lado, si el tipo del proyecto est enfocado ms hacia la parametrizacin e integracin de sistemas, requerir algunos roles en menor medida y otros en mayor.

32

Es posible tambin que una persona realice las labores de ms de un rol al mismo tiempo. Esto, sobre todo en proyectos de desarrollo de software ms pequeos. No obstante, es imprescindible que dichas personas conozcan completamente todas sus tareas. Por otro lado, tambin es posible la situacin de tener ms de una persona con un mismo rol en un equipo de desarrollo. Por ejemplo, en sistemas de complejidad mediana hemos utilizado con xito la frmula de tener un administrador de proyecto, dos analistas, dos diseadores, dos programadores y un tster. Eso hace un total de ocho personas en un grupo. Las actividades de documentacin y administracin de configuracin son asumidas por todos los roles. Parte de las actividades de aseguramiento de calidad son asumidas por el tster. 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 ms actividades no estn asociadas a ningn rol, con lo que el proyecto sufrir. Por otro lado, es posible que una o ms actividades estn asociadas a ms de un rol. Esto ltimo producir problemas entre los miembros afectados, lo que tambin 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 comn que, frente a una oferta de una empresa en busca de personal calificado para su equipo de desarrollo de software, nos sintamos atrados a postular a un rol especfico.

33

La fbula de la granja

Un da cualquiera, los animales de una granja decidieron hacer una fiesta, con el propsito de pasar un momento agradable. Para organizar la fiesta, se reunieron el mismo da en la maana. Cada animal deba llevar algo a la fiesta. Como es lgico, 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 participacin 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 fbula para caracterizar a los miembros del grupo de un desarrollo de software. Cmo se comportan, en general? Participan o estn 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, cmo se obtienen estos miembros comprometidos? Es posible crear miembros del grupo comprometidos? Administrador de proyecto comprometido, analista comprometido, diseador comprometido, programador comprometido, tster comprometido, asegurador de calidad comprometido, documentador comprometido, ingeniero de manutencin comprometido, ingeniero de validacin y verificacin comprometido, administrador de la configuracin comprometido y cliente comprometido? La fbula anterior nos ensea 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 tcnico utilizado por el resto de los miembros. Muchas veces, entender una cosa diferente a la expresada lenguaje. 2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los problemas que se presentan durante el desarrollo. Sera 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 estndares de desarrollo, de documentacin, de aseguramiento de la calidad. 4. Un miembro no capacitado no presupuesta su involucramiento en el proyecto, slo su participacin. Este solo hecho reduce las posibilidades de xito del proyecto. Tambin 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. por sus pares. Esto es comn debido a diferencias en el

35

Aspectos a considerar son : Crear un lenguaje comn entre el equipo de desarrollo, as como hacer que entiendan claramente sus deberes y obligaciones. Por otro lado, los clientes tambin deben estar comprometidos con el desarrollo. Eso significa que deben conocer el ciclo de vida escogido, cual es su participacin 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 anlisis, as como en todas aquellas actividades de revisin y aceptacin. 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 caractersticas deseables de cada uno de ellos. Para ello, se requiere entender correctamente las caractersticas de liderazgo dentro de un grupo humano.

36

2.6 Habilidades y capacidades del personal del SQAEl asegurador de calidad debe ser una persona con mucha experiencia en proyectos de desarrollo de software, con conocimientos suficientes sobre tcnicas 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 desempeo 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 garanta de calidad para el proyecto.

Un grupo se considera como la coleccin 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 tamao de proyecto, la estructura y la cultura de la organizacin. Algunos grupos, como el de aseguramiento de la calidad de software, estn enfocados a actividades de proyectos, y otros como el grupo de ingeniera de procesos de software, estn enfocados a actividades en el mbito de toda la organizacin.

37

Habilidad 2: Se provee de recursos y financiamiento adecuados para la realizacin de las actividades de Aseguramiento de Calidad de Software.

1. Se asigna especficamente 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 clculo y herramientas de auditora.

Habilidad 3: Los miembros del grupo de SQA estn capacitados para realizar las tareas asociadas a esta actividad. Ejemplos de capacitacin incluyen: Practicas y habilidades de ingeniera de software, roles y responsabilidades del grupo de ingeniera de software y otros grupos relacionados, mtodos, estndares y procedimientos para el proyecto de software, dominio de la aplicacin del proyecto de software, mtodos, procedimientos y objetivos de garanta de calidad, involucramiento del grupo SQA en las actividades del proyecto, un uso efectivo de los mtodos y herramientas de garanta de calidad, y comunicacin interpersonal.

Habilidad 4: Los miembros del proyecto reciben orientacin en los roles, responsabilidades, autoridad y valor del grupo de SQA.

38

Relacin con otros roles

A continuacin se analiza la relacin del asegurador de calidad con los otros roles: Administrador de proyecto: El asegurador de calidad revisa el plan de administracin de proyecto, para asegurarse que se crea y que se sigue.

Analista: El asegurador de calidad revisa la especificacin de requisitos de usuario y de software, para asegurarse que es una representacin correcta y completa de las expectativas del cliente, y que es suficientemente clara para todos en el grupo de desarrollo, especialmente para el diseador.

Diseador: El asegurador de calidad revisa la fase de diseo arquitectnico, para asegurarse que el diseador seleccion la metodologa apropiada y que el producto final de esta fase cumple con requisitos de rendimiento, diseo y verificacin.

Programador: El asegurador de calidad revisa la fase de diseo detallado, para asegurarse que el cdigo producido cumple con la especificacin de requisitos establecida y que cumple con los atributos de calidad en uso.

Tster : El asegurador de calidad revisa el plan de testeo, para asegurarse que es creado, que es adecuado para el proyecto especfico, y que se aplica en cada fase del proceso de desarrollo hasta la entrega del producto.

39

Documentador: El asegurador de calidad revisa la documentacin, para asegurarse que corresponde con el software desarrollado, y que cumple con el estndar en uso. Administrador de configuracin: El asegurador de calidad revisa los registros de cambios, errores y de configuracin, para asegurarse de que los cambios han sido implementados apropiadamente, y que las lneas bases son almacenadas y que el producto no se puede perder.

2.7 Actividades del SQA.A continuacin se presentan las actividades y metas a cumplir por los aseguradores de calidad. Actividades MetasAsegurarse que la especificacin de requisitos es una representacin correcta y completa de las expectativas del cliente, y que es suficientemente clara para el equipo de desarrollo, especialmente para los diseadores. Asegurarse que el plan es creado y se cumple.

Revisar los documentos de requisitos de usuario y de software Revisar el plan de administracin del proyecto.

Revisar el plan de testeo Revisar la fase de diseo arquitectnico Revisar la fase de diseo detallado Revisar las polticas de control de cambios, control de errores y control de la configuracin. Revisar la documentacin.

Asegurarse que el plan se crea, que es adecuado al proyecto especfico, y que se sigue en cada fase del ciclo hasta que se entrega el producto. Asegurarse que los diseadores seleccionaron la metodologa apropiada y que el producto final cumple con los requisitos de diseo y verificacin. Asegurarse que el software producido cumple con los requisitos especificados y con los atributos de calidad impuestos. Asegurarse que se realizan monitoreos de errores en cada fase del desarrollo y que se respaldan las lneas bases haciendo que el producto no se pueda perder Asegurarse que la documentacin cumple con el estndar utilizado durante el desarrollo del producto de software.

40

2.8 Mtodos y herramientas.Existen varios mtodos y herramientas que pueden ser aplicados durante el desarrollo de software, pero en este apartado se enfocara ms a las actividades del Asegurador de Calidad. Entre las actividades del Asegurador de Calidad, la ms importante es la de participar en las revisiones tcnicas formales (RTF). Si estas revisiones estn bien conducidas, son la forma ms efectiva de encontrar, revelar y corregir errores mientras an es barato encontrarlos y arreglarlos. El estndar 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 diseo arquitectnico. Esto, debido a que las actividades de diseo 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 diseo. Los objetivos de las RTFs son: Descubrir errores en funciones, lgica e implementacin en cualquiera de las representaciones del software. Verificar que el software bajo revisin cumple con los requisitos. Asegurarse que el software ha sido representado de acuerdo al estndar en uso. Alcanzar software que es desarrollado en forma uniforme. Hacer el proyecto ms manejable.

41

Una RTF es una reunin entre tres a cinco personas. Cada una de ellas ha realizado una preparacin de antemano de no ms de dos horas, y su duracin no debe tampoco sobrepasar las dos horas. La RTF se focaliza en un producto pequeo del software, tal como una porcin de los requisitos, el diseo detallado de un mdulo, o el listado de cdigo fuente de un mdulo. Los participantes de una RTF son el productor (la persona que desarroll el producto a revisar), un encargado de la revisin que evala 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 ms relevantes aparecidos durante la revisin. Al final de la revisin, los participantes deben decidir si: 1. Aceptar el producto sin modificacin 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 revisin posterior.

42

2.9 Enfoque de Procesos en el Desarrollo de softwareEn 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 acrnimos como CMM, CMMI, RUP, ISO, PSP, TSP, etc., que causan confusin, principalmente debido a la mala interpretacin de los mismos. Porqu contar con un proceso de software? Hasta hace poco tiempo, la produccin de software era realizada con un enfoque artstico, 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 aos las organizaciones introdujeron los mtodos de ingeniera de software. A partir de estos, se formaliz el enfoque de ingeniera de producto para desarrollar software. Factores como la globalizacin han obligado a las organizaciones a contar con marcos de trabajo que las ayuden hacer las cosas de la manera ms eficiente. Fue entonces que se incorpor la ingeniera de procesos al desarrollo de software.

43

2.9.1 Definicin de Proceso y Enfoque de procesosAntes de definir lo que es un proceso de desarrollo de software, entendamos lo que es un proceso: Proceso: Una definicin sencilla de proceso es serie de acciones que conducen a un final. Esta definicin parece coincidir con las ideas generales de la gente sobre procesos, pero deja muchas preguntas abiertas: El proceso es la forma en que la organizacin opera desde mercadotecnia hasta recursos humanos o es la forma en que un desarrollador disea, produce cdigo, o prueba el software? El proceso se refiere a administracin, ingeniera, o ambas? El proceso implica demasiada documentacin y nos abstiene de desarrollar el producto objetivo? La respuesta a stas puede variar dependiendo de la perspectiva. Sin embargo, siempre que para alcanzar algn fin deseado necesitemos ejecutar una serie de acciones, estaremos y estas hablando acciones de tengan cierto que orden, pueden dependencias, ser roles y responsables, resultados, tiempos de ejecucin y herramientas de apoyo, procesos, predefinidos personalizados. Proceso de software La meta de la ingeniera de software es construir productos de software, o mejorar los existentes; en ingeniera 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 organizacin, reglas, polticas, actividades y sus procedimientos, componentes de software, metodologas, y herramientas utilizadas o creadas especficamente 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 organizacin a incrementar su productividad al desarrollar software: Permite estandarizar esfuerzos, promover reuso, repeticin y consistencia entre proyectos. Provee la oportunidad de introducir mejores prcticas 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 cmo manejar los cambios y liberaciones a sistemas de software existentes. Define cmo lograr la transicin del software a la operacin, y cmo ejecutar los esfuerzos de operacin y soporte. Se requiere un proceso de software cuya funcionalidad est probada en la

prctica, y personalizado para que cumpla con necesidades especficas.

Fig. 4 Elementos tpicos del proceso de software.

46

2.9.2 Capacidad de proceso de softwareEl rango de resultados esperados que se pueden obtener tras seguir un proceso.

2.9.3 Madurez del proceso de softwareEs el punto hasta el cual un determinado proceso es explcitamente 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 TSPEl 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 slo 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 ingeniera de software. En un escenario ideal, cada ingeniero de software creara un proceso que llene lo mejor posible sus propias necesidades, y al mismo tiempo satisfaga las amplias necesidades del equipo y la organizacin. De modo alternativo, el equipo mismo creara su propio proceso, y al mismo tiempo cubrira las necesidades ms reducidas de los individuos y las necesidades amplias de la organizacin. 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, capacitacin y coordinacin pero ambos se pueden conseguir. Por qu TSP /PSP para desarrolladores de software en Mxico? 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 ms popular es el modelo CMMI. Sin embargo, este modelo es complejo para implementar en empresas pequeas. En Mxico se tiene la Norma Mexicana basada en MoProsoft, pero sta se centra en los procesos de las empresas, ms no en los de las personas. La estrategia para incrementar la madurez de la industria de software en Mxico, debe de contemplar no solamente los procesos de las empresas sino, incluir el mejoramiento del elemento bsico 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 Secretara de Economa 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 Mxico la infraestructura humana que permita la introduccin y expansin acelerada del uso de TSP, para que la industria de desarrollo de software en Mxico alcance un desempeo superior al de su competencia internacional.

Los elementos que se conjuntan y que nos hacen creer en esta oportunidad son los siguientes: La gran mayora de las empresas que desarrollan software en Mxico 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 ms eficaz que el CMMI Nivel 5. Con el uso de TSP/PSP las empresas en Mxico podran tomar ventaja y adelantarse en la incorporacin de estos procesos de calidad en menor tiempo y obteniendo mejores resultados. Mxico 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. Mxico, como pas ha demostrado ser un aliado que permitir continuar con la evolucin de dichos modelos. Visin Con la implementacin de este proyecto Mxico lograr: Posicionarse como el pas con mejor calidad y valor agregado de manera gil, adelantndonos a las capacidades de nuestros competidores. Contar con un mtodo 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 definicin de la primera versin del mtodo de evaluacin

organizacional del uso del TSP.

49

La definicin del mtodo de mejora acelerada a travs del TSP+CMMI. Los estudios de impacto del TSP, para ajustar su uso y prcticas. Desarrollar una infraestructura de instructores y coaches a un costo competitivo que permita acelerar la incorporacin del uso de TSP/PSP en Mxico. Si bien, la Secretara de Economa a travs del Prosoft est fondeando el desarrollo de la certificacin para TSP organizacional en el SEI, sta tendr un reconocimiento mundial. As al mantener el sello del SEI Mxico, ser el primer jugador en este esfuerzo, obteniendo ventajas sobre quienes le sigan. Relacin CMMI-TSP Por lo regular se necesita de 18 a 24 meses para lograr un nivel en CMMI, lo que se traduce en seis aos para alcanzar un nivel 4 y ocho aos para alcanzar un nivel 5. Sin embargo, incorporar TSP/PSP acelera el cumplimiento de las prcticas de CMMI de una forma ms generalizada en la organizacin, 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 implementacin de prcticas organizacionales.

PSP Personal Software Process Personal Software Process (PSP) es un proceso diseado para ayudar a los ingenieros de software a controlar, manejar y mejorar su trabajo. PSP est 50

basado en una motivacin: 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 hbitos de trabajo de los ingenieros determinan en gran manera los resultados del desarrollo de software. Basado en prcticas 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 precisin el desempeo, medir la calidad de productos, y mejorar las tcnicas. PSP puede ser aplicado en: Desarrollo de programas. Definicin de requerimientos. Documentacin. 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 mayora, es desarrollado por equipos, por lo que los ingenieros de software deben primero saber controlar su trabajo, y despus saber trabajar en equipo. TSP le ensea a los ingenieros a construir equipos autodirigidos y desempearse como un miembro efectivo del equipo. Tambin 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, Diseo, Implementacin, Pruebas, Postmortem Establecer medidas estndares para calidad y desempeo Proveer definiciones de roles, y evaluaciones de rol y de equipo Requiere disciplina de proceso Provee gua 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 cmo preparar y motivar a sus equipos y como ayudarlos a sostener un alto desempeo.

Acelerar el mejoramiento del software a realizar, con el comportamiento normal y esperado, el nivel 5 de CMM

Ofrecer una gua de mejoramiento a organizaciones de alta madurez.

Facilitar la enseanza 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 estndares locales aplicables al trabajo de ingeniera de software del equipo, evala 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 Plan 1 Requerimientos 1 Diseo 1 Implementacin 1 Pruebas 1 Postmortem 1 Estrategia 2 Plan 2 Requerimientos 2 Diseo 2 Implementacin 2 Pruebas 2 Postmortem 2 Estrategia 3 Plan 3 Requerimientos 3 Diseo 3 Implementacin 3 Pruebas 3 Postmortem 3 Producto terminado Evaluacin final

Fig.6 Estructura y flujo del TSP

El TSP define las siguientes actividades del marco de trabajo: lanzamiento, diseo de alto nivel, implementacin, integracin y prueba, anlisis de resultados. Al igual que sus contrapartes en el PSP, estas actividades permiten al equipo planear, disear y construir un software de una manera disciplinada al mismo tiempo que miden de modo cuantitativo el proceso y el producto. El anlisis de resultados muestran el escenario para el mejoramiento del proceso.

El TSP utiliza una amplia variedad de escritos, formas y estndares que sirven para guiar a los miembros del equipo en su trabajo. Los escritos (scripts) definen actividades especficas del proceso (por ejemplo lanzamiento, diseo, implementacin, integracin 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 slida para iniciar el proyecto. Se recomienda el siguiente script general [HUM00]:

Revisar los objetivos del proyecto con las de gestin, 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 mnimo en trminos generales. Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave.

Es importante sealar 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 prcticas 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 especfico (Moprosoft, CMM. CMMI, etc.) 4. Discutir en grupo sobre la relacin entre proceso y calidad del producto obtenido.

5. Elaborar un proyecto de software tangible de manera que pueda realizarse primero de forma individual y despus 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 comunicacin con el equipo de Aseguramiento de la Calidad. 7. Realizar un ejercicio de una revisin tcnica formal sobre un producto de software realizado anteriormente, cuidar los aspectos y recomendaciones sealadas en este captulo, 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 despus de desarrollar el producto, intente clasificarlas identificando el tipo de proceso segn 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 Estndares de calidad aplicados al software.

3.1 ISOEn el capitulo I se mencionaron las familias de normas ISO, en este punto se detallar que es el ISO y su aplicacin en la calidad de software. Qu es el ISO 9000 ? En el ao de 1987, la Organizacin Internacional para la Estandarizacin (ISO por sus siglas en ingls) con base en Gnova public la serie de estndares internacionales ISO 9000 para que sirvieran como base para el sistema de administracin de la calidad. Es descendiente del estndar Britnico BS-5750. Desde la publicacin original, los estndares han sido revisados en los aos 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 compaa para asegurar que cumplen con los requisitos del estndar aplicable, y auditan los procesos para asegurar que se implementen los sistemas documentados de forma efectiva. Una vez que se otorga la certificacin, el certificador lleva a cabo auditoras de supervisin una a dos veces por ao para asegurar que el sistema contina siendo implementado y cumple con los requisitos del estndar aplicable. ISO 9000, que junta una propuesta de administracin de calidad total con una metodologa de documentacin para crear un sistema de auditora interno, es

58

tambin el primer intento de crear un estndar internacional de aseguramiento de calidad que cubra todas las industrias y el sector de servicio. El as llamado estndar ISO 9000 est actualmente comprendido por una serie de estndares. Los estndares publicados el 15 de diciembre del 2000 son: ISO 9000:2005 Sistemas de Administracin de la Calidad Fundamentos y Vocabulario ISO 9001:2008 Sistemas de Administracin de la Calidad Requisitos ISO 9004:2000 Sistemas de Administracin de a Calidad Gua para la Mejora del Desempeo 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 especificacin, sin embargo, se nombra en ISO 9001 como una referencia normativa y vocabulario. ISO 9001:2008 son los requisitos actuales para el sistema de administracin de la calidad. Sus requisitos definen el criterio para el sistema de calidad. El papel de este estndar en las series no ha cambiado, pero su contenido y organizacin son revisadas completamente. ISO 9004:2000 describe un sistema de calidad que va ms all de los requisitos bsicos especificados en el ISO 9001. Est previsto como una gua para organizaciones que quieren expandir y mejorar an ms el sistema de calidad despus de implementar el ISO 9001 (ejem. en las fases despus de la certificacin). ISO 9004 no es un requerimiento y no debe ser usado por auditores de terceros para auditoras de registro. as puede ser usada por los auditores para apoyar su interpretacin de los requisitos del ISO 9001, en particular con referencia al

59

Los principios bsicos en que se ha basado la revisin de esta norma son : Organizacin enfocada al cliente: Para obtener la satisfaccin de los mismos e incluso superar sus expectativas. Liderazgo: Para avanzar hacia la excelencia el liderazgo e los equipos directivos es fundamental. Participacin de las personas: Para el proceso de mejora continua es necesario que los conocimientos de todo el personal que integra la organizacin estn a disposicin del mismo. Enfoque e procesos: Se consigue mayor efectividad cuando todas las actividades interrelacionadas se comprenden y gestionan en forma sistemtica a partir de una informacin fiable. Enfoque del sistema hacia la gestin: Por medido de la gestin de los procesos se consigue la mejora y el logro eficiente de los objetivos. Mejora continua: Es el procedimiento segn 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 informacin 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, valdra la pena preguntarse: Porqu los estndares son tan importantes? Muchas compaas requieren que sus proveedores estn certificados bajo el estndar ISO 9000 y debido a esto, las compaas certificadas encuentras que sus oportunidades de mercado se han incrementado. Adems, la conformidad de la compaa con el estndar ISO 9000 asegura que tiene un sistema de aseguramiento de calidad slido. Las compaas certificadas han tenido reducciones dramticas en las quejas de cliente, reducciones significativas en costos de operacin 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 estndar 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 cuando as lo requieras. Beneficios de la Conformidad a ISO 9001 Los siguientes son algunos de los muchos beneficios que las compaas 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 gastos normalmente asociados con la certificacin. Estars en posicin de certificar

61

Incremento en la retroalimentacin 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 raz de los errores Una excelente herramienta de mercadotecnia.

3.1 SPICE

Antecedentes: Debido al incremento del nmero de modelos y estndares aplicados a valorar la mejora del desarrollo de software y su producto, estos mismos propiciaron al inicio de los 90s el sentimiento generalizado de la necesidad de promover un estndar 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 colaboracin Dicho proyecto deba proporcionar el soporte

internacional que deba materializarse en un nuevo estndar para la valoracin del proceso de software. necesario para la elaboracin del nuevo estndar. La realizacin de pruebas de campo sera una labor fundamental de la que deberan extraer los datos oportunos y derivar los anlisis que posibilitaran la mejora del modelo en sus diferentes versiones.

62

El estndar resultante del proyecto deba cumplir ciertos objetivos: Ser lo suficientemente genrico para tener un amplio horizonte de aplicacin, a la par de lo suficientemente especfico como para ser til y manejable. Establecer mecanismos que permitieran migrar desde estndares ya establecidos, contrastantes. Proporcionar un programa de transferencia tecnolgica que permitiera la adopcin del nuevo estndar. De los aos 1993 a 1995 se desarrollaron y realizaron las primeras pruebas de campo, para verano de 1996 se dieron diferentes cambios en la norma para ajustarla a los datos recogidos en las pruebas efectuadas, para octubre de ese mismo ao se realiz en Mxico un encuentro del grupo de trabajo numero 10 (WG10) en el que la comunidad internacional, por primera vez pudo conocer las partes que definen el modelo. Posteriormente se entreg a la secretaria del comit las 9 partes de documento comenzando el periodo de votaciones ( hay que recordar como se vio en el primer captulo cmo es que se realizan estos estndares y los acuerdos a los mismos), la fase de revisin y votacin por parte de los miembros del comit JTC1. En los aos sucesivos a la publicacin del informe tcnico ste se encuentra sujeto a revisiones por el mismo comit. Entre los principales colaboradores del proyecto SPICE se encuentran: SEI Software Engineering Institute USA ,AT&T Bell labs USA, IBM Australia, NTT Japn, Northen Telecom Canad, British Telecom, Fujitsi, Defense Reseach Agency de Gran Bretaa, ITDC Finlandia, Etnoteam Italia, CSELT Italia. as como evitar la aparicin de otros estndares

63

Objetivo de SPICE: Establecer un estndar de evaluacin de procesos de software para: _ Evaluacin de la capacidad de los procesos (nivel de madurez). - Determinacin de la capacidad de los procesos. _ Mejora continua, (mejora de los procesos). _ Como base para el comercio internacional de software Alcance de SPICE: Ejecutar, planificar, gestionar, controlar y mejorar los procesos de: _ Adquisicin _ Suministro _ Desarrollo _ Operacin _ Soporte _ Mantenimiento _ Organizacin Independiente del tipo de organizacin, modelo de ciclo de vida, metodologa de desarrollo y de la tecnologa utilizada

SPICE como modelo Bidimensional El modelo a travs de una aproximacin estructurada, permite valorar los procesos de software, fomentando la autoevaluacin y ofreciendo un mecanismo por lo cual los adquisidores pueden ganar confianza en los resultados de la valoracin, de esta forma los datos obtenidos pueden ser utilizados para los fines de calificacin de los suministradores, permitiendo 64

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

Fig. 7 Arquitectura de SPICE

65

Una de ellas determina los procesos a ser valorados, definiendo el proceso de vida del software. La otra dimensin presenta una escala para evaluar la capacidad. La escala elegida posee cinco niveles caracterizados por un conjunto de nueve atributos de procesos, que a su vez son tasados segn el grado de cumplimiento de los mismos indicando en tantos por cientos, como se muestra en la Fig. 8.

Fig.9 SPICE: Relacin de dimensiones y atributos del proceso.

La primera dimensin denominada dimensin del proceso define un conjunto estndar de procesos para el ciclo de vida completo del software. La dimensin del proceso parte de tres clases bsicas de procesos: Primarios, de Soporte y Organizativos.

66

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

67

Fig.10 Arquitectura de los procesos segn SPICE

Los niveles considerados por el estndar son mostrados en la Fig.10, estos niveles de capacidad por separado, no son suficientes para evitar ambigedades en la cuantificacin de la capacidad de los procesos, por lo que es necesario tener una serie de atributos comunes a todos los procesos. Estos atributos son utilizados como base para la valoracin. Cada uno e ellos est definido desde el punto de vista de las caractersticas que el proceso debera exhibir. Para cada atributo hay una descripcin general y un conjunto de caractersticas especficas, de forma que cada uno es evaluado para cada proceso valorado, desde el punto de vista del grado de realizacin del mismo.

68

Fig.10 Niveles de capacidad y Atributos de Proceso

Los valores son asignados en una escala de cuatro puntos (Fig.11): no alcanzado, parcialmente alcanzado, altamente alcanzado, y totalmente alcanzado. Considerando el valor de cada atributo se podr determinar en qu nivel se encuentra el proceso estudiado. El modelo de evaluacin se basa en el principio de que proceso. la capacidad del

proceso se puede evaluar si se demuestra la consecucin de los atributos del

ISO/IEC 15504 obliga a evaluar empezando desde el Nivel 1 y, en caso de que sean alcanzados ampliamente (L) o completamente (F) los atributos de los procesos asociados a un cierto nivel, permite evaluar un nivel superior.

69

Valores posibles del atributo N No alcanzado P Parcialmente alcanzado L Ampliamente alcanzado F Completamente alcanzado

Grado de alcance 0% -15%

Situacin para determinar el grado de alcance del atributo Indica un poco o nula evidencia de que