Dr. Marcelo Jenkins C.
Escuela de Computación e Informática Universidad de Costa Rica
San Pedro, Costa Rica Tel: (506) 207-4020 Fax: (506) 234-8846
Dr. Marcelo
Dr. Marcelo Jenkins Jenkins C. C.
Escuela de Computaci
Escuela de Computacióón e Informn e Informááticatica Universidad de Costa Rica
Universidad de Costa Rica San Pedro, Costa Rica
San Pedro, Costa Rica TelTel: (506) 207: (506) 207--40204020
Fax: (506) 234
Fax: (506) 234--88468846
[email protected] [email protected]
Estándares de Calidad
para el Desarrollo y Mantenimiento de Software
Est Est á á ndares de Calidad ndares de Calidad
para el Desarrollo y Mantenimiento para el Desarrollo y Mantenimiento
de Software de Software
Ca lida d
Ca lida d
Aseguramiento de la Calidad del Software (SQA)
Aseguramiento de la Calidad Aseguramiento de la Calidad
del Software (SQA)
del Software (SQA)
Características del Software Caracter
Caracter í í sticas del Software 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
q
El mantenimiento es costoso
La complejidad es dif La complejidad es dif í í cil de estimar cil de estimar
La calidad es dif La calidad es dif ícil de medir í cil de medir
El proceso de desarrollo es muy El proceso de desarrollo es muy dependiente de factores humanos dependiente de factores humanos
ll DifDifíícil de controlarcil de controlar
ll EstEstáá expuesto a altos riesgosexpuesto a altos riesgos
El mantenimiento es costoso El mantenimiento es costoso
Exactus Exac3.0tus
3.0
Importancia del Software Importancia del Software Importancia del Software
“La ventaja competitiva de cualquier empresa en tecnología de
información radica en el software y el peopleware que posea, y no en el hardware que adquiera”.
“ “ La ventaja competitiva de cualquier La ventaja competitiva de cualquier empresa en tecnolog
empresa en tecnolog í í a de a de informaci
informaci ó ó n radica en el n radica en el software software y y el peopleware el peopleware que posea, y no en que posea, y no en
el hardware que adquiera el hardware que adquiera ” ” . .
[Jenkins 95]
Hardware Hardware Software Software Peopleware Peopleware
Costo del Software vrs. Hardware Costo del Software
Costo del Software vrs vrs . Hardware . Hardware
1980
1960 1970 1990 2000
F u n c i o n a l i d a d
C o s t o
Hardware Hardware
Software Software
1 2 3 0
10 20 30 40 50 60 70 80 90 100
1 2 3
Costo de Corregir Defectos Costo de Corregir Defectos Costo de Corregir Defectos
Análisis Desarrollo Mantenimiento
[Boehm 81]
Proceso de Desarrollo de Software Proceso de Desarrollo de Software Proceso de Desarrollo de Software
Conjunto de pasos que se utilizan para Conjunto de pasos que se utilizan para
desarrollar o mantener software.
desarrollar o mantener software.
ll
Tareas Tareas
ll
Procedimientos Procedimientos
ll
Documentos Documentos
ll
Reportes Reportes
ll
Est Est á á ndares ndares
ll
M M é é todos todos
ll
Herramientas Herramientas
Análisis Análisis
Diseño Diseño Progra-
mación Progra- mación Prueba
Prueba
Aseguramiento de la Calidad del Software (SQA)
Aseguramiento de la Calidad del Software Aseguramiento de la Calidad del Software
(SQA) (SQA)
Conjunto sistemático de procedimientos,
herramientas y métodos necesarios para asegurar la calidad del software.
Conjunto sistem
Conjunto sistem á á tico de tico de procedimientos,
procedimientos, herramientas y m
herramientas y m é é todos todos necesarios para asegurar necesarios para asegurar
la calidad del software.
la calidad del software.
MétodosMétodosProcedi- mientos Procedi- mientos
Herra- mientas
Herra- mientas
SQA SQA
Plan de Calidad del Software Plan de Calidad del Software Plan de Calidad del Software
“Conjunto planificado y sistemático de acciones necesarias para proveer la
confianza de que un producto cumple con los requerimientos técnicos establecidos”
“ “ Conjunto planificado y sistem Conjunto planificado y sistem á á tico de tico de acciones necesarias para proveer la acciones necesarias para proveer la
confianza de que un producto cumple con confianza de que un producto cumple con
los requerimientos t
los requerimientos t é é cnicos establecidos cnicos establecidos ” ”
EstEstáándar IEEE 610.12ndar IEEE 610.12--19901990 IEEE Software
IEEE Software EngineeringEngineering StandardsStandards IEEE Inc., 1994
IEEE Inc., 1994
Calidad del Software Calidad del Software Calidad del Software
q
Concordancia con los requerimientos
funcionales y de rendimiento.
q
Cumplimiento con los estándares de
desarrollo.
q
Cumplimiento con otras características
implícitas.
Concordancia con los Concordancia con los requerimientos
requerimientos funcionales y de funcionales y de
rendimiento.
rendimiento.
Cumplimiento con los Cumplimiento con los est est á á ndares de ndares de
desarrollo.
desarrollo.
Cumplimiento con otras Cumplimiento con otras caracter
caracter í í sticas sticas impl impl í í citas. citas.
Requeri- mientos Requeri-
mientos Están- dares Están-
dares OtrosOtros Exactus
Exac3.0tus 3.0
Factores de Calidad Factores de Calidad Factores de Calidad
Operación Operación Mo di fic ac ió n
Mo di fic ac ió n Ad ap ta
ció n Ad ap ta
ci Ad ap ta
ci ó ó n n
• Correctitud
• Confiabilidad
• Eficiencia
• Integridad
• Correctitud
• Confiabilidad
• Eficiencia
• Integridad
• Facilidad de mantenimiento
• Flexibilidad
• Facilidad de prueba
• Facilidad de mantenimiento
• Flexibilidad
• Facilidad de prueba
• Portabilidad
• Reusabilidad
• Interoperabilidad
• Portabilidad
• Reusabilidad
• Interoperabilidad
Herramientas Modernas Herramientas Modernas Herramientas Modernas
Desarrollo Desarrollo
Orientado a Objetos Orientado a Objetos
Herramientas Herramientas
CASECASE
JAD, RAD, PD JAD, RAD, PD
Lenguajes de Lenguajes de 4ta 4ta generacgeneracíóíónn
MMéétodostodos formales formales
Reusabilidad Reusabilidad Ingenier
Ingenieríía dea de la informaci la informacióónn
Estándares Est Est á á ndares ndares
Contrataci Contratacióónn
externa externa Reingenier
Reingenierííaa de procesos de procesos Administraci Administracióónn
del riesgo del riesgo
MMéétricastricas
? ?
InspeccionesInspeccionesEstándar de Ingeniería de Software Est Est á á ndar de Ingenier ndar de Ingenier í í a de Software a de Software
Regla o base de comparación que se utiliza para medir algún aspecto del software.
l Calidad
l Productividad
l Duración
l Esfuerzo
l Costo
Regla o base de comparaci
Regla o base de comparaci ó ó n que n que se utiliza para medir alg
se utiliza para medir alg ún aspecto ú n aspecto del software.
del software.
ll CalidadCalidad
ll ProductividadProductividad
l
l DuraciDuracióónn
ll EsfuerzoEsfuerzo
ll CostoCosto
EstEstáándarndar XYZXYZ
¿Por qué Utilizar Estándares?
¿ ¿ Por qu Por qu é é Utilizar Est Utilizar Est á á ndares? ndares?
q
Son indispensables cuando muchas personas, productos y herramientas deben coexistir.
l Promueven el buen uso de métodos y herramientas.
l Permiten la comunicación entre los desarrolladores.
q
Facilitan el mantenimiento del software.
q
Facilitan la capacitació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.
Son indispensables cuando muchas personas, Son indispensables cuando muchas personas, productos y herramientas deben coexistir.
productos y herramientas deben coexistir.
ll Promueven el buen uso de mPromueven el buen uso de méétodos y herramientas.todos y herramientas.
ll Permiten la comunicaciPermiten la comunicación entre los desarrolladores.ón entre los desarrolladores.
Facilitan el mantenimiento del software. Facilitan el mantenimiento del software.
Facilitan la capacitaci Facilitan la capacitaci ó ó n del personal. n del personal.
Proveen una base para evaluar los diferentes Proveen una base para evaluar los diferentes productos de software.
productos de software.
Permiten definir el proceso de software de una Permiten definir el proceso de software de una organizaci
organizaci ó ó n. n.
Objetivo de los Estándares Objetivo de los Est
Objetivo de los Est á á ndares ndares
Nivel de calidad Nivel de calidad
Ingeniero Ingeniero de Software de Software
SQASQA
Usuario Usuario
Estándare s
EstáEstándarendare ss
Utilización de Estándares Utilizaci
Utilizaci ó ó n de Est n de Est á á ndares ndares
CMM CMM
ISO 9001 ISO 9001 SPICE
SPICE
Estándares de Software Est Est á á ndares ndares de Software de Software
Proceso de mejoramiento
de la calidad
Proceso de
Proceso de
mejoramiento
mejoramiento
de la calidad
de la calidad
Referencias: SQA Referencias: SQA Referencias: SQA
q Schulmeyer G.G., McManus J.I. Handbook of Software Quality Assurance. Prentice Hall, 1999.
q Roger S. Pressman. Ingenierí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.
q N.F. Schneidewind, N. Fenton. Do Standards Improve Quality? IEEE Software, Jan. 1996, pags. 22-24.
q J. Sanders and E. Curran. Software Quality: A
Framework for Success in Software Development and
qq SchulmeyerSchulmeyer G.G., G.G., McManusMcManus J.I. J.I. HandbookHandbook ofof Software Software Quality
Quality AssuranceAssurance.. PrenticePrentice Hall, 1999. Hall, 1999.
qq RogerRoger S. S. PressmanPressman. . IngenierIngenieríía de Software: Un Enfoque a de Software: Un Enfoque Aplicado.
Aplicado. 4ta edici4ta edicióón, n, McGrawMcGraw Hill, 1998. Hill, 1998.
qq S. Lawrence PfleegerS. Lawrence Pfleeger, N. , N. FentonFenton, S. , S. PagePage. . EvaluatingEvaluating Software
Software EngineeringEngineering StandardsStandards. . IEEE IEEE ComputerComputer, , SeptSept. . 1994,
1994, pagspags. 71. 71--79.79.
qq N.F. SchneidewindN.F. Schneidewind, N. , N. FentonFenton. Do Standards. Do Standards ImproveImprove Quality
Quality? ? IEEE SoftwareIEEE Software, , JanJan. 1996, . 1996, pags. 22pags. 22--24.24.
qq J. J. SandersSanders andand E. Curran. E. Curran. Software Software QualityQuality: A : A Framework
Framework forfor SuccessSuccess in Software Developmentin Software Development andand
Estándares de Ingeniería de Software de la IEEE Est Est á á ndares de Ingenier ndares de Ingenier í í a a
de Software de la IEEE de Software de la IEEE
I E E E
I E E E
Estándares de la IEEE Est Est á á ndares de la IEEE 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érminos
l 1 taxonomía (clasificación)
IEEE Standards Collections: Software Engineering.
IEEE Inc., 1999 edition.
IEEE Standards Board 345 East 47th Street New York, NY 10017 USA
Conjunto de 22 est
Conjunto de 22 est á á ndares ndares
ll 15 est15 estáándares del procesondares del proceso
l
l 5 est5 estáándares del productondares del producto
ll 1 glosario de t1 glosario de téérminosrminos
ll 1 taxonomí1 taxonomía (clasificacia (clasificacióón)n)
IEEE
IEEE StandardsStandards CollectionsCollections: Software : Software EngineeringEngineering. . IEEE Inc., 1999
IEEE Inc., 1999 editionedition.. IEEE
IEEE StandardsStandards BoardBoard 345 East345 East 47th Street47th Street NewNew York, NY 10017York, NY 10017 USAUSA
Estándares del Producto Est Est á á ndares del Producto ndares del Producto
IEEE
IEEE StdStd. 830. 830--18841884 Especif
Especif. de . de Requeri-Requeri- mientos
mientos del Softwaredel Software
IEEE
IEEE StdStd. 1016. 1016-1987 -1987 Descripci
Descripcióón del n del DiseñDiseño del Softwareo del Software
An An á á lisis lisis Desarrollo Desarrollo Mantenimiento Mantenimiento
IEEE
IEEE StdStd. 990. 990--19871987 PrPráácticas para elcticas para el
uso de ADA uso de ADA
IEEE
IEEE StdStd. 1063. 1063-1987 -1987 Documentaci
Documentacióónn de Usuario de Usuario
Estándares del Proceso: Calidad Est Est á á ndares del Proceso: Calidad ndares del Proceso: Calidad
IEEE
IEEE StdStd. 730. 730--19891989 Planes de Calidad Planes de Calidad
de Software de Software
IEEE
IEEE StdStd. 1012. 1012--19971997 Verificaci
Verificacióón y n y Validaci
Validacióónn IEEE
IEEE StdStd. 1028. 1028-1988-1988 Revisiones y
Revisiones y Auditor
Auditorííasas IEEE
IEEE StdStd. 1074. 1074-1991-1991 Desarrollo de Desarrollo de Ciclos de Vida Ciclos de Vida IEEE
IEEE StdStd. 1298. 1298-1992-1992 Sistemas de SQA:
Sistemas de SQA:
Requerimientos Requerimientos
IEEE
IEEE StdStd. 1058.1. 1058.1--19871987 Planes para
Planes para AdminisAdminis-- traci
tracióónn de Proyectosde Proyectos
Estándares del Proceso: Métricas Est Est á á ndares del Proceso: M ndares del Proceso: M é é tricas tricas
IEEE
IEEE StdStd. 998.1. 998.1--19881988 Medidas para Medidas para Software Confiable Software Confiable
IEEE
IEEE StdStd. 1045. 1045--19921992 MéMétricas detricas de
Productividad Productividad IEEE
IEEE StdStd. 998.2. 998.2--19881988 GuíGuía para Medidas a para Medidas de Software Confiable de Software Confiable
IEEE
IEEE StdStd. 1061. 1061--19921992 Metodolog
Metodologíía dea de MéMétricas de Calidadtricas de Calidad
Estándares del Proceso: Pruebas y Mantenimiento
Est Est á á ndares del Proceso: Pruebas y ndares del Proceso: Pruebas y Mantenimiento
Mantenimiento
IEEE
IEEE StdStd. 1219. 1219-1992-1992 Mantenimiento del Mantenimiento del
Software Software
IEEE
IEEE StdStd. 828. 828--19901990 Planes de
Planes de ConfiguConfigu-- racióración del Softwaren del Software IEEE
IEEE StdStd. 1042. 1042-1987-1987 GuíGuía para a para ConfiguConfigu-- racióración del Softwaren del Software
IEEE
IEEE StdStd. 1008. 1008--19871987 Pruebas de Unidad Pruebas de Unidad
del Software del Software IEEE
IEEE StdStd. 829. 829--19831983 Documentaci
Documentacióón den de Pruebas
Pruebas
Estándares del Proceso: Otros Est Est á á ndares del Proceso: Otros ndares del Proceso: Otros
IEEE
IEEE StdStd. 1002. 1002-1987-1987 Taxonom
Taxonomíía de a de EstEstáándaresndares
IEEE Std. 610.12-1990 Glosario Estándar
de Términos IEEE
IEEE StdStd. 610.12. 610.12-1990-1990 Glosario Est
Glosario Estáándarndar de Téde Términosrminos
IEEE
IEEE StdStd. 1209. 1209-1992-1992 Evaluaci
Evaluacióón de n de Herramientas CASE Herramientas CASE
Revisiones y Auditorías Revisiones y
Revisiones y Auditor Auditor í í as as
IEEE Std. 1028-1988 para
Revisiones y Auditorías del Software IEEE
IEEE Std Std . 1028 . 1028 - - 1988 para 1988 para Revisiones y
Revisiones y Auditor Auditor í í as as del Software del Software
q
Define procedimientos para definir y llevar a cabo procesos de revisión y auditoría del
software.
q
Describe cinco tipos de revisiones y auditorí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 particulares.
Define procedimientos para definir y llevar a Define procedimientos para definir y llevar a cabo procesos de revisi
cabo procesos de revisi ó ó n y n y auditor auditor í í a a del del software.
software.
Describe cinco tipos de revisiones y Describe cinco tipos de revisiones y auditor auditor í í as as que se pueden utilizar.
que se pueden utilizar.
Incluye tanto al producto como al proceso de Incluye tanto al producto como al proceso de software.
software.
No prescribe el uso de revisiones ni No prescribe el uso de revisiones ni auditor auditor í í as as particulares.
particulares.
Definiciones Definiciones Definiciones
q
Auditoría
l Evaluació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 del proceso para producirlo.
– Cómo chequear el cumplimiento.
Auditor Auditor í í a a
l
l EvaluaciEvaluacióón independiente (objetiva) de un producto n independiente (objetiva) de un producto o proceso de software.
o proceso de software.
ll Mide el cumplimiento de estMide el cumplimiento de estáándares, gundares, guíías, as, especificaciones, y procedimientos.
especificaciones, y procedimientos.
ll Utiliza criterios objetivos de medida debidamente Utiliza criterios objetivos de medida debidamente documentados.
documentados.
–– Formato y contenido del producto.Formato y contenido del producto.
–– DescripciDescripcióón del proceso para producirlo.n del proceso para producirlo.
–– CCóómo chequear el cumplimiento. mo chequear el cumplimiento.
Definiciones (cont.) Definiciones (cont.) Definiciones (cont.)
q
Revisión
l Evalú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 de administración
– Revisión técnica
– Inspección
– Caminata
Revisi Revisi ó ó n n
l
l EvalEvalúúa un producto o proceso de software.a un producto o proceso de software.
ll Determina status actual contra el plan original.Determina status actual contra el plan original.
ll Reporta resultados y recomendaciones.Reporta resultados y recomendaciones.
ll Sigue un proceso formal.Sigue un proceso formal.
l
l Cuatro tipos de revisiones:Cuatro tipos de revisiones:
–– RevisiRevisión de administración de administracióónn
–– RevisiRevisióón tn téécnicacnica
–– InspecciInspeccióónn
–– CaminataCaminata
Tipos de Revisiones Tipos de Revisiones Tipos de Revisiones
Revisión Tipo Elemento Usuario
Revisiones de
administración Semi-formal Proyecto Administración Revisiones
técnicas Semi-formal Producto Equipo de desarrollo Inspecciones Formal Producto o
proceso Equipo de desarrollo Caminatas Informal Producto Equipo de desarrollo
Revisión Tipo Elemento Usuario
Revisiones de
administración Semi-formal Proyecto Administración Revisiones
técnicas Semi-formal Producto Equipo de desarrollo Inspecciones Formal Producto o
proceso Equipo de
desarrollo
Caminatas Informal Producto Equipo de
desarrollo
Ejemplo: Auditorías Ejemplo:
Ejemplo: Auditor Auditor í í as as
q
Objetivos
l Verificar el cumplimiento de los productos y procesos con los estándares, guías,
especificaciones y procedimientos establecidos
q
Descripció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.
Objetivos Objetivos
l
l Verificar el cumplimiento de los productos y Verificar el cumplimiento de los productos y procesos con los est
procesos con los estáándares, gundares, guíías, as,
especificaciones y procedimientos establecidos especificaciones y procedimientos establecidos
Descripci Descripci ó ó n general n general
ll Chequea el status del proyecto contra contratos, Chequea el status del proyecto contra contratos, requerimientos, planes est
requerimientos, planes estáándares, gundares, guíías, as,
especificaciones y procedimientos, para identificar especificaciones y procedimientos, para identificar
problemas y recomendar soluciones.
problemas y recomendar soluciones.
Ejemplo: Auditorías (cont.) Ejemplo:
Ejemplo: Auditor Auditor í í as as (cont.) (cont.)
q
Responsabilidades
l Líder
– Planificar, convocar y documentar reuniones.
– Asegurar la disponibilidad de la información.
l Revisores
– Prepararse para las reuniones de revisión.
l Autores
– Hacer disponible el material.
Responsabilidades Responsabilidades
l
l LLííderder
–– Planificar, convocar y documentar reuniones.Planificar, convocar y documentar reuniones.
–– Asegurar la disponibilidad de la informaciAsegurar la disponibilidad de la informacióón.n.
ll RevisoresRevisores
–– Prepararse para las reuniones de revisiPrepararse para las reuniones de revisión.ón.
ll AutoresAutores
–– Hacer disponible el material.Hacer disponible el material.
Ejemplo: Auditorías (cont.) Ejemplo:
Ejemplo: Auditor Auditor í í as as (cont.) (cont.)
q
Entradas
l Objetivos específicos de la auditoría.
l Contratos, requerimientos, planes estándares, guías, especificaciones y procedimientos.
l Informació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ó.
Entradas Entradas
l
l Objetivos especObjetivos especííficos de la ficos de la auditorauditorííaa..
ll Contratos, requerimientos, planes estContratos, requerimientos, planes estáándares, gundares, guíías, as, especificaciones y procedimientos.
especificaciones y procedimientos.
ll InformaciInformacióón actualizada del software o proceso a ser n actualizada del software o proceso a ser auditado.
auditado.
Criterios de entrada Criterios de entrada
ll El plan del proyecto incluye una auditorEl plan del proyecto incluye una auditorííaa
l
l Alguna persona o entidad interna o externa con Alguna persona o entidad interna o externa con autoridad la solicit
autoridad la solicitóó..
Ejemplo: Auditorías (cont.) Ejemplo:
Ejemplo: Auditor Auditor í í as as (cont.) (cont.)
q
Procedimiento
l Planificar la auditoría
– Items a examinar
– Reportes a producir
– Criterios de evaluación
– Listas de chequeo para auditar
– Cronograma
l Reunión inicial con la unidad a auditar (opcional)
l Preparación del equipo de auditoría
– Material de evidencia
– Información de la organización a auditar
Procedimiento Procedimiento
l
l Planificar la Planificar la auditorauditorííaa
–– ItemsItems a examinara examinar
–– Reportes a producirReportes a producir
–– Criterios de evaluaciCriterios de evaluaciónón
–– Listas de chequeo para auditarListas de chequeo para auditar
–– CronogramaCronograma
l
l ReuniReunióón inicial con la unidad a auditar (opcional)n inicial con la unidad a auditar (opcional)
ll PreparaciPreparacióón del equipo de n del equipo de auditorauditorííaa
–– Material de evidenciaMaterial de evidencia
–– InformaciInformacióón de la organizacin de la organizacióón a auditarn a auditar
Ejemplo: Auditorías (cont.) Ejemplo:
Ejemplo: Auditor Auditor í í as as (cont.) (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 del reporte
l Conferencia para exponer el reporte final
Procedimiento (cont.) Procedimiento (cont.)
ll Examen de los íExamen de los ítems contra los criterios de tems contra los criterios de evaluaci
evaluacióónn
–– EntrevistasEntrevistas
–– VisitasVisitas
–– Estudio de evidenciasEstudio de evidencias
Reportes Reportes
ll Reporte de Reporte de auditorauditoríaía a la entidad auditadaa la entidad auditada
l
l RevisiRevisióón del reporten del reporte
ll Conferencia para exponer el reporte finalConferencia para exponer el reporte final
Ejemplo: Auditorías (cont.) Ejemplo:
Ejemplo: Auditor Auditor í í as as (cont.) (cont.)
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 auditorías.
q
Pista de auditoría
Criterios de salida Criterios de salida
ll Se cumplieron todos los objetivos especSe cumplieron todos los objetivos específicos.íficos.
l
l El reporte de El reporte de auditorauditorííaa y el reporte de y el reporte de recomendaciones han sido entregados.
recomendaciones han sido entregados.
Salidas Salidas
ll Reporte de Reporte de auditorauditorííaa
–– HallazgosHallazgos
–– Recomendaciones (si aplica)Recomendaciones (si aplica)
–– Recomendaciones para mRecomendaciones para máás s auditorauditorííasas..
Pista de Pista de auditor auditor ía í a
Referencias: Estándares de la IEEE Referencias: Est
Referencias: Est á á ndares de la IEEE ndares de la IEEE
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.
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
qq IEEE IEEE StandardsStandards CollectionsCollections: Software : Software EngineeringEngineering. . IEEE Inc., 1999
IEEE Inc., 1999 editionedition..
qq M. M. JenkinsJenkins. . AdoptingAdopting DevelopmentDevelopment StandardsStandards toto Achieve
Achieve ProcessProcess ImprovementImprovement. . ProceedingsProceedings SixthSixth International
International ConferenceConference onon Software Software QualityQuality, Montreal, , Montreal, Canada
Canada, 1996, , 1996, pagspags. 111. 111--120.120.
qq E.M. E.M. BennatanBennatan. . OnOn--Time, Time, WithinWithin BudgetBudget Software Software Management
Management PracticesPractices andand TechniquesTechniques.. McGrawMcGraw--Hill, Hill, 1992.
1992.
qq E. E. YourdonYourdon. . StructuredStructured WalkthroughsWalkthroughs.. 4th 4th editionedition, , Yourdon
Yourdon PressPress, 1989., 1989.
qq http://www.computer.orghttp://www.computer.org
Caso Práctico:
Exactus de Costa Rica Caso Pr
Caso Pr á á ctico: ctico:
Exactus
Exactus de Costa Rica de Costa Rica
La Empresa La Empresa La Empresa
q
180 empleados
l 120 en Desarrollo
l 30 en Soporte Técnico
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
180 empleados 180 empleados
ll 120 en Desarrollo120 en Desarrollo
l
l 30 en Soporte T30 en Soporte Téécnicocnico
Herramientas de desarrollo Herramientas de desarrollo
ll CenturaCentura (4GL orientado a objetos)(4GL orientado a objetos)
ll Visual BasicVisual Basic
ll Visual C++Visual C++
1 producto 1 producto
ll EXACTUSEXACTUS
200 Clientes en 15 pa 200 Clientes en 15 pa í í ses de ses de latinoam latinoam é é rica rica
Objetivo de Exactus de Costa Rica Objetivo de
Objetivo de Exactus Exactus de Costa Rica de Costa Rica
Alcanzar certificación Nivel 2 del CMM Alcanzar certificaci
Alcanzar certificaci ó ó n Nivel 2 del CMM n Nivel 2 del CMM
CMM CMM
Nivel 2
Nivel 2
Implementación del Proyecto de SQA Implementaci
Implementaci ó ó n del Proyecto de SQA n del Proyecto de SQA
q
La organización inició un procesos de
adaptación y adopción de los estándares de ingenierí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 de la Configuración
l Especificación de modificaciones
La organizaci La organizaci ó ó n inici n inici ó ó un procesos de un procesos de adaptaci
adaptaci ón y adopci ó n y adopci ó ó n de los est n de los est á á ndares de ndares de ingenier
ingenier í í a de software de la IEEE. a de software de la IEEE.
Se utilizaron como gu Se utilizaron como gu í í as para definir as para definir est est á á ndares propios. ndares propios.
ll AnAnáálisis de requerimientoslisis de requerimientos
ll Especificaciones de diseEspecificaciones de diseññosos
ll ProgramaciProgramacióónn
ll PruebasPruebas
ll MantenimientoMantenimiento
l
l AdministraciAdministracióón de la Configuracin de la Configuracióónn
ll EspecificaciEspecificacióón de modificacionesn de modificaciones
¿Por qué los Estándares de la IEEE?
¿ ¿ Por qu Por qu é é los Est los Est á á ndares de la IEEE? ndares de la IEEE?
q
Están bien documentados.
q
Son públicos.
q
Están actualizados.
q
Son periódicamente revisados.
q
Son muy específicos.
q
Son independientes uno del otro.
Est Est á á n bien documentados. n bien documentados.
Son p Son p ú ú blicos. blicos.
Est Est á á n actualizados. n actualizados.
Son peri Son peri ó ó dicamente revisados. dicamente revisados.
Son muy espec Son muy espec í í ficos. ficos.
Son independientes uno del otro. Son independientes uno del otro.
I E E E I E E E I E E E
Ejemplo: Estándar para Pruebas del Software Ejemplo: Est
Ejemplo: Est á á ndar para Pruebas del Software ndar para Pruebas del Software
Pruebas de Verificación
1.
Pruebas de Validación
2.
Reporte Fallas Ítems Prueba Revisados
Requerimientos del Software
Reporte Sumario Pruebas Convenciones de
Programación
Descripción
Diseño del Software Ítems
Prueba Verificados
Ingeniero Software Descripción
Diseño del Software
Ítems Prueba Revisados
Pruebas de Integración
3.
Ítems Prueba Validados
Software Probado BD Pruebas
Reporte Defectos Integración
El Proceso de Adaptación de Estándares El Proceso de Adaptaci
El Proceso de Adaptaci ó ó n de Est n de Est á á ndares ndares
Identificar
Soluciones Adaptar Soluciones
Documen- Estándartar
Aprobar Estándar
Capacitar Personal
Probar
Revisar y Mejorar Estándar Determinar
Causas Identificar
Áreas Problema
Beneficios Obtenidos Beneficios Obtenidos Beneficios Obtenidos
q
Disminución en la cantidad de re-trabajo.
q
Mejor calidad de los productos.
q
Mejor definición del proceso de desarrollo.
q
Facilitan la capacitación de nuevo personal.
q
Facilitan la comunicación entre analistas.
q
Ha permitido un crecimiento ordenado del Departamento de Desarrollo.
Disminuci Disminuci ó ó n en la cantidad de re n en la cantidad de re - - trabajo. trabajo.
Mejor calidad de los productos. Mejor calidad de los productos.
Mejor definici Mejor definici ón del proceso de ó n del proceso de desarrollo.
desarrollo.
Facilitan la capacitaci Facilitan la capacitaci ó ó n de nuevo n de nuevo personal.
personal.
Facilitan la comunicaci Facilitan la comunicaci ón entre analistas. ó n entre analistas.
Ha permitido un crecimiento ordenado del Ha permitido un crecimiento ordenado del Departamento de Desarrollo.
Departamento de Desarrollo.
Estándares por Definir Est Est á á ndares por Definir ndares por Definir
q
Control de subcontratistas.
q
Plan de inspecciones.
q
Plan de métricas de calidad y productividad.
Control de subcontratistas. Control de subcontratistas.
Plan de inspecciones. Plan de inspecciones.
Plan de m Plan de m é é tricas de calidad y productividad. tricas de calidad y productividad.
Consideraciones Finales
Consideraciones Finales
Consideraciones Finales
Estándares de la IEEE Est Est á á ndares de la IEEE ndares de la IEEE
q
Constituyen una buena base para definir estándares propios a la medida de la
organización.
q
Al igual que el CMM, se concentran
principalmente en la definición de procesos.
q
Algunos de los estándares requieren un
proceso previo de adaptación antes de poder ser adoptados en organizaciones pequeñas y medianas.
q
No existe una manera objetiva de medir el nivel
Constituyen una buena base para definir Constituyen una buena base para definir está est á ndares propios a la medida de la ndares propios a la medida de la
organizaci
organizaci ó ó n. n.
Al igual que el CMM, se concentran Al igual que el CMM, se concentran principalmente en la definici
principalmente en la definici ó ó n de procesos. n de procesos.
Algunos de los est Algunos de los est á á ndares requieren un ndares requieren un proceso previo de adaptaci
proceso previo de adaptaci ó ó n antes de poder n antes de poder ser adoptados en organizaciones peque
ser adoptados en organizaciones peque ñ ñ as y as y medianas.
medianas.
No existe una manera objetiva de medir el nivel No existe una manera objetiva de medir el nivel
I E E E I E E E
