CONTENIDO

PG. 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

Introduccin
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 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.

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.

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.

Estndar o Especificacin
ISO/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.

Estndar o Especificacin
ISO/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 globalizado

En 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 Total

El 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 CALIDAD

Fig. 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 mismo

Ciclo 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 PRINCIPALES
Adquisicin Suministro

PROCESOS DE SOPORTE
Documentacin Gestin de la configuracin
Aseguramiento de la calidad Verificacin Validacin Revisin Conjunta Auditora

Desarrollo

Explotacin
Mantenimiento

Resolucin de problemas

PROCESOS DE LA ORGANIZACIN
Gestin 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

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 SQA

El 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 Metas
Asegurarse 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 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 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 procesos

Antes 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 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 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 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 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 ISO
En 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 se ha alcanzado este atributo en el proceso evaluado. Se evidencia una aproximacin sistemtica del alcance del atributo, pero algunas de sus caractersticas no se dan. Hay bastantes evidencias de que se alcanza el atributo, pero la realizacin del proceso diverge en alguna rea. Hay evidencia de que el atributo se alcanza plenamente y de

16% -50%

51% - 85%

86%-100%

manera sistemtica en el proceso evaluado y no hay debilidades importantes en la unidad organizacional en la que se ubica el proceso.

Fig. 11Escala de valoracin de los atributos de los procesos segn ISO/IEC 15504

Esta aproximacin no solo permite conocer el nivel en que se encuentra el proceso, sino que es una gua que permite su mejora al conocer el valor que deben tener los atributos para conseguir un nivel superior de excelencia, segn la escala propuesta. La dimensin de la capacidad no solo sirve para cuantificar la capacidad de la organizacin sino tambin es una gua para su optimizacin. A continuacin se muestran los niveles, con los atributos de los procesos asociados y grado de cumplimiento

70

Nivel de Capacidad 0 1

Atributos de los procesos (PA) No hay atributos en este nivel Realizacin del proceso (PA.1.1) Gestin de la realizacin

Descripcin

Representa la medida de cundo se alcanza el propsito de un proceso, transformando los productos de entrada en productos de salida. Representa el grado de gestin de la realizacin del proceso, para que se obtengan productos que cumplan los objetivos definidos Representa el grado de gestin de los productos resultantes producidos por los procesos Representa el nivel de realizacin del proceso, segn el cual utiliza una definicin de proceso basada en un proceso estndar para conseguir sus objetivos Representa estndar Representa el nivel en el que las medidas y los objetivos de los productos y de los procesos son el nivel de adecuacin de la implementacin o despliegue efectivo del proceso

(PA.2.1) Gestin de productos resultantes (PA.2.2) Definicin de los procesos (PA.3.1)

3 Aplicacin del proceso (PA.3.2)

Medida del proceso (PA.4.1)

utilizados para asegurar que la realizacin del proceso soporte el alcance de los objetivos definidos como apoyo en los objetivos de negocio. Representa el nivel de control del proceso a travs de la recopilacin, anlisis y uso de medidas de

Control del proceso (PA.4.2)

proceso y de producto, para corregir, en caso necesario, su rendimiento y para conseguir los objetivos de proceso y de producto definidos. Representa el nivel de control de los cambios en la

Innovacin de los procesos (PA.5.1) 5

definicin, gestin y realizacin del proceso con el fin de alcanzar los objetivos de negocio fijados en la organizacin. Representa el nivel bajo el cual se identifican e

Optimizacin de los procesos implantan los cambios en los procesos, para (PA.5.2) conseguir una mejora continua en el cumplimiento de los objetivos de negocio de la organizacin. Fig.12 Atributos de los procesos asociados a los niveles de capacidad de ISO/IEC 15504

71

Fig.13 Ejemplo de perfil de evaluacin de proceso.

La Fig. 13 muestra un ejemplo de perfil de evaluacin del proceso en el que son considerados los atributos arriba mencionados. En el mismo puede denotarse en qu nivel de capacidad se encuentran los procesos evaluados, en el proceso de Soporte al cliente no se tiene la suficiente evidencia que para aprobar el atributo de Gestin de productos resultantes (PA2.2), a pesar de haber cubierto el de Gestin de Realizacin del proceso (PA2.1), por lo que su nivel de capacidad queda en 1. De manera similar los procesos de Diseo y Construccin del software, solo cubren parcialmente el grado del atributo al presentarse solo del 16% al 50% de las evidencias, por lo que su nivel de capacidad tambin queda en 1.

72

En la captura de los requisitos a pesar de que se tiene

ampliamente

conseguida la Aplicacin del proceso (PA3.2), la realizacin del mismo difiere en alguna rea, por lo que no puede obtener el nivel 3 y su nivel alcanzado es 2. Por ltimo el proceso de Prueba del software se tiene evidencia que los atributos de Realizacin del proceso (PA 1.1), Gestin de la realizacin(PA.2.1) y Gestin de los productos resultantes (PA.2.2) se alcanzan plenamente y de manera es 2. sistemtica, y que no existen debilidades importantes en la organizacin en la que se ubica dicho proceso, por lo cual su nivel de capacidad

3.3 CMM (Capability Maturity Model)

El modelo Capability Maturity Model(CMM ), tambin denominado CMM-SW. Fue desarrollado por el SEI (Software Engineering Institute), como marco de referencia para la evaluacin y mejora de procesos de software. Con el fin de proporcionar al gobierno de los Estados Unidos un mtodo para evaluar la capacidad de sus proveedores de software, en noviembre de 1986, el SEI junto con el Centro de Investigacin Gubernamental Mitre, comenzaron a desarrollar un nuevo marco de mejora de procesos de software. En septiembre de 1987, publicaron el primer resultado en forma de una breve descripcin del proceso de madurez as como un cuestionario para detectar los puntos dbiles de la empresa evaluada. Despus de unos cuantos aos de aplicacin del primer modelo y refinamiento del mismo a partir de los resultados que se iban obteniendo en su aplicacin en diferentes empresas, el SEI desarroll y public la primera versin de CMM en 1991. Esta primera versin fue revisada y 73

utilizada por la comunidad de software durante 1991 y 1992, en abril de ese ao surgi la primera versin definitiva, CMM Versin 1.0. CMM contiene los elementos esenciales para conseguir procesos eficaces en uno o ms cuerpos de conocimiento, estando estos elementos basados en los conceptos desarrollados por Crosby, Deming, Juran y Humphey. En el ao 2000 el CMM fue actualizado hacia el modelo CMMI (Capability Maturity Model Integration). En junio del 2009 tuvo lugar en Len (Espaa la presentacin mundial de la traduccin al castellano del Modelo de Mejora de Procesos CMMI para Desarrollo de Software. La traduccin ha sido desarrollada por la Ctedra de Mejora de Procesos de Software en el Espacio Iberoamericano, dirigida por Gonzalo Cuevas. Espaa es el segundo pas de Europa (con 105 evaluaciones CMMI, por detrs de Francia que tiene 141) y el noveno a nivel mundial en nmero de empresas evaluadas sobre el Modelo para el Desarrollo (CMMIDEV), pero slo estaba disponible en ingls, francs, chino y japons, lo que se traduca en que muchas compaas, sobre todo las de menor tamao, tuvieran dificultades para acceder al mismo.

3.3.1 Definicin del modelo

El modelo de madurez gua a las organizaciones indicando cmo mejorar los procesos asociados al desarrollo y mantenimiento del software. La filosofa general que rige a este modelo se fundamenta en diferentes niveles de madurez entendidas como sucesivas etapas cuyo objetivo es la obtencin de un proceso de software optimizado, en cada nivel, adems de establecer una escala de medida de la capacidad de los procesos, se fijan unos objetivos que 74

ayudan a la organizacin a priorizar los esfuerzos dedicados a la mejora de estos procesos. Es importante indicar que el modelo de madurez, se fundamenta en la secuencia de los niveles propuestos. No es aconsejable ni tcnicamente adecuado el pretender un nivel superior sin haber alcanzado el intermedio. Los niveles de madurez pueden asemejarse a los estratos telricos, uno sucede al otro, lo apoya y sustenta. Es fcil entender que no es posible el proceder a una mejora continua con la aplicacin de nuevas tecnologas como sera el caso del nivel 5, sin haber establecido un control cuantitativo de los procesos de software, o haber establecido estndares adecuados para, por ejemplo, la recopilacin o manipulacin de datos en la que asentar la cuantificacin de los procesos productivos. El modelo de madurez propuesto por el SEI se basa en mejoras continuas y progresivas, no en saltos cualitativos ni en revoluciones tecnolgicas de inesperadas consecuencias. La exigencia de la calidad no es slo para los productos materiales, tambin lo es para los servicios. La Fig. 14 nos muestra los 5 niveles de madurez del proceso, cada nivel de madurez se interpreta como la capacidad de los procesos de ingeniera de software y de administracin de proyectos usados en una organizacin de desarrollo de software. A su vez cada nivel de madurez con excepcin del nivel Inicial tiene una estructura interna como es mostrada en la Fig. 15.

75

Fig.14 Niveles de madurez de CMM.

Fig. 15 Estructura de los niveles de madurez de CMM

Con excepcin del Nivel 1, cada uno de estos Niveles de Madurez est compuesto por un cierto nmero de Areas Claves de Proceso, conocidas a travs de la documentacin del CMM por su sigla inglesa: KPA. Cada KPA 76

identifica una agrupacin de actividades y prcticas relacionadas, las cuales cuando son realizadas en forma colectiva permiten lograr alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestin, Organizacional e Ingeniera. Las prcticas que deben ser realizadas por cada rea Clave de Proceso estn organizadas en cinco caractersticas comunes (se describen mas adelante), las cuales constituyen atributos que indican si la implementacin y la institucionalizacin de un proceso clave es efectivo, repetible y duradero. Metas: Representan el propsito, alcance y lmites de cada rea clave de Proceso. Pueden ser usadas para determinar si una organizacin o proyecto ha implementado efectivamente la KPA. Aspectos Comunes: Son atributos que indican si la implementacin e institucionalizacin de un rea clave de proceso es efectiva, repetible y duradera. Las prcticas clave se dividen en cinco secciones de aspectos comunes: Compromiso para Ejecutar Habilidad para Ejecutar Actividades Realizadas Medicin y Anlisis Verificacin de Implementacin Prcticas Clave: Cada rea clave de proceso est descrita en trminos de prcticas clave que, cuando son implementadas, ayudan a satisfacer las metas de esa rea clave. Describen la infraestructura y actividades que mejor contribuyen implementacin e institucionalizacin del rea clave de proceso 77 a la

La clasificacin de las KPAs se determinan de acuerdo al nivel de Madurez que se va alcanzando dentro del modelo CMM,cada KPA busca alcanzar ciertas metas, cuando se alcanzan todos los KPAs de un Nivel se alcanza ese nivel.

NIVEL 5 KPA1. Administracin de Cambios al Proceso KPA2. Administracin de Cambios de Tecnologa KPA3. Prevencin de defectos NIVEL 4 KPA1. Administracin de la Calidad del Software KPA2. Administracin Cuantitativa del Proceso NIVEL 3 KPA1. Enfoque al Proceso Estndar de Software KPA2. Definicin del Proceso Estndar de Software KPA3. Programa de Capacitacin KPA4. Administracin Integrada del Software KPA5. Ingeniera de productos de Software KPA6. Coordinacin entre grupos de trabajo KPA7. Definicin y enfoque del Proceso Organizacional NIVEL 2 KPA1. Administracin de los requerimientos KPA2. Planeacin del Proyecto (plan de trabajo) KPA3. Seguimiento y supervisin del plan de Trabajo KPA4. Aseguramiento de Calidad del Software en los proyectos KPA5. Administracin de la Configuracin KPA6. Administracin de subcontratistas Fig. 15 reas Clave de proceso por nivel de madurez en CMM

78

3.3.2 Nivel inicial.

El nivel 1 o inicial es el estado primario en la evolucin de las organizaciones que desarrollan software. Una definicin amplia es que en este nivel se encuentran todas las empresas que no han logrado implementar las prcticas bsicas de gestin de proyectos e ingeniera de software definidas a partir del nivel 2 o superiores. Una empresa est en el nivel catico cuando sus gerentes y personal afirmen que los proyectos no se pueden planear, que los requerimientos no se pueden tener bajo control, que no est siempre en condiciones de controlar las versiones de producto, donde la calidad sea percibida como una burocracia innecesaria, cuando se acepte que los procesos son una cosa personal, cuando no se pueda verificar ni validar el producto, y sobre todo, cuando sus gerentes y personal vivan bajo condiciones de stress y frustracin permanentes. Herosmo, caos y emergencia permanente En este tipo de empresas, el software es virtualmente producto del arte ms que de la ingeniera. Cada "artista" crea su propio proceso personal, el cual es parte de su sello personal. La gerencia ocupa una parte significativa de su tiempo en paliar problemas y enfrentar clientes insatisfechos. Ante una situacin de crisis permanente, se les hace difcil destinar recursos para definir o documentar procesos, lo que lleva a un crculo sin salida. Cuando el proyecto se termina, la inversin hecha en desarrollar el proceso es raramente reutilizada en nuevos proyectos. Los desarrolladores de software generalmente tienen que trabajar largas horas y paliar problemas en forma cotidiana, lo cual les disminuye su creatividad y productividad netas. El xito 79

descansa en los hombros de estos hroes, tal como en una pelcula de accin americana. Su nivel de frustracin es elevado y es muy frecuente que, como cualquier "diva", decidan explorar caminos en otras empresas con menor nivel de stress. El proceso, que no est documentado ni a sido compartido, se va con ellos, dentro de sus cerebros. Los reemplazantes heredan problemas y dificultades, pero son raramente capaces de recuperar los procesos de desarrollo. Esto obliga a reinventar la rueda, a un alto costo y retrasando los proyectos. He conocido un par de empresas que han llegado a la conclusin que es demasiado caro o difcil tratar de adivinar lo que el empleado anterior hizo, que les sale ms a cuenta echar a la basura el desarrollo anterior y empezar todo de nuevo. En casos extremos hay que simplemente terminar el producto para no seguir perdiendo dinero o prestigio frente a los clientes. Futuro probable En los orgenes de la industria de software el caos predomin y las empresas que sobrevivieron la seleccin natural llegaron al mercado de nuestros das. La mayora se extingui en la gloria del triunfo efmero. Muchos de los actores actuales estn predestinados a desaparecer en un futuro prximo. A pesar del talento de su personal y el despliegue de tecnologa que puedan sustentar, derrochan su xito debido a la debilidad de sus procesos de desarrollo.

80

3.3.3 Nivel repetido.

El nivel 2 o Repetible hace posible la implementacin de prcticas mnimas de administracin de proyecto, de control de requerimientos, versiones de producto y de proyectos realizados por subcontratistas. El grupo o equipo humano que realiz el proyecto puede aprovechar su experiencia e inversin en procesos para aplicarla en un nuevo proyecto. Este nivel no garantiza que todos los proyectos dentro de la empresa estn necesariamente al mismo nivel de madurez. Algunos pueden estar todava en el nivel inicial. He visto algunos casos en la prctica y en todos ellos estos proyectos fueron ineficientes con respecto a los de mayor madurez, malgastando el xito de estos ltimos. Eventualmente algunos invirtieron los esfuerzos necesarios para ponerse a tono, otros simplemente fueron cerrados con un elevado costo de frustracin y descalabro de carreras profesionales. Beneficios de implantar el Nivel 2 del CMM El mayor beneficio obtenido de la implementacin del nivel 2 por la empresa en la cual me desempeo actualmente, es la planificacin realista de los proyectos. Antes los cronogramas de proyecto expresaban ms los deseos de la gerencia que la realidad. Este principio (el mismo en la cual se basa la magia) conduca una situacin de buscar culpables y generar excusas, produciendo al mismo tiempo frustracin y desconfianza entre clientes y empleados. Actualmente los cronogramas son cada da ms confiables, y mejora a medida que se acumula ms informacin en las bases de datos de los proyectos pasados. El uso generalizado de mtodos de estimacin permite al personal del proyecto de justificar plazos y recursos. An el "olfato profesional" y la experiencia personal juegan un papel importante en la generacin de planes de 81

proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas como en el pasado. Descripcin de las reas Clave de proceso para Nivel 2 CMM
NIVEL 2 REPETIBLE KPA1. Administracin de los requerimientos KPA2. Planeacin del Proyecto (plan de trabajo) KPA3. Seguimiento y supervisin del plan de Trabajo KPA4. Aseguramiento de Calidad del Software en los proyectos KPA5. Administracin de la Configuracin KPA6. Administracin de subcontratistas

Gestin de Requerimientos Propsito: Establecer una comprensin comn entre el cliente y el proyecto, de los requerimientos del cliente que debe satisfacer el proyecto. Meta 1: Los requerimientos del sistema asignados al software son controlados para establecer un "baseline" para uso de la ingeniera de software y la gestin. Meta 2: Los planes, productos y actividades de software deben mantenerse consistentes con los requerimientos del sistema asignados al software. Planeamiento de Proyectos de Software Propsito: Establecer planes razonables para ejecutar la Ingeniera de Software y para administrar el proyecto de Software. Meta 1: Las estimaciones de software estn documentadas para usar en el planeamiento y seguimiento del proyecto de software. Meta 2: Las actividades y compromisos del proyecto de software estn planeadas y documentadas.

82

Meta 3: Los individuos y grupos afectados acuerdan sus compromisos vinculados con el proyecto de software. Seguimiento y Supervisin de Proyectos Propsito: Establecer una adecuada visibilidad del progreso real para que la gerencia pueda tomar medidas efectivas cuando se producen desvos significativos del desempeo con respecto a los planes de software. Meta 1: Los resultados y desempeos se siguen contra los planes de software. Meta 2: Las acciones correctivas son tomadas y administradas cuando los resultados reales y el desempeo se desvan significativamente de los planes de software. Meta 3: Los cambios en los compromisos de software son acordados por los individuos y grupos afectados. Gestin de Subcontratacin de Software Propsito: Seleccionar subcontratistas de Software calificados y administrarlos efectivamente. Meta 1: calificados. Meta 2: El principal contratista y el subcontratista de software acuerdan sus compromisos mutuos. Meta 3: El principal contratista y el subcontratista de software mantienen una comunicacin regular. Meta 4: El contratista principal sigue los resultados y desempeo del subcontratista de software contra sus compromisos. Aseguramiento de Calidad de software El principal contratista selecciona subcontratistas de software

83

Propsito: Proporcionar a la gerencia la visibilidad apropiada del proceso usado en el proyecto y de los productos en construccin. Meta 1: Se planean la actividades de SQA. Meta 2: La adhesin de los productos y actividades de software a los estndares, procedimientos y requerimientos aplicables se verifica objetivamente. Meta 3: Los grupos e individuos afectados son informados de las actividades y resultados de SQA. Meta 4: Los incumplimientos que no pueden resolverse dentro del proyecto de software son encarados por la alta gerencia. Gestin de Configuracin de Software Propsito: Establecer y mantener la integridad de los productos de Software del proyecto a lo largo del ciclo de vida. Meta 1: Se planean las actividades de Gestin de configuracin de software. Meta 2: Los Productos de trabajo de software seleccionados son identificados, controlados y estn disponibles. Meta 3: Se controlan los cambios a productos de trabajo de software identificados. Meta 4: Los grupos e individuos afectados son informados del estado y contenidos de la "baseline" de los productos de software.

84

3.4 Nivel definido. La empresa ha definido un conjunto de procesos, metodologas y herramientas comunes a todos los proyectos iniciados por la corporacin. El proceso comn est suficientemente documentado en una biblioteca accesible a todos los desarrolladores. Todo el personal ha recibido el entrenamiento necesario para entender el proceso estndar. Existen pautas y criterios definidos para adaptar dicho proceso a las necesidades y caractersticas propias de cada proyecto. El nivel de definicin es detallado y completo. La dependencia (o el riesgo de depender) en individuos irreemplazables es baja. Beneficios de implantar el Nivel 3 del CMM La base de datos que rene estadsticas de los proyectos pasados y en curso, permite planificar y comparar el rendimiento. Existen mecanismos de comunicacin entre proyectos y departamentos, lo que garantiza una visin comn del producto y una rpida accin para enfrentar los problemas. He conocido unas pocas empresas a este nivel y la cosa que ms me resalt fue la satisfaccin del personal. En empresas de nivel 1 habitualmente se escuchan quejas y acusaciones. A nivel 3 los empleados tienen una alta valoracin de los procesos y entienden claramente la manera en que afectan su desempeo habitual. Los gerentes pueden realizar su verdadera funcin, administrar. El hecho de realizar revisiones tempranas en forma regular mejora

visiblemente la calidad de los productos y minimiza las reiteraciones. Descripcin de las reas Clave de proceso para Nivel 3 CMM
NIVEL 3 DEFINIDO

85

KPA1. Enfoque al Proceso de la Organizacin KPA2. Definicin del Proceso de software de la Organizacin KPA3. Programa de Capacitacin KPA4. Administracin Integrada del Software KPA5. Ingeniera de productos de Software KPA6. Coordinacin intergrupal KPA7. Revisiones por pares

Enfoque en el Proceso de la Organizacin Propsito: Establecer la responsabilidad organizacional para las actividades del proceso de Software que mejoran la capacidad global del proceso de software. Meta 1: El proceso de desarrollo de software y las actividades de mejora son coordinadas a lo largo de la organizacin. Meta 2: Las fortalezas y debilidades del proceso de software utilizado estn identificadas en relacin al proceso estndar. Meta 3: Las actividades de desarrollo y mejora del proceso se planifican a nivel de la organizacin. Definicin del Proceso de la Organizacin Propsito: Desarrollar y mantener un conjunto de recursos del proceso que mejoran el desempeo de los proyectos y proveen una base para obtener beneficios a largo plazo. Meta 1: Un proceso estndar software para la organizacin est desarrollado y es mantenido. Meta 2: La informacin relativa al uso por los proyectos de software del proceso estndar de software de la organizacin, se rene, revisa y est disponible

86

Programa de Entrenamiento Propsito: Desarrollar las habilidades y el conocimiento de los individuos, para que ejecuten sus roles con efectividad y eficiencia [capacitacin]. Meta 1: Las actividades de entrenamiento se planean. Meta 2: Se provee entrenamiento para el desarrollo de las habilidades y conocimientos necesarios para desempear los roles gerencial y tcnico. Gestin Integrada de Software Propsito: Integrar las actividades de Ingeniera de Software y de Gestin en un proceso de Software coherente y definido, que es adaptado desde el proceso de software estndar de la organizacin y las evaluaciones de proceso relacionadas. Meta 1: El proceso de software definido para el proyecto es una versin adaptada del proceso estndar de software de la organizacin. Meta 2: El proyecto es planeado y administrado de acuerdo con el proceso de software definido para el proyecto Ingeniera de Producto de Software Propsito: Ejecutar consistentemente un proceso de ingeniera bien definido que integre todas las actividades de Ingeniera de Software para producir efectiva y eficientemente productos de Software correctos y consistentes. Meta 1: Las tareas de ingeniera de software estn definidas, integradas y son consistentemente ejecutadas para producir el software. Meta 2: Los productos del trabajo de software se mantienen consistentes entre s.

87

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

88

3.3.5 Nivel administrado.

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

NIVEL 4 GESTIONADO (ADMINISTRADO) KPA1. Administracin de la Calidad del Software KPA2. Administracin Cuantitativa del Proceso

Administracin de la Calidad del Software Propsito: Desarrollar una comprensin cuantitativa de la calidad de los productos de software y alcanzar objetivos especficos de calidad. Meta 1: Se planean las actividades de gestin de calidad del proyecto de software. Meta 2: Estn definidas metas medibles para la calidad del producto de software y sus prioridades. Meta 3: El progreso real para alcanzar las metas de calidad de los productos de software est cuantificado y administrado. Administracin cuantitativa del proceso Propsito: Controlar cuantitativamente la performance del proceso del proyecto de software. Meta 1: Se planean las actividades de gestin cuantitativa el proceso. Meta 2: El desempeo del proceso de software definido para el proyecto se controla cuantitativamente. Meta 3: La capacidad del proceso estndar de software de la organizacin es conocido en trminos cuantitativos.

90

3.3.6 Nivel optimizado.

En el Nivel Optimizado, la caracterstica principal es el mejoramiento continuo del proceso, en base a la realimentacin cuantitativa y al ensayo de ideas y tecnologas innovadoras. Beneficios de implantar el Nivel 5 del CMM La organizacin entera se aboca al mejoramiento continuo del proceso. La corporacin cuenta con los medios para identificar las debilidades y reforzar en forma proactiva el proceso, con objeto de prevenir la ocurrencia de defectos. Los datos relativos a la eficacia del proceso de software se usan para analizar el costo y el beneficio de usar nuevas tecnologas y de implementar cambios al proceso de software. Los proyectos de software analizan los defectos para determinar sus causas. Los proceso de software se evalan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos. Descripcin de las reas Clave de proceso para Nivel 5 CMM
NIVEL 5 OPTIMIZADO KPA1. Administracin de Cambios al Proceso KPA2. Administracin de Cambios de Tecnologa KPA3. Prevencin de defectos

91

Administracin de Cambios al Proceso Propsito: Mejorar continuamente el proceso para incrementar: Calidad del Software, Productividad, Disminuir tiempo de desarrollo de productos. Meta 1: Se planea la mejora continua del proceso de cambio. Meta 2: Toda la organizacin participa en las actividades de mejora del proceso. Meta 3: El proceso estndar de la organizacin y el proceso de software definido para el proyecto, se mejoran continuamente. Administracin de cambios de Tecnologa Propsito: Identificar las nuevas tecnologas beneficiosas (herramientas, mtodos, procesos) y transferirlos a la organizacin. Meta 1: La incorporacin de cambios en la tecnologa se planea. Meta 2: Las nuevas tecnologas son evaluadas para determinar su efecto sobre la calidad y productividad. Meta 3: Las nuevas tecnologas se transfieren a la prctica normal a los largo de la organizacin. Prevencin de Defectos Propsito: Identificar la causa de los defectos y prevenirlos. Meta 1: Prevencin de defectos. Meta 2: Causas comunes de defectos son pesquisadas e identificadas. Meta 3: Causas comunes de defectos son priorizadas y sistemticamente eliminadas.

92

Comparacin de CMM con ISO y SPICE Una vez presentados los modelos ISO, SPICE y CMM es conveniente hacer una comparativa de los mismos considerando varios aspectos: CMM ISO Aspecto: nfasis La principal diferencia entre los modelos ISO CMM es que CMM hace hincapi en la mejora continua del proceso. Otra diferencia reside en que CMM focaliza estrictamente en Software, mientras que ISO 9001 tiene un alcance mucho ms amplio, que comprende software, hardware, materiales procesados y servicios. Aspecto: Nivel de Detalle La principal diferencia entre los modelos ISO CMM es el nivel de detalle que difiere significativamente, la seccin 4 en ISO 9000tiene alrededor de 12 pginas de largo, contra ms de 500 pginas de CMM. El alto nivel de abstraccin de ISO puede causar que los auditores interpreten el estndar de maneras diferentes. Aspecto: Auditores Los auditores son entrenados en los estndares de la Serie ISO 9000, pero no son entrenados en conocimiento sobre aspectos especficos de software. Para auditorias especficas de software debera integrarse al equipo personas con conocimientos en la disciplina.

93

Otra razn de discrepancia es que un Auditor puede no requerir maestra para satisfacer la correspondencia con la clusula de ISO 9001. Comparacin CMM -SPICE Aspecto: Evolucin del Proceso SPICE Los niveles de capacidad son aplicados sobre los procesos. Agrega el nivel 0: un nivel puede no ser ejecutado para nada. Ventaja: Mayor granularidad en la medicin y anlisis. Desventaja: Procesos menos importantes pueden ocultar aspectos que no se definieron como prioritarios. CMM Los niveles de madurez organizacional pueden definirse como un conjunto de perfiles para los procesos de SPICE. Las KPA pertenecen a un nico nivel de madurez. Los procesos que no estn descriptos en CMM, tambin existen y evolucionan. Ventaja: Focaliza en pocas reas vitales que comnmente bloquean la performance del proceso. Desventaja: La gente puede perder el seguimiento de los procesos que no estn focalizados en algn nivel particular, pero que an as deben realizarse.

94

Aspecto: Determinacin de Prioridades de Mejoramiento SPICE No prescribe ningn camino particular de mejora. Las prioridades son dejadas completamente a la organizacin. Los procesos individuales pueden ser mejorados continuamente. Los niveles de capacidad miden un proceso especfico .Desventaja: Puede ser difcil decidir que aspectos atacar primero. CMM Construye la capacidad del proceso focalizando en pocos aspectos vitales para la organizacin en su totalidad. Los niveles de madurez priorizan los problemas de software generales. Desventaja: prescriba atacar aspectos de gestin de proyecto antes que los de ingeniera.

Ejemplo de Aplicacin sobre un rea Clave de Proceso del Nivel 2: Planificacin de Proyectos de Software El ejemplo siguiente tiene como propsito detallar mas claramente como son especificados cada una de las prcticas para cumplir con una rea clave de proceso (KPA), que en este caso es la Planificacin de Proyectos de Software para un nivel 2 (Repetido) de CMM. Vale la pena hacer nfasis que se han agrupado las principales caractersticas para una mejor comprensin, los estudiantes pueden realizar como ejercicio propuesto investigar para otras KPAS o un buen ejercicio es checar si estas prcticas son llevadas a cabo en algn desarrollo de un proyecto de software.

95

AREA CLAVE 2.2 Planificacin de Proyectos de Software

Propsito: Establecer planes razonables para ejecutar la Ingeniera de Software y para administrar el proyecto de Software. Estos planes son la base de la gestin del proyecto, 2.3.(siguiente KPA) _____________________________________________________________ Meta 1: Las estimaciones de software estn documentadas para usar en el planeamiento y seguimiento del proyecto el software. Meta 2: Las actividades y compromisos del proyecto de software estn planeadas y documentadas. Meta 3: Los individuos y grupos afectados acuerdan sus compromisos vinculados con el proyecto de software. ______________________________________________________ Compromiso para la ejecucin 1. Un gerente de proyectos de software es designado responsable de negociar los compromisos y desarrollar el plan del proyecto de desarrollo de software. 2. Para el planeamiento de un proyecto de software (PSw), el proyecto sigue una poltica organizacional escrita Compromiso 1 Esta poltica comnmente establece que: 1. Los requerimientos del sistema asignados al software son usados como base para la planificacin del proyecto de software. 2. Los compromisos del proyecto de software son negociados entre: El gerente de proyecto, el gerente de proyecto de software, y otros administradores. 3. La intervencin de otros grupos en las actividades de software es negociada con estos grupos y documentada. Ejemplos de otros grupos de ingeniera incluyen: Ingeniera de Sistemas, Ingeniera de Hardware, Prueba de Sistema. 96

4. Los grupos afectados revisan el proyecto de software: Estimacin de tamao del software, Estimacin del esfuerzo y el costo, programas, y otros compromisos. Ejemplos de otros grupos afectados: Ingeniera de software (incluyendo todos los subgrupos tales como diseo de software), Estimacin de software, Ingeniera de sistema, Prueba de sistema, Aseguramiento de la calidad del software, Gestin de Configuracin de Software , Gestin de contratos y, Soporte de documentacin. 5. La gerencia revisa todos los compromisos del proyecto de software hechos a individuos y grupos externos de la organizacin. 6. El plan de desarrollo de software del proyecto es gestionado y controlado. _____________________________________________________________ Habilidad para ejecutar 1. Existe una orden de trabajo documentada y aprobada para el PSw. 2. Se asignan responsabilidades para el desarrollo del plan de desarrollo de software. 3. Se proveen adecuados recursos y fondos para el planeamiento del PSw. 4. Los gerentes de software, los ingenieros de software y otrosindividuos involucrados en el planeamiento del PSw estn entrenados en los procedimientos de estimacin y planeamiento aplicables a su rea de responsabilidad. Hab 1. Existe una orden de trabajo documentada y aprobada para el PSw. 1. La Orden de Trabajo abarca: alcance del trabajo, objetivos y metas tcnicas, identificacin de clientes y usuarios finales, estndares impuestos

97

responsabilidades

asignadas,

restricciones

objetivos

de

costos

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

Actividades ejecutadas

98

1. El grupo de Ingeniera de Software participa en el equipo que propone el proyecto. 2. El planeamiento del proyecto de software se inicia en las etapas iniciales y en paralelo con el planeamiento global del proyecto. 3. A lo largo de la vida del proyecto el grupo de Ingeniera de Software participa junto con otros grupos afectados, en el planeamiento global del proyecto. 4. Los compromisos del proyecto de software hechos por individuos y grupos ajenos a la organizacin son revisados con la gerencia senior de acuerdo a un procedimiento documentado. 5. Est identificado o definido un ciclo de vida con etapas predefinidas de tamao manejables. 6. El plan del proyecto de desarrollo de software se desarrolla de acuerdo a un procedimiento documentado. 7. El plan para el proyecto de software est documentado. 8. Lo productos del trabajo de software que se necesitan establecer y mantener estn identificados. 9. Las estimaciones del tamao de los productos del trabajo de software (o cambios de ese tamao) son derivadas de acuerdo a un procedimiento documentado. 10. 11. 12. 13. Las estimaciones del esfuerzo y costo del proyecto de software son Las estimaciones de los recursos crticos de computadoras son derivadas El cronograma del proyecto de software se deriva de acuerdo a un Los riesgos de software asociados con costos, recursos, cronogramas y tcnicos del proyecto estn identificados, establecidos y derivadas de acuerdo a un procedimiento documentado. de acuerdo a un procedimiento documentado. procedimiento documentado. aspectos 14.

documentados. Se preparan planes para las facilidades y herramientas de soporte a ingeniera de software del proyecto. 99

15.

Se registran los datos del planeamiento del software.

Medicin y anlisis Las mediciones se hacen y se usan para determinar el estado de las actividades de planeamiento de software. Ejemplos de mediciones incluyen: Trabajo completado, esfuerzo gastado, fondos gastados en las Cumplimiento de hitos para las actividades planificadas en el proyecto de software, comparado con el plan. Actividades planificadas en el proyecto de software, comparadas con el plan. _____________________________________________________________ Verificacin de la implementacin 1.Las actividades para planear el proyecto de software son revisadas peridicamente con la gerencia senior. 2.Las actividades para planear el proyecto de software son revisadas peridicamente con el gerente de proyecto y en respuesta a eventos. 3.El grupo de aseguramiento de calidad de software revisa y/o audita las actividades y productos del trabajo para planear el proyecto de software e informa los resultados. Verificacin 1 Las actividades para planear el proyecto de software son revisadas peridicamente con la gerencia senior. 1.Se revisa la performance tcnica, del personal, de costos y de programacin.

100

2.Los

conflictos

aspectos

no

resueltos

en

niveles

ms

bajos

son

direccionados. 3.Los riesgos asociados al Proyecto de Software son direccionados. 4.Los tems son asignados, revisados y rastreados hasta el cierre. 5.Un reporte de resumen de cada reunin se prepara y distribuye a los individuos y grupos afectados. Verificacin 2 Las actividades para planear el proyecto de software son revisadas peridicamente con el gerente de proyecto y en respuesta a eventos. 1.Estn representados los grupos afectados. 2.El estado y los resultados actuales de las actividades de la planificacin del proyecto de software son revisadas con la definicin del trabajo y los requerimientos. 3.Son direccionadas las dependencias entre grupos.. 4.Son direccionados los conflictos y aspectos no resueltos en los nivele ms bajos. 5.Son revisados los riesgos del proyecto. 6.Los tems de accin son asignados, revisados y rastreados hasta su cierre. 7.Un reporte de resumen de cada reunin se prepara y distribuye a los individuos y grupos afectados. Verificacin 3 El grupo de aseguramiento de calidad del software revisa y/o audita las actividades y productos del trabajo para planear el proyecto de software e informa los resultados. Como mnimo, los revisores y/o auditores verifican: 1. Las actividades para la estimacin y planificacin de software. 2. Las actividades para revisin y concrecin de compromisos de lproyecto.. 3. Las actividades para la preparacin del Plan de Desarrollo de Software. 4. El estndar utilizado para la confeccin del Plan de Desarrollo de Software. 101

5. El contenido del Plan de Desarrollo de Software. _____________________________________________________________ Cuestionario de madurez Las estimaciones (tamao, costo, cronograma, etc) se documentan para usar en el planeamiento y seguimiento del proyecto de software? Los planes de software documentan las actividades a ser ejecutadas y los compromisos hechos? Todos los grupos e individuos acuerdan son compromisos relacionados con el proyecto? El proyecto sigue una poltica organizacional escrita para planear el proyecto? Se proveen recursos adecuados para el planeamiento del proyecto (fondos, personal con experiencia, etc.) Se usan mediciones para determinar el status de las actividades de planeamiento (ejemplo: los hitos completados se comparan con el plan)? El gerente de proyecto revisa las actividades de planeamiento sobre la base de perodos y eventos? _____________________________________________________________ Conclusiones del CMM

Una forma de ocuparnos de la calidad es a travs de la mejora del proceso de desarrollo de software. Como modelo de madurez y capacidad, CMM representa una de las alternativas mas efectivas y difundidas en todo el mundo para guiar a las organizaciones de software en la seleccin de estrategias para el mejoramiento de sus procesos de desarrollo.

102

CMM describe un camino evolutivo de cinco niveles madurez en el cual cada nivel nos indica reas claves de proceso y nos lleva desde un proceso inicial o ad hoc hasta un proceso maduro o disciplinado. Los principales beneficios que provee son: mejorar la calidad de los productos, aumentar tiempo de respuesta al mercado e incrementarla productividad de la organizacin.

3. 4 MOPROSOFT
(Modelo de Procesos para la Industria de Software)
La Secretara de Economa (SE) defini el Programa para el Desarrollo de la Industria de Software (PROSOFT que formaba parte del Plan Nacional de Desarrollo 2001-2006. PROSOFT tiene siete lneas estratgicas, siendo la sexta la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos". Al comenzar el desarrollo de esta lnea estratgica se evalu la adopcin de los modelos: ISO 9000, ISO 15504, SW-CMM. El resultado de la evaluacin fue: "Ninguno de los estndares o modelos cumple con los requisitos expresados por la industria nacional", y se decidi la elaboracin de un modelo adecuado para las caractersticas de las empresas mexicanas, que se basara en los modelos evaluados. En base a esta decisin la Secretara de Economa encarg la elaboracin de dicho modelo a la Asociacin Mexicana para la Calidad en Ingeniera del Software (AMCIS) en colaboracin con la Universidad Nacional Autnoma de Mxico (UNAM). La primera versin de MoProSoft se public en diciembre de 2002. El Plan Nacional de Desarrollo (PND) 2001-2006 de Mxico plantea el objetivo de mejorar la competitividad del pas mediante la promocin, uso y

103

aprovechamiento de la tecnologa e informacin. En dicho plan la Secretara de Economa defini el Programa para el Desarrollo de la Industria del Software. El propsito de este Modelo de Procesos para la Industria de Software la estandarizacin de su operacin a

(MoProSoft) en Mxico fue: fomentar

travs de la incorporacin de las mejores prcticas en gestin e ingeniera de software, permitiendo elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Para proporcionar este modelo fue necesario considerar que se deba

proporcionar a la industria de software en Mxico, que en su gran mayora es pequea y mediana, un modelo basado en las mejores prcticas internacionales con las siguientes caractersticas: Fcil de entender Fcil de aplicar No costoso en su adopcin Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 [1] o CMM1 V1.1 El modelo de procesos MoProSoft est dirigido a las empresas o reas internas dedicadas al desarrollo y/o mantenimiento de software. Las organizaciones, que no cuenten con procesos establecidos, pueden usar el modelo ajustndolo de acuerdo a sus necesidades. Mientras que las organizaciones, que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir. MoProSoft y su mtodo de evaluacin EvalProSoft, propuesta de Secretara de Economa para la PyME de desarrollo de software, fueron entregados en junio 2004 al NYCE, organismo responsable de la normalizacin y certificacin en Mxico. La norma tcnica a la que da contenido es la NMX-059/01-NYCE-2005 104

que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicacin de su declaratoria en el Diario de la Federacin. El objetivo de esta norma es proveer acceso a las prcticas de ingeniera de software de clase mundial y contar con un mtodo de evaluacin propio. MoProSoft considera que los modelos de evaluacin y mejora, CMMI e ISO/IEC 15504 no resultan apropiados para empresas pequeas y medianas de desarrollo y mantenimiento de software. MoProSoft se basa en los modelos de procesos ISO 9001:2000, en las reas de procesos de los niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prcticas y conceptos de PMBOK Y SWEBOK.

3.4.1 Generalidades y Estructura.

Para la elaboracin del modelo de procesos MoProSoft, fueron aplicados los siguientes criterios: 1. Generar una estructura de los procesos que est acorde con la estructura de las organizaciones de la industria de software (Alta Direccin, Gestin y Operacin). 2. Destacar el papel de la Alta Direccin en la planificacin estratgica, su revisin y mejora continua como el promotor del buen funcionamiento de la organizacin. 3. Considerar a la Gestin como proveedor de recursos, procesos y proyectos, as como responsable de vigilar el cumplimiento de los objetivos estratgicos de la organizacin. 105

4. Considerar a la Operacin como ejecutor de los proyectos de desarrollo y mantenimiento de software. 5. Integrar de manera clara y consistente los elementos indispensables para la definicin de procesos y relaciones entre ellos. 6. Integrar los elementos para la administracin de proyectos en un slo proceso. 7. Integrar los elementos para la ingeniera de productos de software en un solo marco que incluya los procesos de soporte (verificacin, validacin, documentacin y control de configuracin). 8. Destacar la importancia de la gestin de recursos, en particular los que componen la base de conocimiento de la organizacin tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentacin de procesos y los datos recaudados a partir de su uso y lecciones aprendidas. 9. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMM V.1.1. Usar como marco general ISO/IEC 15504 - Software Process Assesment PMBOK, SWEBOK y otros ms especializados. e incorporar las mejores prcticas de otros modelos de referencia tales como

106

Estructura El modelo de procesos (MoProSoft) tiene tres categoras de procesos: Alta Direccin, Gerencia y Operacin que reflejan la estructura de una organizacin.

Fig. 16 Diagrama de categoras de los procesos en MoProSoft.

La categora de Alta Direccin contiene el proceso de Gestin de Negocio. La categora de Gerencia est integrada por los procesos de Gestin de Procesos, Gestin de Proyectos y Gestin de Recursos. ste ltimo est constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organizacin.

La categora de Operacin est integrada por los procesos de Administracin de Proyectos Especficos y de Desarrollo y Mantenimiento de Software. 107

En cada proceso estn definidos los roles responsables por la ejecucin de las prcticas. Los roles se asignan al personal de la organizacin de acuerdo a sus habilidades y capacitacin para desempearlos.

En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de Proceso y otros roles involucrados. Adems se considera al Cliente y al Usuario como roles externos a la organizacin.

MoProSoft al igual que otros Modelos de Proceso, tambin

cuenta con sus

niveles de capacidades como se muestra en la Fig. 16. Los colores mostrados representan los niveles para la versin escrita 1.3 Por niveles de capacidad, esto quiere decir que las partes coloreadas de la norma sugieren un orden de la implementacin de las prcticas de los procesos de MoProSoft partiendo de las prcticas bsicas, correspondientes a nivel1, e incorporando las prcticas que corresponden a los niveles ms avanzados.

NIVEL 1 2 3 4 5

Capacidad de proceso REALIZADO GESTINADO ESTABLECIDO PREDECIBLE OPTIMIZADO

Color Amarillo Azul Verde Rosa Ninguno

Fig.16 Correspondencia de los niveles de capacidad de Moprosoft.

As mismo para una mejor comprensin del modelo y sus procesos vale la pena tomar en cuenta las siguientes definiciones:

108

Concepto Categora de procesos

Descripcin Un conjunto de procesos que abordan la misma rea general de actividad dentro de una organizacin. Conjunto de prcticas relacionadas entre si, llevadas a cabo a travs de roles y por elementos automatizados, que utilizando recursos y a partir de insumos producen un satisfactor de negocio para el cliente. Fin a que se dirige o encamina una accin u operacin. Mecanismo que sirve para mostrar o significar una cosa con evidencias y hechos. Es responsable por un conjunto de actividades de uno o ms procesos. Un rol puede ser asumido por una o ms personas de tiempo parcial o completo. Cualquier elemento que se genera en un proceso. Un conjunto de elementos, tales como actividades, roles, infraestructura y mediciones, que al llevarse a cabo describen la ejecucin de un proceso. Conjunto de tareas especficas asignadas para su realizacin a uno o ms roles. Actividad para confirmar que el producto refleja propiamente los requerimientos especificados para l. Actividad para confirmar que el producto resultante es capaz de satisfacer los requerimientos para su aplicacin especificada o uso previsto. Esquema que expresa las relaciones entre las actividades de un proceso. Una relacin puede ser secuencial, paralela, cclica, de seleccin o anidada. Modificacin a las prcticas, entradas y salidas de un proceso, siempre y cuando no afecten al cumplimiento de sus objetivos. Hacer diligencias conducentes al logro de un negocio. Organizar trabajo y disponer recursos. Empresa o rea interna de una organizacin dedicada al desarrollo y/o mantenimiento de software. Conjunto de elementos o servicios que se consideran necesarios para la creacin y funcionamiento de una organizacin. Accin o efecto de medir. Es un repositorio de todos los productos tales como productos de software, planes, reportes, registros, lecciones aprendidas y otros documentos. Circunstancia que impide el desarrollo de una actividad. Experiencia positiva o negativa obtenida durante la realizacin de alguna actividad. Estudio de la potencialidad o de la capacidad que tiene alguna cosa para producir o dar resultados en el futuro, a partir del anlisis de los datos reunidos previamente.

Proceso

Objetivo Indicador Rol Producto Prctica Actividad Verificacin Validacin Flujo de trabajo Gua de ajuste Gestin Administracin Organizacin Infraestructura Medicin Base de conocimiento Situacin excepcional Leccin aprendida

Prospeccin

109

Patrn de procesos de MoProSoft El patrn de procesos es un esquema de elementos que servir para la documentacin de los procesos, se encuentra constituido por tres partes: Definicin general del proceso: Aqu se identifica su nombre, categora a la que pertenece, propsito, descripcin general de sus actividades, objetivos, indicadores, metas cuantitativas, responsabilidad y autoridad, subprocesos en caso de tenerlos, procesos relacionados, entradas, salidas, productos internos y referencias bibliogrficas. Prcticas: En esta parte se identifican los roles involucrados en el proceso y la capacitacin flujo de requerida, se se describen las las actividades y en detalle, asocindolas a los objetivos del proceso, se presenta un diagrama de trabajo, describen verificaciones validaciones requeridas, se listan los productos que se incorporan a la base de conocimiento, se identifican los recursos de infraestructura necesarios para apoyar las actividades, se establecen las mediciones del proceso, as como las prcticas para la capacitacin, manejo de situaciones excepcionales y uso de lecciones aprendidas. Guas de ajuste: En este apartado se sugieren modificaciones al proceso que no deben afectar los objetivos del mismo. A continuacin se muestra la descripcin del patrn de procesos, esto debe considerarse como una gua al momento de consultar cada uno de los procesos, el orden y las imgenes que aqu se presentan es como lo establece la versin 1.3 y como lo encontrarn en las versiones disponibles al pblico por parte del NYCE. 110

111

112

113

El patrn de procesos fue utilizado como esquema para documentar los procesos de MoProSoft. Las organizaciones que adopten el modelo de procesos pueden adecuarlo a sus necesidades siguiendo las reglas de la seccin 6. El patrn de procesos que utilicen las organizaciones puede ser distinto del sugerido en este modelo, pero debe de preservar los objetivos, indicadores y metas cuantitativas correspondientes para lograr el propsito general de MoProSoft. El patrn de proceso puede ser utilizado para documentar e integrar otros procesos que no fueron contemplados en el modelo.

3.4.2 Categora de Alta Direccin (DIR)

Categora de procesos que aborda las prcticas de Alta Direccin relacionadas con la gestin del negocio. Proporciona los lineamientos a los procesos de la Categora de Gerencia y se retroalimenta con la informacin generada por ellos. El proceso que la conforma es: DIR.1 Gestin de Negocio El propsito de Gestin de Negocio es establecer la razn de ser de la organizacin, sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, as como evaluar los resultados para poder proponer cambios que permitan la mejora continua. Adicionalmente habilita a la organizacin para responder a un ambiente de cambio y a sus miembros para trabajar en funcin de los objetivos establecidos. Este proceso se compone de la planificacin estratgica, la preparacin para la realizacin de la estrategia, y la valoracin y mejora continua de la organizacin.

114

Objetivos Lograr una planificacin estratgica exitosa mediante el cumplimiento del Plan estratgico. Lograr que la organizacin trabaje en funcin del Plan Estratgico mediante la correcta comunicacin e implantacin del mismo. Mejorar el plan estratgico mediante la implementacin de la propuesta de mejoras.

3.4.3 Categora de Gerencia (GER)

Categora de procesos que aborda las prcticas de gestin de procesos, proyectos y recursos en funcin de los lineamientos establecidos en la Categora de Alta Direccin. Proporciona los elementos para el funcionamiento de los procesos de la Categora de Operacin, recibe y evala la informacin generada por stos y comunica los resultados a la Categora de Alta Direccin.

GES.1 Gestin de Procesos. El propsito de Gestin de Procesos es establecer los procesos de la organizacin, en funcin de los procesos requeridos identificados en el plan estratgico. As como definir, planificar, e implantar las actividades de mejora en los mismos. Se compone de las siguientes actividades: planificacin de procesos, preparacin a la implantacin y la evaluacin y control de procesos. Objetivos: Planificar las actividades de definicin, implantacin y mejora de los procesos en funcin del plan estratgico. Dar seguimientos a las actividades de definicin, implantacin y mejora de los procesos mediante el cumplimiento del plan de procesos. Mejorar el desempeo de los procesos mediante el cumplimiento del plan de mejora.

115

Mantener informado a Gestin de Negocio sobre el desempeo de los procesos mediante el Reporte Cuantitativo y Cualitativo. GES.2 Gestin de Proyectos. El propsito de la Gestin de Proyectos es asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organizacin. Se ocupa de los proyectos externos, internos y de las oportunidades de proyectos de la organizacin. Para las oportunidades de proyectos, se debe realizar la generacin y cierre de oportunidades de proyectos, la presentacin de propuesta y firma de contrato. Para los proyectos internos antes de su aprobacin, se requiere evaluar diferentes alternativas de realizacin. Los proyectos internos y externos aprobados requieren de una planificacin general y asignacin de los recursos, asi como un seguimiento y evaluacin de desempeo. La gestin de proyectos comprende la planificacin, la realizacin y la evaluacin y control. Objetivos: Cumplir con el Plan Estratgico de la organizacin mediante la generacin e instrumentacin de proyectos. Mantener bajo control las actividades de Gestin de Proyectos mediante el cumplimiento del Plan de Gestin de Proyectos. Proveer la informacin del desempeo de los proyectos a Gestin de Negocio mediante la generacin del Reporte Cuantitativo y cualitativo. Atender los comentarios y quejas del cliente mediante la definicin y ejecucin de acciones preventivas o correctivas. GES.3 Gestin de Recursos. El propsito de GES.3 es conseguir y dotar a la organizacin de los recursos humanos, infraestructura, ambiente de trabajo y proveedores, as como crear y mantener la base de conocimiento de la organizacin. La finalidad es apoyar el cumplimiento de los objetivos del plan estratgico de la organizacin. 116

Se compone de las siguientes actividades: la planificacin, seguimiento y control de recursos, e investigacin de tendencias tecnolgicas, apoyadas con tres subprocesos: Recursos Humanos y ambiente de trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organizacin. Objetivos: Lograr los objetivos del Plan Estratgico mediante la provisin de los recursos suficientes y calificados a la organizacin. Proveer a los miembros de la organizacin de los medios y mecanismos adecuados para el uso y resguardo de la informacin mediante la Base de Conocimiento. Mantener tendencias tecnolgicas. a la organizacin informada la oportunamente elaboracin de sobre las tecnolgicas mediante propuestas

GES.3.1 Recursos Humanos y Ambiente de Trabajo. Su propsito es proporcionar los recursos humanos adecuados para cumplir las responsabilidades asignadas a los roles dentro de la organizacin, as como la evaluacin del ambiente de trabajo. En funcin del Plan operativo de Recursos Humanos y ambiente de trabajo y Acciones correctivas de Gestin de Recursos se realizan las actividades de preparacin, instrumentacin y generacin de reportes. Objetivos: Proveer a la organizacin de recursos humanos calificados mediante la seleccin y capacitacin adecuada a los roles que les asignen. Evaluar el ambiente de trabajo de la organizacin mediante la encuesta sobre el ambiente de trabajo.

117

GES.3.2 Bienes, Servicios e Infraestructura. Su propsito es proporcionar proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisicin y proyectos. En funcin del Plan Operativo de Bienes, Servicios e Infraestructura y Acciones correctivas de Gestin de Recursos, se realizan las actividades de preparacin, instrumentacin y generacin de reportes. Objetivos : Proporcionar a la organizacin los bienes y servicios requeridos por los procesos y los proyectos mediante la seleccin y evaluacin de los proveedores. Mantener la infraestructura de la organizacin mediante el cumplimiento del plan de mantenimiento. GES.3.3 Conocimiento de la organizacin. Su propsito es mantener disponible y administrar la base de conocimiento que contiene la informacin y los productos generados por la organizacin. En funcin del Plan Operativo de Conocimiento e la Organizacin y las acciones correctivas de Gestin de Recursos se realizan las siguientes actividades: Planificacin, Realizacin, Evaluacin y control para generar peridicamente un reporte del estado de la Base del conocimiento. Su objetivo es: Proporcionar ala organizacin la Base de Conocimiento de forma confiable, oportuna y segura mediante el cumplimiento del plan de administracin de la Base del Conocimiento.

3.4.4 Categora de Operacin (OPE)

Esta categora de procesos aborda las prcticas de los proyectos de desarrollo y mantenimiento de software. Esta categora realiza las actividades de acuerdo 118

a los elementos proporcionados por la Categora de Gerencia y entrega a sta la informacin y productos generados. Los procesos que contiene esta categora son los siguientes: OPE.1 Administracin de Proyectos Especficos .Establece y lleva a cabo sistemticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados. Aplica conocimientos, habilidades, tcnicas y herramientas, a cada una de las siguientes actividades: Planificacin, Realizacin, Evaluacin y control y cierre. Sus objetivos son: Logar los objetivos del proyecto en tiempo y costo mediante la coordinacin y el manejo de los recursos del mismo. Mantener informado al cliente mediante la realizacin de reuniones de avance del proyecto. OPE.2 Desarrollo y Mantenimiento de Software Realizar sistemticamente las actividades de anlisis, diseo, construccin, integracin y pruebas de productos de software nuevos o modificados, cumpliendo con los requerimientos especificados. Para el estudiante ser interesante ste apartado dado que se encuentra en fase de aprendizaje de la construccin de sistemas de informacin o productos de software, por lo que para sta norma se mencionan las actividades en el proceso de desarrollo. El proceso de desarrollo y mantenimiento de software se compone de uno o ms ciclos de desarrollo, cada ciclo est compuesto de las fases siguientes: INICIO: Se revisa el plan de desarrollo por los miembros del equipo de trabajo para lograr un entendimiento comn del compromiso de su realizacin. 119 proyecto y para obtener el

REQUERIMIENTOS: Conjunto de actividades cuya finalidad

es obtener la

documentacin de la Especificacin de Requerimientos y Plan de Pruebas al Sistema, para conseguir un entendimiento comn entre el cliente y el proyecto. ANALISIS Y DISEO: Conjunto de actividades en las cuales se analizan los requerimientos especificados para producir una descripcin de la estructura de los componentes del software, la cual servir de base para la construccin. Como resultado se obtiene la documentacin de anlisis y diseo y Plan de pruebas de integracin. CONSTRUCCION: Conjunto de actividades para producir componentes de software que correspondan al anlisis y Diseo as como la realizacin de pruebas unitarias. Como resultado se obtienen los componentes de software probados. INTEGRACIN Y PRUEBAS: Integrar y probar los componentes de software, basndose en los planes de pruebas de Integracin y de Sistema, con la finalidad de obtener el software que satisfaga los requerimientos especificados. Se genera la versin final del Manual de Usuario, Manual de Operacin y Manual de mantenimiento. Como resultado se obtiene el producto de software probado y documentado. CIERRE: Integracin final de la configuracin de software generada en las fases para su entrega, Identificacin y documentacin de las Lecciones Aprendidas, Generacin de Reporte de Mediciones y Sugerencias de Mejora.

120

Objetivos: Lograr que los productos de salida sean consistentes con los productos de entrada en cada fase de un ciclo de desarrollo mediante las actividades de verificacin, validacin o prueba. Sustentar la realizacin de ciclos posteriores o proyectos de mantenimiento futuros mediante la integracin de la configuracin de

software del ciclo actual. Llevar a cabo las actividades de fases de inicio de un ciclo mediante el cumplimiento del plan de desarrollo actual.

3.5 Preguntas de repaso y prcticas sugeridas.

1. Investigar qu empresas se han certificado en las distintas normas aqu presentadas, cuales han sido las ventajas obtenidas para dichas empresas.

2. Discutir en grupo sobre las diferencias y semejanzas entre una norma aplicada a la calidad de software.

3. Investigar las prcticas correspondientes a los primeros niveles de madurez o de capacidad, aplicarlas o verificarlas con el proyecto de software a realizar.

4. Comparar los diferentes modelos o normas que pueden aplicarse al desarrollo de software.

121

5. Discutir en clase sobre el impacto que ha tenido la implantacin de la norma Moprosoft en nuestro pas. 6. Tomando en cuenta el ejemplo citado para la evaluacin de un rea de proceso como lo es la Planeacin del proyecto de software, invite a los equipos a emular una evaluacin a la planeacin de su proyecto, una vez que estos hayan realizado al menos un ciclo de desarrollo. Tambin puede aplicarse la realizacin del postmortem como se explica en el anexo 3 de este texto. 7. Para equipos o estudiantes de semestres avanzados y con mayores fortalezas en el desarrollo de software, puede sugerir realizar su producto de software bajo una norma propuesta, los mismos estudiantes decidirn las herramientas y modelos a aplicar, otros equipos tambin pueden hacer el rol de evaluadores o testers de pruebas al mismo software. Se recomienda que sean proyectos de software que han sido continuados en otras materias o que llevan un tiempo desarrollndose.

122

4 Calidad enfocada al desarrollo de software.

4.1 Qu es la calidad del software?
Tal como se vio en el apartado 1.2, se defini a la calidad de software como la Concordancia con los requerimientos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinnimo de eficiencia, flexibilidad, correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y vara de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo perodo (10 aos o ms), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotacin. La calidad del software puede medirse despus de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin de la calidad como su control durante todas las etapas del ciclo de vida del software. 123

4.2 Cmo obtener calidad de software.

A travs de todo este texto se han mostrado las distintas normas y prcticas existentes tanto a nivel internacional como nacional, y que la mayora de ellas hacen especial nfasis en el proceso que implica el desarrollo as como la gestin de recursos implicados y el desarrollo del producto. Las diversas herramientas y mtodos tambin fueron mostrados en el apartado 2.8., en conjunto todas ellas hacen que las mejores prcticas de desarrollo puedan llevarse a cabo y mejoramiento del producto de software. La obtencin de o un software con calidad implica la utilizacin para el anlisis, de sean tiles en el proceso del

metodologas

procedimientos

estndares

diseo,

programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico. El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado. La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin.

124

4.3 Cmo controlar la calidad del software.

Para controlar la calidad del software es necesario, ante todo, definir los parmetros, indicadores o criterios de medicin, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir". Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define mtricas de calidad y criterios, donde cada mtrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodologa para la evaluacin de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerrquicos: factor, criterio, mtrica, elemento de evaluacin, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categoras de mtricas: de complejidad de programa o cdigo, y de complejidad de sistema o estructura. Todos los autores coinciden en que el software posee determinados ndices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los ndices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos: Definir el software que va a ser controlado: clasificacin por tipo, esfera de aplicacin, complejidad, etc., de acuerdo con los estndares establecidos para el desarrollo del software.

125

Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios periciales y herramientas automatizadas para medir los criterios de clculo. Definir las regulaciones organizativas para realizar el control: quines participan en el control de la calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc.

4.4 Costo de la calidad del software.

Incluye costos tanto de la bsqueda de calidad como de las acciones realizadas para su obtencin. Los costes de calidad pueden dividirse segn el enfoque en: Costos de prevencin: Planificacin de la calidad, revisiones tcnicas formales, equipo de pruebas, formacin. Costos de evaluacin: para tener una visin de la calidad real del producto, incluye la inspeccin en el proceso y entre procesos,calibrado y mantenimiento del equipo. Costes de fallos, que pueden dividirse en costos internos o externos. Internos: errores antes de la entrega del producto al cliente( Revisin, reparacin, anlisis de las modalidades de fallos). Externos: errores o defectos detectados despus del envo al cliente (Resolucin de quejas, devolucin y sustitucin de productos, soporte de lnea de ayuda, trabajo de garanta). Los costos relativos de calidad aumentan rpidamente de prevencin a deteccin y de error interno a externo.

126

La distribucin de costos a travs de las distintas actividades en el proceso de software depende del proceso utilizado y del tipo de software que se vaya a desarrollar. Por ejemplo, el software de tiempo real normalmente requiere una validacin y pruebas ms extensas que los sistemas basados en web. Sin embargo cada uno de los diferentes enfoques genricos al desarrollo del software tiene un perfil de distribucin de costos diferente a travs de las actividades del proceso del software. Si se considera que el costo total del desarrollo de un sistema de software complejo es de 100 unidades de costo, la Fig.20 muestra cmo se gastan stas en las diferentes actividades del proceso.

Fig.20 Distribucin de costos de las actividades de la Ing. Software

En un enfoque en cascada, los costos de especificacin, diseo, implementacin e integracin se miden de forma separada, la integracin y pruebas del sistema son las actividades de desarrollo ms caras. Normalmente, ste supone alrededor del 40% del costo de desarrollo total, pero para algunos sistemas crticos, es probable que sea al menos el 50% de los costos de desarrollo del sistema. 127

Si el software se desarrolla utilizando un enfoque interativo, no existe divisin entre la especificacin, el diseo y el desarrollo. En este enfoque, los costos de la especificacin se reducen debido a que slo se produce la especificacin de alto nivel antes que el desarrollo. La especificacin, el diseo, la implementacin, la integracin y las pruebas se llevan a cabo en paralelo dentro de una actividad de desarrollo. Sin embargo, aun se necesita una actividad independiente de pruebas del sistema una vez que la implementacin inicial est completa. La ingeniera de software basada en componentes slo ha sido ampliamente utilizada durante un corto periodo de tiempo, en este enfoque no se tiene datos exactos para los costos de las diferentes actividades de desarrollo de software, sin embargo, se sabe que los costos de desarrollo se reducen en relacin a los costos de integracin y pruebas. Los costos de integracin y pruebas se incrementan porque se tiene que asegurar que los componentes utilizados cumplen realmente su especificacin y funcionan como se espera con otros componentes. Adems de los costos de desarrollo, existen costos asociados a los cambios realizados cuando el software ya est en uso. Los costos de evolucin varan drsticamente dependiendo del tipo de sistema. Para sistemas de larga vida, tales como los sistemas de orden y control que pueden ser usados durante 10 o ms aos, estos costos exceden a los de desarrollo por un factor de 3 o 4, como se muestra en la penltima barra de la Fig. 20. tanto costos de evolucin ms reducidos. Esta distribucin de costos se cumple para el software personalizado, el cual es especificado por un cliente y desarrollado por un contratista. Para productos de software que se venden de manera comercial, el perfil del costo es diferente. 128 Sin embargo, los sistemas de negocio ms pequeos tienen una vida mucho ms corta y, por lo

Estos productos comnmente se desarrollan a partir de una especificacin inicial utilizando un enfoque de desarrollo evolutivo. Los costos de la especificacin son relativamente bajos. Sin embargo, debido a que se pretende utilizarlos en distintas configuraciones, deben ser probados a fondo. En la ltima barra de la Fig. 20 se muestra el perfil del costo que se puede esperar para estos productos. Los costos de evolucin para productos de software genricos son difciles de estimar. En muchos casos, existe poca evolucin de un producto. Una vez que una versin de producto se entrega, se inicia el trabajo para entregar la siguiente y, por razones de mercadotecnia, sta se presenta como un producto nuevo (pero compatible) ms que como una versin modificada de un producto que el usuario ya adquiri. Por lo tanto, los costos de evolucin no se consideran de forma separada como en el caso del software personalizado, sino que son sencillamente los costos del desarrollo para la siguiente versin del sistema.

4.5 Nomenclatura y certificacin ISO 9001:2000

La nomenclatura de la norma de calidad en caso especfico de la ISO 9000: 2000 es la siguiente: 1 Parte ISO Esta seccin de la nomenclatura indica la norma de la que se trata, en este caso es la norma ISO, la cual significa para la traduccin en espaol como Organizacin Internacional de estndares, en esta seccin se indica el tipo de norma, como ejemplo otra nomenclatura puede ser la QS la cual es la usada en las empresas de giro automotriz, etc. 2 Parte 9000 Esta seccin indica el tipo de norma de la que se esta hablando en este caso la 9000 es el vocabulario, trminos y definiciones solamente, la 9001 son los 129

requisitos, mucha gente por no conocer esta diferencia ,hace referencia a que "esta certificada por ISO 9000" esto es un error la certificacin se realiza mediante el cumplimiento de requisitos, entonces la ISO 9000 es un apoyo de todo el vocabulario que se incluye en la ISO 9001 3 Parte 2000 Esta seccin es para indicar desde cuando es vigente la norma , en este caso la ultima vigencia de la ISO 9001 es desde el ao 2000 La norma ISO 9001:200 (ISO,2000), especifica los requisitos para un sistema de gestin de calidad cuando una organizacin: Necesite demostrar su capacidad para proporcionar de forma coherente productos que satisfagan los requisitos del cliente y los reglamentos aplicables. Aspira a aumentar la satisfaccin del cliente a travs de la aplicacin eficaz del sistema, incluyendo los procesos para la mejora continua del sistema y el aseguramiento de la conformidad con los requisitos del cliente. Los principios bsicos de la norma ISO 9001, constituyen la parte medular del sistema son: Enfoque al Cliente: Las organizaciones dependen de sus clientes y por tanto deberan comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes. Liderazgo: Los lderes establecen la unidad de propsito y la orientacin de la organizacin Ellos deberan crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organizacin.

130

Participacin del personal: El personal, a todos los niveles, es la esencia de una organizacin y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organizacin. Enfoque basado en procesos: Un resultado deseado se alcanza mas eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso Enfoque de sistema para la gestin: Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organizacin en el logro de sus objetivos. Mejora Continua: La mejora continua del desempeo global de la organizacin debera ser un objetivo permanente de sta. Enfoque basado en hechos para la toma de decisin: Las decisiones eficaces se basan en el anlisis de los datos y la informacin. Relaciones mutuamente beneficiosas con el proveedor: Una

organizacin y sus proveedores son interdependientes y una relacin mutuamente beneficiosa aumenta la capacidad de ambos para crear valor. Estos ocho principios de gestin de la calidad constituyen la base de las normas de sistemas de gestin de la calidad(SGC). La norma ISO 9001 est dividida en ocho puntos, de los cuales, los cinco ltimos definen los requisitos del SGC (Sistema de Gestin de Calidad). PARTE 1, 2, 3 INTRODUCCION A LA NORMA En la cual se destacan los siguientes conceptos: Los objetivos y campo de aplicacin de la norma, son demostrar la capacidad para cumplir los 131

requisitos reglamentarios y los del cliente y satisfacerle mediante la mejora continua y la prevencin de no conformidades. Se pueden excluir ciertos requerimientos de la norma en funcin de la naturaleza de los productos o servicios, los requerimientos del cliente o los requisitos reglamentarios. En la parte 2 se indica que la norma de consulta es la ISO 9000:2000 relativa a los Sistemas de Gestin de la calidad, principios y vocabulario. PARTE 4 SISTEMA DE GESTION DE CALIDAD Aqu se definen los requisitos generales y los documentacin. Los requisitos generales son: Planificar: Identificar de todos los procesos que, afectar a la calidad del producto, determinar la secuencia y relacion que estos procesos tienen entre s. Ejecutar: Determinar metodos y criterios para asegurar el correcto requisitos generales de

funcionamiento y control de los procesos, los procesos deben estar documentados y medidos mediante parmetros relevantes, y se establecen los responsables de los procesos. Medir: asegurar la disponibilidad de la informacin suficiente que permita el seguimiento del proceso. Actuar: Medir y realizar el seguimiento del proceso, para analizar y conseguir una mejora continua.

132

PARTE 5 RESPONSABILIDAD DE LA DIRECCIN Aqu se indica las series de responsabilidades o acciones en las cuales el Gerente General debe de participar directamente o mnimo estar enterado de ellas, entre las que se destacan: Compromiso de la direccin, el enfoque al cliente, poltica de calidad, planificacin, administracin, revisin por la direccin. PARTE 6 GESTION DE RECURSOS Aqu se indica lo mnimo necesario que la organizacin debe de gestionar en cuanto a recursos, esto para garantizar al cliente que la falta de los mismos no generar un producto de mala calidad. Se detallan cuatro subpartes: Suministro de recursos, Recursos humanos, Instalaciones, Entorno de trabajo. PARTE 7 REALIZACIN DEL PRODUCTO Aqu se indican los requisitos mnimos necesarios para realizar las actividades que garanticen producto que cumplan con lo estipulado, esta se subdivide en 6 partes: Planificacin de los procesos de realizacin, Procesos relacionados con los clientes, Diseo y/o desarrollo, Compras, Operaciones de produccin y prestacin de servicios, control de equipos de medicin y de seguimiento.

PARTE 8 MEDICIN , ANALISIS Y MEJORA Este punto hace referencia a la medicin que se debe realizar al producto en sus diferentes fases y al producto final, es decir describe los requisitos relacionados con la deteccin, el seguimiento y el anlisis de las mejoras. Se subdivide en 5 subpartes: Planificacin, medicin y seguimiento, control de las no conformidades, anlisis de datos, mejora. 133

Dentro de la medicin y seguimiento se incluyen las siguientes reas: Satisfaccin del cliente, auditora interna, medicin y seguimiento de los procesos, medicin y seguimiento del producto.

4.6 La norma ISO/IEC 9126

La norma ISO/IEC 9126 est enfocada a la calidad de Producto y consta de las siguientes partes: Parte 1: Modelo de Calidad Define un modelo de calidad basado en dos partes bien identificadas: la calidad interna y externa, y la calidad de uso. Calidad interna: totalidad de las caractersticas del producto de software desde un punto de vista interno. Calidad externa: totalidad de las caractersticas del producto de software desde un puesto de vista externo. Calidad de uso: capacidad del software que posibilita la obtencin de objetivos seguridad. La calidad del proceso influye en la calidad del producto que a su vez es relevante en la calidad de uso. La figura 17 muestra el modelo de calidad segn ISO/IEC 9126. especficos con efectividad, productividad, satisfaccin y

134

Fig. 17 Modelo de calidad segn ISO/IEC 9126 Parte 2: Mtricas externas Son medidas del producto de software obtenidas del comportamiento del sistema en la fase de ejecucin del mismo. Finalmente las mtricas de calidad de uso, como tercer gran concepto propuesto por la norma, mide la extensin en la que un producto alcanza las necesidades expuestas por el usuario de forma especfica en relacin a los objetivos de efectividad, seguridad, productividad, y satisfaccin. Parte 3: Mtricas internas Son aquellas medidas que se realizan sobre un producto de software no ejecutable, tal como la norma indica un producto de software intermedio debera ser evaluado usando mtricas internas.

Parte 4: Calidad en las mtricas de uso. Comprende la eficacia, productividad, seguridad y satisfaccin definidas como:

135

Eficacia: Capacidad del software para permitir a los usuarios alcanzar objetivos especficos con precisin y completamente en un contexto especfico de uso. Productividad: Capacidad del producto de software para alcanzar niveles aceptables de riesgo hacia la gente, negocio, software, propiedad o medio ambiente, en un contexto especfico de uso. Satisfaccin: La capacidad del producto de software para satisfacer al usuario en un contexto especfico de uso.

4.7 Anlisis de factores que determinan la calidad del software.

Desde un punto de vista ms formal, se puede decir que un producto software es de calidad si cumple o tiene algunos o todos de los siguientes factores de calidad: Correccin: cumple la especificacin de requisitos. Mantenibilidad: facilidad para cambiar el software. Portabilidad: esfuerzo para trasladar el software de una a otra plataforma. Testabilidad: facilidad para probar que el software es correcto. Facilidad de uso: esfuerzo para aprender, usar e interrumpir un sistema en marcha. Confiabilidad: capacidad para continuar el trabajo aunque haya interrupciones. (sistemas seguros)

136

Eficiencia: recursos que se necesita para la aplicacin. Integridad: datos y sistemas inaccesible por personas no autorizadas. Reusabilidad: facilidad para reutilizar cosas en otros proyectos. Interoperabilidad: habilidad para operar con otros sistemas.

Qu es un factor de calidad? Un factor de calidad tambin llamado parmetro de calidad es una cualidad cuya presencia o ausencia en un producto software condiciona su calidad. Factores externos: Detectados por los usuarios. Son los factores que realmente interesan(objetivo). Factores internos: nicamente percibidos por los desarrolladores. Un medio para conseguir la calidad externa. Factores de calidad de McCall Clasifica los factores de calidad de acuerdo a las etapas por las que un producto pasa: Transicin de producto, Revision de producto y Operacin del producto. Los factores responden a las interrogativas mostradas a continuacin en la Fig.18.

137

Fig.18 Factores de calidad de Mc Call

4.8 Anlisis del proceso del ciclo de vida del software

En el apartado 2.4 de este mismo texto se explic la calidad del software en el proceso de ciclo de vida de software, los procesos que lo conforman, as como la definicin del modelo de ciclo de vida; por lo que nicamente en este mismo apartado se limitar a mencionar los principales modelos de ciclo de vida. Modelos tradicionales Formados por un conjunto de fases o actividades en las que no tienen en cuenta la naturaleza evolutiva del software: Clsico, lineal o en cascada Estructurado Iterativo o basado en prototipos Desarrollo rpido de aplicaciones (RAD) Modelos evolutivos Son modelos que se adaptan a la evolucin que sufren los requisitos del 138

sistema en funcin del tiempo. En espiral Evolutivo Incremental Modelo de desarrollo concurrente Modelos para sistemas orientados a objetos Modelos con un alto grado de iteratividad y solapamiento entre fases. De agrupamiento Fuente Remolino Pinball Basado en componentes UP

4.9 Funciones de evaluacin del software

Con base en los estndares de calidad sugeridos la norma ISO/IEC 9126, de la ISO (Organizacin Internacional de Normalizacin) y la IEC (Comisin Electrotcnica Internacional) se presenta el proceso de evaluacin de software. El proceso de evaluacin de software se inicia con una visin cualitativa y deriva en una evaluacin cuantitativa, siendo todo el proceso documentado y cumpliendo los siguientes pasos: 1 Estado del Software: Conocimiento del el estado del software, estableciendo si se trata de un desarrollo sin terminar o un producto terminado para la entrega al cliente.

139

2 Identificar el tipo de software: Especificar el tipo de software a evaluar, si es un sistema operativo, software de seguridad, software de ofimtica, lenguaje de programacin, base de datos, aplicativo a la medida, entre otros. 3 Perfiles de Evaluadores: Teniendo como marco conceptual al estndar ISO [ISO/IEC9126], se consideran tres perfiles de usuario, a un alto nivel de abstraccin para desarrollo de software, usuarios finales, desarrolladores, y gerentes. El estndar afirma que la relativa importancia de las caractersticas de calidad (como usabilidad, funcionalidad, confiabilidad, eficiencia, portabilidad, y mantenibilidad y calidad en uso) varan dependiendo del punto de vista considerado y de la critica de los componentes del software a evaluar. La visin del usuario final, concierne al inters de los mismos en usar el software, como as tambin su ejecucin, su eficiencia, su facilidad de uso, entre otros aspectos. Los usuarios finales no estn interesados en caractersticas internas o de desarrollo del software (sin embargo, atributos internos contribuyen a la calidad de uso). La visin de calidad del desarrollador debe considerar no slo los requerimientos del software para la visin del usuario sino tambin la calidad para los desarrollos intermedios resultantes de las actividades de la fase de desarrollo. Se debe tener en cuenta que los desarrolladores estn preocupados en caractersticas de calidad del software como mantenibilidad y portabilidad. La visin de calidad del gerente es una visin integradora, que incorporar requerimientos de negocio a las caractersticas individuales. Ejemplo, un gerente esta interesado en el equilibrio entre la mejora del software y los costos y tiempos establecidos. 140

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

Fig.19 Criterios al evaluar un software.

141

7 Seleccionar mtricas La seleccin de mtricas se obtiene a partir de los indicadores especificados en el modelo. Niveles o escalas A cada mtrica seleccionada le asigna un puntaje mximo de referencia. La suma de los puntajes mximos de todas las mtricas debe ser igual o aproximado a 100 puntos. El personal que participa en la evaluacin debe establecer niveles de calificacin cualitativa con base a los puntajes, por ejemplo:

De 0 a 1 Inaceptable. De 2 a 3 mnimo aceptable Mas de 3 Aceptable o satisfactorio Otro ejemplo de calificacin cualitativa puede ser: Deficiente Insuficiente Aceptable Sobresaliente Excelente Se permite usar nmeros enteros o hasta con un decimal de

aproximacin. Definir por cada mtrica, un puntaje mnimo de aprobacin, y al final de la evaluacin, dependiendo del puntaje si es mayor o menor a lo propuesto, considerar si el software cumple o no cumple con los objetivos propuestos.

142

8 Establecer criterios Las persona que participa en el proceso de evaluacin debe tener criterios con respecto al indicador que se esta analizando, Es importante tener en cuenta que el criterio debe ajustar al tipo de software que se va a evaluar. 9 Tomar medidas Para la medicin, las mtricas seleccionadas se aplican al software. Los resultados son valores expresados en las escalas de las mtricas, definidos previamente. 10 Resultados El proceso de evaluacin genera un cuadro de resultados por cada uno de los principales indicadores y el total final de resultado.

11 Documentacin El proceso de evaluacin se documenta, indicando la fecha, empresa, los cargos, nombres y apellidos, dependencia de las personas que participan en el proceso de evaluacin, especificando las etapas en las que participaron. 6.12 Seguimiento Si el resultado de la evaluacin tiene observaciones o indicadores de calidad bajos, y el personal que lo evala permite realizar la correccin, se programa otra evaluacin donde se verifique que el proceso mejora, el tiempo que se estime debe influir en los criterios de la aproxima evaluacin.

143

4.10 Preguntas de repaso y prcticas sugeridas.

1. Investigar y participar en un foro de discusin en clase para abordar las diferencias que existen as como las ventajas y desventajas de aplicar un modelo de ciclo de vida respecto a otro. 2. Realizar la revisin tcnica formal del producto de software teniendo como base los factores de calidad de McCall, sta revisin puede llevarse a cabo dentro de la clase en donde para corroborar la existencia de los mismos se le pide a los integrantes del equipo identifiquen y justifiquen como fueron aplicados a su producto de software. 3. Integrar como parte de las estrategias de un nuevo ciclo de desarrollo, los factores de calidad, de manera que durante el anlisis, diseo y desarrollo del producto se mantenga como objetivo lograr que estos factores estn presentes y puedan ser demostrados para una nueva revisin. 4. Llevar a cabo el resumen final del proyecto, donde se integre la informacin, lecciones aprendidas y mediciones realizadas a travs del proyecto. Un buen ejercicio final puede ser documentar adecuadamente la base de conocimiento adquirida para futuros proyectos a realizar. 5. Investigar y discutir a manera de lluvia de ideas en clase cuales fueron las mejores practicas que pueden ayudar a que la calidad de un producto de software se obtenga. 6. Investigar ms sobre los costos que acarrea el implantar o buscar calidad en los productos de software.

144

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

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

146

FASE: LANZAMIENTO Formar equipo de trabajo Definir proyecto/Investigar que proyecto hacer Definicin de lugar y horas de trabajo Definicin de estndares de documentos Definir un presupuesto general investiga precios Asignacin de roles y tareas preeliminares Capturar toda la informacin anterior con base en la plantilla de equipo Impresin de los documentos DEFINICION DESARROLLAR Lectura-Revisin de los documentos emitidos Bitcora de equipo Preservar RESPALDO VERIFICA DE documentacin TODOS Y LOS y ARCHIVOS archivos DURANTE QUE SE DURANTE TODO EL CICLO TODOS LOS CICLOS /Elaborar un plan de respaldo TIEMPOS ACTIVIDADES ESTEN REALIZANDO A TIEMPO solicita correccin DE ESTRATEGIAS PARA EL CICLO A

E R R R R R X

R X X X X X X X X X X X

R R X R x R R X

Simbologa R = Responsable P=Programador X = colaborador T=Tester Q= Asegurador de Calidad E= Todos (EQUIPO) L=Lder de proyecto A=Analista D=Diseador

147

FASE: PLANEACION Y ANALISIS DE REQUERIMIENTOS Definir tareas generales de acuerdo al proyecto en formato TSP ciclo N Definir tareas particulares de acuerdo al Rol y proyecto seleccionado formato PSP ciclo N Realizacin de actividades del anlisis general de acuerdo al proyecto Definicin de requerimientos Elaboracin de modelos que representen dichos requerimientos Revisin de modelos de acuerdo a requerimientos Formular estrategias de capacitacin para el desarrollo del producto o capacitar al equipo Anlisis de alternativas, riesgos, etc Actualizacin de formatos TSP Actualizacin de formatos PSP Elaboracin de documentos del anlisis general Elaboracin de prototipo de acuerdo a los requerimientos preeliminar Prueba a los prototipos (en caso de haberlos requerimientos Lectura-Revisin y solicita correccin de los documentos emitidos Entrega de avances realizados) verifica o elaboracin diseo

E X

L R

R R R X X R

X X R X R

x R

148

FASE: DISEO Diseo fsico del producto Diseo lgico del producto Diseo de controles preventivos, detectivos correctivos del producto Diseo de pruebas al producto Diseo de la seguridad del producto (fsica, integridad, Verificacin del diseo con base en los requerimientos antes definidos Pruebas al diseo(s) del producto Elaboracin de algoritmos de solucin Capacitacin en herramientas de desarrollo a miembros del equipo Elaboracin de documentos general Presentacin del diseo al cliente Rectificacin de requerimientos solicitados del diseo en

L x x

A x x

D R R R

x x x R x x R R X

x x x x x x X R x X R correccin x R R x x x x X x R x x R

R R x X x x R

por el cliente en el diseo del producto Actualizacin de formatos TSP Actualizacin de formatos PSP Lectura-Revisin y solicita

de los documentos emitidos Entrega de avances/ Bitcora

Simbologa R = Responsable P=Programador X = colaborador T=Tester Q= Asegurador de Calidad E= Todos L=Lder de proyecto A=Analista D=Diseador

149

FASE: IMPLEMENTACION Y PRUEBAS Desarrollo de programas con base en los diseos Elaboracin de pruebas al producto de software documentacin del resultado de las mismas Verificacin requerimientos Documentar programacin Actualizacin de formatos TSP Actualizacin de formatos PSP Lectura-Revisin y solicita correccin del en cumplimiento el producto y de de los software. durante

E x

P R

Solicitud de correcciones tiempos errores R X R x R E PSP de acuerdo al ciclo R L A D P T Q x R R

de los documentos emitidos Entrega de avances/ Bitcora FASE: POSTMORTEM Cierre de formato

progamado Cierre de formato TSP de acuerdo al ciclo

programado Resumen de tiempos, esfuerzo, errores Anlisis de los resultados obtenidos vs estrategias utilizadas Resumen de conclusiones para el ciclo concluido Cierre de toda la documentacin emitida durante el ciclo Verificacin de la documentacin a entregar Diseo de presentacin del producto verificacin de la misma Entrega de avances/ Bitcora (en su caso) Preparacin usuario de capacitacin al

R R R R R x x R R x R x R X x

150

Anexo 2 Formato para planeacin y registro de tiempo individual

Ejemplo (continuacin) 4.-Cada integrante es responsable de registrar y documentar sus actividades, al trmino de las mismas reportar al responsable de la actividad y lider del equipo. Al concluir el ciclo de desarrollo deber obtener el numero total de horas para cada actividad y participar con su equipo en el postmortem.(Anexo 3)

151

Anexo 3 Formato auxiliar para postmortem y lecciones aprendidas.

FASE: LANZAMIENTO Se llevo a cabo la formacin del equipo en forma adecuada? El proyecto fue definido en su objetivo general? Se definieron las horas y lugar de trabajo de equipo Fueron definidos los estndares de documentacin y trabajo en esta fase? Los roles estn asignados de acuerdo a las caractersticas y fortalezas de cada integrante? Fueron reconocidas las habilidades y se formularon estrategias para fortalecer las deficiencias en cada integrante del equipo? Los participantes del equipo conocen sus roles asignados y las tareas a realizar Cada integrante cuenta con su documento PSP impreso y actualizado Se definieron estrategias para el proyecto en esta etapa y fueron seguidas por todos y cada uno de los integrantes Se llev a cabo un plan de presupuesto y estrategias para asumir los costos inherentes a la realizacin del proyecto? Se llevo a cabo la lectura y correccin de los documentos que forman parte de esta fase El equipo tom como parte de sus estrategias el asesoramiento por parte del profesor? En la bitcora de equipo pueden identificarse las actividades referentes a esta fase Se realizo una estrategia de respaldo y resguardo de los documentos y archivos generados Se formularon estrategias de capacitacin para el desarrollo del producto o capacitar al equipo? Todos los participantes del equipo terminaron al mismo tiempo esta fase? Se realizo la verificacin de tiempos asignados para esta fase de forma adecuada y oportuna SI NO Observaciones

152

Los formatos de TSP se refieren a un cronograma general que el equipo puede plantear con los tiempos como se explic en el anexo 1, y el formato de PSP se refiere al formato de planeacin de actividades individual.
FASE: PLANEACION Y ANALISIS DE REQUERIMIENTOS Fueron definidas las tareas y tiempos en el formato TSP, Fueron definidas las tareas particulares de acuerdo al Rol y proyecto seleccionado utilizando el formato de PSP? Cada integrante realiz su PSP considerando los tiempos y fases marcadas en el TSP del equipo? El formato fue verificado por el lder de proyecto y SQA? Cada integrante cont con su PSP impreso y fue actualizado diariamente? El analista defini otras tareas o actividades de apoyo para los compaeros del equipo? Se elaboraron estrategias para conocer los requerimientos del cliente? Se obtuvieron los requerimientos del cliente o usuario potencial directamente? Los requerimientos estn expresados por documentos y/o modelos que son claramente entendidos por los miembros del equipo? Las tcnicas empleadas durante el anlisis fueron suficientes para la obtencin de los requerimientos? Se formularon alternativas de desarrollo y/o solucin al producto a desarrollar? Se realiz un anlisis de factibilidad para el proyecto? Se desarrollo un anlisis de riesgos congruente con el proyecto a desarrollar? Fueron planeadas en esta fase los tiempos para realizar las pruebas al proyecto? Hubo algn prototipo preeliminar desarrollado para la mayor comprensin de los requerimientos al cliente.? Hubo una buena comunicacin del analista hacia los dems integrantes del equipo durante esta fase? Los documentos elaborados para esta fase fueron previamente revisados y aprobados por el lder de proyecto y SQA? Las actividades de esta fase estn reflejadas en la bitcora de equipo y en los formatos de planeacin individual de los integrantes? SI NO OBSERVACIONES

153

FASE: DISEO El diseador recibi las especificaciones del analista en forma adecuada y oportuna (a tiempo)? Fueron considerados los riesgos y alternativas de la fase de anlisis para el diseo del producto? Se cuenta con un diseo optimo para la prevencin, deteccin y correccin de errores del producto? Fueron diseadas las pruebas al producto tomando en cuenta los diseos y requerimientos sealados? Fue verificado el diseo del producto de software en base a los requerimientos antes definidos Verificacin del diseo con base en los requerimientos antes definidos Fueron elaborados y documentados los algoritmos, rutinas, componentes durante su diseo? Los algoritmos fueron comprendidos por todos los miembros del equipo? En esta fase se dio inicio a la capacitacin del equipo en lo referente a la programacion u otros aspectos a mejorar? Fueron revisados y verificados los documentos durante esta fase? Se presentaron los diseos al cliente o usuario potencial? Fueron rectificados los diseos de acuerdo a las observaciones hechas por el cliente o usuario potencial? Hubo una buena comunicacin del diseador hacia los dems integrantes del equipo durante esta fase? Los documentos elaborados para esta fase fueron previamente revisados y aprobados por el lder de proyecto y SQA?

SI

NO

Observaciones

154

Las actividades de esta fase estn reflejadas en la bitcora de equipo y en los psp de los integrantes? Se formul como estrategia la reutilizacin de diseos?

FASE: IMPLEMENTACION Y PRUEBAS Se desarrollaron los programas con base en los diseos aprobados ? Fueron elaboradas las pruebas de acuerdo a un procedimiento establecido y documentado? Se verific por parte del SQA y tester el cumplimiento de los requerimientos en el producto de software. Solicitud de correcciones Se documentaron la solicitud de correcciones Se documentaron los errores y tiempos de correccin Se tuvo la participacin de todos los miembros del equipo durante la programacin Las actividades de esta fase estn reflejadas en la bitcora de equipo y en los psp de los integrantes? Existi buena comunicacin del programador hacia los dems integrantes del equipo en esta fase? Existi buena comunicacin del SQA hacia los dems integrantes del equipo en esta fase? Existi buena comunicacin del tester hacia los dems integrantes del equipo en esta fase? Fueron revisados y verificados los documentos durante esta fase?

Si NO

OBSERVACIONES

S FASE: POSTMORTEM Se realiz el cierre de formato PSP de acuerdo al ciclo programado Se realizo el cierre del formato TSP del ciclo Se obtuvieron los valores de tiempo, esfuerzo, recursos financieros El anlisis de los resultados obtenidos vs estrategias utilizadas se hizo por todos los integrantes? Se documento las conclusiones del ciclo presente I

N O

OBSERVACIONE S

155

SE hizo la entrega oportuna de la documentacin final por parte de todos los integrantes del equipo? Verificacin de la documentacin a entregar Realizacin del CHECKLIST de postmortem.

Ejemplo (Continuacin) 5.- Los integrantes del equipo al concluir la fase de postmortem y observar los datos recolectados, as como los tiempos aportados, y las diferencias obtenidas, podrn replantear estrategias para un nuevo ciclo de desarrollo y documentar aquellas experiencias (lecciones aprendidas) que tuvieron durante el primer ciclo y ciclos siguientes. Todas las fases se repiten para cada ciclo, para un semestre normal de 16 semanas pueden dividirse en 2 ciclos de 8 semanas de desarrollo o en pequeos ciclos de 4 semanas (en productos de software no grandes). La finalidad de aplicar estos formatos es nicamente que el estudiante pueda controlar sus procesos de desarrollo, documentarlos y aprender de l mismo cmo puede mejorarlos, y cmo puede trabajar en un equipo efectivamente.

156

Anexo 4 Entrevistas realizadas a profesionistas del rea de calidad y desarrollo de software.

Durante el periodo de recabar informacin para el texto presente, se present la oportunidad de platicar y entrevistar a profesionistas del rea de calidad o desarrollo de software. Quise incluir en este anexo, algunas de estas plticas a modo de conclusin, ya que existen numerosos libros, revistas, artculos y referencias, pero sin embargo es importante considerar la experiencia que se vive diariamente o que se ha acumulado por parte de quienes son responsables directos de aplicar las normas, prcticas, modelos, etc., que aqu se han mencionado. Entrevista a Mario Segura Velazquez
Mario Segura Velazquez Es Ingeniero Mecnico elctrico, egresado de la Escuela Nacional de Estudios Profesionales Aragn ENEP Aragn UNAM, de 2001 a 2005 fungi como instructor de calidad y mejora continua de la empresa Coordinados de Mxico Oriente de una de las empresas del Grupo ADO. Actualmente es Promotor de Calidad y Mejora Continua de la empresa ADQUEM (empresa de desarrollo de software a la medida). __________________________________________________________________ ERG: Cmo defines el trmino Calidad? MSV: Calidad es una cultura que nos permite realizar y ofrecer servicios y productos cumpliendo con los requerimientos del cliente ERG: Crees que la calidad sea una cuestin de percepcin que tiene finalmente el cliente? Es slo una parte, el que el cliente perciba que est bien hecho con lleva a que se estn cumpliendo con los procesos y mtodos que definen la realizacin de un producto y un servicio, por eso podemos hablar de mala calidad, mediana calidad, alta calidad. ERG: La calidad tiene que ver con el proceso de elaboracin del producto o servicio?

157

MSV: Absoutamente. ERG:Quien define entonces la calidad: el proceso, el cliente...quien o qu? MSV: Bueno si es desde ah, tienes que irte desde mucho ms atrs, desde lo que vas a ofrecer un servicio y un producto, verificar los requerimientos de ese servicio y producto, en base a un estudio de mercado, definir un proceso, aplicarlo, detectar reas de oportunidad y mejorarlo. Es todo un ciclo como el PHVA (Planear-Verificar-Hacer-Actuar) de Deming. Se realiza el anlisis de una necesidad, luego la construccin de un proceso que satisficiera esa necesidad, la deteccin de reas de oportunidad, y la mejora del mismo para cumplir con esas necesidades del cliente ERG: Hay autores que dicen que quien define la calidad es el cliente, otros dependiendo de cmo es realizado hacia el proceso y otros mas hacia el cumplimiento de normas ya preestablecidas. Qu opinas de eso? MSV: Yo voy mas a un anlisis de las necesidades del cliente y si es as lo define el cliente no podemos construir ni ofrecer lo que no van a compara o no usarn. ERG: Siendo as, Podramos decir que se cumple aquello de "al cliente lo que pida" y traducirlo a que "si hacemos lo que el cliente pidi tenemos un producto o servicio con mas calidad"? MSV: Si cumple con la satisfaccin del cliente, s. Por ejemplo: si te atienden bien... Estas contenta?, si compras algo que funciona ... Estas conforme?

ERG:Que importancia tiene entonces la calidad para los procesos de desarrollo de software? MSV: Mucha y no creo que solo sea para procesos de software es para cualquier proceso en general. ERG: Consideras que la Calidad solo un termino de moda? MSV: Bueno en realidad creo que la actualidad, se entiende por moda de que las empresas solo quieren obtener certificados de diestra a siniestra: ISO 9001,CMMI nivel de madurez 5, Six Sigma, TIL Cobit, y un sin numero de certificaciones que hay, porque creen que les da prestigio, y si lo da, pero de nada les sirve tener un certificado en lo que quieran sino mejoran sus procesos e implementan una cultura de calidad cuando salga una nueva norma, como "esta de moda", la tomas y consigues el certificado,lo compras y descuidas el proceso. ERG: El contar con un certificado de calidad asegura que tu proceso de desarrollo es correcto, eficiente? MSV: No, el tener un ttulo Te asegura que eres un buen ingeniero? Un doctor en calidad puede ser muy bueno en la teora, Pero lo ser en la prctica? Conseguir una certificacin es fcil, mantener el sistema de calidad es diferente ERG:Cuales serian los cuidados, por as decirlo que deben considerar las empresas para mantener su sistema de calidad?

158

MSV: Compromiso de la direccin, anlisis de fortalezas y debilidades, documentacin de procesos, capacitacin del personal, comit de seguimiento, tener un mtodo de recabar quejas y sugerencias, y un plan de comunicacin adecuado. ERG: Para la industria mexicana Qu tan difcil ha sido entrar a todo esto de la calidad a comparacin de otras industrias como la India, EU, Union Europea? Influye la cultura? MSV: Observo la resistencia al cambio, a la gente no le gusta mejorar quiere seguir haciendo lo mismo, le da miedo. ERG: Consideras que el mexicano es conformista por no querer mejorar? MSV: S en el sentido de que no tenemos planeacin, si no hay planeacin no hay objetivos, si no hay objetivos no hay metas, y sin metas no hay acciones. ERG: y Visualizas alguna ventaja que tengamos? MSV: Muchas. Tenemos recursos, gente, es un buen principio. ERG: A que te refieres con recursos y gente? Qu es lo que ves en ellos? MSV: En que en Mxico tenemos medios al alcance de la tecnologa, conocimientos los hay, y hay personas con hambre de mejorar, pero en ocasiones nosotros mismos nos ponemos el pie. ERG: Cuntas PYMES que inician en Mxico logran sobrevivir sin una cultura de calidad? MSV: La vida de una PYME sin esas condiciones es de 2 aos, por falta de planeacin. ERG: Falta preparacin en este rubro? MSV: Bastante. En s desde las bases en la ecuacin primaria. Hablamos de Calidad Educativa, Calidad de vida, utilizamos mucho la palabra calidad pero no le damos el sentido verdadero. ERG: Ya que lo has mencionado, Que relacin existe entre la calidad de vida y la calidad del producto o servicio que puede ofrecer una persona? MSV: Mucha. Si la gente no est satisfecha con su trabajo, no lo har bien y eso afecta a la calidad de lo que hace u ofrece. ERG: Y que pasa para un profesionista? MSV: Pasa lo mismo, si no ests contento con tu trabajo y las condiciones del mismo no son las mejores, no lo realizas bien. ERG: Existen otros factores, adems del trabajo que puedan afectar a la calidad del servicio o producto que ofrece una persona? MSV: S, una remuneracin justa y equitativa, un ambiente de trabajo agradable, un desarrollo profesional, un reconocimiento de su trabajo, una retroalimentacin de lo que hace. Si no hay eso, esta desmotivado y no hace bien su trabajo, sea el trabajo que sea o la actividad que realice.

159

ERG: Por ltimo,Qu recomendaciones haras para adentrarse a estos temas de calidad: para los estudiantes quienes se estn preparando en alguna profesin y para las industrias (cual sea su tamao) que desean iniciar alguna certificacin? MSV: Para los estudiantes inculcarles que los conocimientos sin un enfoque a la planeacin y mejora de las cosas no sirven de nada. Y a las industrias el compromiso de impulsar la mejora de sus productos y servicios pero mejorando la calidad de vida de sus colaboradores.

ENTREVISTA CON DR. LUIS CARLOS VARGAS HERRING

Luis Carlos Vargas Herring es Dr. En Sistemas computacionales (Sistemas Distribuidos) egresado de la Universidad de Cambridge, estudi su maestria en Sistemas Computacionales en la Universidad de Essex, y la carrera de Ingeniero en Sistemas Computacionales en el Tecnologico de Celaya. Cuenta con las certificaciones MCSD(Microsoft Certified Solution Developer), MCDBA(Microsoft Certified DataBase Administrador), ha trabajado como Technical Leader en General Electric Treasury Sistem , Software Developer en GMatrix y actualmente se desempea como Program Manager en SQL Server en Microsoft En Estados unidos.

________________________________________________________
ERG: Como podras resumir tu experiencia en el desarrollo de productos de software? Ha cambiado o mejorado? LCVH: Cada vez ha sido ms estructurada, con ms normas y cada vez ha sido ms dinmica. Me he tenido que adaptar mas rpido Cuando empezaba a trabajar en Mxico, no haba divisin de roles, as que empec realizando varios roles o tareas pero en s no haba una clasificacin de los roles que deba fungir. Tampoco haba normas que seguir, as que yo me encargaba de la calidad del producto. Mas tarde en GE haba mas estructura, ya que me toc los roles de desarrollador y tester para asegurar la calidad, el diseo ya estaba en base de los requerimientos y tenamos junta con los analistas de negocio quienes decidan cuales eran las caractersticas que deba tener el software, en juntas platicbamos que caractersticas deba tener el producto. As que cuando se empezaba a desarrollar ya tenamos una idea mas clara sobre lo que se quera hacer, incluso se tenan algunos procesos ya identificados y existan patrones a seguir para el desarrollo, recomendaciones a seguir, y esto nos servia como una gua para el mismo desarrollo. En cuanto al testing, no haba mucho proceso, el desarrollador hacia las pruebas y se pona en lugar del usuario, as que ah si faltaba definir mas cosas. Ya una vez que el software estaba probado, exista ya documentacin para realizar el montaje del producto en los servidores, de forma que si haba alguna duda o error se poda consultar esta documentacin, este proceso se deba hacer con mucho cuidado. De aqu y despus de mi doctorado mi experiencia hasta ahora ha sido en Microsoft, en donde existe un mayor numero de procesos ya definidos desde el diseo de software, en el desarrollo si hay un conjunto de practicas que se deben seguir as como un conjunto de herramientas, por ejemplo hay herramientas para el control del mdulo para asegurar que los mdulos no se vean afectados unos al otro. El testing es completamente estructurado, est el lder de proyecto, cuya funcin es decidir cual es la siguiente versin del producto a realizar, teniendo informacin de nuestros clientes, de otros productos o referencias en revistas, esto es para hacerlo mas competitivo en el mercado. El lder decide la funcionalidad que va a tener el producto de software y el criterio

160

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

161

ERG:Te ha pasado? LCVH:No, generalmente tiendo a ser estricto con las fechas y mas bien me ha pasado de estar un poco mas tarde. ERG: Con lo que me has dicho, me quedo con la idea de que en Microsoft el desarrollo de producto es mas estructurado ya que hay procesos roles y actividades bien definidas, adems hay un elemento consejo que cuida estos procesos , Ellos mismos cuidan la calidad del producto y el proceso para obtenerla? LCVH:Bueno la calidad es responsabilidad de cada uno de los grupos de hacerla, y el consejo por decirlo as es quien revisa. ERG: Cmo le haces para obtener un producto de calidad? LCVH: Yo creo que la calidad depende de 2 aspectos. Para mi es hacer lo que me indican los requerimientos en el tiempo en el que se plane, yo no creo que hacer calidad sea hacer el producto que tenga la mayor cantidad de caractersticas o hacer un producto perfecto sin ningn error. Como se logra? Teniendo buenas especificaciones, buenos diseos y un buen equipo. Los documentos se pueden cambiar fcil pero una vez escrito el cdigo, eso es lo mas caro a cambiar. Yo creo que el tener especificaciones claras y que todo mundo est de acuerdo eso te da casi el 80% de xito del proyecto. ERG: A travs de todo este tiempo Qu mejor producto o para lograr esa calidad? prcticas te han servido para obtener un

LCVH: Lo primero y lo principal es entender los requerimientos del cliente. Eso desde la escuela nos lo han dicho pero a veces se olvida. Bsicamente como desarrollador de software queremos hacer lo que creemos que es la mejor solucin, pero el cliente tiene su propia concepcin que incluso puede llegar a ser mas simple de lo que nosotros pensbamos. Tienes que estar en contacto con el cliente, por ejemplo mientras escribo las especificaciones funcionales yo hago juntas o tengo llamadas telefnicas cada 2 semanas para asegurarme de que lo que estoy planeando, lo que estoy diseando es lo que ellos realmente quieren. Tambin es importante especificar claramente las fechas de cuando se va a revisar el avance del proyecto y qu es lo que se va a revisar, dependiendo que tan grande es el proyecto puede ser cada 3 semanas o cada mes, pero debe reunirse todo el equipo y preguntarse si en el punto en el que estn es el punto que originalmente pensaron que debieron estar. ERG: Tu recomendaras entonces que existan puntos de control del producto? revisiones continuas a manera de

LCVH: Si, obviamente es un balance, no quiere decir tener juntas cada semana porque es tiempo perdido de desarrollo y tester. Yo procuro tener juntas cada 3 semanas, y otra cosa importante es tratar de ser totalmente abiertos con el equipo. Por ejemplo si el desarrollador tiene alguna duda que l mismo lo platique con su equipo; yo tengo 4 desarrolladores y si alguno tiene un problema grave, por ejemplo un cdigo que no puede resolver, entonces que en lugar de que se pase todo el da tratando de resolver el problema l solo, tenemos la poltica de que l debe enviar un mail a todo el grupo desarrollador y si alguien ya ha tenido un problema similar entonces trata de ayudarle, de esa forma no se pierde tiempo. ERG: Entonces el trabajo en equipo es esencial para el desarrollo del producto?

162

LCVH: Si. ERG:Qu recomendaciones que tu haras para que quienes van empezando a desarrollar software, a quienes estn estudiando? LCVH: Prctica. La prctica les va a ayudar, hay obviamente ciertos mecanismos en la carrera donde puedes practicar como son las residencias, pero si se quieren dedicar a la industria de software que entonces tomen sus residencias en una empresa dedicada al desarrollo de software sino van a estar perdiendo su tiempo. Y lo otro de eso, antes de eso hay muchos proyectos de Open Source, de cdigo libre que estn abiertos para que los que quieran pueden participar colaborando con ellos, ellos cuentan con una estructura de cmo trabajar, hay personas que se encargan de revisar cdigo, otras dar consejos sobre cmo codificar, otras de cmo disear para las prximas versiones. Que busquen que es lo que quieren hacer, hay de todo, desde videojuegos hasta pginas web, pero tambin lo pueden hacer en su tiempo libre para que vayan agarrando prctica de cmo debe trabajarse en equipo.

163

Anexo 5 Referencias
Apuntes para anlisis de sistemas Mara N. Moreno Garca Departamento de Informtica y Automtica Universidad de Salamanca Calidad en el Software Memoria de Experiencia Profesional, Mara del Roco Patio Palacios, ITCelaya, Junio 2004. Capital humano y conciencia de calidad Matas Sales, Portal de estudiantes de RRHH, Universidad Champagnat, Argentina matiassalesarrobauch.edu.ar CMM y la calidad en el desarrollo de software Innevo www.innevo.com, junio 2009 Garanta de la calidad de software Basado en CMU/SEI-93-tr-25 Traduccin de SET consultores. Versin 1.3 no liberada. Gestion de la calidad Humberto Crdenas Sierra 21 Feb 2005, curso en lnea www. mailxmail.com Guia Tecnica para la evaluacion del software Carlos Alberto Largo Garcia, Erledy Marin Mazo, 1.Edicion. www.puntoexe.com.co, 2005 Ingeniera del Software, un enfoque prctico Pressman, R. S. 6 Edicin. Mc Graw Hill, 2005. 164

7 8

10

Ingeniera del Software Ian Sommerville 7a. Edicin Pearson Educacin, SA, Madrid 2005 Iniciativa Nacional TSP/PSP Beatriz Velazquez Soto, SoftwareGuru, 31 julio 2008 2008 SG Software Guru

11

ISO/IEC 15504 (SPICE) Modelo de Evaluacin, Mejora y capacidad de Software Carmen Golobart, Prisma Calidad y Medio ambiente consultores, Espaa. 21 abril 2009. La calidad del software y su medida Jess M. Minguet Melian, Juan Francisco Hernndez Ballesteros , Editorial Centro de Estudios Ramn Areces, S.A. Espaa. Manual de Calidad ISO 9001 para Negocios Pequeos Quality Sistems Innovations, Inc. http://www.qsinnovations.com/iso9001espanol.htm , Mejoramiento de los procesos de software Luciano Guerrero, http://www.geocities.com/SiliconValley/Lab/3629/mejorami.htm 2000 Modelo de procesos para la industria de Software Hanna Oktaba, Claudia Alquicira Esquivel, Anglica Su Ramos Ver 1.3 Agosto 2005, Secretaria de Economa Mxico. Modelo de Procesos Fanny Ruiz Castro. Presentacin mundial de la versin en espaol del CMMI SG Software Guru - 15 de septiembre de 2009 2009 SG Software Guru Procesos de Software Mara Ruvalcaba 165

12

13

14

15

16

17 18

SG Software Guru 16 de marzo de 2009 2009 SG Software Guru

19

20

Roles en el desarrollo de software David Fuller Padilla Escuela de Ingeniera Civil Informtica Universidad Catlica del Maule Chile www.eici.ucm.cl Tcnicas cuantitativas para la gestin en la Ingeniera de Software Tuya Javier, Ramos Romn Isabel, Dolado Cosn Javier NETBIBLO editorial 2007, Espaa. The Capability Maturity Model for Software Mark C. Paulk, Software Engineering Institute Carnegie Mellon University
Pittsburgh, PA 15213-3890

21

22

The Capability Maturity Model Medellin Janzel Proyecto de Fomento a la industria de software en el Estado de Guanajuato, Mxico . Un enfoque actual sobre la calidad del software Informe tcnico Oscar M. Fernndez Carrasco, Delba Garca Len y Alfa Beltrn Benavides. ACIMED 3(3):40-42, septiembrediciembre, 1995 cmm-cmu-sei-tr24-93 (CMM 1.1) cmm-cmu-sei-tr25-93 (Key pract.)

23

24 25

166

167