Estándares de Calidad para el Desarrollo y Mantenimiento de Software Dr. Marcelo Jenkins C. Escuela de Computación n e Informática Universidad de Costa Rica San Pedro, Costa Rica Tel: : (506) 207-4020 Fax: (506) 234-8846 mjenkins@cariari.ucr.ac.cr Calidad 1
Aseguramiento de la Calidad del Software (SQA) 2
Características del Software q La complejidad es difícil de estimar q La calidad es difícil de medir q El proceso de desarrollo es muy dependiente de factores humanos l Difícil de controlar l Está expuesto a altos riesgos Exactus 3.0 q El mantenimiento es costoso 3
Importancia del Software [Jenkins 95] La ventaja competitiva de cualquier empresa en tecnología a de información n radica en el software y el peopleware que posea, y no en el hardware que adquiera. Peopleware Software Hardware 4
Costo del Software vrs.. Hardware F u n c i o n a l i d a d Hardware Software C o s t o 1960 1970 1980 1990 2000 5
Costo de Corregir Defectos [Boehm 81] 100 90 80 70 60 50 40 30 20 10 0 1 2 3 Análisis Desarrollo Mantenimiento 6
Proceso de Desarrollo de Software Conjunto de pasos que se utilizan para desarrollar o mantener software. ltareas lprocedimientos ldocumentos lreportes lestándares lmétodos lherramientas Prueba Análisis Programación Diseño 7
Aseguramiento de la Calidad del Software (SQA) Conjunto sistemático tico de procedimientos, herramientas y métodos m necesarios para asegurar la calidad del software. Métodos SQA Procedimientos Herramientas 8
Plan de Calidad del Software Conjunto planificado y sistemático tico de acciones necesarias para proveer la confianza de que un producto cumple con los requerimientos técnicos t establecidos Estándar IEEE 610.12-1990 1990 IEEE Software Engineering Standards IEEE Inc., 1994 9
Calidad del Software q Concordancia con los requerimientos funcionales y de rendimiento. Exactus 3.0 q Cumplimiento con los estándares de desarrollo. q Cumplimiento con otras características implícitas. Requerimientos Estándares Otros 10
Factores de Calidad 11 Facilidad de mantenimiento Flexibilidad Facilidad de prueba Adaptación ModificaciónAdaptación Modificación Operación Correctitud Confiabilidad Eficiencia Integridad Facilidad de uso Portabilidad Reusabilidad Interoperabilidad
Herramientas Modernas Herramientas Desarrollo CASE Orientado a Objetos Reingeniería de procesos Administración del riesgo JAD, RAD, PD Lenguajes de 4ta generacíó íón Contratación externa Métodos formales? Inspecciones Métricas Reusabilidad Ingeniería a de la información Estándares 12
Estándar de Ingeniería a de Software Regla o base de comparación n que se utiliza para medir algún n aspecto del software. l Calidad l Productividad l Duración l Esfuerzo l Costo Estándar XYZ 13
Por qué Utilizar Estándares? q Son indispensables cuando muchas personas, productos y herramientas deben coexistir. l Promueven el buen uso de métodos m y herramientas. l Permiten la comunicación n entre los desarrolladores. 14 q Facilitan el mantenimiento del software. q Facilitan la capacitación n del personal. q Proveen una base para evaluar los diferentes productos de software. q Permiten definir el proceso de software de una organización. n.
Objetivo de los Estándares Usuario SQA Ingeniero de Software Estándare s Nivel de calidad 15
Utilización n de Estándares CMM Estándares de Software Proceso de mejoramiento de la calidad ISO 9001 SPICE 16
Referencias: SQA 17 q Schulmeyer G.G., McManus J.I. Handbook of Software Quality Assurance. Prentice Hall, 1999. q Roger S. Pressman. Ingeniería a de Software: Un Enfoque Aplicado. 4ta edición, McGraw Hill, 1998. q S. Lawrence Pfleeger,, N. Fenton,, S. Page. Evaluating Software Engineering Standards. IEEE Computer, Sept. 1994, pags.. 71-79. 79. q N.F. Schneidewind,, N. Fenton.. Do Standards Improve Quality? IEEE Software, Jan.. 1996, pags.. 22-24. 24. q J. Sanders and E. Curran. Software Quality: : A Framework for Success in Software Development and Support. Addison-Wesley,, 1994.
Estándares de Ingeniería de Software de la IEEE I E E E 18
Estándares de la IEEE Conjunto de 22 estándares l 15 estándares del proceso l 5 estándares del producto l 1 glosario de términost l 1 taxonomía a (clasificación) 19 IEEE Standards Collections: : Software Engineering. IEEE Inc., 1999 edition. IEEE Standards Board 345 East 47th Street New York,, NY 10017 USA www.computer.org
Estándares del Producto Análisis Desarrollo Mantenimiento IEEE Std.. 830-1884 Especif.. de Requeri- mientos del Software IEEE Std.. 1016-1987 1987 Descripción n del Diseño o del Software IEEE Std.. 990-1987 Prácticas para el uso de ADA IEEE Std.. 1063-1987 1987 Documentación de Usuario 20
Estándares del Proceso: Calidad IEEE Std.. 730-1989 Planes de Calidad de Software IEEE Std.. 1298-1992 1992 Sistemas de SQA: Requerimientos IEEE Std.. 1074-1991 1991 Desarrollo de Ciclos de Vida IEEE Std.. 1058.1-1987 1987 Planes para Adminis- tración de Proyectos IEEE Std.. 1012-1997 1997 Verificación n y Validación IEEE Std.. 1028-1988 1988 Revisiones y Auditorías 21
Estándares del Proceso: MétricasM IEEE Std.. 998.1-1988 1988 Medidas para Software Confiable IEEE Std.. 998.2-1988 Guía a para Medidas de Software Confiable IEEE Std.. 1045-1992 1992 Métricas de Productividad IEEE Std.. 1061-1992 1992 Metodología a de Métricas de Calidad 22
Estándares del Proceso: Pruebas y Mantenimiento IEEE Std.. 1219-1992 1992 Mantenimiento del Software IEEE Std.. 828-1990 Planes de Configu- ración n del Software IEEE Std.. 1042-1987 1987 Guía a para Configu- ración n del Software IEEE Std.. 1008-1987 1987 Pruebas de Unidad del Software IEEE Std.. 829-1983 Documentación n de Pruebas 23
Estándares del Proceso: Otros IEEE Std.. 1002-1987 1987 Taxonomía a de Estándares IEEE Std.. 610.12-1990 1990 Glosario Estándar de Términos IEEE Std.. 1209-1992 1992 Evaluación n de Herramientas CASE 24
Revisiones y Auditorías 25
IEEE Std.. 1028-1988 1988 para Revisiones y Auditorías del Software q Define procedimientos para definir y llevar a cabo procesos de revisión n y auditoría del software. q Describe cinco tipos de revisiones y auditorías as que se pueden utilizar. q Incluye tanto al producto como al proceso de software. q No prescribe el uso de revisiones ni auditorías as particulares. 26
q Auditoría Definiciones l Evaluación n independiente (objetiva) de un producto o proceso de software. l Mide el cumplimiento de estándares, guías, especificaciones, y procedimientos. l Utiliza criterios objetivos de medida debidamente documentados. Formato y contenido del producto. Descripción n del proceso para producirlo. Cómo chequear el cumplimiento. 27
q Revisión Definiciones (cont.) l Evalúa a un producto o proceso de software. l Determina status actual contra el plan original. l Reporta resultados y recomendaciones. l Sigue un proceso formal. l Cuatro tipos de revisiones: Revisión n de administración Revisión n técnicat Inspección Caminata 28
Tipos de Revisiones Revisión Tipo Elemento Usuario Revisiones de administración Revisiones técnicas Semi-formal Proyecto Administración Semi-formal Producto Equipo de desarrollo Inspecciones Formal Producto o proceso Equipo de desarrollo Caminatas Informal Producto Equipo de desarrollo 29
q Objetivos Ejemplo: Auditorías l Verificar el cumplimiento de los productos y procesos con los estándares, guías, especificaciones y procedimientos establecidos q Descripción n general l Chequea el status del proyecto contra contratos, requerimientos, planes estándares, guías, especificaciones y procedimientos, para identificar problemas y recomendar soluciones. 30
Ejemplo: Auditorías (cont.) q Responsabilidades l Líder Planificar, convocar y documentar reuniones. Asegurar la disponibilidad de la información. n. l Revisores Prepararse para las reuniones de revisión. l Autores Hacer disponible el material. 31
q Entradas Ejemplo: Auditorías (cont.) l Objetivos específicos de la auditoría. l Contratos, requerimientos, planes estándares, guías, especificaciones y procedimientos. l Información n actualizada del software o proceso a ser auditado. q Criterios de entrada l El plan del proyecto incluye una auditoría l Alguna persona o entidad interna o externa con autoridad la solicitó. 32
q Procedimiento Ejemplo: Auditorías (cont.) l Planificar la auditoría Items a examinar Reportes a producir Criterios de evaluación Listas de chequeo para auditar Cronograma l Reunión n inicial con la unidad a auditar (opcional) l Preparación n del equipo de auditoría Material de evidencia Información n de la organización n a auditar 33
Ejemplo: Auditorías (cont.) q Procedimiento (cont.) l Examen de los ítems contra los criterios de evaluación Entrevistas Visitas Estudio de evidencias q Reportes l Reporte de auditoría a la entidad auditada l Revisión n del reporte l Conferencia para exponer el reporte final 34
Ejemplo: Auditorías (cont.) 35 q Criterios de salida l Se cumplieron todos los objetivos específicos. l El reporte de auditoría y el reporte de recomendaciones han sido entregados. q Salidas l Reporte de auditoría Hallazgos Recomendaciones (si aplica) Recomendaciones para más m auditorías. as. q Pista de auditoría l Reporte de auditoría
Referencias: Estándares de la IEEE 36 q IEEE Standards Collections: : Software Engineering. IEEE Inc., 1999 edition. q M. Jenkins. Adopting Development Standards to Achieve Process Improvement. Proceedings Sixth International Conference on Software Quality,, Montreal, Canada,, 1996, pags.. 111-120. 120. q E.M. Bennatan. On-Time, Within Budget Software Management Practices and Techniques. McGraw-Hill, 1992. q E. Yourdon. Structured Walkthroughs. 4th edition, Yourdon Press,, 1989. q http://www.computer.org
Caso Práctico: Exactus de Costa Rica 37
q 180 empleados La Empresa l 120 en Desarrollo l 30 en Soporte TécnicoT q Herramientas de desarrollo l Centura (4GL orientado a objetos) l Visual Basic l Visual C++ q 1 producto l EXACTUS q 200 Clientes en 15 países de latinoamérica 38
Objetivo de Exactus de Costa Rica Alcanzar certificación n Nivel 2 del CMM CMM Nivel 2 39
Implementación n del Proyecto de SQA 40 q La organización n inició un procesos de adaptación n y adopción n de los estándares de ingeniería a de software de la IEEE. q Se utilizaron como guías para definir estándares propios. l Análisis de requerimientos l Especificaciones de diseños l Programación l Pruebas l Mantenimiento l Administración n de la Configuración l Especificación n de modificaciones
Por qué los Estándares de la IEEE? q Están n bien documentados. q Son públicos. p q Están n actualizados. q Son periódicamente revisados. q Son muy específicos. q Son independientes uno del otro. I E E E 41
Ejemplo: Estándar para Pruebas del Software Convenciones de Programación Descripción Diseño del Software 1. Pruebas de Verificación Requerimientos del Software Ítems Prueba Revisados Reporte Fallas Ítems Prueba Verificados Descripción Diseño del Software Ítems Prueba Revisados 2. Pruebas de Validación Ingeniero Software Ítems Prueba Validados BD Pruebas Reporte Sumario Pruebas 3. Pruebas de Integración Reporte Defectos Integración Software Probado 42
El Proceso de Adaptación n de Estándares Identificar Áreas Problema Determinar Causas Identificar Soluciones Adaptar Soluciones Documentar Estándar Aprobar Estándar Capacitar Personal Revisar y Mejorar Estándar 43 Probar Estándar
Beneficios Obtenidos q Disminución n en la cantidad de re-trabajo. q Mejor calidad de los productos. q Mejor definición n del proceso de desarrollo. q Facilitan la capacitación n de nuevo personal. q Facilitan la comunicación n entre analistas. q Ha permitido un crecimiento ordenado del Departamento de Desarrollo. 44
Estándares por Definir q Control de subcontratistas. q Plan de inspecciones. q Plan de métricas m de calidad y productividad. 45
Consideraciones Finales 46
Estándares de la IEEE 47 q Constituyen una buena base para definir estándares propios a la medida de la organización. n. I E E E q Al igual que el CMM, se concentran principalmente en la definición n de procesos. q Algunos de los estándares requieren un proceso previo de adaptación n antes de poder ser adoptados en organizaciones pequeñas y medianas. q No existe una manera objetiva de medir el nivel de cumplimiento con los estándares
Gracias! 48