Está en la página 1de 167

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

 

9

1.5 La calidad y el mundo globalizado

12

1.6 Calidad de

 

14

1.7 Calidad Total

16

1.8 Preguntas de repaso y prácticas sugeridas

19

2 Aseguramiento

de la Calidad del Software (SQA)

21

2.1

Relación de la Ingeniería del Software con

22

2.2

Definición y propósito del

24

2.4

Calidad del software en el ciclo de vida del mismo

26

2.5

Roles y responsabilidades de los equipos de

31

2.6

Habilidades y capacidades del personal del SQA

37

2.7

Actividades del

40

2.8

Métodos y

41

2.9

Enfoque de Procesos en el Desarrollo de software

43

2.9.1 Definición de Proceso y Enfoque de procesos

44

2.9.2 Capacidad de proceso de software

47

2.9.3 Madurez del proceso de software

47

2.9.4 Modelos de proceso PSP y TSP

47

2.10 Preguntas de repaso y prácticas

56

3 Estándares de calidad aplicados al

58

3.1

ISO

58

3.1

SPICE

62

3.3

CMM (Capability Maturity Model

73

3.3.2

Nivel inicial

 

79

 

3.3.3

Nivel repetido

81

3.3.5

Nivel

89

3.3.6

Nivel

91

3. 4 MOPROSOFT

 

103

4

Calidad enfocada al desarrollo de software

123

4.1 ¿Qué es la calidad del

software?

123

4.2 Cómo obtener calidad de

124

4.3 Cómo controlar la calidad del

125

4.4 Costo de la calidad del

 

126

4.5 Nomenclatura y certificación ISO 9001:2000

129

4.6 La norma ISO/IEC 9126

134

4.7 Análisis de factores que determinan la calidad del software

136

4.8 Análisis del proceso del ciclo de vida del software

138

4.9 Funciones de evaluación del software

139

4.10 Preguntas de repaso y prácticas

144

ANEXOS

 

145

Anexo 1: Tareas por roles y fases de desarrollo

145

Anexo 2 Formato para planeación y registro de tiempo individual

151

Anexo 3 Formato auxiliar para postmortem y lecciones

152

Anexo 4 Entrevistas realizadas a profesionistas del área de calidad y

desarrollo de

 

157

Anexo 5 Referencias

164

Introducción

La calidad de los productos y servicios de software son una necesidad creciente para todo tipo de usuarios de los mismos; por lo tanto es un factor de competitividad de las empresas que los desarrollan y ofrecen ya que han de satisfacer las necesidades de sus clientes, no sólo para continuar en el mercado, sino, además para conseguir la superioridad, el liderazgo como una meta empresarial.

La industria de software es un sector donde el concepto de calidad total ha generado la revolución más radical, siendo la producción industrial de software una actividad con alta participación de recursos humanos, cien por ciento intelectual y en cierto sentido sin insumos ni materias primas.

Existen desarrolladores quienes continúan creyendo que la calidad es algo en lo que se debe comenzar a preocupar hasta después de que se ha generado el código pero hay que tomar conciencia que la calidad se aplica a lo largo del proceso de software.

En el texto que se presenta a continuación trata de auxiliar a los estudiantes y docentes de nivel superior a comprender los principales conceptos relacionados con la calidad de software y los estándares definidos a nivel nacional e internacional.; para que a su vez puedan ser aplicados en los proyectos en los que se contemple el desarrollo de software.

Agradezco las colaboraciones de la empresa ADQUEM, a Luis Carlos Vargas Herring (Microsoft USA), José Arturo Mora Soto (Universidad Carlos III España), María del Rocío Patiño Palacios (IMB Gdl. México), Fernando Nuñez Rojas (ITESI), Julio Armando Asato España (ITC), todos ellos exalumnos del Instituto Tecnológico de Celaya, quienes me brindaron su apoyo y experiencia para elaborar el presente texto.

1 Conceptos Básicos de Calidad 1.1 Definición de la calidad. Para comprender lo que es

1 Conceptos Básicos de Calidad

1.1 Definición de la calidad.

Conceptos Básicos de Calidad 1.1 Definición de la calidad. Para comprender lo que es 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.

1.2 Definición de calidad de software.

1.2 Definición de calidad de software. La calidad del software se define como: Concordancia con los

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.

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?

de concordancia es alta. 1.3 ¿Quién define la calidad? Debe entenderse que en cuestión de la

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.

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.

Estándar o Especificación

ENFOCADO A:

ISO/IEC 91261

Ingeniería de Software - Calidad de producto- Modelos de calidad.

ISO/IEC TR 91264

Ingeniería de software - Calidad de producto- Calidad en métricas de uso.

ISO 924111

Guías en Usabilidad.

Especificaciones ISO 20282

Usabilidad en productos de cada día. interfaz e interacción

ISO/IEC TR 91262

Ingeniería de software- Calidad de producto- Métricas externas.

Especificaciones ISO 9241

Requisitos ergonómicos para trabajo en oficinas y terminales de trabajo.

ISO/IEC TR 91263

Ingeniería de software- Calidad de producto- Métricas internas.

Especificaciones

Interacción de Diálogo - Control del cursor en edición de textos.

ISO/IEC 107411

ISO 9241

Requisitos ergonómicos para oficinas con terminales visuales.

Especificaciones

 

ISO/IEC 11581

Iconos, símbolos y funciones.

ISO 11064

Diseño ergonómico para centros de control.

Especificaciones

 

ISO 13406

Requisitos ergonómicos de trabajo de paneles planos.

ISO 14915

Ergonomía de software para interfaz multimedia.

Especificaciones

 

ISO/IEC 14754

Interfaz de escritura manual. Interacción

IEC TR 61997

Guías de interfaz de usuario en equipos multimedia de uso general.

Especificaciones

 

ISO/IEC 18021

Interfaz de usuario para dispositivos móviles.

ISO 18789

Requisitos ergonómicos y sistemas métricos para pantallas. Documentación

Estándar o Especificación

ENFOCADO A:

ISO/IEC 18019

Guías para el diseño y preparación de documentación de software de usuario.

Especificaciones

Documentación de procesos de software. de usuario proceso de desarrollo

ISO/IEC 15910

ISO 13407

Diseño de procesos interactivos.

ISO/IEC 14598

Evaluación de software.

ISO TR 16982

Métodos de soporte de diseños centrados en usuarios. capacidad de la empresa

ISO TR 18529

Procesos descriptivos de vida de producto, otros ISO

ISO 92411

Introducción general.

ISO 92412

Guía en requisitos de acciones.

iSO 100751

Principios ergonómicos de carga mental, términos y definiciones.

iSO DTS 16071

Guía de accesibilidad en interfaz de usuario.

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

BENEFICIOS PARA LOS CLIENTES • COSTO DE OPORTUNIDAD CONTROLADO Dependiendo de la importancia de la aplicación

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.

PARA EL ÁREA DE IT • REDUCCIÓN DE COSTOS DE DESARROLLO Principalmente costos asociados a

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.

1.5 La calidad y el mundo globalizado

1.5 La calidad y el mundo globalizado En un contexto dinámico y competitivo, la Calidad se

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

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.

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.

del cliente y la mejora de procesos. 1.6 Calidad de vida. La palabra calidad se deriva

La palabra calidad se deriva de cualidad que significa cada una de las circunstancias o caracteres superiores y excelentes que distinguen a las personas y cosas.

Vida significa: ―Fuerza interna substancial en virtud de la cual obra el ser que

la posee. Conducta o método de vivir con respecto a las acciones de los seres

humanos‖ .

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.

estar en la plenitud, es poder funcionar ciento por ciento. o Físicamente, significa encontrarse en buenas

o

Físicamente, significa encontrarse en buenas condiciones, fuerte, resistente

a

las enfermedades o poder sobreponerse rápidamente a ellas.

o

Psíquicamente, es poder disfrutar, hacerse cargo de las responsabilidades,

combatir la tensión nerviosa y el estrés.

o Emocionalmente, es estar en paz. La persona que mantiene su calidad de

vida es una persona que se siente bien, vigorosa, entusiasmada, con la

sonrisa propia del que se siente bien en todas sus dimensiones.

La calidad de vida es el bienestar, felicidad, satisfacción de la persona que le permite una capacidad de actuación o de funcionar en un momento dado de la vida.

La calidad de vida es: "la percepción que un individuo tiene de su lugar en la existencia, en el contexto de la cultura y del sistema de valores en los que vive y en relación con sus objetivos, sus expectativas, sus normas, sus inquietudes.

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, : Es la percepción del estado físico o la salud, entendida como ausencia de enfermedad, los síntomas producidos por la enfermedad, y los efectos adversos del tratamiento. No hay duda que estar sano es un elemento esencial para tener una vida con calidad.

Dimensión psicológica: Es la percepción del individuo de su estado cognitivo y afectivo como el miedo, : Es la percepción del individuo de su estado cognitivo y afectivo como el miedo, la ansiedad, la incomunicación, la pérdida de autoestima, la incertidumbre del futuro. También incluye las creencias personales, espirituales y religiosas como el significado de la vida y la actitud ante el sufrimiento.

Dimensión social: Es la percepción del individuo de las relaciones interpersonales y los roles sociales en : 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

médico-paciente y el desempeño laboral. 1.7 Calidad Total El término TQM (Total Quality Management) se acuña

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:

Hewlett-Packard’s Total Quality Control (TQC): ’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. Sigma Strategy.

Se

centra

en

conseguir niveles

satisfacción del usuario.

estrictos

de

IBM’s Market Driven Quality. BM’s Market Driven Quality.

calidad

para

obtener la

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

Medida y análisis : el objetivo es conducir la mejora continua en todos los parámetros

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 Proceso de mejora de la calidad basado en un ciclo de retroalimentación para optimizar un único proceso de producción.

para optimizar un único proceso de producción. Quality Improvement Paradigm (QIP). Pretende construir una

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.

y el aseguramiento de su estado relativo a esos objetivos. SEI Capability Maturity Model. (CMM) Proceso

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.

posteriores se abarcará con mas detalle este modelo. Leas Enterprise Management. Basado en el principio de

Leas Enterprise Management. Basado en el principio de concentración de la producción en actividades de valor añadido.

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.

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.

2 Aseguramiento de la Calidad del Software (SQA) La función de aseguramiento de la calidad

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.

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

El proceso define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnología de la ingeniería del software. El proceso del software forma la base para el control de la gestión de los proyectos de software y establece el contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.), se establecen los fundamentos, se asegura la calidad, y el cambio se maneja de manera apropiada.

Más adelante se abordarán los temas referentes a proceso y el enfoque de procesos para de esta forma comprender mejor los enfoques de calidad que se mencionaron en el párrafo anterior.

Los métodos de la ingeniería del software proporcionan los ―cómo‖ técnicos para construir software, Los métodos abarcan un amplio espectro de tareas que incluyen la comunicación, el análisis de requisitos, el modelado del diseño, la construcción del programa, la realización de pruebas y el soporte. Los métodos de la ingeniería del soltare se basan en un conjunto de principios básicos que gobiernan cada área de la tecnología e incluye actividades de modelado y otras técnicas descriptivas.

Las herramientas de la ingeniería del software proporcionan el soporte automatizado o semiautomatizado para el proceso y los métodos. Cuando las herramientas se integran de forma que la información que cree una de ellas pueda usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software, que con frecuencia se denomina ingeniería del software asistida por computadora.

2.2 Definición y propósito del SQA.

Antecedentes:

2.2 Definición y propósito del SQA. Antecedentes: El control y la garantía de la calidad son

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

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.del software, englobando los siguientes aspectos: Tecnología de ingeniería del software efectiva. Revisiones

Tecnología de ingeniería del software efectiva.los siguientes aspectos: Enfoque de gestión de calidad. Revisiones técnicas formales que se aplican durante el

Revisiones técnicas formales que se aplican durante el proceso del software.calidad. Tecnología de ingeniería del software efectiva. Estrategia de prueba multiescalada. El control de la

Estrategia de prueba multiescalada.formales que se aplican durante el proceso del software. El control de la documentación del software

El control de la documentación del software y de los cambios realizados.el proceso del software. Estrategia de prueba multiescalada. Procedimiento que asegure un ajuste a los estándares

Procedimiento que asegure un ajuste a los estándares de desarrollo del software.la documentación del software y de los cambios realizados. Mecanismos de medición y de generación de

Mecanismos de medición y de generación de informes.un ajuste a los estándares de desarrollo del software. 2.3 Problemas que resuelve el SQA. El

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 trabajo técnico, aplicando métodos sólidos y medidas, realizando revisiones y llevando a cabo pruebas de software.

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

Establecimiento de un plan de SQA para un proyecto.mantenimiento de registros, análisis e informes. Participación en el desarrollo de la descripción del

Participación en el desarrollo de la descripción del proceso de software del proyecto.Establecimiento de un plan de SQA para un proyecto. Revisión de las actividades de ingeniería del

Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido.de la descripción del proceso de software del proyecto. Auditoría de los productos de software designados

Auditoría de los productos de software designados para verificar el ajuste con los definidos como parte del proceso de software.para verificar su ajuste al proceso de software definido. Asegurar que las desviaciones del trabajo y

Asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con un procedimiento establecido.ajuste con los definidos como parte del proceso de software. Registrar lo superiores. que no se

Registrar loy se manejen de acuerdo con un procedimiento establecido. superiores. que no se ajuste a los

superiores.

que

no

se

ajuste

a

los

requisitos e

informar a sus

2.4 Calidad del software en el ciclo de vida del mismo

a sus 2.4 Calidad del software en el ciclo de vida del mismo Ciclo de vida

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

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

de su uso (norma ISO 12207-1) [ISO/IEC, 1995]. Objetivos Proporcionar una estrategia de desarrollo y un

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

Explotación

Mantenimiento

PROCESOS DE SOPORTE

Documentación

Gestión de la configuración

Aseguramiento de la calidad Verificación Validación Revisión Conjunta Auditoría

Resolución de problemas

PROCESOS DE LA ORGANIZACIÓN

Gestión

Infraestructura

Mejora

Formación

Fig. 2 Procesos del ciclo de vida.

Procesos principales:

Son los que resultan útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software durante su ciclo de vida.

Proceso de adquisición

Actividades y tareas que se realizan para comprar un producto software.

Proceso de suministro

Actividades y tareas que el suministrador realiza.

Proceso de desarrollo

Contiene las actividades de análisis de requisitos, diseño, codificación, integración, pruebas e instalación y aceptación.

Proceso de explotación

Incluye la explotación del software y el soporte operativo a los usuarios.

Proceso de mantenimiento

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.

Procesos de soporte

Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida.

Proceso de documentación

Registra la información producida por un proceso o actividad en el ciclo de vida.

Proceso de gestión de la

Aplica ciertos procedimientos y técnicas durante todo el ciclo de vida del sistema.

configuración

Proceso de aseguramiento de

Aporta la confianza de que los procesos y los productos software del ciclo de vida cumplen los requisitos especificados y se ajustan a los planes establecidos.

la calidad

Proceso de verificación

Determina si los requisitos de un sistema o del software están completos y son correctos.

Proceso de validación

Sirve para determinar si el sistema o software final cumple con los requisitos previstos para su uso.

Proceso de revisión conjunta

Sirve para evaluar el estado del software y sus productos en una actividad del ciclo de vida o una fase de un proyecto.

Proceso de auditoría

Permite determinar, en los hitos predeterminados, si se han cumplido los requisitos, los planes y el contrato.

Proceso de resolución de

Permite analizar y eliminar los problemas descubiertos durante el desarrollo, explotación, el mantenimiento u otro proceso.

problemas

Procesos de soporte:

Sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida.

Proceso de documentación:

Proceso de gestión de la configuración:

Proceso de aseguramiento de la calidad

Proceso de verificación

Proceso de validación

Proceso de revisión conjunta

Proceso de auditoría

Proceso de resolución de problemas

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.

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.

Proceso de Gestión

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

Proceso de infraestructura

Establece la infraestructura necesaria para cualquier otro proceso.

Proceso de mejora

Sirve para establecer, valorar, medir, controlar y mejorar los procesos del ciclo de vida del software.

 

Sirve

para

proporcionar

y

mantener

al

Proceso de formación

personal formado.

 

De los procesos anteriores existe otro muy importante si se requiere hacer la adaptación a la norma ISO-12207 que debe ser considerado.

Proceso de adaptación:

Sirve para realizar la adaptación básica de la norma ISO-12207 con respecto a los proyectos software. Es necesario comprender los procesos, las organizaciones y sus relaciones bajo diferentes puntos de vista:

y sus relaciones bajo diferentes puntos de vista: Bajo el punto de vista del contrato, el

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.

Bajo el punto de vista de gestión, el comprador, el proveedor, el desarrollador, el operador

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

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

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

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.

de la calidad ) proporcionan servicios de apoyo a otros grupos en el cumplimiento de tareas

2.5 Roles y responsabilidades de los equipos de desarrollo.

¿Qué es un equipo?

de los equipos de desarrollo. ¿Qué es un equipo? ―Al menos dos personas quienes están trabajando

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

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.

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.

La fábula de la granja

La fábula de la granja Un día cualquiera, los animales de una granja decidieron hacer una
La fábula de la granja Un día cualquiera, los animales de una granja decidieron hacer una
La fábula de la granja Un día cualquiera, los animales de una granja decidieron hacer una

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.

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.

Aspectos a considerar son :

Crear un lenguaje común entre el equipo de desarrollo, así como hacer que entiendan claramente sus deberes y obligaciones.Aspectos a considerar son : Por otro lado, los clientes también deben estar comprometidos con el

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.hacer que entiendan claramente sus deberes y obligaciones. En caso que el cliente no tenga dicha

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.en todas aquellas actividades de revisión y aceptación. Es claro entonces que todos los integrantes del

Es claro entonces que todos los integrantes del equipo de desarrollo debiesen estar comprometidos con el proyecto, incluyendo los clientes.en la senda correcta del éxito de un proyecto de software. Lo anterior implica trabajar con

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.todos los integrantes del equipo de desarrollo debiesen estar comprometidos con el proyecto, incluyendo los clientes.

2.6 Habilidades y capacidades del personal del SQA

2.6 Habilidades y capacidades del personal del SQA El asegurador de calidad debe ser una persona

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.

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.

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.

• Documentador: El asegurador de calidad revisa la documentación, para asegurarse que corresponde con el software desarrollado, y que cumple con el estándar en uso.

• Administrador de configuración: El asegurador de calidad revisa los registros de cambios, errores y de configuración, para asegurarse de que los cambios han sido implementados apropiadamente, y que las líneas bases son almacenadas y que el producto no se puede perder.

2.7 Actividades del SQA.

A continuación se presentan las actividades y metas a cumplir por los aseguradores de calidad.

Actividades

Revisar los documentos de requisitos

de usuario y de software

Revisar el plan de administración del

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.

Metas

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.

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.

diseñadores. Asegurarse que el plan es creado y se cumple. Asegurarse que el plan se crea,

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.

seleccionaron la metodología apropiada y que el producto final cumple con los requisitos de diseño y

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

de errores en cada fase del desarrollo y que se respaldan las líneas bases haciendo que
de errores en cada fase del desarrollo y que se respaldan las líneas bases haciendo que

Asegurarse que la documentación cumple con el estándar utilizado durante el desarrollo del producto de software.

2.8 Métodos y herramientas.

2.8 Métodos y herramientas. Existen varios métodos y herramientas que pueden ser aplicados durante el desarrollo

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.de los errores de diseño. Los objetivos de las RTFs son: Verificar que el software bajo

Verificar que el software bajo revisión cumple con los requisitos.en cualquiera de las representaciones del software. Asegurarse que el software ha sido representado de acuerdo

Asegurarse que el software ha sido representado de acuerdo al estándar en uso.que el software bajo revisión cumple con los requisitos. Alcanzar software que es desarrollado en forma

Alcanzar software que es desarrollado en forma uniforme.Asegurarse que el software ha sido representado de acuerdo al estándar en uso. Hacer el proyecto

Hacer el proyecto más manejable.software ha sido representado de acuerdo al estándar en uso. Alcanzar software que es desarrollado en

Una RTF es una reunión entre tres a cinco personas. Cada una de ellas ha

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.

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.

2.9.1 Definición de Proceso y Enfoque de procesos

Antes de definir lo que es un proceso de desarrollo de software, entendamos lo que es un proceso:

Proceso:

Una definición sencilla de proceso es ―serie de acciones que conducen a un final‖.

Esta definición parece coincidir con las ideas generales de la gente sobre procesos, pero deja muchas preguntas abiertas:

¿El proceso es la forma en que la organización opera desde mercadotecnia hasta recursos humanoso 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.

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

un servicio, innovar y extender un producto de software”. Fig. 3 Proceso de software Un proceso

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.

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.

y personalizado para que cumpla con necesidades específicas. Fig. 4 Elementos típicos del proceso de software.

Fig. 4 Elementos típicos del proceso de software.

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?

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.que nos hacen creer en esta oportunidad son los siguientes: El modelo que utilizan nuestros competidores

El modelo que utilizan nuestros competidores (CMMI) es complejo y apropiado para organizaciones grandes.son los siguientes: La gran mayoría de las empresas que desarrollan software en México son menores

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

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á:ha probado ser más eficaz que el CMMI Nivel 5. Posicionarse como el país con mejor

Posicionarse como el país con mejor calidad y valor agregado de manera ágil, adelantándonos a las capacidades de nuestros competidores.Con la implementación de este proyecto México logrará: Contar con un método avalado por el SEI

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.adelantándonos a las capacidades de nuestros competidores. Que la calidad de los desarrollos con talento mexicano

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.proyectos desarrollados por las empresas que usan el TSP. Las metas para alcanzar a corto plazo

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.se transforma en una ventaja de costo. Las metas para alcanzar a corto plazo con la

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

Los estudios de impacto del TSP, para ajustar su uso y prácticas.del método de mejora acelerada a través del TSP+CMMI. Desarrollar una infraestructura de instructores y coaches

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.de impacto del TSP, para ajustar su uso y prácticas. Si bien, la Secretaría de Economía

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

organizacionales. PSP – Personal Software Process Personal Software Process (PSP) es un proceso diseñado para

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á

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.

Documentación. Pruebas de sistemas. Mantenimiento de sistemas. Fig. 5 Proceso de Software Personal (PSP) 51

Fig. 5 Proceso de Software Personal (PSP)

TSP - Team Software Process

TSP - Team Software Process Team Software Process (TSP) es un marco para el desarrollo de

Team Software Process (TSP) es un marco para el desarrollo de software que pone igual énfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue propuesto por Watts Humphrey. TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es desarrollado por equipos, por lo que los ingenieros de software deben primero saber controlar su trabajo, y después saber trabajar en equipo. TSP le enseña a los ingenieros a construir equipos autodirigidos y desempeñarse como un miembro efectivo del equipo. También muestra a los administradores como guiar y soportar estos equipos.

Estrategia de TSP

• Proveer un proceso sencillo basado en PSP

• Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento,

Estrategia, Plan, Requerimientos, Diseño, Implementación, Pruebas, Postmortem

• Establecer medidas estándares para calidad y desempeño

• Proveer definiciones de roles, y evaluaciones de rol y de equipo

• Requiere disciplina de proceso

• Provee guía para manejo de problemas de trabajo en equipo.

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.puros o equipos de producto integrado de 3 a 20 integrantes. Acelerar el mejoramiento del software

Acelerar el mejoramiento del software a realizar, con el comportamiento normal y esperado, el nivel 5 de CMMsus equipos y como ayudarlos a sostener un alto desempeño. Ofrecer una guía de mejoramiento a

Ofrecer una guía de mejoramiento a organizaciones de alta madurez.con el comportamiento normal y esperado, el nivel 5 de CMM Facilitar la enseñanza universitaria de

Facilitar la enseñanza universitaria de habilidades de equipo industrial de calidad.una guía de mejoramiento a organizaciones de alta madurez. El equipo autodirigido entiende en forma consistente

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.

Planteamiento de la necesidad Ciclo 1 Lanzamiento Ciclo 2 Lanzamiento Ciclo 3 Lanzamiento Estrategia 1
Planteamiento de la necesidad
Ciclo 1
Lanzamiento
Ciclo 2
Lanzamiento
Ciclo 3
Lanzamiento
Estrategia 1
Estrategia 2
Plan 1
Plan 2
Estrategia 3
Requerimientos 1
Requerimientos 2
Plan 3
Diseño 1
Diseño 2
Requerimientos 3
Implementación 1
Implementación 2
Diseño 3
Pruebas 1
Pruebas 2
Implementación 3
Postmortem 1
Postmortem 2
Pruebas 3
Postmortem 3

Producto terminado

Evaluación final

Fig.6 Estructura y flujo del TSP

El TSP define las siguientes actividades del marco de trabajo: lanzamiento, diseño de alto nivel, implementación, integración y prueba, análisis de resultados. Al igual que sus contrapartes en el PSP, estas actividades permiten al equipo planear, diseñar y construir un software de una manera disciplinada al mismo tiempo que miden de modo cuantitativo el proceso y el producto. El análisis de resultados muestran el escenario para el mejoramiento del proceso.

El TSP utiliza una amplia variedad de escritos, formas y estándares que sirven para guiar a los miembros del equipo en su trabajo. Los escritos (scripts) definen actividades específicas del proceso (por ejemplo lanzamiento, diseño, implementación, integración y prueba de unidad) que son parte del proceso del equipo.

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

Establecer las funciones del equipo.las de gestión, acordar, y documentar las metas del equipo. Definir el proceso de desarrollo del

Definir el proceso de desarrollo del equipo.las metas del equipo. Establecer las funciones del equipo. Elaborar un plan de calidad y plantear

Elaborar un plan de calidad y plantear los objetivos de calidad.del equipo. Definir el proceso de desarrollo del equipo. Preparar un plan para las necesidades de

Preparar un plan para las necesidades de soporte necesarias.un plan de calidad y plantear los objetivos de calidad. Producir una estrategia de desarrollo general

Producir una estrategia de desarrollo generalPreparar un plan para las necesidades de soporte necesarias. Elaborar un plan de desarrollo para el

Elaborar un plan de desarrollo para el proyecto en su totalidad.necesarias. Producir una estrategia de desarrollo general Hacer planes detallados para cada ingeniero en la siguiente

Hacer planes detallados para cada ingeniero en la siguiente fase.un plan de desarrollo para el proyecto en su totalidad. Adaptar los planes individuales a un

Adaptar los planes individuales a un plan de equipo.planes detallados para cada ingeniero en la siguiente fase. Hacer un balance de la cantidad de

Hacer un balance de la cantidad de trabajo para obtener un programa mínimo en términos generales.fase. Adaptar los planes individuales a un plan de equipo. Valorar los riesgos del proyecto y

Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave.a un plan de equipo. Hacer un balance de la cantidad de trabajo para obtener un

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.

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.

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.

3 Estándares de calidad aplicados al software. 3.1 ISO En el capitulo I se mencionaron

3 Estándares de calidad aplicados al software.

3.1 ISO

3 Estándares de calidad aplicados al software. 3.1 ISO En el capitulo I se mencionaron las

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

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.

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.

las

actividades interrelacionadas se comprenden y gestionan en forma sistemática a partir de una información fiable.

Enfoque

e

procesos:

Se

consigue

mayor

efectividad

cuando

todas

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.

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 operacioneshan ganado al implementar los sistemas de calidad ISO 9000: Mejoramiento en la calidad de servicio

Mejoramiento en la calidad de servicio a sus clientes con aseguramientolos sistemas de calidad ISO 9000: Mejor control de sus operaciones Un sistema de calidad extenso

Un sistema de calidad extenso y formal l l

Incremento en la retroalimentación del empleado en el proceso de toma de decisiones Mejora en

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.

de los errores Una excelente herramienta de mercadotecnia. 3.1 SPICE Antecedentes: Debido al incremento del número
de los errores Una excelente herramienta de mercadotecnia. 3.1 SPICE Antecedentes: Debido al incremento del número
de los errores Una excelente herramienta de mercadotecnia. 3.1 SPICE Antecedentes: Debido al incremento del número

3.1 SPICE

Una excelente herramienta de mercadotecnia. 3.1 SPICE Antecedentes: Debido al incremento del número de modelos y

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.

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.resultante del proyecto debía cumplir ciertos objetivos: Establecer mecanismos que permitieran migrar desde

Establecer mecanismos que permitieran migrar desde estándares ya establecidos, así como evitar la aparición de otros estándares contrastantes.suficientemente específico como para ser útil y manejable. Proporcionar un programa de transferencia tecnológica que

Proporcionar un programa de transferencia tecnológica que permitiera la adopción del nuevo estándar.evitar la aparición de otros estándares contrastantes. De los años 1993 a 1995 se desarrollaron y

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.

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

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.

bien determinadas y complementarias, la Fig. 7 nos muestra la Arquitectura de SPICE. Fig. 7 Arquitectura

Fig. 7 Arquitectura de SPICE

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.

en tantos por cientos, como se muestra en la Fig. 8. Fig.9 SPICE: Relación de dimensiones

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.

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.

Fig.10 Arquitectura de los procesos según SPICE Los niveles considerados por el estándar son mostrados

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.

Fig.10 Niveles de capacidad y Atributos de Proceso Los valores son asignados en una escala

Fig.10 Niveles de capacidad y Atributos de Proceso

Los valores son asignados en una escala de cuatro puntos (Fig.11): no alcanzado, parcialmente alcanzado, altamente alcanzado, y totalmente alcanzado. Considerando el valor de cada atributo se podrá determinar en qué nivel se encuentra el proceso estudiado.

El modelo de evaluación se basa en el principio de que la capacidad del proceso se puede evaluar si se demuestra la consecución de los atributos del proceso.

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

Valores posibles del atributo

Grado de

 

alcance

Situación para determinar el grado de alcance del atributo

   

Indica un poco o nula evidencia de que se ha alcanzado este atributo en el proceso evaluado.

N

No alcanzado

0% -15%

 

P

Parcialmente

 

Se evidencia una aproximación sistemática del alcance del atributo, pero algunas de sus características no se dan.

alcanzado

16% -50%

 

L

Ampliamente

 

Hay bastantes evidencias de que se alcanza el atributo, pero la realización del proceso diverge en alguna área.

alcanzado

51% - 85%

 
   

Hay evidencia de que el atributo se alcanza plenamente y de manera sistemática en el proceso evaluado y no hay debilidades importantes en la unidad organizacional en la que se ubica el proceso.

 

F

Completamente

86%-100%

 

alcanzado

 

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

Nivel de

Atributos de los procesos (PA)

 

Capacidad

 

Descripción

 
 

0

No hay atributos en este nivel

 
   

Representa la medida de cuándo se alcanza el propósito de un proceso, transformando los productos de entrada en productos de salida.

Realización del proceso

1

(PA.1.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 la realización

(PA.2.1)

2

 

Gestión de productos resultantes (PA.2.2)

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

Definición de los procesos

(PA.3.1)

3

 
 

Representa

el

nivel

de

adecuación

de

la

 

Aplicación del proceso

 

(PA.3.2)

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 utilizados para asegurar que la realización del proceso soporte el alcance de los objetivos definidos como apoyo en los objetivos de negocio.

Medida del proceso (PA.4.1)

4

 
 

Representa el nivel de control del proceso a través de la recopilación, análisis y uso de medidas de proceso y de producto, para corregir, en caso necesario, su rendimiento y para conseguir los objetivos de proceso y de producto definidos.

 

Control del proceso (PA.4.2)

   

Representa el nivel de control de los cambios en la definición, gestión y realización del proceso con el fin de alcanzar los objetivos de negocio fijados en la organización.

Innovación de los procesos

(PA.5.1)

5

 
 

Representa el nivel bajo el cual se identifican e implantan los cambios en los procesos, para conseguir una mejora continua en el cumplimiento de los objetivos de negocio de la organización.

 

Optimización de los procesos

(PA.5.2)

Fig.12 Atributos de los procesos asociados a los niveles de capacidad

de ISO/IEC 15504

Fig.13 Ejemplo de perfil de evaluación de proceso. La Fig. 13 muestra un ejemplo de

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.

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)

de capacidad es 2. 3.3 CMM (Capability Maturity Model ) El modelo Capability Maturity Model (CMM

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

utilizada por la comunidad de software durante 1991 y 1992, en abril de ese año surgió la primera versión definitiva, CMM Versión 1.0.

CMM contiene los elementos esenciales para conseguir procesos eficaces en uno o más cuerpos de conocimiento, estando estos elementos basados en los conceptos desarrollados por Crosby, Deming, Juran y Humphey.

En el año 2000 el CMM fue actualizado hacia el modelo CMMI (Capability Maturity Model Integration).

En junio del 2009 tuvo lugar en León (España la presentación mundial de la traducción al castellano del Modelo de Mejora de Procesos CMMI para Desarrollo de Software. La traducción ha sido desarrollada por la Cátedra de Mejora de Procesos de Software en el Espacio Iberoamericano, dirigida por Gonzalo Cuevas. España es el segundo país de Europa (con 105 evaluaciones CMMI, por detrás de Francia que tiene 141) y el noveno a nivel mundial en número de empresas evaluadas sobre el Modelo para el Desarrollo (CMMI- DEV), pero sólo estaba disponible en inglés, francés, chino y japonés, lo que se traducía en que muchas compañías, sobre todo las de menor tamaño, tuvieran dificultades para acceder al mismo.

3.3.1 Definición del modelo

El modelo de madurez guía a las organizaciones indicando cómo mejorar los procesos asociados al desarrollo y mantenimiento del software. La filosofía general que rige a este modelo se fundamenta en diferentes niveles de madurez entendidas como sucesivas etapas cuyo objetivo es la obtención de un proceso de software optimizado, en cada nivel, además de establecer una escala de medida de la capacidad de los procesos, se fijan unos objetivos que

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.

Fig.14 Niveles de madurez de CMM. Fig. 15 Estructura de los niveles de madurez de

Fig.14 Niveles de madurez de CMM.

Fig.14 Niveles de madurez de CMM. Fig. 15 Estructura de los 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

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 Ejecutarclave se dividen en cinco secciones de aspectos comunes: Habilidad para Ejecutar Actividades Realizadas Medición y

Habilidad para Ejecutarsecciones de aspectos comunes: Compromiso para Ejecutar Actividades Realizadas Medición y Análisis Verificación

Actividades Realizadascomunes: Compromiso para Ejecutar Habilidad para Ejecutar Medición y Análisis Verificación de Implementación

Medición y Análisispara Ejecutar Habilidad para Ejecutar Actividades Realizadas Verificación de Implementación Prácticas Clave: Cada

Verificación de Implementaciónpara Ejecutar Actividades Realizadas Medición y Análisis Prácticas Clave: Cada área clave de proceso está descrita

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

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

de Cambios de Tecnología KPA3. Prevención de defectos NIVEL 4 KPA1. Administración de la Calidad del

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

3.3.2 Nivel inicial.

3.3.2 Nivel inicial . El nivel 1 o inicial es el estado primario en la evolución

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

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.

3.3.3 Nivel repetido.

3.3.3 Nivel repetido . El nivel 2 o Repetible hace posible la implementación de prácticas mínimas

El nivel 2 o Repetible hace posible la implementación de prácticas mínimas de administración de proyecto, de control de requerimientos, versiones de producto y de proyectos realizados por subcontratistas. El grupo o equipo humano que realizó el proyecto puede aprovechar su experiencia e inversión en procesos para aplicarla en un nuevo proyecto.

Este nivel no garantiza que todos los proyectos dentro de la empresa estén necesariamente al mismo nivel de madurez. Algunos pueden estar todavía en el nivel inicial. He visto algunos casos en la práctica y en todos ellos estos proyectos fueron ineficientes con respecto a los de mayor madurez, malgastando el éxito de estos últimos. Eventualmente algunos invirtieron los esfuerzos necesarios para ponerse a tono, otros simplemente fueron cerrados con un elevado costo de frustración y descalabro de carreras profesionales.

Beneficios de implantar el Nivel 2 del CMM

El mayor beneficio obtenido de la implementación del nivel 2 por la empresa en la cual me desempeño actualmente, es la planificación realista de los proyectos. Antes los cronogramas de proyecto expresaban más los deseos de la gerencia que la realidad. Este principio (el mismo en la cual se basa la magia) conducía una situación de buscar culpables y generar excusas, produciendo al mismo tiempo frustración y desconfianza entre clientes y empleados. Actualmente los cronogramas son cada día más confiables, y mejora a medida que se acumula más información en las bases de datos de los proyectos pasados. El uso generalizado de métodos de estimación permite al personal del proyecto de justificar plazos y recursos. Aún el "olfato profesional" y la experiencia personal juegan un papel importante en la generación de planes de

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

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.

Meta

3:

Los

individuos

y

grupos

afectados

acuerdan

vinculados con el proyecto de software.

sus

compromisos

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.

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

Meta

1:

El

principal

contratista

selecciona

subcontratistas

de

4:

El

contratista

principal

sigue

los

resultados

y

desempeño

del

subcontratista de software contra sus compromisos. Aseguramiento de Calidad de software

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:

estándares,

objetivamente.

La adhesión

de

los

procedimientos

productos y

y

actividades de software a los

verifica

requerimientos

aplicables

se

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.

3.4 Nivel definido.

3.4 Nivel definido. La empresa ha definido un conjunto de procesos, metodologías y herramientas comunes a

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

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.

uso por los proyectos de software del

proceso estándar de software de la organización, se reúne, revisa y está

disponible

Meta 2: La información relativa al

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:

adaptada del proceso estándar de software de la organización.

El

proceso de software definido para el proyecto es una versió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í.

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.

3.3.5 Nivel administrado.

3.3.5 Nivel administrado. En este nivel la corporación mide la calidad del producto y del proceso

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

NIVEL 4 GESTIONADO (ADMINISTRADO)

KPA1. Administración de la Calidad del Software KPA2. Administración Cuantitativa del Proceso

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.

3.3.6 Nivel optimizado.

3.3.6 Nivel optimizado. En el Nivel Optimizado, la característica principal es el mejoramiento continuo del proceso,

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

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:

métodos, procesos) y transferirlos a la organización.

Identificar

las

nuevas

tecnologías

beneficiosas

(herramientas,

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.

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. 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.es que CMM hace hincapié en la mejora continua del proceso. Aspecto: Nivel de Detalle La

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 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.de 12 páginas de largo, contra más de 500 páginas de CMM. Aspecto: Auditores Los auditores

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.el estándar de maneras diferentes. Aspecto: Auditores Para auditorias específicas de software debería integrarse

Para auditorias específicas de software debería integrarse al equipo personas con conocimientos en la disciplina.los estándares de la Serie ISO 9000, pero no son entrenados en conocimiento sobre aspectos específicos

Otra razón de discrepancia es que un Auditor puede no requerir maestría para satisfacer la

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.

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.

AREA CLAVE 2.2 Planificación de Proyectos de Software

Propósito

:

de

Software y para administrar el proyecto de Software. Estos planes son la base de la gestión del proyecto, 2.3.(siguiente KPA)

Establecer planes

razonables

para

ejecutar la

Ingeniería

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

vinculados con el proyecto de software.

afectados acuerdan sus compromisos

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.

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

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.

Se asignan responsabilidades para el desarrollo del plan de desarrollo3. La directiva de trabajo es administrada y controlada. de software. 1.El gerente del PSw, directamente

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.

. Se proveen adecuados recursos y fondos para el planeamiento del PSw. 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

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.

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.

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.

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?del Plan de Desarrollo de Software. Cuestionario de madurez ¿Los planes de software documentan las actividades

¿Los planes de software documentan las actividades a ser ejecutadas y los compromisos hechos?