UNIDAD 2. CALIDAD ENFOCADA AL DESARROLLO DE SISTEMAS DE INFORMACIÓN Competencia específica a desarrollar Conocer la importancia de la ingeniería de sistemas de información y la calidad que se aplica en ellos. Conocer y aplicar técnicas para determinar los niveles de error y defectos en los sistemas de información. Habilidad para obtener la calidad de los sistemas de información.
2.1. Calidad en los sistemas de información. En la Sociedad de la Información y del Conocimiento cada vez se hace más necesario el conocimiento y el aprendizaje para desarrollar cualquier actividad bien sea esta empresarial, recreativa, investigadora, o de otra índole, y además estos conocimientos deben actualizarse regularmente, pues con frecuencia quedan desfasados, y el proceso de aprendizaje debe ser continuo para que sea eficaz. La materia prima para estos procesos (aprendizaje y adquisición de conocimiento) es la información, de ahí su importancia, pero no toda la información que se genera y a la que tenemos acceso es igual de relevante y significativa. La capacidad de discernir la buena de la mala información para su uso posterior determinará el éxito del individuo, grupo u organización en este nuevo entorno en el que la información se ha constituido en un recurso valioso. Aplicadas las definiciones de calidad al ámbito de la información podría decirse que la calidad de la información de un sistema de información, vendrá determinada por su capacidad para satisfacer las necesidades de información de la persona o personas que lo utilicen. De allí la urgencia de contar con sistemas de información donde la información revista de la calidad exigida, a objeto de que aquellos logren los objetivos para los cuales fueron diseñados e implantados. Son muchos los autores que han expresado lo difícil de una definición de calidad; el Diccionario de la Lengua Española define el vocablo calidad en los siguientes términos: “Propiedad o conjunto de propiedades inherentes a una cosa, que permite apreciarla como igual, mejor o peor que las restantes de su especie”. Según lo que plantea la norma ISO 9000:2000, calidad: “Es el grado en el que un conjunto de características (rango diferenciador) inherentes cumple con los requisitos (necesidad o expectativa establecida, generalmente implícita u obligatoria)”. 1
Según la norma ISO 8402 define calidad como: “La totalidad de las características de una entidad que le confieren la aptitud para satisfacer las necesidades establecidas e implícitas”. Por otro lado, no son numerosos los conceptos existentes en la bibliografía sobre la información de la calidad en los servicios. Es importante la definición de calidad de la información donde se dice que: “Comprende un conjunto de actividades dirigidas a la obtención en tiempo y forma de los datos acerca del comportamiento de los principales índices de calidad de los productos, así como de los indicadores que reflejan la calidad de los mismos”. [Gómez, 1985]. Lucey [1987] define un Sistema de Información para la dirección como: “Un sistema para convertir datos procedentes del interior o exterior del mismo en información y para brindarle esta, en forma apropiada a los directivos de todos los niveles, para facilita la toma de decisiones”. Además por sistema de información se entiende “un conjunto de elementos organizados para ofrecer información oportuna en cuanto a contenido, formato, tiempo y lugar a un usuario determinado. Es decir, se trata de una configuración de medios, diseñados para proporcionar información referida a calidad un receptor, o usuario, cumpliendo unos requisitos de calidad predeterminados” [Edwards, 1997]. Diferenciar el concepto de información y datos, reviste gran importancia para el desarrollo de Sistemas de información en función de la dirección. Frecuentemente los términos datos e información se intercambian, confundiendo su significado. George W. Reynols [1988] expresan los conceptos de información y datos: Datos: Es la colección desorganizada de hechos que no han sido procesados en información, dato es el hecho crudo cuyas conclusiones pudieran ser desentrañadas. Estos hechos pueden describir personas, lugares, cosas, ideas, procesos o eventos. Información: Es el conocimiento adquirido por causa del procesamiento de datos. El dato es la personificación material de la información, constituye su base. Los datos en general son necesarios en tanto que pueden transformarse en información por esto, por su esencia, ocurren solo cuando están relacionados con una tarea fijada que será resuelta por algún usuario con estos datos. 2
Según lo que plantea uno de los principios de las normas ISO 9000, donde se define que un sistema de información de la calidad, se refiere al sistema informativo que permite gestionar la calidad de los procesos para tomar decisiones asociadas a la calidad, basadas en hechos. Un sistema de información de la calidad: “Es un método organizado para recolectar, almacenar y reportar la información sobre la calidad para ayudar a los tomadores de decisiones en todos los niveles”. [Juran, 1999]. Dimensiones de la calidad de la información Como sabemos, el concepto de calidad es relativo, está en los ojos del observador, por lo que podemos considerar la calidad como un concepto multidimensional, sujeta a restricciones y ligada a compromisos aceptables (Piattini et al., 1997). Así, por ejemplo, Redman (1996) señala quince características deseables en una vista de datos "ideal": 1. La vista debería proporcionar los datos necesarios para la aplicación (relevancia) 2. Los valores de los datos deberían ser fácilmente obtenibles (facilidad de obtención) 3. Cada término en la definición de la vista debería estar claramente definido (claridad de definición). 4. Todo elemento de datos necesario debería ser incluido (totalidad). 5. No se debería incluir ningún elemento de datos innecesario (esencialidad) 6. Los atributos deberían definirse al nivel adecuado de detalle para soportar aplicaciones 7. Los dominios de los posibles valores deberían ser lo suficientemente grandes para soportar las aplicaciones (precisión de dominio) 8. Todo elemento de la vista debería tener un homólogo en el mundo real (naturalidad) 9. La vista debería facilitar la identificación de las entidades individuales (identificación de ocurrencias) 10. Los tipos de entidad deberían definirse con el fin de minimizar la ocurrencia de atributos innecesarios (homogeneidad) 11. La redundancia debería mantenerse al mínimo (redundancia mínima) 12. La vista debería ser clara, no ambigua y consistente (consistencia semántica) 13. Los tipos de entidad y atributos deberían tener la misma estructura básica cuando sea posible (consistencia estructural) 14. La vista debería ser lo suficientemente amplia como para no requerir cambios cada vez que cambien las aplicaciones (robustez) 15. Cuando sea necesario, la vista puede ser modificada fácilmente (flexibilidad) 3
2.2. Defectos y errores de calidad en los sistemas de información. FALLO Un fallo ocurre cuando algo deja de funcionar:
Cuando debería de hacerlo o
Como debería de hacerlo. Un infarto cardíaco es un FALLO
Los fallos están referidos directamente al (in)cumplimiento de las especificaciones tanto explícitas como implícitas. (Definición de calidad). La OCURRENCIA de fallos señala la distancia del producto al objetivo de la calidad y en consecuencia del proceso que lo creó. DEFECTOS Un defecto es la causa de un fallo. Es algo en el producto que: Está, pero no debe. No está, pero debe. No está como debe estar. La acumulación de colesterol en el sistema circulatorio es un DEFECTO. Desde el punto de vista de la corporación, sus efectos se computan como “COSTE DE LA NO CALIDAD”, que se agravan cuanto más “tiempo” permanezca sin ser eliminado. La PRESENCIA de defectos apunta de forma directa a la validez de los procedimientos de inspección y prueba. BUGS (BICHOS) Un buges el término común usado para describir un defecto, en un programa. La introducción del término "bug" a menudo se atribuye Grace Hopper, que en 1946informó sobre la causa de una avería en uno de los primeros equipos electromecánicos de (MARK II). Hooper junto con otros operadores encontraron una polilla muerta que bloqueaba un contacto. El informe incluía la polilla pegada con cinta adhesiva. Desde entonces se utiliza el término bug para nombrar a los defectos sw, debug(ear) para nombrar la operación de eliminarlos y debuggera las herramientas útiles a tal fin. ERRORES Un error es la acción que ha provocado la introducción de un defecto en el producto. No mantener una dieta sana y equilibrada es un ERROR La COMISIÓN de errores señala de forma directa a la calidad de los procesos de desarrollo. 4
Un fallo OCURRE durante el FUNCIONAMIENTO del equipo. Un defecto se INTRODUCE en el PRODUCTO durante su desarrollo. Un error lo COMETE una PERSONA durante el desarrollo.
ERRORES DE LOS USUARIOS UN FALLO PROVOCADO POR UN ERROR DE UN USUARIO ES UN DEFECTO NUESTRO Los usuarios también cometen errores, pero eso no debe comprometer las prestaciones del sistema. No deben producir fallos.
No es razonable trasladar la culpa al usuario de las averías causadas por la incorrecta utilización (salvo especificación).
Por ello calidad es atender también a la formación y entrenamiento de los usuarios.
Además de ello, la calidad del producto y por tanto del proceso de desarrollo debe plantearse bajo la perspectiva del uso y por tanto se debe prever cualquier eventualidad que pueda ocurrir durante la explotación y proteger el sistema frente a ello. Calidad ---proporcionar las prestaciones importantes para los usuarios. Trabajo del Ingeniero de SW -Entregar productos de calidad:
Costes Tiempos Satisfacer necesidades del usuario de forma segura y consistente
Defecto - algo equivocado… sintáctico, tipográfico, incorrección. En requisitos, diseños, codificaciones... Encontrar defectos antes de entregar el producto final El que escribe está más capacitado para encontrar el defecto Los defectos salen a la luz de forma imprevisible Si no tratas de no tener defectos, no lo conseguirás
5
2.2.1. El cuaderno de registro de defectos. Tipología de defectos
Uso de cuaderno de defectos
Mejorar la programación Reducir el número de defectos en tus programas Ahorrar tiempo Ahorrar dinero Hacer tu trabajo de forma responsable
6
2.2.2. Contabilización de defectos y errores.
Las anotaciones en el cuaderno deben basarse sólo en las correcciones que se hacen (un solo despiste, p. eje. Un punto y coma) puede provocar varios errores, pero la corrección es sólo una. Por otro lado, el diseño puede sufrir cambios durante el desarrollo debido a la aparición de ideas mejores u optimizaciones (o, simplemente, cambios en el parecer del cliente que también ocurre con más frecuencia de la deseada). Esto no se consideran defectos (otra cosa sería cometer un error en los requisitos, con lo que sería un defecto de requisitos).Recuérdese que se considera defecto aquellos que aparecen tras la codificación (si se nota algo mientras se está codificando y se corrige antes determinar, no se considera defecto).Conviene contabilizar los defectos cuando se termine cada fase (diseño, codificación). Sin embargo, dentro de una misma fase (por ejemplo codificación), si se hace un módulo y luego un segundo, y a mitad del segundo módulo se descubre un defecto en el primero, sí es un defecto. Para aprender a reunir datos de defectos, conviene comenzar por contabilizar sólo los de compilación y pruebas hasta que se tome práctica.
2.2.3 Formas de encontrar y corregir defectos Aunque no hay forma de acabar con la introducción de defectos, es posible encontrar y eliminar casi todos los defectos al principio del desarrollo. Siempre están implicados estos métodos:
Identificar los síntomas del defecto. Deducir de estos síntomas la localización del defecto. Entender lo que es erróneo en el programa. Decidir cómo corregir el defecto. Hacer la corrección. Verificar que el arreglo ha resuelto el programa.
Mediante pruebas.
Las pruebas de unidad encuentran sobre el 50% de los defectos lógicos. Las de sistema entre un 30% y un 40%. Pero no podemos probar todos los casos. La más común de todas: Que los detecten los usuarios.
7
Durante un año, IBM gastó 250 millones de dólares en reparar y reinstalar correcciones de 13,000 errores encontrados por los usuarios: 20,000 dólares por defecto. La calidad de las pruebas por el grado en que estos escenarios cubren todas las funciones importantes del programa. Aunque las pruebas pueden utilizarse para comprobar casi cualquier función del programa, tiene varias desventajas. Primero como con los compiladores, las pruebas solo suponen el primer paso de corrección de defectos. Otro problema, es que cada prueba verifica solamente un conjunto de condiciones del programa. Según Humphrey, la forma más rápida y eficiente es revisando personalmente el código fuente. Así se ven los problemas, no los síntomas. Sin embargo, con experiencia encontrará una media del 75% al 80% de los defectos. Se necesitan, al menos, 30 minutos para revisar 100 LOC (lines of code).Otra forma de encontrar los defectos es la más común de todas, consiste en entregar programas defectuosos y esperar que los usuarios identifiquen e informen de los defectos. Esta es la estrategia más costosa. Por último, indicar que la forma más efectiva de encontrar y corregir defectos es revisar personalmente el código fuente del programa. Aunque esto puede parecer una forma difícil de limpiar un programa defectuoso. Se trata de la forma más rápida y eficiente. La causa de que la revisión de código sea tan eficiente, es porque cuando haces revisiones, ves los problemas no los síntomas. Es decir, mientras revisas el código, piensas sobre lo que el programa debe hacer. Las revisiones también tienen desventajas. Las dos desventajas principales son que las revisiones de código consumen tiempo y es difícil hacerlas correctamente.
2.2.4 El costo de encontrar y corregir defectos El costo medio de encontrar y corregir un defecto crece unas 10 veces en cada paso del proceso de desarrollo. Aunque el tiempo de corregir los defectos varía enormemente, estos valores medios muestran, a pesar de todo, los tipos de defectos. El tiempo de encontrar los defectos en las pruebas de integración, de componentes o del sistema, también variará con el tamaño y la complejidad del sistema. Una vez que los productos son entregados a los clientes, el coste de encontrar y corregir los defectos puede ser mucho mayor, dependiendo de la clase de productos y de los tipos y número de clientes. Además del coste, una razón de igual importancia para encontrar los defectos al principio es que la compilación, depuración y las pruebas tienen una efectividad reducida. Así, si se requiere producir un producto de alta calidad, tendrás que producir un programa sin defectos al principio o esperar dedicarle mucho tiempo en las pruebas.
8
Un estudio marca que: Durante la revisión, se encuentra 1 error cada 1 ó 2 minutos. Durante las pruebas de unidad, 1 error cada 10 ó 20 minutos. En las pruebas de integración, 10 a 40 horas. Datos reales: Una pequeña empresa: Con PSP, las pruebas de integración duraron 2 semanas. Con el módulo desarrollado sin PSP, las pruebas duraron varias semanas, con 300 horas por defecto. Un sistema aeroespacial necesitó: Una media de 40 horas por defecto en las pruebas del sistema de navegación aérea. En Digital Equipment Corporation, para un sistema, el tiempo mínimo para encontrar y corregir cada defecto informado por el cliente fue de 88 horas.
2.3. Listas de comprobación. Una lista de comprobación (checklist, en inglés) es una herramienta de ayuda en el trabajo diseñada para reducir los errores provocados por los potenciales límites de la memoria y la atención en el ser humano. Ayuda a asegurar la consistencia y exhaustividad en la realización de una tarea. Un ejemplo sencillo de una lista de comprobación sería una lista de tareas pendientes. Un ejemplo más complejo sería una planificación, donde se detallan las tareas que hay que realizar dependiendo del horario, el día, u otros factores.
Aplicaciones
Dentro de la seguridad aérea, se utilizan listas de comprobación previas al despegue de las aeronaves para asegurar que ninguna tarea crítica se ha olvidado. En medicina, se recomienda su uso para comprobar que se siguen las pautas establecidas en la práctica clínica. Un ejemplo sería la Surgical Safety Checklist desarrollada para la Organización Mundial de la Salud por el doctor Atul Gawande.2 La evidencia que soporta la efectividad de las listas de comprobación en la cirugía es provisional, pero limitada.3 En ingeniería de programas informáticos se utilizan para asegurar la calidad, cumplimiento de procedimientos, estandarización de código de programación, prevención de errores y otros. Se emplean con frecuencia en procesos industriales. Su uso en litigios permite reducir la complejidad de los recursos o la evaluación y examen de las pruebas en un proceso judicial. Son utilizadas por algunos analistas financieros como un elemento crítico en la toma de decisiones sobre inversiones. Su empleo puede reducir las demandas por negligencia, al justificar que su uso evidencia que existía un sistema de gestión del riesgo.
9
Formato Una lista de comprobación suele tener un párrafo de texto para cada tarea, con un cuadrado vacío en la parte izquierda. Una vez que la tarea ha sido completada, el cuadrado se rellena con una pequeña marca de verificación. Pero el formato depende del sector de actividad en el que se esté utilizando. En aviación, por ejemplo, la lista consiste en un sistema y una acción divididos por una línea de puntos. En este ámbito no se utilizan las marcas de verificación porque las listas se suelen leer en alto y están pensadas para reutilizarse.
Limitaciones La excesiva dependencia de las listas de comprobación puede comprometer el rendimiento en situaciones donde el tiempo es un factor crítico, por ejemplo, en una urgencia médica o en una emergencia aérea. En cualquier caso, no deberían ser un sustituto del sentido común. La formación intensiva, incluyendo la memorización de las listas de comprobación, puede integrar su uso con otras técnicas de resolución de problemas más adaptativas y flexibles.
CONJUNTO DE REGLAS PARA LAS LISTAS DE COMPROBACIÓN Este conjunto de reglas deben emplearse para la planificación de una nueva inspección, tratando de no violar ninguna de ellas. Pero, al aplicar a una empresa nueva todo el proceso de inspección de software o que la empresa solo tenga el objetivo de mejorar el proceso de desarrollo de software, las listas de comprobación puede violar este conjunto de reglas, pero no por mucho tiempo, ya que, a medida que el proceso se retroalimente por la detección de los defectos, las reglas serán cumplidas satisfactoriamente. Una lista de comprobación debe derivarse del sistema de reglas generales del producto en desarrollo. •Cada pregunta de la lista de comprobación debe incluir una referencia a la etiqueta de la regla que interpreta dentro de un estándar o reglamentos internos de la empresa desarrolladora. •Las listas de comprobación deben ser actualizadas cuando sea necesario para reflejar el descubrimiento de los defectos importantes no incluidos hasta este momento. •Las preguntas y objetivos para una lista de comprobación no debe exceder de una sola página física. •Las descripciones de las preguntas y objetivos de la lista de comprobación pueden incluir las sugerencias para la severidad probable del defecto. •Está generalmente redactada cada pregunta, pero no necesariamente, para que una respuesta negativa identifique un defecto. •Las preguntas de la lista de comprobación deben concentrarse en divulgar defectos importantes. •Los resultados de la lista de comprobación no debe emplearse de mala forma para definir una nueva regla.
10
2.4. Gestión del tiempo para el desarrollo de sistemas de información. El tiempo en el ciclo de vida de un proyecto es primordial y tenerlo vigilado en todo momento como el tiempo, costo y alcance son la triple restricción en un proyecto, es decir, que cuando estos se definen al momento de realizar el acta de constitución, no puedes sobrepasar estos valores.
En el caso del tiempo, si un proyecto está planificado para seis meses, el administrador debe hacer todo lo posible para que el proyecto sea realizado en esos seis meses y el sobrepasar ese tiempo definido conlleva a perder dinero, ya sea en multas para la empresa que hace el proyecto siendo el principal responsable el administrador del proyecto, y por el hecho de estar retrasado requerir más dinero (dinero adicional a lo ya definido en la acta de constitución) para la rápida culminación del proyecto.
El objetivo principal de la gestión del tiempo es terminar el proyecto en el plazo de tiempo definido logrando realizar el alcance del proyecto en el tiempo, costo y calidad esperado por el cliente. La Gestión del Tiempo del Proyecto comprende los procesos necesarios para lograr que el proyecto se complete a tiempo. Los procesos que incluye la Gestión del tiempo son los siguientes:
Definición de las Actividades
Se identifican las actividades específicas del plan de trabajo que se deben ejecutar para crear los productos entregables del proyecto. Actividad Reunión con cliente
Descripción Responsable Reunión formal con el Administrador y equipo de cliente y equipo de desarrollo desarrollo
Elaboración del Reunión del enunciado del proyecto proyecto
equipo
de Administrador y equipo de desarrollo
Creación de la EDT Reunión de equipo de Administrador y equipo de (Estructura de Desglose desarrollo para definición de desarrollo de Trabajos) EDT Elaboración de plan de Reunión del equipo de Administrador y equipo de gestión de riesgos desarrollo para creación de desarrollo 11
un plan de gestión de riesgos Reunión con personal de Entrevista con el personal Personal de empresa cliente de la empresa cliente para requerimientos recolección de datos
toma
de
Reunión del equipo de Reunión del equipo de Administrador y equipo de desarrollo desarrollo para la definición desarrollo de la arquitectura del software Implementación módulos
de Desarrollo de los módulos Equipo de desarrollo del software
Establecimiento de la Secuencia de las Actividades Se muestran y se documentan las dependencias entre las actividades del plan de trabajo.
En la figura 1, la actividad A es reunión con el cliente y la actividad B es elaboración del enunciado del proyecto. Primero se ejecuta la actividad A y luego la actividad B, esta actividad es de tipo Final a inicio (FI).
Estimación de Recursos de las Actividades Establece el tipo y las cantidades de recursos necesarios para llevar a cabo cada actividad del plan de trabajo.
12
Estimación de la Duración de las Actividades Se calcula la cantidad de tiempo necesario para completar cada actividad del cronograma.
13
Desarrollo del Cronograma Se analiza el orden en que se deben ejecutar las actividades, las duraciones, la necesidad de recursos, las restricciones de tiempo que se tengan para crear el cronograma del proyecto.
14
Control del Cronograma Se controlan los cambios al plan de trabajo. El trabajo que se requiere para la ejecución de los seis procesos de Gestión del Tiempo del Proyecto está precedido por una planificación previa de parte del equipo de dirección del proyecto.
Esta tarea de planificación es parte del proceso Desarrollar el Plan de Gestión del Proyecto, que produce un plan de trabajo que determina el formato y establece los lineamientos para desarrollar y controlar el cronograma de trabajo del proyecto. El cronograma de trabajo está incluido en el plan de gestión del proyecto, o es un plan secundario del mismo, y puede ser formal o informal, poco, o ampliamente detallado, dependiendo de las necesidades del proyecto. El control de cronograma implica: - Determinar el estado actual del cronograma del proyecto. - Influir sobre los factores que crean cambios en el cronograma. - Determinar que el cronograma del proyecto ha cambiado. - Gestionar los cambios reales a medida que suceden.
15
Procesos y características de la Gestión de los Riesgos del Proyecto La Gestión de los Riesgos del Proyecto comprende los procesos relacionados con la planificación de la gestión de riesgos, la identificación y el análisis de riesgos, las respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto. Los objetivos de esta gestión son aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos negativos dentro del proyecto. Los procesos de Gestión de los Riesgos del Proyecto son los siguientes: Planificación de la Gestión de Riesgos Se planifica la ejecución de las actividades de gestión de riesgos para el proyecto. Identificación de Riesgos Se analizan los riesgos que pueden afectar al proyecto y se documentan sus características. Análisis Cualitativo de Riesgos Consiste en establecer la prioridad de los riesgos para realizar otros análisis o acciones posteriores, se trata de evaluar la probabilidad de ocurrencia y su impacto. Análisis Cuantitativo de Riesgos Analiza matemáticamente el efecto de los riesgos identificados dentro del plan del proyecto. Planificación de la Respuesta a los Riesgos Se evalúan las opciones y acciones necesarias para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Seguimiento y Control de Riesgos Es el proceso que le da el seguimiento a los riesgos previamente identificados, además supervisa los riesgos residuales, e identifica los nuevos que podrían aparecer, ejecuta planes de respuesta en caso de que los riesgos se conviertan en realidad. Un riesgo en un proyecto es un evento o condición no predecible, que en caso de producirse tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, y los objetivos están estrechamente relacionados con el tiempo, el costo, el alcance o la calidad. Las condiciones de riesgo dentro del proyecto se pueden ver afectadas por prácticas deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, múltiples proyectos concurrentes o por depender de participantes externos que no pueden ser controlados.
2.5. Obtener calidad en los sistemas de información (métodos, métricas, metodologías, estándares).
Investigado por el alumno. 16
2.6. Controlar la calidad del sistema de información. El diccionario define la calidad como un atributo o característica que es asociada con algo. Siendo un concepto tan genérico, debe ser definida por cada área u organización para que conforme a estos atributos o características, sea posible medir la calidad de un producto. Es por eso que el control y el Aseguramiento de Calidad juegan un papel muy importante en todo tipo de empresas. En las áreas u organizaciones de TI la principal responsabilidad del aseguramiento de calidad es determinar si las necesidades de los usuarios han sido satisfechas adecuadamente. Pero éstas deben ser vistas bajo su perspectiva en conjunto con las necesidades de otros usuarios y sobre todo en conjunto con los objetivos y metas de la organización. El Aseguramiento de Calidad evalúa los sistemas antes de su instalación sin discernir si se trata de nuevos desarrollos, nuevas funcionalidades o mantenimientos y para ello esta función evalúa tres elementos: 1. Objetivos. ¿El sistema cubre los objetivos del usuario y de toda la organización? Las metas de la organización deben ser consideradas en primer lugar dando pauta a los objetivos de los requerimientos del usuario. El grupo de Aseguramiento de Calidad debe resaltar los conflictos entre ambos objetivos, debe asegurarse de que los objetivos de unos y otros se encuentren en armonía. Siempre sin lugar a duda los objetivos de los requerimientos deben coadyuvar al cumplimiento de los objetivos de la organización. 2. Métodos. ¿Se encuentran estandarizados los métodos empleados en el desempeño de la función de las organizaciones de TI? Estos métodos se ven manifiestos en las políticas, procedimientos, estándares y guían la función del grupo, debe evaluar su cumplimiento a lo largo del desarrollo del trabajo. 3. Desempeño. ¿El equipo de desarrollo de sistemas ha optimizado el uso de hardware y software cuando desarrollan las aplicaciones? Esto involucra un diseño calificado del sistema y el uso de las técnicas de programación apropiadas. De hecho, debido al tipo de evaluación realizada por el grupo de aseguramiento de calidad es que generalmente lo ven más como un policía que como un aliado y/o asesor. Pero ese es uno entre otros tropiezos a los que se enfrentan los equipos que desempeñan las funciones de calidad y que no se hablará de ello por ahora. Por otro lado, y no más simple, el papel del control de calidad es comparar el producto contra otro producto cuyo estándar y atributos han sido claramente definidos y son usados 17
como referencia de comparación. El propósito del control de calidad es identificar defectos y corregirlos antes de terminar el producto. El control de calidad se limita a revisar los productos y esta función puede ser desempeñada por los desarrolladores mismos. Actividades tales como la revisión de sistemas y pruebas de software son actividades de Control de Calidad. Aseguramiento de Calidad vs Control de Calidad El aseguramiento de calidad es una función que administra calidad. Establece controles de calidad pero no desempeña el rol de la función del Control de Calidad como tal, inspeccionando productos. El aseguramiento de calidad utiliza los resultados del Control de Calidad para evaluar y mejorar los “procesos” que generan los productos. Por lo tanto vemos que el aseguramiento de Calidad trabaja con procesos y el Control de Calidad trabaja con productos. Dado que las organizaciones y las definiciones de los niveles de calidad son constituidas bajo la percepción humana no se debe soslayar que los programas de calidad y mejora continua deben establecerse y definirse enfocándose en quienes generan y utilizan los productos más que en los productos mismos, es por eso que el concepto de control de Calidad no sustituye al Concepto de Aseguramiento de la Calidad, se requiere de ambos para escucharse y complementarse uno al otro permitiendo que la percepción humana no pierda su subjetividad. Ambas funciones no pueden vivir aisladas y esa es una de las vicisitudes que deben manejar todo grupo de trabajo en las prácticas de mejora continua e instrumentaciones de modelos de calidad. El aseguramiento de calidad requiere de procesos establecidos y que el control de calidad se encuentre muy bien introducido en dichos procesos para poder proveer información acerca de los defectos encontrados al grupo de aseguramiento de calidad. Refinar e instrumentar ambas cosas al enfrentarse a una organización se convierte en una actividad creativa y de psicología organizacional para determinar cómo se introducen estas funciones en las organizaciones. Algo sí es cierto, se podrán establecer los mejores programas de mejora o de control de calidad, pero sin un buen plan de aseguramiento de calidad, lo invertido, en un plazo no muy largo se convertirá en algo simplemente recordado y guardado en los servidores. Las organizaciones aprenden sí, pero entonces ¿cómo te das cuenta que ya es tiempo de ‘afilar el hacha’?, por lo que no se debe olvidar nunca asignar presupuesto y recursos para un grupo de aseguramiento de calidad con contrato de tiempo indefinido.
18
¿Cómo ayuda un Grupo de Aseguramiento de Calidad a una organización TI?
Cambiando la tecnología cuando lo vea necesario. Evaluando cuando abortar un proyecto Como son llevados los proyectos y brindando asesoría de seguimiento y control Evaluando objetivamente cuando son o no claramente especificadas las necesidades del usuario y dando asesoría para que las expectativas del usuario sean cumplidas y especificadas claramente en los requerimientos
Auditando los requerimientos Siendo consultores internos dado el conocimiento adquirido por los diversos proyectos en
que el grupo participa. Ayudando a desarrollar o complementar estándares de desarrollo.
Evaluando herramientas para las áreas de desarrollo. Siendo agente de cambio cultural Promoviendo y asegurando la buena comunicación entre los involucrados en los proyectos y la alta dirección. La única manera de garantizar que esta ayuda será recibida es eligiendo a las personas correctas para desempeñar las actividades listadas. ¿Cómo sabemos que se cuenta con las personas correctas? Su preparación, capacidad de aprendizaje y experiencia en el desarrollo de aplicaciones se combinan con habilidades de liderazgo, búsqueda de empatía con el comportamiento organizacional y actitud positiva de trabajar en equipo y transferir conocimiento. Dado el perfil descrito: las técnicas existentes para detectar las habilidades y experiencia de las personas ayudarán a encontrar a las personas que mejor se adhieran al mismo. Crear un organigrama con la descripción detallada de roles para delinear las responsabilidad del grupo y su alcance, especificar el nivel de autoridad del grupo en cada aspecto de su rol y afirmar las expectativas de alta calidad por parte del ejecutivo una vez que la nueva estructura organizacional se ha hecho del conocimiento de todos los miembros de la organización como parte de su total apoyo para que el grupo desempeñe sus funciones. De hecho se recomienda que el grupo de Aseguramiento de Calidad quede al nivel suficientemente superior e independiente para favorecer la objetividad y autoridad necesaria en el desempeño de sus funciones.
19
2.7. Costo de calidad de los sistemas de información. El argumento es algo parecido a esto: sabemos que la calidad es importante, pero cuesta tiempo y dinero - demasiado tiempo y dinero- lograr el nivel de calidad en el software que en realidad queremos. Visto así, este argumento parece razonable. No hay duda de que la calidad tiene un costo, pero la mala calidad también lo tiene -no sólo para los usuarios finales que deban vivir con el software defectuoso, sino también para la organización del software que lo elaboró y que debe darle mantenimiento-. La pregunta real es ésta: ¿por cuál costo debemos preocupamos? Para responder a esta pregunta debe entenderse tanto el costo de tener calidad como el del software de mala calidad. El costo de la calidad incluye todos los costos en los que se incurre al buscar la calidad o al realizar actividades relacionadas con ella y los costos posteriores de la falta de calidad. Para entender estos costos, una organización debe contar con unidades de medición que provean el fundamento del costo actual de la calidad, que identifiquen las oportunidades para reducir dichos costos y que den una base normalizada de comparación. El costo de la calidad puede dividirse en los costos que están asociados con la prevención, la evaluación y la falla. Los costos de prevención incluyen lo siguiente: 1) el costo de las actividades de administración requeridas para planear y coordinar todas las actividades de control y aseguramiento de la calidad, 2) el costo de las actividades técnicas agregadas para desarrollar modelos completos de los requerimientos y del diseño, 3) los costos de planear las pruebas y 4) el costo de toda la capacitación asociada con estas actividades.
20
Los costos de evaluación incluyen las actividades de investigación de la condición del producto la "primera vez" que pasa por cada proceso. Algunos ejemplos de costos de evaluación incluyen los siguientes: • El costo de efectuar revisiones técnicas de los productos del trabajo de la ingeniería de software. • El costo de recabar datos y unidades de medida para la evaluación. • El costo de hacer las pruebas y depurar. Los costos de falla son aquellos que se eliminarían si no hubiera errores antes o después de enviar el producto a los consumidores. Los costos de falla se subdividen en internos y externos. Se incurre en costos internos detalla cuando se detecta un error en un producto antes del envío. Los costos internos de falla incluyen los siguientes: • El costo requerido por efectuar repeticiones (reparaciones para corregir un error). • El costo en el que se incurre cuando una repetición genera inadvertidamente efectos colaterales que deban mitigarse. • Los costos asociados con la colección de las unidades de medida de la calidad que permitan que una organización evalúe los modos de la falla. Los costos externos de falla se asocian con defectos encontrados después de que el producto se envió a los consumidores. Algunos ejemplos de costos externos de falla son los de solución de quejas, devolución y sustitución del producto, ayuda en línea y trabajo asociado con la garantía. La mala reputación y la pérdida resultante de negocios es otro costo externo de falla que resulta difícil de cuantificar y que, sin embargo, es real. Cuando se produce software de mala calidad, suceden cosas malas.
21
En lo que constituye una acusación contra los desarrolladores de software que se rehúsan a considerar los costos de falla externos, Cem Kaner [Kan95] afirma lo siguiente: Muchos de los costos de falla externos, tales como los fondos de comercialización, son difíciles de cuantificar, por lo que muchas compañías los ignoran cuando calculan sus relaciones costo-beneficio. Otros costos externos de falla pueden reducirse (al dar un apoyo barato debido a la mala calidad después de hacer la venta, o al cobrar el apoyo a los consumidores) sin que se incremente la satisfacción del cliente. Al ignorar los costos que los malos productos generan a nuestros compradores, los ingenieros de la calidad estimulan una toma de decisiones que los hace víctimas en lugar de satisfacerlos. Como es de esperar, los costos relacionados con la detección y la corrección de errores o defectos se incrementan en forma abrupta cuando se pasa de la prevención a la detección, a la falla interna y a la externa. La figura siguiente, basada en datos obtenidos por Boehm y Basili.
2.7.1. Cálculo del costo de la calidad El costo promedio de la industria por corregir un defecto durante la generación de código es aproximadamente de US$977 por error. El promedio del costo en el que incurre la industria por corregir el mismo error si se descubre durante las pruebas 22
del sistema es de US$7,136. Cigital, lnc. [Cig07] tome en cuenta que una aplicación grande contiene 200 errores introducidos durante la codificación. De acuerdo con datos promedio, el costo de encontrar y corregir defectos durante la fase de codificación es de US$977 por defecto. Entonces, el costo total por corregir los 200 errores "críticos" durante esta fase es de (200 x US$977) US$195 400, aproximadamente. Los datos promedio de la industria indican que el costo de encontrar y corregir defectos durante la fase de pruebas del sistema es de US$7 136por cada uno. En este caso, si se supone que en dicha fase se descubren aproximadamente 50 defectos críticos (tan sólo 25%de los descubiertos por Cigital en la fase de codificación), el costo de encontrarlos y corregirlos (50 x US$7 136) sería aproximadamente de US$356 800. Esto también habría resultado en 150 errores críticos no detectados ni corregidos. El costo de encontrar y corregir estos 150defectos en la fase de mantenimiento (150 x US$14 102) habría sido de US$2 115 300. Entonces, el costo total de encontrar y corregir los 200 defectos (US$2 I 15300 + US$356 800) después de la fase de codificación habría sido de US$2 472 100. Aun si la organización de software tuviera costos que fueran la mitad del promedio de la industria (la mayor parte de compañías no tiene idea de cuáles son sus costos), los ahorros asociados con el control de calidad temprano y las actividades para su aseguramiento (efectuadas durante el análisis de los requerimientos y el diseño) serían notables.
23
