Adecuacion Del Estandar IEEE730

Adecuaci¶on del est¶andar IEEE 730 a proyectos de desarrollo de software

a nivel licenciatura y su implementaci¶on en un sistema computacional de

apoyo a la ense~nanza

Victor Zamudio-Herreraa, Geraldiny Mar¶³n-Toledanoa, Jorge Cervantes-Ojedaa y

Mar¶³a del Carmen G¶omez-Fuentesa¤

aUniversidad Aut¶onoma Metropolitana, Cuajimalpa

Departamento de Matem¶aticas Aplicadas y Sistemas

Arti¯cios 40, Col. Hidalgo, Delegaci¶on ¶ Alvaro Obreg¶on, M¶exico, D. F., C.P. 01120.

En este trabajo se describe una adecuaci¶on del est¶andar IEEE 730 para ayudar en el proceso

de ense~nanza/aprendizaje de los conceptos del aseguramiento de la calidad del software a nivel

licenciatura. Se presentan tambi¶en los requerimientos del Sistema de Aseguramiento de Calidad del

Software (SACS), basados en esta adecuaci¶on. En general, el SACS es un sistema que brinda al profesor

control y a los alumnos una gu¶³a sobre las actividades que deben llevarse a cabo para el aseguramiento

de la calidad durante el desarrollo de proyectos de software. El SACS incluye herramientas para:

dar de alta proyectos de desarrollo de software, seguimiento y revisi¶on de documentos, control de

inspecciones, control de pruebas, control de con¯guraciones de software y registro de la aportaci¶on

individual de cada uno de los participantes en los proyectos dados de alta. Se describe tambi¶en el

impacto esperado tanto en la calidad de la educaci¶on como del software producido.

Palabras clave: ingenier¶³a del software, aseguramiento de la calidad del software, administraci¶on de

proyectos.

1. INTRODUCCI¶ON

El proceso de ense~nanza de la ingenier¶³a de

software es largo. En ocasiones es dif¶³cil hacer

ver a los estudiantes la conveniencia de aplicar las

t¶ecnicas probadas de aseguramiento de la calidad

a los productos de software. Esta di¯cultad

surge porque los proyectos desarrollados en un

curso son por lo general de tama~no peque~no y

es dif¶³cil que los alumnos aprecien las bondades

de las metodolog¶³as en este tipo de proyectos,

ya que est¶an pensadas para proyectos de gran

tama~no que involucran a muchas personas y

consecuentemente, requieren de mucho m¶as

tiempo que el asignado a un curso.

Cuando el profesor adapta las t¶ecnicas

estudiadas al proyecto que se desarrolla, seg¶un

sus caracter¶³sticas particulares, com¶unmente se

dejan de lado los proyectos de gran tama~no,

para los cuales es importante entrenar a los

estudiantes, ya que son los que presentan un

mayor grado de di¯cultad y para los cuales se

hacen m¶as necesarias las t¶ecnicas de la ingenier¶³a

¤mgomez@correo.cua.uam.mx

de software. Otra opci¶on es proponer proyectos

grandes en donde sea indispensable aplicar

alguna metodolog¶³a robusta para el desarrollo del

software, pero se presenta otro problema: no

hay tiempo su¯ciente en un curso normal para

completar la aplicaci¶on pr¶actica de los m¶etodos.

La contribuci¶on de este trabajo es la

construcci¶on de una herramienta que establece

un compromiso intermedio entre las dos

posibilidades mencionadas. Esto hace posible

que en proyectos peque~nos se incluyan m¶as

metodolog¶³as ilustrativas de la ingenier¶³a

del software, en apoyo a la ense~nanza del

aseguramiento de la calidad y en general de

la ingenier¶³a del software.

Otra contribuci¶on del sistema es la posibilidad

de llevar a cabo un seguimiento, por parte del

responsable de un proyecto, de las contribuciones

individuales de cada participante. As¶³, el profesor

podr¶a identi¯car desviaciones e intervenir de

manera oportuna para orientar a los alumnos en

sus esfuerzos. Hemos llamado a este sistema:

Sistema de Aseguramiento de la Calidad del

Software (SACS).

71

72 V. Zamudio-Herrera et. al.

2. ANTECEDENTES

El SACS es una de las pocas herramientas

disponibles con esta orientaci¶on. Hay varios

paquetes de software para administraci¶on de

proyectos pero no para Aseguramiento de la

Calidad del Software seg¶un el est¶andar IEEE

730 [1]. Sabemos que en 1985, un sistema

para el aseguramiento de la calidad del software

fue desarrollado en Alemania [8]. Seg¶un esta

publicaci¶on, el sistema no fue bien acogido por los

desarrolladores de software, quiz¶as por la falta de

cultura de calidad en esos a~nos.

En la metodolog¶³a de Proceso Uni¯cado

Racional o RUP (Rational Uni¯ed Process) no

se hace una menci¶on expl¶³cita del aseguramiento

de la calidad del software aunque seg¶un Karen

Ultrech [9] va impl¶³cito en ella de manera

abstracta. Una herramienta que re¶una el

aseguramiento de la calidad con un proceso de

desarrollo de software bien de¯nido signi¯car¶a

una novedosa manera de ense~nar los conceptos

del aseguramiento de la calidad del software sobre

los proyectos que normalmente desarrollan los

alumnos.

3. METODOLOG¶IA

Se consider¶o como documento base el

est¶andar IEEE 730 (Standard for Software

Quality Assurance Plans) [1] para generar

una herramienta que gu¶³e a los alumnos en

la creaci¶on del plan de aseguramiento de la

calidad de su proyecto y sobre todo, a seguirlo y

actualizarlo. Por lo tanto, las recomendaciones

del est¶andar IEEE 730 se convierten en requisitos

del sistema adem¶as de ser aplicados durante

su desarrollo. La ¶unica adecuaci¶on importante

que hay que mencionar es que no se exige la

creaci¶on de un plan de veri¯caci¶on y validaci¶on

como tal [4]. Basta, en esta adecuaci¶on, con

tener un plan de pruebas (ver secci¶on 3:3).

La justi¯caci¶on de esta adecuaci¶on es que los

alumnos deben ir estudiando los conceptos de

calidad y pruebas durante el trimestre y al mismo

tiempo ir documentando su proyecto mediante el

sistema, lo cual les hace dif¶³cil abarcar tambi¶en

la parte de la documentaci¶on de veri¯caci¶on y

validaci¶on. Sin embargo, esta documentaci¶on

est¶a relacionada con el plan de pruebas, el cual

s¶³ se exige y puede seguirse para esto el est¶andar

IEEE 829. Consideramos tambi¶en que el est¶andar

IEEE 1012 [4] es demasiado grande como para el

tama~no de los proyectos que se pretenden llevar

a cabo con la ayuda del SACS.

El desarrollo del SACS se est¶a llevando a

cabo mediante cada una de las actividades que

se ilustran en la ¯gura 1, que corresponde al

modelo de desarrollo de software incremental,

tambi¶en llamado por etapas [6], [7]. Para

describir los requerimientos del sistema hemos

usado el est¶andar IEEE 830 con la plantilla A.3,

organizada por la clase de usuario. En el dise~no

de interfaces se utiliz¶o Dream Weaver R°. El

documento de dise~no de arquitectura del software

incluye diagramas de interacciones entre m¶odulos

y de secuencia de eventos adem¶as del diagrama

entidad-relaci¶on para el dise~no de la base de

datos. Se generaron documentos de pruebas

en base al est¶andar IEEE 829 [3] incluyendo

las pruebas relacionadas con cada uno de los

requerimientos y adem¶as las pruebas que surgen

a partir de la documentaci¶on de dise~no. En la

implementaci¶on de los m¶odulos software se utiliz¶o

una combinaci¶on de los lenguajes HTML, PHP y

Java. Las inspecciones de software y el dise~no

del control de inspecciones dentro del SACS se

llevaron a cabo en base a la metodolog¶³a de Tom

Gilb y Dorothy Graham [5].

Concepto del

Software

Versión

Correcciones

Análisis de

requisitos

Versión Diseño de

alto novel

Correcciones

Correcciones

Diseño

detallado

Versión

Codificación Entrega

Depuración Prueba

Figura 1. Modelo de entrega por etapas seg¶un

McConell [6].

Adecuaci¶on del Est¶andar IEEE 730 73

3.1. Standard IEEE 730

El est¶andar IEEE 730 [1] es una recomendaci¶on

para elaborar un Plan de Aseguramiento de la

Calidad del Software SQAP (Software Quality

Assurance Plan) para proyectos de desarrollo de

software. Cuando en un proyecto de desarrollo

de software se incluye un plan de estos, las

decisiones relacionadas con la calidad deben ser

tomadas con anticipaci¶on y por lo tanto, deben

ser estudiadas y razonadas su¯cientemente antes

de iniciar el desarrollo. El equipo de desarrollo

deber¶a entonces ajustarse al plan y as¶³, mejorar

continuamente los procesos de desarrollo en

bene¯cio del proyecto en curso y de los proyectos

futuros.

...