Universidad La Salle Maestría en Sistemas...

Maestría en Sistemas Computacionales Seminario de Auditoría Informática

Página 1 de 1 lunes, 02 de diciembre de 2002

ProyectoFinal.doc

Universidad La Salle Maestría en Sistemas Computacionales

Seminario de Auditoría Informática

Metodología para la auditoría en el desarrollo de sistemas.

Profesor: M. En C. Mario Farias-Elinos Alumna: América Méndez Arellano. Cuenta: 016115.


Página 2 de 2 lunes, 02 de diciembre de 2002 ProyectoFinal.doc

Metodología para la auditoría en el desarrollo de sistemas.

1 Introducción ..........................................................................................................................................................5 2 Auditoría Informática . .........................................................................................................................................5

2.1 Conceptos de Auditoría Informática........................................................................................................5 2.2 Técnicas Básicas y Clásicas de Auditoría.................................................................................................7

2.2.1 Cuestionarios. .........................................................................................................................................7 2.2.2 Auditar alrededor de la computadora.............................................................................................8 2.2.3 Auditoría a través de la computadora. ............................................................................................8 2.2.4 Tabla de Pruebas "Test Deck". .............................................................................................................9 2.2.5 Revisión de auditoría a programas de aplicación. ......................................................................10

2.3 La computadora herramienta de auditoria mediante el uso de programas . ..............................10 3 Auditoria de Software . ......................................................................................................................................11

3.1 Auditoría de Software.................................................................................................................................11 3.1.1 Roles y responsabilidades en la auditoria.......................................................................................11 3.1.2 Entrada para el proceso de auditoria.............................................................................................11 3.1.3 Necesidad de la auditoria.................................................................................................................11 3.1.4 Plan de auditoria debe establecer:.................................................................................................11

3.2 El proceso de Auditoría..............................................................................................................................12 3.2.1 Autorización. .........................................................................................................................................12 3.2.2 Reunión previa que provee información sobre: ...........................................................................12 3.2.3 Preparación de la auditoria. .............................................................................................................12 3.2.4 Reunión de apertura...........................................................................................................................12 3.2.5 Entrevistas y exámenes.......................................................................................................................12 3.2.6 Reunión final. ........................................................................................................................................12 3.2.7 Distribución del reporte. .....................................................................................................................13 3.2.8 Auditoria completa. ............................................................................................................................13

3.3 Tipos de Auditoría........................................................................................................................................13 3.3.1 Actividades QSA. .................................................................................................................................13

4 Revisiones de Software . ....................................................................................................................................14 4.1 Revisiones de Software...............................................................................................................................14

4.1.1 Responsabilidades en una revisión. .................................................................................................14 4.1.2 Roles y responsabilidades en la revisión..........................................................................................15 4.1.3 Entradas para el proceso de revisión. .............................................................................................15 4.1.4 Procedimiento de revisión. ................................................................................................................15

4.2 Revisiones de Requerimiento de Software.............................................................................................16 4.3 Revisiones de Diseño de Software. ..........................................................................................................16

5 Revisiones Especializadas “Peer Reviews”. ....................................................................................................17 5.1 Definición de una revisión entre pares (Peer Reviews)........................................................................17 5.2 Tipos de revisiones. ......................................................................................................................................17

5.2.1 Reuniones informales (pasillo). ..........................................................................................................17 5.2.2 Revisiones técnicas formales. ............................................................................................................17

5.3 Participantes en una revisión.. ..................................................................................................................18 5.4 Fases de una revisión entre pares............................................................................................................19

5.4.1 Pre-Observación (Información preliminar). ....................................................................................19 5.4.2 La Observación entre pares. .............................................................................................................19 5.4.3 Observación Posterior (Instrucciones). ............................................................................................19 5.4.4 Entrega de la documentación. ........................................................................................................19

5.5 Producto de trabajo. ..................................................................................................................................19 5.6 Listas de verificación y formas. .................................................................................................................19

5.6.1 Formas de recoger la información...................................................................................................19 5.6.2 Listas de verificación. ..........................................................................................................................20

5.7 Métricas de software. .................................................................................................................................21 5.7.1 Razones que Justifican la Medición del Software.........................................................................22



ProyectoFinal.doc

5.7.2 Clasificación de Métricas...................................................................................................................23 5.7.3 Consideraciones en la Etapa de Análisis........................................................................................23 5.7.4 Consideraciones en la Etapa de Desarrollo...................................................................................24

5.8 Laboratorio de inspección. .......................................................................................................................25 6 Estándares y modelos de calidad en la Ingeniería de Software. .............................................................26

6.1 La Normas ISO . ............................................................................................................................................26 6.1.1 La Normas ISO aplicables al Control en el Desarrollo de Software ..........................................27

6.2 Estándares de la IEEE. .................................................................................................................................31 6.2.1 Estándares de la IEEE aplicables al Control en el Desarrollo de Software . .............................31

6.3 El modelo Tickt IT..........................................................................................................................................34 6.3.1 Ciclo de vida del software.................................................................................................................34 6.3.2 Soporte y aseguramiento de calidad. ............................................................................................35

6.4 El modelo CMM. ..........................................................................................................................................35 6.4.1 Estructura del modelo.........................................................................................................................37 6.4.2 Áreas claves del proceso...................................................................................................................38 6.4.3 Utilización del modelo.........................................................................................................................40

6.5 El modelo BOOTSTRAP. ...............................................................................................................................41 6.5.1 El proceso de evaluación. .................................................................................................................41 6.5.2 Uso de la base de datos de soporte. ..............................................................................................42 6.5.3 Proceso de mejora. .............................................................................................................................42 6.5.4 Instrumentos para la evaluación......................................................................................................42

6.6 El Modelo ISO/SPICE....................................................................................................................................43 6.6.1 Arquitectura del modelo....................................................................................................................44 6.6.2 Los elementos de evaluación. ..........................................................................................................44

7 Metodología propuesta para Auditar el Desarrollo de Sistemas..............................................................45 7.1 Planificación de la auditoría. ....................................................................................................................45

7.1.1 Comprensión del negocio y de su ambiente. ...............................................................................46 7.1.2 Riesgo y materialidad de auditoría..................................................................................................46 7.1.3 Técnicas de evaluación de Riesgos. ...............................................................................................46 7.1.4 Objetivos de controles y objetivos de auditoría............................................................................47 7.1.5 Procedimientos de auditoría. ............................................................................................................47

7.2 Desarrollo del programa de auditoría. ...................................................................................................47 7.3 Asignación de Recursos de auditoría. ....................................................................................................48 7.4 Técnicas de recopilación de evidencias. ..............................................................................................49

7.4.1 Errores en el levantamiento de la información..............................................................................49 7.4.2 Pretesteo de los instrumentos de levantamiento de la información ........................................51 7.4.3 Desarrollo y verificación de los instrumentos de reunión de información................................52

7.5 Actividades de Validación y Verificación..............................................................................................55 7.5.1 Análisis de la información primaria ..................................................................................................55 7.5.2 Actividades de Calidad. ....................................................................................................................57 7.5.3 Walkthroughs. .......................................................................................................................................57 7.5.4 Inspecciones. ........................................................................................................................................57 7.5.5 Objetivo de las Inspecciones. ...........................................................................................................57 7.5.6 Uso de los resultados. ..........................................................................................................................57 7.5.7 Entrada/Salida de las inspecciones.................................................................................................57 7.5.8 El proceso de la inspección...............................................................................................................58 7.5.9 Roles en una inspección. ...................................................................................................................58 7.5.10 La reunión..............................................................................................................................................58 7.5.11 Beneficios de las Inspecciones. ........................................................................................................58 7.5.12 Efectividad de las Inspecciones. ......................................................................................................58 7.5.13 ¿Cuándo hacer una inspección?....................................................................................................59 7.5.14 Reglas de Weinberg para revisiones. ..............................................................................................59 7.5.15 Recomendaciones..............................................................................................................................59 7.5.16 Mantenimiento de la Integridad de la Inspección.......................................................................59

7.6 Laboratorio de Pruebas .............................................................................................................................60



7.6.1 Fase de pruebas. .................................................................................................................................60 7.6.2 Actividades de las pruebas. ..............................................................................................................60 7.6.3 Administración de las pruebas..........................................................................................................60

7.7 El entrenamiento adecuado del equipo de pruebas deberá ser un conducto para realizar mejor el trabajo.Evaluación de fortalezas y debilidades de auditoría. ................................................................61 7.8 Informes de auditoría (Reportes)..................................................................................................................61

7.8.1 Elementos básicos del informe de auditoría ..................................................................................62 7.8.2 Objetivos Características y afirmaciones que contiene el informe de auditoría...................64 7.8.3 Circunstancias con efecto en la opinión del auditor ..................................................................65 7.8.4 Tipos de oponión..................................................................................................................................65

7.9 Seguimiento de las observaciones de auditoría. ..........................................................................................69 8 Referencias...........................................................................................................................................................69



ProyectoFinal.doc

1 Introducción 1.

Cada día es mayor el número de situaciones irregulares que se presentan, como consecuencia del uso y aplicación de la Tecnología de Información (T. I.), en las diferentes organizaciones, entidades, empresas y compañías en general.

El conocimiento de esta tecnología se ha ampliado a todas las esferas; la gente aprende cada día más, se vuelve más estudiosa y conocedora, pero no todos están orientados puramente al conocimiento como aumento de calidad en todos los campos; a algunos les interesa aprender más que todo, para ver cómo efectúan o generan irregularidades en provecho propio, o que como producto de lo que conocen, adquieren destreza para utilizarlas con fines alevosos y malintencionados; situación que ligada a la pérdida de valores morales, éticos y religiosos en todos los niveles y estratos de la sociedad, ha originado todo tipo de acciones fraudulentas, y que se haga imposible para la administración, establecer controles que disminuyan los riesgos presentados.

Aunado a lo anterior, las aperturas comerciales, la globalización, las alianzas estratégicas, y las integraciones de todo tipo, de alguna manera han venido a complicar la situación en cuanto al sistema de control interno se refiere; también han recargado las funciones que deben realizar los auditores.

Los aspectos citados han generado también, un desajuste en todos los campos relacionados con la T. I.; nadie sabe qué hacer, ni cómo hacerlo; unos dicen:

"...eso no me corresponde a mí, "le toca" a los técnicos expertos en cómputo.".

Los informáticos manifiestan: "...los usuarios no colaboran, no saben lo que quieren...".

La Alta Administración, no participa y delega en otros las funciones y actividades que le corresponden.

Los usuarios jefes, únicamente solicitan trabajos a cómputo, sin participación activa, y dicen:

"...Yo no sé de cómputo, pero entiendo que todo es muy fácil...".

La Auditoría Interna, ha participado muy poco en todos los procesos, más que todo por desconocimiento y por temor a perder la independencia, también por influencia de la Alta Administración, quien no los deja "participar".

La Auditoría en Sistemas de Información (ASI): se ha preocupado más en las revisiones posteriores de lo ya realizado (cuando ya es tarde), que en el establecimiento de controles preventivos.

Todos los aspectos citados, han tenido gran influencia en la situación actual de los sistemas de información diseñados y desarrollados en la mayoría de nuestras organizaciones; situación que debe cambiar ya, (debió cambiar hace unos 20 ó más años), y somos nosotros, quienes debemos ser agentes de este cambio.

2 Auditoría Informática 2.

2.1 Conceptos de Auditoría Informática.

Auditoría. Examen crítico que se realiza con el objetivo de evaluar la eficiencia y eficacia de operación de una sección o de la totalidad de un organismo para que, por medio del señalamiento de cursos alternativos de acción, se tomen decisiones que permitan corregir los errores, en caso de que existan, o bien mejorar la forma de actuación.

La Auditoría es un proceso formal que requiere ser definido por medio de planes y procedimientos. El nivel de detalle depende del ambiente de trabajo, por ejemplo, los requerimientos militares son más estrictos que los comerciales. El ISO 9001 requiere un



programa formal de auditoria, con procesos documentados que incluyan aspectos como frecuencia de auditorias, auditores independientes, reportes requeridos.

Los reportes de auditoria deben incluir:

1. Lista de aspectos que no satisfacen requerimientos. 2. Observaciones (positivas y negativas). 3. Recomendaciones.

Informática. Ciencia que se encarga del estudio y aplicación práctica de la tecnología, métodos, técnicas y herramientas relacionados con las computadoras y el manejo de la información por medios electrónicos.

Proceso metodológico que se desarrolla de manera permanente en las organizaciones para el análisis, evaluación, selección, implantación y actualización de los recursos humanos (conocimientos, habilidades, normas,...), tecnológicos (hardware, software,...), materiales (escritorios, edificios, accesorios, ...) y financieros (inversiones) encaminados al manejo de la información, buscando alcanzar los propósitos de calidad, confiabilidad, oportunidad, integridad y veracidad, entre otros.

Auditoría en Informática.

I) Es un proceso formal orientado a la verificación y aseguramiento de la ejecución de manera oportuna y eficiente de las políticas, controles y procedimientos establecidos para el manejo y uso adecuado de la tecnología de informática en la organización.

II) Proceso metodológico cuyo propósito principal es revisar y evaluar todos los recursos (humanos, materiales, financieros, tecnológicos, ...) relacionados con la función informática para garantizar al negocio que operan con un criterio de integración y desempeño de niveles altamente satisfactorios en apoyo a la productividad y rentabilidad de la organización.

Su campo de acción incluye:

A. La evaluación administrativa del departamento / área de informática. B. La evaluación de los sistemas y paquetería. C. La evaluación del proceso de datos. D. La evaluación de los equipos de cómputo.

La evaluación administrativa del departamento de informática comprende:

1. La Misión y objetivos del departamento / área. 2. Servicios soportados por el área. 3. Metas, planes, políticas y procedimientos de procesos. 4. Organización del área y su estructura orgánica. 5. Funciones y niveles de autoridad y responsabilidad del área. 6. Integración de los recursos materiales y técnicos. 7. Costos. 8. Controles (presupuestales, administrativos,...). 9. Parámetros de medición.

La evaluación del software:

1. Evaluación del análisis de los sistemas. 2. Evaluación del diseño del sistema. 3. Evaluación del desarrollo físico del sistema. 4. Control de proyectos. 5. Instructivos y documentación. 6. Formas de implantación. 7. Seguridad física y lógica de los sistemas.



ProyectoFinal.doc

8. Confidencialidad de los sistemas. 9. Controles de mantenimiento. 10. Forma de respaldo de los sistemas. 11. Administración de la paquetería. 12. Aspectos legales de la paquetería. 13. Utilización de los sistemas / paquetes. 14. Grado de satisfacción al usuario.

La evaluación del proceso de datos.

1. Control de los datos fuente. 2. Control de operación. 3. Control de salida. 4. Control de asignación de trabajo. 5. Control de medios de almacenamiento masivo. 6. Seguridad física y lógica. 7. Confidencialidad. 8. Respaldos y recuperación.

La evaluación de los equipos y las instalaciones.

1. Evaluación de la administración del equipo. 2. Evaluación de la configuración del equipo. 3. Evaluación de la red y las telecomunicaciones. 4. Evaluación del mantenimiento. 5. Seguridad física y lógica. 6. Orden en las instalaciones. 7. Contratos de compra, mantenimiento, seguros y respaldo. 8. Evaluación de la instalación eléctrica y ambiental.

2.2 Técnicas Básicas y Clásicas de Auditoría.

2.2.1 Cuestionarios.

Secuencia de preguntas, permite evaluar las probables fuerzas y debilidades del sistema para realizar pruebas sustanciales y adecuadas en las áreas identificadas. Su uso principal es en la revisión general del sistema.

2.2.1.1 Problemas.

• Repetir respuestas de cuestionarios anteriores. • Respuestas automáticas de "si" o "no", sin entenderse la pregunta. • Redacción con tendencia a destacar las debilidades o problemas, ya que

ante una respuesta que debería ser "no", se provoca respuesta de "si". • Falta de entendimiento de la pregunta por el auditor.

2.2.1.2 Cuando incorporar cambios. • Por nuevos aspectos a evaluar. • Para obtener opiniones concensadas. • Verificar otras respuestas. • Obtener información estadística. • Darle sentido o rumbo más con sentido.

2.2.1.3 Guías generales para preparar cuestionarios. • Explicar el propósito, uso, seguridad y disposición de las preguntas. • Instrucciones detalladas para responderlo. • Fijar tiempo máximo de respuesta, en caso de que el auditor no sea quien

lo aplique directamente. • Preguntas positivas y precisas.



• Formular las preguntas considerando como serán manejadas, manual o automáticamente.

• Espacio suficiente para las respuestas. • Redacción clara. • Redacción que no provoque respuestas ambiguas. • Posibilidad de ampliación cuando se requiera. • Explicaciones apropiadas. • Incluir información de referencia, nombre, puesto, área,...

2.2.2 Auditar alrededor de la computadora.

Consiste en considerar a la computadora y los sistemas como una "caja negra" y revisar las entradas y salidas solamente. Los controles y procedimientos del proceso de datos son considerados sin importancia, en la medida que las salidas correspondan a las entradas y estas últimas sean válidas, de tal manera que si entradas y salidas corresponden, se considera que los controles están operando correctamente.

El auditor:

Selecciona una muestra de transacciones que ya ha sido procesada. Revisa desde el origen de la transacción hasta la salida que produce.

Ventajas.

• No se interfiere con datos en línea. • Requiere poca capacidad técnica del auditor. • Simple, directa y fácil de entender. • Los recursos de auditoria son de bajo costo.

Desventajas. • Difícil manejar bases de datos muy voluminosas. • No se apoya a que los auditores se involucren en el entendimiento de los sistemas

computacionales. • Se ignoran los controles del sistema por lo que ignora posibles fallas o debilidades

del sistema. • Es auditoria "a posteriori" por lo que no ayuda en la prevención. • No hace uso de la computadora y todo su potencial como herramienta de

auditoria. • Es limitada en sus alcances.

2.2.3 Auditoría a través de la computadora.

Pone más énfasis en probar al sistema computacional que produce los resultados más que a los resultados por si mismos.

El auditor prueba y verifica:

• La efectividad de los controles y procedimientos de operación y programas computacionales.

• Lo correcto del procesamiento interno.

La técnica implica 2 tareas básicas.

• Revisar y verificar las transacciones fuente. • Probar la lógica de los programas y sus controles, puede hacer uso de una tabla

de pruebas (test deck).

Ventajas. • El auditor se involucra más con el sistema. • La computadora opera como una herramienta auxiliar en las pruebas de

adecuación / conformidad y en la evaluación de los controles programados.



ProyectoFinal.doc

• Los controles y las operaciones son evaluados por el auditor. • Los resultados de las pruebas son identificables y pueden ser utilizados como

medida de confiabilidad del proceso interno. • Usa a la computadora como herramienta para realizar actividades de auditoria.

Desventajas. • Requiere tiempo de computadora. • Requiere más conocimiento técnico. • Realiza pruebas "a posteriori" y no preventivas. • Prueba limitada por el sistema.

2.2.4 Tabla de Pruebas "Test Deck".

Transacciones simuladas o transacciones que idealmente incluye cualquier condición posible, incluyendo aquellas que el sistema no puede manejar por falta de controles propios. Esto es, deben incluirse pruebas válidas e inválidas y ser procesadas por los sistemas normales. El auditor debe conocer o determinar cuales deben ser los resultados de las pruebas para compararlos con los que se obtengan del sistema.

Preparación de las pruebas.

• Considerar el sistema de controles completo. • Seleccionar transacciones para probar aspectos selectos del sistema o el sistema

completo. • Las pruebas deben ser introducidas al sistema. • Verificar que se hayan introducido correctamente. • Las pruebas deben ser procesadas usando los programas en producción y

sistemas operativos normales. • Se comparan los resultados obtenidos con los predeterminados.

Controles de auditoria sobre los programas que se están probando.

• Procedimientos de cambio de programas y Uso de paquetería integral. • Solicitar los programas a ser probados de manera no planeada, obtener un

listado fuente de los mismos. • Ejecutar las pruebas de manera inmediata o simultánea al procesamiento

cotidiano en producción.

Ventajas.

• No requiere conocimiento técnico profundo. • Es buena opción cuando las posibles combinaciones de transacciones y su

amplitud no son de mayores dimensiones. • Da una objetiva evaluación y verificación de los controles de los programas y

otras operaciones, que en otras circunstancias sería imposible realizar. • Se puede realizar de manera sorpresiva y paralela a las operaciones normales

disminuye los problemas por programas modificados y mejora los resultados obtenidos por otras pruebas.

Desventajas.

• Requiere gran cantidad de tiempo la preparación de una serie de pruebas representativas, así como su mantenimiento.

• En ocasiones las pruebas no se realizan sobre el sistema real en producción. • En sistemas complejos con una gran variedad de transacciones es difícil anticipar

todas las condiciones importantes y variables que deben ser probadas. • El auditor debe estar familiarizado con la lógica de programación que está

probando.



• La prueba no prueba todos los errores posibles y es difícil recorrer todos las opciones probables del programa.

• Es difícil que la prueba aborde una situación específica.

2.2.5 Revisión de auditoría a programas de aplicación.

El auditor revisa los controles, lo completo del código y lo propio de la lógica, se siguen las opciones del programa para procesar datos típicos de entrada con el propósito de identificar errores. En cierta forma el auditor trata de ser la computadora.

Razones para realizar revisiones de auditoria a programas. • Detectar o descubrir fraudes por programación. • Establecer el grado de cumplimiento de reglamentos y leyes. • Ver si son usadas formas convencionales de registro y detectar errores honestos o

maliciosos. • Evaluar la eficiencia de los programas. • Establecer como genera información el programa en áreas de difícil

determinación. • Determinar si la documentación está actualizada. • Facilitar la revisión de modificaciones subsecuentes al programa. • Como experiencia real de programación para el auditor. • Involucrar al auditor con el sistema, ganando respeto del personal de cómputo.

Técnica formal para realizar la revisión de auditoria de programas.

1. Revisar los estándares de documentación y programación establecidos para la instalación.

2. Seleccionar un programa o sistema en particular para revisarlo. 3. Obtener una copia de código fuente del programa. 4. Obtener una copia de la documentación del programa. 5. Determinar los archivos de entrada y salida que son usados y como son usados

por el programa. 6. Confirmar el nivel de entendimiento de los archivos y registros recibidos. 7. Revisar la manipulación de archivos y registros que hace el programa. 8. Revisar la lógica del programa. 9. Buscar las estructuras de control de flujo de procesamiento y evaluarlas. 10. Verificar los llamados a programas externos que complementan el

procesamiento del programa. 11. Poner a funcionar el programa en la computadora.

2.3 La computadora herramienta de auditoria mediante el uso de programas 2.

El auditor tiene las siguientes fuentes de programas de auditoría.

• Escritos por un programador de la organización auditada. • Escritos por o bajo la supervisión de el auditor. • Desarrollados por firmas de auditoría y/o casas de software. • Programas de utilería proporcionados por proveedores de computadoras.

Categorías de programas.

• Diseñados exclusivamente para resolver una necesidad de auditoría. • Diseñados para cubrir una necesidad de auditoría, pero útiles para la administración

con cierta frecuencia. • Modificación de un programa existente para realizar una función de auditoría al

mismo tiempo que una operación normal. • Programas existentes que se ejecutan bajo una situación controlada.



ProyectoFinal.doc

3 Auditoria de Software 3.

3.1 Auditoría de Software.

Mecanismo para determinar el grado de cumpliendo con estándares, guías / instructivos, especificaciones y procedimientos, que tiene el software en su estado actual. Debe comprender:

• Planes y procedimientos documentados. • Evaluar elementos y procesos de software. • Resultados documentados y enviados a la gerencia. • Seguimiento a acciones correctivas.

3.1.1 Roles y responsabilidades en la auditoria.

Cliente Solicitante de la auditoría (cliente) externo o interno que tiene la capacidad para autorizarla.

Administración de la organización de auditoría Debe tener como propósito soportar la auditoría con los recursos y el tiempo de preparación apropiados.

Líder. Sus responsabilidades incluyen:

• Ser el primer contacto con la organización auditada. • Organiza y dirige al equipo de auditoría, incluye proporcionar la orientación y

entrenamiento necesarios. • Coordina la preparación de la auditoria; establece programa de entrevistas. • Realización del reporte. • Asegurar que el equipo está preparado (materiales, documentos,

herramientas,...). • Asegurar que son seguidos los procedimientos de auditoria.

Auditor. Debe prepararse profesionalmente, esto incluye conocimiento de:

• La organización auditada. • Los productos y procesos. • El criterio de auditoria.

Auditados (Organización / área auditada). Deben considerar la auditoria como una oportunidad de mejorar sus operaciones.

3.1.2 Entrada para el proceso de auditoria.

• Autorización. • Propósito y ámbito. • Criterio objetivo de auditoria. • Identificación de componentes de software y procesos a ser auditados. • Información de referencia.

3.1.3 Necesidad de la auditoria.

• Por requerimiento externo. • Por elementos internos de la organización. • Proyectos demasiado largos o enfrentar criterio de salida. • Leyes y regulaciones.

3.1.4 Plan de auditoria debe establecer:

• Proyectos y procesos por auditar. • Software que será auditado. • Programa incluyendo el tiempo para cada área auditada. • Contenido y distribución del reporte. • Criterio de Auditoria (ISO 9001, IEEE Std 730).



• Procedimientos. • Checklists (listas de verificación) únicas para cada auditoria. • Identificar la organización a auditar y su localización.

3.2 El proceso de Auditoría.

3.2.1 Autorización.

Es la acreditación otorgada por la empresa para que otro órgano calificado tenga acceso a la información y archivos de la misma con fines preventivos.

3.2.2 Reunión previa que provee información sobre:

• Acuerdos existentes. • Producción y procesos. • Procesos, objetivos y resultados esperados de la auditoría. • Programa de entrevistas establecido. • Consideraciones especiales de la organización auditada. • Distribución de las instalaciones.

3.2.3 Preparación de la auditoria.

• Revisión de la documentación. • Familiarizarse lo más posible con los productos y procesos. • Crear "checklists" únicos. • Regla de oro - un día de preparación por un día de auditoría.

3.2.4 Reunión de apertura.

• Introducción. • Revisión del programa y realización de ajustes necesarios. • programación diaria. • reunión de retroalimentación. • reunión final, lugar y hora.

3.2.5 Entrevistas y exámenes.

Son realizados para evaluar componentes de software y personal en referencia a:

• Estándares, procedimientos e instrucciones. • Estructura del trabajo, ejemplo: definición de tareas y su criterio de aceptación. • Productos (documentación, código, resultados de prueba, problemas...). • Análisis de problemas existentes o factores resultantes de las entrevistas o las

revisiones de la documentación.

Sesiones de retroalimentación diaria, permite mantener informado a los auditados de cualquier problema encontrado. Período de tiempo para revisar si los auditores tienen toda la información correcta para poder determinar aspectos que no satisfacen los requerimientos.

Preparación de reportes de avance, el formato de los reportes de auditoría varía, sin embargo no deben contener ninguna sorpresa, de preferencia se debe presentar lo encontrado con los auditados antes de concluir la visita y aclarar cualquier punto o aspecto antes de la reunión final.

3.2.6 Reunión final.

Preparación de reporte definitivo. El reporte definitivo debe cumplir con lo estipulado en el plan de auditoría. Normalmente contiene la siguiente información:

• Identificación: Título, Organización de auditoría, auditados, fechas y equipo auditor.



ProyectoFinal.doc

• Ámbito de la auditoría: Incluye identificación de estándares, procesos y/o sistema utilizados como referencia.

• Conclusión: Interpretación de los hallazgos y observaciones. • Cobertura: Componentes de Software, procesos y productos auditados. • Seguimiento: Actividades a realizar en consecuencia. • Recomendaciones si son requeridas por el plan de auditoría.

3.2.7 Distribución del reporte.

Seguimiento.

Las auditorias deben ser auditables, por lo que se debe guardar registro de todo el proceso.

3.2.8 Auditoria completa.

• Cada elemento programado para auditoría ha sido examinado. • Lo identificado ha sido presentado a los auditados. • Las respuestas han sido recibidas y evaluadas. • Reporte de auditoria preparado y enviado. • Las actividades consecuentes han sido realizadas según se requirió.

3.3 Tipos de Auditoría.

Al-proceso (In-process). Verifica la consistencia del producto. Determina si las interfaces son consistentes, el código fue totalmente probado, el diseño satisface requerimientos funcionales y de desempeño y el código es consistente con la documentación de diseño. Es aplicada para determinar el grado de cumplimiento de estándares del proceso. Se deben proporcionar descripciones formales de los procesos y muestras del producto.

Sistema de Calidad (Quality System Audit- QSA). Evaluación basada en criterios de calidad documentados. Tiene como objetivo determinar:

• El cumplimiento de estándares de la documentación del sistema de calidad. • Si la estructura de desarrollo se ajusta al programa de calidad. • Si el programa o plan de calidad incorpora criterios objetivos de desempeño;

procedimientos y estándares internos, requerimientos por ley, contrato o política de la compañía, y estándares apropiados para el aseguramiento de la calidad de software.

3.3.1 Actividades QSA.

• Reunión previa. • Examinar el programa de calidad. • Entrevistas con el personal. • Realización de auditorias al-proceso (In-process) limitadas. • Examinar reportes de desarrollo y mantenimiento.

Evaluación propia. Forma de hacer explícitos los procesos de calidad de tal manera que los involucrados puedan entenderlos, necesitan ser definidos para proyectos específicos. Requieren de una metodología. Deben considerarse como un proceso de mejora continua, hacerlos sólo una vez es un error.

El instituto de ingeniería de software propone el modelo de madurez de capacidades / competencias (SEI-Capability maturity model CMM)

NIVEL ENFASIS AREAS CLAVE DEL PROCESO

Optimizado Proceso de mejora

continua

Prevención de fallas. Administración del cambio tecnológico. Administración del proceso de cambio



Administrado Calidad del producto y del

proceso

Administración de la calidad de Software. Administración cuantitativa del proceso

Definido Proceso de Ingeniería de

software

Énfasis en la Organización. Definición de la Organización. Revisiones detalladas. Programa de capacitación. Coordinación entre grupos. Ingeniería de Software. Administración integrada del software

Repetición Administración del

proyecto

Planeación de proyectos de SW. Seguimiento de proyectos de SW. Administración de subcontratos de SW. Aseguramiento de calidad de SW. Administración de la configuración de SW. Administración de requerimientos

Inicial

4 Revisiones de Software 4.

4.1 Revisiones de Software.

Son reuniones formales en las que un producto o documento es presentado para discusión o aprobación. Pueden hacerse de, requerimientos, diseño, clientes, procesos y proyectos entre otras:

Revisión. Evaluación de componentes de software y estatus de proyectos para identificar diferencias respecto a los resultados planeados y para sugerir mejoras.

Revisión especializada ("Peer Review"). Revisión crítica y documentada por especialistas independientes del trabajo en revisión.

Independiente. Evaluación por alguien que no es participante, supervisor, revisor técnico o asesor del trabajo que está en revisión.

4.1.1 Responsabilidades en una revisión.

• Reunión previa. • Examinar el programa de calidad.

De la administración.

• Revisiones y reproceso. • Realización de las revisiones. • Reporte de resultados. • Proporcionar recursos.



ProyectoFinal.doc

Del Personal de Realización (desarrollo).

• Experiencia y conocimiento del producto. • Entrenamiento y orientación a participantes.

OBJETIVO DE LA REVISION Evaluar un componente específico del software.

• Se adecua a su especificación. • Se desarrolla o mantiene de acuerdo con los requerimientos del proyecto. • Cambios implementados correctamente. • Critica.

- Suposiciones. - Cálculos. - Extrapolaciones. - Inconsistencia de interpretaciones. - Metodología. - Conclusiones.

4.1.2 Roles y responsabilidades en la revisión.

• Líder Dirigir la revisión y realizar actividades administrativas. • Registrador llevar referencia de documentos encontrados y recomendaciones. • Miembros del equipo revisor prepararse y hacer recomendaciones. • Administración llevar a cabo las recomendaciones.

4.1.3 Entradas para el proceso de revisión.

• Establecimiento de objetivos. • Identificación de componentes de software. • Especificación de componentes de software. • Requerimientos del proyecto. • Estándares aplicables.

Criterio de inicio definido.

• Autorización. • Inicio / arranque.

- Establecimiento de objetivos. - Individuos listos. - Componentes de software completos aceptablemente.

4.1.4 Procedimiento de revisión.

Planeación el líder debe identificar el equipo de revisión, programar y anunciar la revisión y distribuir el material.

Presentación general el diseñador o analista proporciona un panorama general de lo que será revisado. Es opcional, útil cuando los revisores no conocen lo suficiente el producto objetivo.

Preparación que realiza cada participante sobre los componentes de software a ser revisados.

Examinación de los componentes de software.

Realización del reporte de revisión.

Seguimiento acciones a realizar.

Una revisión está completa cuando.

• todos los aspectos fueron tratados. • todas las suposiciones fueron validadas. • cálculos verificados.



• consecuencias de resultados entendidas. • limitaciones de metodologías y procedimientos entendidas. • El reporte es realizado. • Aspectos de diseño y administración son resueltos.

Una revisión también debe ser auditable!!!

4.2 Revisiones de Requerimiento de Software.

• Asegurar lo adecuado de la especificación de requerimientos. • Evaluar factibilidad técnica. • Grado de Completo ("completitud"). • Realizar hasta que la especificación de requerimientos de software sea.

- No ambigua. - Verificable. - Consistente. - Modificable. - Seguible. - Útil.

Checklist.

• Se puede seguir y completar. • Compatibilidad de interfaces. • Adecuación a estándares. • Factibilidad de requerimientos de desempeño. • Racionalidad de requerimientos derivados. • Interfaces adecuadas hombre / máquina. • Requerimientos de desempeño adecuados. • Consideración de factores humanos.

4.3 Revisiones de Diseño de Software.

• Evaluar la adecuación técnica del diseño. • Verificar el progreso, consistencia y adecuación técnica del diseño seleccionado. • Revisar.

- Compatibilidad de interfaces. - Satisfacción de los estándares de documentación de diseño. - Riesgos. - Seguible. - Probable.

Checklist.

• Interfaces de software. • Funcionalidad genérica. • Factores Humanos. • Mantenible. • Factibilidad de descripción lógica. • Precisión técnica de la documentación de pruebas. • Software de soporte. • Interfaces de hardware. • Razonamiento alternativo de diseño. • Documentación. • Suposiciones. • Disponibilidad de los datos. • Descripción lógica correcta. • Situación técnica de pruebas. • Software de prueba.



ProyectoFinal.doc

• Línea de referencia para configuración. • Ambiente estándar de operación. • Consideraciones de prueba. • Documentación de riesgos. • Completitud de los algoritmos. • Compatibilidad de algoritmos.

5 Revisiones Especializadas “Peer Reviews”.

5.1 Definición de una revisión entre pares (Peer Reviews).

Este término, traducido al castellano como “revisión editorial” o “arbitraje” o como “revisión por pares”, se refiere al proceso de revisión o evaluación del trabajo por expertos en el campo objeto del estudio en cuestión (“revisores” o “árbitros”) 5.

Este método de control es posible usarlo cuando se ha logrado relativa madurez sobre el Proceso de Software; principalmente cuando los productores de software asumen la importancia de reconocer y corregir sus errores “en casa” antes de que el mismo sea detectado fuera de la organización6.

Resulta factible cuando se logra que el productor de software esté realmente interesado en aprender del propio proceso y logra superar los reparos a permitir que su actividad sea revisada por otro profesional de su mismo nivel6.

Es una buena metodología para aplicar a sistemas complicados o con muchos errores6.

Presenta las características de una reunión de trabajo, muchas veces solicitada por el propio jefe de proyecto con objetivo de inspeccionar y revisar técnicamente su producto o su proceso para detectar errores6.

A la misma no deben asistir gerentes, pues la intención es encontrar fuentes de error para guía del jefe de proyecto; y no inspeccionar su trabajo6.

Normalmente funcionan sobre un checklist; y se buscan fuentes de defectos y no detalles. Los que se detectan, no se explican allí6.

Para una adecuada reunión de este tipo se plantean los siguiente roles: moderador, productores, registrador, inspectores (“reviewers” pares) 6.

En ellas normalmente se revisan: especificaciones de requerimientos, aceptación de los mismos, especificaciones de diseño, revisiones generales sobre diseño, revisiones críticas del diseño, conformidad de lo realizado contra lo diseñado, etc6.

5.2 Tipos de revisiones.

5.2.1 Reuniones informales (pasillo).

Las revisiones informales son una forma de discusión del equipo de proyecto o del equipo de trabajo, involucrando a dos o más participantes del grupo. Las revisiones informales tienen como objetivo analizar las distintas perspectivas de enfoque y revisar los reportes de avance conforme a las metas. Estas revisiones no tienen restricciones y el grupo auditor no es responsable de estas. En este tipo de revisión se encuentra la revisión personal, la cual debe ocupar un puesto importante en las actividades personales diarias.

5.2.2 Revisiones técnicas formales7.

Una revisión técnica formal es una actividad de garantía de calidad del software que es llevada acabo por los ingenieros de Software.

Objetivo. Descubrir errores, verificar requisitos, garantizar el seguimiento de los estándares, conseguir uniformidad y aumentar su manejabilidad.



Las reuniones de revisión, deben de convocarse entre tres y cinco personas . Se deben preparar por adelantado (no más de dos horas de trabajo por cada persona). Debe durar menos de dos horas. Se inspecciona una parte concreta del software (limitación del centro de atención).

Cuando se finaliza un producto, el desarrollador lo comunica al jefe del proyecto, para que este informe al jefe de revisión, que organiza la revisión del producto finalizado.

Todos los resultados quedan registrados en:

• Lista de sucesos de revisión. • Informe de revisión.

Directrices para la revisión:

• Revisar el producto no al productor. • Fijar una agenda y mantenerla. • Limitar el debate y las impugnaciones. • Enunciar áreas de problemas pero no intentar resolver cualquier problema que se

ponga de manifiesto. • Tomar notas escritas. • Limitar el número de participantes e insistir en la preparación anticipada. • Desarrollar una lista de comprobación para cada producto que haya de ser

revisado. • Disponer recursos y una agenda para las Revisiones Técnicas Formales. • Llevar a cabo un buen mantenimiento de todos los revisores. • Repasar las revisiones anteriores.

5.3 Participantes en una revisión.8.

Una de las partes más importantes dentro de las revisiones es el personal que deberá participar y sus características.

Uno de los esquemas generalmente aceptados para tener un adecuado control es que el personal que intervengan esté debidamente capacitado, con alto sentido de moralidad, al cual se le exija la optimización de recursos (eficiencia) y se le retribuya o compense justamente por su trabajo.

Con estas bases se debe considerar las características de conocimientos, práctico profesional y capacitación que debe tener el personal que intervendrá en la auditoría. En primer lugar se debe pensar que hay personal asignado por la organización, con el suficiente nivel para poder coordinar el desarrollo de la auditoría, proporcionar toda la información que se solicite y programar las reuniones y entrevistas requeridas.

Éste es un punto muy importante ya que, de no tener el apoyo de la alta dirección, ni contar con un grupo multidisciplinario en el cual estén presentes una o varias personas del área a auditar, sería casi imposible obtener información en el momento y con las características deseadas.

También se debe contar con personas asignadas por los usuarios para que en el momento que se solicite información o bien se efectúe alguna entrevista de comprobación de hipótesis, nos proporcionen aquello que se esta solicitando, y complementen el grupo multidisciplinario, ya que se debe analizar no sólo el punto de vista de la dirección de informática, sino también el del usuario del sistema.

Para completar el grupo, como colaboradores directos en la realización de la auditoría se deben tener personas con las siguientes características:

• Técnico en informática. • Experiencia en el área de informática.



ProyectoFinal.doc

• Experiencia en operación y análisis de sistemas. • Conocimientos de los sistemas más importantes.

En caso de sistemas complejos se deberá contar con personal con conocimientos y experiencia en áreas específicas como base de datos, redes, etc. Lo anterior no significa que una sola persona tenga los conocimientos y experiencias señaladas, pero si deben intervenir una o varias personas con las características anotadas.

5.4 Fases de una revisión entre pares.

5.4.1 Pre-Observación (Información preliminar).

Debe haber una reunión inicial entre la empresa y el revisor de pares para acordar la fecha y la hora en que se llevará a cabo la observación, las metas y el enfoque de la observación así como cualquier herramienta, documentación o notas utilizadas por el revisor la intervención.

5.4.2 La Observación entre pares.

Esta observación es personal y debe darse en una o dos sesiones.

5.4.3 Observación Posterior (Instrucciones).

Se debe continuar con una reunión entre la empresa y el revisor de pares, para discutir las percepciones de cada uno en las actividades realizadas en las sesiones, interacciones y hacer sugerencias constructivas de los cambios a realizar.

5.4.4 Entrega de la documentación.

El revisor de pares deberá entregar un documento escrito con las recomendaciones acerca de que deberán continuar haciendo así como sugerir que cambios hay que hacer, como poder mejorar las sesiones y los métodos de intervención.

5.5 Producto de trabajo.

Producto de trabajo. Es cualquier información producida por un proceso. Esto puede incluir archivos, documentos o partes de un producto, servicios procesos, especificaciones y facturas. Ejemplos de procesos como productos de trabajo incluyen el proceso de manufactura el proceso de entrenamiento y el proceso de deshechos. La diferencia entre un producto de trabajo y un producto componente es que el producto de trabajo no neecesita ninguna maquila.9

Para llevar acaabo cualquier auditoria de software se debe tener perfectamente identificado el producto de trabajo a auditar, para poder obtener:

• La configuración que guarda la administración de la integridad de los productos de trabajo.

• Los registros de identificación que dan la definición o descripción del producto de trabajo

• El control de la configuración con el cual ordenan y monitorean la configuración de acuerdo a la cadena del producto de trabajo.

• El status que debera llevar una cuenta sobre los cambios que ha sufrido el producto de trabajo.10

5.6 Listas de verificación y formas.

5.6.1 Formas de recoger la información.

Hay muchas maneras de recoger información durante una auditoría. Siguiendo el flujo natural, del área de contrato al área de expedición; siguiendo el flujo reverso, del área de expedición al área de contrato; o bien con flujo aleatorio, o sea sin orden predeterminada.



5.6.2 Listas de verificación11.

Antes de realizar una auditoria, es necesario hacer una lista de verificación de los aspectos que esta abarca. Con frecuencia existen listas de verificación que emplean los operadores y es posible simplificar la lista de verificación de la auditoria. Otras veces será necesario consultar el procedimiento o proceso a auditar y transformar su forma escrita en puntos para preguntar.

• Haga una lista de verificación de los equipos que desea ver durante la auditoria. • Haga una lista de personas que desea entrevistar durante la auditoria. • Observe todos los problemas detectados en la auditoria previa de la misma área,

procedimiento o proceso. • Observe los números de párrafos de los procedimientos aplicables en la lista de

verificación para que no tenga que referirse continuamente al procedimiento. • Deje suficiente espacio en la lista de verificación para hacer notas sobre lo que

observe y lo que se comente durante la auditoria.

La lista de verificación es una herramienta y debe ser usada para guiar las inspecciones. Los objetivos de la misma son:

• Unificar las acciones del auditor;. • Servir como orientación auxiliar;. • Garantizar que todos los puntos fueron alcanzados;. • Permitir un manejo eficaz del tiempo para cada área o actividad;. • Facilitar el registro de observaciones y evidencias;. • Facilitar el entrenamiento de nuevos auditores.

La lista de verificación deberá informar:

• Lo que se quiere ver. • Lo que se está buscando. • Con quien debe hablar. • Lo que se pretende preguntar.

El equipo de auditoría deberá preparar una lista de verificación que servirá de guía para la auditoría y para estandarizar la acción del auditor. La lista de verificación deberá facilitar el registro de las observaciones y de las evidencias durante la auditoría. Se recomienda que la lista de verificación tenga un sistema de puntuación para permitir que sea usada en un proceso de mejora continua.

Preparar una revisión supone emitir juicios en cada etapa del proceso de revisión. Pueden cometerse errores tanto sistemáticos como aleatorios. Existen varias listas de verificación (Checklist) que permiten a los revisores usarlas como guías en la detección de errores importantes en el proceso de revisión. Algunos puntos que deben tenerse en cuenta se presentan más adelante. Han sido recogidos a partir de múltiples referencias.12.

Formulación de la pregunta.

• Las preguntas de la revisión, ¿están bien formuladas y contienen los componentes clave?.

• ¿Se documentaron y justificaron adecuadamente los cambios en el protocolo?.

Identificación de estudios.

• ¿Hay una búsqueda minuciosa de datos pertinentes usando fuentes apropiadas?.

• ¿Las estrategias de búsqueda son adecuadas para la pregunta que se ha planteado?.

Selección de estudios.



ProyectoFinal.doc

• ¿Se aplican criterios de inclusión y de exclusión apropiados para seleccionar los estudios?.

• ¿Se aplican los criterios de selección de manera que limiten los sesgos?.

Evaluación de los estudios.

• ¿Se valora de manera fiable la validez de los estudios individuales?. • Los parámetros importantes que pueden afectar a los resultados del estudio (por

ejemplo, ámbito, población de estudio, diseño del estudio), ¿se abordan de modo sistemático?.

Obtención de datos.

• ¿Hay una mínima cantidad de datos no disponibles en los resultados y en otras variables que se consideren clave para la interpretación de los resultados?.

Síntesis de datos.

• ¿Se tomaron decisiones razonables con respecto a la manera de combinar los datos?.

• ¿Se han considerado en la síntesis factores importantes como el diseño de los estudios?.

• ¿Son sensibles los resultados a los cambios relacionados con la manera con que se hizo el análisis?.

• Se informa de la precisión de los resultados?.

Discusión.

• ¿Se mencionan las limitaciones de los estudios y del proceso de revisión?. • ¿Se integran los resultados de la revisión en el contexto de otra evidencia

indirecta?.

5.7 Métricas de software7.

Las métricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Cuando se habla de software se referiere a la disciplina de recoger y analizar datos basándonos en mediciones reales de software, así como a las escalas de medición.

Los atributos son características observables del producto o del proceso de software, que proporciona alguna información útil sobre el estado del producto o sobre el progreso del proyecto.

El término producto se utiliza para referirse a las especificaciones, a los diseños y a los listados del código objeto entregado.

Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores de métricas se derivan de los requisitos del cliente o de los usuarios y por tanto actúan como restricciones dentro del proyecto.

Los sistemas métricos necesitan tres tipos de valores:

1. Los objetivos: Se basan habitualmente en consideraciones comerciales.

2. Las ideales: Indican la viabilidad de los objetivos. Se basan en las características del producto con el que tratamos. Proporcionan un medio de comprobar la viabilidad de los objetivos.

3. Los valores reales: Pueden ser comparados con los objetivos para supervisar la progresión del proyecto. Son mediciones discretas de los atributos del software. Es preferible utilizar mediciones objetivas basadas en reglas.

Algunas mediciones se basan en estimaciones donde un valor más que medirse se evalúa.



5.7.1 Razones que Justifican la Medición del Software

Estas son algunas de las razones que justifican la medición del Software

• Para indicar la calidad del producto. • Para evaluar la productividad de la gente que desarrolla el producto. • Para evaluar los beneficios (en términos de productividad y calidad) derivados

del uso de nuevos métodos y herramientas de ingeniería de software. • Para establecer una línea base de estimación. • Para ayudar a justificar el uso de nuevas herramientas o formación adicional.

Las medidas de la Calidad del Software deben comenzar desde la especificación y terminar con la implementación, implantación y mantenimiento o postimplantación. Debe aplicarse a lo largo de todo el proceso de ingeniería de software.

La complejidad de la Calidad del Software está afectada por una serie de factores que deben ser cuantificables directa e indirectamente.

Entre las medidas directas del proceso de ingeniería de software se encuentra el costo y el esfuerzo aplicado. Entre las medidas directas del producto están las líneas de código producidas, velocidad de ejecución y los defectos observados en un período de tiempo. Entre las medidas indirectas se encuentran la calidad, funcionalidad, eficiencia, facilidad de mantenimiento, etc.

Básicamente la medición es una fase normal de cualquier actividad industrial, hay que predecir y supervisar lo que hacemos. Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional.

Las métricas a recabar dependen de los objetivos del negocio en particular. Los desarrolladores de Software tienen a la vez objetivos comunes como, respetar el presupuesto y respetar los plazos, minimizar las tasas de defectos antes y después de la entrega del producto e intentar mejorar la calidad y la productividad.

Las métricas deben ayudar a la evaluación de las representaciones del modelo lógico y físico, deben tener la capacidad de intuir sobre la complejidad del diseño y construcción, y deben ayudar en el diseño de casos de prueba.

El proceso de medición, se caracteriza en cinco actividades:

• Formulación: Obtención de medidas y métricas del software apropiadas para la presentación del software en cuestión.

• Colección: Mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.

• Análisis: Cálculo de las métricas y la aplicación de herramientas matemáticas. • Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por

conseguir una visión interna de la calidad de la presentación. • Retroalimentación: Recomendaciones obtenidas de la interpretación de métricas

y técnicas transmitidas al equipo de desarrollo de software.

Los atributos que deben acompañar a las métricas efectivas del software son:

• Simple y fácil de calcular. • Empírica e intuitivamente persuasiva: Debe satisfacer las nociones intuitivas del

desarrollador sobre el atributo del producto en evaluación. • Consistente y objetiva: Presentar resultados sin ambigüedad. • Consistente en el empleo de unidades y tamaños: Deben emplearse medidas

que no conduzcan a extrañas combinaciones de unidades. • Independiente del lenguaje de programación: No deben depender de la sintaxis

o semántica del lenguaje de programación.



ProyectoFinal.doc

• Un eficaz mecanismo para retroalimentación de calidad: Debe proporcionar al desarrollador de software información que le lleve a un producto final de mayor calidad.

Existen muchas métricas, y éstas deben usarse conforme se acomoden al proceso.

Las métricas del producto están enfocadas a predecir y controlar:

1. El tamaño (líneas de código, bytes de código, operadores y operandos).

2. La estructura (control de flujo, relación entre componentes, cohesión y acoplamiento).

3. La complejidad (combinación de tamaño y estructura).

4. Los índices para controlar la documentación.

5. La calidad (independencia, completo, entendible, aumentado).

6. La estabilidad (los cambios aumentan el número de fallas, los cambios se pueden dar por definición de requerimientos o por cambios del entorno).

Las métricas del proceso se caracterizan por:

• El control y ejecución del proyecto. • Medición de tiempos del análisis, diseño, implementación, implantación y

postimplantación. • Medición de las pruebas (errores, cubrimiento, resultado en número de defectos

y número de éxito). • Medición de la transformación o evolución del producto.

En conclusión, las métricas han de ser utilizadas para el control de los proyectos. No son ni estándares ni universales. Cada proyecto debe seleccionar sus propias métricas.

5.7.2 Clasificación de Métricas

Las métricas de Software pueden clasificarse en tres categorías:

• Métricas de producto: Describen características del producto. • Métricas de proceso: Usadas para mejorar el proceso de desarrollo y

mantenimiento de software. • Métricas de proyecto: Describen las características del proyecto y su ejecución.

Las métricas para auditoria son un subconjunto, que se enfocan a medir los aspectos de cumplimento con los estándares.

Las métricas de auditoria de software pueden dividirse también en:

• Métricas del producto final (end-process). • Métricas de desarrollo (in-process).

La esencia de la auditoría de software es investigar la relación entre métrica in-process de proyecto y de producto final.

5.7.3 Consideraciones en la Etapa de Análisis

Un problema no puede ser definido y acotado completamente hasta que es comunicado. Por esto, es que el primer paso en cualquier proyecto de ingeniería de software es la comunicación con el cliente / usuario.

En esencia, el desarrollador (analista), debe elaborar un mecanismo efectivo para definir y negociar los requerimientos básicos para el proyecto.

Una vez que esto se ha alcanzado, comienza el análisis de requerimientos.

Existen dos opciones en esta etapa:



a) Crear un prototipo que apoyará al desarrollador y al cliente en un mejor entendimiento del sistema a construir.

b) Crear un modelo de análisis detallado que describe los datos, las funciones y el comportamiento del sistema.

El análisis puede realizarse aplicando varios métodos distintos, los cuales comparten un conjunto de principios, los principios del análisis.

1. Debe modelarse el dominio de datos del problema. Deben definirse objetos de datos (entidades) que son visibles al usuario del software, además de las relaciones existentes entre dichos objetos. También debe definirse el contenido de cada objeto de datos (atributos).

2. Debe modelarse el dominio funcional del problema. Las funciones del software, transforman los objetos de datos del sistema y pueden modelarse como una jerarquía, como servicios de clases en un sistema o cómo un conjunto de expresiones matemáticas.

3. Debe representarse el comportamiento del sistema. Todos los sistemas basados en computador responden a eventos externos que modifican como consecuencia su estado de operación. El modelo del comportamiento indica los estados observables externamente de un sistema y como ocurren las transiciones entre dichos estados.

4. Deben particionarse los modelos de datos, funciones y comportamiento. El problema se representa en una primera etapa en un alto nivel de abstracción. A medida que se progresa en la definición del problema, va refinándose y el nivel de abstracción disminuye. Esta actividad se denomina particionamiento.

5. La tendencia en el análisis debe ir de lo esencial a la implementación. A medida que el proceso de elaboración progresa, el planteamiento del problema va moviéndose desde una representación de lo esencial hacia una detallada especificación de la implementación. Esta progresión nos deja pasar desde el análisis al diseño.

Existen variadas técnicas, métodos y enfoques para enfrentar la etapa de análisis, pero puede decirse lo siguiente respecto a los métodos de análisis:

• Proveen una notación para describir los objetos de datos y las relaciones entre ellos.

• Permiten acoplar las funciones con los datos y proveen una forma para comprender cómo las funciones operan sobre los datos.

• Permiten representar en comportamiento a un nivel de sistema, y en algunos casos, en un nivel más específico.

• Soportan el enfoque del particionamiento que permite ir detallando de manera creciente.

5.7.4 Consideraciones en la Etapa de Desarrollo

Como el análisis, el diseño de software posee una serie de métodos para apoyarlo. Cada uno de ellos posee su propia notación y heurística para acompañar el desarrollo de este proceso, pero todos ellos se basan en una serie de principios.

1 Los Datos y los algoritmos que los manipulan deben crearse como un conjunto de abstracciones interrelacionadas.

Creando abstracciones de datos y procedimientos, los modelos de los componentes software poseen características que tienden a una alta calidad. Una abstracción es auto contenida, generalmente implementa una estructura de datos o algoritmo bien acotado, puede tener acceso a través de una interface



ProyectoFinal.doc

simple, los detalles de su operación interna no necesitan ser conocida para ser utilizada en forma efectiva, y es inherentemente reusable.

2 Los detalles internos del diseño de las estructuras de datos y los algoritmos deben ocultarse de otros componentes software que hacen uso de dichas estructuras de datos o algoritmos.

El ocultamiento de la información sugiere que los módulos sean caracterizados por decisiones de diseño que cada uno oculta de todos los demás. El ocultamiento implica que se puede alcanzar la modularidad efectiva definiendo un conjunto de módulos independientes que se comunican unos con otros pasando sólo aquella información que es necesaria para el funcionamiento del software. El uso de ocultamiento de la información como un criterio de diseño provee grandes beneficios cuando se requieren modificaciones (por ejemplo durante la evaluación, o más tarde, durante el mantenimiento). Debido a que la mayor parte de los datos y los procedimientos están ocultos para otras partes del software, los errores inadvertidos que se puedan introducir durante las modificaciones son menos propensos a propagarse a otros sitios del software.

3 Los módulos deben exhibir independencia.

Los módulos deben estar muy poco acoplados con otros módulos y del ambiente externo, además deben poseer cohesión funcional. El software con modularidad efectiva es más fácil de desarrollar debido a que las funciones pueden ser divididas y las interfaces simplificadas (considere las ramificaciones cuando el desarrollo es conducido por un equipo). Los módulos independientes son más fáciles de mantener y evaluar debido a que los efectos secundarios causados por las modificaciones del diseño y la codificación son limitados; la propagación de errores se reduce y hace posible la creación de los módulos reusables.

4 Los algoritmos deben diseñarse utilizando un conjunto restringido de constructores lógicos.

Este es un enfoque de diseño ampliamente conocido como programación estructurada, que fue propuesto para limitar el proceso del diseño de software a un número pequeño de operaciones predecibles. El uso de los constructores de la programación estructurada (secuencia, bifurcación e iteración), reduce la complejidad del programa, aumenta la legibilidad, evaluación y mantenimiento. El uso de un numero limitado de constructores lógicos también ayuda a la comprensión humana.

5.8 Laboratorio de inspección.

El éxito de un desarrollo depende de la calidad con qué fue hecho y de la velocidad con el mismo fue probado e inspeccionado.

Es recomendable y necesario realizar un minucioso trabajo de consultoría, investigación e ingeniería de software que redundandarán en productos que generan valor agregado al desarrollo.

Los recursos humanos deberán disponer de herramientas de integración y métodos para la conexión de sistemas heredados o distribuídos, así como con la capacidad para integrar soluciones de software de terceros.

Deberán trabajar con un esquema de trabajo y colaboración que permita tener un calificado equipo de programadores en diferentes ámbitos. De esta manera será posible ofrecer un estándar de calidad internacional a un precio razonable



6 Estándares y modelos de calidad en la Ingeniería de Software.

La estandarización es toda actividad documentada que norma el comportamiento de un grupo de personas. Los estándares dan los medios para que todos los procesos se realicen siempre de la misma forma, mientras surjan ideas para mejorarlos. Son guías para la productividad y la calidad.

Expectativas de los estándares:

• Mejora de procesos de software acorde a los objetivos estratégicos. • Mejora de los productos. • Protección del cliente o usuario. • Protección de la organización (cultura de la organización y mejora continua).

Existen varias organizaciones de estandarización internacional, algunas son regionales mientras que otras son globales. Las últimas están relacionadas con la ONU o son independientes, como por ejemplo la International Telecomunication Union (ITU)13.

La International Electrotechnical Commission (IEC) que fue fundada en el año 1906 para definir estándares en eléctrica y electrónica, mientras que la International Organization for Standarization (ISO) fue creada en 1947 para abarcar otros temas. Ambas tienen por objetivo facilitar el intercambio de bienes y servicios a nivel internacional, entre otras. En 1987, ISO e IEC decidieron formar el Joint Technical Comité (JTC), cuyo objetivo es elaborar estándares para la tecnología de información Information Technology (IT). El JTC, conocido también como JTC 1, ha creado 19 SCs que abarcan diversas áreas de IT13.

Organizaciones como la ISO, BOOTSTRAP, entre otras se han dedicado a crear modelos para mejorar la Calidad del Software, entre ellos tenemos:

• ISO. • Tick IT (Inglaterra). • CMM (Estados Unidos). • Bootstrap (Europa). • Trillium (Canadá). • ISO/SPICE (Australia ).

6.1 La Normas ISO 14.

La International Organization for Standardization (ISO) es una federación mundial de estándares integrada por más de 140 países.

Es una organización internacional no gubernamental creada en 1946: La misión de ISO es promover el desarrollo de normas y actividades relacionadas en el mundo encaminadas a facilitar el intercambio internacional de bienes y servicios, y para desarrollar la cooperación en la esfera de actividades intelectuales, científica, tecnológicas y económicas.

El trabajo de la ISO da lugar a los acuerdos internacionales que se publican como estándares internacionales.

Nombre de la ISO.

Mucha gente habrá notado una dislexia que aparece al utilizar el nombre oficial, International Organization for Standardization, y la forma corta, ISO ¿no deberían ser las siglas "IOS"? Sí, si son las siglas que no son.

De hecho, la "ISO" es una palabra, derivada de los isos griegos, significando el "igual", que es la raíz del prefijo "ISO -" que ocurre en un anfitrión de términos, tales como "isométrico" (de la medida o de dimensiones igual) y "isonomy" (igualdad de leyes, o de la gente antes de la ley).



ProyectoFinal.doc

Esta forma de pensar condujo de "igual" a "estándar", y a la opción de la "ISO" pues el nombre de la organización es fácil de seguir. Además, el nombre de la ISO se utiliza alrededor del mundo para referirse a la organización, así evitando la plétora de siglas resultando de la traducción del "International Organization for Standardization" en las diversas lenguas nacionales de los miembros, e.g. IOS en inglés, OIN en francés (de la organización internationale de normalisation). De cualquier forma en todos los países, la forma corta del nombre de la organización es siempre ISO.

6.1.1 La Normas ISO aplicables al Control en el Desarrollo de Software 14.

6.1.1.1 Estándares de Terminología.

ISO/IEC 2382-7:2000.

Information technology -- Vocabulary -- Part 7: Computer programming.

ISO/IEC 2382-20:1990.

Information technology -- Vocabulary -- Part 20: System development.

ISO 10005:1995.

Quality management -- Guidelines for quality plans.

ISO 10006:1997.

Quality management -- Guidelines to quality in project management.

ISO 10007:1995.

Quality management -- Guidelines for configuration management.

ISO 10011-1:1990.

Guidelines for auditing quality systems -- Part 1: Auditing.

ISO 10011-2:1991.

Guidelines for auditing quality systems -- Part 2: Qualification criteria for quality systems auditors.

ISO 10011-3:1991.

Guidelines for auditing quality systems -- Part 3: Management of audit programmes.

ISO/IEC TR 15504-9:1998.

Information technology -- Software process assessment -- Part 9: Vocabulary.

ISO/IEC TR 16326:1999.

Software engineering -- Guide for the application of ISO/IEC 12207 to project management.

ISO/IEC TR 9294:1990.

Information technology -- Guidelines for the management of software documentation.

ISO/IEC TR 10176:2001.

Information technology -- Guidelines for the preparation of programming language standards.

ISO 9000-3:1997.



Quality management and quality assurance standards -- Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software.

ISO/IEC TR 14471:1999.

Information technology -- Software engineering -- Guidelines for the adoption of CASE tools.

ISO/IEC TR 15504-1:1998.

Information technology -- Software process assessment -- Part 1: Concepts and introductory guide.

ISO/IEC TR 15504-2:1998.

Information technology -- Software process assessment -- Part 2: A reference model for processes and process capability.

ISO/IEC TR 15504-3:1998.

Information technology -- Software process assessment -- Part 3: Performing an assessment.

ISO/IEC TR 15504-4:1998.

Information technology -- Software process assessment -- Part 4: Guide to performing assessments.

ISO/IEC TR 15504-5:1999.

Information technology -- Software Process Assessment -- Part 5: An assessment model and indicator guidance.

ISO/IEC TR 15504-6:1998.

Information technology -- Software process assessment -- Part 6: Guide to competency of assessors.

ISO/IEC TR 15504-7:1998.

Information technology -- Software process assessment -- Part 7: Guide for use in process improvement.

ISO/IEC TR 15504-8:1998.

Information technology -- Software process assessment -- Part 8: Guide for use in determining supplier process capability.

6.1.1.2 Estándares de Proceso.

ISO/IEC 8652:1995.

Information technology -- Programming languages -- Ada (available in English only).

ISO/IEC TR 10182:1993.

Information technology -- Programming languages, their environments.

ISO/IEC 11404:1996.

Information technology -- Programming languages, their environments and system software interfaces -- Language-independent datatypes.

ISO/IEC 11411:1995.

Information technology -- Representation for human communication of state transition of software (available in English only).



ProyectoFinal.doc

ISO/IEC 12207:1995.

Information technology -- Software life cycle processes.

ISO/IEC 13751:2001.

Information technology -- Programming languages, their environments and system software interfaces -- Programming language Extended APL.

ISO/IEC 13816:1997.

Information technology -- Programming languages, their environments and system software interfaces -- Programming language ISLISP.

ISO/IEC 13817-1:1996.

Information technology -- Programming languages, their environments and system software interfaces -- Vienna Development Method -- Specification Language -- Part 1: Base language.

ISO/IEC 14143-1:1998.

Information technology -- Software measurement -- Functional size measurement -- Part 1: Definition of concepts.

ISO/IEC TR 14369:1999.

Information technology -- Programming languages, their environments and system software interfaces -- Guidelines for the preparation of Language-Independent Service Specifications (LISS).

ISO/IEC 14496-5:2001.

Information technology -- Coding of audio-visual objects -- Part 5: Reference software (available in English only).

ISO/IEC 14764:1999.

Information technology -- Software maintenance.

ISO/IEC TR 15846:1998.

Information technology -- Software life cycle processes -- Configuration Management.

ISO/IEC 15910:1999.

Information technology -- Software user documentation process.

6.1.1.3 Estándares de Producto.

ISO 9127:1988.

Information processing systems -- User documentation and cover information for consumer software packages.

ISO/IEC 8652:1995/Cor 1:2001.

(available in English only).

ISO/IEC 9126-1:2001.

Software engineering -- Product quality -- Part 1: Quality model (available in English only).

ISO/IEC 9126-1:

Information technology - Software quality characteristics and metrics - Part 1: Quality characteristics and subcharacteristics.



ISO/IEC 9126-2:

Information technology - Software quality characteristics and metrics - Part 2: External metrics.

ISO/IEC 9126-3:

Information technology - Software quality characteristics and metrics - Part 3: Internal metrics.

ISO/IEC 9126-4:

Software Product Quality - Part 4: Quality in use metrics.

ISO/IEC 10164-18:1997.

Information technology -- Open Systems Interconnection -- Systems Management: Software management function.

ISO/IEC TR 12182:1998.

Information technology -- Categorization of software.

ISO/IEC 14598-1:1999.

Information technology -- Software product evaluation -- Part 1: General overview.

ISO/IEC 14598-2:2000.

Software engineering -- Product evaluation -- Part 2: Planning and management.

ISO/IEC 14598-3:2000.

Software engineering -- Product evaluation -- Part 3: Process for developers.

ISO/IEC 14598-4:1999.

Software engineering -- Product evaluation -- Part 4: Process for acquirers.

ISO/IEC 14598-5:1998.

Information technology -- Software product evaluation -- Part 5: Process for evaluators.

ISO/IEC 14756:1999.

Information technology -- Measurement and rating of performance of computer-based software systems.

ISO/IEC TR 14759:1999.

Software engineering -- Mock up and prototype -- A categorization of software mock up and prototype models and their use.

ISO/IEC 15026:1998.

Information technology -- System and software integrity levels.

6.1.1.4 Estándares de Recurso y Tecnologías.

ISO/IEC TR 11172-5:1998.

Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 5: Software simulation (available in English only).

ISO/IEC TR 13233:1995.



ProyectoFinal.doc

Information technology -- Interpretation of accreditation requirements in ISO/IEC Guide 25 -- Accreditation of Information Technology and Telecommunications testing laboratories for software and protocol testing services (available in English only).

ISO/IEC TR 13818-5:1997.

Information technology -- Generic coding of moving pictures and associated audio information -- Part 5: Software simulation (available in English only).

ISO/IEC 15068-2:1999.

Information technology -- Portable Operating System Interface (POSIX) System Administration -- Part 2: Software Administration.

ISO/TR 15497:2000.

Road vehicles -- Development guidelines for vehicle based software (available in English only).

6.2 Estándares de la IEEE.

La IEEE es una organización profesional técnica no lucrativa, con más de 377.000 miembros en 150 países. El nombre completo es Institute of Electrical and Electronics Engineers, Inc., aunque la organización es más conocidad por las siglas IEEE.

A través de sus miembros, la IEEE es una autoridad principal en las áreas técnicas que se comprenden la Ingeniería en Computación, la Tecnología Biomédica las Telecomunicaciones, la Energía Eléctrica, el Espacio Aéreo, la Electrónica, entre otras.

Con su publicar técnico, conferencias y actividades consenso-basadas de los estándares, el IEEE.

• Produce el 30 por ciento de la literatura publicada en el mundo sobre Ingeniería Eléctrica, computadoras y tecnología del control, .

• Imparte anualmente más de 300 conferencias importantes y. • Tiene casi 900 estándares activos además de 700 bajo desarrollo.

6.2.1 Estándares de la IEEE aplicables al Control en el Desarrollo de Software 15.

6.2.1.1 Estándares de Terminologías.

IEEE Std 610.12-1990.

IEEE Standard Glossary of Software Engineering Terminology.

IEEE Computer Dictionary Project 610.

(P610) - This is the Institute of Electrical and Electronics Engineers (IEEE) Standard Computer Dictionary which consolidates the current standards based on individual specialties. This standard replaces existing "glossaries" (e.g., 610.12-1990). It attempts to create a common vocabulary for software professionals. For more information, see: http://grouper.ieee.org/groups/610/p610home.html.

IEEE Std 1062, 1998 Edition,.

IEEE Recommended Practice for Software Acquisition.

IEEE Std 1220-1998,.

IEEE Standard for the Application and Management of the Systems Engineering Process.

IEEE Std 1228-1994.

IEEE Standard for Software Safety Plans.



IEEE Std 1233, 1998 Edition,.

IEEE Guide for Developing System Requirements Specifications.

IEEE Std 1362-1998,.

IEEE Guide for Information Technology--System Definition--Concept of Operations Document.

ISO/IEC 12207:1995.

IEEE/EIA 12207 is the US standard set that implements the ISO/IEC standard.

• The US Standard has the following parts: - IEEE/EIA Std 12207.0-1996, Software life cycle processes. - IEEE/EIA Std 12207.1-1997, Software life cycle processes--Life cycle

data. - IEEE/EIA Std 12207.2-1997, Software life cycle processes--

Implementation considerations.

• These standards replace MIL-STD-498 (and previous standards).This military standard was submitted to IEEE and EIA as an US industry standard and then proposed as an (international) standard. It satisfies MIL-Q-9858A (Quality Program Requirements) and ISO9000 (Quality Systems) for software. 12207 was adopted for use by DoD on May 27,1998.MIL-STD-498 is available to download in multiple formats from http://sepo.spawar.navy.mil/498.html.

• see also TR15271 - Guide for ISO/IEC 12207.

6.2.1.2 Estándares de Proceso.

IEEE Std 730-1998,.

IEEE Standard for Software Quality Assurance Plans.

IEEE Std 730.1-1995,.

IEEE Guide for Software Quality Assurance Planning.

IEEE Std 828-1998,.

IEEE Standard for Software Configuration Management Plans.

IEEE Std 1008-1987 (Reaff 1993),.

IEEE Standard for Software Unit Testing.

IEEE Std 1012-1998,.

IEEE Standard for Software Verification and Validation.

IEEE Std 1012a-1998,.

Supplement to IEEE Standard for Software Verification and Validation: Content Map to IEEE/EIA 12207.1-1997.

IEEE Std 1028-1997,.

IEEE Standard for Software Reviews.

IEEE Std 1042-1987 (Reaff 1993),.

IEEE Guide to Software Configuration Management.

IEEE Std 1045-1992,.

IEEE Standard for Software Productivity Metrics.

IEEE Std 1058-1998,.



ProyectoFinal.doc

IEEE Standard for Software Project Management Plans.

IEEE Std 1059-1993,.

IEEE Guide for Software Verification and Validation Plans.

IEEE Std 1074-1997,.

IEEE Standard for Developing Software Life Cycle Processes.

IEEE Std 1219-1998,.

IEEE Standard for Software Maintenance.

IEEE Std 1490-1998,.

IEEE Guide--Adoption of PMI Standard--A Guide to the Project Management Body of Knowledge.

6.2.1.3 Estándares de Producto.

IEEE Std 982.1-1988,.

IEEE Standard Dictionary of Measures to Produce Reliable Software.

IEEE Std 982.2-1988,.

IEEE Guide for the Use of Standard Dictionary of Measures to Produce Reliable Software.

IEEE Std 1061-1998,.

IEEE Standard for Software Quality Metrics Methodology.

IEEE Std 1063-1987 (Reaff 1993),.

IEEE Standard for Software User Documentation.

IEEE Std 1465-1998,.

IEEE Standard Adoption of International Standard ISO/IEC 12199:1994 (E) --Information Technology--Software packages--Quality requirements and testing.

6.2.1.4 Estándares de Recursos y Teconolgía.

IEEE Std 829-1998,.

IEEE Standard for Software Test Documentation.

IEEE Std 830-1998,.

IEEE Recommended Practice for Software Requirements Documentation.

IEEE Std 1016-1998,.

IEEE Recommended Practice for Software Design Descriptions.

IEEE Std 1044-1993,.

IEEE Standard Classification for Software Anomalies.

IEEE Std 1044.1-1995,.

IEEE Guide to Classification for Software Anomalies.

IEEE Std 1320.1-1998,.

IEEE Standard for Functional Modeling Language--Syntax and Semantics for IDEF0.

IEEE Std 1320.2-1998,.



IEEE Standard for Conceptual Modeling Language--Syntax and Semantics for IDEF1X97(IDEFobject).

IEEE Std 1348-1995,.

IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools.

IEEE Std 1420.1-1995,.

IEEE Standard for Information Technology--Software Reuse--Data Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM).

IEEE Std 1420.1a-1996,.

Supplement to the IEEE Standard for Information Technology--Software Reuse--Data Model for Reuse Library Interoperability: Asset Certification Framework.

IEEE Std 1430-1996,.

IEEE Guide for Information Technology--Software Reuse--Concept of Operations for Interoperating Reuse Libraries.

IEEE Std 1462-1998,.

IEEE Standard Adoption of ISO/IEC 14102:1995--Information Technology--Guidelines for the Evaluation and Selection of CASE Tools.

6.3 El modelo Tickt IT.

El Departamento de Comercio e Industria del Reino Unido (DTI: Department of Trade and Industry) creó el esquema Tick IT. Los objetivos primordiales de éste fueron, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad, dando la dirección y guías necesarias para tal efecto. Aunque el proyecto original estuvo a cargo del DTI1, la responsabilidad actual por el esquema Tick IT se pasó a DISC, que es una oficina dependiente de British Standards Institution (BSI) Standards Division, siendo esta última la única autoridad en el Reino Unido para publicar estándares.

Un sistema de calidad típico Tick IT deberá contener los elementos que se enlistan a continuación:

6.3.1 Ciclo de vida del software.

• Elaboración de propuestas y revisión de contratos asegurando que todos los requerimientos estén bien especificados y de que la organización tiene la capacidad para cumplirlos.

• Análisis y especificación de los requerimientos del sistema asegurando que sean revisados y acordados con el cliente.

• Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de problemas potenciales.

• Planeación de la calidad del proyecto, especificando las inspecciones, revisiones y pruebas requeridas durante el desarrollo.

• Inspecciones de los productos contra estándares y requerimientos aplicables y las acciones correctivas correspondientes.

• Diseño de primer nivel identificando los componentes principales y los requerimientos que satisfacen.

• Diseño detallado de todos los componentes e interfaces, construcción, y prueba de los mismos verificando que satisfagan la especificación.

• Integración, pruebas e inspecciones del sistema, demostrando que el sistema integrado funciona correctamente y satisface su especificación.



ProyectoFinal.doc

• Identificar, segregar, investigar y corregir productos no conformes. • Auditorias, pruebas e inspecciones de aceptación del sistema demostrando al

cliente que el sistema satisface los requerimientos. • Almacenamiento, replicación, envío e instalación, asegurando la integridad y

seguridad de los productos, así como el cumplimiento de los compromisos adquiridos con el cliente.

• Puesta en marcha y liberación del producto para disponibilidad del cliente. • Entrenamiento a usuarios en el uso del sistema de tal manera que pueda operarlo

y beneficiarse completamente del mismo con la mínima intervención del proveedor.

• Mantenimiento o sustitución del sistema, asegurando que se continúa operando en conformidad con los requerimientos del cliente o usuario.

• Soporte a clientes de acuerdo a lo especificado en el contrato.

6.3.2 Soporte y aseguramiento de calidad. • Establecer políticas y objetivos de calidad generales de la organización que

sirvan para alinearla en todas sus actividades, procedimientos y políticas específicas.

• Implantar y mantener un sistema de aseguramiento de calidad. • Auditorías, revisiones y acciones correctivas al sistema de calidad que aseguren

que el sistema cumple con los requerimientos, es utilizado y que es efectivo en el logro de resultados.

• Definir, recolectar y analizar datos de calidad para evaluar la efectividad del sistema de calidad e identificar mejoras potenciales.

• Administración de la organización y los proyectos de tal forma que facilite los resultados de calidad.

• Administración de la configuración que identifique y controle, de manera continua, las partes constituyentes y sus versiones, de cada instancia de un sistema o subsistema.

• Respaldos, seguridad y almacenamiento que protejan contra cualquier pérdida o corrupción.

• Sistema de control de registros y documentación para todas las actividades de aseguramiento de calidad, de los proyectos y de soporte, incluyendo procedimientos y registros.

• Especificación y control del proceso de desarrollo incluyendo técnicas, prácticas, convenciones, estándares, mediciones y estadísticas.

• Proceso de compras, incluyendo identificación, selección, adquisición y aceptación que asegure que los bienes y servicios adquiridos sean como se requiere y de calidad aceptable.

• Control de productos incluidos, equipo y herramientas utilizadas: Hardware o Software, adquiridos o suministrados por el cliente, incluyendo utilización, configuración, seguridad.

• Entrenamiento, reclutamiento y desarrollo de personal que asegure su competencia y motivación, y disminuya su rotación.

6.4 El modelo CMM16.

A principios de los años 80’s el Departamento de Defensa de los Estados Unidos enfocó sus tareas a la revisión de los problemas del software y a su mejoramiento. Para contribuir a este programa se creó el Instituto de Ingeniería de Software (SEI) a finales de 1984. Como parte de su trabajo, el Instituto se dio a la tarea de desarrollar el Modelo de Madurez del Proceso de Software y para 1986 se comenzó el Proyecto de Evaluación de la Capacidad del Software. Después de varios años de realizar cuestionarios, evaluaciones, consulta e investigación, junto a otras organizaciones, en 1991 SEI produce el Modelo de Capacidad y Madurez del Software.



El Modelo de Capacidad y Madurez del Proceso de Software (CMM) ayuda a las organizaciones a producir de manera consistente y predecible productos de calidad superior. La capacidad del proceso es la habilidad inherente para producir los resultados planeados. El principal objetivo de un proceso de software maduro es el de producir productos de calidad que cumplan los requerimientos del usuario. Cuando se habla de madurez se entiende como el crecimiento alcanzado en la capacidad del proceso de software y que se considera como una actividad a largo plazo.

En una organización de software inmadura el proceso de software es generalmente improvisado, no existen planes rigurosos, se enfocan en resolver las crisis que se le presentan, carecen de bases objetivas para enjuiciar la calidad de los productos o para resolver los problemas. Por lo contrario cuando la organización alcanza cierto grado de madurez posee una gran habilidad para administrar el proceso de desarrollo y mantenimiento del software, se hacen pruebas y análisis de costo-beneficio para mejorar el proceso, el administrador monitorea la calidad del producto y la satisfacción del cliente, se llevan registros y todos los integrantes están involucrados.

El proceso de software puede ser definido como el conjunto de actividades, métodos, prácticas y transformaciones que las personas usan para el desarrollo y mantenimiento del software y de los productos asociados. La capacidad del proceso de software describe el rango de resultados esperados que se obtienen siguiendo un proceso de software, mientras que el desempeño del proceso de software representa los resultados reales obtenidos. La madurez del proceso de software esta dada cuando un proceso en específico es explícitamente definido, administrado, medido, controlado y es efectivo.

El ciclo Shewhart propone las bases para el trabajo de mejoramiento del proceso. Este consta de 4 pasos que se repiten en forma de ciclo hasta que la implantación produce los resultados esperados y los cambios pasan a ser permanentes.

Los pasos son:

1. Planear.

• Definir el problema. • Establecer los objetivos a mejorar.

2. Ejecutar.

• Identificar las posibles causas de problemas. • Establecer las bases. • Probar los cambios.

3. Revisar.

• Recolectar los datos. • Evaluar los datos.

4. Actuar.

• Implementar los cambios. • Determinar la efectividad.

Basado en estos principios se creó el modelo CMM que permite obtener un incremento gradual en la capacidad del proceso. El modelo describe los principios y prácticas relacionadas con la madurez del proceso de software y se propone ayudar a las organizaciones dedicadas a su desarrollo y a alcanzar la madurez de su proceso en términos del tránsito evolutivo desde un proceso improvisado y caótico a uno maduro con una adecuada disciplina y mayor capacidad.

CMM es un modelo descriptivo en el sentido que describe los atributos esenciales que se espera caractericen una organización dentro de un nivel de madurez en particular. Es un modelo normativo ya que las prácticas detalladas caracterizan el tipo normal de



ProyectoFinal.doc

comportamiento que se espera de una organización que realiza proyectos a gran escala. No es prescriptivo ya que no dice a la organización como mejorar.

6.4.1 Estructura del modelo.

.

El modelo consta de 5 niveles, diseñados de forma que los inferiores proveen unos fuertes cimientos incrementados de manera progresiva sobre los que se construyen los niveles superiores.

Estas 5 etapas de desarrollo son referidas como niveles de madurez y en cada una la organización alcanza una capacidad en el proceso superior.

Los 5 niveles del modelo son:

1. Inicial: el proceso de software es un proceso improvisado y caótico. Pocos procesos están definidos y el éxito que se pueda obtener depende de las habilidades, conocimientos y motivaciones del personal. No existen calendarios ni costos estimados por lo que las funcionalidades y calidad del producto son impredecibles. No existe un ambiente estable para el desarrollo y mantenimiento del software. El proceso del software es impredecible por el continuo cambio o modificación a medida que avanza el trabajo.

2. Repetible: se establecen procedimientos de administración del proceso básico para determinar costos, calendarios y funcionalidades. Se establecen las políticas para la administración del proceso y los procedimientos de implantación. El proceso se basa en repetir éxitos anteriores en proyectos de similares características, por lo que los mayores riesgos se presentan cuando se enfrentan a nuevos proyectos. Se exhiben problemas de calidad y carecen de una adecuada estructura para mejorarla.

3. Definido: el proceso de software para las actividades administrativas y técnicas está documentado, homogeneizado e integrado en un proceso de software estándar dentro de la organización, que ayudará a obtener un desempeño más efectivo. El grupo que trabaja en el proceso enfoca y guía sus esfuerzos al mejoramiento de su desarrollo, facilita la introducción de técnicas y métodos e informa a la administración del estado del proceso. La capacidad del proceso



está basada en una amplia comprensión común dentro de la organización de las actividades, roles y responsabilidades definidas en el desarrollo de software.

4. Administrativo: se recolectan medidas detalladas del proceso de software y de la calidad del producto. Ambos son cuantitativamente entendidos y controlados. El ciclo de Shewhart es constantemente utilizado para planear, implementar y registrar las mejoras al proceso. Este nivel de capacidad permite a la organización predecir las tendencias en la calidad del producto dentro de los límites establecidos y tomar las acciones necesarias en caso que sean excedidos. Los productos de dicha categoría son predeciblemente de alta calidad.

5. Optimización: el mejoramiento continuo del proceso es garantizado por la retroalimentación cuantitativa y desde las pruebas de técnicas y herramientas innovadoras. La organización tiene los medios para identificar los puntos débiles y conocer como fortalecerlos. Su actividad clave es el análisis de las causas de defectos y su prevención.

6.4.2 Áreas claves del proceso.

Cada nivel sirve de base para que los niveles sucesores hagan una eficiente y efectiva implantación del proceso. La organización puede, sin embargo, de forma provechosa usar procesos descritos en niveles superiores. Saltar niveles es contra productivo debido a que cada nivel es básico para obtener el próximo; la capacidad de poder implementar procesos de niveles superiores de madurez no implica que éstos puedan ser saltados.

Cada nivel de madurez está compuesto de varias áreas claves del proceso. Cada área clave es organizada en 5 secciones definidas como características comunes. Las características comunes especifican las prácticas claves para el cumplimiento de las metas en el área clave del proceso. Estas características son:

1. Compromiso a desarrollar: describe las acciones que la organización debe tomar para establecer el proceso y que pueda ser soportado.

2. Habilidad a desarrollar: describe las precondiciones que deben existir en el proyecto u organización para implementar la competitividad del proceso de software.

3. Actividades desarrolladas: describe los roles y procedimientos necesarios para implementar un área clave del proceso.

4. Mediciones y Análisis: describe las necesidades de medir el proceso y analizar los resultados.

5. Verificación de la implantación: describe los pasos para asegurar que las actividades se desarrollan de acuerdo con lo establecido en el proceso.

Cada área clave del proceso está descrita en términos de prácticas claves que contribuyen a satisfacer sus metas. Estas prácticas describen la infraestructura y actividades que más contribuyen a la efectiva implantación e institucionalización de las áreas claves del proceso.

Excepto para el nivel 1, cada nivel de madurez es descompuesto en varias áreas claves que indican el área en la organización hacia la cual debe enfocarse el mejoramiento del proceso de software, identifican las políticas que deben seguirse para obtener un nivel de madurez y describen como la organización madura. Cada área clave del proceso identifica un grupo de actividades relacionadas que, cuando se desarrollan de forma colectiva, permiten lograr una serie de objetivos considerados importantes para ampliar la capacidad del proceso.



ProyectoFinal.doc

Cuando las metas que propone el área son cumplidas, la organización puede afirmar que se ha institucionalizado la capacidad del proceso caracterizada por esa área clave. Las metas indican el alcance, las fronteras y la intención para cada área clave.

6.4.2.1 Áreas claves del proceso para el Nivel 2.

1. Requerimientos de la Dirección: el propósito es establecer una comprensión común entre el usuario y sus requerimientos para el proyecto que será dirigido por el proceso de software.

2. Planificación del Proyecto de Software: su propósito es establecer los planes razonables para el correcto desempeño de la parte de Ingeniería de Software y la dirección del proceso de software.

3. Seguimiento y Supervisión del Proyecto de Software: se requiere proveer una adecuada visibilidad del progreso real de forma que la dirección pueda tomar las acciones efectivas cuando el desarrollo del proyecto se desvía significativamente de lo planeado.

4. Administración de los Suministradores de Software: debe seleccionar suministradores de software calificados y administrarlos efectivamente.

5. Aseguramiento de la Calidad del Software: su propósito es suministrar a la administración la visibilidad adecuada dentro del proceso para revisar el proyecto y los productos que se realizan.

6. Administración de la Configuración del Software: establece y mantiene la integridad de los productos del proyecto de software a lo largo del ciclo de vida de éste.


1. Enfoque del Proceso de la Organización: su propósito es establecer la responsabilidad de la organización con las actividades del proceso de software que mejoran la capacidad de la misma.

2. Definición del Proceso de la Organización: desarrollar y mantener un conjunto reusable de procesos de software que mejoren el desempeño a través de los proyectos y aporten las bases para el beneficio acumulativo a largo plazo de la organización.

3. Programa de Entrenamiento: su propósito es desarrollar las habilidades y el conocimiento del personal de forma tal que puedan desempeñar sus roles de manera efectiva y eficiente.

4. Administración del Software Integral: se compone por las actividades de ingeniería de software y la dirección en un proceso de software coherente y definido que es ajustado del estándar y de los procesos relacionados, que son descritos en la Definición del Proceso de la Organización.

5. Ingeniería del Producto de Software: su objetivo radica en desarrollar un proceso de ingeniería bien definido que integre todas las actividades de ingeniería de software para elaborar un producto correcto y consistente de forma efectiva y eficiente.

6. Coordinación Intergrupal: establece un medio para que los grupos de ingeniería de software participen activamente con los demás grupos de ingeniería de forma que el proyecto sea más capaz de satisfacer las necesidades del cliente de manera eficiente y efectiva.

7. Revisiones por pares (Peer Reviews): su intención es eliminar los defectos del producto de software oportuna y eficientemente. Un importante efecto



consecuente es desarrollar una mejor comprensión del producto para que se puedan prevenir los defectos.


1. Administración Cuantitativa del Proceso: controla el desarrollo del proceso de software de forma cuantitativa, es decir, los resultados reales obtenidos del seguimiento.

2. Administración de la Calidad del Software: desarrollar una comprensión cuantitativa de la calidad de los productos de software del proyecto y obtener las metas especificadas.


1. Prevención de defectos: Identificar las debilidades y prevenirlas para que no vuelvan a ocurrir.

2. Administración del Cambio Tecnológico: Se requiere identificar las nuevas tecnologías y registrarlas dentro de la organización en una manera ordenada.

3. Administración de los Cambios en el Proceso: Se busca mejorar continuamente el proceso de software usado en la organización con la intención de incrementar la productividad y disminuir el tiempo de desarrollo de los productos.

.

6.4.3 Utilización del modelo.

La estructura del CMM brinda un camino progresivo recomendado para las organizaciones dedicadas al desarrollo de software que quieren mejorar la capacidad de su proceso de software. De forma general se identifican 4 usos fundamentales:

1. Equipos de asesores, que usan el modelo para identificar los puntos fuertes y débiles en la organización.



ProyectoFinal.doc

2. Equipos de evaluación, que utilizan CMM para identificar el riesgo de seleccionar entre diferentes contratos de negocio y para monitorearlos.

3. Personal técnico y de dirección, que usa CMM para entender las actividades necesarias que ayuden a planear e implementar el programa de mejoramiento del proceso de software de la organización.

4. Grupo de mejoramiento del proceso, que lo emplean como guía para ayudarse a definir y mejorar el proceso de software en la organización.

6.5 El modelo BOOTSTRAP16.

El Instituto Bootstrap es una organización no lucrativa dedicada a la mejora continua del modelo de calidad de software llamado BOOTSTRAP, también tiene como propósito ayudar a la industria europea del software para mejorar su competitividad.

Bootstrap es un método para analizar, rediseñar y mejorar los procesos de negocio del desarrollo de software. Este se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un proceso de mejora y los instrumentos de evaluación.

6.5.1 El proceso de evaluación.

Su enfoque es evaluar el proceso, no el producto. Para eso se definen un conjunto de características para los procesos, provee un análisis cuantitativo, produce vistas analíticas, hace evidente fortalezas y debilidades, identifica áreas de mejora, provee recomendaciones y sugiere un plan de implementación.

El modelo define el paradigma Organización-Metodología-Tecnología que se usa en Bootstrap para los niveles de evaluación y agrupación de resultados.

El modelo Bootstrap se basa en evaluar las unidades de producción de software de la organización, a través de sus proyectos para hacer un cambio a toda la organización. Dentro de este proceso, hay cuatro etapas principales: preparación, ejecución de la evaluación, determinación del nivel de madurez y capacidades, y la presentación de resultados de la evaluación.

En la etapa de preparación se realizan las siguientes tareas:

a) un entrenamiento inicial para tener claros los objetivos.

b) se seleccionan los proyectos a ser evaluados para obtener la mejor cobertura de la UPS.

c) se define el personal de evaluación para minimizar la subjetividad

d) se define el personal a ser evaluado para obtener la mejor cobertura de los roles involucrados en los proyectos seleccionados y.

e) se hace el acuerdo de confidencialidad.

En la etapa de ejecución, las tareas son:

a) una breve reunión de apertura, para obtener un enfoque colaborativo con el personal a ser entrevistado;.

b) el llenado de los cuestionarios con características generales de la UPS;.

c) el llenado de los cuestionarios del proyecto elegido, incluyendo la evaluación de cómo el proceso de producción es aplicado;.

d) revisión preliminar de la evaluación y.

e) reunión final, con el enfoque de presentar los resultados de la evaluación y obtener el consenso para poder pasar a la fase de mejoras.



En la etapa de determinar el nivel de madurez y capacidades, es donde se califica cada pregunta con uno de 5 valores posibles: nulo, débil, regular, extenso o no aplica. Para cada atributo clave se obtiene un nivel de madurez, aplicando un algoritmo numérico, dando como resultado uno de estos niveles: 1-inicial, 2-repetible, 3-definido, 4- administrado o 5-optimizado. Estos niveles de madurez están subdivididos en cuatro, de forma que se obtenga una calificación más exacta. Los procesos de organización y metodología se califican de 1 a 5, mientras que el de tecnología se califica sólo con dos niveles A o B.

Como resultado de la evaluación, la organización recibe 2 reportes, uno con los resultados de la evaluación de la UPS y otro con los resultados del proyecto evaluado. El correspondiente a la UPS contiene información como: un resumen ejecutivo, los objetivos de la UPS, los puntos débiles y fuertes, un plan de acción recomendado, etc. El reporte del proyecto contiene: comentarios del proyecto actual detallando lo referente a la organización, metodología y tecnología, los niveles de madurez para el proyecto, el plan de acción recomendado, etc.

6.5.2 Uso de la base de datos de soporte.

Una de las características principales de Bootstrap es la base de datos con que cuenta para hacer análisis. Con esto se fundamenta el plan de mejoras, se pueden medir las adaptaciones a la metodología, se puede comparar contra la industria y se pueden establecer objetivos basándose en la competencia.

6.5.3 Proceso de mejora.

Otra parte importante de la metodología de Bootstrap, es el plan de mejora que sugiere. El proceso para obtener el plan de mejora es, primero evaluar las necesidades de la organización tomando en cuenta las mejoras deseadas e indicadores sobre calidad del producto y servicio, tiempo de desarrollo, costos y riesgos del producto y del proyecto. Enseguida hacer una revisión y análisis de resultados de la evaluación, tomando en cuenta las fortalezas y debilidades detectadas. Después definir las capacidades a mejorar, considerando un período entre 18 y 24 meses. Enseguida definir las prioridades de acuerdo a un análisis de impactos. Finalmente en base a las actividades definidas, modificar la organización y responsabilidades para iniciar el cambio, estableciendo un marco de tiempos para su desarrollo y evaluación.

6.5.4 Instrumentos para la evaluación.

El proceso de evaluación es apoyado por:

• Cuestionarios. • Herramienta para el registro y presentación de resultados, y. • Guías para los asesores.

Los cuestionarios son usados para dirigir las entrevistas, donde los asesores los llenan en base a discusión y análisis de material documentado. La mayoría de las preguntas están basadas en términos como: la existencia de un procedimiento formal, la existencia de metodología, la existencia de estándares, la disponibilidad de tecnología, recomendaciones de uso de la tecnología, desempeño de tareas en base a un procedimiento, responsabilidades en toma de decisiones, desempeño de un análisis sistemático de resultados, etc.

El software usado como herramienta para registrar y presentar los resultados tiene los siguientes componentes:



ProyectoFinal.doc

.

Donde el BootCollector registra los resultados de los cuestionarios; BootRetriever es para leer o guardar datos de la base de datos (BootBase); BootCounter es para calcular los niveles de madurez; BootAnalyzer es para mostrar e imprimir las vistas y niveles de madurez y el BootManager es para administrar la base de datos.

Las guías son para homogeneizar los criterios de calificación entre los asesores.

6.6 El Modelo ISO/SPICE16.

.

La Organización Internacional para la Estandarización (ISO) creó el grupo de trabajo WG 10 y le encomendó el desarrollo del estándar internacional de Valuación de Procesos de Software. El grupo de trabajo (Working Group) WG 10, el cual empezó a laborar en enero de 1993 bajo la dirección de Alec Dorling y Peter Simms. Y decidieron crear el proyecto SPICE Software Process Improvement and Capability Determination; la E de SPICE



correspondía, originalmente, a "evaluation" y fue cambiado porque en algunos idiomas se traducía equivocadamente.

Una de las características sobresalientes de este proyecto de estandarización es que incluyó un periodo de pruebas del estándar de 2 años. Es decir, antes de ser publicado como estándar se había estado ajustando por la práctica.

6.6.1 Arquitectura del modelo.

El modelo es tridimensional: la primera dimensión es funcional (procesos), la segunda de capacidades (niveles), y la tercera de adecuación o efectividad (calificaciones).

La dimensión PROCESO:

Está organizada jerárquicamente de la siguiente manera: CATEGORÍA DE PROCESOS, que agrupan procesos comunes; PROCESOS, que logran propósitos técnicos; PRÁCTICAS BÁSICAS, operaciones que conforman un proceso.

Las categorías definidas son: Cliente-Proveedor, Ingeniería, Proyecto, Organización y Soporte.

La dimensión CAPACIDAD:

Está organizada ordinalmente en niveles de capacidad y se han definido cinco niveles. En la versión 1.0 éstos niveles son: Desempeño informal, Planeación y seguimiento bien definido, Cuantitativamente controlado, Mejora continua. Está un área de cambio sustancial en la versión 2.0 (La versión 1.0 de los documentos ISO/SPICE se harán de dominio público como documentos históricos aún cuando ya habrán liberado la versión 2.0.).

La tercera dimensión es la CALIFICACIÓN:

El juicio mismo: ¿qué calificación le doy a este proceso en este atributo de capacidad?. Las escalas que se manejan son discretas de tipo: 0=No adecuado, 1=Parcialmente adecuado, 2=Muy Adecuado, 3=Totalmente Adecuado. Es precisamente al agregar las instancias, de productos y(o) procesos, que podemos obtener valores decimales.

6.6.2 Los elementos de evaluación.

Lo relevante de un juicio o una evaluación es su marco de valor(es) dentro del cual se hace el juicio y su fundamento. Para fundamentar un juicio es necesario presentar evidencia y atender a la recurrencia del evento.

6.6.2.1 Marco de valor.

El Modelo ISO/SPICE tiene un marco de valor explícito. En la dimensión funcional o de proceso: las "mejores prácticas". En la dimensión de capacidad: los atributos de proceso o prácticas genéricas que incrementarán la capacidad del proceso. Este es uno de los componentes más valiosos del estándar internacional.

6.6.2.2 Evidencia.

La evidencia para la evaluación será los productos producidos por las prácticas base. Éste es un enfoque de efectividad… "por sus frutos los conoceréis…". Cada producto tipo ha sido catalogado y sus características de calidad definidas. Este es otro elemento filosófico fundamental de ISO/SPICE: no es un modelo nominalista. Esto quiere decir que, para efectos de una evaluación según ISO/SPICE, un plan de pruebas será un plan de pruebas si, y sólo si, reúne las características de un plan de pruebas y no porque alguien le haya puesto el título "Plan de Pruebas" sin realmente serlo.



ProyectoFinal.doc

6.6.2.3 Recurrencia.

Por último el elemento recurrencia, para fundamentar un juicio o evaluación vendrá dada por la selección de instancias de proyectos o productos representativas, a juicio del Evaluador, de las capacidades reales del proceso de software.

Conceptualmente el modelo ISO/SPICE es un modelo inductivo en su parte funcional: de característica a producto, de producto a práctica, y de práctica a proceso. En su parte de capacidades es un modelo evolutivo. Es, en general, un modelo realista: va a ver los productos, es decir, la efectividad de los procesos no lo que está escrito en algún manual de calidad o de procesos. No es un modelo de evaluación organizacional sino de procesos. El fenómeno organizacional aparecerá en alguna categoría de los procesos o prácticas, y principalmente en niveles superiores de capacidad.

7 Metodología propuesta para Auditar el Desarrollo de Sistemas.

Se requieren varios pasos para realizar una auditoría. El auditor de sistemas deberá evaluar los riesgos globales y desarrollar un programa de auditoría que incluya objetivos de control y procedimientos de auditoría que deben satisfacer esos objetivos. El proceso de auditoría exige que el auditor de sistemas reúna evidencia, evalúe fortalezas y debilidades de los controles existentes basado en la evidencia recopilada, y que prepare un informe de auditoría que presente esos temas en forma objetiva a la gerencia. Asimismo, la gerencia de auditoría debe garantizar una disponibilidad y asignación adecuada de recursos para realizar el trabajo de auditoría además de las revisiones de seguimiento sobre las acciones correctivas emprendidas por la gerencia.

7.1 Planificación de la auditoría.

Una planificación adecuada es el primer paso necesario para realizar auditorías de sistemas eficaces. El auditor de sistemas debe comprender el ambiente del negocio en el que se ha de realizar la auditoría así como los riesgos del negocio y control asociado. A continuación se menciona algunas de las áreas que deben ser cubiertas durante la planificación de la auditoría:



7.1.1 Comprensión del negocio y de su ambiente.

Al planificar una auditoría, el auditor de sistemas debe tener una comprensión suficiente del ambiente total que se revisa. Debe incluir una visión general de las diversas prácticas comerciales y funciones relacionadas con el tema de la auditoría, así como los tipos de sistemas que se utilizan. El auditor de sistemas también debe comprender el ambiente normativo en el que opera el negocio. Por ejemplo, a un banco se le exigirá requisitos de integridad de sistemas de información y de control que no están presentes en una empresa manufacturera. Los pasos que puede llevar a cabo un auditor de sistemas para obtener una comprensión del negocio son: Recorrer las instalaciones de la empresa. Lectura de material sobre antecedentes que incluyan publicaciones sobre esa industria, memorias e informes financieros. Entrevistas a gerentes claves para comprender los temas comerciales esenciales. Estudio de los informes sobre normas o reglamentos. Revisión de planes estratégicos a largo plazo. Revisión de informes de auditorías anteriores.

7.1.2 Riesgo y materialidad de auditoría.

Se puede definir los riesgos de auditoría como aquellos focos rojos que la información pueda tener, como son errores materiales o aquellos que el auditor de sistemas no pueda detectar que han ocurrido. Los riesgos en auditoría se pueden clasificar de la siguiente manera:

Riesgo inherente: Cuando un error material no se puede evitar que suceda por que no existen controles compensatorios relacionados que se puedan establecer.

Riesgo de Control: Cuando un error material no puede ser evitado o detectado en forma oportuna por el sistema de control interno.

Riesgo de detección: Es el riesgo de que el auditor realice pruebas exitosas a partir de un procedimiento inadecuado.

El auditor puede llegar a la conclusión de que no existen errores materiales cuando en realidad los hay. La palabra "material" utilizada con cada uno de estos componentes o riesgos, se refiere a un error que debe considerarse significativo cuando se lleva a cabo una auditoría. En una auditoría de sistemas de información, la definición de riesgos materiales depende del tamaño o importancia del ente auditado así como de otros factores. El auditor de sistemas debe tener una comprensión cabal de estos riesgos de auditoría al planificar. Una auditoría tal vez no detecte cada uno de los potenciales errores en un universo. Pero, si el tamaño de la muestra es lo suficientemente grande, o se utiliza procedimientos estadísticos adecuados se llega a minimizar la probabilidad del riesgo de detección. De manera similar al evaluar los controles internos, el auditor de sistemas debe percibir que en un sistema dado se puede detectar un error mínimo, pero ese error combinado con otros, puede convertirse en un error material para todo el sistema. La materialidad en la auditoría de sistemas debe ser considerada en términos del impacto potencial total para el ente en lugar de alguna medida basado en lo monetario.

7.1.3 Técnicas de evaluación de Riesgos.

Al determinar que áreas funcionales o temas de auditoría deben auditarse, el auditor de sistemas puede enfrentarse ante una gran variedad de temas candidatos a auditar, el auditor de sistemas debe evaluar los posibles focos rojos y determinar cuales áreas consideradas de alto riesgo debe ser auditadas. Existen cuatro motivos por los que se utiliza la evaluación de riesgos, estos son:

• Permitir que la gerencia asigne recursos necesarios para la auditoría.

• Garantizar que se ha obtenido la información pertinente de todos los niveles gerenciales, y garantiza que las actividades de la función de auditoría se



ProyectoFinal.doc

dirigen correctamente a las áreas de alto riesgo y constituyen un valor agregado para la gerencia.

• Constituir la base para la organización de la auditoría a fin de administrar eficazmente el departamento.

• Proveer un resumen que describa como el tema individual de auditoría se relaciona con la organización global de la empresa así como los planes del negocio.

7.1.4 Objetivos de controles y objetivos de auditoría.

El objetivo de un control es anular un riesgo siguiendo la metodología, el objetivo de auditoría es verificar la existencia de estos controles que deben estar funcionando de manera eficaz, respetando las políticas y los objetivos de la empresa. Como ejemplo tenemos los siguientes objetivos de auditoría de sistemas:

• La información en los sistemas de información deberá estar resguardado al acceso indebido y se debe mantenerse actualizada.

• Cada transacción ejecutada en el sistema es autorizada y validada cada vez que se ejecuta.

• Los cambios a los programas deben ser debidamente aprobados y probados.

Los objetivos de auditoría se consiguen mediante los procedimientos de auditoría.

7.1.5 Procedimientos de auditoría.

• Algunos ejemplos de procedimientos de auditoría son: • Revisión de la documentación de sistemas e identificación de los controles

existentes. • Entrevistas con los especialistas técnicos a fin de conocer las técnicas y controles

aplicados. • Utilización de software de manejo de base de datos para examinar el contenido

de los archivos de datos. • Técnicas de diagramas de flujo para documentar aplicaciones automatizadas.

7.2 Desarrollo del programa de auditoría.

Un programa de auditoría es un conjunto documentado de procedimientos diseñados para alcanzar los objetivos de auditoría planificados. El esquema típico de un programa de auditoría incluye lo siguiente:

b. Tema de auditoría: Donde se identifica el área a ser auditada.

c. Objetivos de Auditoría: Donde se indica el propósito del trabajo de auditoría a realizar.

d. Alcances de auditoría: Aquí se identifica los sistemas específicos o unidades de organización que se han de incluir en la revisión en un período de tiempo determinado.

e. Planificación previa: Donde se identifica los recursos y destrezas que se necesitan para realizar el trabajo así como las fuentes de información para pruebas o revisión y lugares físicos o instalaciones donde se va auditar.

f. Procedimientos de auditoría: para:

• Recopilación de datos. • Identificación de lista de personas a entrevistar. • Identificación y selección del enfoque del trabajo. • Identificación y obtención de políticas, normas y directivas. • Desarrollo de herramientas y metodología para probar y verificar los controles

existentes.



• Procedimientos para evaluar los resultados de las pruebas y revisiones. • Procedimientos de comunicación con la gerencia. • Procedimientos de seguimiento.

El programa de auditoría se convierte también en una guía para documentar los diversos pasos de auditoría y para señalar la ubicación del material de evidencia. Generalmente tiene la siguiente estructura:

Hecho Procedimientos de

Auditoría Lugar

Papeles de Trabajo

Referencia Por Fecha

Los procedimientos involucran pruebas de cumplimiento o pruebas sustantivas, las de cumplimiento se hacen para verificar que los controles funcionan de acuerdo a las políticas y procedimientos establecidos y las pruebas sustantivas verifican si los controles establecidos por las políticas o procedimientos son eficaces.

7.3 Asignación de Recursos de auditoría.

La asignación de recursos para el trabajo de auditoría debe considerar las técnicas de administración de proyectos las cuales tienen los siguientes pasos básicos:

• Desarrollar un plan detallado: El plan debe precisar los pasos a seguir para cada tarea y estimar de manera realista, el tiempo teniendo en cuenta el personal disponible.

• Contrastar la actividad actual con la actividad planificada en el proyecto: debe existir algún mecanismo que permita comparar el progreso real con lo planificado. Generalmente se utilizan las hojas de control de tiempo.

• Ajustar el plan y tomar las acciones correctivas: si al comparar el avance con lo proyectado se determina avances o retrasos, se debe reasignar tareas. El control se puede llevar en un diagrama de Gantt.

.

Así mismo las hojas de control de tiempo son generalmente como sigue:

Hoja de Control de Tiempo Semanal.

Semana: del al Nombre: Registro:

General Detalle L Fecha

M Fecha

W Fecha

J Fecha

V Fecha

S Fecha

D Fecha

Auditoría 1 Actividad 1 Auditoría 1 Actividad 2 Auditoría 1 Actividad 3 Auditoría 1 Actividad 4



ProyectoFinal.doc

Auditoría 1 Actividad 5

Hecho por: Revisado por:

Los recursos deben comprender también las habilidades con las que cuenta el grupo de trabajo de auditoría, el entrenamiento y experiencia que estos tengan, así como tener en cuenta la disponibilidad del personal para la realización del trabajo de auditoría, como los períodos de vacaciones que estos tengan, otros trabajos que estén realizando, etc.

7.4 Técnicas de recopilación de evidencias.

La recopilación de material de evidencia es un paso clave en el proceso de la auditoría, el auditor de sistemas debe tener conocimiento de cómo puede recopilar la evidencia examinada. Algunas formas son las siguientes:

• Revisión de las estructuras organizacionales de sistemas de información.

• Revisión de documentos que inician el desarrollo del sistema, especificaciones de diseño funcional, historia de cambios a programas, manuales de usuario, especificaciones de bases de datos, arquitectura de archivos de datos, listados de programas, etc.; estos no necesariamente se encontrarán en documentos, si no en medios magnéticos para lo cual el auditor deberá conocer las formas de recopilarlos mediante el uso de computadoras.

• Entrevistas con el personal apropiado, las cuales deben tener una naturaleza de descubrimiento no acusatoria.

• Observación de operaciones y actuación de empleados, esta es una técnica importante para varios tipos de revisiones, para esto se debe documentar con el suficiente detalle como para presentarlo como evidencia de auditoría.

• Auto documentación, es decir el auditor puede preparar narrativas con base a su observación, diagramas de flujo, cuestionarios de entrevistas realizados. Aplicación de técnicas de muestreo para saber cuando aplicar un tipo adecuado de pruebas (de cumplimiento o sustantivas) por muestras.

• Utilización de técnicas de auditoría asistida por computador CAAT, consiste en el uso de software genérico, especializado o utilitario.

7.4.1 Errores en el levantamiento de la información.

El error puede ocurrir en varios puntos durante el levantamiento y el análisis de la información. Los auditados y los entrevistadores pueden aumentar el error cuando registran la información. El error también puede ser introducido al transferir la información desde los medios de reunión de la misma hacia las bases de datos.

Los mayores errores en la precisión de la información suceden en el registro inicial de la misma. Frecuentemente, la aparición de estos problemas durante la finalización del levantamiento de la información incluyen lo siguiente:

• Puntos no respondidos;

• Respuestas a puntos que podrían ser omitidas por el auditado, el entrevistador o el examinador de documentos;

• Respuestas inapropiadas debido a que los instrumentos de levantamiento de información o las instrucciones no han sido entendidos;

• Errores al introducir la información; o • Respuestas ilegibles.

Estos tipos de errores podrían tener las siguientes repercusiones:



• Debilidad en las instrucciones;

• Problemas en la estructura de los instrumentos de reunión de la información;

• Preguntas que son difíciles de responder para los auditados, que requieren una apreciación excesiva o son de naturaleza sensible; e

• Instrumentos de reunión de datos largos y complejos que reducen la motivación del auditado a contestar; etc.

El planeamiento de la inspección y el diseño de los instrumentos para el levantamiento de la información son importantes. El error en alguna de las fuentes puede reducirse a través de una cuidadosa planeación de la inspección y diseño de los instrumentos de levantamiento de la información. Instrucciones claras y completas, definiciones de los términos, claves usados en las preguntas y una atención cuidadosa a la estructura y el trazado de los instrumentos ayudaran a reducir puntos perdidos y respuestas inapropiadas. Los errores al introducir la información y las respuestas ilegibles pueden minimizarse si se incrementan la motivación y si se utilizan instrumentos que requieran respuestas simples tales como marcar cuadros con "SI" o "NO".

Los errores potenciales pueden ser detectados y oportunamente modificados si se pre-testea los instrumentos de reunión de la información.

El entrenamiento de los entrevistadores y los codificadores es vital. En entrevistas de inspección, el entrevistador puede incurrir en error al no entender al auditado o al transcribir incorrectamente la información de los formularios de la entrevista. En particular, los entrevistadores pueden intencionalmente o no influir en los resultados de las entrevistas. Investigaciones hechas han mostrado claramente que el entrevistador puede influenciar respuestas a través de una variedad de señales verbales y no verbales sutiles, aun cuando no exista tal intención. Por ejemplo, los auditados podrían tomar las sonrisas o las expresiones confirmatorias como "uh huh" de los entrevistadores como una señal de que el entrevistador quiere escuchar o creer.

Se debe temer más cuidado para prevenir el error en respuestas abiertas. Los entrevistadores pueden tener dificultades para registrar completa y adecuadamente las respuestas muy largas. Ellos deben juzgar cuando una pregunta ha sido adecuadamente respondida, tal vez realizando preguntas adicionales para aclarar o asegurar una respuesta completa. Estas circunstancias crean la oportunidad de prevención.

Minimizar estos problemas requiere una cuidadosa selección y entrenamiento de los entrevistadores.

Practicas de control de calidad. Profundizar con los auditados para verificar las respuestas en un sub-grupo de entrevista, tener un segundo entrevistador presente, hacer que el auditado verifique la trascripción de la entrevista, ayudara a evaluar la efectividad del entrenamiento, detectar la prevención y corregir los errores. La conducción de una prueba piloto ayudara a asegurar que la selección y el entrenamiento del entrevistador ha sido efectiva.

También se puede incurrir en error cuando la información obtenida de las entrevistas o documentos debe ser categorizada para facilitar el análisis. Obtener la información con las palabras propias del auditado o de documentos existentes y ubicarlos en categorías creadas por el auditor puede exigir un juicio considerable.

En estas circunstancias, puede reducirse el error teniendo cada documento o entrevista codificado por mas de una persona y entrenando a los codificadores para realizar juicios consistentes. En la auditoria de evaluación, cada informe es



ProyectoFinal.doc

revisado por dos auditores. En un grupo inicial de informes de evaluación, los evaluadores discuten sus juicios sobre cada informe hasta llegar a un acuerdo. Este proceso es repetido hasta que ellos están de acuerdo como mínimo en un 90% de sus decisiones sin discusión.

La información debe ser revisada. Es esencial revisar y editar cada cuestionario de levantamiento de información para identificar información inconsistente, incompleta o ilegible. Cuando sea posible, los auditados, los entrevistadores o las fuentes de información originales deberían ser contactadas para resolver la inconsistencia o la falta de terminación de la información. Cuando no es posible corregir estos problemas anteriores al análisis, los procedimientos estadísticos pueden ser usados algunas veces para estimarlos y corregirlos. Estos procedimientos estadísticos no son un sustituto de una información completa y precisa y requieren una experiencia considerable en su aplicación e interpretación.

Transferencia de información a las bases de datos. El error también puede ser introducido al transferir información desde los instrumentos de reunión de la misma hacia las bases de datos. Los errores pueden resultar de una mala interpretación de información difícil de leer, items perdidos, y un incorrecto acopio de la información.

A menudo, la información de los cuestionarios y las entrevistas en forma escrita son ingresadas en cuestionarios legibles en las maquinas. Instrucciones claras acerca de estas formas de acopio de la información son importantes para minimizar el error. Una vez ingresada, la información deberá ser verificada comparando un impreso de la misma con la del original. La verificación puede ser conducida sobre cada cuestionario individual o, en el caso de bases de datos muy extensas, a través de muestras estadísticas.

El error humano al transferir información a las bases de datos puede reducirse usando técnicas asistidas de computación. Estas técnicas incluyen ingresar la información directamente en cuestionarios legibles en las maquinas, o directamente en una computadora usando cuestionarios computarizados que permitan que las preguntas puedan ser transferidas a una base de datos mediante un software.

Análisis. Varios errores o deficiencias en el levantamiento de información pueden ser identificados durante el análisis. El examen de la distribución frecuente de las respuestas a preguntas individuales y la comparación de respuestas a diferentes preguntas puede revelar contradicciones y patrones inusuales que son debido a errores en la información original o debilidades en la transformación de la información en formularios analizables. Los responsables de llevar a cabo los análisis deberían permanecer alerta a estas posibilidades.

7.4.2 Pretesteo de los instrumentos de levantamiento de la información

El pre-testeo es la administración de los instrumentos de reunión de la información con un pequeño grupo de auditados de la población para una inspección en toda su extensión. Si ocurren problemas en el pre-testeo, es probable que otros similares aparezcan en una administración completa. El propósito del pre-testeo es identificar los problemas con los instrumentos de recolección de la información y encontrar posibles soluciones.

No es posible anticipar todos los problemas que serán encontrados durante la recolección de datos. La tecnología usada en los cuestionarios y entrevistas podría no ser entendida por los auditados y la información devuelta en los documentos podría no estar disponible pronto. La reducción del error a niveles aceptables requiere el pre-testeo de los instrumentos de reunión de información.

Como los procedimientos estandarizados son esenciales para asegurar que las afirmaciones generales pueden ser realizadas, es conveniente hacer tan pocos



ajustes como sean posibles a los instrumentos de reunión de información una vez que esta reunión de información haya iniciadado realmente.

Si el pre-testeo indica que hay una baja probabilidad de obtener información valida, coherente y pertinente para lograr los objetivos de la auditoria, estos los items deberían ser omitidos y otras técnicas de reunión de información deberían ser buscadas.

Principios para el pre-testeo. El pre-testeo debe ser dirigido en circunstancias que sean tan similares como sean posibles con relación a la reunión de información real y en miembros de una población tan parecidos como sea posible con aquellos que sean muestreados.

Deberían tomarse notas cuidadosas acerca de los problemas encontrados y soluciones posibles deberían ser identificadas.

Cuestionarios de pre-testeo. Un objetivo importante de los cuestionarios de pre-testeo es descubrir el pensamiento que se encuentra detrás de las respuestas para que el auditor pueda evaluar exactamente si los cuestionarios son respondidos apropiadamente; si las preguntas son entendidas realmente por los auditados y si las preguntas son acerca de lo que el auditor piensa que realmente son. El pre-testeo también ayuda a evaluar si los auditados son capaces y están dispuestos a dar la información necesaria.

En el pre-testeo, los auditados deberían completar los formularios dando sus puntos de vista durante o después de hacerlo. Un enfoque es dar los cuestionarios como si fuera una entrevista, pidiendo aclaraciones de las respuestas y aclarando las preguntas durante el proceso. Los puntos de vista de los auditados pueden ser obtenidos también durante una entrevista posterior al cuestionario o en un grupo fijo. Otro enfoque común es hacer que los auditados piensen en voz alta mientras contestan.

El pre-testeo permite al auditor responsable testear soluciones a problemas mediante el cuestionario. Por ejemplo, si se consideran diferentes redacciones para una pregunta, una puede ser usada con la mitad de la muestra pre-testeada y la segunda con el resto de la muestra para ver cual funciona mejor.

7.4.3 Desarrollo y verificación de los instrumentos de reunión de información

El termino "instrumentos de reunión de información" describe las herramientas usadas para reunir información como parte de una inspección. Un apropiado diseño de estos instrumentos es esencial para llegar a conclusiones confiables y validas. La información debe ser obtenida en una base comparable, a través de individuos si la intención es hacer afirmaciones agregadas o generales en la base de la información de la inspección. Esto es especialmente cierto cuando la intención es hacer afirmaciones cuantitativas generales acerca de una población mayor (por ejemplo X%, mejor, mas que, etc.). Si las preguntas o instrumentos difieren entre los individuos, o son interpretadas en forma diferente por diferentes miembros de un equipo auditor, la información no será confiable, y una afirmación general será injustificable.

El diseño adecuado y apropiado de los instrumentos es muy importante para la validez. En el caso de cuestionarios, la formulación de las preguntas, su vocabulario, su estructura y el orden en que están presentadas pueden tener un impacto importante en la pertinencia y exactitud de las respuestas y la seguridad de que las preguntas serán respondidas.

Por estas razones, los instrumentos usados en una inspección deberían ser planeados cuidadosamente y deberían formular un conjunto de preguntas estándar que puedan ser administradas en una forma uniforme a todos los auditados.



ProyectoFinal.doc

El desarrollo de cuestionarios y entrevistas estructuradas es tanto una destreza técnica como un arte. Por ejemplo, hay una gran cantidad de literatura que demuestra que el orden de las preguntas y su ubicación al comienzo o al final de un cuestionario puede tener efectos profundos en las respuestas recibida. Para algunos temas específicos tales como el entorno personal, hay una gran investigación del vocabulario y estructura de preguntas efectivas. Cualquiera que desarrolle un cuestionario o una entrevista estructurada necesita ser consciente de los principios básicos de diseño de cuestionarios, problemas técnicos y cualquier literatura técnica acerca del tema a ser inspeccionado. Por supuesto que también es esencial un conocimiento considerable del tema.

7.4.3.1 Cuestionarios.

Los cuestionarios se deberán desarrollar de forma tal que se pueda verificar el grado de cumplimiento de los criterios establecidos. De hecho cada criterio deberá generar una o más preguntas específicas.

De acuerdo al programa de desarrollo, es necesario recolectar la información de fuentes primarias el cual complementará la ya elaborada, y que al mismo tiempo, ayudará a concientizar sobre los beneficiarios del programa de desarrollo de la necesidad de llevar a cabo una evaluación final.

Para proceder a recolectar esta información es fundamental la selección idónea de las personas a entrevistar. Se deben elaborar cuestionarios distintos para llevar a cabo esta tarea, éstos cuestionarios deben contiener preguntas sobre los aspectos del programa de desarrollo. Además deben elaborarse con una metodología de autoevaluación que permita recolectar la valoración de los Grupos sobre el conjunto de los aspectos cualitativos del programa.

Ventajas. La ventaja central de los cuestionarios sobre las entrevistas es que en estos están permitidos para la recolección de información de un gran numero de individuos en forma realmente práctica. Lo práctico resulta de la necesidad de poco personal y, posiblemente, de los gastos de movilidad. El ahorro es más importante cuando se necesita una muestra grande.

Otra ventaja de los cuestionarios sobre las entrevistas es que estos contribuyen a la exactitud provocando una mayor coherencia. Esto se logra eliminando la variación en la interrogación que ocurre cuando se usa una gran cantidad de diferentes entrevistadores. Ellos también reducen la introducción de prevención al eliminar la capacidad de los entrevistadores a influenciar las respuestas tanto intencionalmente como inadvertidamente.

Desventajas. A diferencia de entrevistas de la inspección, los cuestionarios no dan una oportunidad a los auditores de clarificar las preguntas, verificar que estas sean entendidas, buscar su claridad o elaboración o asegurar que el auditado responda el formulario completo. Podría no haber oportunidad si toda la información necesaria para sustentar una conclusión no fue solicitada o prevista, o si se hace evidente que las preguntas no fueron claras. Tampoco es posible la mayoría de las veces buscar corroboración de las preguntas. En general, no se obtiene la misma profundidad en la información que resulta de los cuestionarios que la que se obtiene en las entrevistas. Sumado a eso, los auditados que son inspeccionados deben tener la capacidad requerida de leer y escribir.

Desarrollo del cuestionario. Por la dificultad de obtener o dar clarificación e información adicionales, es esencial el desarrollo cuidadoso del cuestionario para asegurar que las preguntas darán toda la información requerida, y que estas son claras y sin ambigüedad. En particular, es esencial que el auditor examine de cerca los objetivos de la auditoria para clarificar que puntos



específicos de información son requeridos que puedan ser obtenidos a través del enfoque del cuestionario.

Además, el desarrollo de cuestionarios de calidad requiere el conocimiento del área que será interrogada y la capacidad de los auditados de proporcionar la información requerida, también se requiere que el auditor entienda suficientemente la forma en que los auditados responden.

La cantidad de conocimiento anticipado es mayor cuando las preguntas cerradas (SI-NO, marque la opción, o escala de importancia) serán comparadas con las abiertas (completar en los espacios, respuestas cortas o párrafos). El uso eficaz de preguntas cerradas también requiere que la variedad de posibles respuestas pueda ser correctamente anticipada. Si los auditados no tienen el conocimiento requerido o si la terminología no esta claramente entendida o definida, hay un alto riesgo de respuestas incorrectas.

Por otro lado, las preguntas cerradas son más fáciles de recordar y analizar que las abiertas. El seleccionar entre un gran numero de respuestas para preguntas abiertas en las que los auditados podrían usar terminología diferente y podrían tener escritura ilegible seria tanto como una perdida de tiempo. Algunos cuestionarios trataran de procurar un equilibrio entre los dos tipos de preguntas.

Mecanismos de entrega de los cuestionarios. Los cuestionarios deben ser distribuidos personalmente, con el fin de que el personal seleccionada para la auditoría sea el que responda los mismos.

Para reducir tiempos en las entrevistas es recomendable:

• un cuestionario corto (una única pagina o menos) formulando directamente preguntas reales;

• un censo de población de menos de 100 ( las muestras representativas generalmente serian mayores)

• una población rápidamente identificable. • la probabilidad de un grado inicial de respuesta del 85% al 95%

(minimizando la cantidad de insistencia requerida) y , • auditados que estén motivados a responder rápidamente .

7.4.3.2 Entrevistas cara-a-cara estructuradas

Ventajas. Las entrevistas deberán ser más rápidas de conducir que los cuestionarios de inspección porque no es necesario agregar tiempo para contestar, recolectar la información y para que los auditados les presten atención. Una ventaja mayor es que ellas dan mas oportunidad de acceder al entendimiento de los auditados y a la interpretación de las preguntas y a clarificar cualquier confusión que surja acerca del significado de la pregunta o la respuesta. También dan la oportunidad de presentar material a los auditados para ver sus reacciones.

Los auditores deberían ser capaces de establecer una relación de credibilidad con el auditado y de solicitar respuestas a las preguntas a las que los auditados podrían ser de otro modo reacios a responder o responder verazmente.

Cuando menos se sabe acerca de la forma en que los auditados piensan sobre un problema o acerca del alcance de la posible respuesta, las entrevistas estructuradas crean la oportunidad de que los entrevistadores hagan preguntas suplementarias, cuando es necesario obtener respuestas adecuadas.



ProyectoFinal.doc

Desventajas. Sin embargo, las entrevistas también crean el potencial para que el entrevistador intencionalmente o no, influencie los resultados o viole la coherencia en medición. Los auditados serán sensibles a las indicaciones dadas por el comportamiento verbal y no-verbal del entrevistador. Por lo tanto un entrevistador debera hacer preguntas adicionales o hacer aclaraciones y podría influenciar indebidamente las respuestas.

Consecuentemente es esencial un adecuado entrenamiento del entrevistador. Este entrenamiento es necesario para asegurar que los entrevistadores entiendan las formas por las cuales ellos pueden influenciar inadvertidamente las respuestas; la importancia de no hacer esto y las técnicas apropiadas que pueden ser usadas para ayudar al auditado o lograr la información necesaria sin afectar la integridad de la entrevista.

Aunque podrían ser más rápidas que los cuestionarios, estas entrevistas son más costosas por la cantidad de tiempo requerido por el personal para conducir entrevistas y el costo del viaje.

7.4.3.3 Otras consideraciones

Aunque las entrevistas provean mas oportunidades de aclaración y elaboración de lo que hacen los cuestionarios, el diseño cuidadoso de instrumentos de reunión de información es aun critico para asegurar un enfoque estándar que dará información consistente de auditado a auditado. Las guías de entrevistas deben ser pre-testeadas.

Al elegir un enfoque, es importante considerar las características distintivas de la población a la que se esta tratando de evaluar. Aunque los entrevistadores sean capaces de generar credibilidad con algunos tipos de auditados, otros podrían sentirse mas cómodos con el mayor anonimato de los cuestionarios enviados por correo. Algunos podrían impacientarse con cuestionarios hechos en papel y preferir la facilidad de los enfoques electrónicos, mientras que otros podrían intimidarse por la tecnología. El pre-testeo puede asegurar la elección del enfoque mas apropiado.

7.5 Actividades de Validación y Verificación.

Una vez elaborados todos los cuestionarios y sometidos a algunas pruebas de validación para mejorar su comprensión, serán entregados a los auditados; grupos de desarrollo y Administración.

Una vez recogidas las sugerencias sobre posibles modificaciones del documento de metodología se iniciará la recolecta de información. Las visitas/entrevistas se realizarán a todos el personal seleccionado para la auditoría, además de, si se considera necesario, al personal técnico y administrativo. La duración prevista será de tres horas, estando previsto el repaso del cuestionario de indicadores físicos completando aquellas cuestiones que no hubiera contestado el grupo.

La visita deberá ser realizada por dos personas, normalmente alguien responsable de la dirección y coordinación de los trabajos y otra del equipo.

7.5.1 Análisis de la información primaria

Tanto la información obtenida mediante cuestionarios como por entrevista se elaborará una evaluación por proceso y otra por área. En ambos casos se integrará toda la información disponible (primaria y secundaria) para hacer posible la estimación de los indicadores (información más cuantitativa) y el contraste de la información cualitativa (de opiniones).



7.5.1.1 Estimación de indicadores

Una actividad que se debe hacer en el planteamiento global de la auditoria es establecer indicadores para las diferentes medidas de que constará la auditoria. Adicionalmente se debe contar con una batería de indicadores probados para la evaluación de la información recolectada, los cuales deberán permitir identificar los “puntos clave” bien por su poca relevancia, por no existir información disponible, o por ser demasiado exhaustivo.

7.5.1.2 Establecimiento de la confiabilidad y validez

Hay muchos enfoques para evaluar la confiabilidad y la validez de la información de la inspección. Cuando se usa un cuestionario, establecer la confiabilidad comúnmente incluye la administración del cuestionario o partes del mismo a los mismos auditados en diferentes momentos o bajo circunstancias diferentes para evaluar la veracidad de las respuestas.

El establecimiento de la validez se puede llevar a cabo comparando la evidencia de diferentes fuentes y de diferente naturaleza, esto incluye la comparación de resultados de la inspección con observaciones de comportamiento, así como compara la muestra inspeccionada con grupos que se esperan sean similares o no de manera critica y la comparación de resultados con resultados de otros instrumentos de reunión de información que suponen la medición de la misma, la obtención de opiniones expertas.

Escalas de Valoración. El uso de escalas de valoración ("en una escala de 1 a 9, ubique una marca de control, etc.) para comparar las respuestas de individuos o grupos de individuos requiere particularmente el examen de la confiabilidad y validez. Se requiere una corroboración adicional especial cuando un Auditor desea usar una escala de valoración para comparar diferentes auditados entre si, entre otros grupos o con un criterio acerca de un cierto tema. Por ejemplo encontrar los objetivos de la auditoria requiere la evaluación de la satisfacción del personal con el empleo o ciertas funciones de dirección. Alternativamente, podría requerir una evaluación de conocimiento, tales como conocimiento de los problemas del entorno.

En estos casos y similares, es a menudo incorrecto interpretar literalmente el nivel de respuesta en puntos clasificados o grupos de puntos. Hay una tendencia conocida de los auditados a dar respuestas positivas a algunos tipos de preguntas y respuestas negativas a otros. Determinar la exactitud de las estimaciones de satisfacción y de las respuestas a preguntas de conocimiento requiere que las mismas sean comprobadas o sujetas a algún punto de referencia.

7.5.1.3 Contando con instrumentos establecidos

El establecimiento de la validez y la confiabilidad pueden consumir tiempo, y ser caro, especialmente el examen del conocimiento, la medición de las actitudes o la evaluación del empleado. La confiabilidad es mayor cuando se usa mas de un enfoque. Se podría evitar un esfuerzo considerable con el uso de instrumentos establecidos de confiabilidad y validez conocidas.

Para determinar hasta que punto uno puede depender de los instrumentos de reunión de información establecidos, es importante considerar lo siguiente:

• La reputación de quien la desarrolle,

• Hasta que punto el instrumento ha sido probado mediante un uso amplio,

• Hasta que punto ha sido usada una variedad de enfoques para establecer confiabilidad y validez,



ProyectoFinal.doc

• Si la prueba de validez realizadas son pertinentes a los propósitos de la auditoria,

• Hasta que punto el instrumento ha sido probado en grupos similares a aquellos incluidos en la auditoria; y

• La opinión de expertos independientes.

7.5.2 Actividades de Calidad.

• Revisiones por Peer Review. - Inspecciones. - Revisiones. - Walkthroughs.

• Testing. • Las revisiones por pares deben formar parte de todo programa de calidad de

software.

7.5.3 Walkthroughs.

• Usadas para especificaciones de requerimientos o diseños. • Sin preparación previa de asistentes. • "Presentador", que conoce a fondo el producto. • Invitados especialistas en el negocio, la tecnología usada o conocedores de

sistemas impactados. • Bien conducidas son muy productivas.

7.5.4 Inspecciones.

• Versión "formal" de las revisiones técnicas. • La formalidad está dada por:

- Asignación de roles. - Preparación previa. - Procedimiento documentado. - Procedimiento que se cumple. - Registro de errores encontrados.

7.5.5 Objetivo de las Inspecciones.

• Inspeccionar es revisar un producto con el objetivo de encontrar defectos en él. • Las inspecciones son estáticas. • No son excluyentes con el testing. • Se pueden encontrar distintos tipos de defectos. • No todo puede ser inspeccionado.

- Implican un importante esfuerzo. • Asegurar consenso sobre el trabajo / calidad. • Potenciar el trabajo en equipo. • Obtener datos: Métricas.

7.5.6 Uso de los resultados. - Para el código: Inspecciones de Fagan. - "Los resultados de las inspecciones no deben, bajo ninguna circunstancia, ser

usados para la evaluación de los programadores". • Los resultados de las inspecciones son para el uso y beneficio de los

programadores" [Fagan,1976]. • Nunca se deben organizar cacerías de brujas.

7.5.7 Entrada/Salida de las inspecciones.

• Entrada. - Código.



- Especificación del programa. - Reglas: procedimientos y estándares vigentes. - Lista de verificación: guía para ayudar a los revisores.

• Salida. - Informe: Informe final con el resultado de la inspección.

7.5.8 El proceso de la inspección.

• Planificación. - Preparar materiales.

• Preparación. - Revisar el material antes de la reunión.

• Inspección. - Reunión de revisión.

• Corrección. • Seguimiento.

7.5.9 Roles en una inspección.

• Moderador. Responsable del éxito de la revisión. • Lector. Lee el programa, línea por línea. • Autor. • Registrador. Registra todos los defectos encontrados. • Revisores. Buscan encontrar defectos.

7.5.10 La reunión.

• El moderador coordina. - Asegura que estén todos preparados. - Aclara los roles y las reglas. - Hace cumplir los reglas en la reunión.

• El lector lee el código línea por línea. • Los revisores avisan cuando detectan defectos. • El moderador asegura que los temas no se discutan más de lo prudente. • El autor aclara dudas y registra los errores. • A las dos horas debe finalizar la reunión. • La minuta debe enviarse lo antes posible. • Si hay que modificar más del 5% del programa, puede ser necesaria una nueva

inspección.

7.5.11 Beneficios de las Inspecciones.

• Directas. - Mayor calidad, que lleva a aumentos de productividad. - Disminución de los tiempos de test.

• Indirectas. - Capacitación (para aprender a escribir hay que leer). - Mayor visibilidad del proceso. - Trabajo en equipo y mejor comunicación. - Mejora en la calidad de estándares y métodos.

• Las inspecciones son un método de seguimiento.

7.5.12 Efectividad de las Inspecciones.

• Los reportes indican que se identifican entre 7 y 20 defectos mayores por cada 1000 líneas de código.

• Teniendo en cuenta el proceso completo, lleva alrededor de una hora por defecto encontrado. - ¿Cuánto cuesta encontrar esos defectos en producción?. - En producción se detectan manifestaciones de defectos (fallas) y no defectos.



ProyectoFinal.doc

7.5.13 ¿Cuándo hacer una inspección?.

• Si se hace una inspección de un programa testeado extensamente. - La inspección no va a ser eficiente.

• Si se hace una inspección de un programa que nunca fue compilado. - No se podrá revisar ni 30 líneas...

• Entonces... - Es recomendable hacer inspecciones luego de la primera compilación limpia.

7.5.14 Reglas de Weinberg para revisiones.

• Estén preparados. • Busquen asociarse con el autor del programa. • Tengan cuidado con el lenguaje. • Un comentario positivo y uno negativo. • Identifiquen defectos, no los corrijan. • Eviten discusiones de estilo. • Adhieran al estándar. • Los revisores deben ser técnicamente competentes. • Registren todos los temas en público. • Limítense a temas técnicos. • Recuerden la educación. • No evalúen a los autores. • Distribuyan el reporte lo antes posible. • Dejen que el autor decida cuándo está listo.

7.5.15 Recomendaciones.

• Aplicar revisiones de análisis y diseño en sus proyectos. - Tener mucho cuidado con los factores humanos. - Capacitar a los moderadores.

• Asociar revisiones con hitos de su proyecto.

7.5.16 Mantenimiento de la Integridad de la Inspección.

Los instrumentos de reunión de información y las muestras bien diseñadas no proporcionaran información con niveles aceptables de error significativo si los procedimientos de la inspección no son implementados apropiadamente.

La coherencia es importante. Para que los instrumentos de levantamiento de información proporcionen información coherente y valida, ellos deben ser administrados adecuadamente en la manera proyectada. Para que una muestra continúe siendo representativa de su población, debe obtenerse la información de la mayor cantidad posible de seleccionados.

Entrenamiento y supervisión. Mantener la integridad de la inspección requiere entrenar a los responsables de estos procedimientos, supervisión y monitoreo de la ejecución de dichos procedimientos. Dos problemas importantes de dirigir a través del entrenamiento, la supervisión y el monitoreo son la no-repuesta y la prevención del entrevistado.

En inspecciones largas o complejas, es extremadamente conveniente hacer pruebas piloto de los procedimientos de inspección para evitar el riesgo de problemas mayores que no sean detectados hasta que todas las respuestas sean recibidas.

Prueba piloto. Se espera que todos los aspectos de los procedimientos de inspección sean testeados en una pequeña muestra de la población de interés. Pueden ocurrir problemas en cualquier punto que amenacen la integridad de la inspección. Los cuestionarios pueden ser paginas perdidas debido a controles



inadecuados, las direcciones de una muestra podrían estar desactualizadas o ser inadecuadas, los procedimientos para el rastreo del retorno de los cuestionarios podrían ser inadecuados para identificar que cantidad de la muestra ha sido devuelta o para protegerla de la perdida de dichos cuestionarios, las instrucciones para el acceso de la información podrían no ser las correctas, etc.

Las pruebas piloto de las entrevistas de inspección deben incluir todos los aspectos del proceso – desde la selección de los entrevistadores y su entrenamiento hasta el análisis de la información. Para las inspecciones de documentos o bases de datos, las pruebas piloto deberían comenzar con procedimientos para obtener tales documentos y bases de datos.

Sumado a los procedimientos de pruebas piloto de las inspecciones deben ser pretesteados los instrumentos para reunir la información, es decir aplicar a un pequeño grupo de auditados una completa escala de inspección, para identificar y encontrar soluciones a problemas con los instrumentos.

7.6 Laboratorio de Pruebas

Las pruebas de software incluyen entre otras cosas el plan de preparación y revisión de pruebas, preparación de datos de pruebas y revisión, así como la revisión de los resultados de las pruebas.

El Laboratorio de Pruebas debe sugerir, acciones para corregir los defectos desde su origen. Pero también deberá tener un programa para la reevaluación de herramientas, técnicas y metodología usadas en la producción de software.

Deberá implementar estándares de programación que describan prácticas aprobadas y desarrollar listados de cualquier práctica prohibida.

El laboratorio de Pruebas deberá contemplar tres grandes funciones interrelacionadas entre sí, las cuales no podrán desarrollarse de forma aislada, estas funciones son:

7.6.1 Fase de pruebas.

Esta función establecer procedimientos para llevar a cabo pruebas de sobre la funcionalidad del software las cuales deben abarcar:

• pruebas unitarias o modulares • pruebas de integración • Pruebas del sistema • Pruebas de aceptación

7.6.2 Actividades de las pruebas.

Esta función establece el plan de pruebas del desarrollo de software y se llevan acabo las siguientes actividades:

• Calendarización de pruebas • Pruebas de diseño y desarrollo • Pruebas de ejecución • Reporte de resultado de pruebas • Pruebas de regresión

7.6.3 Administración de las pruebas.

Esta función se encarga de controlar todo el proceso de pruebas y las actividades que deben realizarse son:

• Plan de revisión de pruebas. • Entrenamiento del staff de pruebas • Contenido de la documentación de las pruebas



ProyectoFinal.doc

Entonces...

• Las pruebas de regresión deberán ser hechas para asegurar que los cambios son correctos.

• El plan de pruebas deberá ser revisado y validado periódicamente. • Las pruebas deben reflejar en que medida el proceso del Desarrollo del Software

supera lo requerido • El estándar del proceso de software debe ser mantenido y actualizado. • El proceso de pruebas deberá ser continuamente mejorado. • El grupo del sistema de pruebas deberá ser responsable de realizar un sistema de

pruebas independiente.

7.7 El entrenamiento adecuado del equipo de pruebas deberá ser un conducto para realizar mejor el trabajo.Evaluación de fortalezas y debilidades de auditoría.

Luego de desarrollar el programa de auditoría y recopilar evidencia de auditoría, el siguiente paso es evaluar la información recopilada con la finalidad de desarrollar una opinión. Para esto generalmente se utiliza una matriz de control con la que se evaluará el nivel de los controles identificados, esta matriz tiene sobre el eje vertical los tipos de errores que pueden presentarse en el área y un eje horizontal los controles conocidos para detectar o corregir los errores, luego se establece un puntaje (puede ser de 1 a 10 ó 0 a 20, la idea es que cuantifique calidad) para cada correspondencia, una vez completada, la matriz muestra las áreas en que los controles no existen o son débiles, obviamente el auditor debe tener el suficiente criterio para juzgar cuando no lo hay si es necesario el control. Por ejemplo:

Riesgo de Control en

Control de Integridad

Control de Duplicidad

Control de Validación

Control de Limitantes

Control de Existencia

Control de Tablas

Control de Autorización

Despacho item de almacén

0 10 0 0 0 0 0

Ingreso Código de

cliente 0 0 10 10 10 0 5

Código de item 2 0 0 0 0 0 0

Ingreso de calidad

0 10 0 10 0 5 10

En esta parte de evaluación de debilidades y fortalezas también se debe elegir o determinar la materialidad de las observaciones o hallazgos de auditoría. El auditor de sistemas debe juzgar cuales observaciones son materiales a diversos niveles de la gerencia y se debe informar de acuerdo a ello.

7.8 Informes de auditoría (Reportes).

Los informes de auditoría son el producto final del trabajo del auditor de sistemas, este informe es utilizado para indicar las observaciones y recomendaciones a la gerencia, aquí también se expone la opinión sobre lo adecuado o lo inadecuado de los controles o procedimientos revisados durante la auditoría, no existe un formato específico para exponer un informe de auditoría de sistemas de información, pero generalmente tiene la siguiente estructura o contenido:

• Introducción al informe, donde se expresaran los objetivos de la auditoría, el período o alcance cubierto por la misma, y una expresión general sobre la naturaleza o extensión de los procedimientos de auditoría realizados.

• Observaciones detalladas y recomendaciones de auditoría. • Respuestas de la gerencia a las observaciones con respecto a las acciones correctivas. • Conclusión global del auditor expresando una opinión sobre los controles y

procedimientos revisados.



7.8.1 Elementos básicos del informe de auditoría

La materialización final del trabajo llevado a cabo por los auditores independientes se documenta en el dictamen, informe u opinión de auditoría.

El informe de auditoría independiente deberá contener, como mínimo, los siguientes elementos básicos:

a) El título o identificación. b) A quién se dirige y quienes lo encargaron. c) El párrafo de "Alcance". d) El párrafo de "Opinión". e) El párrafo o párrafos de "Énfasis". f) El párrafo o párrafos de "Salvedades". g) La firma del auditor. h) La fecha del informe.

7.8.1.1 El título o identificación

Deberá identificarse el informe bajo el título de "Informe de Auditoría en el Desarrollo de Software", para que cualquier lector o usuario del mismo pueda distinguirlo de otros informes que puede emitir el auditor resultado de trabajos especiales, revisiones limitadas o informes preparados por personas distintas de los auditores, como pueden ser los informes de la Dirección o de otros órganos internos de la entidad. Por tanto, dicho título sólo se aplicará por el auditor a informes basados en exámenes cuya finalidad sea la de expresar una opinión sobre el Desarrollo de sistemas en su conjunto.

7.8.1.2 A quién se dirige y quiénes lo encargaron

El auditor dirigirá su informe a la persona o al órgano de la entidad del que recibió el encargo de la auditoría. Normalmente, el informe del auditor se dirigirá al responsable del área de Sistemas En algunas ocasiones el informe se dirige a los administradores o al comité de auditoría, aunque esto sucederá, normalmente, si se trata de una auditoría voluntaria.

7.8.1.3 El párrafo de alcance

Este párrafo, cuyo objeto es describir la amplitud del trabajo de auditoría realizado, debe claramente:

a) Identificar las áreas auditados. Por tanto, deberá incluir el nombre de la entidad, los temas objeto de examen, la fecha y el período que cubrió la auditoría.

b) Hacer referencia al cumplimiento en el examen de las normas de auditoría generalmente aceptadas en el país Si, por encargo especial, el trabajo se ha realizado de acuerdo con normas de auditoría generalmente aceptadas en otro país, el auditor podrá emitir un informe según las normas vigentes y con el lenguaje usual en dicho país, indicando siempre en su informe el origen de las mismas y, si tales normas utilizadas no cumplen los requisitos mínimos de las Nacionales, haciendo mención en los párrafos de alcance y opinión de los requisitos no cumplidos.

Si el auditor no mencionara en el párrafo de alcance ninguna limitación o salvedad, se entenderá que ha llevado a cabo todos los procedimientos y pruebas de auditoría necesarios para expresar su opinión sobre el desarrollo de software del área de sistemas. En caso contrario, deberá hacer constar que han existido limitaciones al alcance en su examen



ProyectoFinal.doc

Hacemos notar que en el párrafo de alcance únicamente se expresará si no han existido limitaciones al alcance o si, por el contrario, han existido limitaciones, en cuyo caso se menciona únicamente que han existido, pero no se dirá de qué tipo de limitaciones ni tampoco qué procedimientos de auditoría se han dejado de aplicar con motivo de la limitación o las limitaciones; tal información se redactará en uno o varios párrafos de salvedades.

7.8.1.4 El párrafo de opinión

El párrafo de opinión del Informe de Auditoría en el Desarrollo de Software debe mostrar claramente el juicio final del auditor sobre si los Desarrollos de Software, considerados en todos los aspectos significativos, expresan adecuadamente la imagen fiel de los aspectos evaluados en la auditada:

Todo ello dentro de un marco de principios y normas establecidas en el país. Es decir la opinión se refiere al grado en que el desarrollo se apega a los estándares preestablecidos. Asimismo, deberá expresar si estándares han sido aplicados uniformemente.

En este párrafo también se dirá si la documentación contiene la información necesaria y suficiente para su interpretación y comprensión adecuada. La citada información debe identificarse como la información mínima obligatoria que establecen los estándares aplicados específicamente.

También en el párrafo de opinión, el auditor hará constar, en su caso, la naturaleza de cualquier salvedad significativa sobre el Desarrollo de Software. Cuando se diera esta circunstancia, es preciso que se incluya la expresión "excepto por". Cuando la salvedad o salvedades fueran muy significativas, el auditor deberá denegar su opinión o expresar una opinión desfavorable.

7.8.1.5 El párrafo (o párrafos) de énfasis

Mediante los párrafos de énfasis, el auditor pone de manifiesto aquellos hechos que considera relevantes o de especial importancia, aunque tales hechos no llegan a afectar la opinión.

Por tanto, cuando en un informe de auditoría aparece un párrafo de énfasis, el auditor pretende con ello destacar al lector ese hecho en concreto, el cual considera de especial trascendencia para el Área auditada, si bien ello no significa que la opinión de auditoría deba recoger salvedad alguna. Nunca debe confundirse, por tanto, un párrafo de énfasis con uno de salvedad.

Algunas razones usuales por las que el auditor suele incluir en su informe de auditoría párrafos de énfasis son:

• Por la necesidad de poner de manifiesto que un porcentaje importante de de los desarrollos se están realizando con un área en concreto o vía out sourcing.

• Salvedades puestas de manifiesto en anteriores informes y corregidas en este ejercicio; dado que al haber sido corregidas en este ejercicio no tiene aplicación su inclusión como salvedad en este ejercicio, sin embargo, y dada la importancia que esta circunstancia tuvo en anteriores informes (por ello se incluyó como salvedad), se incluyen en el presente como párrafo de énfasis.

• No aplicación excepcional de algún estándar (con lo que el auditor está conforme), debido a que su aplicación impediría mostrar la imagen fiel. Si el auditor no está conforme con la no aplicación, dará lugar a salvedad o a una opinión negativa.



Un párrafo de énfasis nunca estará referenciado en el informe de auditoría por la expresión "excepto por" ya que expresa un hecho o circunstancia que no afecta a la opinión de auditoría en modo alguno.

7.8.1.6 El párrafo (o párrafos) de salvedades

Cuando el auditor ha de poner de manifiesto en su informe que existen algunos reparos en relación con el Desarrollo de Software realizados por el Área de Sistemas, utiliza el párrafo (o párrafos) de salvedades, en el cual se deben justificar siempre los motivos de sus reparos, cuantificándose el impacto que esta salvedad tiene sobre los desarrollos auditados (siempre que la salvedad sea cuantificable); si el efecto de la salvedad no fuese susceptible de ser estimado o cuantificado razonablemente, sólo se mencionarán las causas que provocan tal salvedad.

Es usual y resulta lógico que el auditor recoja la salvedad o salvedades suficientemente explicadas y detalladas, ya que se causan, normalmente, por las diferencias de criterios o de interpretación que ante un mismo hecho o circunstancia, se producen entre los administradores o sus asesores y el propio auditor o firma de auditoría.

Los párrafos de salvedades se sitúan entre el párrafo de alcance y el párrafo de opinión, por lo que son también llamados párrafos intermedios. Nunca se debe confundir un párrafo de salvedades con uno de énfasis. El hecho recolectado en un párrafo de salvedades afecta a la opinión, el reflejado en un párrafo de énfasis, no.

7.8.1.7 La firma del informe por el auditor

Para una auditoría interna el informe debe ir firmado por un auditor reconocido por la empresas. En el caso de informes correspondientes a auditorías realizadas por sociedades de auditoría reconociadas:

NOMBRE DE LA SOCIEDAD

Firma del socio o socios

Nombre del socio o socios firmantes

7.8.1.8 La fecha del informe

El informe del auditor debe expresar una fecha. La fecha del informe deberá ser la del último día de trabajo en las oficinas de la entidad, ya que en esta fecha habrá completado sus procedimientos de auditoría.

Por tanto, si bien el informe de auditoría contiene la opinión profesional sobre la el estado de los desarrollos del período auditado, el auditor en su informe también opina sobre la existencia (o inexistencia) de hechos significativos ocurridos desde el cierre del periódo auditado a la fecha de entrega del informe.

En estos casos especiales en que el auditor obtiene una nueva evidencia entre la fecha de terminación de los trabajos y la fecha de entrega del informe, si esta evidencia afecta al contenido del informe, podrá poner dos fechas distintas, una para el contenido del informe y otra para la evidencia en cuestión.

7.8.2 Objetivos Características y afirmaciones que contiene el informe de auditoría.

El informe de auditoría de Desarrollo de Sistemas tiene como objetivo expresar una opinión técnica de los estados que guardan los Desarrollos de Sistemas en los aspectos significativos o importantes.



ProyectoFinal.doc

Características del informe de auditoría

a. Es un documento público. b. Muestra el alcance del trabajo. c. Contiene la opinión del auditor. d. Se realiza conforme a un marco legal.

Principales afirmaciones que debe contener el informe

• Indica el alcance del trabajo y si ha sido posible llevarlo a cabo y de acuerdo con qué normas de auditoría.

• Expresa si la documentación encontrada contienen la información necesaria y suficiente y han sido elaborados de acuerdo con las especificaciones sobre la cual se está haciendo la auditoría.

• Asimismo, expresa si la documentación y el desarrollo en sí refleja, en todos los aspectos significativos, la imagen de los recursos obtenidos y aplicados.

• Se opina también sobre la concordancia de la información que se estableció deben tener y con la que realmente tienen.

• En su caso, explica las desviaciones que presentan con respecto a los estándares preestablecidos.

Podemos sintetizar que el informe es una presentación pública, resumida y por escrito del trabajo realizado por los auditores y de su opinión sobre el Desarrollo de Sistemas.

7.8.3 Circunstancias con efecto en la opinión del auditor

Las circunstancias que pueden tener efecto en la opinión del auditor y que, por tanto, pueden dar lugar a una opinión no limpia (con salvedades, negativa o denegada) son las siguientes:

• Limitaciones al alcance del trabajo realizado • Incertidumbres cuyo desenlace final no es susceptible de una estimación

razonable • Errores o incumplimientos de los principios y normas establecidas, incluyendo

omisiones de información necesaria • Cambios durante la auditoría, con respecto a los principios y normas en el

Desarrollo de Sistemas aceptados utilizados en auditorias anteriores.

7.8.4 Tipos de oponión

Existen cuatro tipos de opinión en auditoría:

La opinión favorable, limpia o sin salvedades significa que el auditor está de acuerdo, sin reservas, sobre la presentación y contenido de la auditoría en el Desarrollo de Sistemas.

La opinión con salvedades (llamada también en la jerga de la auditoría como opinión calificada o cualificada), significa que el auditor está de acuerdo con la auditoría en el Desarrollo de Sistemas, pero con ciertas reservas.

La opinión desfavorable u opinión adversa o negativa significa que el auditor está en desacuerdo con la auditoría en el Desarrollo de Sistemas y afirma que éstos no presentan adecuadamente la realidad del área auditada.

Por último, la opinión denegada, o abstención de opinión significa que el auditor no expresa ningún dictamen sobre la auditoría en el Desarrollo de Sistemas. Esto no significa que esté en desacuerdo con ellos, significa simplemente que no tiene suficientes elementos de juicio para formarse ninguno de los tres anteriores tipos de opinión.



7.8.4.1 Opinión favorable

Una opinión favorable, limpia, positiva o sin salvedades, expresa que el auditor ha quedado satisfecho, en todos los aspectos importantes, de que el Desarrollos de Sistemas auditado reúne los requisitos siguientes:

(a) Se han preparado de acuerdo con principios y criterios establecidos en estándares de Desarrollo de Software y que guardan uniformidad con los aplicados en auditorias anteriores.

(b) Se han preparado de acuerdo con las normas y disposiciones establecidas que les sean aplicables y que afecten significativamente al adecuado Desarrollo de Sistemas.

(c) Dan, en conjunto, una visión que concuerda con la información de que dispone el auditor sobre el Área de sistemas o actividades del Área.

(d) Informan adecuadamente sobre todo aquello que puede ser significativo para conseguir una presentación e interpretación apropiadas de la documentación del producto.

7.8.4.2 Opinión con salvedades (o calificada, con reservas o con excepciones)

Este tipo de opinión es aplicable cuando el auditor concluye que existen una o varias circunstancias en relación con el Desarrollo de Sistemas tomadas en su conjunto, que pudieran ser significativas. Tratamiento distinto requieren aquellos casos en los que este tipo de circunstancias, por ser muy significativas, impiden que el desarrollo del producto presenten la imagen fiel o no permitan al auditor formarse una opinión sobre el mismos.

A continuación, se presentan algunas circunstancias que pueden originar una opinión con salvedades.

Limitaciones al alcance. Existe una limitación al alcance cuando el auditor no puede aplicar uno o varios procedimientos de auditoría o éstos no pueden practicarse en su totalidad; asimismo, los procedimientos no practicados se consideran necesarios para la obtención de evidencia de auditoría, a fin de satisfacerse de que el Desarrollo de Sofware presenta la imagen fiel de la entidad auditada.

Dentro de las limitaciones al alcance, hemos de diferenciar entre dos tipos:

- Aquellas que provienen de la entidad auditada (limitaciones impuestas).

- Aquellas que vienen causadas por las circunstancias (limitaciones sobrevenidas).

Entre las primeras podemos referirnos, a modo de ejemplo, a la negativa de la entidad a entregar determinada información o a dejar practicar determinados procedimientos de.

Entre las segundas podríamos incluir la destrucción accidental de documentación o registros necesarios para la auditoría, o la imposibilidad de presenciar recuentos físicos de existencias por haber sido nombrados auditores con posterioridad al cierre del ejercicio.

No obstante lo anterior, si existieran métodos alternativos para obtener evidencia suficiente, el auditor deberá aplicar éstos métodos (siempre y cuando la entidad auditada facilite la información necesaria para la aplicación de éstas pruebas alternativas), al objeto de eliminar la limitación inicialmente encontrada.



ProyectoFinal.doc

Ante una limitación al alcance, el auditor debe decidir entre denegar la opinión o emitirla con salvedades, lo cual depende de la importancia de la limitación. Para ello hay que tener en consideración:

a) La naturaleza y significación del efecto potencial de los procedimientos omitidos y,

b) la importancia relativa de la cuenta o cuentas afectadas.

En un informe de auditoría, una limitación al alcance tiene efecto sobre el Párrafo de Alcance y sobre el Párrafo de Opinión, ya que se debe poner de manifiesto no sólo en la opinión esta circunstancia, sino que en el alcance de nuestro trabajo hemos de dejar evidencia de la imposibilidad (limitación) de realizar una parte del trabajo.

Incertidumbres. Una incertidumbre se define como un asunto o situación de cuyo desenlace final no se tiene certeza a la fecha de la auditoría, por depender de que ocurra o no un hecho futuro.

Sin embargo, no debe calificarse de incertidumbre las estimaciones normales que sobre hechos futuros ha de realizar el Área Auditada en la preparación de su documentación.

Errores o incumplimientos de los principios y normas contables generalmente aceptados. Las evidencias del Desarrollo de Sistemas han de expresar la imagen fiel, de acuerdo con principios y normas contables generalmente aceptados. Por tanto, durante la realización del trabajo pueden aparecer circunstancias que suponen un incumplimiento de los citados principios.

Los errores que pueden presentarse son los siguientes:

a) Utilización de principios y normas distintos de los generalmente aceptados.

b) Errores, fueran o no intencionados, en la elaboración de la documentación. Entre ellos se incluyen los errores aritméticos, los errores en la aplicación práctica de los principios y normas establecidas y los errores de interpretación de hechos.

c) La documentación no contiene toda la información necesaria y suficiente para su interpretación y comprensión adecuada.

Por tanto, cuando el auditor observe alguna de las circunstancias anteriores, deberá evaluar y, en su caso si fuera posible, cuantificar su efecto sobre la documentación, de tal forma que si concluyera que estos hechos pudieran ser materialmente significativos, deberá expresar una opinión con salvedades, o, en caso que al documentación no presenten la imagen fiel, una opinión desfavorable.

7.8.4.3 Opinión desfavorable (negativa o adversa)

Una opinión desfavorable supone manifestarse en el sentido de que los productos auditados tomados en su conjunto no presentan la imagen fiel de la entidad auditada, de conformidad con los principios y normas generalmente aceptados.

Para que un auditor llegue a expresar una opinión como la indicada, es preciso que haya identificado errores, incumplimiento de principios y normas establecidas que, a su juicio, afecten el producto de trabajo auditado.

Si además de las circunstancias que originan la opinión desfavorable, existen incertidumbres o cambios de principios y normas establecidas, al auditor deberá detallar estas salvedades en su informe.



7.8.4.4 Opinión Denegada (abstención de opinión)

Cuando el auditor no ha obtenido la evidencia necesaria para formarse una opinión sobre los productos de trabajo tomados en su conjunto, debe manifestar en su informe que no le es posible expresar una opinión sobre las mismas.

La necesidad de denegar la opinión puede originarse exclusivamente por:

- Limitaciones al alcance de auditoría y/o

- Incertidumbres.

de importancia muy significativa que impidan al auditor formarse una opinión.

No obstante lo anterior, aunque el auditor no pudiera expresar una opinión, habrá de mencionar, en párrafo distinto al de opinión, cualquier salvedad que por error o incumplimiento de los principios y normas establecidos o cambios en los mismos hubiese observado durante la realización de su trabajo.

La opinión parcial no está permitida: si el auditor se abstiene de opinar, no puede afirmar al mismo tiempo que, no obstante la denegación de opinión, determinadas cosas sí están bien, con lo que se podría dar la visión deformada de que algunas cosas están mal, pero una gran mayoría está bien, lo cual confundiría al usuario del informe.

En todo caso, no se debe confundir la no admisión de una opinión parcial en el informe de cuentas anuales con la emisión de un informe parcial o revisión limitada, en el que el auditor se enfoca a verificar una determinada parte de las cuentas anuales.

Resulta de vital importancia, a la hora de redactar el Informe de Auditoría de Desarrollo de Sistemas”, que el auditor catalogue una determinada circunstancia como de poco significativa, de significativa o de muy significativa, ya que ello influirá en el tipo de opinión a emitir; en la siguiente tabla, se presenta un resumen de utilidad para relacionar el tipo de opinión con la importancia relativa de las distintas circunstancias que se pueden presentar en la práctica profesional:

CIRCUNSTANCIA / IMPORTANCIA RELATIVA Poco Significativa Significativa Muy Significativa

Limitación al alcance FAVORABLE CON SALVEDADES DENEGADA Incertidumbre FAVORABLE CON SALVEDADES DENEGADA Error o Incumplimiento FAVORABLE CON SALVEDADES DESFAVORABLE Omisión de información FAVORABLE CON SALVEDADES ---

Acuerdo -> PÁRRAFO ÉNFASIS REFERENCIA A

NOTA MEMORIA ---

Falta de uniformidad FAVORABLE No acuerdo -> CON

SALVEDADES DESFAVORABLE(difícil)

Incumplimiento normativa FAVORABLE CON SALVEDADES DENEGADA Dudas en la gestión continuada

FAVORABLE CON SALVEDADES DENEGADA

Asimismo, a la hora de catalogar cada una de las anteriores circunstancias como de no significativa, significativa o muy significativa, dicha tabla se basa, en términos generales, en comparar el importe numérico de la circunstancia a evaluar con una determinada magnitud de la entidad auditada y estimar qué porcentaje representa sobre la misma. Por tanto, la tabla sólo puede orientar en la evaluación de aspectos cuantitativos y no es válida para los aspectos cualitativos.



ProyectoFinal.doc

7.9 Seguimiento de las observaciones de auditoría.

El trabajo de auditoría es un proceso continuo, se debe entender que no serviría de nada el trabajo de auditoría si no se comprueba que las acciones correctivas tomadas por la gerencia, se están realizando, para esto se debe tener un programa de seguimiento, la oportunidad de seguimiento dependerá del carácter crítico de las observaciones de auditoría. El nivel de revisión de seguimiento del auditor de sistemas dependerá de diversos factores, en algunos casos el auditor de sistemas tal vez solo necesite inquirir sobre la situación actual, en otros casos tendrá que hacer una revisión más técnica del sistema.

En caso de encontrar no conformidades, las acciones correctivas propuestas en el plan serán evaluadas por el auditor líder para verificar la corrección de las no conformidades. Esta actividad debe quedar registrada. El auditor tendrá un plazo de 5 días hábiles para evaluar el plan y responder al responsable del área auditada.

Una vez levantadas las no conformidades a satisfacción del auditor líder, éste solicitará al Encargado de la Calidad los documentos de la auditoria y anexará al informe de auditoria la información correspondiente a las acciones correctivas. Luego, el auditor líder devolverá al Encargado de la Calidad los documentos de la auditoria.

El Encargado de la Calidad deberá registrar en el plan de auditoria, la fecha de recepción del informe con el cierre de las no conformidades.

Si la decisión de la gerencia es seguir las recomendaciones de auditoría, para completar el proceso se deberá asesorar la implantación de ellas y evaluarlas una vez que empiecen a funcionar

En caso de que el usuario no desee la colaboración de auditoría se deberá esperar el tiempo estimado para que estas modificaciones entren en vigencia y proceder a evaluarlas.

Si este paso no se ejecuta la labor de auditoría se puede considerar sobrante para la organización.

8 Referencias. http://www.dc.uba.ar/people/materias/isoft2/clases/inspecciones.PDF. http://sistemas.dgsca.unam.mx/publica/pdf/Control%20de%20Calidad.PDF. http://www.tantara.ab.ca/. http://www.isaca.org/standard/sp.htm. http://standards.ieee.org/reading/ieee/std_public/description/se/. http://www.geocities.com/lsialer/NotasInteresantes1.htm. http://www.geocities.com/lsialer/NotasInteresantes1.htm http://www.respondanet.com/spanish/admin_financiera/auditoria/smithp1/argentin/ar11.htm http://www.santafe.gov.ar/tribunal/congreso/TRADUCCION%20-%20CONDUCCION%20DE%20AUDITORIAS-.htm http://ciberconta.unizar.es/LECCION/auditoria03/INICIO.HTML http://216.239.37.100/search?q=cache:IiI6RHgCsjYC:www.oba-bolivia.org/docs/obapro013.doc+%22plan+de+auditoria%22+%2B+seguimiento&hl=es&ie=UTF-8 http://216.239.37.100/search?q=cache:GtbB3k1uYM4C:univalle.galeon.com/document/aud_sistemas.ppt+%22plan+de+auditoria%22+%2B+seguimiento&hl=es&ie=UTF-8 1 http://www.ccss.sa.cr/auditoria/aud012.htm

2 http://mailweb.udlap.mx/~lazzeri/AUDINF/AUDINF_1.html 3 http://mailweb.udlap.mx/~lazzeri/AUDINF/AUDINF_2.html 4 http://mailweb.udlap.mx/~lazzeri/AUDINF/AUDINF_3.html 5 http://www.msc.es/salud/epidemiologia/resp/revista_cdrom/VOL67/67_5_331.pdf

6 http://www.cp.com.uy/43/iso43.htm



7 http://www.google.com./search?q=cache:UBVm5yGVPqwC:www.info-ab.uclm.es/asignaturas/42551/Temas/Tema%25203.pdf+%22tipos+de+revisiones%22+%2B+auditoria&hl=en&ie=UTF-8

8 http://www.monografias.com/trabajos/maudisist/maudisist.shtml 9 http://www.sei.cmu.edu/cmmi/presentations/sepg01.presentations/ippd/sld007.htm

10 http://www.opm.gov/fedclass/gs2200a.pdf

11 http://intranet.inppaz.org.ar/nhp/GMP/E/part2_10.htm

12 http://bvs.insp.mx/componen/mbevid/bibcoch/doc/Manual_esp.PDF

13 http://www.fciencias.unam.mx/~ho/SPICE/pres1.html 14 http://www.iso.ch/iso/en/ISOOnline.openerpage

15 http://members.aol.com/kaizensepg/standard.htm

16http://216.239.37.100/search?q=cache:8w9OlggepoUC:sistemas.dgsca.unam.mx/publica/pdf/Control%2520de%2520Calidad.PDF+%22El+ciclo+Shewhart+propone+%22&hl=en&ie=UTF-8

Universidad La Salle Maestría en Sistemas...

Documents

Transcript of Universidad La Salle Maestría en Sistemas...