• No se han encontrado resultados

Enseñando Aseguramiento de la Calidad del Software en un Programa de Posgrado

N/A
N/A
Protected

Academic year: 2021

Share "Enseñando Aseguramiento de la Calidad del Software en un Programa de Posgrado"

Copied!
8
0
0

Texto completo

(1)

Enseñando Aseguramiento de la Calidad del Software en un Programa de Posgrado

Marcelo Jenkins

Escuela de Ciencias de la Computación e Informática Universidad de Costa Rica

San Pedro, Costa Rica 2060 mjenkins@cariari.ucr.ac.c.r

Resumen

El aseguramiento de la calidad del software es uno de los temas más actuales e importantes dentro de la disciplina de la ingeniería de software. Este artículo describe la experiencia de enseñar aseguramiento de la calidad del software a estudiantes de posgrado. Describimos en detalle el diseño de un curso de posgrado en este tema y la experiencia de haberlo impartido en cuatro ocasiones.

Los puntos descritos en este artículo pueden interesar profesores e instructores que desean formar ingenieros de aseguramiento de la calidad del software a nivel de posgrado.

Palabras claves: enseñanza de ingeniería de software, aseguramiento de la calidad del software, ISO 9000, CMM.

1. Introducción

El aseguramiento de la calidad del software es uno de los temas más actuales e importantes dentro de la disciplina de la ingeniería de software, y curiosamente, es uno de los temas más olvidados en los programas de estudio universitarios. Cada vez más las organizaciones de software están empezando a reconocer la importancia de contar con ingenieros de software especializados en el área de calidad, y particularmente con conocimientos en áreas tales como administración de la calidad del software, administración de procesos de software, administración de proyectos, métricas de software, administración de la configuración, y pruebas de software.

Con el propósito de llenar esta necesidad, el Programa de Maestría en Computación e Informática de la Universidad de Costa Rica ha venido ofreciendo a sus estudiantes una serie de cursos en estos temas. Este artículo describe la experiencia de los últimos cuatro años en la enseñanza de aseguramiento de la calidad del software a estudiantes de posgrado. Describimos en detalle el diseño de un curso de posgrado en este tema y la experiencia de haberlo impartido en cuatro ocasiones. Los puntos descritos en este artículo pueden interesar profesores e instructores que desean formar ingenieros de aseguramiento de la calidad del software a nivel de posgrado.

2. Antecedentes

Programa de Maestría en Computación e Informática de la Universidad de Costa Rica inició en agosto de 1995 y actualmente cuenta con unos 150 estudiantes activos, de los que el 95% trabaja tiempo completo. A la fecha han graduado más de 100 estudiantes.

El programa consta de 10 cursos (o 8 cursos y una tesis) que pueden completarse en 2 años. Todos los cursos son electivos y son escogidos por los estudiantes según sus intereses. Se trabaja en semestres de 16 semanas lectivas con cursos de 4 horas lectivas semanales (4 créditos), lo que nos da 64 horas lectivas por curso.

Una de las principales áreas de concentración es la ingeniería de software. Dentro de los cursos que componen esta área se encuentra PF-3319 Estándares de Calidad para Desarrollo de Software.

(2)

3. Área de Ingeniería de Software

El área de ingeniería de software en una de las más importantes dentro del Programa de Maestría pues debido a que estimamos que más del 75% de nuestros graduados se emplean en la industria del desarrollo de sistemas. Más aún, el mercado laboral requiere de ingenieros de calidad en software pues este tipo de especialidad tiene cada día más demanda en nuestro medio.

En el proceso de diseñar un curso de posgrado en aseguramiento de la calidad del software, uno se enfrenta con el problema: de cómo enseñar tan amplio tema en un solo curso. Al diseñar este curso, nos propusimos tres objetivos principales.

1. Cubrir las metodologías y herramientas básicas de aseguramiento de la calidad del software.

2. Crear un curso muy prácticos donde el estudiante aprenda a aplicar estas las metodologías y herramientas en organizaciones de sistemas de información.

3. Complementar cualquier falta de contenidos con los cursos electivos adicionales (por escoger por cada estudiante).

Un estándar de ingeniería de software es una regla o base de comparación que se utiliza para medir aspectos del software tales como calidad, productividad, duración, esfuerzo, y costo.

El uso sistemático de estándares de ingeniería de software puede mejorar significativamente la calidad del software que produce una organización [SF96][Jenk96]. En la actualidad existen más de 250 diferentes estándares de ingeniería de software elaborados por diferentes organismos de estandarización, todos con diferentes grados de detalle, cobertura, y aplicabilidad. Generalmente, el propósito, el enfoque y el nivel de adaptabilidad de estos estándares varia grandemente, lo que dificulta el proceso de selección de los estándares adecuados a una organización.

La Figura 1, reproducida del Software Productivity Consortioum 1, muestra parcialmente el estado actual de los principales estándares internacionales de calidad de software. Actualmente los principales estándares y normas de calidad son el CMM, el ISO 9000, y el ISO 15504.

Figura 1. Los principales estándares internacionales de calidad de software.

1 Fuente: www.software.org/quagmire

(3)

4. Descripción del Curso de Posgrado

Ante esta situación, se plantean varias interrogantes:

1. Cómo enseñar tantos estándares en un solo curso?

2. Cómo impartir un curso práctico en el que los estudiantes aprendan utilizando estándares en organizaciones de software?

Con estas interrogantes en mente, diseñamos el curso de posgrado descrito a continuación

Nombre:

PF-3319 Estándares de Calidad para Desarrollo de Software Objetivo:

Introducir los principales estándares internacionales de calidad para desarrollo de software y analizar su utilidad en el mejoramiento del proceso de software de una organización de sistemas.

Objetivos específicos:

A finalizar el curso el estudiante será capaz de:

1. Diferenciar los diferentes grupos de estándares internacionales de calidad para software y su campo de aplicación.

2. Utilizar estándares modernos de aseguramiento de la calidad en el proceso de desarrollo de software.

3. Llevar a cabo evaluaciones o auditorias de calidad con base en un estándar o modelo de calidad.

Contenidos:

I. Aseguramiento de la calidad del software (SQA): conceptos, estándares de calidad y mejoramiento del proceso de software, principios de calidad del software, Estándar IEEE 730 para Planes de Aseguramiento de la Calidad del Software, Estándar IEEE 1028 para Revisiones de Software

II. El modelo de Capacidad Madurez (CMM): estructura y organización, niveles de madurez y áreas claves del proceso, proceso de evaluación CBA-IPI.

III. Otros modelos de capacidad madurez del SEI: P-CMM, SA-CMM, CMMI.

IV. El estándar ISO 9000:2000: estructura y organización, requerimientos del sistema de calidad, auditorias de calidad, Estándar ISO/IEC 10011 para Auditorias de calidad.

V. El estándar ISO 15504 (SPICE): estructura y organización, el modelo de referencia, evaluaciones de procesos de software, relación con otros modelos de calidad.

VI. Otros estándares: STD IEEE 1074, STD IEEE 12207, MIL-STD-498, STD IEEE 1059, ISO/IEC 12119.

VII. Epílogo: casos prácticos, utilidad de los estándares, costo de implementación.

Metodología:

La mayor parte del curso se llevará a cabo mediante el sistema de lecciones magistrales. Como material de lectura se utilizará un compendio de capítulos de diferentes libros y artículos de revistas. El profesor complementará el material del compendio con ejemplos de otras fuentes.

Se espera que los estudiantes participen activamente en las secciones mediante el uso de preguntas e intervenciones que enriquezcan la discusión. Cada estudiante dispone del material asignado para cada lección según el cronograma del curso. Las lecturas están numeradas en el orden en que deben ser leídas.

Cada estudiante desarrollará dos trabajos prácticos y una exposición en grupos de 3 personas. Los proyectos prácticos se hacen en grupos de 3 personas y se entregan en las fechas indicadas en el cronograma. El profesor proporcionará una descripción escrita de cada trabajo a realizar.

(4)

La exposición consiste en preparar una presentación de 60 a 90 minutos sobre un tema específico asignado por el profesor. El material básico de cada tema está incluido en el material del curso. La exposición se evaluará tomando en cuenta criterios tales como: dominio del tema, completitud de la investigación, calidad de la exposición oral, y aporte de los expositores al tema.

·Los exámenes parciales consisten en preguntas de opción múltiple, son a libro cerrado, y se harán en las fechas definidas en el calendario del curso.

Evaluación:

No

. Question Respondent Totals

A B C D E F G H I J K M N O P Q Y N Y/Y+N 1 Are estimates (e. g., size, cost, and schedule) documented for

use in planning and tracking the software project? Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y 16 0 1 2

Do the software plans document the activities to be performed and the commitments made for the software

project? Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y 15 1 0.94

3 Do all affected groups and individuals agree to their commitments related to the software project? Y Y Y Y Y Y Y Y NK Y Y Y Y Y N N

K 13 1 0.93 4 Does the project follow a written organizational policy for

planning a software project? Y Y Y Y Y Y Y Y N

K Y Y Y Y Y Y Y 15 0 1 5 Are adequate resources provided for planning the software

project (e. g., funding and experienced individuals)? Y Y N Y Y Y Y Y N Y Y Y Y Y N

K Y 13 2 0.87 6

Are measurements used to determine the status of the activities for planning the software project (e. g., completion of milestones for the project planning activities as compared to the plan)?

Y Y N

K Y Y Y Y Y Y Y Y Y Y Y Y Y 15 0 1 7 Does the project manager review the activities for planning

the software project on both a periodic and event-driven basis?

Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y 16 0 1

I Parcial 25%

II Parcial 25%

2 Proyectos prácticos 40%

Evaluación CMM 20%

Auditoria ISO 15504 20%

Exposición 10%

4.1 Proyecto práctico I

Objetivo:

Aplicar los conocimientos adquiridos en la aplicación del modelo CMM.

Objetivo específico:

Utilizar una metodología simple para realizar una evaluación CMM del proceso de desarrollo de software de una organización.

Metodología:

El trabajo consiste en llevar acabo una evaluación CMM de niveles 2 y 3 del proceso de desarrollo de software de una organización utilizando la metodología de evaluación de Daskalantonakis [3] vista en clase. La recolección de la evidencia debe hacerse utilizando los formularios (“workbooks”) y el cuestionario de madurez del CMM [2]

vistos en clase.

La evaluación debe contemplar únicamente las 13 áreas clave del proceso (KPA´s) de los niveles 2 y 3 del CMM. Si se considera necesario, la evaluación se puede circunscribir a una división o departamento de la organización, o a algún tipo de sistemas de software o proyecto en vez de toda la empresa. En este caso, en el reporte del trabajo debe justificarse esta decisión. La Tabla 1 resume los resultados de sumarizar las respuestas al cuestionario de madurez del CMM [20].

Maturity Questionnaire Analysis

Tabla 1. Resumen de respuestas al cuestionario de madurez del CMM de una organización.

(5)

La Tabla 2 resume los resultados de evaluar las actividades del KPA planificación de proyectos desde el punto de vista del enfoque, la implementación y los resultados obtenidos, según la metodología de Daskalantonakis [3]. La cuarta columna es el promedio de estas tres. Mediante esta tabla se determina el valor del KPA.

Evaluación CMM, Nivel 2 KPA1: Planificación de Proyectos

Lista de Actividades Clave Enfoque Implementación Resultados Promedio

1 El equipo de desarrollo de software participa en la elaboración y actualización del plan del proyecto

6 6 8 6

2 La planificación del proyecto es iniciada en las primeras etapas del mismo

6 6 8 6

3 Compromisos adquiridos con entes externos a la organización son revisados por la gerencia de acuerdo a un procedimiento documentado

4 0 2 2

4 Un ciclo de vida de desarrollo con fases de tamaño adecuado es definido

6 6 6 6

5 El plan de desarrollo del proyecto es elaborado de acuerdo a un procedimiento documentado

6 4 6 5

6 El plan de desarrollo del proyecto es documentado 6 6 8 6

7 Las herramientas necesarias para administrar el proyecto

de software son identificadas 4 2 4 3

8 Las estimaciones del tamaño de los productos de software son derivadas de acuerdo con un procedimiento

documentado

4 2 4 3

9 Las estimaciones del esfuerzo y costo del proyecto son derivadas de acuerdo con un procedimiento documentado

4 2 4 3

10 Las estimaciones de necesidades de recursos computacionales son derivadas de acuerdo con un procedimiento documentado

4 2 4 3

11 El cronograma del proyecto es derivado de acuerdo a un procedimiento documentado

2 0 2 1

12 Los riesgos del proyecto asociados con el costo, recursos, cronograma, y otros aspectos técnicos son identificados, evaluados, y documentados

4 2 4 3

13 Planes para obtener las herramientas y equipo necesarios

son preparados 4 4 4 4

14 Datos sobre la planificación del proyecto son guardados 6 6 6 6 Tabla 2. Evaluación de las actividades del KPA planificación de proyectos de una organización.

La Figura 2 muestra un ejemplo de uno de estos gráficos resultado de hacer la evaluación CMM de nivel en una organización. El gráfico muestra el perfil de los 6 KPA´s de nivel 2 que se evaluaron en esa organización. El gráfico demuestra que el área más débil es la administración de la calidad del software, mientras que la más alta es la planificación de proyectos, aún cuando sólo obtuvo un 3 de 10.

(6)

0 1 2

Planificación de proyectos

3

Control y seguimiento de proyectos

Administración de requerimientos

Aseguramiento de la calidad del software

Adminsitración de sub- contratistas Administración de la configuración del software

Figura 2. Perfil KPA resultado de hacer la evaluación CMM en una organización

4.2 Proyecto práctico II

Objetivo:

Aplicar los conocimientos adquiridos en la aplicación del estándar ISO 15504.

Objetivo específico:

Utilizar el modelo de referencia del ISO 15504 para llevar a cabo una evaluación parcial del proceso de desarrollo de software de una organización.

Metodología:

El trabajo consiste en llevar acabo una evaluación ISO 15504 de algunos de los procesos de desarrollo de software de una organización utilizando el mecanismo de evaluación visto en clase.

La evaluación debe contemplar únicamente los siguientes 5 procesos (y sus subprocesos) del ISO 15504:

CUS.3 Levantamiento de requerimientos.

ENG.1 Desarrollo

ENG.1.1 Análisis y diseño de sistemas

ENG.1.2 Análisis de requerimientos del software ENG.1.3 Diseño del software

ENG.1.4 Construcción del software ENG.1.5 Integración del software ENG.1.6 Pruebas del software

ENG.1.7 Integración y prueba de sistemas SUP.1 Documentación

MAN.2 Administración de proyectos ORG.5 Medición

Si se considera necesario, la evaluación se puede circunscribir a una división o departamento de la organización, o a algún tipo de sistemas de software en vez de toda la empresa.

El trabajo se hará en grupos de 3 o 4 personas y debe ser entregado en la fecha indicada en el calendario del curso PF-3319.

(7)

Entrega:

Se debe entregar la documento resumen con los resultados de la evaluación y los gráficos de barras con el perfil de procesos. Para cada proceso evaluado, se debe incluir una tabla con el perfil de los atributos.

La Figura 3 muestra un ejemplo de uno de estos gráficos resultado de hacer la evaluación. El gráfico muestra el perfil de los 11 procesos de software que se evaluaron en esa organización. Todos los procesos obtuvieron un ranking de cero, excepto Administración de proyectos que obtuvo un ranking de uno (esto en escala de 0 a 5). Esto refleja gráficamente el estado crítico en el que está esta organización con respecto a las mejores prácticas que componen estos once procesos evaluados.

0 1

Niveles

Perfil de Procesos

CUS.3 Levantamiento de Requerimientos ENG.1.1 Análisis y Diseño de Sistemas ENG.1.2 Análisis de Requerimientos del Software ENG.1.3 Diseño del Software ENG.1.4 Construcción del Software ENG.1.5 Integración del Software

ENG.1.6 Pruebas del Software ENG.1.7 Integración y Pruebas del Software

SUP.1 Documentación MAN.2 Administración de Proyectos

ORG.5 Medición

Figura 3. Perfil de procesos de una evaluación ISO 15504 de 11 procesos en una organización.

5. Conclusiones

El curso PF-3319 Estándares de Calidad para Desarrollo de Software se ha impartido cinco veces desde 1997 a un total de 100 estudiantes de posgrado. En general, estamos satisfechos con los resultados obtenidos a la fecha.

Nuestros estudiantes aprenden a implementar estándares de calidad en sus organizaciones de sistemas de información mediante un enfoque muy práctico.

Para un semestre de 64 horas lectivas, el esfuerzo total que el estudiante debe invertir durante las 16 semanas debe ser de unas 192 horas, incluyendo las horas lectivas. Cada uno de los dos trabajos prácticos está planificado para requerir aproximadamente unas 30-40 horas de trabajo por parte de cada estudiante, por lo que esperaríamos que cada estudiante invierta unas 60-80 horas de trabajo en el transcurso del semestre en hacer estas prácticas. Es decir, el estudiante invierte el 47% de su esfuerzo en los trabajos prácticos, el 33% en asistir a lecciones y hacer los quices, y el restante 20% en trabajo individual de lectura del material bibliográfico.

De esta manera, casi la mitad del esfuerzo del curso está destinado a la práctica. Los trabajos prácticos son un componente esencial de curso pues no sólo ayudan al estudiante a comprender la teoría vista en clase, sino que dado que los estudiantes pueden hacer estos trabajos prácticos en sus propias empresas, éstas obtienen un productos con un valor agregado que posteriormente pueden utilizar para mejorar sus procesos internos.

Nuestra experiencia a lo largo de 4 años demuestra que el programa del curso debe estarse renovando continuamente debido a los cambios permanentes que sufren los estándares.

(8)

6. Referencias

[1] J. Cooper et al. Software Acquisition Capability/Maturity Model (SA-CMM) Version 1.02., SEI-CMU.

[2] B. Curtis et al..Overview of the People Capability/Maturity Model. SEI-CMU.

[3] M. Daskalantonakis. Achieving Higher SEI Levels. IEEE Software July 1994, pags. 17-24.

[4] IEEE. IEEE Standards Collection: Software Engineering, 1999 edition. IEEE Inc. 1999.

[5] ISO. International Standard ISO 9001. ISO 2000.

[6] ISO. Information Technology - Software Product Evaluation - Quality Characteristics and Guidelines for their use. ISO 1991.

[7] ISO. ISO/IEC TR 15504-1:1998. ISO 1998.

[8] M. Jenkins. Adopting Development Standards to Achieve Process Improvement. Proceedings Sixth International Conference on Software Quality, Montreal, Canada, 1996, pags. 111-120.

[9] M. Jenkins. CMM vs ISO9001. Memorias III Congreso de Informática y Computación, San José, Costa Rica, 1995, pags. 43-49.

[10] G.A. Kaplan. Secrets of Software Quality. Proceedings Fifth International Conference on Software Quality, Austin, Texas, 1995, pags. 15-27.

[11] S.H. Kan. Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995.

[12] E. McGuire. Software Process Improvement: Concepts and Practices. Idea Group Publishing, 1999.

[13] J.W. Moore. Software Engineering Standards: A User´s Road Map. IEEE Inc., 2000.

[14] M. Paulk, B. Curtis, M.B. Chrissis, C.V. Weber. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, 1995.

[15] S. Lawrence Pfleeger, N. Fenton, S. Page. Evaluating Software Engineering Standards. IEEE Computer.

Sept. 1994, pags. 71-79.

[16] Roger S. Pressman. Ingeniería del Software: Un Enfoque Práctico, 5ta edición, McGraw-Hill, 2001.

[17] N.F. Schneidewind, N. Fenton. Do Standards Improve Quality? IEEE Software. Jan. 1996, pags. 22-24.

[18] Schulmeyer G.G., McManus J.I. Handbook of Software Quality Assurance. Prentice Hall, 1999.

[19] J. Cooper et al. Software Acquisition Capability/Maturity Model (SA-CMM) Version 1.02., SEI-CMU.

[20] D. Zubrow et al . CMU/SEI-94-SR-7 Maturity Questionnaire. SEI, 1994, pags. 1-42.

Referencias

Documento similar

Fuente de emisión secundaria que afecta a la estación: Combustión en sector residencial y comercial Distancia a la primera vía de tráfico: 3 metros (15 m de ancho)..

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

que hasta que llegue el tiempo en que su regia planta ; | pise el hispano suelo... que hasta que el

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

Entre nosotros anda un escritor de cosas de filología, paisano de Costa, que no deja de tener ingenio y garbo; pero cuyas obras tienen de todo menos de ciencia, y aun

E Clamades andaua sienpre sobre el caua- 11o de madera, y en poco tienpo fue tan lexos, que el no sabia en donde estaña; pero el tomo muy gran esfuergo en si, y pensó yendo assi

Por lo tanto, en base a su perfil de eficacia y seguridad, ofatumumab debe considerarse una alternativa de tratamiento para pacientes con EMRR o EMSP con enfermedad activa

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de