CONTENIDO PÁG. CONTENIDO ..................................... ........................................................................... .................................................. ............ 1 Introducción .................................... .......................................................................... .................................................. ............ 3 1 Conceptos Básicos de Calidad ......................................................... ......................................................... 4 1.1 Definición de la calidad. .................................. ................................................................. ............................... 4 1.2 Definición de calidad de software. ............................... ................................................... .................... 5 1.3 ¿Quién define la calidad? ...................................... ............................................................... ......................... 6 1.4 Importancia de la calidad. ............................................................. 9 1.5 La calidad y el mundo globalizado ............................... ................................................. .................. 12 1.6 Calidad de vida. vi da. ......................................................................... ......................................................................... 14 1.7 Calidad Total .................................... .......................................................................... .......................................... .... 16 1.8 Preguntas de repaso y prácticas sugeridas. ............................... .................................... ..... 19 2 Aseguramiento As eguramiento de la Calidad del Software S oftware (SQA) ......................... 21 2.1 Relación Rel ación de la l a Ingeniería Ingenierí a del Software con SQA. ............................. 22 2.2 Definición y propósito del SQA. .................................................... .................................................... 24 2.4 Calidad Cali dad del software en el ciclo de vida del mismo .......................... 26 2.5 Roles y responsabilidades de los equipos de desarrollo. ................... 31 2.6 Habilidades y capacidades del personal del SQA ............................. ............................. 37 2.7 Actividades del SQA. ...................................... ................................................................... ............................. 40 2.8 Métodos y herramientas. ...................................... ............................................................. ....................... 41 2.9 Enfoque de Procesos en el Desarrollo de software ........................... 43 2.9.1 Definición de Proceso y Enfoque de procesos ............................ 44 2.9.2 Capacidad Capaci dad de proceso de software .......................................... 47 2.9.3 Madurez del proceso de software ............................................ ............................................ 47 2.9.4 Modelos de proceso PSP y TSP ...................................... ................................................ .......... 47 2.10 Preguntas de repaso y prácticas sugeridas. .................................. 56 3 Estándares de calidad aplicados al software. ................................ 58 3.1 ISO.................................... .......................................................................... ....................................................... ................. 58 3.1 SPICE ....................................................................................... ....................................................................................... 62 3.3 CMM (Capability Maturity Model.......................................... Model.................................................... .......... 73 3.3.2 Nivel inicial i nicial .......................................................................... .......................................................................... 79 1
3.3.3 Nivel repetido ................................... ....................................................................... .................................... 81 3.3.5 Nivel administrado. .......................................................... ............................................................... ..... 89 3.3.6 Nivel optimizado. ................................................. .................................................................. ................. 91 3. 4 MOPROSOFT ................................... ......................................................................... ........................................ .. 103 10 3 4 Calidad enfocada al desarrollo de software. ................................ 123 4.1 ¿Qué es la calidad del software? ................................... ................................................. .............. 123 4.2 Cómo obtener calidad de software. ..................................... ............................................. ........ 124 4.3 Cómo controlar la calidad cali dad del software. ..................................... ....................................... .. 125 4.4 Costo de la l a calidad del software. ................................................ ................................................ 126 4.5 Nomenclatura y certificación ISO 9001:2000 9001:2 000................................ 129 4.6 La norma ISO/IEC 9126 91 26 ............................................. ............................................................ ............... 134 4.7 Análisis de factores que determinan la l a calidad del software............ 136 4.8 Análisis del proceso del ciclo cicl o de vida del software ......................... 138 4.9 Funciones de evaluación del software .................................. .......................................... ........ 139 4.10 Preguntas de repaso y prácticas sugeridas. ................................ 144 ANEXOS .................................... .......................................................................... ..................................................... ............... 145 Anexo 1: Tareas por roles y fases de desarrollo desarroll o ................................. 145 Anexo 2 Formato para planeación plan eación y registro de tiempo individual ......... 151 Anexo 3 Formato auxiliar para postmortem y lecciones l ecciones aprendidas. ..... 152 Anexo 4 Entrevistas realizadas a profesionistas del área de calidad y desarrollo de software. .................................................... ................................................................... ............... 157 Anexo 5 Referencias ..................................... ....................................................................... .................................. 164
2
Introducción La calidad de los productos y servicios de software son una necesidad creciente para todo tipo de usuarios de los mismos; por lo tanto es un factor de competitividad de las empresas que los desarrollan y ofrecen ya que han de satisfacer las necesidades de sus clientes, no sólo para continuar en el mercado, sino, además para conseguir la superioridad, el liderazgo como una meta empresarial. La industria de software es un sector donde el concepto de calidad total ha generado la revolución más radical, siendo la producción industrial de software una actividad con alta participación de recursos humanos, cien por ciento intelectual y en cierto sentido sin insumos ni materias primas. Existen desarrolladores quienes continúan creyendo que la calidad es algo en lo que se debe comenzar a preocupar hasta después de que se ha generado el código pero hay que tomar conciencia que la calidad se aplica a lo largo del proceso de software. En el texto que se presenta a continuación continuación trata de auxiliar a los estudiantes y docentes de nivel superior a comprender los principales conceptos relacionados con la calidad de software y los estándares definidos a nivel nacional e internacional.; para que a su vez puedan ser aplicados en los proyectos en los que se contemple el desarrollo de software. Agradezco las colaboraciones de la empresa ADQUEM, a Luis Carlos Vargas Herring (Microsoft USA), José Arturo Mora Soto (Universidad Carlos III España), María del Rocío Patiño Palacios (IMB Gdl. México), Fernando Nuñez Rojas (ITESI), Julio Armando Asato España (ITC), todos ellos exalumnos del Instituto Tecnológico de Celaya, quienes me brindaron su apoyo y experiencia para elaborar el presente texto. 3
1 Conceptos Básicos de Calidad
1.1 Definición de la calidad. Para comprender lo que es la calidad de software, debemos definir primeramente los conceptos ―calidad‖ y ―software‖ Software: El software es un elemento lógico, en lugar de físico, de un sistema, por lo tanto tiene características diferentes a las del hardware, para este primer capítulo y para compenetrarlo mejor con el concepto de calidad, definamos que el software es un producto especial, el cual se desarrolla, se construye a la medida para satisfacer la necesidad de un cliente o usuario. Calidad: El término calidad por si mismo, es subjetivo, ¿Qué quiere decir esto? Que si quisiéramos definirla se obtendrían opiniones distintas, ya que un producto o servicio puede ser juzgado de manera diferente dependiendo de la percepción de cada persona, de la educación que tiene, su edad , experiencia, aspectos emocionales o estados de ánimo entre otros factores.
Una definición de la misma podrá ser: “La totalidad de características de un producto o servicio que se refieren a su
habilidad para satisfacer necesidades establecidas o implicadas.”
4
1.2 Definición de calidad de software. La calidad del software se define como: Concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente.
La definición anterior sirve para enfatizar tres puntos importantes:
1. La falta de concordancia con los requerimientos es falta de calidad. 2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. 3. Al no seguir esos criterios, casi siempre se dará una falta de calidad. Existe un conjunto de requerimientos implícitos que a menudo no se mencionan (p. ej. Tener un buen mantenimiento). Si el software se ajusta a sus requerimientos explícitos pero falla en alcanzar los requerimientos implícitos, la calidad del software queda en entredicho. El American Heritage Dictionary define Calidad como ―una característica o atributo de algo‖. Como atributo de un elemento, la calidad se refiere a
características mensurables, es decir: cosas que se pueden comparar para conocer
estándares,
como
longitud,
color,
propiedades
eléctricas
y
maleabilidad, sin embargo el software, principalmente una entidad intelectual, es más difícil de caracterizar que los objetos físicos. 5
Cuando se examina un elemento con base en sus características mensurables se pueden encontrar dos tipos de calidad: calidad de diseño y calidad de concordancia. La calidad de diseño se refiere a las características que los diseñadores especifican para un elemento. La calidad de concordancia es el grado en el que las especificaciones de diseño se aplican durante la fabricación. En el desarrollo de software, la calidad del diseño incluye requisitos, especificaciones y el diseño del sistema, La calidad de concordancia es un tema enfocado principalmente en la implementación. Si ésta sigue el diseño y el sistema resultante satisface sus requisitos y metas de desempeño, la calidad de concordancia es alta.
1.3 ¿Quién define la calidad? Debe entenderse que en cuestión de la percepción del servicio o producto final, el usuario es quien define la calidad; debiendo la empresa complacer a los clientes, y no contentarse sólo con librarlos de sus problemas inmediatos, sino ir más allá para entender a fondo sus necesidades presentes y futuras, a fin de sorprenderlos con productos y servicios que ni siquiera imaginaban. Este conocimiento ya no debe ser sólo del dominio exclusivo de grupos especiales de una organización; sino que debe ser compartido y desarrollado por todos los empleados. Una empresa que define la calidad sin tomar en cuenta a los consumidores corre con el riesgo de producir bienes y servicios con escasa o nula demanda, ya sea porque los clientes tienen otras expectativas y necesidades, o bien porque los competidores están generando bienes con un mayor valor agregado. Por tales motivos es esencial para las empresas practicar tanto la investigación de mercado, como la inteligencia competitiva y una evaluación comparativa. 6
Conocidos los deseos y necesidades de los consumidores, estos deben ser traducidas en términos cuantitativos y tangibles. Este proceso de traducción no es sencillo y requiere de la integración de conocimientos de mercadotecnia con ingeniería y administración, para que las necesidades del consumidor y las expectativas que desarrolló durante el proceso de selección del producto, puedan ser satisfechas completamente. Entre la técnica más importante para tales fines tenemos el Despliegue de la Función de Calidad (QFD), el cual sirve para realizar todo este proceso de traducción, ayudando a que la voz del cliente se despliegue a través de toda la organización. La función de despliegue de la calidad tiene como objetivo asegurar que se cumplan las expectativas del cliente desde el diseño del producto, durante su proceso de manufactura, y hasta que es utilizado por el consumidor. En japonés se le llama ―ten-kai‖ lo cuál significa ―despliegue‖, refiriéndose a la idea de llevar las necesidades y expectativas del cliente expresados en su lenguaje (voz del cliente) a todos los involucrados en la organización, e ir en Cada etapa ―traduciéndolas‖ al lenguaje apropiado. Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. La calidad del software la define o avala una Gestión de la calidad del software por ejemplo: ISO 9000, esto como política de calidad, se entiende como un conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos, el control de la calidad. Algunos de varios estándares para software provienen de ISO 9000 quien rige la calidad mundial. En seguida se muestra una tabla con los diversos estándares ISO, en capítulos posteriores hablaremos de ISO y otros estándares a nivel nacional e internacional.
7
ISO/IEC 9126 – 1 ISO/IEC TR 9126 – 4 ISO 9241 – 11 Especificaciones ISO 20282 ISO/IEC TR 9126 – 2 Especificaciones ISO 9241 ISO/IEC TR 9126 – 3 Especificaciones ISO/IEC 10741 – 1 ISO 9241
Ingeniería de Software - Calidad de producto- Modelos de calidad. Ingeniería de software - Calidad de producto- Calidad en métricas de uso. Guías en Usabilidad. Usabilidad en productos de cada día. interfaz e interacción Ingeniería de software- Calidad de producto- Métricas externas. Requisitos ergonómicos para trabajo en oficinas y terminales de trabajo. Ingeniería de software- Calidad de producto- Métricas internas. Interacción de Diálogo - Control del cursor en edición de textos. Requisitos ergonómicos para oficinas con terminales visuales.
Especificaciones Iconos, símbolos y funciones. ISO/IEC 11581 ISO 11064
Diseño ergonómico para centros de control.
Especificaciones Requisitos ergonómicos de trabajo de paneles planos. ISO 13406 ISO 14915
Ergonomía de software para interfaz multimedia.
Especificaciones Interfaz de escritura manual. Interacción ISO/IEC 14754 IEC TR 61997
Guías de interfaz de usuario en equipos multimedia de uso general.
Especificaciones Interfaz de usuario para dispositivos móviles. ISO/IEC 18021 ISO 18789
Requisitos ergonómicos y sistemas métricos para pantallas. Documentación
8
ISO/IEC 18019 Especificaciones ISO/IEC 15910
ISO 13407
Guías para el diseño y preparación de documentación de software de usuario. Documentación de procesos de software. de usuario proceso de desarrollo
Diseño de procesos interactivos. Evaluación de software.
ISO/IEC 14598 ISO TR 16982 ISO TR 18529
Métodos de soporte de diseños centrados en usuarios. capacidad de la empresa Procesos descriptivos de vida de producto, otros ISO Introducción general.
ISO 9241 – 1 Guía en requisitos de acciones. ISO 9241 – 2 Principios ergonómicos de carga mental, términos y definiciones. iSO 10075 – 1 Guía de accesibilidad en interfaz de usuario. iSO DTS 16071
1.4 Importancia de la calidad. Es posible hacerlo bien a hacerlo de nuevo otra vez, si un equipo de software subraya la calidad en todas las actividades de ingeniería del software, ello reduce la cantidad de reelaboración que se debe realizar además de los consecuentes beneficios que se pueden obtener como a continuación se describe. 9
BENEFICIOS PARA LOS CLIENTES
•
COSTO DE OPORTUNIDAD CONTROLADO
Dependiendo de la importancia de la aplicación solicitada, no contar con la misma en el momento previsto, puede ocasionar pérdidas considerables, tanto económicas como de imagen.
•
EFICIENCIA EN LA OPERATORIA DEL DÍA A DÍA
Contar con una aplicación desarrollada bajo estándares de calidad asegurados, garantiza la estabilidad del software, evitando interrupciones en las actividades del negocio por defectos del sistema.
•
AUMENTO EN LA PRODUCTIVIDAD
Una aplicación bien diseñada y desarrollada, facilita las actividades de trabajo diarias, aumentando la productividad en tareas administrativas, productivas y de control entre otras.
•
REDUCCIÓN EN LOS COSTOS OPERATIVOS
La implementación de software de calidad, evita costos asociados a eventos tales como caídas del sistema, demoras en la atención a clientes, pérdidas de información vital del negocio.
10
PARA EL ÁREA DE IT
•
REDUCCIÓN DE COSTOS DE DESARROLLO
Principalmente costos asociados a la no calidad, que se traducen en muchas horas dedicadas a corregir errores de aplicaciones que ya está en producción, necesidad de más recursos humanos para poder cumplir con los plazos establecidos para la finalización de los proyectos y, quizás el más grave, pérdidas económicas a nivel negocio por errores funcionales y conceptuales en las aplicaciones.
•
CLIENTES INTERNOS SATISFECHOS
Porque entregar software en tiempo y alineado con las expectativas del cliente o usuario, genera una imagen de profesionalismo del área de IT y trasmite confianza al resto de la organización.
•
MAYOR DISPONIBILIDAD DE RECURSOS HUMANOS
Porque al eliminar los tiempos invertidos en volver a realizar el trabajo, por cuestiones asociadas a la no calidad, baja considerablemente el número de horas invertidas en cada proyecto, liberando anticipadamente los recursos asignados a un determinado proyecto y dejándolos disponibles para comenzar los próximos.
•
MEJOR ORGANIZACIÓN E INTEGRACIÓN DE LOS EQUIPOS DE TRABAJOS
Desarrollar software en base a un proceso estandarizado y repetitivo, permite controlar eficientemente varios equipos de trabajo.
11
1.5 La calidad y el mundo globalizado En un contexto dinámico y competitivo, la Calidad se ha convertido para las organizaciones actuales en uno de los pilares para alcanzar el éxito. Y el talento que reside en el Capital Humano de las organizaciones resulta fundamental para hacer realidad los programas de Calidad El mundo globalizado ha permitido que la competencia y el flujo de conocimiento se incrementen en un ritmo vertiginoso, lo que ha traído aparejado una evolución del cliente, quien hoy por hoy es mucho más exigente que en tiempos pasados. Ante este panorama, las organizaciones han adoptado a la Calidad como una respuesta al entorno en el que se encuentran inmersas, como una forma de mantener la competitividad y elevar la productividad, maximizando su rentabilidad. Términos como Excelencia, Calidad Total, Mejora Continua, Satisfacción del Cliente y otros se han convertido en vocabulario habitual de quien forma parte de una organización. Diversos autores han definido a la calidad de diferentes maneras, pero la gran mayoría coincide en un punto fundamental: Calidad en una organización supone el cumplimiento de ciertos requisitos, los cuáles son determinados en función de las necesidades del cliente. Una organización que administra un Sistema de Calidad recoge información acerca de las necesidades del cliente, la registra y procesa, obteniendo los resultados necesarios que le permiten tomar decisiones concernientes a la modificación de sus prácticas actuales para adaptar su producto/servicio a lo que verdaderamente requiere el cliente. Estas prácticas son evaluadas mediante la utilización de índices que miden los resultados de la organización en varios de sus procesos, ya que el
12
principio fundamental de la Calidad es que no se puede mejorar lo que no se puede medir. Una organización que se introduce en el tema de la Mejora Continua y la Calidad define una estructura organizativa para tal. De esta manera, comienza con la concepción de una Visión, punto de partida para la generación de la Conciencia de Calidad. Esto plantea el requisito fundamental de contar con el compromiso de quienes toman decisiones dentro de la organización. En otras palabras, los esfuerzos para adoptar la Gestión de Calidad Total son inútiles si la alta dirección no está comprometida. Con el compromiso gerencial, la organización está en condiciones de transferir la Visión de Calidad hacia todos los niveles de la organización, definiendo una Misión, políticas, sistemas y programas de calidad. Esto plantea la necesidad de ―educar‖ a los recursos humanos transfiriendo los
valores, factor imprescindible para instalar un modelo de gestión de estas características en cualquier organización. Por esta razón, la Calidad está estrechamente relacionada con el capital humano de una organización: no puede haber calidad si no se cuenta con recursos humanos de calidad. En otras palabras, una organización no podrá obtener productos o brindar servicios de calidad, sino cuenta con calidad humana. Cuando hablamos de calidad humana nos referimos al Talento, elemento fundamental que debe poseer todo recurso humano que forme parte de una organización. El talento de los recursos humanos está dado por una serie de factores como la capacitación, sus valores, el potencial, su sentido de responsabilidad, etc. De esta manera, una organización que posee un capital humano de calidad (recursos humanos talentosos) y ha creado una conciencia de calidad entre los mismos, puede decirse que es poseedora de una ventaja competitiva muy importante.
13
Una organización solo puede considerarse de Calidad cuando está compuesta por personas de Calidad, quienes aplican los valores de trabajar en equipo, actuar con prevención, planificar bien para ejecutar mejor, aprender y desarrollarse, comunicarse con eficacia, enfocarse a servir a sus clientes y mejorar continuamente. Una organización de estas características adopta una cultura de confianza, lo que la lleva inevitablemente a la capacitación, al trabajo en equipo y a la auto dirección. En definitiva, Calidad implica la determinación de las actividades que se deben realizar, el conocimiento de los requisitos a cumplir, el adiestramiento sobre esos requisitos, el cumplimiento estricto de los mismos, el compromiso y predisposición positiva al trabajo y finalmente la vocación de servicio de todo el capital humano de una organización. Por esta razón podemos afirmar que la Conciencia de Calidad dentro de la organización es la base para la transformación de la organización en función de los requisitos establecidos por el análisis de las necesidades y demandas del cliente, lo cual se logra mediante el conocimiento (la Visión Compartida), el entendimiento del cliente
y
la
mejora
de
procesos.
1.6 Calidad de vida. La palabra calidad se deriva de cualidad que significa cada una de las circunstancias o caracteres superiores y excelentes que distinguen a las personas y cosas. Vida signif ica: ica: ―Fuerza interna substancial en virtud de la cual obra el ser que la posee. Conducta o método de vivir vivi r con respecto a las acciones de los seres humanos‖ .
14
La calidad de vida es un concepto que va más allá de lo físico pues implica valores y actitudes mentales. La calidad de vida es un estado positivo desde todos los puntos de vista. Es estar en la plenitud, es poder funcionar ciento por ciento.
o Físicamente, significa encontrarse en buenas condiciones, fuerte, resistente a las enfermedades o poder sobreponerse rápidamente a ellas. ella s. o Psíquicamente, es poder disfrutar, hacerse cargo de las responsabilidades, combatir la tensión nerviosa y el estrés. est rés. o Emocionalmente, es estar en paz. La persona que mantiene su calidad de vida es una persona que se siente bien, vigorosa, entusiasmada, con la sonrisa propia del que se siente bien en todas sus dimensiones. La calidad de vida es el bienestar, felicidad, satisfacción de la persona que le permite una capacidad de actuación o de funcionar en un momento dado de la vida. La calidad de vida es: "la percepción que un individuo tiene de su lugar en la existencia, en el contexto de la cultura y del sistema de valores en los que vive y en relación con sus objetivos, sus expectativas, sus normas, sus inquietudes. 15
La calidad de vida tiene su máxima expresión en la calidad de vida relacionada con la salud. Las tres dimensiones que global e integralmente comprenden la calidad de vida son:
Dimensión física: Es la percepción del estado físico o la salud, entendida como ausencia de enfermedad, los síntomas producidos por la enfermedad, y los efectos adversos del tratamiento. tratamiento. No hay duda que estar sano es un elemento esencial para tener una vida con calidad. Dimensión psicológica: Es la percepción del individuo de su estado cognitivo y afectivo como el miedo, la ansiedad, la incomunicación, la pérdida de autoestima, autoestima, la incertidumbre del futuro. También incluye las creencias personales, espirituales y religiosas como el significado de la vida y la actitud ante el sufrimiento. Dimensión social: Es la percepción del individuo de las relaciones interpersonales y los roles sociales en la vida como la necesidad de apoyo familiar y social, la relación médico-paciente y el desempeño laboral.
1.7 Calidad Total El término TQM (Total Quality Management) se acuña en 1985 para describir el estilo japonés de incremento de calidad. Representa un estilo de gestión movido por conseguir éxito a largo plazo enlazando calidad y satisfacción de usuario. Es básica la creación de una cultura en la que todos los miembros de la organización quienes participan en la mejora de procesos, productos y servicios. La adopción de ISO 9000 como estándar de gestión de calidad en la Unión Europea ilustra la importancia de esta filosofía. Ejemplos implementación exitosa de una estrategia TQM: 16
Hewlett-Packard ’s Total Quality Control (TQC): Define estrategias y planes para cada área (gestión liderazgo, cliente, participación total, etc.) para conducir un incremento de calidad, eficiencia y responsabilidad. Motorola’s Six Sigma Strategy.
Se centra en conseguir niveles estrictos de calidad para obtener la satisfacción del usuario. IBM’s Market Driven Quality.
Los elementos clave de TQM pueden resumirse en: Orientado al cliente: el objetivo es conseguir una satisfacción total del cliente. Incluye estudios de las necesidades de los clientes, recolección de requisitos de cliente, medida y gestión de su nivel de satisfacción. Procesos: el objetivo es reducir las variaciones del proceso y conseguir una mejora continua del proceso. Incluye tanto los procesos de negocio como los procesos de desarrollo del producto. A través de la mejora de los procesos se mejora la calidad del producto. Parte humana de la calidad: el objetivo es crear una cultura de calidad global a la compañía. Áreas objetivo son: dirección, participación total, otorgar poderes a los empleados y otros factores sociales, psicológicos y humanos.
17
Medida y análisis: el objetivo es conducir la mejora continua en todos los parámetros de calidad, utilizando el sistema de medidas orientadas al objetivo. Una organización que practique TQM debe tener una jefatura ejecutiva, y debe centrarse en infraestructura, entrenamiento y educación, además de realizar planificación estratégica de calidad. Se han definido varios marcos organizacionales para sustanciar la filosofía TQM: Plan-Do-Check-Act. Proceso de mejora de la calidad basado en un ciclo de retroalimentación para optimizar un único proceso de producción. Quality Improvement Paradigm (QIP). Pretende construir una organización que mejora continuamente, basándose en sus objetivos evolutivos y el aseguramiento de su estado relativo a esos objetivos. SEI Capability Maturity Model. (CMM) Proceso de mejora dividido en fases. Basado en la valoración con respecto a un conjunto áreas clave de proceso. El objetivo es el nivel 5 donde se alcanza una mejora continua de procesos. El objetivo es conseguir mejora continua de procesos mediante prevención de defectos, innovaciones tecnológicas y gestión del cambio de procesos. En capítulos posteriores se abarcará con mas detalle este modelo. Leas Enterprise Management. Basado en el principio de concentración de la producción en actividades de valor añadido.
18
1.8 Preguntas de repaso y prácticas sugeridas. 1 Buscar en Internet artículos relacionados con el arranque de un proyecto de desarrollo de software y recomendaciones dadas por las empresas o profesionistas del ramo. 2. Formar equipos en donde se asignen a los participantes distintos roles de trabajo para el desarrollo de un producto. Es importante que los integrantes de cada equipo identifiquen cuales son las tareas que les son asignadas y como se relacionan con otros roles, en que tareas tienen más habilidades y en cuales requerirán capacitación.
3. Realizar un diagrama o esquema en donde se identifiquen los procesos principales que abarcará el producto de software a construir.
4. Mediante un ejemplo ilustra el porque el concepto de calidad puede ser subjetivo. 5. Mediante un ejemplo ilustra como la calidad de vida puede influir para la construcción del software con calidad. 6. Buscar en Internet diversos puntos de vista que las empresas y profesionistas tienen acerca del concepto de calidad, calidad de software, impacto de la calidad en su calidad de vida. 7. Investigar mas sobre PSP y TSP, hacer una breve presentación indicando los beneficios que se pueden tener al aplicar estos modelos al desarrollo del software. 19
8. Investigar y hacer una presentación sobre las empresas que han implantado la filosofía TQM (calidad total) , discutir que ventajas puede representar para la industria de software. 9.
Discutir en equipo sobre la importancia de la calidad para el desarrollo de un producto de software.
10. Investigar los siguientes conceptos: Control de calidad, garantía de calidad, costo de calidad. Discuta en grupo en que fase del ciclo de vida del software se aplican estos conceptos. 11. Investigar cuales son los organismos encargados de certificar los procesos de calidad del software en nuestro país.
20
2 Aseguramiento de la Calidad del Software (SQA) La función de aseguramiento de la calidad tiene como finalidad primaria el determinar si las necesidades de los usuarios están siendo satisfechas adecuadamente. Otra de sus funciones, aunque no se tocará mucho en la presente investigación, es la de determinar los costos que puede causar el añadir ciertas características al producto, ya que tarde o temprano, la economía resulta ser un factor decisivo para obtener un producto de calidad. Para determinar si las necesidades de los usuarios están siendo satisfechas, se deben de evaluar tres áreas: Objetivos: Los objetivos de la organización son primero, luego vienen los requerimientos del usuario. Los objetivos de cualquier usuario deben de estar en armonía con los objetivos de la organización,
Métodos: Deben de utilizarse métodos que contengan u observen las políticas, procedimientos y estándares de la organización,
Ejecución: Optimización del uso de hardware y software al implementar los productos de software.
Para evaluar las áreas expuestas con anterioridad, es necesario que se cuente con un programa de aseguramiento de calidad que sea efectivo y que tenga un impacto dentro del desarrollo y prueba del producto de software final.
21
2.1 Relación de la Ingeniería del Software con SQA. El IEEE[IEEE93] define a la ingeniería del software como: “La aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento del software; es decir la aplicación de la ingeniería al software.”
La ingeniería de software es una tecnología estratificada, como se muestra en la siguiente figura: HERRAMIENTAS METODOS PROCESO UN ENFOQUE DE CALIDAD Fig. 1. Estratos de la ingeniería del software
Cualquier enfoque de la ingeniería (incluido el de la ingeniería del software) debe estar sustentado en un compromiso con la calidad. La gestión de la Calidad total, Seis Sigma y enfoques similares fomentan una cultura de mejora continua del proceso, y es esta cultura la que al final conduce al desarrollo de enfoques muy efectivos para la ingeniería del software. La base que soporta a la ingeniería del software es un enfoque en la calidad. La base de la ingeniería del software es el estrato del proceso. El proceso de la ingeniería del software es el elemento que mantiene juntos los estratos de la tecnología y que permite el desarrollo racional y a tiempo del software de computadora.
22
El proceso define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnología de la ingeniería del software. El proceso del software forma la base para el control de la gestión de los proyectos de software y establece el contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.), se establecen los fundamentos, se asegura la calidad, y el cambio se maneja de manera apropiada.
Más adelante se abordarán los temas referentes a proceso y el enfoque de procesos para de esta forma comprender mejor los enfoques de calidad que se mencionaron en el párrafo anterior. Los métodos de la ingeniería d el software proporcionan los ―cómo‖ técnicos para construir software, Los métodos abarcan un amplio espectro de tareas que incluyen la comunicación, el análisis de requisitos, el modelado del diseño, la construcción del programa, la realización de pruebas y el soporte. Los métodos de la ingeniería del soltare se basan en un conjunto de principios básicos que gobiernan cada área de la tecnología e incluye actividades de modelado y otras técnicas descriptivas.
Las herramientas de la ingeniería del software proporcionan el soporte automatizado o semiautomatizado para el proceso y los métodos. Cuando las herramientas se integran de forma que la información que cree una de ellas pueda usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software, que con frecuencia se denomina ingeniería del software asistida por computadora.
23
2.2 Definición y propósito del SQA. Antecedentes: El control y la garantía de la calidad son actividades esenciales en cualquier negocio que elabore productos de consumo. Antes del siglo XX el control de la calidad era responsabilidad exclusiva del empresario que fabricaba un producto. La primera función formal de garantía y control de la calidad la introdujeron los Laboratorios Bell en 1916 y se extendió tan rápidamente a través del mundo industrial. Durante el decenio de 1940 surgieron enfoques mas formales del control de la calidad los cuales se apoyaban en la medición y la mejora continua de los procesos como los elementos clave la gestión de la calidad. La historia de la garantía de la calidad en el desarrollo de software avanza paralela a la de la calidad en la fabricación de hardware. Durante los primeros días de la computación (décadas de 1950 y 1960), la calidad era responsabilidad exclusiva del programador. Los estándares de garantía de calidad para el software se introdujeron en los contratos militares de desarrollo de software durante el decenio de 1970 y se han extendido rápidamente en el desarrollo del software en el mundo de los negocios.
Definición y propósito: Si se extiende la definición presentada anteriormente, la garantía de la calidad del software es un ―patrón de acciones sistemático y planificado‖ que se requiere para garantizar alta calidad en el software. Numerosos participantes tienen responsabilidad en la garantía de la calidad del software: ingenieros de
24
software, gestores de proyecto, clientes, vendedores y los individuos que integran el grupo de SQA. La calidad de un producto debe asegurarse,
la Garantía de Calidad del
software SQA ( Software Quality Assurance), es una actividad de protección
que se aplica a todo el proceso de ingeniería del software, englobando los siguientes aspectos: Enfoque de gestión de calidad. Tecnología de ingeniería del software efectiva. Revisiones técnicas formales que se aplican durante el proceso del software. Estrategia de prueba multiescalada. El control de la documentación del software y de los cambios realizados. Procedimiento que asegure un ajuste a los estándares de desarrollo del software. Mecanismos de medición y de generación de informes.
2.3 Problemas que resuelve el SQA. El grupo de SQA funciona como el representante en casa del cliente. Es decir las personas que realizan el SQA deben observar el software desde el punto de vista del cliente. Existen gran variedad de tareas, realizadas tanto por los ingenieros de software como por el grupo de SQA.
Los ingenieros realizan el
trabajo técnico ,
aplicando métodos sólidos y
medidas, realizando revisiones y llevando a cabo pruebas de software.
25
El grupo de SQA realiza tareas de ayuda al equipo de ingenieros, planifican
el
proceso
de
garantía
de
calidad,
supervisión,
mantenimiento de registros, análisis e informes. Establecimiento de un plan de SQA para un proyecto. Participación en el desarrollo de la descripción del proceso de software del proyecto. Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido. Auditoría de los productos de software designados para verificar el ajuste con los definidos como parte del proceso de software. Asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con un procedimiento establecido. Registrar lo que no se ajuste a los requisitos e informar a sus superiores.
2.4 Calidad del software en el ciclo de vida del mismo Ciclo de vida del software: Aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software. (norma IEEE 1074) [IEEE, 1999] El ciclo de vida incluye: Ciclo de desarrollo del sistema y Tiempo de vida del sistema
26
Modelo de ciclo de vida: Marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso (norma ISO 12207-1) [ISO/IEC, 1995]. Objetivos Proporcionar una estrategia de desarrollo y un enfoque sistemático en la realización de las actividades de desarrollo y mantenimiento de un sistema, ayudar a fijar objetivos. Y permitir un seguimiento de las necesidades de recursos, las actividades del ciclo de vida del software se pueden agrupar de la forma siguiente (norma ISO 12207-1) [ISO/IEC, 1995]: PROCESOS PRINCIPALES Adquisición Suministro
Desarrollo
PROCESOS DE SOPORTE Documentación Gestión de la configuración
Explotación
Aseguramiento de la calidad Verificación Validación Revisión Conjunta Auditoría
Mantenimiento
Resolución de problemas
PROCESOS DE LA ORGANIZACIÓN Gestión
Infraestructura
Mejora
Formación
Fig. 2 Procesos del ciclo de vida.
27
Procesos principales: Son los que resultan útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software durante su ciclo de vida.
Actividades y tareas que se realizan para comprar un producto software. Actividades y tareas que el suministrador realiza. Contiene las actividades de análisis de requisitos, diseño, codificación, integración, pruebas e instalación y aceptación. Incluye la explotación del software y el soporte operativo a los usuarios. Aparece cuando el software necesita modificaciones, ya sea en el código o en la documentación asociada, debido a un error, una deficiencia, un problema o la necesidad de mejora o adaptación. Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida. Registra la información producida por un proceso o actividad en el ciclo de vida. Aplica ciertos procedimientos y técnicas 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 están completos y son correctos. Sirve para determinar si el sistema o software 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 una fase de un proyecto. Permite determinar, en los hitos p redeterminados, si se han cumplido los requisitos, los planes y el contrato. Permite analizar y eliminar los problemas descubiertos durante el desarrollo, explotación, el mantenimiento u otro proceso.
28
Procesos de soporte: Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida. Registra la información producida por un
:
proceso o actividad en el ciclo de vida. Aplica ciertos procedimientos y técnicas :
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 están completos y son correctos.
Sirve para determinar si el sistema o software 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 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, explotación, el mantenimiento u otro proceso.
29
Procesos de la organización (generales): Los emplea una organización para llevar a cabo funciones tales como la gestión, la formación del personal o la mejora del proceso.
Actividades y tareas genéricas que puede emplear cualquier organización que tenga que gestionar sus procesos, incluyendo planificación, seguimiento y control, y revisión y evaluación Establece la infraestructura necesaria para cualquier otro proceso. Sirve
para
establecer,
valorar,
medir,
controlar y mejorar los procesos del ciclo de vida del software. Sirve para proporcionar y mantener al personal formado.
De los procesos anteriores existe otro muy importante si se requiere hacer la adaptación a la norma ISO-12207 que debe ser considerado. Proceso de adaptación: Sirve para realizar la adaptación básica de la norma ISO-12207 con respecto a los
proyectos
software.
Es
necesario
comprender
los
procesos,
las
organizaciones y sus relaciones bajo diferentes puntos de vista:
Bajo el punto de vista del contrato, el comprador y el proveedor negocian y firman un
contrato, empleando los procesos de adquisición y
suministro. 30
Bajo el punto de vista de gestión, el comprador, el proveedor, el desarrollador, el operador y el personal de mantenimiento gestionan sus respectivos procesos para el proyecto software. Bajo el punto de vista de explotación, el operador proporciona el servicio de explotación del software a los usuarios. Bajo el punto de vista de ingeniería, el desarrollador o el personal de mantenimiento llevan a cabo sus respectivas tareas de ingeniería para producir o modificar los productos software Bajo el punto de vista de soporte, los grupos (tales como el de la gestión de la configuración, el aseguramiento de la calidad...) proporcionan servicios de apoyo a otros grupos en el cumplimiento de tareas únicas y específicas.
2.5 Roles y responsabilidades de los equipos de desarrollo.
¿Qué es un equipo? ―Al
menos
dos
personas
quienes
están
trabajando
juntos
por
una
meta/objetivo/misión común, donde a cada persona se le ha asignado roles o funciones específicas a desarrollar, y en donde el cumplimiento de la misión requiere algún tipo de dependencia entre los miembros del grupo‖
Jean L. Dyer
El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en grupo. Además, esta actividad requiere de distintas capacidades, las que no se encuentran todas en una sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las personas que cubran todas las capacidades requeridas. 31
Cada una de esas personas aportará al grupo parte del total de las capacidades necesarias para llevar a cabo con éxito el desarrollo.
Por ello, es que cada persona debe tener un rol dentro del grupo, que viene dado por su experiencia y capacidades personales. En este capítulo se describen los roles que tradicionalmente se consideran en el desarrollo de software. Estos roles son:
Administrador de proyecto, analista, diseñador, programador, téster, asegurador de calidad, documentador, ingeniero de manutención, ingeniero de validación y verificación, administrador de la configuración y por último, el cliente.
Para cada uno de estos roles, se definen sus objetivos, actividades, interacción con otros roles, herramientas a utilizar, perfil de las personas en ese rol y un plan de trabajo. Hay que señalar que es posible que no se requieran todos los roles en un desarrollo.
Eso dependerá del tamaño y del tipo del desarrollo. Por ejemplo, el desarrollo de un sistema de información de gran tamaño requerirá más roles que uno de menor tamaño. Por otro lado, si el tipo del proyecto está enfocado más hacia la parametrización e integración de sistemas, requerirá algunos roles en menor medida y otros en mayor.
32
Es posible también que una persona realice las labores de más de un rol al mismo tiempo. Esto, sobre todo en proyectos de desarrollo de software más pequeños. No obstante, es imprescindible que dichas personas conozcan completamente todas sus tareas. Por otro lado, también es posible la situación de tener más de una persona con un mismo rol en un equipo de desarrollo. Por ejemplo, en sistemas de complejidad mediana hemos utilizado con éxito la fórmula de tener un administrador
de
proyecto,
dos
analistas,
dos
diseñadores,
dos
programadores y un téster. Eso hace un total de ocho personas en un grupo. Las actividades de documentación y administración de configuración son asumidas por todos los roles. Parte de las actividades de aseguramiento de calidad son asumidas por el téster. El resto de las actividades no son realizadas. El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus responsabilidades y actividades asociadas, hace que se produzcan problemas. Por un lado, es posible que una o más actividades no estén asociadas a ningún rol, con lo que el proyecto sufrirá. Por otro lado, es posible que una o más actividades estén asociadas a más de un rol. Esto último producirá problemas entre los miembros afectados, lo que también redunda en problemas en el desarrollo del sistema. Por lo anterior, se hace necesario que cada miembro conozca muy bien su rol dentro del proyecto, así como las responsabilidades y actividades asignadas. Es bastante común que, frente a una oferta de una empresa en busca de personal calificado para su equipo de desarrollo de software, nos sintamos atraídos a postular a un rol específico.
33
La fábula de la granja
Un día cualquiera, los animales de una granja decidieron hacer una fiesta, con el propósito de pasar un momento agradable. Para organizar la fiesta, se reunieron el mismo día en la mañana. Cada animal debía llevar algo a la fiesta. Como es lógico, a la vaca le pidieron la leche. A la gallina, le tocó llevar los huevos. Y al chancho, el tocino. En este caso, la vaca y la gallina participan de la fiesta. Sin embargo, el chancho se encuentra involucrado. Su participación le obliga a entregar parte de si mismo como aporte para la fiesta. Al chancho le toca aportar una cuota de sacrificio mayor. Lo anterior muestra la diferencia entre participar en un evento y estar involucrado.
Tomemos esta fábula para caracterizar a los miembros del grupo de un desarrollo de software. ¿Cómo se comportan, en general? ¿Participan o están comprometidos en el proceso de desarrollo de software? Parece claro que lo deseable, desde el punto de vista del problema completo, es tener integrantes comprometidos. Pero, ¿cómo se obtienen estos miembros comprometidos? ¿Es posible ―crear‖ miembros del grupo comprometidos? ¿Administrador de proyecto
comprometido,
analista
comprometido,
diseñador
comprometido,
programador comprometido, téster comprometido, asegurador de calidad comprometido, documentador comprometido, ingeniero de manutención comprometido, ingeniero de validación y verificación comprometido, administrador de la configuración comprometido y cliente comprometido? La fábula anterior nos enseña la diferencia entre participar y estar comprometidos en una actividad. Es claro que para tener miembros del equipo de desarrollo, comprometidos, es necesario capacitarlos en sus deberes y derechos en el ciclo de vida del desarrollo de software. 34
Es muy poco probable que un miembro no capacitado pueda estar comprometido con los objetivos del proyecto. Este presentará claras deficiencias en el momento de participar en el proceso. Como ejemplo, se mencionan algunas: 1. Un miembro no capacitado no entenderá el lenguaje técnico utilizado por el resto de los miembros. Muchas veces, entenderá una cosa diferente a la expresada
por sus pares. Esto es común debido a diferencias en el
lenguaje. 2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los problemas que se presentan durante el desarrollo. Sería muy bueno que el miembro pudiera aportar sus conocimientos en su dominio del problema durante todo el ciclo de desarrollo del proyecto. Saber cuando exigir y cuando ceder, conocer los estándares de desarrollo, de documentación, de aseguramiento de la calidad. 4. Un miembro no capacitado no presupuesta su involucramiento en el proyecto, sólo su participación. Este solo hecho reduce las posibilidades de éxito del proyecto. También aumenta los tiempos de desarrollo, disminuye la calidad del sistema, aumentan los riesgos de rechazo del sistema por parte de la comunidad de clientes, etc. Lo anterior sugiere que es necesario contar con ―miembros comprometidos‖ para desarrollar correctamente el proyecto.
35
Aspectos a considerar son : Crear un lenguaje común entre el equipo de desarrollo, así como hacer que entiendan claramente sus deberes y obligaciones. Por otro lado, los clientes también deben estar comprometidos con el desarrollo. Eso significa que deben conocer el ciclo de vida escogido, cual es su participación en cada una de las fases del ciclo, y la cantidad de esfuerzo y recursos que se espera que pongan en cada momento del proyecto. Es de vital importancia que participen activamente en la etapa de análisis, así como en todas aquellas actividades de revisión y aceptación. En caso que el cliente no tenga dicha experiencia, se hace necesario que antes de un desarrollo, se los capacite para convertirlos en clientes comprometidos. Lo anterior requiere de trabajo, pero va en la senda correcta del éxito de un proyecto de software. Es claro entonces que todos los integrantes del equipo de desarrollo debiesen estar comprometidos con el proyecto, incluyendo los clientes. Lo anterior implica trabajar con el equipo completo en torno a las metas a lograr, así como las cualidades y características deseables de cada uno de ellos. Para ello, se requiere entender correctamente las características de liderazgo dentro de un grupo humano.
36
2.6 Habilidades y capacidades del personal del SQA El asegurador de calidad debe ser una persona con mucha experiencia en proyectos de desarrollo de software, con conocimientos suficientes sobre técnicas que aseguren la calidad de un producto de software. Lo anterior lo hace capaz de negociar con la calidad del producto, y ocasionalmente, modificar el criterio de los desarrolladores. Considerando el Aseguramiento de la Calidad del software como una de las claves áreas de proceso de CMM nivel 2, las habilidades para el desempeño para el grupo de Aseguramiento de la calidad del Software son las siguientes:
Habilidad 1: Existe un grupo de Aseguramiento de Calidad que es el responsable de coordinar e implementar las actividades de garantía de calidad para el proyecto.
Un grupo se considera como la colección de departamentos, gerentes e individuos que tienen responsabilidades por un conjunto de tareas o actividades. Un grupo puede variar desde una o varias personas asignadas a tiempo parcial de diferentes departamentos, hasta varios individuos dedicados a tiempo completo. Las consideraciones a tener para implementar un grupo incluyen las tareas y actividades asignadas, el tamaño de proyecto, la estructura y la cultura de la organización. Algunos grupos, como el de aseguramiento de la calidad de software, están enfocados a actividades de proyectos, y otros como el grupo de ingeniería de procesos de software, están enfocados a actividades en el ámbito de toda la organización.
37
Habilidad 2: Se provee de recursos y financiamiento adecuados para la realización de las actividades de Aseguramiento de Calidad de Software.
1. Se asigna específicamente un gerente responsable por las actividades de SQA 2. Un gerente superior, quien es conocedor del SQA y tiene la autoridad de tomar acciones de control, es designado para recibir y actuar sobre los ítemes de software no conformes. 3. Se dispone de herramientas de apoyo a SQA como son : estaciones de trabajo, programas de bases de datos, programas de planilla de cálculo y herramientas de auditoría.
Habilidad 3: Los miembros del grupo de SQA están capacitados para realizar las tareas asociadas a esta actividad. Ejemplos de capacitación incluyen: Practicas y habilidades de ingeniería de software, roles y responsabilidades del grupo de ingeniería de software y otros grupos relacionados, métodos, estándares y procedimientos para el proyecto de software, dominio de la aplicación del proyecto de software, métodos, procedimientos y objetivos de garantía de calidad, involucramiento del grupo SQA en las actividades del proyecto, un uso efectivo de los métodos y herramientas de garantía de calidad, y comunicación interpersonal.
Habilidad 4: Los miembros del proyecto reciben orientación en los roles, responsabilidades, autoridad y valor del grupo de SQA.
38
Relación con otros roles
A continuación se analiza la relación del asegurador de calidad con los otros roles: • Administrador de proyecto: El asegurador de calidad revisa el plan de
administración de proyecto, para asegurarse que se crea y que se sigue.
• Analista: El asegurador de calidad revisa la especificación de requisitos de
usuario y de software, para asegurarse que es una representación correcta y completa de las expectativas del cliente, y que es suficientemente clara para todos en el grupo de desarrollo, especialmente para el diseñador.
• Diseñador: El asegurador de calidad revisa la fase de diseño arquitectónico,
para asegurarse que el diseñador seleccionó la metodología apropiada y que el producto final de esta fase cumple con requisitos de rendimiento, diseño y verificación.
• Programador: El asegurador de calidad revisa la fase de diseño detallado,
para asegurarse que el código producido cumple con la especificación de requisitos establecida y que cumple con los atributos de calidad en uso.
• Téster : El asegurador de calidad revisa el plan de testeo, para asegurarse
que es creado, que es adecuado para el proyecto específico, y que se aplica en cada fase del proceso de desarrollo hasta la entrega del producto.
39
• Documentador: El asegurador de calidad revisa la documentación, para
asegurarse que corresponde con el software desarrollado, y que cumple con el estándar en uso. • Administrador de configuración: El asegurador de calidad revisa los registros
de cambios, errores y de configuración, para asegurarse de que los cambios han sido implementados apropiadamente, y que las líneas bases son almacenadas y que el producto no se puede perder.
2.7 Actividades del SQA. A continuación se presentan las actividades y metas a cumplir por los aseguradores de calidad.
Revisar los documentos de requisitos de usuario y de software Revisar el plan de administración del
Asegurarse que la especificación de requisitos es una representación correcta y completa de las expectativas del cliente, y que es suficientemente clara para el equipo de desarrollo, especialmente para los diseñadores. Asegurarse que el plan es creado y se cumple.
proyecto.
Revisar el plan de testeo Revisar la fase de diseño arquitectónico Revisar la fase de diseño detallado Revisar las políticas de control de cambios, control de errores y control de la configuración. Revisar la documentación.
Asegurarse que el plan se crea, que es adecuado al proyecto específico, y que se sigue en cada fase del ciclo hasta que se entrega el producto. Asegurarse que los diseñadores seleccionaron la metodología apropiada y que el producto final cumple con los requisitos de diseño y verificación. 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 líneas bases haciendo que el producto no se pueda perder Asegurarse que la documentación cumple con el estándar utilizado durante el desarrollo del producto de software.
40
2.8 Métodos y herramientas. Existen varios métodos y herramientas que pueden ser aplicados durante el desarrollo de software, pero en este apartado se enfocara más a las actividades del Asegurador de Calidad. Entre las actividades del Asegurador de Calidad, la más importante es la de participar en las revisiones técnicas formales (RTF). Si estas revisiones están bien conducidas, son la forma más efectiva de encontrar, revelar y corregir errores mientras aún es barato encontrarlos y arreglarlos. El estándar ESA incluye revisiones en las fases RU/R, RS/R, DA/R y DD/R. No obstante, las RTFs son especialmente requeridas en la fase de diseño arquitectónico. Esto, debido a que las actividades de diseño introducen entre el 50 y 65% de todos los errores durante el proceso de desarrollo. Se ha demostrado que las RTFs descubren del orden del 75% de los errores de diseño. Los objetivos de las RTFs son: Descubrir errores en funciones, lógica e implementación en cualquiera de las representaciones del software. Verificar que el software bajo revisión cumple con los requisitos. Asegurarse que el software ha sido representado de acuerdo al estándar en uso. Alcanzar software que es desarrollado en forma uniforme. Hacer el proyecto más manejable.
41
Una RTF es una reunión entre tres a cinco personas. Cada una de ellas ha realizado una preparación de antemano de no más de dos horas, y su duración no debe tampoco sobrepasar las dos horas. La RTF se focaliza en un producto pequeño del software, tal como una porción de los requisitos, el diseño detallado de un módulo, o el listado de código fuente de un módulo. Los participantes de una RTF son el productor (la persona que desarrolló el producto a revisar), un encargado de la revisión que evalúa el producto genera copias de material y lo distribuye a dos o tres revisores para que se preparen de antemano. Uno de los revisores toma el rol de documentador de los aspectos más relevantes aparecidos durante la revisión. Al final de la revisión, los participantes deben decidir si: 1. Aceptar el producto sin modificación posterior. 2. Rechazar el producto debido a errores serios. 3. Aceptar el producto con errores menores que deben ser corregidos, pero no se requiere una revisión posterior.
42
2.9 Enfoque de Procesos en el Desarrollo de software En un mundo de cambios constantes y competencia global, las organizaciones de desarrollo de software son presionadas a alcanzar mayor eficiencia con menores costos. Para poder lograr este objetivo, es necesario adoptar una forma de trabajo que permita entender, controlar, comunicar, mejorar, predecir y certificar el trabajo realizado. Actualmente existe una gran diversidad de opciones relacionadas con procesos de desarrollo. Constantemente se escuchan diferentes acrónimos como CMM, CMMI, RUP, ISO, PSP, TSP, etc., que causan confusión, principalmente debido a la mala interpretación de los mismos. ¿Porqué contar con un proceso de software? Hasta hace poco tiempo, la producción de software era realizada con un enfoque artístico, a diferencia de un enfoque industrial. Ante la constante presencia de proyectos fallidos, y con el objetivo de mejorar la calidad de los productos, en los últimos años las organizaciones introdujeron los métodos de ingeniería de software. A partir de estos, se formalizó el enfoque de ingeniería de producto para desarrollar software. Factores como la globalización han obligado a las organizaciones a contar con marcos de trabajo que las ayuden hacer las cosas de la manera más eficiente. Fue entonces que se incorporó la ingeniería de procesos al desarrollo de software.
43
2.9.1 Definición de Proceso y Enfoque de procesos Antes de definir lo que es un proceso de desarrollo de software, entendamos lo que es un proceso: Proceso: Una definición sencilla de proceso es ―serie d e acciones que conducen a un final‖.
Esta definición parece coincidir con las ideas generales de la gente sobre procesos, pero deja muchas preguntas abiertas: ¿El proceso es la forma en que la organización opera —desde mercadotecnia hasta recursos humanos— o es la forma en que un desarrollador diseña, produce código, o prueba el software? ¿El proceso se refiere a administración, ingeniería, o ambas? ¿El proceso implica demasiada documentación y nos abstiene de desarrollar el producto objetivo? La respuesta a éstas puede variar dependiendo de la perspectiva. Sin embargo, siempre que para alcanzar algún fin deseado necesitemos ejecutar una serie de acciones, y estas acciones tengan cierto orden, dependencias, roles responsables, resultados, tiempos de ejecución y herramientas de apoyo, estaremos
hablando
de
procesos,
que
pueden
ser
predefinidos
y
personalizados. Proceso de software La meta de la ingeniería de software es construir productos de software, o mejorar los existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.
44
Un proceso de desarrollo de software se define como: “Un conjunto de personas, estructuras de organización, reglas, políticas,
actividades
y
sus
procedimientos,
componentes
de
software,
metodologías, y herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software”.
Fig. 3 Proceso de software
Un proceso de software efectivo habilita a la organización a incrementar su productividad al desarrollar software: • Permite estandarizar esfuerzos, promover reuso, repetición y consistencia
entre proyectos. • Provee la oportunidad de introducir mejores prácticas de la industria.
• Permite entender que las herramientas deben ser utilizadas para soportar un
proceso. • Establece la base para una mayor consistencia y mejoras futuras.
45
Un proceso de software mejora los esfuerzos de mantenimiento y soporte: • Define cómo manejar los cambios y liberaciones a sistemas de software
existentes. • Define cómo lograr la transición del software a la operación, y cómo ejecutar
los esfuerzos de operación y soporte. Se requiere un proceso de software cuya funcionalidad esté probada en la práctica, y personalizado para que cumpla con necesidades específicas.
Fig. 4 Elementos típicos del proceso de software.
46
2.9.2 Capacidad de proceso de software El rango de resultados esperados que se pueden obtener tras seguir un proceso.
2.9.3 Madurez del proceso de software Es el punto hasta el cual un determinado proceso es explícitamente definido, administrado, medido, controlado y efectivo. ¿Qué es un nivel de madurez? Es una plataforma bien definida desde la cual podremos obtener un proceso maduro de software.
2.9.4 Modelos de proceso PSP y TSP El mejor proceso de software es el que esta cerca de la gente que realizará el trabajo. Si un modelo de proceso
de software ha sido desarrollado en un
ámbito corporativo u organizacional, puede ser efectivo sólo si es en gran medida adaptable para satisfacer las necesidades del equipo del proyecto, que es el que en realidad lleva a cabo el trabajo de ingeniería de software. En un escenario ideal, cada ingeniero de software crearía un proceso que llene lo mejor posible sus propias necesidades, y al mismo tiempo satisfaga las amplias necesidades del equipo
y la organización. De modo alternativo, el equipo
mismo crearía su propio proceso, y al mismo tiempo cubriría las necesidades más reducidas de los individuos y las necesidades amplias de la organización. Watts Humphrey [HUM97] y [HUM00] argumenta que es posible crear un ―proceso de software personal‖ o un ―proceso de software en equipo‖ ambos
requieren un trabajo arduo, capacitación y coordinación pero ambos se pueden conseguir. ¿Por qué TSP /PSP para desarrolladores de software en México? 47
Es bien sabido que para desarrollar software de calidad de manera consistente se requiere contar con una alta madurez de procesos. A nivel internacional, el modelo de madurez de procesos más popular es el modelo CMMI. Sin embargo, este modelo es complejo para implementar en empresas pequeñas. En México se tiene la Norma Mexicana basada en MoProsoft, pero ésta se centra en los procesos de las empresas, más no en los de las personas. La estrategia para incrementar la madurez de la industria de software en México, debe de contemplar no solamente los procesos de las empresas sino, incluir el mejoramiento del elemento básico que da sustento a la industria: las personas. Precisamente en las personas se enfoca el Personal Software Process (PSP) y Team Software Process (TSP), creados por el Dr. Watts Humphrey del Software Engineering Institute (SEI). Es así que la Secretaría de Economía ha dado marcha a la Iniciativa Nacional TSP/PSP, la cual se está trabajando directamente con el SEI y el Dr. Humphrey. El objetivo de esta iniciativa es crear en México la infraestructura humana que permita la introducción y expansión acelerada del uso de TSP, para que la industria de desarrollo de software en México alcance un desempeño superior al de su competencia internacional.
Los elementos que se conjuntan y que nos hacen creer en esta oportunidad son los siguientes: La gran mayoría de las empresas que desarrollan software en México son menores a 50 empleados. El modelo que utilizan nuestros competidores (CMMI) es complejo y apropiado para organizaciones grandes. 48
El TSP/PSP, cuando se implementa correctamente, ha probado ser más eficaz que el CMMI Nivel 5. Con el uso de TSP/PSP las empresas en México podrían tomar ventaja y adelantarse en la incorporación de estos procesos de calidad en menor tiempo y obteniendo mejores resultados. México ya ocupa el primer lugar mundial de personas certificadas en PSP, lo que nos da ventaja sobre nuestros competidores. El SEI busca impulsar significativamente TSP/PSP y está en busca de un socio que le ayude a cumplir este objetivo. México, como país ha demostrado ser un aliado que permitirá continuar con la evolución de dichos modelos. Visión Con la implementación de este proyecto México logrará: Posicionarse como el país con mejor calidad y valor agregado de manera ágil, adelantándonos a las capacidades de nuestros competidores. Contar con un método avalado por el SEI que permitirá demostrar objetivamente la calidad de los proyectos desarrollados por las empresas que usan el TSP. Que la calidad de los desarrollos con talento mexicano sean mejores que aquellos con niveles de alta madurez de CMMI. Esto permitirá hacer desarrollos en menor tiempo y mejor calidad, lo que se transforma en una ventaja de costo. Las metas para alcanzar a corto plazo con la Iniciativa Nacional TSP/PSP son: La definición de la primera versión del método de evaluación organizacional del uso del TSP. 49
La definición del método de mejora acelerada a través del TSP+CMMI. Los estudios de impacto del TSP, para ajustar su uso y prácticas. Desarrollar una infraestructura de instructores y coaches a un costo competitivo que permita acelerar la incorporación del uso de TSP/PSP en México. Si bien, la Secretaría de Economía a través del Prosoft está fondeando el desarrollo de la certificación para TSP organizacional en el SEI, ésta tendrá un reconocimiento mundial. Así al mantener el sello del SEI México, será el primer ―jugador‖ en este esfuerzo, obteniendo ventajas sobre quienes le sigan.
Relación CMMI-TSP Por lo regular se necesita de 18 a 24 meses para lograr un nivel en CMMI, lo que se traduce en seis años para alcanzar un nivel 4 y ocho años para alcanzar un nivel 5. Sin embargo, incorporar TSP/PSP acelera el cumplimiento de las prácticas de CMMI de una forma más generalizada en la organización, y recorta significativamente el tiempo necesario para alcanzar cada nivel. Esto sucede porque los integrantes del equipo de trabajo conocen y aplican PSP en sus procesos personales, lo cual acelera la implementación de prácticas organizacionales.
PSP – Personal Software Process Personal Software Process (PSP) es un proceso diseñado para ayudar a los ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está 50
basado en una motivación: La calidad de software depende del trabajo de cada uno de los ingenieros de software. Debido a que los costos de personal constituyen 70% del costo del desarrollo de software, las capacidades y hábitos de trabajo de los ingenieros determinan en gran manera los resultados del desarrollo de software. Basado en prácticas encontradas en CMM, el PSP puede ser usado por ingenieros para estructurar y disciplinar el desarrollo de software. El ingeniero de software podrá planear mejor el trabajo, conocer con precisión el desempeño, medir la calidad de productos, y mejorar las técnicas. PSP puede ser aplicado en: Desarrollo de programas. Definición de requerimientos. Documentación. Pruebas de sistemas. Mantenimiento de sistemas.
Fig. 5 Proceso de Software Personal (PSP)
51
TSP - Team Software Process Team Software Process (TSP) es un marco para el desarrollo de software que pone igual énfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue propuesto por Watts Humphrey. TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es desarrollado por equipos, por lo que los ingenieros de software deben primero saber controlar su trabajo, y después saber trabajar en equipo. TSP le enseña a los ingenieros a construir equipos autodirigidos y desempeñarse como un miembro efectivo del equipo. También muestra a los administradores como guiar y soportar estos equipos.
Estrategia de TSP • Proveer un proceso sencillo ba sado en PSP • Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento,
Estrategia, Plan, Requerimientos, Diseño, Implementación, Pruebas, Postmortem • Establecer medidas estándares para calidad y desempeño • Proveer definiciones de roles, y evalu aciones de rol y de equipo • Requiere disciplina de proceso • Provee guía para manejo de problemas de trabajo en equipo.
52
Objetivos del TSP: Construir equipos independientes que planeen y tengan un seguimiento de su trabajo, establezcan metas y posean sus procesos y planes. Estos grupos pueden ser equipos de software puros o equipos de producto integrado de 3 a 20 integrantes.
Mostrar a los jefes cómo preparar y motivar a sus equipos y como ayudarlos a sostener un alto desempeño.
Acelerar el mejoramiento del software a realizar, con el comportamiento normal y esperado, el nivel 5 de CMM
Ofrecer una guía de mejoramiento a organizaciones de alta madurez.
Facilitar la enseñanza universitaria de habilidades de equipo industrial de calidad.
El equipo autodirigido entiende en forma consistente sus metas y objetivos generales. Define funciones y responsabilidades para cada uno de sus miembros, registra datos cuantitativos del proyecto (como productividad y calidad); identifica un proceso de equipo apropiado para el proyecto y una estrategia para implementar el proceso; define estándares locales aplicables al trabajo de ingeniería de software del equipo, evalúa en cada momento riesgos, reacciones; y registra, gestiona y reporta el estatus del proyecto.
53
Planteamiento de la necesidad
Ciclo 1 Lanzamiento
Ciclo 2 Lanzamiento
Ciclo 3 Lanzamiento
Estrategia 1 Plan 1
Estrategia 2
Requerimientos 1
Plan 2
Estrategia 3
Diseño 1
Requerimientos 2
Plan 3
Implementación 1
Diseño 2
Requerimientos 3
Pruebas 1
Implementación 2
Diseño 3
Postmortem 1
Pruebas 2
Implementación 3
Postmortem 2
Pruebas 3 Postmortem 3 Producto terminado Evaluación final
Fig.6 Estructura y flujo del TSP
El TSP define las siguientes actividades del marco de trabajo: lanzamiento, diseño de alto nivel, implementación, integración
y prueba, análisis de
resultados. Al igual que sus contrapartes en el PSP, estas actividades permiten al equipo planear, diseñar y construir un software de una manera disciplinada al mismo tiempo que miden de modo cuantitativo el proceso y el producto. El análisis de resultados muestran el escenario para el mejoramiento del proceso.
El TSP utiliza una amplia variedad de escritos, formas y estándares que sirven para guiar a los miembros del equipo en su trabajo. Los escritos (scripts) definen actividades específicas del proceso (por ejemplo lanzamiento, diseño, implementación, integración y prueba de unidad) que son parte del proceso del equipo.
54
La actividad inicial del proceso conocida como lanzamiento permite al equipo establecer una base sólida para iniciar el proyecto. Se recomienda el siguiente script general [HUM00]:
Revisar los objetivos del proyecto con las de gestión, acordar, y documentar las metas del equipo. Establecer las funciones del equipo. Definir el proceso de desarrollo del equipo. Elaborar un plan de calidad y plantear los objetivos de calidad. Preparar un plan para las necesidades de soporte necesarias. Producir una estrategia de desarrollo general Elaborar un plan de desarrollo para el proyecto en su totalidad. Hacer planes detallados para cada ingeniero en la siguiente fase. Adaptar los planes individuales a un plan de equipo. Hacer un balance de la cantidad de trabajo para obtener un programa mínimo en términos generales. Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave.
Es importante señalar que la actividad de lanzamiento puede aplicarse antes de cada actividad del marco de trabajo del TSP, esto se ajusta a la naturaleza iterativa de muchos proyectos y permite que el equipo se adapte a las necesidades cambiantes del cliente y a las lecciones aprendidas de actividades previas.
55
2.10 Preguntas de repaso y prácticas sugeridas. 1. Investigar diferentes modelos de ciclos de vida, discutir en grupo las ventajas y desventajas de estos para aplicarlos en el desarrollo de un producto de software. 2. Realizar una lluvia de ideas grupal en donde se lleven a cabo soluciones que permitan tener a un grupo de desarrollo de software y aseguramiento de calidad mas comprometidos. 3. Investigue cuales son las principales actividades que realizan los miembros de SQA para una norma en específico (Moprosoft, CMM. CMMI, etc.) 4. Discutir en grupo sobre la relación entre proceso y calidad del producto obtenido.
5. Elaborar un proyecto de software tangible de manera que pueda realizarse primero de forma individual y después de manera grupal en un tiempo definido. Documentar las experiencias que se tienen al hacerlo de distinto modo. Discutir cuales fueron las practicas que mejor pueden servir para realizar el producto con mayor éxito. SE PUEDEN BASAR EN LOS ANEXOS 1, 2 Y 3 DE ESTE TEXTO COMO APOYO EN SU PROYECTO.
56
6. Discutir en grupo sobre la responsabilidad de cada uno de los roles de los integrantes del equipo de desarrollo de software y el porqué es importante su comunicación con el equipo de Aseguramiento de la Calidad. 7. Realizar un ejercicio de una revisión técnica formal sobre un producto de software realizado anteriormente, cuidar los aspectos y recomendaciones señaladas en este capítulo, documentar las experiencias obtenidas y discutir las posibles mejoras que puedan realizarse. 8. Realizar una visita a una empresa que desarrolle software, observe cuales son las actividades que se realizan antes, durante y después de desarrollar el producto,
intente clasificarlas identificando
el tipo de
proceso según la norma ISO 12207-1. 9. Realizar en equipo algunas de las actividades de la fase de lanzamiento para el TSP descritas en el script general.
57
3 Estándares de calidad aplicados al software.
3.1 ISO En el capitulo I se mencionaron las familias de normas ISO, en este punto se detallará que es el ISO y su aplicación en la calidad de software. ¿Qué es el ISO 9000 ? En el año de 1987, la Organización Internacional para la Estandarización (ISO por sus siglas en inglés) con base en Génova publicó la serie de estándares internacionales ISO 9000 para que sirvieran como base para el sistema de administración de la calidad. Es descendiente del estándar Británico BS-5750. Desde la publicación original, los estándares han sido revisados en los años 1994 y 2000. El certificado ISO 9000 es otorgado por organizaciones acreditadas llamadas certificadoras, que revisan el manual de calidad y los procedimientos de la compañía para asegurar que cumplen con los requisitos del estándar aplicable, y auditan los procesos para asegurar que se implementen los sistemas documentados de forma efectiva. Una vez que se otorga la certificación, el certificador lleva a cabo auditorías de supervisión una a dos veces por año para asegurar que el sistema continúa siendo implementado y cumple con los requisitos del estándar aplicable. ISO 9000, que junta una propuesta de administración de calidad total con una metodología de documentación para crear un sistema de auditoría interno, es 58
también el primer intento de crear un estándar internacional de aseguramiento de calidad que cubra todas las industrias y el sector de servicio. El así llamado estándar ISO 9000 está actualmente comprendido por una serie de estándares. Los estándares publicados el 15 de diciembre del 2000 son: ISO 9000:2005 Sistemas de Administración de la Calidad – Fundamentos y Vocabulario ISO 9001:2008 Sistemas de Administración de la Calidad – Requisitos ISO 9004:2000 Sistemas de Administración de a Calidad – Guía para la Mejora del Desempeño ISO 9000:2005 describe conceptos y propuestas esenciales para la familia ISO 9000:2000 y brinda definiciones para el vocabulario. ISO 9000 no es una especificación, sin embargo, se nombra en ISO 9001 como una referencia normativa y así puede ser usada por los auditores para apoyar su interpretación de los requisitos del ISO 9001, en particular con referencia al vocabulario. ISO 9001:2008 son los requisitos actuales para el sistema de administración de la calidad. Sus requisitos definen el criterio para el sistema de calidad. El papel de este estándar en las series no ha cambiado, pero su contenido y organización son revisadas completamente. ISO 9004:2000 describe un sistema de calidad que va más allá de los requisitos básicos especificados en el ISO 9001. Está previsto como una guía para organizaciones que quieren expandir y mejorar aún más el sistema de calidad después de implementar el ISO 9001 (ejem. en las fases después de la certificación). ISO 9004 no es un requerimiento y no debe ser usado por auditores de terceros para auditorías de registro.
59
Los principios básicos en que se ha basado la revisión de esta norma son : Organización enfocada al cliente: Para obtener la satisfacción de los mismos e incluso superar sus expectativas. Liderazgo: Para avanzar hacia la excelencia el liderazgo e los equipos directivos es fundamental. Participación de las personas: Para el proceso de mejora continua es necesario que los conocimientos de todo el personal que integra la organización estén a disposición del mismo. Enfoque e procesos: Se consigue mayor efectividad cuando todas las actividades interrelacionadas se comprenden y gestionan en forma sistemática a partir de una información fiable. Enfoque del sistema hacia la gestión: Por medido de la gestión de los procesos se consigue la mejora y el logro eficiente de los objetivos. Mejora continua: Es el procedimiento según el cual se planifican acciones encaminadas a la mejora de las actividades, se ejecutan esas acciones, midiendo sus resultados y actuando en consecuencia. La mejora continua debe ser el objetivo permanente de las empresas para evitar el retroceso. Enfoque hacia la toma de decisiones: Se debe observar y estudiar las medidas de los procesos y en toda la información relevante y fiable que se pueda obtener. Relaciones mutuamente beneficiosas suministradores-proveedores. Al final de la cadena proveedor-suministrador se encuentra el cliente final, por lo que es necesario establecer relaciones de mutua confianza entre los proveedores y los suministradores. 60
Por lo anterior, valdría la pena preguntarse: ¿Porqué los estándares son tan importantes? Muchas compañías requieren que sus proveedores estén certificados bajo el estándar ISO 9000 y debido a esto, las compañías certificadas encuentras que sus oportunidades de mercado se han incrementado. Además, la conformidad de la compañía con el estándar ISO 9000 asegura que tiene un sistema de aseguramiento de calidad sólido. Las compañías certificadas han tenido reducciones dramáticas en las quejas de cliente, reducciones significativas en costos de operación y un incremento en la demanda de sus productos y servicios. ¿Qué es un sistema de calidad conforme a ISO 9001? Un sistema de calidad conforme a ISO 9001 satisface los requisitos del estándar ISO 9001 pero no ha sido formalmente evaluado y certificado por un certificador de terceros. Esto significa que puedes disfrutar de los beneficios de un sistema de calidad conforme a ISO 9001 sin pasar por los
gastos
normalmente asociados con la certificación. Estarás en posición de certificar cuando así lo requieras. Beneficios de la Conformidad a ISO 9001 Los siguientes son algunos de los muchos beneficios que las compañías reportan que han ganado al implementar los sistemas de calidad ISO 9000: Mejor control de sus operaciones Mejoramiento en la calidad de servicio a sus clientes con aseguramiento Un sistema de calidad extenso y formal
l
61
Incremento en la retroalimentación del empleado en el proceso de toma de decisiones Mejora en la habilidad de dar seguimiento a los procedimientos Incremento en la habilidad para determinar la causa raíz de los errores Una excelente herramienta de mercadotecnia.
3.1 SPICE
Antecedentes: Debido al incremento del número de modelos y estándares aplicados a valorar la mejora del desarrollo de software y su producto, estos mismos propiciaron al inicio de los 90’s el sentimiento generalizado de la necesidad de promover un
estándar internacional que armonizara los modelos de referencia existentes (CMM, Trillium, Bootstrap, etc). El
proyecto
SPICE
(Software
Process
Improvement
and
Capability
dEtermination) promovido por ISO surgió como un esfuerzo de colaboración internacional que debía materializarse en un nuevo estándar para la valoración del proceso de software. Dicho proyecto debía proporcionar el soporte necesario para la elaboración del nuevo estándar. La realización de pruebas de campo sería una labor fundamental de la que deberían extraer los datos oportunos y derivar los análisis que posibilitarían la mejora del modelo en sus diferentes versiones.
62
El estándar resultante del proyecto debía cumplir ciertos objetivos: Ser lo suficientemente genérico para tener un amplio horizonte de aplicación, a la par de lo suficientemente específico como para ser útil y manejable. Establecer mecanismos que permitieran migrar desde estándares ya establecidos, así como evitar la aparición de otros estándares contrastantes. Proporcionar un programa de transferencia tecnológica que permitiera la adopción del nuevo estándar. De los años 1993 a 1995 se desarrollaron y realizaron las primeras pruebas de campo, para verano de 1996 se dieron diferentes cambios en la norma para ajustarla a los datos recogidos en las pruebas efectuadas, para octubre de ese mismo año se realizó en México un encuentro del grupo de trabajo numero 10 (WG10) en el que la comunidad internacional, por primera vez pudo conocer las partes que definen el modelo. Posteriormente se entregó a la secretaria del comité las 9 partes de documento comenzando el periodo de votaciones ( hay que recordar como se vio en el primer capítulo cómo es que se realizan estos estándares y los acuerdos a los mismos), la fase de revisión y votación por parte de los miembros del comité JTC1. En los años sucesivos a la publicación del informe técnico éste se encuentra sujeto a revisiones por el mismo comité. Entre los principales colaboradores del proyecto SPICE se encuentran: SEI Software Engineering Institute USA ,AT&T Bell labs USA, IBM Australia, NTT Japón, Northen Telecom Canadá, British Telecom, Fujitsi, Defense Reseach Agency de Gran Bretaña, ITDC Finlandia, Etnoteam Italia, CSELT Italia.
63
Objetivo de SPICE: • Establecer un estándar de evaluación de procesos de software para:
_ Evaluación de la capacidad de los procesos (nivel de madurez). - Determinación de la capacidad de los procesos. _ Mejora continua, (mejora de los procesos). _ Como base para el comercio internacional de software Alcance de SPICE: • Ejecutar, planificar, gestionar, controlar y mejorar los procesos de:
_ Adquisición _ Suministro _ Desarrollo _ Operación _ Soporte _ Mantenimiento _ Organización • Independiente del tipo de organización, modelo de ciclo de vida, metodología
de desarrollo y de la tecnología utilizada
SPICE como modelo Bidimensional El modelo a través de una aproximación estructurada, permite valorar los procesos de software, fomentando la autoevaluación y ofreciendo un mecanismo por lo cual los adquisidores pueden ganar confianza en los resultados de la valoración, de esta forma los datos obtenidos pueden ser utilizados para los fines de calificación de los suministradores, permitiendo 64
determinar la capacidad de los procesos, así como su adecuación para cumplir un requisito determinado o una clase de requisitos. La norma ISO 15504 se basa en otra norma de ISO la 12207 que describe el ciclo de vida. El modelo ISO/IEC 15504 también está ideado para determinar la idoneidad de los procesos de otras organizaciones, para un contrato determinado o clase de contrato. El modelo de referencia se fundamenta en dos dimensiones bien determinadas y complementarias, la Fig. 7 nos muestra la Arquitectura de SPICE.
Fig. 7 Arquitectura de SPICE
65
Una de ellas determina los procesos a ser valorados, definiendo el proceso de vida del software. La otra dimensión presenta una escala para evaluar la capacidad. La escala elegida posee cinco niveles caracterizados por un conjunto de nueve atributos de procesos, que a su vez son tasados según el grado de cumplimiento de los mismos indicando en tantos por cientos, como se muestra en la Fig. 8.
Fig.9 SPICE: Relación de dimensiones y atributos del proceso.
La primera dimensión denominada dimensión del proceso define un conjunto estándar de procesos para el ciclo de vida completo del software. La dimensión del proceso parte de tres clases básicas de procesos: Primarios, de Soporte y Organizativos.
66
Estos se dividen en nueve categorías de proceso: PRIMARIOS: Procesos de Adquisición – (ACQ) Procesos de Proveedores – (SPL) Procesos de Ingeniería – (ENG) Procesos de Operación – (OPE) PROCESOS DE SOPORTE (SUP) PROCESOS ORGANIZATIVOS: Procesos de GESTION – (MAN) Procesos de Mejora – (PIM) Procesos de Recursos e Infraes – (RIN) Procesos de Reusabilidad – (REU) Cada proceso se define desde el punto de vista de su finalidad y como un conjunto identificado de resultados. La dimensión de la capacidad del proceso se sustenta en un conjunto de atributos que determinan el nivel. El objetivo de esta dimensión es definir la escala de medida para la capacidad del proceso, para ello se considera una escala de tipo ordinal de 6 puntos. La base fundamental para este estándar representa la medida del software de igual forma que en el caso del estándar CMM. En la Fig. 10 podemos apreciar la arquitectura de los procesos y su interacción con los niveles de madurez del proceso.
67
Fig.10 Arquitectura de los procesos según SPICE
Los niveles considerados por el estándar son mostrados en la Fig.10, estos niveles de capacidad por separado, no son suficientes para evitar ambigüedades en la cuantificación de la capacidad de los procesos, por lo que es necesario tener una serie de atributos comunes a todos los procesos. Estos atributos son utilizados como base para la valoración. Cada uno e ellos está definido desde el punto de vista de las características que el proceso debería exhibir. Para cada atributo hay una descripción general y un conjunto de características específicas, de forma que cada uno es evaluado para cada proceso valorado, desde el punto de vista del grado de realización del mismo.
68
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 modelo de evaluación evaluación se basa en el principio principio de que la capacidad del del proceso se puede evaluar si se demuestra la consecución de los atributos del proceso.
ISO/IEC 15504 obliga a evaluar empezando desde el Nivel 1 y, en caso de que sean alcanzados ampliamente (L) o completamente (F) los atributos de los procesos asociados a un cierto nivel, permite evaluar un nivel superior.
69
N No alcanzado P Parcialmente alcanzado L Ampliamente alcanzado
0% -15% 16% -50% 51% - 85%
alcanzado
atributo en el proceso evaluado. Se evidencia una aproximación sistemática del alcance del atributo, pero algunas de sus características no se dan. Hay bastantes evidencias de que se alcanza el atributo, pero la realización del proceso diverge en alguna área. Hay evidencia de que el atributo se alcanza plenamente y de
F Completamente
Indica un poco o nula evidencia de que se ha alcanzado este
86%-100%
manera sistemática en el proceso evaluado y no hay debilidades importantes en la unidad organizacional en la que se ubica el proceso.
Fig. 11Escala de valoración de los atributos de los procesos según ISO/IEC 15504
Esta aproximación no solo permite conocer el nivel en que se encuentra el proceso, sino que es una guía que permite su mejora al conocer el valor que deben tener los atributos para conseguir un nivel superior de excelencia, según la escala propuesta. La dimensión de la capacidad no solo sirve para cuantificar la capacidad de la organización sino también es una guía para su optimización. A continuación se muestran los niveles, con los atributos de los procesos asociados y grado de cumplimiento
70
0 1
No hay atributos en este nivel Realización del proceso (PA.1.1)
propósito
de
un
proceso,
transformando
los
productos de entrada en productos de salida.
Gestión de la realización 2
Representa la medida de cuándo se alcanza el
(PA.2.1)
Representa el grado de gestión de la realización del proceso, para que se obtengan productos que cumplan los objetivos definidos
Gestión de productos resultantes (PA.2.2) Definición de los procesos (PA.3.1)
Representa el grado de gestión de los productos resultantes producidos por los procesos Representa el nivel de realización del proceso, según el cual utiliza una definición de proceso basada en un proceso estándar para conseguir sus objetivos
3 Aplicación del proceso (PA.3.2)
Representa
el
nivel
de
adecuación
de
la
implementación o despliegue efectivo del proceso estándar Representa el nivel en el que las medidas y los objetivos de los productos y de los procesos son
Medida del proceso (PA.4.1)
utilizados para asegurar que la realización del proceso soporte el alcance de los objetivos definidos como apoyo en los objetivos de negocio.
4
Representa el nivel de control del proceso a través de la recopilación, análisis y uso de medidas de Control del proceso (PA.4.2) proceso y de producto, para corregir, en caso necesario, su rendimiento y para conseguir los objetivos de proceso y de producto definidos. Representa el nivel de control de los cambios en la Innovación de los procesos
definición, gestión y realización del proceso con el fin
(PA.5.1)
de alcanzar los objetivos de negocio fijados en la organización.
5
Representa el nivel bajo el cual se identifican e Optimización de los procesos implantan los cambios en los procesos, para (PA.5.2)
conseguir una mejora continua en el cumplimiento de los objetivos de negocio de la organización.
Fig.12 Atributos de los procesos asociados a los niveles de capacidad de ISO/IEC 15504
71
Fig.13 Ejemplo de perfil de evaluación de proceso.
La Fig. 13 muestra un ejemplo de perfil de evaluación del proceso en el que son considerados los atributos arriba mencionados. En el mismo puede denotarse en qué nivel de capacidad se encuentran los procesos evaluados, en el proceso de Soporte al cliente no se tiene la suficiente evidencia que para aprobar el atributo de Gestión de productos resultantes (PA2.2), a pesar de haber cubierto el de Gestión de Realización del proceso (PA2.1), por lo que su nivel de capacidad queda en 1. De manera similar los procesos de Diseño y Construcción del software, solo cubren parcialmente el grado del atributo al presentarse solo del 16% al 50% de las evidencias, por lo que su nivel de capacidad también queda en 1.
72
En la captura de los requisitos a pesar de que se tiene
ampliamente
conseguida la Aplicación del proceso (PA3.2), la realización del mismo difiere en alguna área, por lo que no puede obtener el nivel 3 y su nivel alcanzado es 2. Por último el proceso de Prueba del software se tiene evidencia que los atributos de Realización del proceso (PA 1.1), Gestión de la realización(PA.2.1) y Gestión de los productos resultantes (PA.2.2) se alcanzan plenamente y de manera sistemática, y que no existen debilidades importantes en la organización en la que se ubica dicho proceso, por lo cual su nivel de capacidad es 2.
3.3 CMM (Capability Maturity Model ) El modelo Capability Maturity Model (CMM ), también denominado CMM-SW. Fue desarrollado por el SEI (Software Engineering Institute), como marco de referencia para la evaluación y mejora de procesos de software. Con el fin de proporcionar al gobierno de los Estados Unidos un método para evaluar la capacidad de sus proveedores de software, en noviembre de 1986, el SEI junto con el Centro de Investigación Gubernamental Mitre, comenzaron a desarrollar un nuevo marco de mejora de procesos de software. En septiembre de 1987, publicaron el primer resultado en forma de una breve descripción del proceso de madurez así como un cuestionario para detectar los puntos débiles de la empresa evaluada. Después de unos cuantos años de aplicación del primer modelo y refinamiento del mismo a partir de los resultados que se iban obteniendo en su aplicación en diferentes empresas, el SEI desarrolló y publicó la primera versión de CMM en 1991. Esta primera versión fue revisada y 73
utilizada por la comunidad de software durante 1991 y 1992, en abril de ese año surgió la primera versión definitiva, CMM Versión 1.0. CMM contiene los elementos esenciales para conseguir procesos eficaces en uno o más cuerpos de conocimiento, estando estos elementos basados en los conceptos desarrollados por Crosby, Deming, Juran y Humphey. En el año 2000 el CMM fue actualizado hacia el modelo CMMI (Capability Maturity Model Integration). En junio del 2009 tuvo lugar en León (España la presentación mundial de la traducción al castellano del Modelo de Mejora de Procesos CMMI para Desarrollo de Software. La traducción ha sido desarrollada por la Cátedra de Mejora de Procesos de Software en el Espacio Iberoamericano, dirigida por Gonzalo Cuevas. España es el segundo país de Europa (con 105 evaluaciones CMMI, por detrás de Francia que tiene 141) y el noveno a nivel mundial en número de empresas evaluadas sobre el Modelo para el Desarrollo (CMMIDEV), pero sólo estaba disponible en inglés, francés, chino y japonés, lo que se traducía en que muchas compañías, sobre todo las de menor tamaño, tuvieran dificultades para acceder al mismo.
3.3.1 Definición del modelo El modelo de madurez guía a las organizaciones indicando cómo mejorar los procesos asociados al desarrollo y mantenimiento del software. La filosofía general que rige a este modelo se fundamenta en diferentes niveles de madurez entendidas como sucesivas etapas cuyo objetivo es la obtención de un proceso de software optimizado, en cada nivel, además de establecer una escala de medida de la capacidad de los procesos, se fijan unos objetivos que 74
ayudan a la organización a priorizar los esfuerzos dedicados a la mejora de estos procesos. Es importante indicar que el modelo de madurez, se fundamenta en la secuencia de los niveles propuestos. No es aconsejable ni técnicamente adecuado el pretender un nivel superior sin haber alcanzado el intermedio. Los niveles de madurez pueden asemejarse a los estratos telúricos, uno sucede al otro, lo apoya y sustenta. Es fácil entender que no es posible el proceder a una mejora continua con la aplicación de nuevas tecnologías como sería el caso del nivel 5, sin haber establecido un control cuantitativo de los procesos de software, o haber establecido estándares adecuados para, por ejemplo, la recopilación o manipulación de datos en la que asentar la cuantificación de los procesos productivos. El modelo de madurez propuesto por el SEI se basa en mejoras continuas y progresivas, no en saltos cualitativos ni en revoluciones tecnológicas de inesperadas consecuencias. La exigencia de la calidad no es sólo para los productos materiales, también lo es para los servicios. La Fig. 14 nos muestra los 5 niveles de madurez del proceso, cada nivel de madurez se interpreta como la capacidad de los procesos de ingeniería de software y de administración de proyectos usados en una organización de desarrollo de software. A su vez cada nivel de madurez con excepción del nivel Inicial tiene una estructura interna como es mostrada en la Fig. 15.
75
Fig.14 Niveles de madurez de CMM.
Fig. 15 Estructura de los niveles de madurez de CMM
Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está compuesto por un cierto número de Areas Claves de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA. Cada KPA 76
identifica una agrupación de actividades y prácticas relacionadas, las cuales cuando son realizadas en forma colectiva permiten lograr alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestión, Organizacional e Ingeniería. Las prácticas que deben ser realizadas por cada Área Clave de Proceso están organizadas en cinco características comunes (se describen mas adelante), las cuales constituyen atributos que indican si la implementación y la institucionalización de un proceso clave es efectivo, repetible y duradero. Metas: Representan el propósito, alcance y límites de cada área clave de Proceso. Pueden ser usadas para determinar si una organización o proyecto ha implementado efectivamente la KPA. Aspectos Comunes: Son atributos que indican si la implementación e institucionalización de un área clave de proceso es efectiva, repetible y duradera. Las prácticas clave se dividen en cinco secciones de aspectos comunes: Compromiso para Ejecutar Habilidad para Ejecutar Actividades Realizadas Medición y Análisis Verificación de Implementación Prácticas Clave: Cada área clave de proceso está descrita en términos de prácticas clave que, cuando son implementadas, ayudan a satisfacer las metas de esa área clave. Describen la infraestructura y actividades que mejor contribuyen a la implementación e institucionalización del área clave de proceso 77
La clasificación de las KPA’s se determinan de acuerdo al nivel de Madurez que se va alcanzando dentro del modelo CMM,cada KPA busca alcanzar ciertas metas, cuando se alcanzan todos los KPA’s de un Nivel se alcanza ese nivel.
NIVEL 5 KPA1. Administración de Cambios al Proceso KPA2. Administración de Cambios de Tecnología KPA3. Prevención de defectos NIVEL 4 KPA1. Administración de la Calidad del Software KPA2. Administración Cuantitativa del Proceso NIVEL 3 KPA1. Enfoque al Proceso Estándar de Software KPA2. Definición del Proceso Estándar de Software KPA3. Programa de Capacitación KPA4. Administración Integrada del Software KPA5. Ingeniería de productos de Software KPA6. Coordinación entre grupos de trabajo KPA7. Definición y enfoque del Proceso Organizacional NIVEL 2 KPA1. Administración de los requerimientos KPA2. Planeación del Proyecto (plan de trabajo) KPA3. Seguimiento y supervisión del plan de Trabajo KPA4. Aseguramiento de Calidad del Software en los proyectos KPA5. Administración de la Configuración KPA6. Administración de subcontratistas
Fig. 15 Áreas Clave de proceso por nivel de madurez en CMM
78
3.3.2 Nivel inicial . El nivel 1 o inicial es el estado primario en la evolución de las organizaciones que desarrollan software. Una definición amplia es que en este nivel se encuentran todas las empresas que no han logrado implementar las prácticas básicas de gestión de proyectos e ingeniería de software definidas a partir del nivel 2 o superiores. Una empresa está en el nivel caótico cuando sus gerentes y personal afirmen que los proyectos no se pueden planear, que los requerimientos no se pueden tener bajo control, que no esté siempre en condiciones de controlar las versiones de producto, donde la calidad sea percibida como una burocracia innecesaria, cuando se acepte que los procesos son una cosa personal, cuando no se pueda verificar ni validar el producto, y sobre todo, cuando sus gerentes y personal vivan bajo condiciones de stress y frustración permanentes. “Heroísmo, caos y emergencia permanente ‖
En este tipo de empresas, el software es virtualmente producto del arte más que de la ingeniería. Cada "artista" crea su propio proceso personal, el cual es parte de su sello personal. La gerencia ocupa una parte significativa de su tiempo en paliar problemas y enfrentar clientes insatisfechos. Ante una situación de crisis permanente, se les hace difícil destinar recursos para definir o documentar procesos, lo que lleva a un círculo sin salida. Cuando el proyecto se termina, la inversión hecha en desarrollar el proceso es raramente reutilizada en nuevos proyectos. Los desarrolladores de software generalmente tienen que trabajar largas horas y paliar problemas en forma cotidiana, lo cual les disminuye su creatividad y productividad netas. El éxito 79
descansa en los hombros de estos héroes, tal como en una película de acción americana. Su nivel de frustración es elevado y es muy frecuente que, como cualquier "diva", decidan explorar caminos en otras empresas con menor nivel de stress. El proceso, que no está documentado ni a sido compartido, se va con ellos, dentro de sus cerebros. Los reemplazantes heredan problemas y dificultades, pero son raramente capaces de recuperar los procesos de desarrollo. Esto obliga a reinventar la rueda, a un alto costo y retrasando los proyectos. He conocido un par de empresas que han llegado a la conclusión que es demasiado caro o difícil tratar de adivinar lo que el empleado anterior hizo, que les sale más a cuenta echar a la basura el desarrollo anterior y empezar todo de nuevo. En casos extremos hay que simplemente terminar el producto para no seguir perdiendo dinero o prestigio frente a los clientes. Futuro probable En los orígenes de la industria de software el caos predominó y las empresas que sobrevivieron la selección natural llegaron al mercado de nuestros días. La mayoría se extinguió en la gloria del triunfo efímero. Muchos de los actores actuales están predestinados a desaparecer en un futuro próximo. A pesar del talento de su personal y el despliegue de tecnología que puedan sustentar, derrochan su éxito debido a la debilidad de sus procesos de desarrollo.
80
3.3.3 Nivel repetido . El nivel 2 o Repetible hace posible la implementación de prácticas mínimas de administración de proyecto, de control de requerimientos, versiones de producto y de proyectos realizados por subcontratistas. El grupo o equipo humano que realizó el proyecto puede aprovechar su experiencia e inversión en procesos para aplicarla en un nuevo proyecto. Este nivel no garantiza que todos los proyectos dentro de la empresa estén necesariamente al mismo nivel de madurez. Algunos pueden estar todavía en el nivel inicial. He visto algunos casos en la práctica y en todos ellos estos proyectos fueron ineficientes con respecto a los de mayor madurez, malgastando el éxito de estos últimos. Eventualmente algunos invirtieron los esfuerzos necesarios para ponerse a tono, otros simplemente fueron cerrados con un elevado costo de frustración y descalabro de carreras profesionales. Beneficios de implantar el Nivel 2 del CMM El mayor beneficio obtenido de la implementación del nivel 2 por la empresa en la cual me desempeño actualmente, es la planificación realista de los proyectos. Antes los cronogramas de proyecto expresaban más l os deseos de la gerencia que la realidad. Este principio (el mismo en la cual se basa la magia) conducía una situación de buscar culpables y generar excusas, produciendo al mismo tiempo frustración y desconfianza entre clientes y empleados. Actualmente los cronogramas son cada día más confiables, y mejora a medida que se acumula más información en las bases de datos de los proyectos pasados. El uso generalizado de métodos de estimación permite al personal del proyecto de justificar plazos y recursos. Aún el "olfato profesional" y la experiencia personal juegan un papel importante en la generación de planes de 81
proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas como en el pasado. Descripción de las Áreas Clave de proceso para Nivel 2 CMM NIVEL 2 REPETIBLE KPA1. Administración de los requerimientos KPA2. Planeación del Proyecto (plan de trabajo) KPA3. Seguimiento y supervisión del plan de Trabajo KPA4. Aseguramiento de Calidad del Software en los proyectos KPA5. Administración de la Configuración KPA6. Administración de subcontratistas
Gestión de Requerimientos Propósito: Establecer una comprensión común entre el cliente y el proyecto, de los requerimientos del cliente que debe satisfacer el proyecto. Meta 1: Los requerimientos del sistema asignados al software son controlados para establecer un "baseline" para uso de la ingeniería de software y la gestión. Meta 2: Los planes, productos y actividades de software deben mantenerse consistentes con los requerimientos del sistema asignados al software. Planeamiento de Proyectos de Software Propósito: Establecer planes razonables para ejecutar la Ingeniería de Software y para administrar el proyecto de Software. Meta 1: Las estimaciones de software están documentadas para usar en el planeamiento y seguimiento del proyecto de software. Meta 2: Las actividades y compromisos del proyecto de software están planeadas y documentadas.
82
Meta 3: Los individuos y grupos afectados acuerdan sus compromisos vinculados con el proyecto de software. Seguimiento y Supervisión de Proyectos Propósito: Establecer una adecuada visibilidad del progreso real para que la gerencia pueda tomar medidas efectivas cuando se producen desvíos significativos del desempeño con respecto a los planes de software. Meta 1: Los resultados y desempeños se siguen contra los planes de software. Meta 2: Las acciones correctivas son tomadas y administradas cuando los resultados reales y el desempeño se desvían significativamente de los planes de software. Meta 3: Los cambios en los compromisos de software son acordados por los individuos y grupos afectados. Gestión de Subcontratación de Software Propósito: Seleccionar subcontratistas de Software calificados y administrarlos efectivamente. Meta 1: El principal contratista selecciona subcontratistas de software calificados. Meta 2: El principal contratista y el subcontratista de software acuerdan sus compromisos mutuos. Meta 3: El principal contratista y el subcontratista de software mantienen una comunicación regular. Meta 4: El contratista principal sigue los resultados y desempeño del subcontratista de software contra sus compromisos. Aseguramiento de Calidad de software 83
Propósito: Proporcionar a la gerencia la visibilidad apropiada del proceso usado en el proyecto y de los productos en construcción. Meta 1: Se planean la actividades de SQA. Meta 2: La adhesión de los productos y actividades de software a los estándares,
procedimientos
y
requerimientos
aplicables
se
verifica
objetivamente. Meta 3: Los grupos e individuos afectados son informados de las actividades y resultados de SQA. Meta 4: Los incumplimientos que no pueden resolverse dentro del proyecto de software son encarados por la alta gerencia. Gestión de Configuración de Software Propósito: Establecer y mantener la integridad de los productos de Software del proyecto a lo largo del ciclo de vida. Meta 1: Se planean las actividades de Gestión de configuración de software. Meta 2: Los Productos de trabajo de software seleccionados son identificados, controlados y están disponibles. Meta 3: Se controlan los cambios a productos de trabajo de software identificados. Meta 4: Los grupos e individuos afectados son informados del estado y contenidos de la "baseline" de los productos de software.
84
3.4 Nivel definido. La empresa ha definido un conjunto de procesos, metodologías y herramientas comunes a todos los proyectos iniciados por la corporación. El proceso común está suficientemente documentado en una biblioteca accesible a todos los desarrolladores. Todo el personal ha recibido el entrenamiento necesario para entender el proceso estándar. Existen pautas y criterios definidos para adaptar dicho proceso a las necesidades y características propias de cada proyecto. El nivel de definición es detallado y completo. La dependencia (o el riesgo de depender) en individuos irreemplazables es baja. Beneficios de implantar el Nivel 3 del CMM La base de datos que reúne estadísticas de los proyectos pasados y en curso, permite planificar y comparar el rendimiento. Existen mecanismos de comunicación entre proyectos y departamentos, lo que garantiza una visión común del producto y una rápida acción para enfrentar los problemas. He conocido unas pocas empresas a este nivel y la cosa que más me resaltó fue la satisfacción del personal. En empresas de nivel 1 habitualmente se escuchan quejas y acusaciones. A nivel 3 los empleados tienen una alta valoración de los procesos y entienden claramente la manera en que afectan su desempeño habitual. Los gerentes pueden realizar su verdadera función, administrar. El hecho de realizar revisiones tempranas en forma regular mejora visiblemente la calidad de los productos y minimiza las reiteraciones. Descripción de las Áreas Clave de proceso para Nivel 3 CMM NIVEL 3 DEFINIDO
85
KPA1. Enfoque al Proceso de la Organización KPA2. Definición del Proceso de software de la Organización KPA3. Programa de Capacitación KPA4. Administración Integrada del Software KPA5. Ingeniería de productos de Software KPA6. Coordinación intergrupal KPA7. Revisiones por pares
Enfoque en el Proceso de la Organización Propósito: Establecer la responsabilidad organizacional para las actividades del proceso de Software que mejoran la capacidad global del proceso de software. Meta 1: El proceso de desarrollo de software y las actividades de mejora son coordinadas a lo largo de la organización. Meta 2: Las fortalezas y debilidades del proceso de software utilizado están identificadas en relación al proceso estándar. Meta 3: Las actividades de desarrollo y mejora del proceso se planifican a nivel de la organización. Definición del Proceso de la Organización Propósito: Desarrollar y mantener un conjunto de recursos del proceso que mejoran el desempeño de los proyectos y proveen una base para obtener beneficios a largo plazo. Meta 1: Un proceso estándar software para la organización está desarrollado y es mantenido. Meta 2: La información relativa al uso por los proyectos de software del proceso estándar de software de la organización, se reúne, revisa y está disponible
86
Programa de Entrenamiento Propósito: Desarrollar las habilidades y el conocimiento de los individuos, para que ejecuten sus roles con efectividad y eficiencia [capacitación]. Meta 1: Las actividades de entrenamiento se planean. Meta 2: Se provee entrenamiento para el desarrollo de las habilidades y conocimientos necesarios para desempeñar los roles gerencial y técnico. Gestión Integrada de Software Propósito: Integrar las actividades de Ingeniería de Software y de Gestión en un proceso de Software coherente y definido, que es adaptado desde el proceso de software estándar de la organización y las evaluaciones de proceso relacionadas. Meta 1: El proceso de software definido para el proyecto es una versión adaptada del proceso estándar de software de la organización. Meta 2: El proyecto es planeado y administrado de acuerdo con el proceso de software definido para el proyecto Ingeniería de Producto de Software Propósito: Ejecutar consistentemente un proceso de ingeniería bien definido que integre todas las actividades de Ingeniería de Software para producir efectiva y eficientemente productos de Software correctos y consistentes. Meta 1: Las tareas de ingeniería de software están definidas, integradas y son consistentemente ejecutadas para producir el software. Meta 2: Los productos del trabajo de software se mantienen consistentes entre sí. 87
Coordinación Intergrupal Propósito: Establecer un medio para que el grupo de SE participe activamente con otros ingenieros para que el proyecto esté en mejores condiciones de satisfacer efectiva y eficientemente las necesidades del usuario. Meta 1: Los requerimientos del usuario son acordados por todos los grupos afectados. Meta 2: Los compromisos entre los grupos de ingeniería son acordados por los grupos afectados. Meta 3: El grupo de ingeniería identifica, rastrea y resuelve los aspectos intergrupales. Revisiones por Pares Propósito: Eliminar temprano y eficientemente defectos del Software. Meta 1: Se planean las actividades de revisión por pares. Meta 2: Se identifican y eliminan defectos de los productos de software.
88
3.3.5 Nivel administrado. En este nivel la corporación mide la calidad del producto y del proceso de software. Ambos, producto y proceso, son seguidos en forma cuantitativa y se controlan mediante métricas detalladas. La capacidad de rendimiento del proceso es previsible. Las mediciones permiten detectar cuando las variaciones del rendimiento se salen de los rangos aceptables, de manera de poder tomar medidas correctivas para asegurar la calidad. Beneficios de implantar el Nivel 4 del CMM La empresa es capaz de proponerse metas cuantitativas para la calidad de los productos y de los procesos de software. Es posible medir la productividad y calidad de los procesos de software a través de todo el proyecto. Los proyectos pueden controlar la variación del rendimiento de sus productos y procesos para mantenerla dentro de fronteras cuantitativas aceptables. Es posible discriminar las variaciones significativas en el rendimiento del proceso de la variación (ruido) al azar, particularmente dentro de líneas de productos establecidas. Es necesario aclarar que el hecho de contar con un sistema de métricas de software no significa que se esté en el nivel 4. He conocido muchas empresas de nivel 1 que miden cuidadosamente el número de defectos detectados durante las pruebas o tests (no es casualidad que les interese tanto!). Es una virtual señal de alarma que les dice cuán graves son sus problemas, pero la inmadurez de sus procesos no les permite hacer nada efectivo, excepto tal vez abortar el producto para evitar un daño mayor que puede resultar de distribuirlo a los clientes. Descripción de las Áreas Clave de proceso para Nivel 4 CMM 89
NIVEL 4 GESTIONADO (ADMINISTRADO) KPA1. Administración de la Calidad del Software KPA2. Administración Cuantitativa del Proceso
Administración de la Calidad del Software Propósito: Desarrollar una comprensión cuantitativa de la calidad de los productos de software y alcanzar objetivos específicos de calidad. Meta 1: Se planean las actividades de gestión de calidad del proyecto de software. Meta 2: Están definidas metas medibles para la calidad del producto de software y sus prioridades. Meta 3: El progreso real para alcanzar las metas de calidad de los productos de software está cuantificado y administrado. Administración cuantitativa del proceso Propósito: Controlar cuantitativamente la performance del proceso del proyecto de software. Meta 1: Se planean las actividades de gestión cuantitativa el proceso. Meta 2: El desempeño del proceso de software definido para el proyecto se controla cuantitativamente. Meta 3: La capacidad del proceso estándar de software de la organización es conocido en términos cuantitativos.
90
3.3.6 Nivel optimizado.
En el Nivel Optimizado, la característica principal es el mejoramiento continuo del proceso, en base a la realimentación cuantitativa y al ensayo de ideas y tecnologías innovadoras. Beneficios de implantar el Nivel 5 del CMM La organización entera se aboca al mejoramiento continuo del proceso. La corporación cuenta con los medios para identificar las debilidades y reforzar en forma proactiva el proceso, con objeto de prevenir la ocurrencia de defectos. Los datos relativos a la eficacia del proceso de software se usan para analizar el costo y el beneficio de usar nuevas tecnologías y de implementar cambios al proceso de software. Los proyectos de software analizan los defectos para determinar sus causas. Los proceso de software se evalúan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos. Descripción de las Áreas Clave de proceso para Nivel 5 CMM NIVEL 5 OPTIMIZADO KPA1. Administración de Cambios al Proceso KPA2. Administración de Cambios de Tecnología KPA3. Prevención de defectos
91
Administración de Cambios al Proceso Propósito: Mejorar continuamente el proceso para incrementar: Calidad del Software, Productividad, Disminuir tiempo de desarrollo de productos. Meta 1: Se planea la mejora continua del proceso de cambio. Meta 2: Toda la organización participa en las actividades de mejora del proceso. Meta 3: El proceso estándar de la organización y el proceso de software definido para el proyecto, se mejoran continuamente. Administración de cambios de Tecnología Propósito: Identificar las nuevas tecnologías beneficiosas (herramientas, métodos, procesos) y transferirlos a la organización. Meta 1: La incorporación de cambios en la tecnología se planea. Meta 2: Las nuevas tecnologías son evaluadas para determinar su efecto sobre la calidad y productividad. Meta 3: Las nuevas tecnologías se transfieren a la práctica normal a los largo de la organización. Prevención de Defectos Propósito: Identificar la causa de los defectos y prevenirlos. Meta 1: Prevención de defectos. Meta 2: Causas comunes de defectos son pesquisadas e identificadas. Meta 3: Causas comunes de defectos son priorizadas y sistemáticamente eliminadas. 92
Comparación de CMM con ISO y SPICE Una vez presentados los modelos ISO, SPICE y CMM es conveniente hacer una comparativa de los mismos considerando varios aspectos: CMM – ISO Aspecto: Énfasis La principal diferencia entre los modelos ISO –CMM es que CMM hace hincapié en la mejora continua del proceso. Otra diferencia reside en que CMM focaliza estrictamente en Software, mientras que ISO 9001 tiene un alcance mucho más amplio, que comprende software, hardware, materiales procesados y servicios. Aspecto: Nivel de Detalle La principal diferencia entre los modelos ISO –CMM es el nivel de detalle que difiere significativamente, la sección 4 en ISO 9000tiene alrededor de 12 páginas de largo, contra más de 500 páginas de CMM. El alto nivel de abstracción de ISO puede causar que los auditores interpreten el estándar de maneras diferentes. Aspecto: Auditores Los auditores son entrenados en los estándares de la Serie ISO 9000, pero no son entrenados en conocimiento sobre aspectos específicos de software. Para auditorias específicas de software debería integrarse al equipo personas con conocimientos en la disciplina. 93
Otra razón de discrepancia es que un Auditor puede no requerir maestría para satisfacer la correspondencia con la cláusula de ISO 9001. Comparación CMM -SPICE Aspecto: Evolución del Proceso SPICE Los niveles de capacidad son aplicados sobre los procesos. Agrega el nivel 0: un nivel puede no ser ejecutado para nada. Ventaja: Mayor granularidad en la medición y análisis. Desventaja: Procesos menos importantes pueden ocultar aspectos que no se definieron como prioritarios. CMM Los niveles de madurez organizacional pueden definirse como un conjunto de perfiles para los procesos de SPICE. Las KPA pertenecen a un único nivel de madurez. Los procesos que no están descriptos en CMM, también existen y evolucionan. Ventaja: Focaliza en pocas áreas ―vitales‖ que comúnmente bloquean la performance del proceso. Desventaja: La gente puede perder el seguimiento de los procesos que no están focalizados en algún nivel particular, pero que aún así deben realizarse.
94
Aspecto: Determinación de Prioridades de Mejoramiento SPICE No prescribe ningún camino particular de mejora. Las prioridades son dejadas completamente a la organización. Los procesos individuales pueden ser mejorados continuamente. Los niveles de capacidad miden un proceso específico .Desventaja: Puede ser difícil decidir que aspectos atacar primero. CMM Construye la capacidad del proceso focalizando en pocos aspectos vitales para la organización en su totalidad. Los niveles de madurez priorizan los problemas de software generales. Desventaja: prescriba atacar aspectos de gestión de proyecto antes que los de ingeniería.
Ejemplo de Aplicación sobre un Área Clave de Proceso del Nivel 2: Planificación de Proyectos de Software El ejemplo siguiente tiene como propósito detallar mas claramente como son especificados cada una de las prácticas para cumplir con una área clave de proceso (KPA), que en este caso es la Planificación de Proyectos de Software para un nivel 2 (Repetido) de CMM. Vale la pena hacer énfasis que se han agrupado las principales características para una mejor comprensión, los estudiantes pueden realizar como ejercicio propuesto investigar para otras KPAS o un buen ejercicio es checar si estas prácticas son llevadas a cabo en algún desarrollo de un proyecto de software.
95
AREA CLAVE 2.2 Planificación de Proyectos de Software Propósito: Establecer planes razonables para ejecutar la Ingeniería de Software y para administrar el proyecto de Software. Estos planes son la base de la gestión del proyecto, 2.3.(siguiente KPA) _____________________________________________________________ Meta 1: Las estimaciones de software están documentadas para usar en el planeamiento y seguimiento del proyecto el software. Meta 2: Las actividades y compromisos del proyecto de software están planeadas y documentadas. Meta 3: Los individuos y grupos afectados acuerdan sus compromisos vinculados con el proyecto de software. ______________________________________________________ Compromiso para la ejecución 1. Un gerente de proyectos de software es designado responsable de negociar los compromisos y desarrollar el plan del proyecto de desarrollo de software. 2. Para el planeamiento de un proyecto de software (PSw), el proyecto sigue una política organizacional escrita Compromiso 1 Esta política comúnmente establece que: 1. Los requerimientos del sistema asignados al software son usados como base para la planificación del proyecto de software. 2. Los compromisos del proyecto de software son negociados entre: El gerente de proyecto, el gerente de proyecto de software, y otros administradores. 3. La intervención de otros grupos en las actividades de software es negociada con estos grupos y documentada. Ejemplos de otros grupos de ingeniería incluyen: Ingeniería de Sistemas, Ingeniería de Hardware, Prueba de Sistema. 96
4. Los grupos afectados revisan el proyecto de software: Estimación de tamaño del software, Estimación del esfuerzo y el costo, programas, y otros compromisos. Ejemplos de otros grupos afectados: Ingeniería de software (incluyendo todos los subgrupos tales como diseño de software), Estimación de software, Ingeniería de sistema, Prueba de sistema, Aseguramiento de la calidad del software,
Gestión de Configuración de
Software , Gestión de contratos y, Soporte de documentación. 5. La gerencia revisa todos los compromisos del proyecto de software hechos a individuos y grupos externos de la organización. 6. El plan de desarrollo de software del proyecto es gestionado y controlado. _____________________________________________________________ Habilidad para ejecutar 1. Existe una orden de trabajo documentada y aprobada para el PSw. 2. Se asignan responsabilidades para el desarrollo del plan de desarrollo de software. 3. Se proveen adecuados recursos y fondos para el planeamiento del PSw. 4. Los gerentes de software, los ingenieros de software y otrosindividuos involucrados en el planeamiento del PSw están entrenados en los procedimientos de estimación y planeamiento aplicables a su área de responsabilidad. Hab 1. Existe una orden de trabajo documentada y aprobada para el PSw. 1. La Orden de Trabajo abarca: alcance del trabajo, objetivos y metas técnicas, identificación de clientes y usuarios finales, estándares impuestos 97
responsabilidades
asignadas,
restricciones
y
objetivos
de
costos
y
cronogramas, dependencias entre el PSw y otras organizaciones, restricciones y objetivos de los recursos, otras restricciones y objetivos para desarrollo y mantenimiento 2. La orden de trabajo es revisada por: gerente de proyecto, gerente del PSw, otros gerentes de software, otros grupos afectados. 3. La directiva de trabajo es administrada y controlada. Hab 2. Se asignan responsabilidades para el desarrollo del plan de desarrollo de software. 1.El gerente del PSw, directamente o por delegación, coordina el planeamiento del PSw. 2.Las responsabilidades por los productos del trabajo de software y las actividades se asignan a los gerentes de software en una forma rastreable y contabilizable. Hab 3. Se proveen adecuados recursos y fondos para el planeamiento del PSw . 1.Cuando es factible individuos con experiencia se asignan al desarrollo del plan. 2.Se dispone de herramientas para soportar el planeamiento de las actividades del PSw _____________________________________________________________
Actividades ejecutadas
98
1. El grupo de Ingeniería de Software participa en el equipo que propone el proyecto. 2. El planeamiento del proyecto de software se inicia en las etapas iniciales y en paralelo con el planeamiento global del proyecto. 3. A lo largo de la vida del proyecto el grupo de Ingeniería de Software participa junto con otros grupos afectados, en el planeamiento global del proyecto. 4. Los compromisos del proyecto de software hechos por individuos y grupos ajenos a la organización son revisados con la gerencia senior de acuerdo a un procedimiento documentado. 5. Está identificado o definido un ciclo de vida con etapas predefinidas de tamaño manejables. 6. El plan del proyecto de desarrollo de software se desarrolla de acuerdo a un procedimiento documentado. 7. El plan para el proyecto de software está documentado. 8. Lo productos del trabajo de software que se necesitan establecer y mantener están identificados. 9. Las estimaciones del tamaño de los productos del trabajo de software (o cambios de ese tamaño) son derivadas de acuerdo a un procedimiento documentado. 10.
Las estimaciones del esfuerzo y costo del proyecto de software son
derivadas de acuerdo a un procedimiento documentado. 11.
Las estimaciones de los recursos críticos de computadoras son derivadas
de acuerdo a un procedimiento documentado. 12.
El cronograma del proyecto de software se deriva de acuerdo a un
procedimiento documentado. 13.
Los riesgos de software asociados con costos, recursos, cronogramas y
aspectos técnicos del proyecto están identificados, establecidos y documentados. 14.
Se preparan planes para las facilidades y herramientas de soporte a
ingeniería de software del proyecto. 99
15.
Se registran los datos del planeamiento del software.
Medición y análisis Las mediciones se hacen y se usan para determinar el estado de las actividades de planeamiento de software. Ejemplos de mediciones incluyen: Trabajo completado, esfuerzo gastado, fondos gastados en las Cumplimiento de hitos para las actividades planificadas en el proyecto de software, comparado con el plan. Actividades planificadas en el proyecto de software, comparadas con el plan. _____________________________________________________________ Verificación de la implementación 1.Las actividades para planear el proyecto de software son revisadas periódicamente con la gerencia senior. 2.Las actividades para planear el proyecto de software son revisadas periódicamente con el gerente de proyecto y en respuesta a eventos. 3.El grupo de aseguramiento de calidad de software revisa y/o audita las actividades y productos del trabajo para planear el proyecto de software e informa los resultados. Verificación 1 Las actividades para planear el proyecto de software son revisadas periódicamente con la gerencia senior. 1.Se revisa la performance técnica, del personal, de costos y de programación. 100
2.Los conflictos y aspectos no resueltos en niveles más bajos son direccionados. 3.Los riesgos asociados al Proyecto de Software son direccionados. 4.Los ítems son asignados, revisados y rastreados hasta el cierre. 5.Un reporte de resumen de cada reunión se prepara y distribuye a los individuos y grupos afectados. Verificación 2 Las actividades para planear el proyecto de software son revisadas periódicamente con el gerente de proyecto y en respuesta a eventos. 1.Están representados los grupos afectados. 2.El estado y los resultados actuales de las actividades de la planificación del proyecto de software son revisadas con la definición del trabajo y los requerimientos. 3.Son direccionadas las dependencias entre grupos.. 4.Son direccionados los conflictos y aspectos no resueltos en los nivele más bajos. 5.Son revisados los riesgos del proyecto. 6.Los ítems de acción son asignados, revisados y rastreados hasta su cierre. 7.Un reporte de resumen de cada reunión se prepara y distribuye a los individuos y grupos afectados. Verificación 3 El grupo de aseguramiento de calidad del software revisa y/o audita las actividades y productos del trabajo para planear el proyecto de software e informa los resultados. Como mínimo, los revisores y/o auditores verifican: 1. Las actividades para la estimación y planificación de software. 2. Las actividades para revisión y concreción de compromisos de lproyecto.. 3. Las actividades para la preparación del Plan de Desarrollo de Software. 4. El estándar utilizado para la confección del Plan de Desarrollo de Software. 101
5. El contenido del Plan de Desarrollo de Software. _____________________________________________________________ Cuestionario de madurez ¿Las estimaciones (tamaño, costo, cronograma, etc) se documentan para usar en el planeamiento y seguimiento del proyecto de software? ¿Los planes de software documentan las actividades a ser ejecutadas y los compromisos hechos? ¿Todos los grupos e individuos acuerdan son compromisos relacionados con el proyecto? ¿El proyecto sigue una política organizacional escrita para planear el proyecto? ¿Se proveen recursos adecuados para el planeamiento del proyecto (fondos, personal con experiencia, etc.) ¿Se usan mediciones para determinar el status de las actividades de planeamiento (ejemplo: los hitos completados se comparan con el plan)? ¿El gerente de proyecto revisa las actividades de planeamiento sobre la base de períodos y eventos? _____________________________________________________________ Conclusiones del CMM
Una forma de ocuparnos de la calidad es a través de la mejora del proceso de desarrollo de software. Como modelo de madurez y capacidad, CMM representa una de las alternativas mas efectivas y difundidas en todo el mundo para guiar a las organizaciones de software en la selección de estrategias para el mejoramiento de sus procesos de desarrollo. 102
CMM describe un camino evolutivo de cinco niveles madurez en el cual cada nivel nos indica áreas claves de proceso y nos lleva desde un proceso inicial o ad hoc hasta un proceso maduro o disciplinado. Los principales beneficios que provee son: mejorar la calidad de los productos, aumentar tiempo de respuesta al mercado e incrementarla productividad de la organización.
3. 4 MOPROSOFT (Modelo de Procesos para la Industria de Software) La Secretaría de Economía (SE) definió el Programa para el Desarrollo de la Industria de Software (PROSOFT que formaba parte del Plan Nacional de Desarrollo 2001-2006. PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos". Al comenzar el desarrollo de esta línea estratégica se evaluó la adopción de los modelos: ISO 9000, ISO 15504, SW-CMM. El resultado de la evaluación fue: "Ninguno de los estándares o modelos cumple con los requisitos expresados por la industria nacional", y se decidió la elaboración de un modelo adecuado para las características de las empresas mexicanas, que se basaría en los modelos evaluados. En base a esta decisión la Secretaría de Economía encargó la elaboración de dicho modelo a la Asociación Mexicana para la Calidad en Ingeniería del Software (AMCIS) en colaboración con la Universidad Nacional Autónoma de México (UNAM). La primera versión de MoProSoft se publicó en diciembre de 2002. El Plan Nacional de Desarrollo (PND) 2001-2006 de México plantea el objetivo de mejorar la competitividad del país mediante la promoción, uso y 103
aprovechamiento de la tecnología e información. En dicho plan la Secretaría de Economía definió el Programa para el Desarrollo de la Industria del Software. El propósito de este Modelo de Procesos para la Industria de Software (MoProSoft) en México fue: fomentar la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software, permitiendo elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Para proporcionar este modelo fue necesario considerar que se debía proporcionar a la industria de software en México, que en su gran mayoría es pequeña y mediana, un modelo basado en las mejores prácticas internacionales con las siguientes características: • Fácil de entender • Fácil de aplicar • No costoso en su adopción • Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas,
tales como ISO 9000:2000 [1] o CMM®1 V1.1 El modelo de procesos MoProSoft está dirigido a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software. Las organizaciones, que no cuenten con procesos establecidos, pueden usar el modelo ajustándolo de acuerdo a sus necesidades. Mientras que las organizaciones, que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir. MoProSoft y su método de evaluación EvalProSoft, propuesta de Secretaría de Economía para la PyME de desarrollo de software, fueron entregados en junio 2004 al NYCE, organismo responsable de la normalización y certificación en México. La norma técnica a la que da contenido es la NMX-059/01-NYCE-2005 104
que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el Diario de la Federación. El objetivo de esta norma es proveer acceso a las prácticas de ingeniería de software de clase mundial y contar con un método de evaluación propio. MoProSoft considera que los modelos de evaluación y mejora, CMMI e ISO/IEC 15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo y mantenimiento de software. MoProSoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de procesos de los niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y conceptos de PMBOK Y SWEBOK.
3.4.1 Generalidades y Estructura. Para la elaboración del modelo de procesos MoProSoft, fueron aplicados los siguientes criterios: 1. Generar una estructura de los procesos que esté acorde con la estructura de las organizaciones de la industria de software (Alta Dirección, Gestión y Operación). 2. Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora continua como el promotor del buen funcionamiento de la organización. 3. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización. 105
4. Considerar a la Operación como ejecutor de los proyectos de desarrollo y mantenimiento de software. 5. Integrar de manera clara y consistente los elementos indispensables para la definición de procesos y relaciones entre ellos. 6. Integrar los elementos para la administración de proyectos en un sólo proceso. 7. Integrar los elementos para la ingeniería de productos de software en un solo marco que incluya los procesos de soporte (verificación, validación, documentación y control de configuración). 8. Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentación de procesos y los datos recaudados a partir de su uso y lecciones aprendidas. 9. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMM ® V.1.1. Usar como marco general ISO/IEC 15504 - Software Process Assesment e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK, SWEBOK y otros más especializados.
106
Estructura El modelo de procesos (MoProSoft) tiene tres categorías de procesos: Alta Dirección, Gerencia y Operación que reflejan la estructura de una organización.
Fig. 16 Diagrama de categorías de los procesos en MoProSoft.
La categoría de Alta Dirección contiene el proceso de Gestión de Negocio. La categoría de Gerencia está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización.
La categoría de Operación está integrada por los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software. 107
En cada proceso están definidos los roles responsables por la ejecución de las prácticas. Los roles se asignan al personal de la organización de acuerdo a sus habilidades y capacitación para desempeñarlos.
En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de Proceso y otros roles involucrados. Además se considera al Cliente y al Usuario como roles externos a la organización.
MoProSoft al igual que otros Modelos de Proceso, también
cuenta con sus
niveles de capacidades como se muestra en la Fig. 16. Los colores mostrados representan los niveles para la versión escrita 1.3 Por niveles de capacidad, esto quiere decir que las partes coloreadas de la norma sugieren un orden de la implementación de las prácticas de los procesos de MoProSoft partiendo de las prácticas básicas, correspondientes a nivel1, e incorporando las prácticas que corresponden a los niveles más avanzados.
NIVEL
Capacidad de proceso
Color
1
REALIZADO
Amarillo
2
GESTIÓNADO
Azul
3
ESTABLECIDO
Verde
4
PREDECIBLE
Rosa
5
OPTIMIZADO
Ninguno
Fig.16 Correspondencia de los niveles de capacidad de Moprosoft.
Así mismo para una mejor comprensión del modelo y sus procesos vale la pena tomar en cuenta las siguientes definiciones:
108
Concepto Categoría de procesos
Descripción Un conjunto de procesos que abordan la misma área general de actividad dentro de una organización.
Proceso
Conjunto de prácticas relacionadas entre si, llevadas a cabo a través de roles y por elementos automatizados, que utilizando recursos y a partir de insumos producen un satisfactor de negocio para el cliente.
Objetivo
Fin a que se dirige o encamina una acción u operación.
Indicador
Mecanismo que sirve para mostrar o significar una cosa con evidencias y hechos. Es responsable por un conjunto de actividades de uno o más procesos. Un rol puede ser asumido por una o más 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 ejecución de un proceso. Conjunto de tareas específicas asignadas para su realización a uno o más 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 aplicación especificada o uso previsto. Esquema que expresa las relaciones entre las actividades de un proceso. Una relación puede ser secuencial, paralela, cíclica, de selección o anidada. Modificación a las prácticas, entradas y salidas de un proceso, siempre y cuando no afecten al cumplimiento de sus objetivos. Hacer diligencias conducentes al logro de un negocio. Organizar trabajo y disponer recursos.
Rol Producto Práctica Actividad Verificación Validación Flujo de trabajo Guía de ajuste Gestión Administración Organización Infraestructura Medición
Empresa o área interna de una organización dedicada al desarrollo y/o mantenimiento de software. Conjunto de elementos o servicios que se consideran necesarios para la creación y funcionamiento de una organización. Acción o efecto de medir.
Base de conocimiento
Es un repositorio de todos los productos tales como productos de software, planes, reportes, registros, lecciones aprendidas y otros documentos.
Situación excepcional
Circunstancia que impide el desarrollo de una actividad.
Lección aprendida Prospección
Experiencia positiva o negativa obtenida durante la realización 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 análisis de los datos reunidos previamente.
109
Patrón de procesos de MoProSoft El patrón de procesos es un esquema de elementos que servirá para la documentación de los procesos, se encuentra constituido por tres partes: Definición general del proceso: Aquí se identifica su nombre, categoría a la que pertenece, propósito, descripción general de sus actividades, objetivos, indicadores, metas cuantitativas, responsabilidad y autoridad, subprocesos en caso de tenerlos, procesos relacionados, entradas, salidas, productos internos y referencias bibliográficas. Prácticas: En esta parte se identifican los roles involucrados en el proceso y la capacitación requerida, se describen las actividades en detalle, asociándolas a los objetivos del proceso, se presenta un diagrama de flujo de trabajo, se describen las verificaciones y validaciones requeridas, se listan los productos que se incorporan a la base de conocimiento, se identifican los recursos de infraestructura necesarios para apoyar las actividades, se establecen las mediciones del proceso, así como las prácticas para la capacitación, manejo de situaciones excepcionales y uso de lecciones aprendidas. Guías de ajuste: En este apartado se sugieren modificaciones al proceso que no deben afectar los objetivos del mismo. A continuación se muestra la descripción del patrón de procesos, esto debe considerarse como una guía al momento de consultar cada uno de los procesos, el orden y las imágenes que aquí se presentan es como lo establece la versión 1.3 y como lo encontrarán en las versiones disponibles al público por parte del NYCE.
110
111
112
113
El patrón de procesos fue utilizado como esquema para documentar los procesos de MoProSoft. Las organizaciones que adopten el modelo de procesos pueden adecuarlo a sus necesidades siguiendo las reglas de la sección 6. El patrón de procesos que utilicen las organizaciones puede ser distinto del sugerido en este modelo, pero debe de preservar los objetivos, indicadores y metas cuantitativas correspondientes para lograr el propósito general de MoProSoft. El patrón de proceso puede ser utilizado para documentar e integrar otros procesos que no fueron contemplados en el modelo .
3.4.2 Categoría de Alta Dirección (DIR) Categoría de procesos que aborda las prácticas de Alta Dirección relacionadas con la gestión del negocio. Proporciona los lineamientos a los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos. El proceso que la conforma es: DIR.1 Gestión de Negocio El propósito de Gestión de Negocio es establecer la razón de ser de la organización, sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para poder proponer cambios que permitan la mejora continua. Adicionalmente habilita a la organización para responder a un ambiente de cambio y a sus miembros para trabajar en función de los objetivos establecidos. Este proceso se compone de la planificación estratégica, la preparación para la realización de la estrategia, y la valoración y mejora continua de la organización.
114
Objetivos Lograr una planificación estratégica exitosa mediante el cumplimiento del Plan estratégico. Lograr que la organización trabaje en función del Plan Estratégico mediante la correcta comunicación e implantación del mismo. Mejorar el plan estratégico mediante la implementación de la propuesta de mejoras.
3.4.3 Categoría de Gerencia (GER) Categoría de procesos que aborda las prácticas de gestión de procesos, proyectos y recursos en función de los lineamientos establecidos en la Categoría de Alta Dirección. Proporciona los elementos para el funcionamiento de los procesos de la Categoría de Operación, recibe y evalúa la información generada por éstos y comunica los resultados a la Categoría de Alta Dirección.
GES.1 Gestión de Procesos. El propósito de Gestión de Procesos es establecer los procesos de la organización, en función de los procesos requeridos identificados en el plan estratégico. Así como definir, planificar, e implantar las actividades de mejora en los mismos. Se compone de las siguientes actividades: planificación de procesos, preparación a la implantación y la evaluación y control de procesos. Objetivos: Planificar las actividades de definición, implantación y mejora de los procesos en función del plan estratégico. Dar seguimientos a las actividades de definición, implantación y mejora de los procesos mediante el cumplimiento del plan de procesos. Mejorar el desempeño de los procesos mediante el cumplimiento del plan de mejora.
115
Mantener informado a Gestión de Negocio sobre el desempeño de los procesos mediante el Reporte Cuantitativo y Cualitativo. GES.2 Gestión de Proyectos. El propósito de la Gestión de Proyectos es asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización. Se ocupa de los proyectos externos, internos y de las oportunidades de proyectos de la organización. Para las oportunidades de proyectos, se debe realizar la generación y cierre de oportunidades de proyectos, la presentación de propuesta y firma de contrato. Para los proyectos internos antes de su aprobación, se requiere evaluar diferentes alternativas de realización. Los proyectos internos y externos aprobados requieren de una planificación general y asignación de los recursos, asi como un seguimiento y evaluación de desempeño. La gestión de proyectos comprende la planificación, la realización y la evaluación y control. Objetivos: Cumplir con el Plan Estratégico de la organización mediante la generación e instrumentación de proyectos. Mantener bajo control las actividades de Gestión de Proyectos mediante el cumplimiento del Plan de Gestión de Proyectos. Proveer la información del desempeño de los proyectos a Gestión de Negocio mediante la generación del Reporte Cuantitativo y cualitativo. Atender los comentarios y quejas del cliente mediante la definición y ejecución de acciones preventivas o correctivas. GES.3 Gestión de Recursos. El propósito de GES.3 es conseguir y dotar a la organización de los recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como crear y mantener la base de conocimiento de la organización. La finalidad es apoyar el cumplimiento de los objetivos del plan estratégico de la organización. 116
Se compone de las siguientes actividades: la planificación, seguimiento y control de recursos, e investigación de tendencias tecnológicas, apoyadas con tres subprocesos: Recursos Humanos y ambiente de trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización. Objetivos: Lograr los objetivos del Plan Estratégico mediante la provisión de los recursos suficientes y calificados a la organización. Proveer a los miembros de la organización de los medios y mecanismos adecuados para el uso y resguardo de la información mediante la Base de Conocimiento. Mantener a la organización informada oportunamente sobre las tendencias
tecnológicas
mediante
la
elaboración
de
propuestas
tecnológicas.
GES.3.1 Recursos Humanos y Ambiente de Trabajo. Su propósito es proporcionar los recursos humanos adecuados para cumplir las responsabilidades asignadas a los roles dentro de la organización, así como la evaluación del ambiente de trabajo. En función del Plan operativo de Recursos Humanos y ambiente de trabajo y Acciones correctivas de Gestión de Recursos se realizan las actividades de preparación, instrumentación y generación de reportes. Objetivos: Proveer a la organización de recursos humanos calificados mediante la selección y capacitación adecuada a los roles que les asignen. Evaluar el ambiente de trabajo de la organización mediante la encuesta sobre el ambiente de trabajo. 117
GES.3.2 Bienes, Servicios e Infraestructura. Su propósito es proporcionar proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisición y proyectos. En función del Plan Operativo de Bienes, Servicios e Infraestructura y Acciones correctivas de Gestión de Recursos, se realizan las actividades de preparación, instrumentación y generación de reportes. Objetivos : Proporcionar a la organización los bienes y servicios requeridos por los procesos y los proyectos mediante la selección y evaluación de los proveedores. Mantener la infraestructura de la organización mediante el cumplimiento del plan de mantenimiento. GES.3.3 Conocimiento de la organización. Su propósito es mantener disponible y administrar la base de conocimiento que contiene la información y los productos generados por la organización. En función del Plan Operativo de Conocimiento e la Organización y las acciones correctivas de Gestión de Recursos se realizan las siguientes actividades: Planificación, Realización, Evaluación y control para generar periódicamente un reporte del estado de la Base del conocimiento. Su objetivo es: Proporcionar ala organización la Base de Conocimiento de forma confiable, oportuna y segura mediante el cumplimiento del plan de administración de la Base del Conocimiento.
3.4.4 Categoría de Operación (OPE) Esta categoría de procesos aborda las prácticas de los proyectos de desarrollo y mantenimiento de software. Esta categoría realiza las actividades de acuerdo 118
a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos generados. Los procesos que contiene esta categoría son los siguientes: OPE.1 Administración de Proyectos Específicos .Establece y lleva a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados. Aplica conocimientos, habilidades, técnicas y herramientas, a cada una de las siguientes actividades: Planificación, Realización, Evaluación y control y cierre. Sus objetivos son: Logar los objetivos del proyecto en tiempo y costo mediante la coordinación y el manejo de los recursos del mismo. Mantener informado al cliente mediante la realización de reuniones de avance del proyecto. OPE.2 Desarrollo y Mantenimiento de Software Realizar sistemáticamente las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados, cumpliendo con los requerimientos especificados. Para el estudiante será interesante éste apartado dado que se encuentra en fase de aprendizaje de la construcción de sistemas de información o productos de software, por lo que para ésta norma se mencionan las actividades en el proceso de desarrollo. El proceso de desarrollo y mantenimiento de software se compone de uno o más ciclos de desarrollo, cada ciclo está compuesto de las fases siguientes: INICIO: Se revisa el plan de desarrollo por los miembros del equipo de trabajo para lograr un entendimiento común del proyecto y para obtener el compromiso de su realización. 119
REQUERIMIENTOS: Conjunto de actividades cuya finalidad
es obtener la
documentación de la Especificación de Requerimientos y Plan de Pruebas al Sistema, para conseguir un entendimiento común entre el cliente y el proyecto. ANALISIS Y DISEÑO: Conjunto de actividades en las cuales se analizan los requerimientos especificados para producir una descripción de la estructura de los componentes del software, la cual servirá de base para la construcción. Como resultado se obtiene la documentación de análisis y diseño y Plan de pruebas de integración. CONSTRUCCION: Conjunto de actividades para producir componentes de software que correspondan al análisis y Diseño así como la realización de pruebas unitarias. Como resultado se obtienen los componentes de software probados. INTEGRACIÓN Y PRUEBAS: Integrar y probar los componentes de software, basándose en los planes de pruebas de Integración y de Sistema, con la finalidad de obtener el software que satisfaga los requerimientos especificados. Se genera la versión final del Manual de Usuario, Manual de Operación y Manual de mantenimiento. Como resultado se obtiene el producto de software probado y documentado. CIERRE: Integración final de la configuración de software generada en las fases para su entrega, Identificación y documentación de las Lecciones Aprendidas, Generación de Reporte de Mediciones y Sugerencias de Mejora.
120
Objetivos: Lograr que los productos de salida sean consistentes con los productos de entrada en cada fase de un ciclo de desarrollo mediante las actividades de verificación, validación o prueba. Sustentar
la
realización
de
ciclos
posteriores
o
proyectos
de
mantenimiento futuros mediante la integración integración de la configuración configuración de software del ciclo actual. Llevar a cabo las actividades de fases de inicio de un ciclo mediante el cumplimiento del plan de desarrollo actual.
3.5 Preguntas de repaso y prácticas sugeridas.
1. Investigar qué empresas se han certificado en las distintas normas aquí presentadas, cuales han sido las ventajas obtenidas para dichas empresas.
2. Discutir en grupo sobre las diferencias y semejanzas entre una norma aplicada a la calidad de software.
3. Investigar las prácticas correspondientes a los primeros niveles de madurez o de capacidad, aplicarlas o verificarlas con el proyecto de software a realizar.
4. Comparar los diferentes modelos o normas que pueden aplicarse al desarrollo de software. 121
5. Discutir en clase sobre el impacto que ha tenido la implantación de la norma Moprosoft en nuestro país. 6. Tomando en cuenta el ejemplo citado para la evaluación de un área de proceso como lo es la Planeación del del proyecto de software, invite a los equipos a emular una evaluación a la planeación de su proyecto, una vez que estos hayan realizado al menos un ciclo de desarrollo. También puede aplicarse la realización del postmortem como se explica en el anexo 3 de este texto. 7. Para equipos o estudiantes de semestres avanzados y con mayores fortalezas en el desarrollo de software, puede sugerir realizar su producto de software bajo bajo una norma propuesta, los mismos estudiantes decidirán decidirán las herramientas y modelos a aplicar, otros equipos también pueden hacer el rol de evaluadores o testers de pruebas al mismo software. Se recomienda que sean proyectos de software que han sido continuados en otras materias o que llevan un tiempo tiem po desarrollándose.
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
explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente‖. La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad,
corrección,
confiabilidad,
mantenibilidad,
portabilidad,
usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación. La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software software.. 123
4.2 Cómo obtener calidad de software. A través de todo este texto se han mostrado las distintas normas y prácticas existentes tanto a nivel internacional como nacional, y que la mayoría de ellas hacen especial énfasis en el proceso que implica el desarrollo así como la gestión de recursos implicados y el desarrollo del producto. Las diversas herramientas y métodos también fueron mostrados en el apartado 2.8., en conjunto todas ellas hacen que las mejores prácticas de desarrollo puedan llevarse a cabo y
sean útiles en el proceso del
mejoramiento del producto de software. La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico. El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software. El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado. La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.
124
4.3 Cómo controlar la calidad del software. Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir". Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura. Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos: Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
125
Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.
4.4 Costo de la calidad del software. Incluye costos tanto de la búsqueda de calidad como de las acciones realizadas para su obtención. Los costes de calidad pueden dividirse según el enfoque en: Costos de prevención: Planificación de la calidad, revisiones técnicas formales, equipo de pruebas, formación. Costos de evaluación: para tener una visión de la calidad real del producto, incluye la inspección en el proceso y entre procesos,calibrado y mantenimiento del equipo. Costes de fallos, que pueden dividirse en costos internos o externos. Internos: errores antes de la entrega del producto al cliente( Revisión, reparación, análisis de las modalidades de fallos). Externos: errores o defectos detectados después del envío al cliente (Resolución de quejas, devolución y sustitución de productos, soporte de línea de ayuda, trabajo de garantía). Los costos relativos de calidad aumentan rápidamente de prevención a detección y de error interno a externo.
126
La distribución de costos a través de las distintas actividades en el proceso de software depende del proceso utilizado y del tipo de software que se vaya a desarrollar. Por ejemplo, el software de tiempo real normalmente requiere una validación y pruebas más extensas que los sistemas basados en web. Sin embargo cada uno de los diferentes enfoques genéricos al desarrollo del software tiene un perfil de distribución de costos diferente a través de las actividades del proceso del software. Si se considera que el costo total del desarrollo de un sistema de software complejo es de 100 unidades de costo, la Fig.20 muestra cómo se gastan éstas en las diferentes actividades del proceso.
Fig.20 Distribución de costos de las actividades de la Ing. Software
En un enfoque en cascada, los costos de especificación, diseño, implementación e integración se miden de forma separada, la integración y pruebas del sistema son las actividades de desarrollo más caras. Normalmente, éste supone alrededor del 40% del costo de desarrollo total, pero para algunos sistemas críticos, es probable que sea al menos el 50% de los costos de desarrollo del sistema. 127
Si el software se desarrolla utilizando un enfoque interativo, no existe división entre la especificación, el diseño y el desarrollo. En este enfoque, los costos de la especificación se reducen debido a que sólo se produce la especificación de alto nivel antes que el desarrollo. La especificación, el diseño, la implementación, la integración y las pruebas se llevan a cabo en paralelo dentro de una actividad de desarrollo. Sin embargo, aun se necesita una actividad independiente de pruebas del sistema una vez que la implementación inicial esté completa. La ingeniería de software basada en componentes sólo ha sido ampliamente utilizada durante un corto periodo de tiempo, en este enfoque no se tiene datos exactos para los costos de las diferentes actividades de desarrollo de software, sin embargo, se sabe que los costos de desarrollo se reducen en relación a los costos de integración y pruebas. Los costos de integración y pruebas se incrementan porque se tiene que asegurar que los componentes utilizados cumplen realmente su especificación y funcionan como se espera con otros componentes. Además de los costos de desarrollo, existen costos asociados a los cambios realizados cuando el software ya está en uso. Los costos de evolución varían drásticamente dependiendo del tipo de sistema. Para sistemas de larga vida, tales como los sistemas de orden y control que pueden ser usados durante 10 o más años, estos costos exceden a los de desarrollo por un factor de 3 o 4, como se muestra en la penúltima barra de la Fig. 20.
Sin embargo, los
sistemas de negocio más pequeños tienen una vida mucho más corta y, por lo tanto costos de evolución más reducidos. Esta distribución de costos se cumple para el software personalizado, el cual es especificado por un cliente y desarrollado por un contratista. Para productos de software que se venden de manera comercial, el perfil del costo es diferente. 128
Estos productos comúnmente se desarrollan a partir de una especificación inicial utilizando un enfoque de desarrollo evolutivo. Los costos de la especificación son relativamente bajos. Sin embargo, debido a que se pretende utilizarlos en distintas configuraciones, deben ser probados a fondo. En la última barra de la Fig. 20 se muestra el perfil del costo que se puede esperar para estos productos. Los costos de evolución para productos de software genéricos son difíciles de estimar. En muchos casos, existe poca evolución de un producto. Una vez que una versión de producto se entrega, se inicia el trabajo para entregar la siguiente y, por razones de mercadotecnia, ésta se presenta como un producto nuevo (pero compatible) más que como una versión modificada de un producto que el usuario ya adquirió.
Por lo tanto, los costos de evolución no se
consideran de forma separada como en el caso del software personalizado, sino que son sencillamente los costos del desarrollo para la siguiente versión del sistema.
4.5 Nomenclatura y certificación ISO 9001:2000 La nomenclatura de la norma de calidad en caso específico de la ISO 9000: 2000 es la siguiente: 1 Parte ISO Esta sección de la nomenclatura indica la norma de la que se trata, en este caso es la norma ISO, la cual significa para la traducción en español como Organización Internacional de estándares, en esta sección se indica el tipo de norma, como ejemplo otra nomenclatura puede ser la QS la cual es la usada en las empresas de giro automotriz, etc. 2 Parte 9000 Esta sección indica el tipo de norma de la que se esta hablando en este caso la 9000 es el vocabulario, términos y definiciones solamente, la 9001 son los 129
requisitos, mucha gente por no conocer esta diferencia ,hace referencia a que "esta certificada por ISO 9000" esto es un error la certificación se realiza mediante el cumplimiento de requisitos, entonces la ISO 9000 es un apoyo de todo el vocabulario que se incluye en la ISO 9001 3 Parte 2000 Esta sección es para indicar desde cuando es vigente la norma , en este caso la ultima vigencia de la ISO 9001 es desde el año 2000 La norma ISO 9001:200 (ISO,2000), especifica los requisitos para un sistema de gestión de calidad cuando una organización: Necesite demostrar su capacidad para proporcionar de forma coherente productos que satisfagan los requisitos del cliente y los reglamentos aplicables. Aspira a aumentar la satisfacción del cliente a través de la aplicación eficaz del sistema, incluyendo los procesos para la mejora continua del sistema y el aseguramiento de la conformidad con los requisitos del cliente. Los principios básicos de la norma ISO 9001, constituyen la parte medular del sistema son: Enfoque al Cliente: Las organizaciones dependen de sus clientes y por tanto deberían comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes. Liderazgo: Los líderes establecen la unidad de propósito y la orientación de la organización Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización. 130
Participación del personal: El personal, a todos los niveles, es la esencia de una organización y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organización. Enfoque basado en procesos: Un resultado deseado se alcanza mas eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso Enfoque de sistema para la gestión: Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos. Mejora Continua: La mejora continua del desempeño global de la organización debería ser un objetivo permanente de ésta. Enfoque basado en hechos para la toma de decisión: Las decisiones eficaces se basan en el análisis de los datos y la información. Relaciones
mutuamente
beneficiosas
con
el
proveedor:
Una
organización y sus proveedores son interdependientes y una relación mutuamente beneficiosa aumenta la capacidad de ambos para crear valor. Estos ocho principios de gestión de la calidad constituyen la base de las normas de sistemas de gestión de la calidad(SGC). La norma ISO 9001 está dividida en ocho puntos, de los cuales, los cinco últimos definen los requisitos del SGC (Sistema de Gestión de Calidad). PARTE 1, 2, 3 INTRODUCCION A LA NORMA En la cual se destacan los siguientes conceptos: Los objetivos y campo de aplicación de la norma, son
demostrar la capacidad para cumplir los 131
requisitos reglamentarios y los del cliente y satisfacerle mediante la mejora continua y la prevención de no conformidades. Se pueden excluir ciertos requerimientos de la norma en función de la naturaleza de los productos o servicios, los requerimientos del cliente o los requisitos reglamentarios. En la parte 2 se indica que la norma de consulta es la ISO 9000:2000 relativa a los ―Sistemas de Gestión de la calidad, principios y vocabulario‖.
PARTE 4 SISTEMA DE GESTION DE CALIDAD Aquí se definen los requisitos generales y los
requisitos generales de
documentación. Los requisitos generales son: Planificar: Identificar de todos los procesos que, afectar a la calidad del producto, determinar la secuencia y relacion que estos procesos tienen entre sí. Ejecutar: Determinar metodos y criterios para asegurar el correcto funcionamiento y control de los procesos, los procesos deben estar documentados y medidos mediante parámetros relevantes, y se establecen los responsables de los procesos. Medir: asegurar la disponibilidad de la información suficiente que permita el seguimiento del proceso. Actuar: Medir y realizar el seguimiento del proceso, para analizar y conseguir una mejora continua.
132
PARTE 5 RESPONSABILIDAD DE LA DIRECCIÓN Aquí se indica las series de responsabilidades o acciones en las cuales el Gerente General debe de participar directamente o mínimo estar enterado de ellas, entre las que se destacan: Compromiso de la dirección, el enfoque al cliente, política de calidad, planificación, administración, revisión por la dirección. PARTE 6 GESTION DE RECURSOS Aquí se indica lo mínimo necesario que la organización debe de gestionar en cuanto a recursos, esto para garantizar al cliente que la falta de los mismos no generará un producto de mala calidad. Se detallan cuatro subpartes: Suministro de recursos, Recursos humanos, Instalaciones, Entorno de trabajo. PARTE 7 REALIZACIÓN DEL PRODUCTO Aquí se indican los requisitos mínimos necesarios para realizar las actividades que garanticen producto que cumplan con lo estipulado, esta se subdivide en 6 partes: Planificación de los procesos de realización, Procesos relacionados con los clientes, Diseño y/o desarrollo, Compras, Operaciones de producción y prestación de servicios, control de equipos de medición y de seguimiento.
PARTE 8 MEDICIÓN , ANALISIS Y MEJORA Este punto hace referencia a la medición que se debe realizar al producto en sus diferentes fases y al producto final, es decir describe los requisitos relacionados con la detección, el seguimiento y el análisis de las mejoras. Se subdivide en 5 subpartes: Planificación, medición y seguimiento, control de las no conformidades, análisis de datos, mejora. 133
Dentro de la medición y seguimiento se incluyen las siguientes áreas: Satisfacción del cliente, auditoría interna, medición y seguimiento de los procesos, medición y seguimiento del producto.
4.6 La norma ISO/IEC 9126 La norma ISO/IEC 9126 está enfocada a la calidad de Producto y consta de las siguientes partes: Parte 1: Modelo de Calidad Define un modelo de calidad basado en dos partes bien identificadas: la calidad interna y externa, y la calidad de uso. Calidad interna: totalidad de las características del producto de software desde un punto de vista interno. Calidad externa: totalidad de las características del producto de software desde un puesto de vista externo. Calidad de uso: capacidad del software que posibilita la obtención de objetivos
específicos
con
efectividad,
productividad,
satisfacción
y
seguridad‖.
La calidad del proceso influye en la calidad del producto que a su vez es relevante en la calidad de uso. La figura 17 muestra el modelo de calidad según ISO/IEC 9126.
134
Fig. 17 Modelo de calidad según ISO/IEC 9126 Parte 2: Métricas externas Son medidas del producto de software obtenidas del comportamiento del sistema en la fase de ejecución del mismo. Finalmente las métricas de calidad de uso, como tercer gran concepto propuesto por la norma, mide la extensión en la que un producto alcanza las necesidades expuestas por el usuario de forma específica en relación a los objetivos de efectividad, seguridad, productividad, y satisfacción. Parte 3: Métricas internas Son aquellas medidas que se realizan sobre un producto de software no ejecutable, tal como la norma indica ―un producto de software intermedio debería ser evaluado usando métricas internas‖.
Parte 4: Calidad en las métricas de uso. Comprende la eficacia, productividad, seguridad y satisfacción definidas como:
135
Eficacia: Capacidad del software para permitir a los usuarios alcanzar objetivos específicos con precisión y completamente en un contexto específico de uso. Productividad: Capacidad del producto de software para alcanzar niveles aceptables de riesgo hacia la gente, negocio, software, propiedad o medio ambiente, en un contexto específico de uso. Satisfacción: La capacidad del producto de software para satisfacer al usuario en un contexto específico de uso.
4.7 Análisis de factores que determinan la calidad del software. Desde un punto de vista más formal, se puede decir que un producto software es de calidad si cumple o tiene algunos o todos de los siguientes factores de calidad: Corrección:: cumple la especificación de requisitos. Corrección Mantenibilidad:: facilidad para cambiar el software. Mantenibilidad Portabilidad:: esfuerzo para trasladar el software de una a otra Portabilidad plataforma. „Testabilidad‟: facilidad para probar que el software es correcto.
Facilidad de uso: uso: esfuerzo para aprender, usar e interrumpir un sistema en marcha. Confiabilidad:: Confiabilidad
capacidad
para
continuar
el
trabajo
aunque
haya
interrupciones. (sistemas seguros) 136
Eficiencia:: recursos que se necesita para la aplicación. Eficiencia Integridad:: datos y sistemas inaccesible por personas no autorizadas. Integridad Reusabilidad:: facilidad para reutilizar cosas en otros proyectos. Reusabilidad Interoperabilidad:: habilidad para operar con otros sistemas. Interoperabilidad
¿Qué es un factor de calidad? Un factor de calidad también llamado parámetro de calidad es una cualidad cuya presencia o ausencia en un producto software condiciona su calidad. Factores externos: – Detectados por los usuarios. – Son los factores que realmente realm ente interesan(objetivo).
Factores internos: – Únicamente percibidos por los desarrolladores. – Un medio para conseguir la calidad cali dad externa.
Factores de calidad de McCall Clasifica los factores de calidad de acuerdo a las etapas por las que un producto pasa: Transición de producto, Revision de producto y Operación del producto. Los factores responden a las interrogativas mostradas a continuación en la Fig.18.
137
Fig.18 Factores de calidad de Mc Call
4.8 Análisis del proceso del ciclo de vida del software En el apartado 2.4 de este mismo texto se explicó la calidad del software en el proceso de ciclo de vida de software, los procesos que lo conforman, así como la definición del modelo de ciclo de vida; por lo que únicamente en este mismo apartado se limitará a mencionar los principales modelos de ciclo de vida. Modelos tradicionales Formados por un conjunto de fases o actividades en las que no tienen en cuenta la naturaleza evolutiva del software: Clásico, lineal o en cascada Estructurado Iterativo o basado en prototipos Desarrollo rápido de aplicaciones (RAD) Modelos evolutivos Son modelos que se adaptan a la evolución que sufren los requisitos del 138
sistema en función del tiempo. En espiral Evolutivo Incremental Modelo de desarrollo concurrente Modelos para sistemas orientados a objetos Modelos con un alto grado de iteratividad y solapamiento entre fases. De agrupamiento Fuente Remolino Pinball Basado en componentes UP
4.9 Funciones de evaluación del software Con base en los estándares de calidad sugeridos la norma ISO/IEC 9126, de la ISO (Organización Internacional de Normalización) y la IEC (Comisión Electrotécnica Internacional) se presenta el proceso de evaluación de software. El proceso de evaluación de software se inicia con una visión cualitativa y deriva en una evaluación cuantitativa, siendo todo el proceso documentado y cumpliendo los siguientes pasos: 1 Estado del Software: Conocimiento del el estado del software, estableciendo si se trata de un desarrollo sin terminar o un producto terminado para la entrega al cliente.
139
2 Identificar el tipo de software: Especificar el tipo de software a evaluar, si es un sistema operativo, software de seguridad, software de ofimática, lenguaje de programación, base de datos, aplicativo a la medida, entre otros. 3 Perfiles de Evaluadores: Teniendo como marco conceptual al estándar ISO [ISO/IEC9126], se consideran tres perfiles de usuario, a un alto nivel de abstracción para desarrollo de software, usuarios finales, desarrolladores, y gerentes. El estándar afirma que la relativa importancia de las características de calidad
(como
usabilidad,
funcionalidad,
confiabilidad,
eficiencia,
portabilidad, y mantenibilidad y calidad en uso) varían dependiendo del punto de vista considerado y de la critica de los componentes del software a evaluar. La visión del usuario final, concierne al interés de los mismos en usar el software, como así también su ejecución, su eficiencia, su facilidad de uso, entre otros aspectos. Los usuarios finales no están interesados en características internas o de desarrollo del software (sin embargo, atributos internos contribuyen a la calidad de uso). La visión de calidad del desarrollador debe considerar no sólo los requerimientos del software para la visión del usuario sino también la calidad para los desarrollos intermedios resultantes de las actividades de la fase de desarrollo. Se debe tener en cuenta que los desarrolladores están preocupados en características de calidad del software como mantenibilidad y portabilidad. La visión de calidad del gerente es una visión integradora, que incorporar requerimientos de negocio a las características individuales. Ejemplo, un gerente esta interesado en el equilibrio entre la mejora del software y los costos y tiempos establecidos. 140
4 Especificar los Objetivos Conocer los objetivos tanto generales como específicos del software. 5 Aplicar el modelo de calidad Elaborar un instrumento o formato donde aplique el modelo de calidad externo e interno y calidad de uso. Si existe un comité o conjunto de personas encargadas de la evaluación, el instrumento debe ser aprobado por los participantes. 6 Criterios de la evaluación Los criterios parten de los 7 indicadores principales los cuales fueron socializados anteriormente. Los criterios para evaluar el software se dividen en dos grandes bloques: uno dedicado a criterios que son aplicables a cualquier tipo de software (criterios generales), y otro conjunto compuesto por criterios adaptables al grupo de software evaluados (criterios específicos). En este caso se definen los criterios en la Fig.19 de la evaluación según el tipo de software, para el cual debe conformar un equipo evaluador, este ejercicio ayuda a definir que opciones se deben evaluar con más detalle y valor.
Fig.19 Criterios al evaluar un software.
141
7 Seleccionar métricas La selección de métricas se obtiene a partir de los indicadores especificados en el modelo. Niveles o escalas • A cada métrica seleccionada le asigna un puntaje máximo de referencia. • La suma de los puntajes máximos de todas las métricas debe ser igual o
aproximado a 100 puntos. • El personal que participa en la evaluación debe establecer niveles de
calificación cualitativa con base a los puntajes, por ejemplo:
De 0 a 1 Inaceptable. De 2 a 3 mínimo aceptable Mas de 3 Aceptable o satisfactorio Otro ejemplo de calificación cualitativa puede ser: Deficiente Insuficiente Aceptable Sobresaliente Excelente • Se permite usar números enteros o hasta con un decimal de
aproximación. • Definir por cada métrica, un puntaje mínimo de aprobación, y al final de
la evaluación, dependiendo del puntaje si es mayor o menor a lo propuesto, considerar si el software cumple o no cumple con los objetivos propuestos. 142
8 Establecer criterios Las persona que participa en el proceso de evaluación debe tener criterios con respecto al indicador que se esta analizando, Es importante tener en cuenta que el criterio debe ajustar al tipo de software que se va a evaluar. 9 Tomar medidas Para la medición, las métricas seleccionadas se aplican al software. Los resultados son valores expresados en las escalas de las métricas, definidos previamente. 10 Resultados El proceso de evaluación genera un cuadro de resultados por cada uno de los principales indicadores y el total final de resultado.
11 Documentación El proceso de evaluación se documenta, indicando la fecha, empresa, los cargos, nombres y apellidos, dependencia de las personas que participan en el proceso de evaluación, especificando las etapas en las que participaron. 6.12 Seguimiento Si el resultado de la evaluación tiene observaciones o indicadores de calidad bajos, y el personal que lo evalúa permite realizar la corrección, se programa otra evaluación donde se verifique que el proceso mejora, el tiempo que se estime debe influir en los criterios de la aproxima evaluación.
143
4.10 Preguntas de repaso y prácticas sugeridas. 1. Investigar y participar en un foro de discusión en clase para abordar las diferencias que existen así como las ventajas y desventajas de aplicar un modelo de ciclo de vida respecto a otro. 2. Realizar la revisión técnica formal del producto de software teniendo como base los factores de calidad de McCall, ésta revisión puede llevarse a cabo dentro de la clase en donde para corroborar la existencia de los mismos se le pide a los integrantes del equipo identifiquen y justifiquen como fueron aplicados a su producto de software. 3. Integrar como parte de las estrategias de un nuevo ciclo de desarrollo, los factores de calidad, de manera que durante el análisis, diseño y desarrollo del producto se mantenga como objetivo lograr que estos factores estén presentes y puedan ser demostrados para una nueva revisión. 4. Llevar a cabo el resumen final del proyecto, donde se integre la información, lecciones aprendidas y mediciones realizadas a través del proyecto. Un buen ejercicio final puede ser documentar adecuadamente la base de conocimiento adquirida para futuros proyectos a realizar. 5. Investigar y discutir a manera de lluvia de ideas en clase cuales fueron las mejores practicas que pueden ayudar a que la calidad de un producto de software se obtenga. 6. Investigar más sobre los costos que acarrea el implantar o buscar calidad en los productos de software.
144
ANEXOS Anexo 1: Tareas por roles y fases de desarrollo Las siguientes tablas contienen actividades propuestas para un ciclo de desarrollo de software, se han citado las mas comunes que se pueden encontrar para realizar en un proyecto de clase, por lo cual puede ser usado como referencia para los alumnos pudiendo agregar o eliminar aquellas que consideren mas adecuadas a su proyecto. Es conveniente que en base a la experiencia adquirida en otros proyectos, se planee el tiempo requerido para efectuarlas, y se registre en la hoja de avance de proyecto individual (Anexo 2). Al concluir las fases en un ciclo de desarrollo (se recomienda efectuar todas, y limitar el producto resultante para cada ciclo) se realizará una retroalimentación (POSTMORTEM) de dicho ciclo para que cada equipo vea cuales prácticas concensuadas pudieron ser llevadas a cabo y cuales no, de tal forma que puedan plantear o replantear estrategias que les permitan alcanzar sus metas en el próximo ciclo de desarrollo. Se recomienda que sea el instructor o profesor quien aplique una Revisión Técnica Formal (RTF) con el fin de corroborar los objetivos planteados y los obtenidos. También es recomendable que los estudiantes adquieran el hábito de registrar sus actividades y documentarlas adecuadamente, de modo que éstas puedan servir de evidencia en cada ciclo para comparar la madurez del proceso de desarrollo de software. Es importante señalar que los formatos consideran al PSP y TSP como procesos a implantar para el desarrollo del proyecto de software no importando su trabajo y que tienen como finalidad el aprendizaje práctico y aplicación de las disciplinas y mejores prácticas de desarrollo. Para iniciar el proyecto el equipo deberá estar compuesto de al menos 5 personas quienes tomarán los roles de Líder, Analista, Diseñador, 145
Programador, Tester y Asegurador de Calidad para el caso de equipos mas pequeños, pueden asumirse 2 roles o repartir las tareas asignadas.. Como podrá observarse hay actividades para todos ellos en todas las fases, esto fomenta el trabajo colaborativo pero también debe recalcarse la importancia de la comunicación y responsabilidad de cada integrante para cumplir con las tareas que le sean encomendadas. En cada actividad existe un responsable de coordinarla, para el caso de la actividad en que Todos sean responsables, el líder de proyecto será quien verifique que realmente la actividad fue efectuada por todos los miembros. Se recomienda como línea base establecer un tiempo máximo por dia (una hora por ejemplo) con el cual debe contribuir cada miembro del equipo, así como hacer una distribución equitativa del numero de horas por ciclo. Ejemplo de pasos a seguir: 1.-El equipo se reúne y decide cual será el objetivo a cumplir para el primer ciclo: el producto A. 2.- El equipo designa los roles que cada integrante tendrá y analiza la lista de tareas asignando un tiempo para cada actividad, teniendo en cuenta la fecha de entrega para no sobrepasar el tiempo. 3.- El número de horas (o tiempo total) se divide entre el número de integrantes, por ejemplo 150 hrs./5 = 30 hrs/hombre este es el número máximo de horas que cada elemento aportara durante el primer ciclo, por lo cual las tareas asignadas no deben sobrepasar este rango y si faltan deberá completarlas con tareas de apoyo a otro miembro. De esta forma el esfuerzo de cada miembro podrá equilibrarse. Las actividades deberá registrarlas en un formato, que se ve en el Anexo 2.
146
FASE: LANZAMIENTO
E
Formar equipo de trabajo
R
Definir proyecto/Investigar que proyecto hacer
R
Definición de lugar y horas de trabajo
R
Definición de estándares de documentos
R
Definir un presupuesto general investiga precios
R
Asignación de roles y tareas preeliminares
X
Capturar toda la información en la plantilla de equipo
anterior
con
base
L
A
D
P
T
Q
X
X
X
X
X
X
X
X
X
X
R X
Impresión de los documentos DEFINICION DE ESTRATEGIAS PARA EL CICLO A DESARROLLAR Lectura-Revisión solicita de los documentos emitidos
corrección
R
Bitácora de equipo Preservar documentación DURANTE TODO EL CICLO
R y
archivos
X
R
RESPALDO DE TODOS LOS ARCHIVOS DURANTE TODOS LOS CICLOS /Elaborar un plan de respaldo VERIFICA TIEMPOS Y ACTIVIDADES ESTEN REALIZANDO A TIEMPO
QUE
SE
x R
R X
Simbología R = Responsable X = colaborador E= Todos (EQUIPO) L=Líder de proyecto A=Analista D=Diseñador P=Programador T=Tester Q= Asegurador de Calidad
147
FASE: PLANEACION Y ANALISIS DE REQUERIMIENTOS
E
L
Definir tareas generales de acuerdo al proyecto en formato TSP ciclo N
X
R
Definir tareas particulares de acuerdo al Rol y proyecto seleccionado formato PSP ciclo N
X
R
Realización de actividades del análisis general de acuerdo al proyecto
X
A
D
P
T
Q
X
R
x
R
X
x
x
R
R
Definición de requerimientos
R
Elaboración de modelos que representen dichos requerimientos
R
X
Revisión de modelos de acuerdo a requerimientos Formular estrategias de capacitación para el desarrollo del producto o capacitar al equipo
R
Análisis de alternativas, riesgos, etc
X
Actualización de formatos TSP
X
Actualización de formatos PSP
R
Elaboración de documentos del análisis general
X
R R
R
Elaboración de prototipo de acuerdo a los requerimientos o elaboración diseño preeliminar Prueba a los prototipos (en caso de haberlos realizados) verifica
R
R
R
requerimientos Lectura-Revisión y solicita de los documentos emitidos Entrega de avances
corrección
R
148
FASE: DISEÑO
E
L
A
D
Diseño físico del producto
x
x
R
Diseño lógico del producto
x
x
R
x
R
x
Diseño de controles preventivos, detectivos correctivos del producto
P
T
Diseño de pruebas al producto
x
Diseño de la seguridad del producto (física, integridad,
x
Verificación del diseño con base en los requerimientos antes definidos
x
x
x
R
Pruebas al diseño(s) del producto
x
x
R
X
Elaboración de algoritmos de solución
x
X
R
Capacitación en herramientas de desarrollo a miembros del equipo
x
x
R
Elaboración de documentos del diseño en general
R
X
x
R
x
x
Q
R
X
Presentación del diseño al cliente
R
x
x
x
Rectificación de requerimientos solicitados por el cliente en el diseño del producto
x
x
x
x
Actualización de formatos TSP
X
Actualización de formatos PSP
R
Lectura-Revisión y solicita de los documentos emitidos
corrección
Entrega de avances/ Bitácora
x
R
R
x
x
R
R
Simbología R = Responsable
X = colaborador
E= Todos L=Líder de proyecto A=Analista D=Diseñador P=Programador T=Tester Q= Asegurador de Calidad
149
FASE: IMPLEMENTACION Y PRUEBAS
E
Desarrollo de programas con base en los diseños
x
Elaboración de pruebas al producto de software documentación del resultado de las mismas
L
A
D
P
T
Q
R
x
R
x
x
R
T
Q
R
X
x
x
x
R
R x
Verificación del cumplimiento de los requerimientos en el producto de software. Solicitud de correcciones Documentar tiempos programación
y
errores
durante
R
Actualización de formatos TSP
X
Actualización de formatos PSP
R
Lectura-Revisión y solicita de los documentos emitidos
corrección
x
Entrega de avances/ Bitácora
R
FASE: POSTMORTEM
E
Cierre de formato PSP de acuerdo al ciclo progamado Cierre de formato TSP de acuerdo al ciclo programado
R
Resumen de conclusiones para el ciclo concluido
R
Cierre de toda la documentación emitida durante el ciclo
R
Verificación de la documentación a entregar producto
x
Entrega de avances/ Bitácora (en su caso) Preparación de capacitación al usuario
A
D
P
R
Análisis de los resultados obtenidos vs estrategias utilizadas
del
L
R
Resumen de tiempos, esfuerzo, errores
Diseño de presentación verificación de la misma
R
R R
x
R
150
Anexo 2 Formato para planeación y registro de tiempo individual
Ejemplo (continuación) 4.-Cada integrante es responsable de registrar y documentar sus actividades, al término de las mismas reportar al responsable de la actividad y lider del equipo. Al concluir el ciclo de desarrollo deberá obtener el numero total de horas para cada actividad y participar con su equipo en el postmortem.(Anexo 3)
151
Anexo 3 Formato auxiliar para postmortem y lecciones aprendidas. FASE: LANZAMIENTO
SI
NO
Observaciones
¿Se llevo a cabo la formación del equipo en forma adecuada? El proyecto fue definido en su objetivo general? Se definieron las horas y lugar de trabajo de equipo Fueron definidos los estándares de documentación y trabajo en esta fase? Los roles están asignados de acuerdo a las características y fortalezas de cada integrante? Fueron reconocidas las habilidades y se formularon estrategias para fortalecer las deficiencias en cada integrante del equipo? Los participantes del equipo conocen sus roles asignados y las tareas a realizar Cada integrante cuenta con su documento PSP impreso y actualizado Se definieron estrategias para el proyecto en esta etapa y fueron seguidas por todos y cada uno de los integrantes Se llevó a cabo un plan de presupuesto y estrategias para asumir los costos inherentes a la realización del proyecto? Se llevo a cabo la lectura y corrección de los documentos que forman parte de esta fase El equipo tomó como parte de sus estrategias el asesoramiento por parte del profesor? En la bitácora de equipo pueden identificarse las actividades referentes a esta fase Se realizo una estrategia de respaldo y resguardo de los documentos y archivos generados Se formularon estrategias de capacitación para el desarrollo del producto o capacitar al equipo? Todos los participantes del equipo terminaron al mismo tiempo esta fase? Se realizo la verificación de tiempos asignados para esta fase de forma adecuada y oportuna
152
Los formatos de TSP se refieren a un cronograma general que el equipo puede plantear con los tiempos como se explicó en el anexo 1, y el formato de PSP se refiere al formato de planeación de actividades individual. FASE: PLANEACION Y ANALISIS DE REQUERIMIENTOS Fueron definidas las tareas y tiempos en el formato TSP, Fueron definidas las tareas particulares de acuerdo al Rol y proyecto seleccionado utilizando el formato de PSP? Cada integrante realizó su PSP considerando los tiempos y fases marcadas en el TSP del equipo? El formato fue verificado por el líder de proyecto y SQA? Cada integrante contó con su PSP impreso y fue actualizado diariamente? El analista definió otras tareas o actividades de apoyo para los compañeros del equipo? Se elaboraron estrategias para conocer los requerimientos del cliente? Se obtuvieron los requerimientos del cliente o usuario potencial directamente? Los requerimientos están expresados por documentos y/o modelos que son claramente entendidos por los miembros del equipo? Las técnicas empleadas durante el análisis fueron suficientes para la obtención de los requerimientos? Se formularon alternativas de desarrollo y/o solución al producto a desarrollar? Se realizó un análisis de factibilidad para el proyecto? Se desarrollo un análisis de riesgos congruente con el proyecto a desarrollar? Fueron planeadas en esta fase los tiempos para realizar las pruebas al proyecto? Hubo algún prototipo preeliminar desarrollado para la mayor comprensión de los requerimientos al cliente.? Hubo una buena comunicación del analista hacia los demás integrantes del equipo durante esta fase? Los documentos elaborados para esta fase fueron previamente revisados y aprobados por el líder de proyecto y SQA? Las actividades de esta fase están reflejadas en la bitácora de equipo y en los formatos de planeación individual de los integrantes?
SI
NO
OBSERVACIONES
153
FASE: DISEÑO El diseñador recibió las especificaciones del analista en forma adecuada y oportuna (a tiempo)?
SI
NO
Observaciones
Fueron considerados los riesgos y alternativas de la fase de análisis para el diseño del producto? Se cuenta con un diseño optimo para la prevención, detección y corrección de errores del producto? Fueron diseñadas las pruebas al producto tomando en cuenta los diseños y requerimientos señalados? Fue verificado el diseño del producto de software en base a los requerimientos antes definidos Verificación del diseño con requerimientos antes definidos
base
en
los
Fueron elaborados y documentados los algoritmos, rutinas, componentes durante su diseño? Los algoritmos fueron comprendidos por todos los miembros del equipo? En esta fase se dio inicio a la capacitación del equipo en lo referente a la programacion u otros aspectos a mejorar? Fueron revisados y verificados los documentos durante esta fase? Se presentaron los diseños al cliente o usuario potencial? Fueron rectificados los diseños de acuerdo a las observaciones hechas por el cliente o usuario potencial? Hubo una buena comunicación del diseñador hacia los demás integrantes del equipo durante esta fase? Los documentos elaborados para esta fase fueron previamente revisados y aprobados por el líder de proyecto y SQA?
154
Las actividades de esta fase están reflejadas en la bitácora de equipo y en los psp de los integrantes? Se formuló como estrategia la reutilización de diseños?
FASE: IMPLEMENTACION Y PRUEBAS Se desarrollaron los programas con base en los diseños aprobados ? Fueron elaboradas las pruebas de acuerdo a un procedimiento establecido y documentado? Se verificó por parte del SQA y tester el cumplimiento de los requerimientos en el producto de software. Solicitud de correcciones Se documentaron la solicitud de correcciones Se documentaron los errores y tiempos de corrección Se tuvo la participación de todos los miembros del equipo durante la programación Las actividades de esta fase están reflejadas en la bitácora de equipo y en los psp de los integrantes? Existió buena comunicación del programador hacia los demás integrantes del equipo en esta fase? Existió buena comunicación del SQA hacia los demás integrantes del equipo en esta fase? Existió buena comunicación del tester hacia los demás integrantes del equipo en esta fase? Fueron revisados y verificados los documentos durante esta fase?
Si NO
FASE: POSTMORTEM
S N I O
OBSERVACIONES
OBSERVACIONE S
Se realizó el cierre de formato PSP de acuerdo al ciclo programado Se realizo el cierre del formato TSP del ciclo Se obtuvieron los valores de tiempo, esfuerzo, recursos financieros El análisis de los resultados obtenidos vs estrategias utilizadas se hizo por todos los integrantes? Se documento las conclusiones del ciclo presente
155
SE hizo la entrega oportuna de la documentación final por parte de todos los integrantes del equipo? Verificación de la documentación a entregar Realización del CHECKLIST de postmortem.
Ejemplo (Continuación) 5.- Los integrantes del equipo al concluir la fase de postmortem y observar los datos recolectados, así como los tiempos aportados, y las diferencias obtenidas, podrán replantear estrategias para un nuevo ciclo de desarrollo y documentar aquellas experiencias (lecciones aprendidas) que tuvieron durante el primer ciclo y ciclos siguientes. Todas las fases se repiten para cada ciclo, para un semestre normal de 16 semanas pueden dividirse en 2 ciclos de 8 semanas de desarrollo o en pequeños ciclos de 4 semanas (en productos de software no grandes). La finalidad de aplicar estos formatos es únicamente que el estudiante pueda controlar sus procesos de desarrollo, documentarlos y aprender de él mismo cómo puede mejorarlos, y cómo puede trabajar en un equipo efectivamente.
156
Anexo 4 Entrevistas realizadas a profesionistas del área de calidad y desarrollo de software. Durante el periodo de recabar información para el texto presente, se presentó la oportunidad de platicar y entrevistar a profesionistas del área de calidad o desarrollo de software. Quise incluir en este anexo, algunas de estas pláticas a modo de conclusión, ya que existen numerosos libros, revistas, artículos y referencias, pero sin embargo es importante considerar la experiencia que se vive diariamente o que se ha acumulado por parte de quienes son responsables directos de aplicar las normas, prácticas, modelos, etc., que aquí se han mencionado. Entrevista a Mario Segura Velazquez Mario Segura Velazquez Es Ingeniero Mecánico eléctrico, egresado de la Escuela Nacional de Estudios Profesionales Aragón ENEP Aragón UNAM, de 2001 a 2005 fungió como instructor de calidad y mejora continua de la empresa Coordinados de México Oriente de una de las empresas del Grupo ADO. Actualmente es Promotor de Calidad y Mejora Continua de la empresa ADQUEM (empresa de desarrollo de software a la medida). __________________________________________________________________ ERG: ¿Cómo defines el término Calidad? MSV: Calidad es una cultura que nos permite realizar y ofrecer servicios y productos cumpliendo con los requerimientos del cliente ERG: ¿Crees que la calidad sea una cuestión de percepción que tiene finalmente el cliente? Es sólo una parte, el que el cliente perciba que está bien hecho con lleva a que se estén cumpliendo con los procesos y métodos que definen la realización de un producto y un servicio, por eso podemos hablar de mala calidad, mediana calidad, alta calidad. ERG: ¿La calidad tiene que ver con el proceso de elaboración del producto o servicio?
157
MSV: Absoutamente. ERG:¿Quien define entonces la calidad: el proceso, el cliente...quien o qué? MSV: Bueno si es desde ahí, tienes que irte desde mucho más atrás, desde lo que vas a ofrecer un servicio y un producto, verificar los requerimientos de ese servicio y producto, en base a un estudio de mercado, definir un proceso, aplicarlo, detectar áreas de oportunidad y mejorarlo. Es todo un ciclo como el PHVA (Planear-Verificar-Hacer-Actuar) de Deming. Se realiza el análisis de una necesidad, luego la construcción de un proceso que satisficiera esa necesidad, la detección de áreas de oportunidad, y la mejora del mismo para cumplir con esas necesidades del cliente ERG: Hay autores que dicen que quien define la calidad es el cliente, otros dependiendo de cómo es realizado hacia el proceso y otros mas hacia el cumplimiento de normas ya preestablecidas. ¿Qué opinas de eso? MSV: Yo voy mas a un análisis de las necesidades del cliente y si es así lo define el cliente no podemos construir ni ofrecer lo que no van a compara o no usarán. ERG: Siendo así, ¿Podríamos decir que se cumple aquello de "al cliente lo que pida" y traducirlo a que "si hacemos lo que el cliente pidió tenemos un producto o servicio con mas calidad"? MSV: Si cumple con la satisfacción del cliente, sí. Por ejemplo: si te atienden bien... ¿Estas contenta?, si compras algo que funciona ... ¿Estas conforme?
ERG:¿Que importancia tiene entonces la calidad para los procesos de desarrollo de software? MSV: Mucha y no creo que solo sea para procesos de software es para cualquier proceso en general. ERG: ¿Consideras que la Calidad solo un “termino de moda”? MSV: Bueno en realidad creo que la actualidad, se entiende por ―moda‖ de que las empresas
solo quieren obtener certificados de diestra a siniestra: ISO 9001,CMMI nivel de madurez 5, Six Sigma, TIL Cobit, y un sin numero de certificaciones que hay, porque creen que les da prestigio, y si lo da, pero de nada les sirve tener un certificado en lo que quieran sino mejoran sus procesos e implementan una cultura de calidad cuando salga una nueva norma, como "esta de moda", la tomas y consigues el certificado,‖lo compras‖ y descuidas el proceso.
ERG: ¿El contar con un certificado de calidad asegura que tu proceso de desarrollo es correcto, eficiente? MSV: No, el tener un título ¿T e asegura que eres un buen ingeniero? Un ―doctor en calidad‖ puede ser muy bueno en la teoría, ¿Pero lo será en la práctica? Conseguir una certificación es fácil, mantener el sistema de calidad es diferente ERG:¿Cuales serian los “cuidados”,
por así dec irlo que deben considerar las
empresas para mantener su sistema de calidad?
158
MSV: Compromiso de la dirección, análisis de fortalezas y debilidades, documentación de procesos, capacitación del personal, comité de seguimiento, tener un método de recabar quejas y sugerencias, y un plan de comunicación adecuado. ERG: Para la industria mexicana ¿Qué tan difícil ha sido “entrar” a todo esto de la
calidad a comparación de otras industrias como la India, EU, Union Europea? ¿Influye la cultura? MSV: Observo la resistencia al cambio, a la gente no le gusta mejorar quiere seguir haciendo lo mismo, le da miedo. ERG: ¿Consideras que el mexicano es conformista por no querer mejorar? MSV: Sí en el sentido de que no tenemos planeación, si no hay planeación no hay objetivos, si no hay objetivos no hay metas, y sin metas no hay acciones. ERG: y ¿Visualizas alguna ventaja que tengamos? MSV: Muchas. Tenemos recursos, gente, es un buen principio. ERG: ¿A que te refieres con recursos y gente? ¿Qué es lo que ves en ellos? MSV: En que en México tenemos medios al alcance de la tecnología, conocimientos los hay, y hay personas con hambre de mejorar, pero en ocasiones nosotros mismos ―nos ponemos el pie‖. ERG: ¿Cuántas PYMES que inician en México logran “sobrevivir” sin una cultura de
calidad?
MSV: La vida de una PYME sin esas condiciones es de 2 años, por falta de planeación. ERG: ¿Falta preparación en este rubro? MSV: Bastante. En sí desde las bases en la ecuación primaria. Hablamos de Calidad Educativa, Calidad de vida, utilizamos mucho la palabra calidad pero no le damos el sentido verdadero. ERG: Ya que lo has mencionado, ¿Que relación existe entre la calidad de vida y la calidad del producto o servicio que puede ofrecer una persona? MSV: Mucha. Si la gente no está satisfecha con su trabajo, no lo hará bien y eso afecta a la calidad de lo que hace u ofrece. ERG: ¿Y que pasa para un profesionista? MSV: Pasa lo mismo, si no estás contento con tu trabajo y las condiciones del mismo no son las mejores, no lo realizas bien. ERG: ¿Existen otros factores, además del trabajo que puedan afectar a la calidad del servicio o producto que ofrece una persona? MSV: Sí, una remuneración justa y equitativa, un ambiente de trabajo agradable, un desarrollo profesional, un reconocimiento de su trabajo, una retroalimentación de lo que hace. Si no hay eso, esta desmotivado y no hace bien su trabajo, sea el trabajo que sea o la actividad que realice.
159
ERG: Por último,¿Qué recomendaciones harías para adentrarse a estos temas de calidad: para los estudiantes quienes se están preparando en alguna profesión y para las industrias (cual sea su tamaño) que desean iniciar alguna certificación? MSV: Para los estudiantes inculcarles que los conocimientos sin un enfoque a la planeación y mejora de las cosas no sirven de nada. Y a las industrias el compromiso de impulsar la mejora de sus productos y servicios pero mejorando la calidad de vida de sus colaboradores.
ENTREVISTA CON DR. LUIS CARLOS VARGAS HERRING Luis Carlos Vargas Herring es Dr. En Sistemas computacionales (Sistemas Distribuidos) egresado de la Universidad de Cambridge, estudió su maestria en Sistemas Computacionales en la Universidad de Essex, y la carrera de Ingeniero en Sistemas Computacionales en el Tecnologico de Celaya. Cuenta con las certificaciones MCSD(Microsoft Certified Solution Developer), MCDBA(Microsoft Certified DataBase Administrador), ha trabajado como Technical Leader en General Electric Treasury Sistem , Software Developer en GMatrix y actualmente se desempeña como Program Manager en SQL Server en Microsoft En Estados unidos.
________________________________________________________
ERG: ¿Como podrías resumir tu experiencia en el desarrollo de productos de software? ¿Ha cambiado o mejorado? LCVH: Cada vez ha sido más estructurada, con más normas y cada vez ha sido más dinámica. Me he tenido que adaptar mas rápido Cuando empezaba a trabajar en México, no había división de roles, así que empecé realizando varios roles o tareas pero en sí no había una clasificación de los roles que debía fungir. Tampoco había normas que seguir, así que yo me encargaba de la calidad del producto. Mas tarde en GE había mas estructura, ya que me tocó los roles de desarrollador y tester para asegurar la calidad, el diseño ya estaba en base de los requerimientos y teníamos junta con los analistas de negocio quienes decidían cuales eran las características que debía tener el software, en juntas platicábamos que características debía tener el producto. Así que cuando se empezaba a desarrollar ya teníamos una idea mas clara sobre lo que se quería hacer, incluso se tenían algunos procesos ya identificados y existían patrones a seguir para el desarrollo, recomendaciones a seguir, y esto nos servia como una guía para el mismo desarrollo. En cuanto al testing, no había mucho proceso, el desarrollador hacia las pruebas y se ponía en lugar del usuario, así que ahí si faltaba definir mas cosas. Ya una vez que el software estaba probado, existía ya documentación para realizar el montaje del producto en los servidores, de forma que si había alguna duda o error se podía consultar esta documentación, este proceso se debía hacer con mucho cuidado. De aquí y después de mi doctorado mi experiencia hasta ahora ha sido en Microsoft, en donde existe un mayor numero de procesos ya definidos desde el diseño de software, en el desarrollo si hay un conjunto de practicas que se deben seguir así como un conjunto de herramientas, por ejemplo hay herramientas para el control del módulo para asegurar que los módulos no se vean afectados unos al otro. El testing es completamente estructurado, está el líder de proyecto, cuya función es decidir cual es la siguiente versión del producto a realizar, teniendo información de nuestros clientes, de otros productos o referencias en revistas, esto es para hacerlo mas competitivo en el mercado. El líder decide la funcionalidad que va a tener el producto de software y el criterio
160
de éxito, esto es algo que al final de que el producto esta realizado, se puede calificar y decidir si fue exitoso o no. P ej. Se quiere una funcionalidad para hacer una replicar información de una BD El criterio de éxito seria que esa funcionalidad tenga un nivel bajo de fallos y que el proceso de replicación va a durar menos de determinado tiempo. Se tienen que tomar criterios que sean mesurables de tal forma que al finalizar el equipo que desarrolló la funcionalidad pueda saber si en realidad funcionó o no. Por lo tanto los criterios son importantes ya que cuando se está desarrollando se tiene que tener en mente que dicho criterio debe cumplirse. ERG: ¿Estos criterios ya vienen definidos por parte de Microsoft? CVH: Dentro de cada producto por ejemplo SWL tiene varios equipos, un equipo se encarga de cierta parte del producto. Se tiene un consejo (no añaden nada de funcionalidad que asegura que lo que los equipos hacen tenga o cumpla ciertas normas de calidad; entonces ese consejo se encarga de varios aspectos, por ejemplo dentro de ese consejo hay un equipo que se encarga de seguridad conformado de 3 o 4 personas expertas en seguridad y que es encargan que cualquier funcionalidad que nuestros equipos añaden al producto cumpla con las normas de seguridad de Microsoft. Así como éste equipo hay otro encargado del desempeño, otro de privacidad, otro de globalización, esto último es importante porque siendo SQL Server un producto que se usa a nivel mundial, cualquier funcionalidad que añadamos tiene que funcionar para cualquier idioma, ya que hay idiomas que utilizan palabras muy largas, imagínate que quieras poner un mensaje de error y éste sea demasiado largo para el lugar donde lo quieras ubicar…entonces ese consejo tiene sus grupos para cuidar cada aspecto, y se tiene que tener la
aprobación de todos ellos antes de escribir cualquier línea de código.
Antes de escribir este código debe existir un documento de diseño (pseudocódigo, y estructuras de datos a implementar en la funcionalidad) ese lo revisa el líder de proyecto y el tester, en base a este documento se crea el documento de testing, que indica que es lo que se va a aprobar y cómo se va a probar (también aprobado por el líder de proyecto y el desarrollador) ERG: ¿Qué pasa si ninguno de estos documentos está aprobado? ¿Les implica tiempo y costo? LCVH: Si, básicamente si el documento no esta aprobado no puedes implementar, es tiempo perdido y tienes que ponerte de acuerdo y poder solucionar el problema. ERG: ¿Te dan algún tiempo límite para que pueda llevarse a cabo la aprobación? LCVH: Yo como líder de proyecto establezco los tiempos, desde que empiezo a escribir las especificaciones funcionales yo tengo que darle una fecha a mi jefe y esa es la fecha en la que vamos a empezar a desarrollar, si llegado ese plazo no se ha empezado a desarrollar mi jefe empieza a presionar obviamente, entonces yo como líder tengo que preocuparme por que mi equipo pueda empezar a desarrollar en esa fecha. ERG: ¿ Y qué pasa si tu te adelantas a las fechas? LCVH: No pasa nada, cualquier tiempo que tu puedas ahorrar y tienes la aprobación de todas las personas requeridas, del consejo y mi equipo, pues adelante. Generalmente no pasa. Cuando ocurre esto puede significar que el líder de proyecto no es muy bueno estimando los tiempos.
161
ERG:¿Te ha pasado? LCVH:No, generalmente tiendo a ser estricto con las fechas y mas bien me ha pasado de estar un poco mas tarde. ERG: Con lo que me has dicho, me quedo con la idea de que en Microsoft el desarrollo de producto es mas estructurado ya que hay procesos roles y actividades bien definidas, además hay un elemento consejo que cuida estos procesos , ¿Ellos mismos cuidan la calidad del producto y el proceso para obtenerla? LCVH:Bueno la calidad es responsabilidad de cada uno de los grupos de hacerla, y el consejo por decirlo así es quien revisa. ERG: ¿Cómo le haces para obtener un producto de calidad? LCVH: Yo creo que la calidad depende de 2 aspectos. Para mi es hacer lo que me indican los requerimientos en el tiempo en el que se planeó, yo no creo que hacer calidad sea hacer el producto que tenga la mayor cantidad de características o hacer un producto perfecto sin ningún error. ¿Como se logra? Teniendo buenas especificaciones, buenos diseños y un buen equipo. Los documentos se pueden cambiar fácil pero una vez escrito el código, eso es lo mas caro a cambiar. Yo creo que el tener especificaciones claras y que todo mundo esté de acuerdo eso te da casi el 80% de éxito del proyecto. ERG: A través de todo este tiempo ¿Qué prácticas te han servido para obtener un mejor producto o para lograr esa calidad? LCVH: Lo primero y lo principal es entender los requerimientos del cliente. Eso desde la escuela nos lo han dicho pero a veces se olvida. Básicamente como desarrollador de software queremos hacer lo que creemos que es la mejor solución, pero el cliente tiene su propia concepción que incluso puede llegar a ser mas simple de lo que nosotros pensábamos. Tienes que estar en contacto con el cliente, por ejemplo mientras escribo las especificaciones funcionales yo hago juntas o tengo llamadas telefónicas cada 2 semanas para asegurarme de que lo que estoy planeando, lo que estoy diseñando es lo que ellos realmente quieren. También es importante especificar claramente las fechas de cuando se va a revisar el avance del proyecto y qué es lo que se va a revisar, dependiendo que tan grande es el proyecto puede ser cada 3 semanas o cada mes, pero debe reunirse todo el equipo y preguntarse si en el punto en el que están es el punto que originalmente pensaron que debieron estar. ERG: ¿Tu recomendarías entonces que existan revisiones continuas a manera de puntos de control del producto? LCVH: Si, obviamente es un balance, no quiere decir tener juntas cada semana porque es tiempo perdido de desarrollo y tester. Yo procuro tener juntas cada 3 semanas, y otra cosa importante es tratar de ser totalmente abiertos con el equipo. Por ejemplo si el desarrollador tiene alguna duda que él mismo lo platique con su equipo; yo tengo 4 desarrolladores y si alguno tiene un problema grave, por ejemplo un código que no puede resolver, entonces que en lugar de que se pase todo el día tratando de resolver el problema él solo, tenemos la política de que él debe enviar un mail a todo el grupo desarrollador y si alguien ya ha tenido un problema similar entonces trata de ayudarle, de esa forma no se pierde tiempo. ERG: ¿Entonces el trabajo en equipo es esencial para el desarrollo del producto?
162
LCVH: Si. ERG:¿Qué recomendaciones que tu harías para que quienes van empezando a desarrollar software, a quienes están estudiando? LCVH: Práctica. La práctica les va a ayudar, hay obviamente ciertos mecanismos en la carrera donde puedes practicar como son las residencias, pero si se quieren dedicar a la industria de software que entonces tomen sus residencias en una empresa dedicada al desarrollo de software sino van a estar perdiendo su tiempo. Y lo otro de eso, antes de eso hay muchos proyectos de Open Source, de código libre que están abiertos para que los que quieran pueden participar colaborando con ellos, ellos cuentan con una estructura de cómo trabajar, hay personas que se encargan de revisar código, otras dar consejos sobre cómo codificar, otras de cómo diseñar para las próximas versiones. Que busquen que es lo que quieren hacer, hay de todo, desde videojuegos hasta páginas web, pero también lo pueden hacer en su tiempo libre para que vayan agarrando práctica de cómo debe trabajarse en equipo.
163
Anexo 5 Referencias “Apuntes para análisis de sistemas”
1
María N. Moreno García Departamento de Informática y Automática Universidad de Salamanca “Calidad en el Software”
2
Memoria de Experiencia Profesional, María del Rocío Patiño Palacios, ITCelaya, Junio 2004. “Capital humano y conciencia de calidad”
3
Matías Sales, Portal de estudiantes de RRHH, Universidad Champagnat, Argentina matiassalesarrobauch.edu.ar
“CMM y la calidad en el desarrollo de software”
4
Innevo www.innevo.com, junio 2009
“Garantía de la calidad de software”
5
Basado en CMU/SEI-93-tr-25 Traducción de SET consultores. Versión 1.3 no liberada. “Gestion de la calidad”
6
7 8
Humberto Cárdenas Sierra 21 Feb 2005, curso en línea www. mailxmail.com “Guia Tecnica para la evaluacion del software”
Carlos Alberto Largo Garcia, Erledy Marin Mazo, 1ª.Edicion. www.puntoexe.com.co, 2005 ― Ingeniería del Software, un enfoque práctico ‖ Pressman, R. S. 6ª Edición. Mc Graw Hill, 2005. 164
9
10
“Ingeniería del Software”
Ian Sommerville 7a. Edición Pearson Educación, SA, Madrid 2005 “Iniciativa Nacional TSP/PSP” Beatriz Velazquez Soto‖,
SoftwareGuru, 31 julio 2008 2008 © SG Software Guru
“ISO/IEC 15504 (SPICE) Modelo de Evaluación, Mejora y capacidad de Software”
11
Carmen Golobart, Prisma Calidad y Medio ambiente consultores, España. 21 abril 2009. “La calidad del software y su medida”
12
Jesús M. Minguet Melian, Juan Francisco Hernández Ballesteros , Editorial Centro de Estudios Ramón Areces, S.A. España. “Manual de Calidad ISO 9001 para Negocios Pequeños”
13
Quality Sistems Innovations, Inc. http://www.qsinnovations.com/iso9001espanol.htm , “Mejoramiento de los procesos de software”
14
Luciano Guerrero, http://www.geocities.com/SiliconValley/Lab/3629/mejorami.htm 2000 “Modelo de procesos para la industria de Software”
15
16
Hanna Oktaba, Claudia Alquicira Esquivel, Angélica Su Ramos Ver 1.3 Agosto 2005, Secretaria de Economía México. “Modelo de Procesos”
Fanny Ruiz Castro.
“Presentación mundial de la versión en español del CMMI”
17
SG Software Guru - 15 de septiembre de 2009 2009 © SG Software Guru
18
“Procesos de Software”
Mara Ruvalcaba
165
SG Software Guru 16 de marzo de 2009 2009 © SG Software Guru
“Roles en el desarrollo de software”
19
David Fuller Padilla Escuela de Ingeniería Civil Informática Universidad Católica del Maule Chile www.eici.ucm.cl
“Técnicas cuantitativas para la gestión en la Ingeniería de Software”
20
Tuya Javier, Ramos Román Isabel, Dolado Cosín Javier NETBIBLO editorial 2007, España. “The Capability Maturity Model for Software”
21
Mark C. Paulk, Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 “The Capability Maturity Model”
22
Medellin Janzel Proyecto de Fomento a la industria de software en el Estado de Guanajuato, México . “Un enfoque actual sobre la calidad del software”
23
Informe técnico Oscar M. Fernández Carrasco, Delba García León y Alfa Beltrán Benavides. ACIMED 3(3):40-42, septiembrediciembre, 1995
24
cmm-cmu-sei-tr24-93 (CMM 1.1)
25
cmm-cmu-sei-tr25-93 (Key pract.)
166
