You are on page 1of 5

Adecuacin del estndar IEEE 730 a proyectos de desarrollo de software o a a nivel licenciatura y su implementacin en un sistema computacional de o apoyo a la enseanza n

Victor Zamudio-Herreraa , Geraldiny Mar n-Toledanoa , Jorge Cervantes-Ojedaa y a Mar del Carmen Gmez-Fuentes a o
a

Universidad Autnoma Metropolitana, Cuajimalpa o Departamento de Matemticas Aplicadas y Sistemas a Articios 40, Col. Hidalgo, Delegacin Alvaro Obregn, Mxico, D. F., C.P. 01120. o o e En este trabajo se describe una adecuacin del estndar IEEE 730 para ayudar en el proceso o a de enseanza/aprendizaje de los conceptos del aseguramiento de la calidad del software a nivel n licenciatura. Se presentan tambin los requerimientos del Sistema de Aseguramiento de Calidad del e Software (SACS), basados en esta adecuacin. En general, el SACS es un sistema que brinda al profesor o control y a los alumnos una gu sobre las actividades que deben llevarse a cabo para el aseguramiento a 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 revisin de documentos, control de o inspecciones, control de pruebas, control de conguraciones de software y registro de la aportacin o individual de cada uno de los participantes en los proyectos dados de alta. Se describe tambin el e impacto esperado tanto en la calidad de la educacin como del software producido. o Palabras clave: ingenier del software, aseguramiento de la calidad del software, administracin de a o proyectos.

1. INTRODUCCION El proceso de enseanza de la ingenier de n a software es largo. En ocasiones es dif hacer cil ver a los estudiantes la conveniencia de aplicar las tcnicas probadas de aseguramiento de la calidad e a los productos de software. Esta dicultad surge porque los proyectos desarrollados en un curso son por lo general de tamao pequeo y n n es dif que los alumnos aprecien las bondades cil de las metodolog en este tipo de proyectos, as ya que estn pensadas para proyectos de gran a tamao que involucran a muchas personas y n consecuentemente, requieren de mucho ms a tiempo que el asignado a un curso. Cuando el profesor adapta las tcnicas e estudiadas al proyecto que se desarrolla, segn u sus caracter sticas particulares, comnmente se u dejan de lado los proyectos de gran tamao, n para los cuales es importante entrenar a los estudiantes, ya que son los que presentan un mayor grado de dicultad y para los cuales se hacen ms necesarias las tcnicas de la ingenier a e a
mgomez@correo.cua.uam.mx

de software. Otra opcin es proponer proyectos o grandes en donde sea indispensable aplicar alguna metodolog robusta para el desarrollo del a software, pero se presenta otro problema: no hay tiempo suciente en un curso normal para completar la aplicacin prctica de los mtodos. o a e La contribucin de este trabajo es la o construccin de una herramienta que establece o un compromiso intermedio entre las dos posibilidades mencionadas. Esto hace posible que en proyectos pequeos se incluyan ms n a metodolog as ilustrativas de la ingenier a del software, en apoyo a la enseanza del n aseguramiento de la calidad y en general de la ingenier del software. a Otra contribucin del sistema es la posibilidad o de llevar a cabo un seguimiento, por parte del responsable de un proyecto, de las contribuciones individuales de cada participante. As el profesor , podr identicar desviaciones e intervenir de a 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 2. ANTECEDENTES El SACS es una de las pocas herramientas disponibles con esta orientacin. Hay varios o paquetes de software para administracin de o proyectos pero no para Aseguramiento de la Calidad del Software segn el estndar IEEE u a 730 [1]. Sabemos que en 1985, un sistema para el aseguramiento de la calidad del software fue desarrollado en Alemania [8]. Segn esta u publicacin, el sistema no fue bien acogido por los o desarrolladores de software, quizs por la falta de a cultura de calidad en esos aos. n En la metodolog de Proceso Unicado a Racional o RUP (Rational Unied Process) no se hace una mencin expl o cita del aseguramiento de la calidad del software aunque segn Karen u Ultrech [9] va impl cito en ella de manera abstracta. Una herramienta que rena el u aseguramiento de la calidad con un proceso de desarrollo de software bien denido signicar a una novedosa manera de ensear los conceptos n del aseguramiento de la calidad del software sobre los proyectos que normalmente desarrollan los alumnos. 3. METODOLOG IA Se consider como documento base el o estndar IEEE 730 (Standard for Software a Quality Assurance Plans) [1] para generar una herramienta que gu a los alumnos en e la creacin del plan de aseguramiento de la o calidad de su proyecto y sobre todo, a seguirlo y actualizarlo. Por lo tanto, las recomendaciones del estndar IEEE 730 se convierten en requisitos a del sistema adems de ser aplicados durante a su desarrollo. La unica adecuacin importante o que hay que mencionar es que no se exige la creacin de un plan de vericacin y validacin o o o como tal [4]. Basta, en esta adecuacin, con o tener un plan de pruebas (ver seccin 3.3). o La justicacin de esta adecuacin es que los o o 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 abarcar tambin cil e la parte de la documentacin de vericacin y o o validacin. Sin embargo, esta documentacin o o est relacionada con el plan de pruebas, el cual a s se exige y puede seguirse para esto el estndar a IEEE 829. Consideramos tambin que el estndar e a

V. Zamudio-Herrera et. al. IEEE 1012 [4] es demasiado grande como para el tamao de los proyectos que se pretenden llevar n a cabo con la ayuda del SACS. El desarrollo del SACS se est llevando a a cabo mediante cada una de las actividades que se ilustran en la gura 1, que corresponde al modelo de desarrollo de software incremental, tambin llamado por etapas [6], [7]. e Para describir los requerimientos del sistema hemos usado el estndar IEEE 830 con la plantilla A.3, a organizada por la clase de usuario. En el diseo n de interfaces se utiliz Dream Weaver R . El o documento de diseo de arquitectura del software n incluye diagramas de interacciones entre mdulos o y de secuencia de eventos adems del diagrama a entidad-relacin para el diseo de la base de o n datos. Se generaron documentos de pruebas en base al estndar IEEE 829 [3] incluyendo a las pruebas relacionadas con cada uno de los requerimientos y adems las pruebas que surgen a a partir de la documentacin de diseo. En la o n implementacin de los mdulos software se utiliz o o o una combinacin de los lenguajes HTML, PHP y o Java. Las inspecciones de software y el diseo n del control de inspecciones dentro del SACS se llevaron a cabo en base a la metodolog de Tom a Gilb y Dorothy Graham [5].

Concepto del Software


Versin

Correcciones

Anlisis de requisitos
Versin

Correcciones

Diseo de alto novel


Versin

Correcciones

Diseo detallado Entrega

Codificacin

Depuracin

Prueba

Figura 1. Modelo de entrega por etapas segn u McConell [6].

Adecuacin del Estndar IEEE 730 o a 3.1. Standard IEEE 730 El estndar IEEE 730 [1] es una recomendacin a o 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 anticipacin y por lo tanto, deben o ser estudiadas y razonadas sucientemente antes de iniciar el desarrollo. El equipo de desarrollo deber entonces ajustarse al plan y as mejorar a , continuamente los procesos de desarrollo en benecio del proyecto en curso y de los proyectos futuros. 3.2. Standard IEEE 830 El estndar IEEE 830 [2] establece las a normas y condiciones para producir un buen documento de Especicacin de Requerimientos o (SRS: Software Requirements Specication). Contiene ocho plantillas diferentes para denir los requerimientos segn la naturaleza del sistema, u las cuales contemplan: organizar el sistema por modo, por clase de usuario, por objetos, por rasgos, por est mulos o por jerarqu a funcional, existe tambin la posibilidad de tener e organizaciones mltiples. u 3.3. Standard IEEE 829 El estndar IEEE 829 [3] establece una a recomendacin de la documentacin que debe o o generarse antes y durante el proceso de pruebas del sistema. Los documentos son: plan de pruebas, diseo de prueba, caso de prueba, n procedimiento de prueba, reporte de transmisin o de mdulo, bitcora de pruebas, reporte de o a incidente de prueba, resumen de pruebas. 3.4. Los requerimientos generales del sistema Se requiere un sistema en el que sea forzoso producir y seguir un Plan de Aseguramiento de la Calidad del Software apegndose al estndar a a IEEE 730 [1] para cada proyecto que se haya dado de alta. Con la informacin incluida o en dicho plan deber controlarse la creacin, a o revisin, inspeccin, entrega y mantenimiento o o del resto de la documentacin involucrada en el o aseguramiento de la calidad que, para el caso de los estudiantes de Ingenier en Computacin, es a o toda la documentacin del proyecto. El sistema o

73 deber guiar a los usuarios para que sigan las a recomendaciones de los estndares IEEE 730 e a IEEE 829. En general se identican las siguientes reas dentro del sistema. a Alta de proyectos de desarrollo de software: permitida slo a profesores. o Seguimiento y revisin de documentos: o cuando un documento se encuentre en estado de revisin, podr ser revisado por o a los miembros de una lista de distribucin o asignada a ste. Cada observacin que e o se haga a un documento deber estar a documentada, para ello cada uno tendr a una seccin de comentarios. El estado del o documento ser administrado por el l a der del proyecto. Procedimiento de actualizacin o de documentos aceptados: los documentos en estado de aceptado podrn ser actualizados a slo mediante reportes de problema (o To Record) crendose una nueva versin del a o documento. Control de inspecciones: cada inspeccin o planeada en el SQAP deber contener una a serie de documentos m nimos los cuales sern controlados por el sistema. a Control de documentacin de pruebas: o basada en el estndar IEEE 829. a Control de conguraciones de software: generacin de diferentes productos software o o paquetes a partir de la agrupacin de o mdulos software reutilizables que pueden o provenir de cualquiera de los proyectos dados de alta en el sistema. Seguimiento y medicin de cumplimiento o de tareas por cada usuario, elaboracin de o reportes de trabajo y de tareas pendientes de cada usuario. Asignacin de tareas por o parte del l der de proyecto o por el profesor. 4. AVANCES Y RESULTADOS El desarrollo del SACS ha pasado por las etapas de planeacin, anlisis de requerimientos, diseo o a n de interfaces de usuario, diseo de pruebas y n diseo de sistema. Actualmente se encuentra en n la fase de implementacin, hacindose entregas o e

74 por etapas segn el plan de pruebas. u Se sigui un proceso de anlisis de requerimientos o a para elaborar la especicacin de requerimientos. o El documento de diseo de interfaces ha sido n revisado y aprobado. El diseo de la arquitectura n del software est terminado aunque tuvo que ser a recortado en un 20% aproximadamente debido a la falta de tiempo para contemplar todos los requisitos, sin embargo, permite el paso a la implementacin de la funcionalidad incluida o hasta ahora. La documentacin del diseo de o n las pruebas est terminada. Queda por hacer a la documentacin de la fase de pruebas. En o general se ha avanzado substancialmente en el proyecto producindose ya ms de 300 pginas e a a totales incluyendo unas 120 de documentacin y o el resto de cdigo. o Se han identicado algunas reas que presentan a dicultad para su implementacin, as como o otras que parecen ser de fcil implementacin a o como sigue. El procedimiento de control del estado de un documento en revisin as como o la inclusin de comentarios y su respectiva o distribucin a los miembros de su lista de o distribucin, resultan de fcil implementacin y o a o no se esperan retrasos. Este procedimiento es bsico y se usar como parte fundamental de a a otros procedimientos del sistema. El control de documentacin de inspecciones parece ser o tambin de fcil implementacin. e a o Los procedimientos ms complicados son a aquellos procedimientos diseados para controlar n y reportar el cumplimiento de tareas asignadas a cada miembro de un equipo de desarrollo (alumnos). El diseo de esta funcionalidad n involucra actualizaciones en tiempo real originadas por acciones de varios usuarios simultneamente y en una variedad de a situaciones. Tambin involucra consideraciones e de seguridad, adems del diseo de reportes a n individualizados y en grupo para la supervisin o del trabajo hecho. Aunque lo anterior representa un reto importante de desarrollo, es posible hacer una entrega de la funcionalidad restante sin afectar el diseo y obtener un sistema de mucha n utilidad. Actualmente ya se tiene un prototipo funcional con los primeros requerimientos de la especicacin del SACS. En la gura 2 se muestra o un diagrama de bloques del sistema completo.

V. Zamudio-Herrera et. al.

Figura 2. Diagrama a bloques de Qualiteam.

5. CONCLUSIONES FUTURO

TRABAJO

Un sistema como el SACS tiene mucho potencial, para incrementar la eciencia y ecacia de la educacin de la ingenier en computacin. o a o Su uso deber permitir el desarrollo de proyectos a de software de mucho mayor tamao, lo cual n es una gran ventaja en la enseanza mediante n el desarrollo de proyectos, conceptos abstractos de la ingenier del software y en particular a del aseguramiento de la calidad del software. Otra gran ventaja esperada del SACS es que permita que en un proyecto de software haya un mayor nmero de participantes involucrndose u a en un mismo proyecto a alumnos de diferentes niveles, sin perder el control del proyecto ni de la aportacin individual al mismo por parte de o los participantes. Esto permitir que, desde muy a temprano en sus estudios, los alumnos pudieran participar en proyectos grandes y aceptaran de una manera ms natural las metodolog de la a as ingenier del software. a En el futuro estaremos reportando cules han a sido las experiencias con los alumnos y profesores en cuanto a la aceptacin del sistema y cules han o a sido las direcciones en que ha sido modicado o desarrollado el sistema. Ser importante disear a n mtricas que indiquen claramente el porqu de e e dichas modicaciones y si stas han sido efectivas e o no y en qu medida. e BIBLIOGRAF IA 1. IEEE STD-730 Standard for Software Quality Assurance Plans. IEEE Computer Society;

Adecuacin del Estndar IEEE 730 o a 2002. 2. IEEE STD-830 Recommended Practice for Software Requirements Specications. IEEE Computer Society; 1998. 3. IEEE STD-829 Standard for Software Test Documentation. IEEE Computer Society; 1998. 4. IEEE STD-1012-2004 Standard for Software Verication and Validation. IEEE Computer Society; 2004. 5. T. Gilb y D. Graham. Software Inspection. 4ta edicin. Inglaterra: Adison-Wesley; 1998. o 6. S. McConnell. Rapid development. Estados Unidos: Microsoft Press; 1996. 7. S. L. Peeger. Software engineering: theory and practice. Estados Unidos: Prentice Hall; 1998. 8. H. M. Sneed y A. Merey. Automated Software Quality Assurance. IEEE Transactions on Software Engineering. 1985; 11 (9): 909-916. 9. K. Ulferts. Why isnt there a RUP workow for software quality assurance? http:// www.ibm.com/developerworks/rational/ library/jun05/ulferts/index.html

75

You might also like